Re: Specification of tunnel/transport attribute in IKEv2

[Stephen Kent <kent@bbn.com>]

Charlie,

>Returning to the original posting under this subject line, Andrew Krywaniuk
>asked:
>
>> I remember reading a posting on the list recently about the confusion
>> surrounding the specification of tunnel mode with SA bundles (i.e. if you
>> are doing ESP+AH, should you specify tunnel mode for one and transport
>for
>> the other or tunnel for both). At the bakeoffs, we decided that you
>should
>> put tunnel mode in both protocols. Also, we decided that the ordering of
>the
>> protocols in the proposal shouldn't matter, since the only ordering that
>> makes sense is [AH][ESP][IPCOMP].
>
>Seems like this should be pinned down. My inclination is to say that the
>order in the proposal *does* matter, and therefore if the above is the only
>order that makes sense then that is the only order allowed in the proposal.
>Markku Savela claimed there was a legitimate use for a different
>composition. I'll confess I didn't understand the rationale, but I'm
>reluctant
>to delete functionality if it's implemented and doesn't get in anyone's
>way.
>
>Would people accept making it explicit that the order in the proposal
>MUST match the order of headers in the resulting packets with mention
>that implementations of combinations SHOULD use the order
>[AH][ESP][IPCOMP]?
>
>Currently, no composition of AH and ESP is mandatory to implement, and
>I would expect that it would be unusual for anyone to support it in a
>single
>bundle. (They might exist in a single packet when tunnels are nested, but
>such would not be an issue for IKE). Is there an expectation that people
>are actually going to do this?

2401 does mandate support in transport mode for [IP1][AH][ESP] but says to not do [IP1][ESP][AH].  I suspect that's why folks thought the order didn't matter.  I agree, though, that we should state that ordering does matter. On the other hand, I assume that we will depricate the use of AH in general and we can kill of that combination as a MUST.


>>
>> I figured we should make sure that these ambiguities are cleared up in
>the
>> Son-of-IKE candidates. However, in perusing through the IKEv2 draft, I
>can
>> find no mention of tunnel mode or transport mode at all. Are the authors
>> assuming that one of the modes is going to be eliminated before we
>> standardize SOI, or is this just an oversight?
>
>It was not an oversight, though it may have been a mistake. I assumed
>that tunnel vs transport mode did not need to be negotiated nor be an
>attribute of the SA, but rather that every SA would be capable of
>carrying both transport mode and tunnel mode packets. In the extreme,
>a single SA might carry both types where tunnel mode is used when the
>inner IP addresses don't match the outer IP addresses. I can see how
>this might cause confusion through NATs, but it's not clear how adding
>tunnel vs. transport mode to the negotiation helps in that case.
>
>Could someone give an example of when it's not "obvious" what mode
>should be used and how the endnodes can manage to negotiate the
>right thing in that case?

There are different opinions here. I believe that one should negotiate the mode and the other end should enforce it when parsing a packet. Dan McDonald (Sun) believe that it makes no difference.


Steve