Cisco Systems, Inc.

101 Cooper Street Santa Cruz CA 95060 USA rohan@cisco.com

Transport SIPPING WG I-D Internet-Draft policy midcom firewall SIP Entities (especially User Agents) are frequently setup in private networks where a policy element or other middlebox must be traversed to communicate with other networks including the public Internet. The document discusses the apparent paradox of balancing the concerns and requirements of administrators of these middleboxes with the rights of individual users. Consistent with this discussion, this document also proposes a new SIP response code with which middleboxes can communicate policy requirements back to SIP User Agents.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119.

Many SIP networks consist of User Agents which are located in a private network which is connected to the Internet by various types of middleboxes. These middleboxes are primarily concerned with details about sessions which are contained in offers and answers, each of which can appear in a variety of requests or responses.

This document defines a new 400-class SIP response code which middleboxes can use to communicate that 490 Use Policy This response contains one or more sipfrags which each of which includes an error message indicating a part of the request which was unacceptable. Requests 490 Use Policy Content-Type: message/sipfrag 493 Undecipherable 406 Not Acceptable Accept: application/sdp Firewall traversal To accomplish firewall traversal, the user agent sends a request which contains a session description which the firewall controller can read to open pinholes on behalf of the user agent. perhaps the user agent sent a session description which was end-to-end encrypted. The firewall controller sends a response back to the initiator indicating that the message wasn't readable to allow for firewall traversal. If the user agent has session details it wishes to keep secret, such as end-to-end encryption keys, it can keep these secret by sending both an end-to-end encrypted session description intended for the final recipient and a more abbreviated session description intended for the firewall controller. NAT traversal To accomplish NAT traversal, the user agent has two options. It can send a request which contains a session description already suitable for NAT traversal (using a protocol such as STUN to detect this), in which case the middlebox acts just as a firewall, verifying the addresses map to existing bindings. Alternatively, the user agent can send a session description with private addresses. Rather than break end-to-end message integrity by modifying the session description, the NAT controller returns a 490 Use Policy response which contains a sipfrag with an appropriately remapped session description. If the user agent approves of the remapping, the user agent can then send the request (optionally with end-to-end message integrity). 488 Not Acceptable Here Content-Type: application/sdp m=audio 19502 Responses when forwarding requests to a UAS, middlebox controllers add a new option-tag to the Require header of the request. Require: policy include a matching In addition this document proposes that SIP proxy servers should be allowed to append message bodies to any SIP message, and to delete message bodies "addressed" to them. Offer is in a request, Answer is in a response INVITE/18x INVITE/200 PRACK/200 UPDATE/200 Content-Type: application/sdp Content-Disposition: session;handling=required;direction=offer Content-Type: message/sipfrag Content-Disposition: policy;handling=optional;direction=answer SIP/2.0 490 Use Policy Content-Type: application/sdp m= c= Offer is in a response, Answer is in a request 18x/PRACK 200/ACK INVITE --> --> --> --> <-- <-- <-- <-- 18x (w/offer) PRACK (w/answer) <-- 490 PRACK (w/ no m-lines answer) --> ---> --> UPDATE -> (offer) <-- 200 (answer) who needs to get these requests this is somewhat complicated by the fact that only the offer or answer appears in a given message, that there is no way to respond to responses, and that offers can appear in responses. preconditions policy preconditions each side has precon should work in two NAT model or the one NAT model. One NAT at UAC offer in request offer in response One NAT at UAS offer in request offer in response NAT on both sides "Layered" NATs try with preconditions as well....

The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234.

***