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

[Karen Seo: Thomas Narten -- clarification, etc.]

Hi Thomas,

	I spent quite a bit of time discussing the issue which you
raised (forwarded to me by Jeff) with Karen Seo and Charlie Lynn.  They
believe that IPSEC architecture draft as it currently stands is
consistent with the current IPV6 drafts.  

	As it currently stands, because of how the IPV6 documents are
written, the bit in the option defines whether or not the option
contents is mutable, regardless of whether not the receive can predict
it.  As a result, the IPSEC implementation must zero all IPV6 options
with the mutable bit set, regardless of whether or not the receiver can
predict it.  This was done so that we would be consistent with the
current IPV6 specifications.

	Karen and Charlie point out that if the IPV6 draft were changed
so that the meaning of that bit means "mutable or receiver can predict",
then it would be possible to include such options in the Integrity Check
Value (ICV).  However, I note that if we do this, and later someone
defines a new mutable-but-predictable option, IPSEC implementations
which don't know about the new option won't know how to predict option
value, and thus will not be able to properly calculate the ICV.

	It is therefore simpler to say that all mutable options are not
covered by the ICV, which is the current position of the IPV6 and IPSEC
documents.  The tradeoff then is that existing mutable-but-predictable
options will not be integrity-protected.  If we would like to change
this, we would need to tweak both documents.  However, the introduction
of a new mutable-but-predictable option will cause interoperability
problems with older security gateways, so it's not clear that we will be
able to introduce new mutable-but-predictable options in the future in a
practical fashion anyway.

	Given this, do you have a strong opinion regarding change both
drafts, or leaving them as they currently stand?  My recommendation
would be to leave them as they currently stand, on the grounds of
simplifying the implementations.  

						- Ted


------- Forwarded Message

Date:     Tue, 28 Apr 98 20:36:53 EDT
From: Karen Seo <kseo@BBN.COM>
To: tytso@MIT.EDU
Cc: skent@BBN.COM, clynn@BBN.COM, kseo@BBN.COM
Subject:  Thomas Narten -- clarification, etc.

Hi Ted,

My apologies for not getting back to you yesterday.  Per our
conversation earlier today, here's our interpretation and comments on
Thomas's message.  Thanks again for your hard work and help with these
documents.

Please let us know if you have further questions, 
Karen


>>Date: Fri, 24 Apr 1998 11:02:17 -0400
>>From: Thomas Narten <narten@raleigh.ibm.com>
>>
>>Bob, Steve:
>>
>>In reviewing draft-ietf-ipsec-auth-header-05.txt, I noticed the
>>following wording:
>>
>>>    As a new extension header or IPv4 option is created, it will be
>>>    defined in its own RFC and SHOULD include (in the Security
>>>    Considerations section) directions for how it should be handled when
>>>    calculating the AH ICV.  If the IPsec implementation encounters an
>>>    extension header that it does not recognize, it MUST zero the whole
>>>    header except for the Next Header and Hdr Ext Len fields.  The length
>>>    of the extension header MUST be computed by 8 * Hdr Ext Len value +
>>>    8.  If the IPsec implementation encounters an IPv4 option that it
>>>    does not recognize, it should zero the whole option, using the second
>>>    byte of the option as the length.  (IPv6 options contain a flag
>>>    indicating mutability, which determines appropriate processing for
>>>    such options.)
>>
>>Text regarding processing of unrecognized extension options seems
>>wrong (there are bits in header saying whether field is mutable). Do
>>you agree?

	As background...

	A. There are 3 cases of new IP extension headers and options:
		1. new IPv4 options
		2. new IPv6 extension headers (e.g., Routing (Type 0),
		   Fragmentation, etc.)
		3. new options in existing IPv6 extension headers, i.e.,
		   Hop-by-Hop, and Destination

	B. For case (3), a variable number of options are carried in the
	   extension header with individual option headers which have a
	   bit which indicates mutability/immutability (the Option Data
	   field mentioned later in Thomas's message.)

		* We're not sure what Thomas is saying with regard to
		  "unrecognized extension options".  The bit for
		  mutability/immutability is in the individual Option
		  Header(s) not the Extension Header.  Perhaps he's
		  confusing Options with Extension Headers.

	C. An extension header has its own IP protocol number (e.g., AH
	   = 51, ESP = 50) and fields like Next Header, etc.  Although
	   most folks think of them as strictly an IPv6 concept, they
	   can in principle be used with IPv4 or IPv6.

	The first sentence is addressing cases 1 and 2 -- we didn't
	specify the "new extension header" as being "IPv6" because of
	point C above.  The parenthetical statement at the end is
	addressing case 3.  There isn't anything wrong with the text.
	We could add various clarifications if it would help.

>>>>Also, in looking at the current IPv6 base document, it says on this
>>>>point:
>>>>
>>>    The third-highest-order bit of the Option Type specifies whether or
>>>    not the Option Data of that option can change en-route to the
>>>    packet's final destination.  When an Authentication header is present
>>>    in the packet, for any option whose data may change en-route, its
>>>    entire Option Data field must be treated as zero-valued octets when
>>>    computing or verifying the packet's authenticating value.
>>>
>>>       0 - Option Data does not change en-route
>>>
>>>       1 - Option Data may change en-route
>>>
>>>    The three high-order bits described above are to be treated as part
>>>    of the Option Type, not independent of the Option Type.  That is, a
>>>    particular option is identified by a full 8-bit Option Type, not just
>>>    the low-order 5 bits of an Option Type.
>>
>>Is the above text correct? In particular, the text says "mutable"
>>rather than "has predictable value at receiver".
>>
>>Do either or both of these drafts need tweaking?
	
	Thomas is correct in pointing out that there are really
	3 cases:
		1. Immutable -- Option Data does not change en-route
		2. Mutable and predictable -- Option Data changes
		   en-route; sender can predict its value at the
		   receiver.
		3. Mutable and unpredictable -- Option Data changes
		   en-route; sender cannot predict its value at the
		   receiver.

	At present, if the Option Data is "mutable", there is no way to
	tell whether the data is predictable or unpredictable.  Hence
	the IPsec AH spec says that if the data is "mutable", the option
	data must be zero'd.

	If the IPv6 text above is changed to something like the following:

		0 - Option Data does not change en-route or changes
		    such that the sender can predict the value at
		    the receiver
		1 - Option Data may change en-route 

	then case (2) is covered.  And one would not need to change the
	IPsec AH text, but could highlight this if one wanted to by
	changing the paragraph in IPsec AH quoted by Thomas from:

		(IPv6 options contain a flag indicating mutability,
		which determines appropriate processing for such
		options.)
	to:
		(IPv6 options contain a flag indicating "immutable or
		mutable-predictable" vs "mutable-unpredictable", which
		determines appropriate processing for such options.)

	By the way, following up on your/Charlie's conversation re: what
	happens if sender understands a new extension header but the
	receiver does not recognize it.... Charlie says that this may
	not be a big problem because it will only apply if the new
	extension header is placed in front of the AH header.  If it
	comes after the AH header, it will have been included verbatim
	in the ICV and not processed prior to the AH header being
	processed.






------- End Forwarded Message
Follow-Ups: