Re: SOI QUESTION: 5.3 SPD entries

[Stephen Kent <kent@bbn.com>]

At 11:44 AM +0300 7/12/02, Ari Huttunen wrote:
>Theodore Ts'o wrote:
>>
>>  Please discuss and answer the following question:
>>
>>  5.3 SPD entries
>>
>>  5.3.A) Is it important in SOI to allow the the responder to accept a subset
>>  of the proposed SA, or should it be an all or nothing acceptance?
>>
>>  5.3.B) Should the SOI offer multiple selectors with specific ports and
>>  addresses, or a single selector with a range of ports and range of
>>  addresses?  (complicated boolean complexity!)
>>
>>  Implications from the scenarios:
>>
>>  <<<In the case of a pair of SGWs fronting multiple non-contiguous
>>  subnets, a mechanism that allowed the negotiation of a list of phase 2
>>  identities will help to alleviate the number of IPsec tunnels that must
>>  be created.>>> [[[5.3]]]
>
>It would be good to be able to configure a VPN client to be able
>to connect to
>      10.0.0.0        -   10.255.255.255  (10/8 prefix)
>      172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
>      192.168.0.0     -   192.168.255.255 (192.168/16 prefix)
>and let the gateway figure out which of the network(s) is actually
>behind it, and return that subset in the return message. This would
>remove the need to pre-configure that information in the client.
>I know some vendors use config mode to convey that information from
>the gateway to the client, but that's not too nice a strategy for SOI.
>If the SA selectors must match correctly from the start, something
>config mode looking is likely to emerge.

I agree with the desirability of allowing subset selection, a point 
you and Michale have made. But in preparing 2401bis I need to have a 
simple algorithm for how the initiator deals with this reduction of 
scope in a proposal. I am especially concerned about what should 
happen if the reduced scope selector set is cached (for high 
performance in a security gateway) and if a subsequent packet arrives 
which would have matched the proposed, broader selector set, but not 
the narrower set that was negotiated.

if we can get agreement on the required behavior in all cases, I'm 
amenable to making these sorts of changes, but a goal in the revision 
of 2401 is to make clearer exactly how an IPsec implementation must 
behave.

Steve