[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Karen Seo: Thomas Narten -- clarification, etc.]
Ted,
[Sorry for the cross posting, but this is really both an IPSec and
IPv6 issue.]
Let me back up a little and clarify the point that caught my
attention. draft-ietf-ipsec-auth-header-05.txt says:
>>> 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.)
There would seem to be an potential interoperability issue here. If
what the AH actually covers is determined by what the sending IPSec
module understands, how does the receiver obtain that knowledge? The
receiver needs to know which headers are covered in order to validate
the received AH.
First, let us assume that we are talking about an extension header
that precedes AH or ESP. Headers that appear afterwards are considered
data to the AH/ESP, so nothing special needs to be done for them.
If the sender "recognizes" the option, but the receiver does not,
presumably there is no issue. The receiver will not know what to do
with the header and toss the packet. It doesn't really make sense for
a receiver to skip/ignore an extension header it does not
understand. This check will take place before IPSec processing takes
place.
If the sender doesn't "recognize" the option, but the receiver does,
here is where the issue comes up. The receiver needs an unambiguous
way of knowing whether a particular extension header (that precedes
AH) is covered by the AH check.
I was assuming that it wouldn't make sense for a node to be sending
extension headers it *does* understand that the IPSec module *did
not*. I.e., if the extension header is mutable, but its contents are
predictable at the reciever, the sending IPSec module should always be
able to include it in the AH computation.
Couple of perspectives:
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.
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.
3) It's not immediately clear to me how one could signal to the
receiver in a generic way whether or not an extension header is
covered by the AH check. This suggests a couple of approaches:
- require that IPSec and future extension headers be upgraded in sync
on sending/receiving machines, so that the extension header itself
can define the right semantics regarding AH coverage. Note that this
may not be as onerous as first appears, since it only applies to new
extension headers that *precede* AH.
- declare that all extension headers (except the IPv6 headers that
are already defined) - including future ones that have yet to be
defined - should be zeroed and ignored for the purposes of AH. (That
is, take out the text that allows the sender to choose, based on what
it understands)
- leave the text as is, but at least document the interoperability
implications.
- are there other possibilities?
> 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",
I think you mean (thanks Matt): "mutable and sender can not predict"
> then it would be possible to include such options in the Integrity Check
> Value (ICV).
That is what I *thought* the bit was supposed to mean. However, the
current text doesn't say that, so I'm awaiting clarification from the
IPng WG.
> 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.
Agreed. But I think there is already an interoperability issue here.
> 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.
Isn't there a similar issue here in that it may not make sense for the
security gateway to understand how to process the option yet *not*
understand how to do the integrity check on that option?
> 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.
I'd like to hear from the IPng folks regarding the mutable but
predictable issue (but that is a separate issue). I'm also
uncomfortable with leaving the AH text as is without better addressing
the interoperability issue.
Thomas
Follow-Ups:
References: