Subject: RE: Question regarding null padding session name in RSVP-TE Att o bj

From: "Jiang, Donghua (Jane)" <[email-masked]>
Date: Fri, 16 May 2003 08:51:42 -0400

George,

2) Should we use the Name Length to decide where the end of the Session Name is, rather than checking on whether the character is printable or not?

Thanks,
Jane

-----Original Message-----
From: George Swallow [mailto:[email-masked]]
Sent: Thursday, May 15, 2003 5:22 PM
To: Ling Yan
Cc: [email-masked]; [email-masked]
Subject: Re: Question regarding null padding session name in RSVP-TE Att
obj 

>     I have a simple question regarding null padding to the session name
> to make it to be a multiple of 4 and at least 8 in RSVP-TE attribute
> object. It is really appreciated if someone can help to clarify it.
> Thanks in advance.
> 
> If the string length is exactly a multiple of 4 and greater than 8
> without counting null padding or null terminate character, --
> 1) is it required to add at least null terminated char to indicate the
> string termination?

No.  But it would not be illegal to add a multiple of 4 nulls.  But
optimally you should only add 0-3 nulls.

> 2) is it required to check at the receiver whether the session name is
> null terminated or not?

Only to find the end of the string.  I.e. if the last char is
printable it should pass.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719

---

From: George Swallow <[email-masked]>
Date: Fri, 16 May 2003 10:39:55 -0400

Jane -

> 2) Should we use the Name Length to decide where the end of the
> Session Name is, rather than checking on whether the character is
> printable or not?

Yes, though either should work if the sender is playing by the rules.
(and if you're really worried about being defensive then both are
necessary).  But all of this is what we call "implementation detail",
i.e not specified.

...George

---

From: David Charlap <[email-masked]>
Date: Fri, 16 May 2003 14:22:42 -0400

> 2) Should we use the Name Length to decide where the end of the Session Name 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

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 16 May 2003 15:35:53 -0400

In message <[email-masked]>, David Charlap writes:
> > 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?
> 

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