[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
No Subject
>From dharkins@cisco.com Sat Nov 7 21: 42:49 1998
Return-Path: <dharkins@cisco.com>
Received: from chip.cisco.com (chip.cisco.com [171.69.63.39])
by lox.sandelman.ottawa.on.ca (8.8.7/8.8.8) with ESMTP id VAA29139
for <mcr@sandelman.ottawa.on.ca>; Sat, 7 Nov 1998 21:42:47 -0500 (EST)
Received: from localhost (dharkins@localhost) by chip.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id SAA16982; Sat, 7 Nov 1998 18:42:26 -0800 (PST)
Message-Id: <199811080242.SAA16982@chip.cisco.com>
To: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>
cc: "Scott G. Kelly" <skelly@redcreek.com>
Subject: Re: transform tunnel/transport attributes
In-reply-to: Your message of "Sat, 07 Nov 1998 18:51:08 EST."
<199811072351.SAA13986@istari.sandelman.ottawa.on.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <16980.910492946.1@cisco.com>
Date: Sat, 07 Nov 1998 18:42:26 -0800
From: Daniel Harkins <dharkins@cisco.com>
X-Filtered-By: NoCeM-E v0.6 (http://www.novia.net/~doumakes)
Resent-To: ipsec@tis.com
Resent-Date: Sun, 08 Nov 1998 12:28:14 -0500
Resent-From: "Michael C. Richardson" <mcr@istari.sandelman.ottawa.on.ca>
On Sat, 07 Nov 1998 18:51:08 EST you wrote
>
> >>>>> "Daniel" == Daniel Harkins <dharkins@cisco.com> writes:
> Daniel> So when traffic from a1 to b1 hits SG1 it will send a single
> Daniel> Quick Mode with a1 and b1 as client IDs. This single Quick Mode
> Daniel> will specify ESP in tunnel mode. Then when the ESP packet tries
> Daniel> to go out it will trigger another Quick Mode with SG1 and SG2 as
> Daniel> client IDs and the protocol field as 50 and specify AH in
> Daniel> transport mode. Then when traffic from a2 to b2 hits SG1 it will
> Daniel> trigger yet another Quick Mode for ESP between a2 and b2, in
> Daniel> tunnel mode. When that ESP packet, protecting a2 and b2, hits the
> Daniel> output interface it will just use the existing AH SA to protect
> Daniel> it.
>
> Daniel> But the two cases are specifying different policy and are
> Daniel> negotiated differently.
>
> I think that this is significant, and I hadn't realized it.
> The two policies *are* different because one creates two AH SPIs and the
> other produces one. While that may not be that exciting for this case, if you
> swap the AH and ESP, then what you have is per-flow authentication with
> a single better resistance to traffic analysis by merging flows.
> [of course, the really paranoid (and rich), do per-flow ESP w/auth, merging
> into a single ESP flow]
I think you just made a good case for doing IPSec transport followed by
IPSec tunnel. I hadn't thought of that and was only bringing this up to
show that that case is different that the other one.
But regardles of the utility the processing is different. If the ESP&AH
are a bundle they are both operated in a single go-round through your SAPD
check and process. If they're separate then I think a fully-formed IP
packet has to be reconstructed after the AH transport mode processing
and then that packet, which is now an authenticated ESP packet between
SG1 and SG2, is reinserted back into the flow path for another SAPD check
and then separate processing to decapsulate the inner IP datagram. To me
these are two different things and not just two different ways of expressing
the same thing.
> Daniel> I really don't want to see case 1 invalidated because the next
> Daniel> protocol field in the AH packet is ESP and not IPinIP and is
> Daniel> therefore, *technically*, transport mode. Although one can argue
> Daniel> that since the AH is protecting the transient traffic and not
> Daniel> just all ESP between SG1 and SG2 (as is the 2nd) that it truely
> Daniel> is tunnel mode. It's a pointless arguement since each side is
> Daniel> right. Given that there's running code that implements case 1 I
> Daniel> really don't want to open that case up to interpretation
> Daniel> again. Maybe we just need to clarify the two cases.
>
> I think that you just did. Now, how can this be clearly and cleanly
> described in IKE exchanges? I think we need to add IKE details to this. What
> would you expect/send for each case?
Did what? Invalidate case 1 or open it up to re-interpretation? You just
gave a good example of why someone would want to do case 2. I still think
case 1 has merit.
In any event, this is what an IKE offer for case 1 would look like in
my hypothetical network (IDxx=addr/protocol/port):
SA, [proposal 1: ESP(3DES, no auth)] [proposal 1: AH(HMAC-SHA)],
IDci=a1/0/0, IDcr=b1/0/0
then
SA, [proposal 1: ESP(CAST, no auth)] [proposal 1: AH(HMAC-MD5)],
IDci=a2/0/0, IDcr=b2/0/0
So packets in this case would be:
[IP, SG1 to SG2] [AH:HMAC-SHA] [ESP:3DES, noauth] [IP, a1 to b1]
and
[IP, SG1 to SG2] [AH:HMAC-MD5] [ESP:CAST, noauth] [IP, a2 to b2]
Whereas in case 2 it's:
SA, [proposal 1: ESP(3DES, whatever auth)], IDci=a1/0/0, IDcr=b1/0/0
then
SA, [proposal 1: ESP(CAST, whatever auth)], IDci=a2/0/0, IDcr=b2/0/0
then
SA, [proposal 1: AH(HMAC-SHA)], IDci=SG1/50/0, IDcr=SG2/50/0
So packets in this case would be:
[IP, SG1 to SG2] [AH:HMAC-SHA] [ESP:3DES, whateverauth] [IP, a1 to b1]
and
[IP, SG1 to SG2] [AH:HMAC-SHA] [ESP:CAST, whateverauth] [IP, a2 to b2]
The same AH SA is used for all ESP traffic between SG1 and SG2 in this case.
The packets construction looks identical but they're constructed and
processed differently. For instance additional policy in case 1 could
specify ESP w/HMAC-SHA for traffic between a3 and b3. Then traffic between
a1 and b1, and a2 and b2, would be AH&ESP protected while that from a3 to b3
would just be ESP protected. But if this additional rule is added in case 2
the traffic from a3 to b3 is ESP protected but that packet is further
protected by AH.
Does this make sense?
Dan.