Subject: Issue #82: Creation of SAs -- clarifications

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Oct 2003 18:23:10 +0300

Parsing this text took quite a long time for me. I finally think I
managed to understand what it is trying to say, but I think the actual
text added to the final document must explain the things more clearly.

So my understanding of the issue is that this changes the text which
says that we can create SAs selectors based on the packet or based on
the SPD to text which says that we can create SA selectors based on
the packet or based on the SPD, or something between.

I.e in addition to only take selectors from the packet implementations
are allowed to expand them towards to the SPD selectors as much as
they like.

Orginal case a) allowed only very specific SA selectors based on the
packet itself. The original case b) takes the SA selectors from the
SPD. The current IKEv2 approach is that we take the selectors from the
packet and select the SPD which matches to them and then create SA
that is either that SPD or any subset of it, as long as the packet
itself fits to that subset.

Is my understanding correct?

If so, I think we can approve this change, but we do need better
wording for the actual text. It took quite a lot of parsing and
thinking while trying to understand what the proposed text actually
says... 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Oct 2003 17:19:49 -0400

>text added to the final document must explain the things more clearly.

we'll try to rephrase, to make this complex topic clearer. I admit it 
was badly done in 2401 and we're trying to do a better job this time.

>the packet or based on the SPD, or something between.

the goal is to allow an SAD entry and an SPD cache entry to be 
created based on selector values from the packet that triggered the 
creation of the SA. This facility was supposed to be described in 
2401, but I think it was even less clear there :-)

>are allowed to expand them towards to the SPD selectors as much as

I don't understand these words.  Let me try again.

For each selector in the SPD, in addition to the literal values that 
define a match, we have defined special values, e.g., ANY and 
OPAQUE. We're saying there is another special value, PFP (populate 
from packet) that indicates the SPD entry matches any value for this 
selector, but wants a new SA created with the value from that 
selector field in the packet header to be used in creating the new SA.

>itself fits to that subset.

IKE is invoked with a set of SPD selector values. In the case of a 
PFP selector, what IKE sees is the SPD entry with the selector field 
extracted from the packet, as opposed to a value from the SPD.

Does this help?

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 15 Oct 2003 13:32:39 +0300

> selector field in the packet header to be used in creating the new SA.

Ok, this is more like taking subset of SPD per field basis?

I.e if the SPD says:

	Entry 1
	set 1	(10.0.0.0-10.0.0.255 <-> 10.0.1.0-10.0.1.255)
	set 2	(192.168.2.0-192.168.2.255 <-> 10.0.1.0-10.0.1.255)

and we have packet with 10.source 10.0.0.22 and destination 10.0.1.5
then we can create either SA directly from the packet

	SA (10.0.0.22 <-> 10.0.1.5)

or from the SPD

	SA (10.0.0.0-10.0.0.255, 192.168.2.0-192.168.2.255 <->
	10.0.1.0-10.0.1.255)

or source from packet and destination from SPD:

	SA (10.0.0.22 <-> 10.0.1.0-10.0.1.255)

and

	SA (10.0.0.0-10.0.0.255, 192.168.2.0-192.168.2.255 <-> 10.0.1.5)

Do we want to allow creation of following SA:

	SA (10.0.0.0-10.0.0.255 <-> 10.0.1.0-10.0.1.255)

I.e take the selector set 1 from the SPD and create SA based on that,
but leave out selector set 2?

Or any arbitrary subset:

	SA (10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9)

Note, that that kind of subsets might be result of the IKEv2
negotiation, as the other end might have different SPD, and he will
limit the proposal sent by initiator to his SPD. I.e if the other end
have following SPD:

	Entry 1
	set 1	(10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9)
	set 2	(10.0.0.20-10.0.0.30 <-> 10.0.33.0-10.0.33.9)
	Entry 2
	set 1	(10.0.0.0-10.0.0.19 <-> 10.0.1.0-10.0.1.255)
	set 2	(10.0.0.31-10.0.0.255 <-> 10.0.1.0-10.0.1.255)
	set 3	(192.168.2.0-192.168.2.255 <-> 10.0.1.0-10.0.1.255)
	set 4	(10.0.0.20-10.0.0.30 <-> 10.0.1.10-10.0.1.255)

He will select the entry 1 as it is the only one where the original
packet fits in. The proposal he actually gets in IKE will be
(10.0.0.22 <-> 10.0.1.5, 10.0.0.0-10.0.0.255 <-> 10.0.1.0-10.0.1.255,
192.168.2.0-192.168.2.255 <-> 10.0.1.0-10.0.1.255), i.e the first
source destination address pair matches the actual packet, and then it
gets the SPD info from the initiator. The IKEv2 defines that he must
select subset that contains the first entry, thus he must select his
SPD entry 1. When he creates the reply, he will take intersection of
the initiator set and his entry 1, getting back result:

	(10.0.0.22 <-> 10.0.1.5, 10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9)

which he can then optimize to as the first item is inside the second. 

	(10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9)

and reply with that to the initiator. This cause the SA to have the

	SA (10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9)

to be created, even when such items was neither ends SPD (it is
largest common subset of their SPDs which can process the packet).

> extracted from the packet, as opposed to a value from the SPD.

Ok, se only possible values given to IKE are either the whole SPD
entry (+the actual value from packet) or only the value from packet
per each field in selector.

Note, that IKEv2 will need the exact values from the packet regardless
whether the final entry is created based on SPD or from the value of
the packet.

