Re: [tcpm] Handling of malformed options

[Joe Touch <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fernando Gont wrote:
> Hello, Joe,
> 
>>>>> This suggests that extending SACK while still using the same option type
>>>>> is not a good idea, or at least not a backwards-compatible one.
>>>> ...
>>>>
>>>> It may also suggest a bug.
>>> Where's the bug? The spec says the length field is e.g. 2. If you
>>> implement the standard, and receive an option with a length field that
>>> is different than 2, how are you supposed to process the option? If you
>>> don't know how to process it, it seems sensible to ignore the option.
>> OK, since this is supposed to be a security doc, can you explain why you
>> take a segment with a mis-formed option and ignore it, even when the
>> length - the field that tells you where the next option starts - is
>> nonsensical?
>>
>> Why don't you drop the segment or send a RST?
> 
> draft-gont-tcp-security recommends to silently drop the segment, *NOT*
> to silently ignore the option.

OK, but why not make a more general recommendation for all options in
this regard? And why does the doc not indicate that this does differ
from what is widely deployed, and discuss that issue?

Let's look at one other:

3.6.7 present Ramaiah's suggestions on RST handling, but lacks the
advice on which components were already standard (silently dropping RSTs
out of window) and the conditions under which Ramaiah's extensions are
recommended.

I continue to believe the doc needs a scrub on this point. It should be
much more clear about the difference between:

	- recommendations already required by standards

	- recommendations currently deployed but not standard,
	and the WG's position on each (recommended, recommended
	in some deployments, not recommended, or no position)

	- additional recommendations, and whether they are
	consistent with or diverge from standards, and
	whether they have been deployed or differ from
	deployments

If we are going to work with this doc as a starting point, having a
dozen people replicating that effort isn't useful.

Joe

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpLo74ACgkQE5f5cImnZruiJACgqPImxN2+k7iSFVvwoVHPDdux
mFMAoOO9vJLrlwQVmnIdy9O5Pq/RwpRc
=YetP
-----END PGP SIGNATURE-----