Subject: [tcpm] Minimum nonce length in draft-touch-tcpm-experimental-options

From: "SCHARF, Michael" <[email-masked]>
Date: Mon, 20 Feb 2012 12:34:45 +0100

Joe,

The wording on the nonce length in draft-touch-tcpm-experimental-options
may be a little bit unclear ("it MAY be as few as 16 bits if desired").

Does that statement intend to say something like "MUST NOT be shorter
than 16 bits long"? Or shall even a nonce of length 0 be allowed,
provided that there are additional security mechanism such as checksums
or digital signatures? In the latter case, existing use of the
codepoints without nonce could be compliant to the recommendation,
provided that there are other means to detect false positives.

As a side note, I guess that the numbers "245 and 255" in the second
paragraph are wrong. This should refer to 253 and 254, right?

Michael (as individual)

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 28 Feb 2012 12:14:50 -0800

Hi,

> provided that there are other means to detect false positives.

I don't have strong opinion on this yet, but I personally think we
don't have to mention minimum length specifically in the draft.
However, I might prefer to put a little bit more stress in this regards, like,
   o It's implementor's responsibility to find good balance between
the overhead of magic number and the overhead to handle false
positive.
   o the draft doesn't guarantee anything even if an implementor
chooses longer magic number

Thanks,
--
Yoshifumi Nishida

---

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 29 Feb 2012 22:08:23 +0200

> chooses longer magic number

I agree. Given the scarcity of TCP option space, you do not want to use any more space for the magic number than necessary. Maybe one possible option could be to use a 32-bit magic number in the SYN handshake, to declare that for the rest of that connection option types 253 and 254 are used without magic number for feature X (or perhaps with a shorter magic number, to allow simultaneous experimental features). This could be useful when the option space is expected to get tight.

- Pasi

---

From: "SCHARF, Michael" <[email-masked]>
Date: Wed, 29 Feb 2012 21:29:09 +0100

> >> provided that there are additional security mechanism such as 
> >> checksums or digital signatures? In the latter case, 
> existing use of 
> >> the codepoints without nonce could be compliant to the 
> >> recommendation, provided that there are other means to 
> detect false positives.
> > 
> >   o It's implementor's responsibility to find good balance 
> between the 
> > overhead of magic number and the overhead to handle false positive.
> I agree. Given the scarcity of TCP option space, you do not 
> want to use any more space for the magic number than 
> necessary. Maybe one possible option could be to use a 32-bit 
> magic number in the SYN handshake, to declare that for the 
> rest of that connection option types 253 and 254 are used 
> without magic number for feature X (or perhaps with a shorter 
> magic number, to allow simultaneous experimental features). 
> This could be useful when the option space is expected to get tight.

Option space is particularly scarce in SYNs. Afterwards one could try to
piggyback a long option to an empty ACK instead. Thus, this only helps
if a rather long option must indeed be present in a data segment, right?

Michael

---

From: Joe Touch <[email-masked]>
Date: Wed, 29 Feb 2012 13:15:06 -0800

> if a rather long option must indeed be present in a data segment, right?

There could be multiple instances of option 253 or 254, and the only way 
to know they're distinct is the magic number. Otherwise, any shortcut 
you use could conflict with someone else's.

So there's no shortcut here; as you note, this isn't helping the more 
critical location (SYNs) anyway.

Joe