[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Revised drafts -- Arch, AH, ESP
I don't read IPSec often anymore, but in working on my own found a new
error just introduced in the latest drafts:
> From: Karen Seo <kseo@bbn.com>
> In follow-up to Thomas Narten's (IESG) feedback (see Ted Ts'o's email of
> 3. Section 5.1.2.1 IPv4 -- Header Construction for Tunnel Mode -- added
> note to clarify decrementing of TTL.
>
> After the following paragraph:
> 2. The TTL in the inner header is decremented by the
> encapsulator prior to forwarding and by the decapsulator if
> it forwards the packet. (The checksum changes when the TTL
> changes.)
>
> we added:
> Note: The decrementing of the TTL is one of the usual actions
> that takes place when forwarding a packet. Packets
> originating from the same node as the encapsulator do not
> have their TTL's decremented, as the sending node is
> originating the packet rather than forwarding it.
>
The note is in error. The TTL is required to be decremented when
encapsulating into a tunnel in exactly the same way as when forwarding
into any other interface, even when the sending node originated the
packet, in order to prevent loops where the packet is decapsulated and
encapsulated and forwarded again. On many systems, there is no
distinction -- a tunnel is an interface. An originating node that makes
the mistake described in the note could be involved in such a loop.
This is a fundamental principle, and already proscribed in the various
tunnelling RFCs.
Since I don't want the publication of these documents to be delayed in
any way (see my response to the Last Call April 11), and it is already
July, and there are already many known failure modes inherent in these
documents, you could just leave the error. I just thought I ought to
tell you, since this error affects the work of so many other IETF WGs.
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
Follow-Ups: