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

Re: Revised drafts -- Arch, AH, ESP

Hello Bill,

>>....  I just thought I ought to tell you, since this error affects the
>>work of so many other IETF WGs.

	Since your email is addressed to the IESG (and cc'd to ipsec),
	presumably your comments are intended for the IESG.  However,
	just in case your feedback is intended primarily for the IPsec
	community and/or document editors, I've attached the rationale
	for this change below....  In short, the note was intended to
	address Thomas Narten's question/recommendation.  Charlie Lynn
	didn't hear back from any routing experts or other IETF folks so
	we went ahead with Thomas Narten's proposal (per Ted's direction
	on 5/22).

Thank you,
Karen


[From email to ipsec community from Ted Ts'o on 5/22/98]

>From: Thomas Narten <narten@hygro.raleigh.ibm.com>
>To: iesg@ietf.org
>Date: Fri, 24 Apr 1998 17:55:25 -0400
>Subject: Re: Ballot: Security Architecture for the Internet Protocol to Proposed Standard 
>......
>Text relating to decrementing TTL of inner header of encapsulated
>packet needs clarification.  Text should be clarified to say TTL
>decremented only if packet was forwarded (i.e., the forwarding
>operation is what decrements the TTL, not the fact that a complete IP
>packet is being encapsulated again upon entry to an IPSec tunnel). If
>packet originates from node, TTL is left unchanged. This is consistent
>with the current general practice of when to decrement TTLs, and some
>aspects of IPv6 protocols (i.e, ND) depend on it.

   My understanding is that everyone is implementing this anyway.
   Thomas in a later message suggested the following clarification, to
   be added after the text which described when the TTL in the inner
   header should be decremented:

	   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 TTLs decremented, as the sending node is
	   originating the packet rather than forwarding it.

   Charile Lynn has sent mail dissenting, claiming that it would be a
   bad thing to do this since it would imply that this would imply that
   IPSEC tunnels change the Internet Routing Topology, and if so, they
   might have to conform to all requirements for Internet Routers.  (I
   don't think that's the case today for normal IP-IP tunnels, is it?)

   Not clear what's the best way to resolve it.  If Charlie is right
   that this has some bad architectural implications, can we please get
   some Internet Routing experts to explain to us exactly what the
   problem is please?  (and quickly).

   If my sense that everyone is implementing it the way Thomas and what
   apparently what most of the IPV6 working group wants, then we might
   as well document that in the spec.  My instincts are to document what
   people are actually implementing and shipping as products, and if
   it's a problem we can fix it later.  This is *only* a proposed
   standard folks ---- we don't have to wait until it is perfect (and
   the technology obsolete) before we ship it.

.......