Subject: RE: [Ipsec] SPD & IKE v2

From: "Timothy Liu" <[email-masked]>
Date: Wed, 2 Mar 2005 14:54:58 -0800

How about for the initiator to include a notification
TS_EXACT_MATCH_REQUIRED,
if exact TS match is required? In this case, the initiator MUST include
exactly ONE TSi 
and ONE Tsr. The responder SHOULD accept the TS as is or reject it. The
initiator that sends TS_EXACT_MATCH_REQUIRED MUST reject narrowed TS 
from the responder. (The 'responder SHOULD' clause relieve the
responsibility
from the responder in case the responder do not recognize the
notification.)

The responder side that need to enforce exact match can do so on its
own.

I think we are in a gray area where IKEv2 impose a interop requirement
on policy
'enforcement', which is quite vendor specific.

Timothy Liu
Juniper Networks

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

---

From: "Yoav Nir" <[email-masked]>
Date: Thu, 3 Mar 2005 00:59:01 -0800

On Mar 3, 2005, at 12:02 AM, Bill Sommerfeld wrote:

> On Wed, 2005-03-02 at 16:43, Paul Hoffman wrote:
>
>> Further, the way the
>> document is worded, you are supposed to make the first selector for
>> the first packet *even if you don't want to actually have that flow*.
>
> why would you ask for an SA you didn't intend to use?

You might want to do this for a remote client.  The client has a 
"Connect" button.  The software has no way on knowing what the user is 
going to do after clicking "Connect".  In IKEv1 it would do only Phase 
1.  In IKEv2 you can't do only phase 1, so you need to make some child 
SA in there.  Making an SA for simple ICMP between the client and the 
gateway (just one address and protocol in each TS) is one way.  You 
could also suggest the entire Internet (0.0.0.0-255.255.255.255) and 
have the gateway narrow that to some range or bunch of ranges which may 
or may not be useful later.  In the case of a generic client I think 
the latter approach is more appropriate, especially if it doesn't have 
a matched policy with the gateway.  Doing the whole thing with the 
"Connect" button and 4-8 packets only to fail because the gateway 
blocks ICMP is a bad idea.

---

From: "Tero Kivinen" <[email-masked]>
Date: Thu, 3 Mar 2005 10:02:53 -0800

Yoav Nir writes:
> going to do after clicking "Connect".

If you press connect button the initiator is not requesting the SA due
to the data packet, thus you do not send the packet specific data in
the TS.

The paragrap describing how to send the TS starts:
----------------------------------------------------------------------
   To enable the responder to choose the appropriate range in this case,
   if the initiator has requested the SA due to a data packet, the
   initiator SHOULD include ...
----------------------------------------------------------------------

I.e. the SHOULD only matters if "the initiator has requested the SA
due to a data packet".

I think that SHOULD should be MUST instead of SHOULD, I do not really
understand now why it is SHOULD as it does not cover this kind of
"connect button" or "autostart" cases, thus there is no point of ever
leaving that TS out.

Anyways as it is SHOULD now, it will stay SHOULD, it is too late to
change that.

Note, that the section which says that responder MUST return TS which
includes the the first TS from the initiator is NOT specific to this
case. That MUST be followed always. I.e. responder do not have option
to return TS which does not match the first TS completely.

This actually solves those SOHO VPN users problem. They configure the
TS to be "autostart", i.e. initiated from the beginning without data
packet, and the first TS included is something that the responder must
accept completely, or fail the negotiation. Of course it will still
cause all the negotiations to fail if the responder is configured to
only allow subset of the first TS.

> In IKEv1 it would do only Phase 1. In IKEv2 you can't do only phase
> 1, so you need to make some child SA in there.

Why are you making the IKE SA if you do not intend to use it?

> Making an SA for simple ICMP between the client and the gateway
> (just one address and protocol in each TS) is one way. You could
> also suggest the entire Internet (0.0.0.0-255.255.255.255) and have
> the gateway narrow that to some range or bunch of ranges which may
> the latter approach is more appropriate, especially if it doesn't
> have a matched policy with the gateway. Doing the whole thing with
> the "Connect" button and 4-8 packets only to fail because the
> gateway blocks ICMP is a bad idea.

If you are doing the client, you should always include the entire
internet as destination, and also for source unless you have IP
address already configured.

