[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: transform tunnel/transport attributes
- To: Daniel Harkins <dharkins@cisco.com>
- Subject: Re: transform tunnel/transport attributes
- From: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>
- Date: Sat, 07 Nov 1998 18:51:08 -0500
- CC: "Scott G. Kelly" <skelly@redcreek.com>
- In-Reply-To: Your message of "Sat, 07 Nov 1998 11:06:30 PST." <199811071906.LAA11898@chip.cisco.com>
- Prev-Resent: Sun, 08 Nov 1998 12:27:11 -0500
- Prev-Resent: "ipsec@tis.com "
- Sender: owner-ipsec@ex.tis.com
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "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]
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?
:!mcr!: | Network and security consulting/contract programming
Michael Richardson | Firewalls, TCP/IP and Unix administration
Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
Corporate: http://www.sandelman.ottawa.on.ca/SSW/
ON HUMILITY: To err is human, to moo bovine.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQB1AwUBNkTc69iXVu0RiA21AQE2igL+PDkv2cQilgz6r0fQ4kmfG8jZ9eL1Et2T
IsSm5HSIwfA1NMIalI6ks7QVZBtY/T9SspFwqMB8gzSckxIYBtDgG12dhn1NJdlq
UlJi/gPIQP/3epVNptJ5bpfgQ+3y09gw
=fEX/
-----END PGP SIGNATURE-----