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

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Sep 2003 13:39:31 -0400

At 23:15 -0400 8/29/03, Michael Richardson wrote:
>-----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.

Michael,

2401 does not mandate a particular processing implementation, and 
2401bis will not. But, we do provide a model for processing as a 
concrete means of describing what needs to be done within an IPsec 
implementation. The processing model is a form of state machine, and 
we certainly specify state machines for protocol standards, at least 
when we do a good job.

A primary goal of IETF standards is to promote interoperability. To 
that end, it is necessary to specify minimum capabilities for 
implementations, not only in terms of the syntax of what data is 
exchanged over the net, but also in terms of processing. Failure to 
do so will result in non-interoperability.

The crux of your argument seems to be where we draw a boundary as to 
what is IPsec and what is the province of some larger system. 
However, we have no specs for the larger "system" to which you refer, 
so there will be no basis for interoperability for it.  That is not, 
IMHO, a desirable outcome.

Steve

---

From: Markku Savela <[email-masked]>
Date: Wed, 3 Sep 2003 00:40:18 +0300

Just a note: my implementation can do nested SA's, assuming you mean
situation where you have an internal node "Another" that wants IPSEC,
but which happens to be behind a security gateway SG:

              SA1
MyNode  <---------------> SG
        <----------------------------------------> Another
              SA2

MyNode has nested SA2's, but both SG and Another would not see nested
SA's.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Sep 2003 18:22:47 -0400

>MyNode has nested SA2's, but both SG and Another would not see nested

If I understand your diagram, the MyNode component is the only one 
that would see these as nested SAs. Presumably SA1 is a tunnel mode 
SA to SG and SA2 is a tunnel or transport SA to Another. is that 
right?

How did you express the policy that SA2 had to be an SA nested inside 
of SA1, and thus that SA1 must be created first, etc.?

Steve

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Sep 2003 18:37:36 -0400

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

>>>>> "Markku" == Markku Savela <[email-masked]> 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.

]      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");  [

---

From: Markku Savela <[email-masked]>
Date: Thu, 4 Sep 2003 21:57:54 +0300

> SA to SG and SA2 is a tunnel or transport SA to Another. is that 

Yup.
 
> of SA1, and thus that SA1 must be created first, etc.?

For example with a policy (assuming 'SG' and 'Another' below are
replaced with real addresses).

----------------------------------------------------------
# SA templates

sa SA1 =
 { esp encrypt_alg 3  auth_alg 3  src_specific pfs }

sa SA2 =
 { esp encrypt_alg 5  auth_alg 2 src_specific }

# pass through for IKE traffic

inbound local_port 500 = { }
outbound remote_port 500 = { }

remote Another = { SA2() SA1(SG) }

# pass through anything else

inbound = { }
outbound = { }
-----------------------------------------------------------

Yes, there is a tricky issue, because it will cause IKE to try to
negotiate SA2 with Another before SA1 with SG is ready. What needs to
be done, depends on how SG treats the port 500 with targets behind it
(Another). Above policy assumes it passes clear.

If not, then things get a bit tricky, and I need to add before the
generic port 500 pass throughs a line

 remote Another remote_port 500 = { SA1(SG) }

MyNode opening a connection to Another would trigger following
sequence:

 Acquire SA's matching template SA2 (src=MyNode, dst=Another) -> IKE
 Acquire SA's matching template SA1 (src=MyNode, dst=SG) -> IKE

IKE is assumed to process these independetly. The IKE UDP connections
to Another are blocked for SA2 (due to policy on port 500 to Another)
until the negotiation with SG for SA1 is complete. [I can share SA's
between policy selectors]

When both SA1 and SA2 are ready, communication with Another can
proceed.