Pekka,
I am finally convinced: it is not easy to fix the document!
Sorry, IMHO the document is not ready for being published!
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.
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
---
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:
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
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 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.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
to
Problem 12. Section 5. Security Considerations
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