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

RE: Specification of tunnel/transport attribute in IKEv2



Hi Charlie,

Thanks for returning this thread back to the original topic.


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

What we discovered at the bakeoffs is that nature seeks out diversity. If
you don't specify stuff like this explicitly in the RFCs then people will
somehow manage to not interoperate. There is a trap that programmers often
fall into, which is to try to find a meaning in any arbitrary sequence of
bits. For IKEv1, most people had no desire to do anything other than
[AH][ESP][IPCOMP]. Since accepting the transforms in any order and
interpreting them as [AH][ESP] appears to give you the greatest probability
of interoperating (you weren't going to interoperate with someone doing
[ESP][AH] anyway), people implemented it that way.


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

I didn't really understand it either. Apparently, an attacker might try to
surrepticiously change the non-mutable fields of the IP header, but they
won't do it if you're using AH because then the attack would be detected. So
by putting AH inside ESP you can bait the attacker into thinking they can
launch the attack undetected. My gut reaction is "fine, then let them,"
although I'm sure Markku is going to reply anyway.

You wouldn't be deleting functionality. You are adding functionality, since
Markku's IKEv1 doesn't interoperate with others in this regard. (There was a
straw poll at a bakeoff, the result being that ESP+AH should be interpreted
as [AH][ESP], and people have been implementing it that way ever since.) I
don't mind if the spec allows arbitrary combinations, as long as anything
other than the standard ordering is relegated to a MAY. Our policy
definition language does not allow the user to control the order of the
transforms, and I hope to not change this.


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

Sadly, people do want to do this. Authentication was added to ESP more than
3 years ago, and I still get frequent questions from people that either a)
don't realize that ESP can provide authentication, b) believe that
authenticating the header is important [even in tunnel mode], or c) want
that "extra level of security" that comes from doing authentication in both
ESP and AH. I don't know why, but it just seems like we're just not getting
the message out.

You've even got it in the draft: (page 32)

   For example,
   an Initiator might want to propose using (AH w/MD5 and ESP w/3DES) OR
   (ESP w/MD5 and 3DES).


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

I was merely wondering, since this is a departure from IKEv1 (encapsulation
modes are defined on page 13 of the DOI). The obvious problem is NATs. With
the existing NAT-T drafts, we use the encapsulation mode attribute to
specify either UDP+transport or UDP+tunnel. Also, there is a special OA
(original address) payload that is only sent for UDP+transport mode and
which allows the effects of the NAT to be reversed.

Also, I wonder what the effects of the tunnel/transport ambiguity might be
for hardware (or even optimized software) implementations of IPsec. The SA
or SA bundle "object" may be a streamlined code path that is tuned to the
specific attributes of the SA. We have some deployed products that would not
take kindly to transport and tunnel being mixed on the same SA. This could
obviously be changed, but I wanted to point out that this update to IKE is
also going to have an affect on people's packet-level IPsec implementations.


> 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).

Okay, it took me awhile to find the text you are referring to, but I assume
you mean:

          Diffie-Hellman Group     5   (IKE and optional in AH and ESP)

I think your interpretation is that same one that I would make, but others
may disagree. Some people take RFC wording very literally (the word "unique"
comes to mind). Remember that this was an interop problem with IKEv1, so
obviously not everyone interpreted the original RFCs the same way.

Andrew
-------------------------------------------
There are no rules, only regulations. Luckily,
history has shown that with time, hard work,
and lots of love, anyone can be a technocrat.



> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of
> Charlie_Kaufman@notesdev.ibm.com
> Sent: Saturday, June 01, 2002 10:55 PM
> To: 'ipsec list'
> Subject: Re: Specification of tunnel/transport attribute in IKEv2
>
>
>
>
>
>
> 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
>