Subject: [tcpm] Hat off: tcpsecure mitigations

From: Ted Faber <[email-masked]>
Date: Thu, 15 Mar 2007 18:18:22 -0700

Hi.

I recently did a read-through of the tcpsecure draft to see how close it
was to a WGLC, and came across an issue I'd like to put before the
group.  I'm doing this without a chair hat on, just as a private
individual.

Looking over the 3 mitigations proposed in that draft, I think that the
first two, the SYN and RST mitigations, are clean and elegant. I'm
perfectly happy to publish a draft saying that TCP implementations
SHOULD implement them.

The data injection mitigation doesn't have the same cleanness to it, and
I'd like to make that mitigation a MAY.

Here's my thinking:
	
	The SYN and RST changes are simple and clear and require minimal
	new code to implement.  A host simply accepts the segment if its
	SEG.SEQ is the same as RCV.NXT and ACKs it otherwise.  No extra
	space in the control block, minimal places to go astray and a
	significant improvement in the protection afforded against
	malicious and misbehaving stacks - the spoofable range of seqnos
	drops from the size of the receive window to 1.

	The data mitigation is more complex - there's an extra state
	variable defined to check the ACK value of each received segment -
	and there's some room to go astray in the implementation of that
	state variable.  I don't begrudge an implementation the extra
	word in the data structure, but it's an indication that this
	mitigation doesn't have the same simplicity as the RST and SYN
	mitigations.

	Furthermore, the mitigation is less effective.  If there is
	significant bi-directional traffic on the connection there will
	be basically no mitigation.  My understanding is that the
	connections most vulnerable to these attacks are long-standing
	connections that have large windows - exactly the ones that will
	receive the least effect from this mitigation.

	I'm not suggesting we discard the mitigation, but because a
	developer might think, IMHO rightly, that the additional
	complexity is not worth the additional protection, I think we
	should give that developer an out by making this mitigation
	OPTIONAL.

I've talked to the authors about this, so I'm not trying to surprise
them while they're on the plane.  I'm sure they'll jump in and discuss.
I'm hoping to get a discussion going here and possibly in Prague about
how strongly we want to recommend the data mitigation.  I believe their
presentation will raise some of these points and their responses.

Thanks.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Fri, 16 Mar 2007 11:58:50 -0700

Ted,
   Thanks for the note. Comments inline..

> Hi.
> 
> I recently did a read-through of the tcpsecure draft to see 
> how close it was to a WGLC, and came across an issue I'd like 
> to put before the group.  I'm doing this without a chair hat 
> on, just as a private individual.
> 
> Looking over the 3 mitigations proposed in that draft, I 
> think that the first two, the SYN and RST mitigations, are 
> clean and elegant. I'm perfectly happy to publish a draft 
> saying that TCP implementations SHOULD implement them.

I would like to add more context to the discussion. Lets start from
here..

All these mitigations were tagged with a MUST clause until recently, but
since you had raised a valid point to say something like "we don't want
the TCP stacks to become all of a sudden non-compliant after this goes
out as an RFC", we changed all the mitigations to SHOULD.

> 
> The data injection mitigation doesn't have the same cleanness 
> to it, and I'd like to make that mitigation a MAY.

- By making it a SHOULD we have already given leeway to the
implementers. Implementere who care for security/robustness of their
systems would treat it as important and will use it.  

> 	mitigation doesn't have the same simplicity as the RST and SYN

Well, not all solutions to all problems are necessarily simple and the
degree of complexity varies. Well, if I read your comments more
seriously, one can imagine there would mostly be MAYs in many RFC's
since the solution isn't simple enough. :-)

In the current case it is about having one variable, namely MAX.SNDWND.
Just to give an example on how simple and effective this is :
Implementations can chose to hardcode this value to 65535 for a
connection ( assuming no window scaling in place) The ACK check would
simply become :

(SND.UNA - 65535) <= SEG.ACK <= SND.NXT).  

> 	receive the least effect from this mitigation.

The mitigation is direction independent by the virtue of the fact the
way ACK checking is, as existing, today. Only thing is we are putting a
sensible limit on the acceptable ACK value rather than accept anything
and everything. if you are saying the above to mean " the attack would
be difficult to perform in case of bi-directional", maybe. As a
generalisation, if the TCP connection is idle, any attacks described in
the document is easier to perform compared to uni-directional compared
to bi-directional....

Another important thing is this mitigation also raises the bar on
malicious (bad) FIN's that can be injected [ the Ack checking helps]
During the initial stages (about couple of years back ) when this was
discussed somebody in the list someone did ask about the "FIN attacks"
and how this mitigation can come handy in dealing with the same.

<snip>

> I've talked to the authors about this, so I'm not trying to 
> surprise them while they're on the plane.  I'm sure they'll 
> jump in and discuss.
> I'm hoping to get a discussion going here and possibly in 
> Prague about how strongly we want to recommend the data 
> mitigation.  I believe their presentation will raise some of 
> these points and their responses.

Sure, sounds like a plan. 

-Anantha

---

From: Ted Faber <[email-masked]>
Date: Mon, 19 Mar 2007 14:00:38 -0700

> systems would treat it as important and will use it.  

SHOULD implies that an implementor should have a good reason not to do
something.  I think the data mitigation is enough extra work for little
enough extra protection that an implementor should implement it if they
feel it's necessary - they MAY implement it if they choose.  I realize I
may be alone in this belief and that's fine.

> since the solution isn't simple enough. :-)

Ha ha.

> (SND.UNA - 65535) <= SEG.ACK <= SND.NXT). 

We talked a little about this off-line, but I'm not sure where that 64K
number comes from.  The draft talks about this check already being part
of the TCP spec in Section 5.1, or I'm misunderstanding that section,
but I don't see any basis for that.  Skimming the FreeBSD code (because
it's right here) I don't see any such check.  I do realize that there
ought to be a lower bound on what an acceptable ACK is (because the ACK
space wraps and you'll seventually come around to SND.NXT from the
bottom) but I don't see this number in the specs.

Is the existing specification actually clear on this?  Are you modifying
an existing limit or introducing a new check?

> the document is easier to perform compared to uni-directional compared

If you put the mitigation in place, an endpoint that is primarily going
to send traffic can set its receive window to be very small from the
initial SYN - 1 byte to allow the FIN - and this mitigation will be its
most effective.  The set of acceptable ACK values goes down from
whatever the default is to 1 acceptable ACK value.  Unidirectional
traffic is your best reasonable case in the sense of greatest
protection.  (Optimal would be both sides with a 1 byte window, but
that's obviously pathological.)

Conversely, bidirectional traffic with sizable windows is the worst case
for the mitigation, because both endpoints will advertise large windows
at some point (and you use the maximum advertised window in your
calculations) so your mitigation will provide the least protection in
the sense that the largest number of spoofed ACK values will pass the
test.

> and how this mitigation can come handy in dealing with the same.

I'd add text to the draft to that effect.

---

From: Joe Touch <[email-masked]>
Date: Mon, 19 Mar 2007 22:14:00 -0700

Ted Faber wrote:
> something. 

I agree with MAY for these recommendations as-is.

SHOULD, in many cases (not just this) needs to come with the conditions,
as noted above. In this particular case:

	routers and proxy systems SHOULD implement these mods for
	their host-based TCP
	(orgination/termination)

	all other hosts MAY implement them

> I think the data mitigation is enough extra work for little

I agree with MAY for those. That's also why I think 'all other hosts'
(sans routers/proxy systems) should have a MAY too; there's far too
little additional protection for typical hosts, and we really don't need
to make the required constellation of TCP more complex than absolutely
necessary.

However, I think this doc also needs a strong "if you're really
concerned about protection, or have seen repeated attempts at attacks,
you really ought to use real security" too.

(sorry if it does already say that; I haven't gone through it in detail).

Joe

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Tue, 20 Mar 2007 07:49:40 -0700

<snip>

> SHOULD implies that an implementor should have a good reason 
> not to do something.  I think the data mitigation is enough 

"good reason", Let me try :-), if someone says "hey I don't care about
extra robustness which offers additional protection in some cases than
what it is existing today ", they can chose to not follow this
recommendation or any other recommendations in the draft. My experience
suggests that these days "people" are concerned about "extra robustness
a.k.a security" in most of the cases. That said, YMMV.

> extra work for little enough extra protection that an 

"enough extra work" is a relative term. Data mitigation requires that :-

#1 Keep an extra variable in the TCB in it's strictest form, in a
slightly stricter version one can avoid this step and simply use a
hardcoded value. So minimal OR no changes to the TCB.

#2 The check for acceptability of ACK segments has been made more
"stricter"

Now the real extra work seems to be is #2. 

> implementor should implement it if they feel it's necessary - 
> they MAY implement it if they choose.  I realize I may be 
> alone in this belief and that's fine.

Well these arguments are true for any mitigation irrespective of its
complexity involved in implementation and that is my point. Just because
one mitigation requires some extra state to be maintained doesn't
necessarily mean it needs to fall under the "MAY" umbrella.

<snip>

> We talked a little about this off-line, but I'm not sure 
> where that 64K number comes from.  The draft talks about this 

64K is a simplified example I gave in response to the "memory concerns"
which you raised for maintaining the extra variable MAX.SNDWND in the
TCB. 

> check already being part of the TCP spec in Section 5.1, or 

Pl see below.

> I'm misunderstanding that section, but I don't see any basis 
> for that.  Skimming the FreeBSD code (because it's right 
> here) I don't see any such check.  I do realize that there 
> ought to be a lower bound on what an acceptable ACK is 
> (because the ACK space wraps and you'll seventually come 
> around to SND.NXT from the
> Is the existing specification actually clear on this?  Are 

It is implicit. First let me quote this section :

Sec 3.2: [sequence numbers]

" It is essential to remember that the actual sequence number space is
  finite, though very large.  This space ranges from 0 to 2**32 - 1.
  Since the space is finite, all arithmetic dealing with sequence
  numbers must be performed modulo 2**32.  This unsigned arithmetic
  preserves the relationship of sequence numbers as they cycle from
  2**32 - 1 to 0 again.  There are some subtleties to computer modulo
  arithmetic, so great care should be taken in programming the
  comparison of such values.  The symbol "=<" means "less than or equal"
  (modulo 2**32)."    -------------------------------  (1)

Now the event processing section (3.9) says :
          If the ACK is a duplicate
          (SEG.ACK < SND.UNA), it can be ignored.  If the ACK acks
          something not yet sent (SEG.ACK > SND.NXT) then send an ACK,
          drop the segment, and return.

(This check holds good for ESTAB state onwards). So the RFC is
*explicit* about the SEG.ACK < SND.UNA, just ignore it, now using modulo
arithmetic (1) this means that any number in the seq space ie., (SND.UNA
- 2^^31 -1) would pass this ACK test. This is what sec 5.1 in TCP secure
mentions. 

May be it is a good idea to elaborate this fact?

> you modifying an existing limit or introducing a new check?

Modiying the existing limit, pl see above.

> > way ACK checking is, as existing, today. Only thing is we 
> are putting 
> > a sensible limit on the acceptable ACK value rather than accept 
> > anything and everything. if you are saying the above to mean " the 
> > attack would be difficult to perform in case of bi-directional", 
> > maybe. As a generalisation, if the TCP connection is idle, 
> any attacks 
> > described in the document is easier to perform compared to 
> > uni-directional compared to bi-directional....
> 
> If you put the mitigation in place, an endpoint that is 
> primarily going to send traffic can set its receive window to 
> be very small from the initial SYN - 1 byte to allow the FIN 
> - and this mitigation will be its most effective.  The set of 
> acceptable ACK values goes down from whatever the default is 
> to 1 acceptable ACK value.  Unidirectional traffic is your 
> best reasonable case in the sense of greatest protection.  
> (Optimal would be both sides with a 1 byte window, but that's 
> obviously pathological.)

Well, agreed.

> 
> Conversely, bidirectional traffic with sizable windows is the 
> worst case for the mitigation, because both endpoints will 
> advertise large windows at some point (and you use the 
> maximum advertised window in your
> calculations) so your mitigation will provide the least 
> protection in the sense that the largest number of spoofed 
> ACK values will pass the test.

Yep, but better than what it is today :-) See above.

> I'd add text to the draft to that effect.

Sure will do. Actually thinking more about it is indeed important since
this kind of raises the bar on FIN attacks. Will mention that. I had
this in mind but somehow this missed the earlier versions but glad that
we are able to correct that.

Thanks,
-Anantha
<snip>

---

From: "Mitesh Dalal \(mdalal\)" <[email-masked]>
Date: Tue, 20 Mar 2007 09:39:32 -0700

please see inline.

> -----Original Message-----
> From: Joe Touch [mailto:[email-masked]] 
> Sent: Monday, March 19, 2007 10:14 PM
> To: Ted Faber
> Cc: [email-masked]; Anantha Ramaiah (ananth)
> Subject: Re: [tcpm] Hat off: tcpsecure mitigations
> 
> 
> 
> Ted Faber wrote:
> >>> The data injection mitigation doesn't have the same 
> cleanness to it, 
> >>> and I'd like to make that mitigation a MAY.
> SHOULD, in many cases (not just this) needs to come with the 
> conditions, as noted above. In this particular case:
> 

I would tend to avoid recommendations based on system role to 
determine MAY/SHOULD language. Since the weakness lies in the
protocol we should make a recommendation one way or the other.
If we are confident that this draft will help routers and
proxies, leaving end hosts behind does not buy us much.
(not that a SHOULD recommendation not implemented by endhost
vendors will cause them to be out of spec)

Mitesh

> > I think the data mitigation is enough extra work for little enough 
> > extra protection that an implementor should implement it if 
> they feel 
> > it's necessary - they MAY implement it if they choose.  I realize I 
> (sans routers/proxy systems) should have a MAY too; there's 
> far too little additional protection for typical hosts, and 
> we really don't need to make the required constellation of 
> TCP more complex than absolutely necessary.
> 
> However, I think this doc also needs a strong "if you're 
> really concerned about protection, or have seen repeated 
> attempts at attacks, you really ought to use real security" too.
>

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Mar 2007 09:49:05 -0700

> protocol we should make a recommendation one way or the other.

The weakness lies in the combination of the protocol, the context of its
use, and the fact that real authentication isn't being used.

> proxies, leaving end hosts behind does not buy us much.

It allows them not to need unnecessarily complexity.

> vendors will cause them to be out of spec)

If that's really your position, then it needs to be stated. SHOULD, by
itself, doesn't carry that sort of information. As Ted(hat-off) noted,
SHOULD needs to indicate where it's allowed to be waived, and that
indication needs to be explicit. By stating this as MUST for
routers/proxy-systems and MAY for hosts, we'd be doing exactly what's
needed for that to happen.

Joe

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 20 Mar 2007 13:10:18 -0400

> (sorry if it does already say that; I haven't gone through it in detail).

I share this general concern, but I think that version 07 of the
document is _probably_ alright in this respect.  It at least minimally
contains a reference to the antispoof draft at the end of the
introduction section and some recognition in the security considerations
that there are other attacks that the tcpsecure document doesn't
address.

The only (very small) change I would suggest to help in this regard is
that the "abbreviated title" that appears on the top of each page
shouldn't be "TCP Security", as this is WAY more general than what the
draft actually discusses.  I think this might have been overlooked when
the actual title of the draft changed.  (If using xml2rfc, this is as
easy as tweaking the abbrev attribute in the title tag.)

-- 
Wesley M. Eddy
Verizon Federal Network Systems
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Mark Allman <[email-masked]>
Date: Tue, 20 Mar 2007 13:26:31 -0400

Folks-

I wanted to clarify my point on IPR that was relayed to the meeting
today.  

Lars brought up IPR in the context of tcpsecure in the meeting after a
side jabber between us.  Anantha noted that we have had the IPR
discussion.  I do not want to open up the IPR discussion as we have
certainly decided to work on this and standardize in the face of the IPR
statement from Cisco.  That said, IPR can influence how strongly we say
hosts should use this technique.  

For instance, my personal feeling (WG chair hat off) is that we should
not standardize something as a MUST in the face of an IPR statement (no
matter how benign we believe the IPR statement is).  That is, I do not
think someone should be considered non-compliant because they choose to
not use IPRed techniques.

So, I do not want to open the entire discussion about IPR again.  That
said, I do not want it to completely fall off our radar, either.

allman

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Mar 2007 16:36:50 -0300

>that there are other attacks that the tcpsecure document doesn't

I think a reference to the icmp attacks draft is missing (as Joe 
pointed out some months ago). Also, it would probably be a good idea 
to link draft-larsen-tsvwg-port-randomization, as it requires more 
work on the side of the attacker for performing any "blind" attack against TCP.

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

---

From: Ted Faber <[email-masked]>
Date: Tue, 20 Mar 2007 15:50:09 -0700

On Tue, Mar 20, 2007 at 09:39:32AM -0700, Mitesh Dalal (mdalal) wrote:
> determine MAY/SHOULD language. 

I agree with Mitesh here.  I don't want to split that hair.  

>                                Since the weakness lies in the

I'm not sure what that means.

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Mar 2007 16:31:26 -0700

> I agree with Mitesh here.  I don't want to split that hair.

Either SHOULD should be qualified somehow - when running a well-known
service where both ends are likely to be known, e.g., BGP, or MAY is
more appropriate.

Otherwise you're recommending a SHOULD to protect everyone from an
attack only a subset of Internet hosts are susceptible to. The threat
isn't large enough to warrant that, and this is not required for correct
operation. Short of widescale necessity or required correctness, MAY
seems the most appropriate choice.

IMO, this is further underscored by the intellectual property issue.

> I'm not sure what that means.

This is the problem.SHOULD not implemented needs to come with a reason.
If we know that reason now - e.g., a host that isn't running a
well-known service with both endpoints likely known - then we ought to
state it as a known exception.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Mar 2007 17:02:34 -0700

Joe Touch wrote:
...
> state it as a known exception.

PS - let me give a more specific equivalent:

	All TCP implementations SHOULD implement TCP/MD5.

There's a cost, and not all TCPs are under threat, so we don't require
that. The cost of this is lower, but still there in terms of
specification complexity, and the impact on additional messages on
correctly operating TCPs that issue RSTs during a data transfer. It
needs a similar MAY or "SHOULD IF" clause, but not an unrestricted SHOULD.

Joe

---

From: Ted Faber <[email-masked]>
Date: Tue, 20 Mar 2007 18:30:05 -0700

> seems the most appropriate choice.

We simply disagree.  To me, the RST/SYN mitigations are a small enough
change with no significant downside.  I don't think that the problem
that they're defending against is earth-shattering, but a significant
mitigation is so simple and and cheap that I'm quite comfortable with a
SHOULD.

I'm curious what others think.

---

From: Ted Faber <[email-masked]>
Date: Tue, 20 Mar 2007 18:37:39 -0700

> 	All TCP implementations SHOULD implement TCP/MD5.

I would argue against such a suggestion on the basis that the complexity
and overhead of TCP/MD5 are significant and most hosts are not menaced by
the attacks this heavy-weight protection prevents.  The off-path RST and
SYN mitigations are so simple and inexpensive that I'm comfortable with
a SHOULD.

Most hosts don't need TIME-WAIT, either, but for most hosts it's
inexpensive.

---

From: Joe Touch <[email-masked]>
Date: Tue, 20 Mar 2007 23:48:34 -0700

> Most hosts don't need TIME-WAIT, either, but for most hosts it's

TIME-WAIT is required for correct, safe operation between two endpoints.

This solution sacrifices good protocol design (never respond to a RST,
in specific, and 'keep it simple' in general) in an attempt to provide
protection from deliberate attacks, protection that is already
sufficient unless both endpoint addresses and a port number is known,
and protection that's insufficient against data injection in-window, as
well as ICMP attacks that can shut a connection just as easily (and
CANNOT need to be in-window, since there are no timing requirements for
ICMP responses).

It's not required for correct operation, and it's not sufficient for
safe operation. And its encumbered.

A SHOULD would burden implementers with needing to justify why their
TCPs did not support this requirement, and avoiding encumberence may not
be sufficient.

This may be simple, but its expense is in the eye of the implementer.

For all these reasons, a MAY is appropriate, but a SHOULD is not.

Joe

---

From: Ted Faber <[email-masked]>
Date: Wed, 21 Mar 2007 11:37:24 -0700

> TIME-WAIT is required for correct, safe operation between two endpoints.

Are *we* really going to argue about TIME-WAIT?

You know that the "correct operation" "guaranteed" by TIME-WAIT is only
exercised upon the occurrance of a very unlikely set of events (delayed
packets from an old connection arriving at a new connection between the
same TCP socket (4-tuple) in an overlapping sequence number window) and
that the "guarantee" entirely depends on an MSL parameter that's
unenforced by the network and set at the whim of sysadmins.  I know you
know that because we've beaten it to death and then published about it.

TIME-WAIT guards against an unlikely occurance by assertation of
correctness.

> protection from deliberate attacks

It also defends against a delayed RST in the same case TIME-WAIT
protects against in the event that TIME-WAIT's "guarantee" wasn't met
because of a misconfigured local value for MSL.

>                                     protection that is already

And it costs about 6 machine instructions to implement without breaking
any existing TCP implementations.  I'm quite delighted to SHOULD it
based on technical merit.

> safe operation. And its encumbered.

Now encumberance is a better argument.

> For all these reasons, a MAY is appropriate, but a SHOULD is not.

I disagree with "all," but I may be swayable based on IPR.

Can we get a ruling from the non-arguing chair about whether IPR is on
the table for the discussion of the SHOULD/MAY issue?

---

From: Mark Allman <[email-masked]>
Date: Wed, 21 Mar 2007 15:50:19 -0400

The subject still contains 'hat off', but I am wearing my co-chair hat
for this note.

> the table for the discussion of the SHOULD/MAY issue?

I will just re-iterate what I said yesterday.  The presence of an IPR
statement can absolutely be used to inform decisions of the WG.

In particular, the WG is well within its rights to use Cisco's
IPR statement on tcpsecure as part of the process of deciding that the
mechanisms contained in that draft ought to be MAY, SHOULD or MUSTs.

The IPR statement is *one* piece of information that can be used in the
decision process.  There are other factors that can also be brought to
bear on the decision: importance of the mitigation, completeness of
solution, complexity of the solution, etc.

Finally, we do not need one answer for the entire draft, but can have an
answer for each mechanism in the draft.

I would also invite other people to weigh in on this topic.  How
strongly should we specify these mechanisms?  MUST?  SHOULD?  MAY?  I
don't yet feel like I really have a sense of the WG's feelings on this
matter, so please send your opinions.

Thanks,
allman

---

From: Ethan Blanton <[email-masked]>
Date: Thu, 22 Mar 2007 13:06:46 -0400

> statement can absolutely be used to inform decisions of the WG.

[snip]

> matter, so please send your opinions.

I feel strongly that IPR-encumbered algorithms MUST NOT be specified
with a MUST.  Furthermore, I feel that they SHOULD NOT be specified
with a SHOULD.  I would be more inclined to support the
standardization of a new protocol with IPR-encumbered portions as
SHOULD, than to introduce IPR-encumbered mechanisms to an established
and absolutely essential protocol such as TCP and categorize them as
SHOULD.

In this specific instance, I do not believe that any of these
mitigations are sufficiently criticial to justify an IPR-encumbered
SHOULD for the TCP protocol.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 Mar 2007 19:28:10 +0200 (EET)

> matter, so please send your opinions.

There are two different ways to use uppercase keywords.

1) a compliant TCP implementation MUST/SHOULD/MAY ...
2) a TCP implementation complying to this specification 
MUST/SHOULD/MAY ..

IMHO, a document cannot do 1) unless it also Updates or Obsoletes 
RFC793, RFC1122, and/or RFC1812 (as applicable).  Tcpsecure currently 
does not.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Wesley Eddy <[email-masked]>
Date: Thu, 22 Mar 2007 13:44:37 -0400

> RFC793, RFC1122, and/or RFC1812 (as applicable).  Tcpsecure currently 

Should it?  It does alter the state machine in 793, doesn't it?

---

From: Mark Allman <[email-masked]>
Date: Thu, 22 Mar 2007 15:14:50 -0400

> > RFC793, RFC1122, and/or RFC1812 (as applicable).  Tcpsecure
> > currently does not.
> 

I have assumed the WG is OK with an 'update' because I assumed that was
a foregone conclusion of putting this on the standards track.  So, if
this is going to be a bone of contention somehow then please discuss.

(The comment that "tcpsecure currently does not [update previous RFCs]"
is pretty mysterious to me.)

allman

---

From: Fernando Gont <[email-masked]>
Date: Thu, 22 Mar 2007 16:39:58 -0300

>SHOULD for the TCP protocol.

FWIW, I fully agree with Ethan's view.

Kindest regards,

---

From: Pekka Savola <[email-masked]>
Date: Fri, 23 Mar 2007 01:37:55 +0200 (EET)

> is pretty mysterious to me.)

What a compliant TCP implementation must implement is AFAICS defined 
by RFCs 793, 1122 and 1812 *).  Even though there have been dozens of 
TCP-related RFCs published, I do not think they change what is 
required of a 'compliant TCP implementation' and should be treated as 
TCP extensions, not required for TCP compliance.

*) as potentially modified by RFCs that Update any of these RFCs, as 
shown from the RFC index.

...

Now,

If you want to formally announce that this document updates the TCP 
state diagram in a normative fashion and that every TCP implementor 
should implement it, it needs to be clearly marked in the document.

Procedurally such a marking has been "Updates: xxxx' in the draft 
header as well as a statement like 'This document updates RFC xxxx' in 
the abstract and the implementation.  (This will also result in adding 
forward references under RFC 793 or similar to this draft in the RFC 
index.)

If such marking is not is not employed, this document should IMHO be 
treated as specifying TCP-secure ("a new variant of TCP") rather than 
modifying TCP (and what a compliant TCP implementation should do).

---

From: Joe Touch <[email-masked]>
Date: Thu, 22 Mar 2007 16:52:59 -0700

Pekka Savola wrote:
> What a compliant TCP implementation must implement is AFAICS defined by
> RFCs 793, 1122 and 1812 *).  Even though there have been dozens of
> TCP-related RFCs published, I do not think they change what is required
> of a 'compliant TCP implementation' and should be treated as TCP
> extensions, not required for TCP compliance.

The TCP roadmap says otherwise (RFC4614). That requires, for IPv4:

793
1122
2581 (cong ctl)
2873 (precedence bit redefinition)
2988 (rexmit timer)

and recommends (which I don't see as extensions, but rather strong SHOULDs):

1323 (high perf)
3168 (ECN)
3042 (limited rexmit)
3390 (big init win)
3782 (newreno recovery)
2018 (SACK)
2883 (SACK extensions)
3517 (conservative SACK loss recovery)

Also, 1948 (ISN randomization) is described as mostly deployed, even
though it's informational, and 2385 (TCP/MD5) is described as used
mostly in routers.

IMO, that's precisely where this draft belongs by analogy - as either an
informational that's described as deployed in many places, or as a
standards track that has a **context** in which it should be deployed
for safety.

> should implement it, it needs to be clearly marked in the document.

Of the above, ONLY RFC3168 (ECN) is listed as such in its header OR in
rfc-index.txt

> Procedurally such a marking has been "Updates: xxxx' in the draft header
> as well as a statement like 'This document updates RFC xxxx' in the
> abstract and the implementation.  (This will also result in adding

The two are not necessarily linked strongly, at least as far as the
difference between the recommendations in RFC4614 and rfc-index suggests.

Joe

---

From: Mark Allman <[email-masked]>
Date: Thu, 22 Mar 2007 23:15:26 -0400

> by RFCs 793, 1122 and 1812 *).  Even though there have been dozens
> of TCP-related RFCs published, I do not think they change what is
> required of a 'compliant TCP implementation' and should be treated
> as TCP extensions, not required for TCP compliance.

My reading is actually quite different.  My reading is that we do a
lousy job of tracking what updates (etc.) older RFCs.  E.g., 2581 and
2988, IMO, are *the* way to do congestion control and RTO timers
respectively, rather than the older documents.  Yet, these documents are
not listed as updating or obsoleting anything [*].  I think the roadmap
makes this sort of thing clear, even though we have done a pretty lousy
job of codifying it in the RFC index.  (And, in fact, something like the
roadmap map is probably the way to keep all of this straight because
simply giving some quick blurb like 'XXXX updates 1122' can border on
useless.  I.e., without saying *what* is updated in something like 1122
the notion that something is updating it is kind of pointless.

The bottom line to me is that if we put the tcpsecure mods (or anything
else) on the standards track and call them MUSTs or SHOULDs then it is
my opinion that we have updated the previous document's advice /
mandates.

allman

[*] RFC 2581 does obsolete RFC 2001.  But, that was just a previous rev
    of the document.  RFC 2001 does not update/obsolete anything.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 23 Mar 2007 10:21:54 +0200 (EET)

> The TCP roadmap says otherwise (RFC4614). That requires, for IPv4:

Whether the TCP roadmap says anything on this may or may not apply; 
it's an _Informative_ RFC, providing a non-normative context to the 
dozens of TCP-related RFCs out there.  A reading list in a way.  But I 
don't think an Informative document can specify what a compliant TCP 
implementation is or isn't.

If the roadmap had been on Standards Track, properly vetted by the 
rest of the IETF, etc. I would agree with you that it could 
normatively specificy what a compliant TCP implementation must or must 
not implement.

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Mar 2007 01:27:49 -0700

Pekka Savola wrote:
> Whether the TCP roadmap says anything on this may or may not apply; it's
> an _Informative_ RFC, providing a non-normative context to the dozens of
> TCP-related RFCs out there.  A reading list in a way.  But I don't think
> an Informative document can specify what a compliant TCP implementation
> is or isn't.
> 
> If the roadmap had been on Standards Track, properly vetted by the rest
> of the IETF, etc. I would agree with you that it could normatively
> specificy what a compliant TCP implementation must or must not implement.

The docs therein are standards track. I don't know exactly what it means
to be standards track as a *change* to TCP's operation and be optional.

IMO, it can only mean that these mods have an odd meaning to MUST/SHOULD
- they are MUST only as far as "if you do this doc, then you MUST do the
MUSTs, you SHOULD do the SHOULDs, etc." - but the entire set, standards
track or not, is take-it-or-leave-it.

That's very strange w.r.t. RFC2119; it would be better to be explicit
about this issue in the doc itself.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Fri, 23 Mar 2007 09:33:00 +0100

On 2007-3-23, at 9:21, ext Pekka Savola wrote:
> dozens of TCP-related RFCs out there.  A reading list in a way.   
> But I don't think an Informative document can specify what a  
> compliant TCP implementation is or isn't.

I was going to make the same comment. A standards-level  
recommendation is the only thing that can define what subset of RFCs  
TCP implementors MUST implement.

Now that we have the roadmap, the WG could discuss publishing a brief  
standards-level document that codifies the MUSTs and SHOULDs and  
informatively points to RFC4614 for the rationale of the standards- 
level recommendations.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 26 Mar 2007 10:04:54 +0200

> to be standards track as a *change* to TCP's operation and be  

A TCP extension can be on the standards track but OPTIONAL to  
implement, for example. The levels of the standards track express a  
level of technical maturity, but don't correlate to which protocol  
mechanisms are REQUIRED/RECOMMENDED/OPTIONAL to implement. For  
example, RFC793, which is a full standard, contains MAYs and SHOULDs  
that implementations need not implement. RFC2581, which is at PS,  
likewise contains MUSTs, SHOULDs, and MAYs.

Just because we publish something on the standards track doesn't mean  
all TCPs need to implement all the MUSTs. Documents need to come with  
a clause that states whether they are a must-implement for a  
standards-compliant TCP or not. (Example: If we were to publish UTO  
as PS - which we aren't - it would probably need to say: "the UTO  
mechanism is OPTIONAL to implement for a standards-compliant TCP.")  
You can view the classification in the roadmap as making such  
statements about existing TCP RFCs retroactively, because many don't  
include such clauses.

This is all a big mess. The roadmap tells implementors of which RFCs  
they must implement the MUSTs, should implement the SHOULDs, etc., to  
implement "the TCP standards", but the RFCs that contain these  
mechanisms are all at different levels of the standards track.  
Because the roadmap is informational, that is OK, but we should  
ideally have a standards-level document that describes what feature  
set is currently needed to "implement TCP", and that document would  
be full of DOWNREFs.

The pragmatic way forward is to use the roadmap as it it were a  
standards-level document, and shelve this issue until the process  
reform attempts leave us with a simplified standards track, so that  
we can upgrade it from info to standards-track without needing to  
deal with a DOWNREF nightmare.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Mon, 26 Mar 2007 10:17:15 +0200

On 2007-3-26, at 10:04, ext Lars Eggert wrote:
> example, RFC793, which is a full standard, contains MAYs and  
> SHOULDs that implementations need not implement. RFC2581, which is  
> at PS, likewise contains MUSTs, SHOULDs, and MAYs.
>
> Just because we publish something on the standards track doesn't  
> mean all TCPs need to implement all the MUSTs. Documents need to  
> come with a clause that states whether they are a must-implement  
> for a standards-compliant TCP or not. (Example: If we were to  
> publish UTO as PS - which we aren't - it would probably need to  
> say: "the UTO mechanism is OPTIONAL to implement for a standards- 
> compliant TCP.") You can view the classification in the roadmap as  
> making such statements about existing TCP RFCs retroactively,  
> because many don't include such clauses.

I realized I'm missing a piece of the argument here: These statements  
are needed, because the TCP specification spans multiple documents.  
For protocols that are specified in a single document, it is  
implicitly clear that the single document has the MUSTs that  
implementations need to implement. This is not clear for more complex  
cases like TCP.

> This is all a big mess. The roadmap tells implementors of which  
> RFCs they must implement the MUSTs, should implement the SHOULDs,  
> etc., to implement "the TCP standards", but the RFCs that contain  
> these mechanisms are all at different levels of the standards  
> track. Because the roadmap is informational, that is OK, but we  
> should ideally have a standards-level document that describes what  
> feature set is currently needed to "implement TCP", and that  
> document would be full of DOWNREFs.
>

Lars

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Mar 2007 02:59:55 -0700

Lars Eggert wrote:
> A TCP extension can be on the standards track but OPTIONAL to implement,

Extensions don't *change* operation, they augment it ;-)

I'm talking more about things that really change (i.e., replace) TCP
behavior.

> for example. The levels of the standards track express a level of
> technical maturity, but don't correlate to which protocol mechanisms are
> REQUIRED/RECOMMENDED/OPTIONAL to implement. For example, RFC793, which
> is a full standard, contains MAYs and SHOULDs that implementations need
> not implement. RFC2581, which is at PS, likewise contains MUSTs,
> SHOULDs, and MAYs.

E.g., 2581 isn't an extension, whereas 1351 is.

> all TCPs need to implement all the MUSTs. Documents need to come with a
> clause that states whether they are a must-implement for a
> standards-compliant TCP or not. (Example: If we were to publish UTO as
> PS - which we aren't - it would probably need to say: "the UTO mechanism
> is OPTIONAL to implement for a standards-compliant TCP.") You can view
> the classification in the roadmap as making such statements about
> existing TCP RFCs retroactively, because many don't include such clauses.

Such statements would render the roadmap as standards-track; as
informational, it doesn't carry any weight in making such assertions.

> mechanisms are all at different levels of the standards track. Because
> the roadmap is informational, that is OK, but we should ideally have a
> standards-level document that describes what feature set is currently
> needed to "implement TCP", and that document would be full of DOWNREFs.

Right.

> standards-level document, and shelve this issue until the process reform
> attempts leave us with a simplified standards track, so that we can
> upgrade it from info to standards-track without needing to deal with a
> DOWNREF nightmare.

Although I agree with this, this isn't what I see happening (now or
moving forward). Also, some could argue that the roadmap might have had
different conclusions if it were intended to be treated as
standards-track, so even using it informally as such seems unlikely.

Joe