Subject: Re: IPsec issue #46 -- No need for nested SAs or SA bundles

From: "Angelos D. Keromytis" <[email-masked]>
Date: Fri, 29 Aug 2003 19:39:59 -0400

Just to start some discussion on this issue: wouldn't this break (or make it
very difficult) for IPSP to deal with intermediate gateways etc. ? The 
advantage
of the current model with respect to nested IPsec processing is that it allows
an implementation to inject a new SPD entry (and associated SAs), and not 
having
to link that SA to a bundle but instead deal with the SPD.
-Angelos

In message <p05200f16bb72791c0917@[128.89.89.115]>, Karen Seo writes:
>Folks,
>
>Here's a description and proposed approach for:
>
>IPsec Issue #:	46
>
>Title:		No need for nested SAs or SA bundles
>
>Description:	There is no mandate to support nested SAs or SA bundles.
>		It would be easy to include support for the simple
>		AH+ESP combination that IKEv1 was able to negotiate, and
>		that 2401 mandates, if that combination is still viewed
>		as needed. However, IKEv1 was not able to negotiate any
>		other nested protocol combinations and IKEv2 does not
>		support negotiation of SA bundles.
>
>Proposed approach:
>
>      1. There will be no support for nesting or SA bundles except via
>	iteration through IPsec processing.  Add text to the discussion
>	of differences between 2401 and 2401bis, along the lines of:
>
>	"The requirement to support nesting of SAs and the concept of
>	SA bundles has been removed. An SPD entry specifies application
>	or removal of only one IPsec header. An implementation MAY
>	choose to offer SA nesting via appropriate configuration of
>	SPDs and forwarding tables. After the packet has passed through
>	IPsec processing, it can be redirected through the IPsec module
>	again via local, ipsec-virtual-interfaces and use of the [still
>	under discussion] forwarding lookup function, to cause more
>	than one layer of IPsec headers to be applied or removed. Note
>	that to accomplish this, multiple entries would have to be
>	created, in distinct SPDs, each specifying a layer of IPsec
>	processing to be applied.  There is no IKE support for
>	negotiating nested SAs, which implies that manual configuration
>	or use of additional policy management protocols would be
>	required to coordinate processing at peer IPsec implementations."
>
>Thank you,
>Karen

---

From: Michael Richardson <[email-masked]>
Date: Fri, 29 Aug 2003 23:15:49 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Angelos" == Angelos D Keromytis <[email-masked]> writes:
    Angelos> Just to start some discussion on this issue: wouldn't this break
    Angelos> (or make it very difficult) for IPSP to deal with intermediate
    Angelos> gateways etc. ? The advantage of the current model with respect

  It isn't clear to me if it does or doesn't.

  Just because IKEv2 can't negotiate bundles, doesn't mean that I can't
negotiate multiple things to do a 5-tuple with different end
points. FreeS/WAN is currently dealing with the question of how much
information we can derive from the policy about the ordering of this
nesting, vs how much we need to be told about. 

  It also isn't clear to me why it is any business of 2401bis to say anything
about this. Permitting looping in SA processing is not a good idea - the
policy daemon should do the looping and tell the kernel what to do. But
again, WHY IS THIS THE DOMAIN OF THE IETF? 

  As expressed, it appears that 2401bis is addressing the "kernel" issues,
not the architecture. It is turning the problem into a design issue, 
rather than a functional requirements issue. 

  There is a functional requirement for the *SYSTEM* to deal with multiple
operations on a 5-tuple. It is not the place for the IETF to tell me where
to put that functionality.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [