[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue #82: Creation of SAs -- clarifications
At 13:32 +0300 10/15/03, Tero Kivinen wrote:
>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?
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.
>
>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)
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?
>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
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.
>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)
this is what would happen is we did not mark any of the selectors as PFP.
>
>or source from packet and destination from SPD:
>
> 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.
>and
>
> 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).
>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?
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.
>Or any arbitrary subset:
>
> 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.
>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).
Agreed.
> > 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.
right
>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.
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.
>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.
sure.
>
>> Does this help?
>
>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