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

transform tunnel/transport attributes



  
  [Reposted with permission]

From: Daniel Harkins <dharkins@cisco.com>
To: "Michael C. Richardson" <mcr@sandelman.ottawa.on.ca>
cc: "Scott G. Kelly" <skelly@redcreek.com>
Subject: transform tunnel/transport attributes
Date: Sat, 07 Nov 1998 11:06:30 -0800

  I think there are 2 different parsings and meanings of the following:

	[ip][ah][esp][whatever]

The way it was discussed back in June was that if you have policy that
says you must do AH&ESP to protect whatever then they're both in tunnel
mode. 

  Your minds can imagine much better than I can ASCII draw so imagine
SGA and SGB as security gateways protecting netA and netB respectively.
On each network is a bunch of other boxes a1...an, and b1...bn.

  So SG1 and SG2 can have policy (lets assume they were configured
identically for simplicity) that says:

	a1 to b1 do ESP(3DES w/no auth) AND AH(HMAC-SHA)
also
	a2 to b2 do ESP(CAST w/no auth) AND AH(HMAC-MD5)

When traffic from a1 to b1 hits SG1 it will send a single Quick Mode with
a1 and b1 as client IDs. This single Quick Mode will specify ESP&AH, both
in tunnel mode since they're protecting transient traffic. When traffic from 
a2 to b2 hits SG1 it will respond with another single Quick Mode that also 
specifies ESP&AH, again both in tunnel mode. 

  But there's another way of thinking about it. My policy could say

	a1 to b1 do ESP(3DES w/any auth including null)
also
	a2 to b2 do ESP(CAST w/any auth including null)
also
	ESP traffic from SG1 to SG2 do AH(HMAC-SHA)

So when traffic from a1 to b1 hits SG1 it will send a single Quick Mode with
a1 and b1 as client IDs. This single Quick Mode will specify ESP in tunnel
mode. Then when the ESP packet tries to go out it will trigger another Quick 
Mode with SG1 and SG2 as client IDs and the protocol field as 50 and specify 
AH in transport mode. Then when traffic from a2 to b2 hits SG1 it will trigger 
yet another Quick Mode for ESP between a2 and b2, in tunnel mode. When that 
ESP packet, protecting a2 and b2, hits the output interface it will just use 
the existing AH SA to protect it.

  In either case the packets flowing between SG1 and SG2 look like this:

	ip ah esp ip <some traffic between netA and netB>

But the two cases are specifying different policy and are negotiated 
differently.

  The encapsulation attribute is not the only thing shared by the offers
in case 1. PFS and lifetime would be shared too. The SAs which were created
as a bundle would die as a bundle and be keyed as a bundle. But in case 2 
the AH SAs could exist even if all the ESP SAs died and went away and the
ESP SAs could have PFS while the AH ones don't or they could have different
groups.

  I really don't want to see case 1 invalidated because the next protocol
field in the AH packet is ESP and not IPinIP and is therefore, *technically*,
transport mode. Although one can argue that since the AH is protecting
the transient traffic and not just all ESP between SG1 and SG2 (as is the
2nd) that it truely is tunnel mode. It's a pointless arguement since each
side is right. Given that there's running code that implements case 1 I
really don't want to open that case up to interpretation again. Maybe we
just need to clarify the two cases.

  Dan.