I.e. if you do not have IP address yet, you send TSi and TSr both to
include full 0.0.0.0-255.255.255.255 and
::0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF, and allow the responder
gateway to assign you both IPv4 and IPv6 addresses (using
Configuration payload), and also narrow your TSi to only include IP
addresses it assigned to you, and narrow TSr to include the
IP-addresses which can be reaced through it.

If you have IP-address already (statically configured), then you set
your TSi to be exactly that, and still use full internet as TSr. 
-- 
[email-masked]

---

From: "Saroop Mathur" <[email-masked]>
Date: Thu, 3 Mar 2005 10:39:09 -0800

--- Tero Kivinen <[email-masked]> wrote:

> I.e. regardless wheather the first traffic selector item is from
> packet or not, it MUST be included in to the returned TS set. This is
> MUST, not SHOULD, so there is no other way to do that. This text does
> not say what to do if the initiators first traffic selector item is
> not completely allowed, but subset of it would be allowed. I would
> think that in that case the negotiation should fail with
> TS_UNACCEPTABLE.

However, the very next paragraph states:
-----------------------
   If the initiator creates the CHILD_SA pair not in response to an
   arriving packet, but rather - say - upon startup, then there may be
   no specific addresses the initiator prefers for the initial tunnel
   over any other.  In that case, the first values in TSi and TSr MAY
be
   ranges rather than specific values, and the responder chooses a
   subset of the initiator's TSi and TSr that are acceptable. 
------------------------

Hence the responder can narrow the first values in the TSi and TSr.

-Saroop

---

From: "Tero Kivinen" <[email-masked]>
Date: Thu, 3 Mar 2005 09:46:02 -0800

Saroop Mathur writes:
> > At 10:14 AM -0800 3/2/05, Surya Batchu wrote:
> > >IMO, it is good to have an indication in TS payload indicating that 
> > >this payload has packet header selectors.
> 
> I believe such an indication will be really useful.

Yes it would be usefull, but not possible at this time.

> It can be generalized to indicate "the responder must include this
> TS in the subset selected by the responder".

That is already there in the document. It says:

----------------------------------------------------------------------
   If the responder's policy does not allow it to accept the entire set
   of traffic selectors in the initiator's request, but does allow him
   to accept the first selector of TSi and TSr, then the responder MUST
   narrow the traffic selectors to a subset that includes the
   initiator's first choices. In this example, the responder might
   respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and
   IP protocols.
----------------------------------------------------------------------

So if the initiator is creating the SA based on the policy not based
on packet, and does not send TS items matching the packet, then the
responder must still include the first TS item inside its narrowed
selectors, i.e. it cannot narrow the first selector down at all.

I.e. if initiator send TS 10.0.0.0-10.0.255.255, and responder has
only 10.0.0.0-10.0.200.255 configured, then responder will return
TS_UNACCEPTABLE. If responder has 10.0.0.0-10.255.255.255 configured,
then it will return 10.0.0.0-10.0.255.255 back (i.e. no narrowing).
I.e. in that case the policy must either match exactly or the
responder must have wider policy. In most cases both ends will have
same policy as this is statically configured vpn system.

If the first packet is from packet it usually means that it is
actually included to some other traffic selector too. I.e. initiator
sends 10.0.0.1-10.0.0.1 proto y port x, and 10.0.0.0-10.0.0.255 proto
any port any. Now if the responder have policy of 10.0.0.0-10.0.0.128
proto from packet port any, then he can return one TS of
10.0.0.0-10.0.0.128 proto x port any. That returned TS is subset of
the union of all input TS items (actually subset of second TS item,
but as the first TS item is subset of second their union is actually
exactly same as second TS), and also the first TS item from the
initiator is also included in this TS item.

> This also allows an initiator to have some say in what the
> negotiated TS will be. e.g. if a initiator supports only a single SA
> for the entire subnet and does not want the responder to narrow the
> TS, it currently cannot indicate this. Most SOHO VPN boxes only
> support a few SAs and will be at the mercy of the responder to not
> narrow down the policy.

If the responder is configured to require separate SA for each port
then there is nothing the initiator can do in the exchange. Their
policies are simply not compatible with each other. 

> 
> > I think it is *way* too late for that for the current spec. There is 
> > no space currently in the headers for that.
> 
> I agree it is way too late for such a change, however, if a change is
> desired, space can be created in the TS header. Currently, the
> "Selector Length" field is 16 bits. It could be reduced to 8 bits and 1
> bit out of the remaining 8 bits be used for this indication. This
> leaves 7 bits for future expansion.

All lengths inside the IKE payloads are 16 bits, and we might want to
have TS type later having more than 256 bytes. It would be much easier
to add a new TS type of TS_IPV4_PACKET and TS_IPV6 PACKET having
format of:

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !   TS Type     !IP Protocol ID |       Selector Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Port               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      !                                                               !
      ~                         Address                               ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and use that to specify the information about the exact packet. But
as said earlier, it is too late for this kind of changes.
-- 
[email-masked]

---

From: "Stephen Kent" <[email-masked]>
Date: Thu, 3 Mar 2005 05:59:26 -0800

At 4:26 PM -0800 3/2/05, Subha wrote:

Hi All,

I also think that IKEv2 and 2401-bis are conforming to each other. I would

appreciate if someone could indicate why they are not.

Thanks,

Subha

I think the problem is that the SPD specifies pairs of TSi/r values, per protocol, to be bound to an individual SA (assuming no use of the PFP feature). If one interprets IKE proposals the way I suggest, then one can negotiate SAs consistent with the SPD. However, as Tero noted, in some cases this will result in significant IKE message size growth, that may cause fragmentation problems. The reason for the growth is that if we need to convey paired TSi/r address and port data, then one might have to replicate a TSi or TSr value to maintain the pairing. Tero gave examples of this.

So we have a few options of how to address this problem:

        1. change IKE to allow explicit binding of TSi/r values, so that one can unambiguously represent both 1-to-1 and 1-to-many relationships.  this is the best answer, in principle, but folks are understandably reluctant to make a change to IKE syntax at this time.

        2. require 1-to-1 matching of IKE payloads, to allow representation of SPD semantics. this does not change IKE syntax, but does change IKE processing rules, and can result in growth in the size of IKE messages in certain contexts, with attendant fragmentation concerns.

        3. change the SPD syntax and semantics to accommodate the limitations of the IKE syntax. this will cause multiple SAs to be created in some contexts, where the current semantics would allow multiple traffic flows to be carried via a single SA.

if we do not go with #1, then we have a tradeoff: we can create bigger proposals (#2) or create more SAs (#3) each undesirable outcome arising under certain conditions.

Steve

---

From: "Stephen Kent" <[email-masked]>
Date: Thu, 3 Mar 2005 05:29:28 -0800

At 1:22 PM +0200 3/2/05, Tero Kivinen wrote:

>	<SNIP>
>  > For example, the text describes how to pass triggering
>>  packet header data as the FIRST selector set data in TSi and TSr
>>  payloads, implying that the order of elements in these payloads is
>>  important, and that one is expected to view them as pairs, matching
>>  the corresponding S/D address and port fields.
>
>I cannot see how it implies that there is any order for the rest of
>the items, when you say that the first item must be from packet if you
>ant to include it. We needed some way to find the specific from packet
>TS item, and instead of adding a flag or using separate TS type for
>that we decided to put it as a first item in the list. We already
>found out in the interop event that this can cause confusion, as some
>people didn't understand that the first item can be very specific. And
>in some cases is it impossible to find out wheather there is one
>specific entry or not.

We agree that if an initiator wants to send header data from a 
triggering packet, then the data is sent as the first pair of entries 
in the TSi/r payloads. In this case, it seems clear that the 
semantics here is that these entries are paired, i.e., the responder 
should interpret the pair of entries as representing the S/D address 
and port data from the triggering packet.  Do you agree?

But, there is no flag that indicates whether the first entry is from 
a triggering packet, not, as others have noted. Thus if the responder 
always treats the first pair of TSi/r addresses & ports as matched, 
which is the sensible interpretation when this first pair represents 
triggering packet data, then it will do so even when the first pair 
does NOT represent such data.  So, why change the interpretation for 
later pairs of S/D addresses & ports?

>  > So, I have to admit
>>  that I am confused by your comment. If I send a series of pairs of
>>  TSi/TSr payloads, I would interpret this to represent pairs of S/D
>>  data, with a common protocol, so that each matched pair represents
>>  one selector set from an SPD entry, if the entry has more than one
>>  selector set in it.
>
>One of the ideas is that the initiator can send TS:
>
>TSi = 0.0.0.0-255.255.255.255
>TSr = 0.0.0.0-255.255.255.255
>
>and the responder can narrow it down to:
>
>TSi = 10.0.11.22-10.0.11.22
>TSr = 10.0.0.0-10.255.255.255, 192.168.0.0-192.168.255.255

