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

[Pekka Savola <pekkas@netcore.fi>]

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