Re: Specification of tunnel/transport attribute in IKEv2

[Charlie_Kaufman@notesdev.ibm.com]

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?

>
> 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?

> Also, it might be nice to
> mention that the ordering of the protocols within the proposal does not
> affect the order in which they are applied to IPsec packets.
>
> A final issue is where to specify the group number if (god forbid) you
are
> using PFS. I think we decided that it should be specified in both the ESP
> and AH protocols and optionally in IPCOMP. I wish I could find the
> antecedent message (I think it was by Joern), but nothing on this subject
> has been posted in the last few days.

My reading of the current draft is that if the group number differs from
the
group of the phase 1 exchange, then it MUST be specified in both the
ESP and AH proposals and MUST NOT be specified in IPCOMP (since
IPCOMP does not use keying material derived from the D-H exchange).

If people think the spec is unclear or this is the wrong thing to do,
please
propose alternative wording.

      --Charlie