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

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

A number of folks have pointed out that I wrongly said "receiver can
predict", when it should have been "sender can predict".  They are of
course right.  My apologies for the error, which invalidates some of my
comments regarding the interoperability issues of changing the sense of the
IPv6 "mutable" bit.  It seems to me now that making this change is
certainly doable, should we have consensus that this would be a good
thing to do for IPv6 options.

With regards to your observations regarding new IPv6 extension headers:

>1) As you point out, on some systems IPSec may not be upgraded or
>otherwise stay in sync with new extension headers. I'm not sure I
>agree with this (or rather, I'm not sure we should explicitely
>encourage this), but even if it is so, it leads to the
>interoperability issue described above. The receiver is left guessing
>which extension headers are actually covered. This would seem to be a
>bug.

There is the added complications that the IPSEC processing may be
happening on a security gateway which is separate from the end-system
which is actually generating the newly defined extension header.  The
security gateway may be a turnkey "black box" provided by some VPN
vendor.  So we can't necessarily guarantee IPSEC implementation will be
upgraded.

>2) One might argue that there will be no need to define future
>extension headers that a) precede the IPSec header, b) are mutable,
>but in a predictable way, c) zeroing out (i.e., not including) the
>extension header in the AH check results in undesired behavior and d)
>the header needs to be defined as extension headers as opposed to a
>destination option (which wouldn't have this problem thanks to an
>explicit bit). However, we should recognize that this approach
>potentially limits future flexibility, something that should not be
>done without careful thought.

I see three primary choices: (1) is to declare that any new extension
headers that preceed the IPsec MUST not be included in the ICV (i.e.,
are zero'ed out), regardless of their mutability status.  (2) would be
to always included new extension headers in the ICV --- with the net
result that new extension header would not be allowed to mutate.
Finally (3) we could live with the potential interoperability problem
that will occur when we define such a new extension header and it passes
through an IPSEC gateway that doesn't understand the new extension.

There are two subcases in this last case, (a) the IPSEC gateway simply
refuses to process the packet with the unknown extension header, or (b)
the IPSEC gateway assumes a default behaviour of zero'ing out the
unknown extension header when calculating the ICV.  (2)(b) is the
current draft wording, and has the property of working if the default
behaviour is correct.  If the default behaviour is not correct, and the
sending IPSEC gateway generates the ICV with the extension header, it
will cause the receiver to reject the packet because of a bad ICV value.
The worst case behaviour happens if there are two security gateways
involved, and both IPSEC gateways don't understand the extension header,
and so zero it when the calculate the ICV.  Now the ICV matches, and the
packet goes through, but the extension is not protected.  If the sending
and receiving hosts understand the extension, they might assume that the
extension has been integrity protected, when in fact it has not been.
If the extension has security implications, this would be bad.

None of these choices are particularly palatable.  Just so I understand
the IPV6 issues a little better --- how likely is it that we will want
to invent new extension headers?  And how likely is it that the ordering
will matter and that the new extension header will have to be before the
AH header, and could not be placed after the AH header?

						- Ted
References: