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

Re: Protocol and port fields in selectors





Mikael.Latvala@nokia.com wrote:
> Undoubtedly true what you are saying. However, consider a typical
scenario where a security administrator wants to configure a security
policy for some application layer protocol, e.g. SIP. SIP is currently
using UDP and TCP but will start using SCTP "really" soon.
> 
> In that case the security administrator must configure 3 identical
> SPD entries, one for each transport layer protocol. Not only that this
> administrative nightmare could be easily prevented by the use of
> wildcards but the number of both SPD and SAD entries could be reduced
> thus improving the performance of IPsec engine.

Yikes. So, basically, in the name of performance (how much, given all 
the other matching?), you're willing to set an SA that might match 
protocols not intended.

I.e., there is NO guarantee that the application protocol will get the 
same port number for SCTP that it has for TCP and UDP. There are a 
number of ports which are defined only for TCP or UDP (i.e., NOT 
reserved or allocated for the other), or which only make sense for one 
protocol.

What you'd be doing is opening a hole in the name of performance.

> What if the administrator needs to configure a different policy for
> lower layer protocols, e.g. ICMP or EGP?

Then the SA should specify those protocols, for which the port fields of 
the SA should have NO meaning.

> In that case the IPsec engine
> should be smart enough to perform some sort of "longest selector match".

Longest match requires contiguity. In IP, the mask can't have a few bits 
set in the middle, and let the top and bottom bits float. In this case, 
it's the same - you shouldn't be able to spec the port UNTIL you spec a 
transport protocol.

> If a SPD entry specifies a port number but a protocol on top of IP does
> not use port, then there is no match and IPsec engine continues
> searching for a correct match.

As it should. That entry would then be underspecified.

> RFC2401 is very vague about this particular issue.

Regardless, the rest of the Internet specs aren't. Ports don't EXIST 
except in relation to a specific transport (i.e., next layer inside IP) 
protocol.

Joe

> touch@isi.edu wrote:
> 
>>sakari.poussa@nokia.com wrote:
>>
>>>Hi,
>>>
>>>I have a question about protocol and src/dst port fields in the SAD selectors.
>>>
>>>Is it allowed to have the protocol field as wildcard and still specify src/dst
>>>port as a specific value? Or is it so that transport layer protocol which actually
>>>has ports (like TCP/UDP/SCTP) must be specified along with the ports.
>>>
>>>I guess it is the latter case according to the rfc2401, page 20 table, but
>>>I just wanted to be sure.
>>
>>Not all transport protocols even have ports (e.g., IP, ICMP, and EGP are 
>>all 'transport' protocols, and none have ports). The port field is 
>>defined only relative to a particular transport protocol.
>>
>>To cover multiple protocols under one port (e.g., TCP/NFS and UDP/NFS) 
>>seems to require multiple selectors.
>