[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ESP and AH used in tunnel mode by a Security Gateway
Yea, I completely forgot about that. Good point. Looking at this
from the SA bundle point-of-view makes it even more compelling.
Dan.
On Fri, 24 Jul 1998 11:12:40 EDT you wrote
>
> Why has no one referred to "protection suites" as defined in the DOI
> document and Oakley or "SA bundles" as defined in the architecture
> document?
>
> Use of these concepts would simplify these discussions, since it would
> reduce the ambiguity of application. For example, a gateway could apply
> an IPCOMP-ESP-AH bundle as
>
> IP [AH ESP PCP] IP DATA
>
> where a host could do either
>
> IP [AH ESP PCP] IP DATA (tunnel mode)
> or IP [AH ESP PCP] DATA (transport mode)
>
> In this case, there's no argument about whether AH and ESP are tunnel or
> transport; they are part of a bundle that is tunnel or transport.
>
> Further, the rule that gateways may do only tunnel mode means that there
> can be no confusion with security headers. What I mean is that all
> security headers that are adjacent in packets must belong to the same
> bundle. This is because the rule that gateways only use tunnel mode
> means that there will always be an IP header between the layers of SA
> bundles.
>
> An example:
>
> H1 --- SG1 ----- H2
> <-- AH --> (tunnel mode)
> <---- ESP ------> (either mode)
>
> In this case packets between SG1 and H2 look like
>
> IP AH IP ESP DATA (H1 to H2 transport mode)
> or IP AH IP ESP IP DATA (H1 to H2 tunnel mode)
>
> Now, all that is needed are explicit expiration rules to apply to
> bundles. Implicitly, the entire bundle expires when any one of the SAs
> in the bundle expires.
>
> Am I missing something here???
>
> ---
> Tim Jenkins TimeStep Corporation
> tjenkins@timestep.com http://www.timestep.com
> (613) 599-3610 x4304 Fax: (613) 599-3617
>
>
> -----Original Message-----
> From: Daniel Harkins [mailto:dharkins@cisco.com]
> Sent: Thursday, July 23, 1998 4:16 PM
> To: Ben Rogers
> Cc: Stephen Waters; ipsec@tis.com
> Subject: Re: ESP and AH used in tunnel mode by a Security Gateway
>
>
> I really don't want to open this can-of-worms but it has some
> interoperability implications.
>
> On 23 Jul 1998 13:58:28 EDT you wrote
> > Stephen Waters <Stephen.Waters@digital.com> writes:
> >
> > > I seem to remember asking this question before, but....
> > >
> > > Although not covered in the IPSEC architecture, is there any
> > > restriction on a Security Gateway
> > > applying both ESP and AH in tunnel mode?
> >
> > You could do this. However, you'll want to be a little more precise
> > with your terminology.
> >
> > ESP and AH in tunnel mode:
> >
> > IP AH IP ESP IP DATA
> >
> > You probably intended to apply ESP in tunnel mode and AH in transport
> > mode on top of that:
> >
> > IP AH ESP IP DATA
> >
> > Note that in an ISAKMP negotiation, you would negotiate a single
> > proposal containing an ESP transform with the tunnel mode attribute
> > and an AH transform with the transport mode attribute. (This is
> > something we agreed to some time ago but which might not have made it
> > into the docs yet.)
>
> I don't remember agreeing to that. In fact, the only mention of this
> I remember came up during the IPCOMP and IPSEC thread. On May 28, in
> <199805282040.NAA01397@orna.mentat.com> Marc Hasson wrote:
>
> >
> > I guess you could say that ESP is in transport mode, but what
> about the
> > case where both AH and ESP are applied to the same packet:
> >
> > [IP2][AH][ESP][IP1][data]
> >
> > Is AH in transport mode?
>
> Good point. I can hear people arguing it both ways and am sorry I
> raised that side tidbit. Whats more important is that we all
> understand
> how to process the above, which I think is pretty clear in the
> specs.
>
> Yes, I feel we can all process this but it's now apparent that we can't
> all
> negotiate it.
>
> The next header in AH is not IPinIP so I understand the point being
> made.
> But these two SAs are the result of a single rule. If PFS is also part
> of
> the rule it applies to both and the ID payloads passed in the QM
> exchange
> also apply to both. They are a single unit.
>
> If we have:
>
> H1 ------ SG1 ---------- SG2 ------- H2
> |<-- secured -->| |
> |__ H3
>
> the rules I've applied to SG1 (vice versa for SG2) is:
>
> For traffic from H1 to H2, apply AH and ESP and peer with SG2
>
> If AH is in transport mode the rule becomes:
>
> For traffic from H1 to H2, apply ESP and peer with SG2
> For ESP traffic from SG1 to SG2 apply AH and peer with SG2
>
> But if I want my packets from H1 to H2 to look like:
>
> IP[SG1-SG2] AH ESP IP[H1-H2]
>
> and from H1 to H3 to look like:
>
> IP[SG1-SG2] ESP [H1-H2]
>
> That'll break down because my packets ESP packets will match the rule
> being applied for H1-H2 traffic and it'll have AH applied. There'd be
> some
> ugly code to prevent this from happening. SG2 would also have some ugly
> spagetti code to make sure that, at decaps, AH is only applied to an ESP
>
> packet that was applied to H1-H2 traffic. That would be necessary since
> the
> AH+ESP negotiation specified H1-H2 and to use AH on an ESP packet that
> was
> H1-H3 would be in violation of that.
>
> Transport mode can't be applied by a SG to a packet in transit-- in
> the
> example a packet from H1 to H2. But if AH was treated as being in
> transport
> mode in IP AH ESP IP DATA then that's exactly what you'd be saying in
> your
> Quick Mode message. So you'd have to do two separate negotiations, one
> for
> ESP on IP between H1 and H2 and another for AH on ESP packets between
> SG1
> and SG2, and that would have problems too because you would be unable to
>
> specify that traffic from H1 to H3 *not* have AH applied.
>
> I think it's better to treat AH as being in tunnel mode in this case.
> It precludes lots of ugly, hard-to-maintain code, it makes UI much
> simpler,
> and it allows for a wider array of rules to be applied to various sorts
> of
> traffic.
>
> I'm not suggesting doing IP AH IP ESP IP DATA. I'm just suggesting
> that
> when we want to do IP AH ESP IP DATA that we negotiate it using the same
> encapsulation attribute-- tunnel mode-- in both the AH and ESP
> proposals.
> This would also apply to IP ESP PCP IP DATA or IP AH ESP PCP IP DATA
> too.
>
> Dan.
>
> ------ =_NextPart_001_01BDB715.801385E0
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3DUS-ASCII">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 5.5.1960.3">
> <TITLE>RE: ESP and AH used in tunnel mode by a Security Gateway =
> </TITLE>
> </HEAD>
> <BODY>
>
> <P><FONT SIZE=3D2>Why has no one referred to "protection =
> suites" as defined in the DOI document and Oakley or "SA =
> bundles" as defined in the architecture document?</FONT></P>
>
> <P><FONT SIZE=3D2>Use of these concepts would simplify these =
> discussions, since it would reduce the ambiguity of application. For =
> example, a gateway could apply an IPCOMP-ESP-AH bundle as</FONT></P>
>
> <P> <FONT SIZE=3D2>IP [AH ESP =
> PCP] IP DATA</FONT>
> </P>
>
> <P><FONT SIZE=3D2>where a host could do either</FONT>
> </P>
>
> <P> <FONT SIZE=3D2>IP [AH ESP =
> PCP] IP DATA (tunnel =
> mode)</FONT></P>
>
> <P><FONT SIZE=3D2> or IP [AH ESP PCP] =
> DATA (transport mode)</FONT>
> </P>
>
> <P><FONT SIZE=3D2>In this case, there's no argument about whether AH =
> and ESP are tunnel or transport; they are part of a bundle that is =
> tunnel or transport.</FONT></P>
>
> <P><FONT SIZE=3D2>Further, the rule that gateways may do only tunnel =
> mode means that there can be no confusion with security headers. What I =
> mean is that all security headers that are adjacent in packets must =
> belong to the same bundle. This is because the rule that gateways only =
> use tunnel mode means that there will always be an IP header between =
> the layers of SA bundles.</FONT></P>
>
> <P><FONT SIZE=3D2>An example:</FONT>
> </P>
>
> <P><FONT SIZE=3D2> H1 --- SG1 ----- H2</FONT>
> <BR><FONT =
> SIZE=3D2> <-- =
> AH --> (tunnel mode)</FONT>
> <BR><FONT SIZE=3D2> <---- ESP ------> (either =
> mode)</FONT>
> </P>
>
> <P><FONT SIZE=3D2>In this case packets between SG1 and H2 look =
> like</FONT>
> </P>
>
> <P> <FONT SIZE=3D2>IP AH IP =
> ESP DATA (H1 to H2 transport =
> mode)</FONT>
> <BR><FONT SIZE=3D2> or IP AH IP ESP IP DATA (H1 to H2 =
> tunnel mode)</FONT>
> </P>
>
> <P><FONT SIZE=3D2>Now, all that is needed are explicit expiration rules =
> to apply to bundles. Implicitly, the entire bundle expires when any one =
> of the SAs in the bundle expires.</FONT></P>
>
> <P><FONT SIZE=3D2>Am I missing something here???</FONT>
> </P>
>
> <P><FONT SIZE=3D2>---</FONT>
> <BR><FONT SIZE=3D2>Tim =
> Jenkins  =
> ; =
> TimeStep Corporation</FONT>
> <BR><FONT =
> SIZE=3D2>tjenkins@timestep.com =
> <A HREF=3D"http://www.timestep.com" =
> TARGET=3D"_blank">http://www.timestep.com</A></FONT>
> <BR><FONT SIZE=3D2>(613) 599-3610 =
> x4304 &=
> nbsp; Fax: (613) 599-3617</FONT>
> </P>
> <BR>
>
> <P><FONT SIZE=3D2>-----Original Message-----</FONT>
> <BR><FONT SIZE=3D2>From: Daniel Harkins [<A =
> HREF=3D"mailto:dharkins@cisco.com" =
> TARGET=3D"_blank">mailto:dharkins@cisco.com</A>]</FONT>
> <BR><FONT SIZE=3D2>Sent: Thursday, July 23, 1998 4:16 PM</FONT>
> <BR><FONT SIZE=3D2>To: Ben Rogers</FONT>
> <BR><FONT SIZE=3D2>Cc: Stephen Waters; ipsec@tis.com</FONT>
> <BR><FONT SIZE=3D2>Subject: Re: ESP and AH used in tunnel mode by a =
> Security Gateway </FONT>
> </P>
> <BR>
>
> <P><FONT SIZE=3D2> I really don't want to open this can-of-worms =
> but it has some</FONT>
> <BR><FONT SIZE=3D2>interoperability implications.</FONT>
> </P>
>
> <P><FONT SIZE=3D2>On 23 Jul 1998 13:58:28 EDT you wrote</FONT>
> <BR><FONT SIZE=3D2>> Stephen Waters =
> <Stephen.Waters@digital.com> writes:</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> > I seem to remember =
> asking this question before, but....</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > Although not covered in =
> the IPSEC architecture, is there any</FONT>
> <BR><FONT SIZE=3D2>> > restriction on a Security Gateway</FONT>
> <BR><FONT SIZE=3D2>> > applying both ESP and =
> AH in tunnel mode?</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> You could do this. However, you'll want =
> to be a little more precise</FONT>
> <BR><FONT SIZE=3D2>> with your terminology.</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> ESP and AH in tunnel mode:</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> IP AH IP ESP IP DATA</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> You probably intended to apply ESP in tunnel =
> mode and AH in transport</FONT>
> <BR><FONT SIZE=3D2>> mode on top of that:</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> IP AH ESP IP DATA</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> Note that in an ISAKMP negotiation, you would =
> negotiate a single</FONT>
> <BR><FONT SIZE=3D2>> proposal containing an ESP transform with the =
> tunnel mode attribute</FONT>
> <BR><FONT SIZE=3D2>> and an AH transform with the transport mode =
> attribute. (This is</FONT>
> <BR><FONT SIZE=3D2>> something we agreed to some time ago but which =
> might not have made it</FONT>
> <BR><FONT SIZE=3D2>> into the docs yet.)</FONT>
> </P>
>
> <P><FONT SIZE=3D2> I don't remember agreeing to that. In fact, =
> the only mention of this</FONT>
> <BR><FONT SIZE=3D2>I remember came up during the IPCOMP and IPSEC =
> thread. On May 28, in </FONT>
> <BR><FONT SIZE=3D2><199805282040.NAA01397@orna.mentat.com> Marc =
> Hasson wrote:</FONT>
> </P>
>
> <P><FONT SIZE=3D2> > </FONT>
> <BR><FONT SIZE=3D2> > I guess you could say =
> that ESP is in transport mode, but what about the</FONT>
> <BR><FONT SIZE=3D2> > case where both AH and =
> ESP are applied to the same packet:</FONT>
> <BR><FONT SIZE=3D2> > </FONT>
> <BR><FONT SIZE=3D2> =
> > [IP2][AH][ESP][IP1][data]</FONT>
> <BR><FONT SIZE=3D2> > </FONT>
> <BR><FONT SIZE=3D2> > Is AH in transport =
> mode? </FONT>
> <BR><FONT SIZE=3D2> </FONT>
> <BR><FONT SIZE=3D2> Good point. I can =
> hear people arguing it both ways and am sorry I</FONT>
> <BR><FONT SIZE=3D2> raised that side =
> tidbit. Whats more important is that we all understand</FONT>
> <BR><FONT SIZE=3D2> how to process the above, =
> which I think is pretty clear in the specs.</FONT>
> <BR><FONT SIZE=3D2> </FONT>
> <BR><FONT SIZE=3D2>Yes, I feel we can all process this but it's now =
> apparent that we can't all</FONT>
> <BR><FONT SIZE=3D2>negotiate it. </FONT>
> </P>
>
> <P><FONT SIZE=3D2> The next header in AH is not IPinIP so I =
> understand the point being made.</FONT>
> <BR><FONT SIZE=3D2>But these two SAs are the result of a single rule. =
> If PFS is also part of</FONT>
> <BR><FONT SIZE=3D2>the rule it applies to both and the ID payloads =
> passed in the QM exchange </FONT>
> <BR><FONT SIZE=3D2>also apply to both. They are a single unit. </FONT>
> </P>
>
> <P><FONT SIZE=3D2> If we have:</FONT>
> </P>
>
> <P> <FONT SIZE=3D2>H1 ------ =
> SG1 ---------- SG2 ------- H2</FONT>
> <BR><FONT =
> SIZE=3D2> &nb=
> sp; |<-- secured =
> -->| |</FONT>
> <BR><FONT =
> SIZE=3D2> &nb=
> sp; &nb=
> sp; &nb=
> sp; |__ H3</FONT>
> </P>
>
> <P><FONT SIZE=3D2>the rules I've applied to SG1 (vice versa for SG2) =
> is:</FONT>
> </P>
>
> <P> <FONT SIZE=3D2>For =
> traffic from H1 to H2, apply AH and ESP and peer with SG2</FONT>
> </P>
>
> <P><FONT SIZE=3D2>If AH is in transport mode the rule becomes:</FONT>
> </P>
>
> <P> <FONT SIZE=3D2>For =
> traffic from H1 to H2, apply ESP and peer with SG2</FONT>
> <BR> <FONT SIZE=3D2>For ESP =
> traffic from SG1 to SG2 apply AH and peer with SG2</FONT>
> </P>
>
> <P><FONT SIZE=3D2>But if I want my packets from H1 to H2 to look =
> like:</FONT>
> </P>
>
> <P> <FONT =
> SIZE=3D2>IP[SG1-SG2] AH ESP IP[H1-H2]</FONT>
> </P>
>
> <P><FONT SIZE=3D2>and from H1 to H3 to look like:</FONT>
> </P>
>
> <P> <FONT =
> SIZE=3D2>IP[SG1-SG2] ESP [H1-H2]</FONT>
> </P>
>
> <P><FONT SIZE=3D2>That'll break down because my packets ESP packets =
> will match the rule</FONT>
> <BR><FONT SIZE=3D2>being applied for H1-H2 traffic and it'll have AH =
> applied. There'd be some</FONT>
> <BR><FONT SIZE=3D2>ugly code to prevent this from happening. SG2 would =
> also have some ugly </FONT>
> <BR><FONT SIZE=3D2>spagetti code to make sure that, at decaps, AH is =
> only applied to an ESP </FONT>
> <BR><FONT SIZE=3D2>packet that was applied to H1-H2 traffic. That would =
> be necessary since the </FONT>
> <BR><FONT SIZE=3D2>AH+ESP negotiation specified H1-H2 and to use AH on =
> an ESP packet that was </FONT>
> <BR><FONT SIZE=3D2>H1-H3 would be in violation of that.</FONT>
> </P>
>
> <P><FONT SIZE=3D2> Transport mode can't be applied by a SG to a =
> packet in transit-- in the </FONT>
> <BR><FONT SIZE=3D2>example a packet from H1 to H2. But if AH was =
> treated as being in transport</FONT>
> <BR><FONT SIZE=3D2>mode in IP AH ESP IP DATA then that's exactly what =
> you'd be saying in your</FONT>
> <BR><FONT SIZE=3D2>Quick Mode message. So you'd have to do two separate =
> negotiations, one for</FONT>
> <BR><FONT SIZE=3D2>ESP on IP between H1 and H2 and another for AH on =
> ESP packets between SG1 </FONT>
> <BR><FONT SIZE=3D2>and SG2, and that would have problems too because =
> you would be unable to </FONT>
> <BR><FONT SIZE=3D2>specify that traffic from H1 to H3 *not* have AH =
> applied.</FONT>
> </P>
>
> <P><FONT SIZE=3D2> I think it's better to treat AH as being in =
> tunnel mode in this case.</FONT>
> <BR><FONT SIZE=3D2>It precludes lots of ugly, hard-to-maintain code, it =
> makes UI much simpler,</FONT>
> <BR><FONT SIZE=3D2>and it allows for a wider array of rules to be =
> applied to various sorts of </FONT>
> <BR><FONT SIZE=3D2>traffic.</FONT>
> </P>
>
> <P><FONT SIZE=3D2> I'm not suggesting doing IP AH IP ESP IP DATA. =
> I'm just suggesting that</FONT>
> <BR><FONT SIZE=3D2>when we want to do IP AH ESP IP DATA that we =
> negotiate it using the same</FONT>
> <BR><FONT SIZE=3D2>encapsulation attribute-- tunnel mode-- in both the =
> AH and ESP proposals.</FONT>
> <BR><FONT SIZE=3D2>This would also apply to IP ESP PCP IP DATA or IP AH =
> ESP PCP IP DATA too.</FONT>
> </P>
>
> <P><FONT SIZE=3D2> Dan.</FONT>
> </P>
>
> </BODY>
> </HTML>
> ------ =_NextPart_001_01BDB715.801385E0--
References: