Subject: [Ipsec] Some comments on draft-ietf-ipsec-rfc2401bis-05.txt

From: Markku Savela <[email-masked]>
Date: Tue, 15 Feb 2005 16:12:47 +0200

Few minor comments on this draft.
-------

4.1 Definition and Scope
   ...
   For an SA used to carry unicast traffic, the SPI (Security Parameters
   Index - see Appendix A and AH [Ken04b] and ESP [Ken04a]
   specifications) by itself suffices to specify an SA.
   ...

-------
Shouldn't this be qualified as "For an inbound SA ...". For outbound,
we naturally can have multiple SA's with same SPI, but different
destinations?
-------

4.4.1.1  Selectors
      ...
      - Name:  This is not a selector like the others above.  It is not
        acquired from a packet. A name may be used as a symbolic
        identifier for an IPsec Local or Remote address. Named SPD
        entries are used in two ways:
      ...
4.4.1.2  Structure of an SPD entry
      ....
           o Name -- a list of IDs.  This quasi-selector is optional.
             The forms that MUST be supported are described above in
             Section 4.4.1.1 under "Name".
      ....
           o One to N selector sets that correspond to the "condition"
             for applying a particular IPsec action. Each selector set
             contains:
                - Local Address
                - Remote Address
                - Next Layer Protocol
                - Local Port, or ICMP message type/code or Mobility
                  Header type (depending on the next layer protocol)
                - Remote Port, or ICMP message type/code or Mobility
                  Header type (depending on the next layer protocol)

-------
If "name" is supposed to be used as an identifier of local or remote
address, shouldn't that be somehow mentioned in the "N selector sets"
description? I don't know how to interpret a plain selector with list
of names, as there is no context whether a name is supposed to be
remote or local address (when that interpretation is inteded). To me
it would seem natural to allow a name where expilicit address is
possible.

In addition to above, a generic observation: the boolean expression
combining the individual selector tests is not specified.
-------

4.4.2 Security Association Database (SAD)

   ...
   For each of the selectors defined in Section 4.4.1.1, the entry for
   an inbound SA in the SAD MUST be initially populated with the value
   or values negotiated at the time the SA was created. (See Section
   4.4.1, paragraph on  Handling Changes to the SPD while the System is
   Running for guidance on the effect of SPD changes on extant SAs.) For
   a receiver, these values are used to check that the header fields of
   an inbound packet (after IPsec processing) match the selector values
   negotiated for the SA. Thus, the SAD acts as a cache for checking the
   selectors of inbound traffic arriving on SAs.  For the receiver, this
   is part of verifying that a packet arriving on an SA is consistent
   with the policy for the SA.
   ....

-------
The last sentence is not true, unless the selectors in SA are
decorrelated. This is explained later in "5. IP Traffic
Processing". But, perhaps above should also be amended, so that a
reader is not mislead here.
-------

At the moment I don't have anything else. For me some concepts are
more confusing than clarifying:

 - protected/unprotected side
 - obsession with interfaces

They are perhaps natural for security gateway, but for a host with
IPSEC inside the TCP/IP stack, those are not very helpful (at least
the way I see the implementation). For a host, the model can be very
simple: you just have incoming and outgoing packets, policy either
matches or not, it does not matter what interfaces are involved.

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Feb 2005 12:28:36 -0500

At 4:12 PM +0200 2/15/05, Markku Savela wrote:

first, note that WG last call and IETF last call have been over for weeks.

>we naturally can have multiple SA's with same SPI, but different

yes, this text refers to inbound traffic processing, which is where 
the issue of how to define an SA based on an SPI applies. For 
outbound traffic processing, the SPI is not used to specify (select) 
and SA.

>it would seem natural to allow a name where expilicit address is

As the text in 4.4.1.1 notes, "name" is special. The name is refers 
to the SPD entry as a whole, and thus encompasses all the selector 
sets. Whether the name applies to the local or remote address is 
determined by whether the IPsec entity is acting as initiator or 
responder, as discussed in 4.4.1.1

>combining the individual selector tests is not specified.

The boolean applied to the selector sets is OR, i.e., if all of the 
headers of a packet match any of the specified selector sets, then 
the SPD entry is matched.

>reader is not mislead here.

In 4.4.1, on page 23, the section on decorrelation states that
	"The processing model described in this document assumes the 
ability to decorrelate overlapping SPD entries to permit caching ..." 
So the discussion in 4.4.2 should be interpreted in the context of 
decorrelation, as indicated.

>matches or not, it does not matter what interfaces are involved.

The host model is simple: if there is one interface in the host to 
the Internet, the barrier is implemented by IPsec in its location in 
the stack. the unprotected side is "below" the Ipsec barrier (the 
network side), while the side "above" IPsec (transport and 
application) is protected. In a host with multiple interfaces the 
same model may apply, or one might designate one of the interfaces to 
be protected, depending on the context. And, of course one can make 
use of the model with virtual interfaces that may be purely internal 
to a host.

The point to keep in mind is that IPsec defines a packet filtering 
firewall that can apply cryptographic security for selected traffic 
flows. Like any firewall, there needs to be a barrier that traffic 
crosses and thus becomes subject to inspection/filtering. The 
unprotected vs. protected side aspect of the model is relevant 
because we treat traffic differently depending on its directionality 
with regard to the barrier.

Steve

---

From: Markku Savela <[email-masked]>
Date: Tue, 15 Feb 2005 19:50:11 +0200

> From: Stephen Kent <[email-masked]>
> 

Outbound SA's need to be searched and identified by something, when
IKE updates the SA's.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Feb 2005 12:59:58 -0500

>Outbound SA's need to be searched and identified by something, when

The question of how IKE tracks the SAs that it has created is not 
addressed by 2401bis (or by IKE?).

However, this is an internal issue for each implementation that can 
be solved lots of ways, e.g., via purely local pointers.

We might add a parenthetical clarification if folks believe it is confusing.

Steve

---

From: Markku Savela <[email-masked]>
Date: Tue, 15 Feb 2005 20:07:33 +0200

> the SPD entry is matched.

Just to be sure, within a selector set, the test is

 A) Local Address OR Remote Address OR ...

 B) Local Address AND Remote Address AND ...

I assume (B) is the correct one?

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Feb 2005 13:38:17 -0500

>I assume (B) is the correct one?

yes, B is the correct interpretation. ALL the parts of a selector set 
must match, so they are ANDs, but the selector sets themselves are 
ORs.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Feb 2005 13:32:05 +0200

> I assume (B) is the correct one?

Not from IKEv2 point of view.

IKEv2 traffic selectors are

list of local selectors ORed together
list of remote selectors ORed together

where the local information from packet needs to match item on the
"list of local selectors" and the remote information from packet needs
to match item on the "list of remote selectors". I.e. any local
address is OK, and any remote address is OK. 

Each item in local or remote selectors list is

Address-range AND Next layer protocol AND Port-range

I did explain this when we were talking about the ASN1 description of
the SPD. See <[email-masked]>
http://www.vpnc.org/ietf-ipsec/mail-archive/msg00092.html.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 16 Feb 2005 13:42:27 +0200

> must match, so they are ANDs, but the selector sets themselves are 

That does not match IKEv2. IKEv2 does always combine all local
selectors (address, next layer protocol and port) to one single union
of them, and same thing for the remote selectors, and you can mix and
match them as you like. I.e you can have tarffic selectors

local = TS(10.0.0.0-10.0.0.255),TS(192.0.2.1-192.0.2.255)
remote = TS(10.0.5.0-10.0.5.255),TS(10.0.22.0-10.0.22.255)

and that will mean that all following packets are allowed:

10.0.0.11 -> 10.0.5.1
192.0.2.1 -> 10.0.5.44
10.0.0.1 -> 10.0.22.5
192.0.2.11 -> 10.0.22.66

etc.

I.e. local address can be any from the local address set, and remote
address can be any from the remote address set.

If you want to make policy which allows only from 10.0.0.0-10.0.0.255
<-> 10.0.5.0-10.0.0.5.255 and 192.0.2.1-192.0.2.255 <->
10.0.22.0-10.0.22.255, then you need to make two rules for that, and
create two SAs for that.
-- 
[email-masked]