I.e to answer my own questions earlier, we do not allow taking only
part of the SPD sets, nor do we allow arbitrary subsets created by the
initiator.

The result of the negotiation might be arbitrary subset of the SPD if
the SPD entries in each end are different. 

> Does this help?

I think so. The PFP constructs helps to understand issue better. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Stephen Kent <[email-masked]>
Date: Wed, 15 Oct 2003 18:23:01 -0400

>Ok, this is more like taking subset of SPD per field basis?

the intent is that specific fields in an SPD entry can be marked as 
being filled in (populated) from the corresponding packet field, if 
it matches the selector value range, rather than just plugging in the 
range from the SPD entry.

>	set 2	(192.168.2.0-192.168.2.255 <-> 10.0.1.0-10.0.1.255)

I assume you are  ignoring all the other selectors here and focusing 
only on the IP addresses, and I assume the "<->" notation is some 
sort of separator for source and destination address, right?

>then we can create either SA directly from the packet

I assume the "10.source is a typo and is supposed to be a source 
address of 10.0.0.22, right?

>	SA (10.0.0.22 <-> 10.0.1.5)

this is what would happen if BOTH the source and destination address 
selectors on set 1 and set 2 were marked for PFP, because the source 
address in the packet does not match the set 2 source address, a 
reasonable interpretation.

>	SA (10.0.0.0-10.0.0.255, 192.168.2.0-192.168.2.255 <->

this is what would happen is we did not mark any of the selectors as PFP.

>	SA (10.0.0.22 <-> 10.0.1.0-10.0.1.255)

this would happen if the source address in set 1 was marked PFP, the 
destination address in set 1 was not PFP, and we ignore set 2, as 
above.

>	SA (10.0.0.0-10.0.0.255, 192.168.2.0-192.168.2.255 <-> 10.0.1.5)

this result is consistent with the source addresses in set 1 and set 
2 not marked as PFP, but the destination address in both was marked 
PFP (I guess).

>but leave out selector set 2?

you have not said which of the address selectors are marked as PFP, 
so I am not sure how to interpret this one. if none of the selectors 
in set 2 is marked as PFP, then this should not be negotiated.

>	SA (10.0.0.20-10.0.0.30 <-> 10.0.1.0-10.0.1.9)

PFP does not seem to be relevant to this sort of subset negotiation, 
as PFP always nails down a selector for an SA to a single value, not 
a range.

>packet fits in. The proposal he actually gets in IKE will be

Agreed.

>per each field in selector.

right

>whether the final entry is created based on SPD or from the value of

right, this is a big change from v1, and not anticipated in the PFP 
notion when it was created. but, the intent is different, i.e., in 
IKE v2 we pass the original packet selectors in an effort to make it 
easier to have two peers establish an acceptable SA without mandating 
identical SPD entries.  it is not trying to create a series of 
distinct SAs, from one SPD entry, in response to transmission of 
different packets.

>the SPD entries in each end are different.

sure.

>I think so. The PFP constructs helps to understand issue better.

But, you did raise some good issues about what to do when a SPD entry 
contains multiple selector sets, one or more of which have PFP 
selectors.  My suggestion is that we should create exactly one SA as 
a result of a packet triggering SA creation. We should examine each 
selector set in the entry. When we encounter a selector set with no 
PFP fields, we just include it in the proposal. If a selector set has 
one or more PFP fields, and if ALL of the fields in the packet are 
consistent with the ranges for the selectors in the set, then that 
should yield one additional proposal.

Comments?

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 16 Oct 2003 14:44:49 +0300

> sort of separator for source and destination address, right?

Yes. 

> address of 10.0.0.22, right?

Yes. 

> 2 not marked as PFP, but the destination address in both was marked 

Isn't it enough for the set 1 destination address to be marked as PFP
to generate this SA?

Actually do we have any cases where we want to have set 1 source
address set marked as PFP but not in the set 2? I.e should the PFP
marker be for the whole entry per field, or for each set per each
field?

> as PFP always nails down a selector for an SA to a single value, not 

That was my impression also, so we do not need to allow that kind of
subsets, i.e we only allow either PFP or full SPD entry per each

> distinct SAs, from one SPD entry, in response to transmission of 

It can cause series of distinct SAs to be created, but at most one SA
(pair) per packet, i.e each negotiation created based on the packet
will create at most one SA (pair) which can handle the packet in
question.

The next packet can cause new SA (pair) to be created from the same
SPD as the previous SA might not be able to handle that new packet
with different values. This can happen either because of the PFP flags
or because the other end had different SPD than what this end have. 

> should yield one additional proposal.

That seems to be right. I.e we always try to minimize the amount of
SAs created per each SPD, and try to offer to the other end the
maximal selector set following our SPD. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Oct 2003 10:02:13 -0400

Tero,

>  > sort of separator for source and destination address, right?

	<SNIP>

>Isn't it enough for the set 1 destination address to be marked as PFP

I'm not sure. Certainly if the dest address in both sets are marked 
PFP, this would result. If only the set 1 dest address is PFP, then I 
might expect to see two proposals:

	SA (10.0.0.0-10.0.0.255, <-> 10.0.1.5)
	SA (192.168.2.0-192.168.2.255, 10.0.1.0-10.0.1.255)

rather than the one, merged example you described.  But, I'm not sure.

>marker be for the whole entry per field, or for each set per each

I think it would be easier to understand that way, and I am in favor 
of not making this any more complex.  So, I'm happy to impose this 
simplification unless anyone objects.

Steve