I don't disagree that you can save space in IKE messages under some 
circumstances by being able to associate one payload for one 
direction with multiple ones for the other direction. However, if we 
do not have a way to represent a one-to-one correspondence between 
TSi and TSr values, then we cannot convey the semantics of the SPD, 
and that is not OK.

>  > Can you cite the parts of IKEv2 that suggest the "mix and match"
>>  approach that you indicated?
>
>It does use mix and match in all other cases with similar lists. Can
>you find out where it says you should pairwise tie TS together? It
>does not say anywhere that there should be even equal number of items
>in the TSi and TSr.

The example I gave, for the first set of values in TSi/r implies a 
1-to-1 (paired) matching in this case. Also, the purpose of the IKE 
negotiation is to represent an SPD entry to a peer. SPD entries, like 
analogous ACL entries, are paired. Because we create pairs of SAs 
that represent traffic bidirectional traffic flows that are common in 
the IP context, one expresses ACLs in terms of these bidirectional 
flows.

>  > Such semantics make no sense in the access control context that the
>>  SPD represents.
>
>It does make perfect sense for me. I.e. the TSi lists the IP-address
>ranges which can be found from the initiators end of the network, and
>TSr contains the list of address ranges which can be found from the
>responders end.

The example you provide is a reasonable one, but it represents a very 
simple case where the mix and match approach expresses the underlying 
access control semantics. However, in the more general case, I may 
want to express the notion that Host A in my net can be accesses by 
Host B in your net and Host C in my net can be accessed by Host D in 
your net, AND I want the traffic for both of these flows to be 
carried via one SA. The SPD allows one to express this notion, and 
IKE needs to be able to convey it. That is how firewalls express 
access control policy (modulo the use of SAs) and the IPsec SPD is a 
standardized representation of such an access control policy.

>I.e. if you have VPN setup where the site A has networks 10.0.22.0/24
>and 10.0.44.0/24, and the site B has
>10.0.55.0/24,10.0.222.0/24,10.0.227.0/24, then the TSi will contain
>the networks from site A has, and TSr of the request will have
>0.0.0.0-255.255.255.255, and the responde will narrow that any ip down
>so that TSi will still have 10.0.22.0/24 and 10.0.44.0/24 and the TSr
>will now have the networks site B has.
>
>This would not be possible if the TS items would be tied together, as
>it would cause lots of TS items to be created. We tried to avoid
>combinatory explosion in the IKEv2.

I agree that we should minimize combinatorial explosion, but the SPD 
is a local representation of access control policy and one cannot 
express the sort of constraints that may be necessary if the TS 
proposals are treated as your suggest. IKE could have a different 
structure for the TS proposals, one that would satisfy both goals. It 
could allow for compact representation of the cases where one wants 
to list only selector range for one direction and bind multiple 
ranges to the other direction. But, we do not have that and I sense a 
lot of resistance to making a change of this sort at this point in 
time.

>  > Also, I'd like to think that IKE should be trying to negotiate what
>>  the SPD specifies, to minimize the likelihood that SAs are
>>  established that later will not carry the intended traffic.
>
>I think you earlier said it other way around, i.e. the SPD was
>specified to be able to negotiate what the IKEv2 can negotiate. I
>think I did comment this earlier when you were writing the ASN1
>version of the SPD, but as I am now behind bad network connections I
>cannot search the archives.

I'm afraid you have this backwards :-)

I have said that we tried to work to align the SPD and IKE, so that 
we could negotiate in IKE what the SPD expresses.  We had mismatches 
in 2401bis vs. IKE v1 in that we could express things in the SPD that 
IKE could not negotiate. While it is true that I have said that we 
wanted to make sure that IKE v2 and 2401bis are aligned, there is a 
priority here, i.e., 2401bis specifies access control policies and 
IKE v2 exists to negotiate SAs consistent with these policies, not 
the other way around.

Steve

---

From: "Kevin Li" <[email-masked]>
Date: Thu, 3 Mar 2005 10:20:04 -0800

Why the initiator must/should have the first packet selector specifying first packet?
If initiator wants the first packet to be accepted by the responder, it could well be included in a TS range which he wants remote end to accept. There is no reason to extract this particular TS out from that range. If the remote end doesn't want to accept the traffic type in first packet according to its local policy, it will reject it any way either through TS_UNACCEPTIBLE or exclude that from the narrowing down TS. 

Thanks.

Kevin

Tero Kivinen wrote: 

Yoav Nir writes:

    

      

Further, the way the

the TS.

due to a data packet".

leaving that TS out.

change that.