[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue #82: Creation of SAs -- clarifications
Stephen Kent writes:
> >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?
Yes.
> >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?
Yes.
> > 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).
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?
> >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.
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
field:
> >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.
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.
> 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.
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.
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/