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

RE: Protocol and port fields in selectors



Steve& Joe, thank you for your responses.

The reason why I am asking this is that
in 3GPP/IMS the SIP signaling between the mobile
phone and SIP-proxy (P-CSCF) is protected with an IPSec SA.
The SA is not negotiated with IKE but with a sip-sec-agree
negotiation. In the resulting IPSec SA, the protocol is 
wildcard and the src/dst addresses and ports specified. The 
rationale is to have a single SA to protect the SIP traffic
running on top of UDP and TCP. 

It seems that some implementations support this scenario
while others don't. 

-sakari

>At 7:48 AM -0700 9/26/02, Joe Touch 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.
>>
>>Joe
>
>Joe is right in his response re 2401 and IKEv1. In 2401bis and the 
>next generation key management protocol, we plan to support lists of 
>ranges of selectors, as suggested in the JFK documents, which will 
>allow mapping multiple sets of ports to the same SA.
>
>Steve
>