Subject: [MMUSIC] Comments on ABNF in draft-petithuguenin-mmusic-ice-sip-sdp-01

From: Magnus Westerlund <[email-masked]>
Date: Wed, 22 Jan 2014 10:35:37 +0100

Hi,

As part of the RTSP for NAT work I actually noticed an issue with the
ABNF that is defined for ICE in SDP.

>From Section 8.1:

   candidate-attribute   = "candidate" ":" foundation SP component-id SP
                           transport SP
                           priority SP
                           connection-address SP     ;from RFC 4566
                           port         ;port from RFC 4566
                           SP cand-type
                           [SP rel-addr]
                           [SP rel-port]
                           *(SP extension-att-name SP
                                extension-att-value)

   foundation            = 1*32ice-char
   component-id          = 1*5DIGIT
   transport             = "UDP" / transport-extension
   transport-extension   = token              ; from RFC 3261
   priority              = 1*10DIGIT
   cand-type             = "typ" SP candidate-types

Petit-Huguenin & KeranenExpires August 29, 2013                 [Page 9]

Internet-Draft             ICE SIP/SDP Usage               February 2013

   candidate-types       = "host" / "srflx" / "prflx" / "relay" / token
   rel-addr              = "raddr" SP connection-address
   rel-port              = "rport" SP port
   extension-att-name    = byte-string    ;from RFC 4566
   extension-att-value   = byte-string
   ice-char              = ALPHA / DIGIT / "+" / "/"

The issue is what is allowed in extension-att-name and
extension-att-value. They are listed here as byte-string. That is an
extremely wide allowance in what values to be included.

First of all it includes SP the character used for delimiting the
-att-name against the -att-value and the next set of name and value. I
can't see that one can allow that, and if one have values that includes
space, then they must be escaped.

Further I wonder if it wise to include the non-visible values from the
below 128 range of the byte. It might be okay, but some thought needs to
be put into this.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Ari Keränen <[email-masked]>
Date: Fri, 24 Jan 2014 13:48:18 +0000

Hi Magnus,

Good point. That ABNF indeed seems to be overly liberal on the extension attribute names and values. Perhaps e.g., token would be more appropriate at least for the extension-att-name (like att-field in RFC4566). 

For extension-att-value, are there any reasonable use cases where e.g., VCHAR would not be sufficient? Are RFC4566 att-values with non-printable characters used somewhere?

Cheers,
Ari