Subject: SCTP Verification Tag: network byte order?

From: Jeff Morriss <[email-masked]>
Date: Mon, 24 Oct 2011 14:39:33 -0400

Hi list,

A pretty trivial question/point: is there any reason that the SCTP 
Verification Tag must be in network byte order?

Since it's an integer (which doesn't appear to have an exception to the 
"MUST be transmitted in network byte order" clause) it seems the answer 
is yes,  but since it's a random number which is (AFAICS) of 
significance only to the generator, I don't see why it MUST be so.

-Jeff

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 24 Oct 2011 21:10:52 +0200

On Oct 24, 2011, at 8:39 PM, Jeff Morriss wrote:

> Hi list,
> 
> A pretty trivial question/point: is there any reason that the SCTP Verification Tag must be in network byte order?
> 
> Since it's an integer (which doesn't appear to have an exception to the "MUST be transmitted in network byte order" clause) it seems the answer is yes,  but since it's a random number which is (AFAICS) of significance only to the generator, I don't see why it MUST be so.
Since the verification tag is not exposed via the socket API, there is no way whether you
sent it in network byte order or not...

Best regards
Michael

---

From: Chris Benson <[email-masked]>
Date: Mon, 24 Oct 2011 12:31:22 -0700 (PDT)

Jeff (and Michael),

The important aspects are only that it is reflected outwards
in the same byte sequence "on the wire" as received, and
that the round trip verification operates in the same way.

From the protocol perspective, it is irrelevant how you 
locally interpret that sequence of four bytes.  If it
is considered as an ordered sequence of four bytes,
then there is no "network byte order" issue.  The 
"random" algorithm that generates a new tag can be
considered to include the network byte ordering
where necessary, so that the random output is just
the four ordered byte values to transmit, reflect,
and verify.

I thus don't think it matters whether you consider the
value to have been rearranged for network byte order or not.
Only the "network-byte-order-value" is important.

By the way, I don't believe totally random values are 
acceptable because of the last sentence of RFC 4960
Section 5.3.1:

 "A new Verification Tag value MUST be used each time the
  endpoint tears down and then reestablishes an association
  in the same peer".

To me, this implies that the new value must be different from
the previous value, which is obviously better for the protocol.
Truly random number sequences contain duplicates (or might!).

With thanks, from Chris.

Chris Benson, Software Engineer,
Adax Inc., Oakland, California, USA.
    [email-masked]
    +1 510 548-7047 ext. 189
    www.adax.com

On Mon, 24 Oct 2011, Michael TÃ¼xen wrote:

>>  Date: Mon, 24 Oct 2011 21:10:52 +0200
>>  From: Michael TÃ¼xen <[email-masked]>
>>  To: Jeff Morriss <[email-masked]>
>>  Cc:  <[email-masked]>
>>  Subject: Re: SCTP Verification Tag: network byte order?
>>

---

From: Jeff Morriss <[email-masked]>
Date: Mon, 24 Oct 2011 15:55:25 -0400

> sent it in network byte order or not...

Sorry, I wasn't asking from an SCTP-User's perspective, but from an SCTP 
implementation perspective.  By looking into the implementation (or 
comparing an implementation's debug output--which includes the vtags--to 
what is on the wire) I can know whether the local vtag is sent in 
network byte order or not.

---

From: Jeff Morriss <[email-masked]>
Date: Mon, 24 Oct 2011 18:15:38 -0400

> Only the "network-byte-order-value" is important.

In fact I had been thinking primarily from the side of the vtag 
generator, but it's doubly true for the vtag receiver/reflector.

---

From: Thomas Dreibholz <[email-masked]>
Date: Tue, 25 Oct 2011 07:55:43 +0200

Am Montag 24 Oktober 2011, 21:10:52 schrieb Michael Tüxen:
> Since the verification tag is not exposed via the socket API, there is no
> way whether you sent it in network byte order or not...

Yes.

However, for debugging purposes, it may be useful to send the verification tag 
in network byte order. Tools like Wireshark interpret the verification tag as 
32-bit value in network byte order and convert it to host byte order to 
display it appropriately.

I have also checked the SCTP implementation sources for FreeBSD, Linux and 
sctplib. All three implementations convert the verification tag to network byte 
order.

Best regards
-- 
=======================================================================
 Dr. Thomas Dreibholz

 University of Duisburg-Essen,                   Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
-----------------------------------------------------------------------
 E-Mail:     [email-masked]
 Homepage:   http://www.iem.uni-due.de/~dreibh
=======================================================================

---

From: Randy Stewart <[email-masked]>
Date: Sat, 29 Oct 2011 09:01:02 -0400

Chris:

Comments in-line…

> Only the "network-byte-order-value" is important.

Exactly…

> Truly random number sequences contain duplicates (or might!).

Well actually this is something thats not talked about in the RFC and
maybe should have been. In TCP you have something called timed-wait, in
SCTP we don't have that concept since a v-tag "protects" us against
old packets.. however, you do need to "timed-wait" the vtags themselves.

So yes, any good implementation is going to keep a "cache" of recently
used vtags and hold them to prevent reuse for 2MSL or so. I know that
most implementations do this.. but it is something we failed to point
out in the RFC.

R

>>> sent it in network byte order or not...

-----
Randall Stewart
[email-masked]

---

From: Randy Stewart <[email-masked]>
Date: Sat, 29 Oct 2011 09:03:06 -0400

On Oct 24, 2011, at 3:55 PM, Jeff Morriss wrote:

> Sorry, I wasn't asking from an SCTP-User's perspective, but from an SCTP implementation perspective.  By looking into the implementation (or comparing an implementation's debug output--which includes the vtags--to what is on the wire) I can know whether the local vtag is sent in network byte order or not.
> 

Hmm.. but as Chris pointed out… if you considered the random number generator giving you v-tags as one
giving you a network-byte order vtag ready to be sent, then you don't have to do anything. Of course
you are welcome to "un-network" it in your debug output and then compare it to a previous un-networked
vtag… but as long as the physical 4 bytes are the same on the wire.. it really does not matter…

R
-----
Randall Stewart
[email-masked]