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

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

Pekka,

I see your points but if we are to use your model as editor then we need
to be consistent in all specs at what level of detail we go into for the
technical protocol specs (as opposed to operational technical ones).  I
think it comes down to what detail and health warnings we put in
documents and I think that is AD and Chairs decision. But whatever it is
lets keep it for all documents.  I have seen Alex's issues in other docs
and other members presented on other specs.  Be good to know the rules
of engagement for v6ops at this juncture with this spec.

Thanks
/jim 

> -----Original Message-----
> From: owner-v6ops@ops.ietf.org 
> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola
> Sent: Tuesday, August 17, 2004 7:50 AM
> To: Alex Conta
> Cc: Erik Nordmark; v6ops@ops.ietf.org; gilligan@intransa.com; 
> david.kessens@nokia.com; jonne.Soininen@nokia.com
> Subject: Re: 12 Problems with 
> "draft-ietf-v6ops-mech-v2-04.txt" : was RE: Reminder: 
> clarification....
> 
> On Mon, 16 Aug 2004, Alex Conta wrote:
> > 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.
> [...]
> 
> (I'll respond with only the document editor hat on.)
> 
> I'll try to summarize your issues in a different way (please 
> clarify if something is missing):
> 
>  A) you want to explicitly spell out that the encapsulator 
> address is configured on the node, and sprinkle that 
> information throughout the document. (Problem 1, part of 
> problem 2, problem 3, problem 4, problem 6, problem 11).  
> 
> Response: there are arguments against doing so, because it is 
> not necessary for protocol interoperability.  I want to see 
> more support from the WG if this would go in.  Erik Nordmark 
> voiced support for the initial versions offlist, but has been 
> quiet since -- it is not clear whether this is due to 
> agreement (with either party) or not.
> 
> I will also note that none of the protocol problems you state seem
> convincing: breaking IP frag, breaking ICMP, breaking dynamic 
> MTU, breaking point-to-point link appearance.  The first 
> three are just basic properties of IPv4 routing: if you 
> insert wrong source address, you don't get the return 
> packets.  The last still holds but between addresses, not the 
> nodes (it might be possible to make this more explicit with 
> an editorial correction to the definition of a tunnel, to set 
> the right expectations).  The security problem is not a real 
> issue, because the attackers have easier time just sending 
> the packets using raw sockets or whatever, not by configuring 
> a tunnel interface
> -- this would create a false sense of security at best 
> because you just can't trust the encapsulators to behave well 
> in any case.
> 
>  B) you want to spell out that the source address is used as 
> a filter for inbound packets (i.e., which tunnel they belong 
> to), and that the addresses MUST be the same on entry & exit 
> points, (the rest of problem 2)
> 
> Response: this is a clarification which is not required for 
> protocol interoperability.  Further, it may restrict the 
> implementators of the protocol.  It also adds a MUST for 
> which an implementor has no way of ensuring it's fulfilled 
> (there is no way to check what the other end has configured 
> -- either it works or it doesn't) -- so this is an 
> unnecessary specification.
> 
>  C) you want to add a MUST to generate protocol-41 
> unreachables when you receive a packet with incorrect source 
> address. (problem 7, problem 12)
> 
> Response: this has already been discussed. Please check the 
> archives at http://ops.ietf.org/lists/v6ops/v6ops.2003/ 
> (scroll down to "RFC
> 2893 Question - Ingress Filtering of IPv6-in-IPv4").  There 
> are good reasons why no ICMP feedback is *required* (however, 
> it's still compliant to send one if you want, it's SHOULD NOT 
> in the spec.).
> 
>  D) you'd like to see a couple of editorial changes (problem 
> 5, problem 9, problem 10)
> 
> Response: 5 & 9 can be easily fixed at AUTH48.  I don't 
> understand the problem 10 at all as by definition all the 
> tunnels are now bidirectional.  If egress is towards X, 
> ingress is coming from X.  
> Wording suggestions are welcome if really necessary.
> 
> Summary:
> 
> Keeping in mind the current state of the document (past WG 
> last call, past IETF last call, past IESG evaluation), there 
> is very strong reason to make no changes unless there is a 
> strong reason to do so.
> I'll take editorial issues to the account (issue D), but 
> unless there is WG consensus, I will not incorporate other 
> changes as they do not seem to be sufficiently do not seem to 
> fulfill the "very strong reason" criterium.
> 
> (editor hat off)
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
> 
>