Subject: [anonsec] what kind of phase 2 SAs are we negotiating?

From: pekka.nikander at nomadiclab.com (Pekka Nikander)
Date: Fri, 27 May 2005 12:59:12 +0300

[Catching up]

[Discussion about BTNS and NATs, like the following:]

> Let's take the following network:
>
> A1------------\
>               +-NAT----S
> B1------------/

[Michael getting to the following conclusion:]

> This suggests that the IPsec layer of S must either do NAT itself 
> before
> passing the packets upwards, or must be well enough integrated into 
> the stack
> that it can annotate the PCB with an appropriate SA.

Given that we are likely to move to an environment where
the IP addresses are likely to be quite ephemeral, IMHO
there is strong architectural reasons to annotate the
incoming IPsec-protected IP packets with the SA, and even
have back-pointers from the SA to the relevant SPD and PAD
entries.

Yes, I know that this not really possible with BITS or BITW,
but I'm genuinely afraid that much of the current
IP-address-relying IPsec practises will break down at
some not-too-distant point in the future anyway.

--Pekka

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 27 May 2005 10:22:46 -0500

> > that it can annotate the PCB with an appropriate SA.

Note that some implementations already support latching of SA IDs (and
other parameters) to PCBs.  IIRC KAME has an IP_POLICY socket option for
that, and Solaris has IP_SEC_POLICY.  This is not news.

My first I-D focused on BITS because that was easy, even if seriously
unsatisfactory.

Next someone should publish an I-D describing the binding done and
maintained by IP_POLICY/IP_SEC_POLICY.

> have back-pointers from the SA to the relevant SPD and PAD

I agree, but this won't make the two-nodes-behind-the-same-NAT problem
that Michael brings up go away as the PAD entry on the server, in that
case, is for the NAT address, not for the address behind the NAT, so
we'd have to fix the PAD to be NAT aware.  Sigh.

> some not-too-distant point in the future anyway.

I share your sentiment.

Nico
--

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Fri, 27 May 2005 10:29:42 -0500

> we'd have to fix the PAD to be NAT aware.  Sigh.

And note that there is a compatibility/authorization problem here.

Suppose I have an application that uses KAME's IP_POLICY socket option
and assumes that the IP addresses of connected sockets with that option
set have been strongly authenticated and so it does authorization checks
based on IP addresses?

I don't know of any such applications, but, do none such exist?

Nico
--

---

From: sommerfeld at sun.com (Bill Sommerfeld)
Date: Fri, 27 May 2005 10:59:06 -0700

On Fri, 2005-05-27 at 08:22, Nicolas Williams wrote:
>  IIRC KAME has an IP_POLICY socket option for

in case anyone stumbles across this in a mail archive and actually wants
to write code based on this:

solaris has a socket option named IP_SEC_OPT, not IP_SEC_POLICY, which
sets a requested/required algorithm set for AH and/or ESP.

% grep IP_SEC /usr/include/netinet/*.h
/usr/include/netinet/in.h:#define       IP_SEC_OPT              0x22   
/* Used to set IPSEC options */

					- Bill

---

From: Nicolas.Williams at sun.com (Nicolas Williams)
Date: Sat, 28 May 2005 15:38:20 -0500

> /* Used to set IPSEC options */

Typo.  Thanks.