[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Stephen Kent writes:
> >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.
> 
> 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.

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).

> 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.

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. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/