RE: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: clarification....

["Bound, Jim" <jim.bound@hp.com>]

I think Alex's suggestions are fine what is the problem here folks it
does not affect current implementation and provides useful added
guidance?  

Thanks
/jim 

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Alex Conta
> Sent: Monday, August 16, 2004 9:14 PM
> To: Pekka Savola
> Cc: Erik Nordmark; v6ops@ops.ietf.org; gilligan@intransa.com; 
> david.kessens@nokia.com; jonne.Soininen@nokia.com
> Subject: 12 Problems with "draft-ietf-v6ops-mech-v2-04.txt" : 
> was RE: Reminder: clarification....
> 
> Pekka,
> 
> I am finally convinced: it is not easy to fix the document!
> 
> Sorry, IMHO the document is not ready for being published!
> 
> Unfortunately, the more you argued against the suggested 
> change, which seemed very obvious and very easy, the more you 
> made me go deeper into the document, and find one after 
> another all sorts of smaller or bigger problems with the 
> text, the protocol, or security of the protocol.
> 
> In conclusion, the document is not in a good shape, and I am 
> sorry to say it, but it is not ready to be published as an 
> RFC, and even less as a Draft Standard RFC. This document is 
> not ready to replace RFC 2893.
> 
> Here are the problems and suggested text 
> additions/modifications, which I hope will help.
> 
> Note: the original problem I contacted you about is included.
> 
> Problem 1
> Section 1.1 Terminology
> 
> Insufficient text in definition.
> 
> Configured tunneling
> 
>                  IPv6-over-IPv4 tunneling where the IPv4 
> tunnel endpoint
>                  address is determined by configuration information on
>                  the encapsulator.  All tunnels are assumed to be
>                  bidirectional, behaving as virtual 
> point-to-point links.
> 
> 
> 
> Suggestion:
> change the definition of configured tunneling to:
> 
> ---
> Configured tunneling:
> 
> 
>                   IPv6-over-IPv4 tunneling where the IPv4 
> tunnel endpoint
>                   address is determined by configuration 
> information on
>                   the encapsulator, and the tunnel entrypoint 
> address is
>                   one of the encapsulator addresses. All tunnels are
>                   assumed to be bidirectional, behaving as virtual
>                   point-to-point links.
> ---
> 
> Problem 2
> Section 3. Configured Tunneling Mechanisms
> 
> Insufficient text in definition of mechanisms that need configuration
> 
> Suggestion:
> Insert before the last paragraph (paragraph before the start 
> of Section
> 3.1) the following text:
> 
> ---
>      The tunnel entrypoint address is one of the encapsulator 
> addresses.
>      This address MAY be administratively configured, by manually
>      selecting one of the encapsulator's addresses. The 
> tunnel entrypoint
>      address is used as the source address of the encapsulating
>      header.
> 
>      The tunnel entrypoint address is also configured on the
>      decapsulator,
>      where it is used as a filter key to ensure that all packets
>      received on the tunnel were sent from the tunnel entrypoint.
> 
>      The tunnel entrypoint address used by the encapsulator as source
>      address of the tunnel packets and the tunnel entrypoint 
> address used
>      as a filter by the decapsulator MUST be identical.
> ---
> 
> 
> Problem 3
> Section 3.5 IPv4 Header Construction
> 
>   Following Text introduces protocol and security problem.
> ------
>             Source Address:
> 
> 
>                  IPv4 address of outgoing interface of the 
> encapsulator
>                  or an administratively specified address as described
>                  below.
> ------
> 
> 
> Protocol problem:
> 
> - Potentially brakes virtual point-to-point link appearance of tunnel.
> - Potential to defeat ICMP functioning in tunnel.
> - Potential to defeat dynamic MTU, which is specific 
> tunneling mechanism
> - Potential to defeat IP fragmentation in tunnel.
> 
> Security problem:
> 
> - Makes very easy accidental or intentional defeat of tunnel 
> packet filtering configured in decapsulator, documented in Section 4.
> 
> Suggestion:
> Change Source Address text to the following text:
> 
> 
>           Source Address:
> 
> 
>                   IPv4 address of outgoing interface of the 
> encapsulator
>                   or an administratively configured address 
> of one of the
>                   encapsulator's node addresses.
> 
> Problem 4
> Section 3.5 IPv4 Header Construction
> 
> Text of last paragraph is not sufficiently clear, language is 
> confusing.
> 
> Suggestion:
> Replace last paragraph with:
> 
>      The source address of the tunnel packets set by the 
> encapsulator in
>      the tunnel header MUST match the tunnel entrypoint address
>      configured in the decapsulator.
> 
>      As the selection of the outgoing interface depends on 
> the best route
>      to the tunnel exitpoint, when an encapsulator has multiple
>      interfaces
>      and it is known to be operating in a non-stable routing 
> environment,
>      the selection of the source address as the address of 
> the outgoing
>      interface may oscillate among the addresses of the node. 
> To prevent
>      this oscillation, it may be desirable to 
> administratively configure
>      the tunnel entrypoint on the encapsulator, by selecting 
> one of its
>      addresses, and thus pin a certain address
>      as the tunnel entrypoint. This would provide a stable 
> source address
>      in the tunnel
>      packets that matches the tunnel entrypoint address 
> configured in the
>      decapsulator. Obviously, this requires that the administrative
>      configuring of the tunnel entrypoint address on the encapsulator
>      SHOULD be possible.
> 
> Problem 5
> Section 3.6 Decapsulation
> 
> Language.
> 
> Suggestion:
> In first Paragraph change "the packet is potentially part of a tunnel"
> to "the packet is potentially a tunnel packet"
> 
> 
> Problem 6:
> 
> Language
> 
> Suggestion:
> Section 3.6 Decapsulation
> In Second Paragraph, last sentence change "IPv4 address of 
> the other end of a tunnel configured on the node" to "IPv4 
> address of the tunnel entrypoint. The tunnel entrypoint 
> address is information configured on the decapsulator."
> 
> Problem 7:
> Section 3.6 Decapsulation
> 
> Black hole effect, in case one misconfigures the tunnel 
> entrypoint, the tunnel exitpoint, or routing system 
> instability causes source address oscillation.
> 
> Node which was misconfigured has no way of finding out it did that.
> Misconfiguration can happen at any end of the tunnel.
> 
> Suggestion:
> Change third paragraph to:
> 
>      Packets for which the IPv4 source address does not match MUST be
>      discarded and an ICMP message MUST be generated, with 
> the error code
>      ICMPv4 Protocol 41 Unreachable.
> 
> Problem 8:
> Section 3.6 Decapsulation
> 
> Unnecessary text in paragraph 4.
> 
> Suggestion:
> Remove 4th paragraph.
> 
> Problem 9:
> Section 3.6 Decapsulation
> 
> Text misplaced in middle of paragraph 5. Text makes no sense.
> 
> Suggestion:
> Remove or clarify paragraph 5.
> 
> Problem 10:
> Section 3.6 Decapsulation
> 
> Text needs more clarity in last enumeration in section.
> 
>     1)   if the tunnel is towards the Internet, the node should be
>          configured to check that the site's IPv6 prefixes 
> are not used
>          as the source addresses, or
> 
> This is configuration in decapsulator? Decapsulation is 
> ingress operation, while "towards" is related to egress operation.
> 
>     2)   if the tunnel is towards an edge network, the node should be
>          configured to check that the source address belongs 
> to that edge
>          network.
> 
> This is configuration in decapsulator? Decapsulation is 
> ingress operation, while "towards" is related to egress 
> operation. How is belonging to an "edge" network determined?
> 
> Suggestion:
> Clarify last enumeration in section 3.6.
> 
> Problem 11.
> Section 5. Security Considerations
> 
> Text of first element in list of paragraph 4
> 
> Suggestion:
> 
> Change text
> 
> "IPv4 source address of the packet MUST be the same as 
> configured for the tunnel end-point,"
> 
> to
> 
> "IPv4 source address of the packet MUST be the same as the 
> tunnel entrypoint address configured in the tunnel exitpoint 
> (decapsulator),"
> 
> Problem 12.
> Section 5. Security Considerations
> 
> Last paragraph suggests mechanism that is black holing 
> accidental miconfigurations of tunnels, giving no alternative 
> mechanism to uncover the misconfiguration.
> 
> Suggestion:
> Remove, or clarify
> 
> 
> I hope this helps,
> Alex
> 
> Pekka Savola wrote:
> 
> > On Fri, 13 Aug 2004, Alex Conta wrote:
> > 
> >>Pekka Savola wrote:
> >>
> >>
> >>>[...]
> >>>
> >>>The proposition was to add language something like "the 
> >>>implementation MUST verify that a manually the source address, if 
> >>>manually configured, is an address of the node" to section 3.5.
> >>>[...]
> >>
> >>I am surprised to see here an interpretation of what I 
> suggested (and 
> >>Erik N. supported), which is not accurate, or correct.
> > 
> > 
> > You didn't provide your explicit suggestion so I had to try to 
> > summarize the best I could the point which seemed to be the 
> root cause 
> > for our debate :).
> > 
> > 
> >>Originally, and
> >>as a primary importance, I (and Erik N.) referred to the following 
> >>text in Section 3.5:
> >>
> >>               Source Address:
> >>
> >>
> >>                 IPv4 address of outgoing interface of the 
> encapsulator
> >>                 or an administratively specified address 
> as described
> >>                 below.
> >>
> >>and suggested replacing it with the following text:
> >>
> >>               Source Address:
> >>
> >>                   IPv4 address of the tunnel entrypoint 
> (encapsulator).
> >>
> > 
> > [Pekka:]
> > 
> >>>Would be OK, I guess.
> >>
> >>This is confusing. You seem to have changed your mind. Do 
> you agree or 
> >>not to this change?
> > 
> > 
> > I see no major fundamental objection to just making that particular 
> > change (except I'd rather avoid it due to being late in the 
> process).
> > Why I wrote it as above was that while I saw no fundamental problem 
> > with that particular change, its usefulness seemed to 
> depend on other 
> > changes which I was having bigger objections towards.  That is, it 
> > didn't seem that this particular change alone would have 
> satisfied all 
> > of us, and that was the reason for my wariness.
> > 
> > 
> >>The secondary importance text at the end of Section 3.5, that need 
> >>changing, and to which I made suggestions, as well as some text in 
> >>Section 3.6, which turns out at a careful reading to be 
> confusing, can 
> >>be discussed separately.
> > 
> > 
> > If there is no need to make other than minor editorial changes in 
> > section 3.5/3.6 apart from the quote above, I wouldn't have major 
> > objections, but I'd still like to get input from the WG.
> > 
> > I just think it's more confusing if it's changed as you 
> propose, if we 
> > assume that the point of the protocol specification is not prevent 
> > misconfiguration (but the implementations could, if they wish).  I 
> > think this is the main point we need to get a feeling about first.
> > 
> 
> 
>