[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
>