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

"Mohan Parthasarathy" <mohanp@tahoenetworks.com> Thu, 04 September 2003 23:29 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01534 for <ipsec-archive@lists.ietf.org>; Thu, 4 Sep 2003 19:29:27 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA06648 Thu, 4 Sep 2003 08:23:17 -0400 (EDT)
x-mimeole: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: IPsec issue #46 -- No need for nested SAs or SA bundles
Date: Wed, 03 Sep 2003 14:30:42 -0700
Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E0134A4C4@TNEXVS02.tahoenetworks.com>
Thread-Topic: IPsec issue #46 -- No need for nested SAs or SA bundles
Thread-Index: AcNxtqhd9Uc+FtNeSZSoZ4LyERTvBwAp1EKA
From: Mohan Parthasarathy <mohanp@tahoenetworks.com>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>, ipsec@lists.tislabs.com
X-OriginalArrivalTime: 03 Sep 2003 21:30:42.0720 (UTC) FILETIME=[A0D54A00:01C37262]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA06614
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Content-Transfer-Encoding: 8bit

 
> 
> >>>>> "Markku" == Markku Savela <msa@burp.tkv.asdf.org> writes:
>     Markku> Just a note: my implementation can do nested 
> SA's, assuming you
>     Markku> mean situation where you have an internal node 
> "Another" that
>     Markku> wants IPSEC, but which happens to be behind a 
> security gateway SG:
> 
>     Markku>               SA1
>     Markku> MyNode  <---------------> SG
>     Markku>         <----------------------------------------> Another
>     Markku>               SA2
> 
>   Let me extend this a bit, to make sure we are talking about 
> the same thing.
> 
> SPD:
> 
>          SRCIP     DESTIP       gateway
>   SA1	 MyNode/32 Another/32   SG
>   SA2	 MyNode/32 Another/32   Another
> 
> 
>   FreeS/WAN current can *NOT* handle this. I consider this a 
> serious bug, which I unfortunately, do not have a mandate to 
> fix at this time.
> 
>   I believe that this facility needs to remain in the 
> specification. In particular, when "MyNode" decapsulates, it 
> has to be very careful to avoid loosing any priviledges that 
> SA1 or SA2 might have conveyed, while still protecting things 
> properly.

Yes, please do not remove it from the specification. PANA working group
is trying to use SA bundles. SG above is the local enforcement
point ( e.g.NAS, Access Router) and "Another" could be the SG of your
corporate network for VPN access.

draft-mohanp-pana-ipsec-00.txt explains this in IP-IP transport mode
where
the SA bundles are not required. But with recent discussions in PANA WG,
I am going to go back to tunnel mode SA. At least, this is another
scenario
where this would be useful.

thanks
mohan

> 
> ]      Out and about in Ottawa.    hmmm... beer.              
>   |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON  
>   |net architect[
> ] mcr@sandelman.ottawa.on.ca 
> http://www.sandelman.ottawa.on.ca/ |device > driver[ ] 
> panic("Just another Debian/notebook using, kernel hacking, 
> security guy");  [
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (GNU/Linux)
> Comment: Finger me for keys - custom hacks make this fully PGP2 compat
> 
> iQCVAwUBP1Ubr4qHRg3pndX9AQGLHQQAoxssKgYDj88AimxNbSU9jZGULpv8OjLP
> r8Iyx0klU9SmG2YiEC3aMXZEl5Enu3gXTETPPUy9tPC5n7jbsEqSR5L2BEQFyWdq
> PT1v8MjIDlVlZ5NHnQiKZRzcj7hgvJEBNKfdznkeavVov1yM259Vgjz8af416FKy
> AtiZP3LXaso=
> =hmzS
> -----END PGP SIGNATURE-----
>