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

RE: transform tunnel/transport attributes


Does something as 'simple' as this work then:

"For ANDed propotals, the 'mode' MUST be the same, and the protocol headers
applied MUST be applied adjacent to each other.  If multiple proposals are
required to protect a packet, and they are to be applied in different modes,
this is achieved by using multiple Phase-2 negotiations".

Steve.



-----Original Message-----
From: Michael C. Richardson [mailto:mcr@sandelman.ottawa.on.ca]
Sent: Saturday, November 07, 1998 11:51 PM
To: Daniel Harkins
Cc: Scott G. Kelly
Subject: Re: transform tunnel/transport attributes 


-----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-----
Follow-Ups: