Jim,
Regards, Alex
Regards, Alex
Bound, Jim wrote:
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.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature