[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


As a clarifications:

I have no interest or benefit in blocking or delaying the publishing of this document as an RFC.

I have a definite interest in having a good quality document.

Quality is more of an issue than time.

I am not happy at all that I found these problems, I would have been a lot happier to find none.

I do not have a lot of time to spend on this, or debate this - I already spent a lot more time than I initially planned or hoped.

Pekka Savola wrote:

On Mon, 16 Aug 2004, Alex Conta wrote:

(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):


I have ordered the problem descriptions and suggestions in the order of the sections in the document to make them flow with the reading of the document.

I am not sure I understand the use of this new exercise, but with the hope it will help resolving the problems, here it is:

NOTE: A majority of the technical problems were described to you already by me or by Erik N. in the private Email exchange we had, in quite a bit of detail, so they should not be new to you.

A) you want to explicitly spell out that the encapsulator address is configured on the node, 

NO. I want a tunneling rule, and/or the previous specs rule, followed.

The tunneling rule is that the source address in a tunnel packet MUST be one of the encapsulator's addresses - see Problem 3 and 4.

This is captured in two rules:
Rule 1.
If the tunnel source address is selected automatically by the encapsulator, it MUST be one of the encapsulator's addresses, preferable the tunnel packets outgoing interfaces.

Rule 2.
If the tunnel source address is configured on the encapsulator, which is OK, it MUST follow the same rule as 1, that is, MUST be one of the encapsulator's addresses, preferable the tunnel packets outgoing interface.

and sprinkle that information throughout the document. (Problem 1, part of problem 2, problem 3, problem 4, problem 6, problem 11). 


Please read carefully my message; it is not only sprinkling that info.

Problem 1, 2 are independent. Section 1.1 and Section 3 are incomplete, as they seem to be left as they were before the changes, and have not followed the changes that this document has undergone.

Problem 6 and 11 are both independent from each other, and from the rest. They're inadequate wording, and thus editorial. They're completely independent of anything else.


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.


Erik N. pointed out also a number of problems.

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. 

You had both me and Erik N. point to and explain these problems.
Here it is once more, this time for the list:

The spec suggests configuring the encapsulator with a source address which is not one of its addresses. This is a departure from the IP architecture, one of the basic functions of the IP, and has the following immediate consequences:

- broken virtual point-to-point link:

The tunnel is a virtual point-to-point link between the encapsulator and decapsulator. Tunnel packets originate on the encapsulator, and thus must have as source the outgoing interface address or one of its other addresses.

When the encapsulator sends packets with a source address which is not one of its interfaces, it breaks the vptop mechanism.

Also, if a node can be configured accidentally, or intentionally, with a tunnel source address different than its own addresses, it is possible to configure multiple encapsulators with the same source, but same
decapsulator. This is a non-traditional multi-point to point link, and thus different from the vptop, specified in this document.

To repeat Erik N.'s comment, if the source address is an anycast address, that MUST be said so, and dealt with it appropriately, and not just pushed under the rug.

- breaking ICMP.

If an intermediate router on the tunnel path detects an error in a tunnel packet that has a source address which is not one of the encapsulator's addresses, the ICMP message cannot reach the encapsulator, and the forwarding of the packet may have unpredictable results.

This may have unpredictable results.

- breaking dynamic MTU (problem pointed out by Erik N.)

If a tunnel packet has a source address different than one of the encapsulator's addresses, Path MTU ICMP messages cannot reach the encapsulator. This breaks the dynamic MTU mechanism.

- breaking IP fragmentation (problem pointed out by Erik N.)

If multiple encapsulators have the same source address, and there is fragmentation on each of them, the spec does not specify how to coordinate the IP fragment IDs, so the packet reassembly will not get confused on the decapsulator. This breaks IP fragmentation.

- other consequences may exist.

The first three are just
basic properties of IPv4 routing: if you insert wrong source address,
you don't get the return packets. 

This is missing the point.

The expectation is that when one follows correctly this protocol specification the result is a working IPv6inIPv4 tunnel.

In this case, one configuring an address that is not one of the encapsulator's addresses is following correctly the specification.
However the result is a non-working IPv6inIPv4 tunnel.

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).

A node has interfaces, which are the node's attachments to adjacent links. Addresses identify interfaces in the network. Point to point links are between ptop interfaces.

I am afraid, a new, technically different definition of a tunnel cannot be an editorial change.

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

The way you allow the configuring of the encapsulator is breaking the very mechanism that you created or existed in the decapsulator, which is checking the encapsulator's source address.

This creates exactly the very problem that it is mentioned in the Security section as a problem.

-- this would create a false sense of security at best because you
just can't trust the encapsulators to behave well in any case.


I agree with that (false sense of security), but then why not remove the decapsulator source address check all together?

 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)


Problem 2 is simply insufficient text.

The changes done on this document on some text resulted in that text being removed, or moved in the wrong place. Consequently the specification has holes when compared to its predecessor, RFC 2893, and for a draft standard it MUST be corrected.

The suggestion is supposed to plug the holes.

Response: this is a clarification which is not required for protocol
interoperability. 

This does not seem an accurate characterization.

Currently two IP implementations that are configured according to the spec, may not work, that is, they may not interoperate.

The suggestion spells out the configuration requirements, and helps the configuring, with the result of a working IPv6inIPv4 tunnel, which is to have two implementations interoperate.

In conclusion is that the suggestion resolves interoperability problems, and thus is required for interoperability.

Further, it may restrict the implementators of the
protocol.

Rewording "restrict", with "driving in the right direction" would be more accurate.

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.

The MUST is related to the configuring of addresses, not to implementation. This is also an operational spec isn't it?


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.).


I do not have the time to check the archives.

I simply pointed out, that currently there is a black hole effect.

That means, it is possible to have a legitimate configuring of a tunnel between two nodes, according to the spec, but a tunnel failure, with packets seemingly going nowhere, and have no indication of the reason the tunnel packets sent from one node do not get to the other.

Furthermore, having it both ways, /w and w/ ICMP messages seems  confusing.

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.


The text is confusing to the extent that I can have several correct but opposite interpretations.

I could work on this with you, but for that I need you qualify the nouns, and verbs in those sentences, so I can see what the spec (or you) really wanted to say.

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.


You had one person (me) and a previous co-author (Erik N.) pointing you these problems.

(editor hat off)

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature