Subject: [tcpm] Handling of malformed options (was: Re: poll for adopting draft-gont-tcp-security)

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Jul 2009 13:38:13 -0300

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.

>From Section 4.4.1 (page 43) of draft-gont-tcp-security-00:

"  The SACK-permitted option is composed by an option-kind octet (which
   must be 4), and an option-length octet which must be 2.  Therefore,
   the following check should be performed on the option:

   option-length == 2

   If the option does not pass this check, the TCP segment carrying the
   option should be silently dropped."

This should be a clear example that this document is not simply turning
"current implementations" into "advice". i.e., the advice provided
sometimes differs from what many implementations are doing (as in this
case).

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Wed, 01 Jul 2009 10:58:23 -0700

> 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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Jul 2009 16:10:04 -0300

Hello, Joe,

> this regard? 

Yes, I guess that such a general recommendation would make sense. The
reason for which I repeated this recommendation separately for each
option is that I wanted the option-specific checks to be within their
respective sections.

Had I made a general recommendation, it would have been something like
"if the option-length doesn't match the expected option length, the
corresponding segment should be silently dropped". But then that would
require the implementer to go back to the spec to check which value
should be checked, etc. Also, for some options there's more than one
check that you should perform on the option length (e.g., see SACK).

That said, there *is* a Section (3.10) with general recommendations for
handling TCP options. So I guess that one could keep the option-specific
checks in each of the different sections, but also add a general
recommendation in Section 3.10.. I have no problem with that.

> And why does the doc not indicate that this does differ

It's just missing. As I said, I'm not saying there is not room for
improvement. And I agree that this discussion that you are suggesting
should be incorporated in the document (i.e., will do).

> out of window) 

Well, isn't this the case for any TCP segment? In-window checks are a
required part of RFC 793 itself. That's why I didn't include it here
explicitly.

> and the conditions under which Ramaiah's extensions are
> recommended.

Well, the document is about improving TCP's resiliency/security.
Therefore, it is assumed that at least from that pov, you will implement
Ramaiah's extensions.

Are are you meaning that I should state that IETF-wise, Ramaiah's
extensions come with an applicability statement, etc.?

> I continue to believe the doc needs a scrub on this point.
[...]

This may be necessary. However, I think the wg is currently making a
more meta-level decision, i.e., whether to adopt draft-gont-tcp-security
as a wg item.

That said, I have no problem with working on this particular point
you've raised.

Thanks!

Kind regards,

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 4 Jul 2009 00:11:23 +0100

On 30 Jun 2009, at 19:32, Joe Touch wrote:
>
> I've repeatedly said why I don't want to proceed on this path. It puts
> the WG in the position of repeating ourselves on issues we've already
> decided. Specific example - ICMP in-window checking. We acknowledge
> systems do this,

where is it acknowledged?

thanks,

L.

> but do NOT recommend it as a security check. I've said
> why in at least 3 different IETF meetings, as have others. Yet this  
> doc
> recommends it. That exceeds advice of the WG.
>
> If you want this doc to be the basis of work in this WG, why don't
> **YOU** start by revising it to at least apply the existing WG  
> positions
> on previously discussed advice?

but Joe, you've obviously got more free time...

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Jul 2009 17:51:19 -0700

> where is it acknowledged?

In Gont's ID.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 4 Jul 2009 06:51:30 +0100

>> where is it acknowledged?

What, in the same individual ID you're spending so much energy  
suggesting
shouldn't even exist, and which you're dismissing as implementation  
advice
outside of the scope of the IETF and have otherwise been trying to  
prevent
being adopted as a WG draft?

How can this be the WG repeating itself on a decided issue, if the WG  
has not
yet acknowledged this in a WG document in the first place?

Obviously, it would be entirely unreasonable for someone to argue  
against
this document's adoption as a WG item while simultaneously using this  
same
document as an example of acknowledgement of decided WG issues not  
written
anywhere else, for that would be... well, hypocrisy.

L.

"Publishing recommendations without validating them isn't wasting  
time."?
DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

---

From: Joe Touch <[email-masked]>
Date: Fri, 03 Jul 2009 23:08:04 -0700

Lloyd Wood wrote:
> What, in the same individual ID you're spending so much energy suggesting
> shouldn't even exist, and which you're dismissing as implementation advice
> outside of the scope of the IETF and have otherwise been trying to prevent

draft-ietf-tcpm-icmp-attacks, not this one.

> yet acknowledged this in a WG document in the first place?

The WG acknowledged the icmp-attacks ID, not this one.

> Obviously, it would be entirely unreasonable for someone to argue against
> this document's adoption as a WG item while simultaneously using this same
> document as an example of acknowledgement of decided WG issues not written

If this document contained only information of decided WG issues,
including WG consensus on those issues, you would be correct. I have
pointed out several cases where that is not the case - and that has been
(and remains) my concern.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sat, 04 Jul 2009 03:51:55 -0100

Joe Touch wrote:

> including WG consensus on those issues, you would be correct.

A very large part of draft-gont-tcp-security is about stuff that has
never been discussed by this wg, but that you dismiss with arguments
such as "who TCP needs not be implemented in a secure way", etc.

Also, draft-gont-tcp-security is based on the idea of giving advice for
implementing TCP as good resiliency as possible. And one might argue
that this is a different context as that of draft-ietf-icmp-attacks,
which I guess that was meant for the general case ("general case"
probably being that case in which we are happy to be vulnerable to
obvious  and trivial attacks, I guess).

> I have pointed out several cases where that is not the case - and
> that has been (and remains) my concern.

The only case for which you raised this is for the ICMP attacks stuff. 
Will you support draft-gont-tcp-security if, say, I were to remove the 
entire ICMP section, or replace it with a summary of what's in
draft-ietf-icmp-attacks?

<sidetrack>
As for the ICMP stuff itself: there have been arguments against checking
  ICMPs to be "in window". However, I don't seem to recall people arguing
against the idea of "hard errors should be processes as soft errors when
received for connections in any of the synchronized states" (*this* is
what has been implemented in virtually all stacks for more than 20 years
as the main counter-measure for icmp-based reset attacks). Has anybody
argued against ignoring ICMP source quenches meant for TCP connections?
(this is the main countermeasure for source quench attacks, and what has
been implemented in most stacks). The "in-window" check is useful as a
mitigation technique for the PMTU counter-measure -- however, the one
described in the I-D is mainly based on the idea of "check for progress
on the connection", which I believe parallels the idea in PLPMTUD. --
and I don't recall people arguing against that idea, either.
Also, see the reviewers in the Acks of the I-D.. that's people from most
of the major TCP implementations. And the ideas in the I-D are the
running code we have and we use. However, we are so full of ourselves
that we tell implementers that the code they have implemented, which has
been running the Internet for the last 20 years or so, is "buggy",
backed on how we think the code should be (despite it doesn't run in
that way, and in some cases has not done it that way for ages (if it 
ever did)).

Want to now what the industry did in response? -- The have ignored our
consensus.
</sidetrack>

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 04 Jul 2009 04:07:12 -0100

> (and remains) my concern.

On April 13 
(http://www.ietf.org/mail-archive/web/tcpm/current/msg04501.html) you 
said: "Implementation advice is outside the scope of the IETF. It's not 
even operational, IMO.". i.e., you argued that we should *dismiss* this 
I-D (draft-gont-tcp-security).

So...if your opinion has now changed, and the only problem you have with 
this I-D is the section on "ICMP processing", would you support 
draft-gont-tcp-security (or at least not object its adoption as a wg 
item) were I to, e.g., remove the section on ICMP processing, replace it 
with a summary of what's in draft-ietf-icmp-attacks, or e.g., note that 
the provided advice is only for TCP implementations that desire good 
resiliency?

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Sat, 04 Jul 2009 09:20:06 -0700

Fernando Gont wrote:
...
...
> Has anybody

Source quenches were supposed to be deprecated a while back, but never
made it into a doc.

> The "in-window" check is useful as a

Ignoring certain ICMPs when the connection is continuing to make
progress might be reasonable.

However, this has *nothing* to do with checking the in-window of the
ICMP payload, which is inappropriate. As I and others have pointed out
many times, routers are not required to send ICMPs in a timely basis, so
there's no reason that an out-of-window ICMP should be treated any
differently from an in-window one.

> been running the Internet for the last 20 years or so, is "buggy",

OK, this is the sort of argument that holds no water. Convince us that
something is useful and correct. Pleaase cease claiming that
implementations define standards.

...
> Want to now what the industry did in response? -- The have ignored our

We need to continue to pull in the direction of standards, regardless of
what implementers do. If you care that much about the implementations,
then change them. It'd be more productive than simply documenting what
has been implemented instead.

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 04 Jul 2009 09:24:35 -0700

> I-D (draft-gont-tcp-security).

That's correct, but please re-read what I wrote above. The doc does not
contain only info the WG has consensus on.

> the provided advice is only for TCP implementations that desire good

It may be useful to explain how to efficiently implement reordering and
reassembly, but not in an RFC.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 4 Jul 2009 18:40:32 +0100

> implementations define standards.

It's rough consensus and running code, Joe.

(Who died and made you king?)

> what implementers do.

Well then, head on back to the happy perfect world of OSI, which  
implementers ignored.

> If you care that much about the implementations,

Implementation experience is an important input to developing and  
refining an IETF standard.

The IETF standard can't be defined wholly on paper theoretically de  
jure, or wholly
in implementations de facto. There's a meeting in the middle - hence  
consensus and code.

I know the M in TCP stands for minor, but really - why are we even  
bringing up standards arguments, when an informational doc would  
suffice?

L.

---

From: Joe Touch <[email-masked]>
Date: Sat, 04 Jul 2009 12:27:06 -0700

> It's rough consensus and running code, Joe.

It's rough consensus AND running code, Lloyd.

Running code isn't enough. Lots of running code doesn't define consensus.

> in implementations de facto. There's a meeting in the middle - hence

Please review sec 9.1 of the TAO of the IETF. The running code is to
prove that the standards are viable. It's the two together that are
meaningful. I.e., standards AND running code, not running code THEN
standards based on them.

> bringing up standards arguments, when an informational doc would suffice?

draft-gont-tcp-security reads like BCP, and recommends changes that
would require it to be standards-track.

Is informational the intended direction? Or BCP? Or changes to standards?

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 4 Jul 2009 21:36:57 +0100

On 4 Jul 2009, at 20:27, Joe Touch wrote:
>> jure, or wholly in implementations de facto. There's a meeting in  
>> the middle - hence
>> consensus and code.
>
> Please review sec 9.1 of the TAO of the IETF.

You might want to reread that. From section 9.1 of the Tao of the IETF:

'One of the oft-quoted tenets of the IETF is "running code wins"'

> The running code is to
> prove that the standards are viable.

No. 'One of the oft-quoted tenets of the IETF is "running code wins"'

The code is rather the _whole point_ of the exercise. No  
implementations,
no point.

> It's the two together that are

and not, as your 'change the implementations' line at top suggests,
standards THEN running code. It's a collaborative feedback loop,
not a one way process from document to code carried down the mountain
to the poor saps at the bottom.

Documenting what is implemented and used widely matters more than
standards that aren't implemented.

Running code wins.

> would require it to be standards-track.

It recommends changes only to what was previously documented,
which has long been superseded by implementations. Not to reality.
(I suggest informational as a workaround, so that the standards
wonks can continue to believe all is right in their world.)

Running code wins.

(If TCPM doesn't take on this work, then TCPM is irrelevant, and the
IETF likely abdicates any authority it had on TCP. Still, there's
always adding new stuff to SCTP, eh?)

L.

---

From: Joe Touch <[email-masked]>
Date: Sat, 04 Jul 2009 14:01:03 -0700

Lloyd Wood wrote:
>>> jure, or wholly in implementations de facto. There's a meeting in the
>>> middle - hence
>>> consensus and code.
>>

You need to quote the entire passage:

Implement -- Write programs that use the current Internet standards. The
standards aren't worth much unless they are available to Internet users.
Implement even the "minor" standards, since they will become less minor
if they appear in more software. Report any problems you find with the
standards to the appropriate Working Group so that the standard can be
clarified in later revisions. One of the oft-quoted tenets of the IETF
is "running code wins", so you can help support the standards you want
to become more widespread by creating more running code.

I.e., to support the standards, make running code. Notice it doesn't say
doing things the other way around.

...
> always adding new stuff to SCTP, eh?)

You're basically claiming that RFC2525 was a waste of time. I disagree.

The WG needs to decide what we want (consensus - which means my voice
counts as much as yours or Fernando's), and decide what position we
should take. No, I don't think TCPM's charter is to run around trying to
standardize or, worse, document without taking a stand, every place
where implementation differs from standard.

In 1999 we had a backbone and decided between deployey* bugs (per 2525)
and things we wanted to change that weren't deployed (e.g., the TOS bit,
which was changed in RFC2873). All I'm asking is that we do the same
now, not just claim that deployed code is the basis of an appropriate
position.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 4 Jul 2009 23:45:01 +0100

On 4 Jul 2009, at 22:01, Joe Touch wrote:
>>>> the

Quoting it at all rather misses the philosophical point that Tao can  
never
be adequately expressed in words, what? [section A.1 barely touches
on this paradox.]

> doing things the other way around.

It does: "Report any problems you find with the standards to the  
appropriate
Working Group so that the standard can be clarified in later revisions."

And those problems are found with the implementations.
The standard is not immutable. The standard is not set in stone.
The standard can be revised. (Much as the Tao of the IETF is
revised.) There's a feedback loop. And, in that loop,
running code wins.

(There's another argument on how the Tao is written for the  
inexperienced
in the IETF, and how citing it in the first place either indicates
inexperience, or that far too much faith is placed in the written word,
which is _so_ not Taoist, as noted above.

And, of course, the Tao is informational, and thus has no bearing on  
standards-
track docs, so a self-respecting standards wonk wouldn't use it in the  
first
place. Much less quote it. Quoting something that recognises that it
can't be encapsulated in words is really missing the point.

And, reflecting on the Tao, one can observe that the above paragraph  
sounds
awfully like the evangelism of Stallman's manifestos. Lots of do-this- 
for-us
imperatives. It's laying out the appropriate puritan work ethic to
be followed, which is certainly not Taoist. The document's a sham!)

> You're basically claiming that RFC2525 was a waste of time.

I claimed no such thing. (And in 1999, when RFC2525 was published, the  
IETF
was reaching its peak meeting attendance, indicating that it was more
relevant as an organisation And TCPM didn't yet exist.)

> I disagree.

You're disagreeing with a strawman position that you invented for me.

RFC2525 is informational, which is an approach that draft-gont could  
take.
The difference here is that we're documenting problems with the written
documentation, not with the implementations - i.e. the inverse of 2525.
The feedback loop also goes the other way. The aim is to keep documents
and code close together. Either can be changed. In this case, changing
the documentation to match widespread practice in a mature
protocol makes a lot of sense.

> counts as much as yours or Fernando's),

rough consensus, not vote counting. I think Fernando's voice, and his
experience in working with others to put together this and other  
documents
in the face of consistent opposition from you, speaks far louder than  
either
of our voices. He's far more credible than we are.

> and decide what position we

Surprised you didn't quote the charter here.

> which was changed in RFC2873). All I'm asking

Constantly using the imperative tense is not asking.

> is that we do the same

Deployed code is, at least, testable science.
A piece of a standard without code implementing that piece as  
specified is
merely religious dogma.
And yet you prefer the latter position?

(RFC2525 didn't touch on the TOS bits. False argument there.)

L.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 05 Jul 2009 07:30:30 -0300

Joe Touch wrote:

>> So...if your opinion has now changed, and the only problem you have
>> with this I-D is the section on "ICMP processing", would you
>> support draft-gont-tcp-security (or at least not object its
>> adoption as a wg item) were I to, e.g., remove the section on ICMP
>> processing, replace it with a summary of what's in
>> draft-ietf-icmp-attacks, or e.g., note that the provided advice is
>> only for TCP implementations that desire good resiliency?
> 
> It may be useful to explain how to efficiently implement reordering
> and reassembly, but not in an RFC.

Is this a joke?

RFC 816: "MODULARITY AND EFFICIENCY IN PROTOCOL IMPLEMENTATION"
RFC 815: "IP DATAGRAM REASSEMBLY ALGORITHMS" (see Section 4)

and,

RFC 1936: "Implementing the Internet Checksum in Hardware" (of which you
are on of the co-authors)

You argue against an I-D that gives implementation advice, yet you have
co-authored such an I-D? Should we take your opinion seriously?

Do you do this intentionally so that we waste cycles in these pointless
discussions instead of getting work done?

Sorry, but I will not play your game anymore.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Sun, 05 Jul 2009 21:51:38 -0700

> RFC 816: "MODULARITY AND EFFICIENCY IN PROTOCOL IMPLEMENTATION"

That's 817, FWIW.

> co-authored such an I-D? Should we take your opinion seriously?

I didn't give advice, I gave an example, as do many RFCs. I don't agree
that efficiency is an appropriate focus of an RFC, and no, that doesn't
stop them from being written by others. There is a difference which is
relevant to some (granted, not all) recommendations in this document.

It is important to deciding whether you're describing (informationally)
or recommending (BCP-ish).

Joe

---

From: Joe Touch <[email-masked]>
Date: Sun, 05 Jul 2009 22:05:59 -0700

Lloyd Wood wrote:
> Quoting it at all rather misses the philosophical point that Tao can never

So you complain when I quote it in its entirety, but respond by further
quoting it out of context?

> Working Group so that the standard can be clarified in later revisions."

Clarifying a standard is what happens when the standard has an
ambiguity. Problems you find can be found in many ways.

None of that says "change the standards to match implementations". None
of that says that "code wins over standards".

> And those problems are found with the implementations.

That's one of many ways problems have been found.

> revised.) There's a feedback loop. And, in that loop,

Please re-read the paragraph above. It says to write code to support the
standards you want to become more widespread, not to write code to
support changes to the standard that you want to them justify as
evidence that the standard should be changed.

...
> I claimed no such thing. (And in 1999, when RFC2525 was published, the IETF
> RFC2525 is informational, which is an approach that draft-gont could take.

2525 doesn't need to be more than informational; it didn't change the
standards (it reiterated them, essentially). Straying from the standard
means either standards track (to change the standard) or BCP (to explain
ways to apply SHOULDs/alternates in the standard to an environment). And
2525 talks about how implementations vary from the standard, not
implementation issues that a standard never addresses (nor should it).

...
> Surprised you didn't quote the charter here.

I'll wait for you to show me where in the charter it explains that we're
here to document and standardize implementations, rather than to decide
what's better for the future of TCP.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 6 Jul 2009 06:59:48 +0100

> what's better for the future of TCP.

The future of TCP only becomes real when implemented.

If you ignore implementations, you have no business "deciding the  
future of TCP".

Implementers detect pomposity, and route around it.

L.

---

From: Andrew Yourtchenko <[email-masked]>
Date: Mon, 6 Jul 2009 18:31:04 +0200 (CEST)

On Wed, 24 Jun 2009, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:

> TCPMers, there was a thread a while ago about working on
> draft-gont-tcp-security in this working group that didn't
> conclusively give us a feeling one way or other:
> http://www.ietf.org/mail-archive/web/tcpm/current/msg04489.html
>
> Basically, my understanding is that there are at least a
> handful of people in the WG that think it should be done
> here as a WG item (more likely for Informational rather
> than BCP), and there are also some expressed opinions on
> why it shouldn't.
>
> Given the raw size of the document, if the WG intends to
> take this document on, then we need some people to clearly
> commit to putting cycles into review and contributions to
> the document.  Since it is quite large, and to my knowledge,
> there hasn't been a specific technical review of the content
> on this list, but just discussions about if the idea in
> general is a good or bad thing, we still need to know if
> people are willing to invest their time and energy in this.

I think the further development of this document with the balanced 
approach (cf: 'the requirements' mention and evaluating the mitigations 
with respect to them) is a useful activity, and as such, would like to 
commit cycles to it if it gets adopted.

thanks,
andrew

>
> Please let us know if there is traction for this in the
> near term, and/or we can also discuss it in Stockholm.
>
> ---------------------------
> Wes Eddy
> Network & Systems Architect
> Verizon FNS / NASA GRC
> Office: (216) 433-6682
> ---------------------------
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 15 Jul 2009 13:44:09 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Andrew Yourtchenko
> Sent: Monday, July 06, 2009 9:31 AM
> To: Eddy, Wesley M. (GRC-MS00)[Verizon]
> Cc: tcpm Extensions WG
> Subject: Re: [tcpm] poll for adopting draft-gont-tcp-security
> 
> 
> 

Agreed.  And I will contribute cycles as well.

-d

---

From: David Borman <[email-masked]>
Date: Thu, 30 Jul 2009 14:46:31 +0200

Based on the response to this poll, and the subsequent discussion at  
the IETF meeting this week, there is clear consensus to take this on  
as a WG item.  We will be kicking off various discussions in separate  
messages to the TCPM list.

	-David Borman & Wes Eddy, TCPM co-chairs