The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <3EC52C72.4040907@marconi.com>, David Charlap writes:
> Jiang, Donghua (Jane) wrote:
> > 
> > 2) Should we use the Name Length to decide where the end of the Session Nam
> e is, rather than checking on whether the character is printable or not?
> 
> Yes, you absolutely must.
> 
> The RFC says that the object is NULL padded, it does not say that the 
> string is NULL terminated.  This means that if the name is an exact 
> multiple of 4 bytes, there may not be any trailing NULL.  If you use a 
> function that expects a NULL-terminated string (like the C language 
> strcpy function), it may overrun the end fo the string, resulting in 
> undefined behavior.
> 
> Also note that the RFC doesn't specify ASCII (or any other encoding) for 
> the name.  If the encoding is something that permits zero-byte values 
> (e.g. Unicode), a function designed for NULL-terminated strings may get 
> a short count of bytes.
> 
> In other words, this is a counted string and should be treated as such. 
>   If use use the C language, you should not use string functions on it. 
>   Instead, track the length and use functions like memcpy to copy its 
> value.  If you absolutely must pass it to a function that uses 
> null-terminated strings, make sure to append your own NULL character to 
> guarantee that the function doesn't overrun the end of the string.
> 
> -- David


David,

Interesting advice.  Not necessarily all good advice.

You are right about one thing.  If the string fits in an exact
multiple of 4 bytes, the string can be (and generally is) sent without
a terminating null and on reception if the name is specified as having
an exact multiple of 4 bytes the terminating null must be added.

As far as the string being ascii, there I think you are wrong.  If we
still beleive in running code, then I know you are wrong because there
are numberous implementations that have shown up at interoperability
bake-offs.

In draft-ietf-mpls-te-mib- and elsewhere mplsTunnelName is defined as
DisplayString.  You can look in the lsr mib for the session name.  I'm
confident it is the same.

In rfc3209 it is described as:

  Session Name      (NULL padded display string)

rfc2579 defines DisplayString as:

  DisplayString ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "255a"
    STATUS       current
    DESCRIPTION
            "Represents textual information taken from the NVT ASCII
            character set, as defined in pages 4, 10-11 of RFC 854.
            To summarize RFC 854, the NVT ASCII repertoire specifies:
              - the use of character codes 0-127 (decimal)
              - the graphics characters (32-126) are interpreted as
                US ASCII
              - NUL, LF, CR, BEL, BS, HT, VT and FF have the special
                meanings specified in RFC 854
              - the other 25 codes have no standard interpretation
              - the sequence 'CR LF' means newline
              - the sequence 'CR NUL' means carriage-return
              - an 'LF' not preceded by a 'CR' means moving to the
                same column on the next line.
              - the sequence 'CR x' for any x other than LF or NUL is
                illegal.  (Note that this also means that a string may
                end with either 'CR LF' or 'CR NUL', but not with CR.)
            Any object defined using this syntax may not exceed 255
            characters in length."
    SYNTAX       OCTET STRING (SIZE (0..255))

(I left out the blank lines).

If you stick unicode in the SESSION_ATTRIBUTE in the session name,
expect interoperability problems, the least of which may be display
problems.

If necessary next iteration of rfc3209 can be more clear about a
display string being as defined in rfc2579.

If there is a null in string most implementations will interpret this
as the end of the string.

Curtis