Subject: [MMUSIC] draft-ietf-mmusic-media-path-middleboxes-00.txt: Firewalling/NAT Traversall

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 07 Apr 2008 14:38:17 +0200

Hi all, 

more comments from Thomas Belling:

OLD SECTION 6:

6.  Interactions between Media Path Signaling and Middlebox Behavior

   This section points to the problems that occur when signaling
   exchanges are performed along the media path when middleboxes are
   present that behave in the way described in this document.

6.1.  Firewalling

   The description in Section 4 highlighted that the timing of the
   policy rule installation by the MIDCOM agent towards the middlebox
   has an impact on when and what media traffic is allowed to traverse.

   Hence, the middlebox prevents the exchange of packets in the media
   path until the session establishment signaling has reached a pre-
   configured milestone where the MIDCOM agent signals to the middlebox
   that packets are allowed to traverse in both directions.  Prior to
   this, packets may be allowed to flow uni-directionally to satisfy
   certain service requirements or may be entirely blocked by the
   middlebox.  For SIP [RFC3261] the typically milestone that must be
   reached is offer/answer exchange [RFC3264] accompanied by an
   acknowledgement that the dialog has been accepted by the UAS (i.e.,
   200 OK to the INVITE).  A concrete example of the impact can be found
   with the case of key exchange along the media path, as it is provided
   by DTLS-SRTP.  Figure 2 of [I-D.fischl-sipping-media-dtls] shows that
   the arrival of the SIP INVITE at the UAS triggers the DTLS handshake.
   This message would be blocked by the middlebox, as described in
   Section 4 since the MIDCOM agent has not yet installed policy rules.
   The consequence is that the DTLS key exchange is delayed until the
   policy rules are installed and that media traffic that is sent before
   the DTLS exchange is completed may be dropped and the user
   experiences clippping.

   Unlike with the pilot packet used for NAT traversal, the bi-
   directional media path is established via the signaling path, not via
   packets sent along the media path.  In some deployment models, RTCP
   is always available bi-directionally regardless of the installed
   policy rules.  Obviously, this is not a property that can be
   guaranteed to be true in the future.

6.2.  NAT Traversal

   The described NAT traversal interaction prevents asynchronous
   exchange of packets in the media path until a pilot packet has been
   received by the middlebox from the endpoint being served.  It can be
   employed for both the [RFC3264] offerer and/or answerer.  Therefore,
   in the worst case, both endpoints must generate a pilot packet
   towards each other to ensure a bi-directional media path exists.  Any
   signaling on the media path that relies upon a uni-directional
   handshake in the reverse direction may not complete until media in
   the forward direction by the other endpoint.  If signaling on the
   media path is required to complete prior to media generation the
   handshake may stall indefinitely.

Proposal for NEW SECTION 6

6.  Interactions between Media Path Signaling and Middlebox Behavior

   This section points to the problems that occur when signaling
   exchanges are performed along the media path when middleboxes are
   present that behave in the way described in this document.

6.1.  Packet Filtering

   The description in Section 4 highlighted that the timing of the
   policy rule installation by the MIDCOM agent towards the middlebox
   has an impact on when and what media traffic is allowed to traverse.

The installation of policy rules for media is a prerequisite for related media to flow. As those policiy rules are derived from information from both SDP offer and answer, they are typically installed at the completion of the first offer-answer exchange[RFC3264].

   Further, the middlebox may prevent the exchange of packets in the media
   path after thiis point by closing "gates§" until the session establishment signaling has reached a pre-
   configured milestone where the MIDCOM agent signals to the middlebox
   that packets are allowed to traverse in both directions.  Prior to
   this, packets may be allowed to flow uni-directionally to satisfy
   certain service requirements or may be entirely blocked by the
   middlebox.  For SIP [RFC3261] the typically milestone that must be
   reached is offer/answer exchange accompanied by an
   acknowledgement that the dialog has been accepted by the UAS (i.e.,
   200 OK to the INVITE). It depends on the policy of an operator when to open gates. The policy may take into account the requirements of special media types to have early bidirectional media exchanges, e.g. if the usage of DTLS is indicated in SDP (not yet standardized)

 A concrete example of the impact can be found
   with the case of key exchange along the media path, as it is provided
   by DTLS-SRTP.  Figure 2 of [I-D.fischl-sipping-media-dtls] shows that
   the arrival of the SIP INVITE at the UAS triggers the DTLS handshake.
   This message would be blocked by the middlebox, as described in
   Section 4 since the MIDCOM agent has not yet installed policy rules.
   The consequence is that the communication fails unless the UAS repeats attempts for an DTLS handshake (not yet standardized) until connectivity is established in both directions by the installation of policy rules and opening of gates. Due to extra time required for the DTLS exchange the user may experiences clipping.

   According to 3GPP standards, gates for RTCP are always opened when policy rules for related media are installed, even if related media traffic is still blocked. Therefore signalling embedded in RTCP is likely to bass after the completion of the first offer-answer exchange.

Standardized policy rules only inspect source and destination information of IP packets and the transport protocol identification (e.g. UDP, TCP), so in-path signalling applying the same transport protocol as media is likely to require no modifications of policy rules.

6.2.  NAT Traversal

Middleboxes as described in Clause 5 will not allow any media to pass through without being configured to do so by the MIDCOM agent when the first offer-answer exchange is completed. (Without latching, it may be technically feasible to pass media packets from answerer towards offerer after the offer has passed the MIDCOM agent, but existing implementations hardly show that behavior). Further, such middleboxes may apply gating policies similar to the policies discussed In Clause 6.1 in addition.

The described latching technique for residential NAT traversal interaction requires  that a pilot packet has been
   received by the middlebox from the endpoint being served before the middlebox is able to send packets towards the endpoint.  This latching technique can be
   employed for both the [RFC3264] offerer and/or answerer.  Therefore,
   in the worst case, both endpoints must generate a pilot packet
   towards each other to ensure a bi-directional media path exists. If the first packets to be exchanged in the media path are signalling packets and a particular directionality of those packets is required, communication may fail.
To overcome this problems, empty packets could be send by the endpoint that has to receive rather that to send the first signalling message. The offer is capable of sending the pilot packet only when receiving the destination information within the answer. Thus, before that point in time the offerer will also not be able to receive any media packets or related signalling.

In a similar manner as outlined in Clause 6.1, any in-path signalling which is sent before the offer-answer exchange is completed will fail.

Depending on the implementation, H.248 controlled midcom agents according to Clause 6.2 may perform media level processing, e.g. transcoding. Such midcom agents will require updates to allow in-path signalling to pass.

Ciao
Hannes
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic