|
Description
|
Support for the PF_KEY API to the IPsec engine according to RFC 2367,
supporting both IPv4 and IPv6, is required. In addition, the PF_KEY API and the
IPsec engine must exhibit the following behavior in response to non-standard
messages sent into the PF_KEY socket:
The interface must allow indication of selectors that allow all transport
protocols supported by SIP (currently UDP and TCP) to be protected with a
single SA, and the IPsec engine must accept and respect these selectors. (The
standard requires zeroing of the corresponding interface message fields.)
The interface must allow indication of source and destination ports as
selectors, and the IPsec engine must accept and respect these selectors. (The
standard requires zeroing of the corresponding interface message fields.)
These extensions are one way to fulfill the requirements of 3GPP. The
requirements of 3GPP are that packets sent with the following selectors1:
ulp=UDP lport=X, rport=Y, laddr=A, raddr=B
and
ulp=TCP lport=X, rport=Y, laddr=A, raddr=B
are protected by only one SA (3GPP TS 33.203, Section 7.1, text regarding ports
as selectors, as well as Annex H), while e.g. packets with the selectors
ulp=TCP lport=Z, rport=Y, laddr=A, raddr=B
and
ulp=UDP lport=Z, rport=Y, laddr=A, raddr=B
must be protected by another SA. For each 4-tuple lport, rport, laddr, and
raddr, and ulp allowing for both TCP and UDP, only and exactly one SA must be
used.
Any other feasible way (besides the afore-mentioned extensions to the PF_KEY
API according to RFC 2367) to support those 3GPP requirements could be
acceptable as well.
xxxxx@xxxxx.com 2005-04-20 12:01:58 GMT
|
