[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: an SPD syntax example
Hi,
I felt that original SPD syntax is good, which provides very good
flexibility and ease of administering the policies in large enterprise
environments.
Consider that, there are 50 discrete subnets in an organization and
the security needs to be applied for port 25, port 80 and port 110.
With the original approach (ASN1), proposed by Steve, it only requires
configuration of 50 ranges of IP addresses, 3 ranges of Ports and
put them in one Selector list.
If we go by approach suggested by 'Ravi', configuration of 150
selector lists need to be created. This problem compounds when the
remote site has multiple discrete subnets. Consider that, remote site
has 20 subnets and that requires 3000 Selectors lists at the local end.
Due to this, I feel, original ASN1 text, with some minor modification
would be good.
SPD ::= SEQUENCE of SPDEntry
SPDEntry ::= SET OF SelectorSet
SelectorSet ::= SEQUENCE {
sourceAddr AddrList,
destAddr AddrList,
protocol INTEGER, -- 8 bits
sourcePort srcPorts,
destPort dstPorts
}
AddrList ::= SET OF AddrOrList
AddrOrList ::= CHOICE {
iPAddr IPaddr -- individual IP address
range IPRange} -- IP address range
srcPorts := SET OF Ports
Ports := SEQUENCE OF {
startPort start
endPort end
}
Note: For clarity, I took ICMP part away.
If we go with this approach, some changes to 'Traffic Selector' in IKEv2
are required.
It means that, each traffic Selector should be able to accommodate
Number of IP address ranges
<all IP address ranges>
Protocol
Number of Port ranges
<all Port ranges>
thoughts?
Thanks
Vamsi
CTO Office
www.intoto.com
At 10:20 AM 1/22/2004 -0500, Stephen Kent wrote:
>>It is better to make this as close to IKEv2 Traffic Selector as
>>possible. Based on that, each IP address range should be combined with
>>Protocol/Port Range. This ASN1 description seems to be creating a set with
>>multiple IP address ranges to a single Protocol and Port (Range).
>
>
>Good point. I'll change the syntax, and the 2401bis text to align with the
>IKEv2 proposal format more closely. The effect is the same, ultimately,
>in terms of associating a set of values with the same SA.
>
>>
>>AddrList ::= AddrOrRangeOrSubnet
>>
>>>
>>> AddrOrList ::= CHOICE {
>>> iPAddr IPaddr -- individual IP address
>>> range IPRange} -- IP address range
>>
>>Above should become
>>AddrOrRangeOrSubnet ::= CHOICE {
>> ipAddr IPaddr
>> range IPRange
>> subnet subNet
>> }
>
>I don't see a need to refer to subnets separately. ranges suffice.
>
>> >
>>> IPaddr ::= CHOICE {
>>> v4Addr INTEGER, -- 32 bits
>>> v6Addr [0] INTEGER } -- 128 bits
>>>
>>> IPRange ::= CHOICE {
>>> v4range SEQUENCE {
>>> start INTEGER, -- 32 bits
>>> end INTEGER } -- 32
>>> bits
>>> v6range [0] SEQUENCE {
>>> start INTEGER, -- 128
>>> bits
>>> end INTEGER } } --
>>> 128 bits
>>
>>Internally, subnet and IPAddr should be converted to range, if IKEv2 is
>>used for key management.
>
>Yes, we ultimately convert to range for the selector payload.
>
>Steve