Subject: [tcpm] Volunteers to review (parts of) draft-ietf-tcpm-tcp-security

From: "SCHARF, Michael" <[email-masked]>
Date: Fri, 1 Apr 2011 10:41:06 +0200

All,

as noted during the meeting, we do need volunteers that are willing to review the technical recommendations in draft-ietf-tcpm-tcp-security-02. The working group came up with a workflow to evaluate/categorize each recommendation. This process is explained on Fernando's slides:

http://www.ietf.org/proceedings/80/slides/tcpm-8.ppt

Therein, you can also find some overview of the number of recommendations and their distribution.

During the meeting, some participants volunteered to help and review parts of the document. I'd really appreciate if those of you could just post a small note to the list. And it would really help if some more folks would offer help, too. If you are particularly interested in certain sections (only), just let us know.

Due to the length of the document, it would be perfectly fine to review only certain parts of the document.

Please also note that the document does require sufficient interest and feedback from the working group in order to move forward.

Thanks!

Michael

---

From: Michael Welzl <[email-masked]>
Date: Fri, 1 Apr 2011 17:52:54 +0200

Hi!

I disagree, I think this document should not be reviewed further at  
this stage, but removed instead.
Plenty of reasons, and they have all been said before - which is why I  
also think that we should avoid even discussing this further. The  
group's email archive could be read instead.

Now, this is of course just my personal opinion; but this document has  
been on the table quite a while now, and it wasn't clear to me in any  
way at this meeting that there would be strong interest in having it  
published, let alone contributing to it.

Cheers,
Michael

On Apr 1, 2011, at 10:41 AM, SCHARF, Michael wrote:

> All,
>
> as noted during the meeting, we do need volunteers that are willing  
> to review the technical recommendations in draft-ietf-tcpm-tcp- 
> security-02. The working group came up with a workflow to evaluate/ 
> categorize each recommendation. This process is explained on  
> Fernando's slides:
>
> During the meeting, some participants volunteered to help and review  
> parts of the document. I'd really appreciate if those of you could  
> just post a small note to the list. And it would really help if some  
> more folks would offer help, too. If you are particularly interested  
> in certain sections (only), just let us know.
>
> Due to the length of the document, it would be perfectly fine to  
> review only certain parts of the document.
>
> Please also note that the document does require sufficient interest  
> and feedback from the working group in order to move forward.
>
> Thanks!
>
> Michael
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sat, 2 Apr 2011 00:41:10 +0100

Fernando,

After attending to Joe's and Bob's IP ID Reuse presentation, and talking
with Tim, I'm thinking that nailing everything down completely would
disable any future room for improvement. In particular, when certain
field are currently simply ignored, with these BCP doc all these packets
would have to be discarded - so one cannot build a backwards-compatible
new 3WHS signaling protocol (see my timestamp proposal; Tim may have
something based around the same idea soon also - what's listed on slides
9+10 would stop all these ideas cold).

Richard Scheffenegger

> -----Original Message-----
> From: Michael Welzl [mailto:[email-masked]]
> Sent: Freitag, 01. April 2011 17:53
> To: tcpm
> Subject: Re: [tcpm] Volunteers to review (parts
of)draft-ietf-tcpm-tcp-
> security

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Fri, 1 Apr 2011 23:55:53 -0700

Michael,
     If what you are saying is true, then this document should not have
become a WG document. By saying it is a WG document we are endorsing
that there is rough consensus in the WG to pursue publishing this
document. It is utter waste of time for the author and the reviewers to
have spent some energy and then say that "throw away this document". I
assume you were in the TCPM meeting and how come you did not raise your
objection then, when this topic came up, curious...
-Anantha

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Michael Welzl
> Sent: Friday, April 01, 2011 8:53 AM
> To: tcpm
of)draft-ietf-tcpm-tcp-

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Sat, 2 Apr 2011 00:00:51 -0700

Michael,

    I already reviewed the document as a whole. I privately discussed
some of the comments with Fernando and will post them to the list soon.
I am back to work and too many things to catch up, so please expect
delays.

-Anantha

From: [email-masked] [mailto:[email-masked]] On Behalf Of
SCHARF, Michael
Sent: Friday, April 01, 2011 1:41 AM
To: [email-masked]
Subject: [tcpm] Volunteers to review (parts of)
draft-ietf-tcpm-tcp-security

All,

as noted during the meeting, we do need volunteers that are willing to
review the technical recommendations in draft-ietf-tcpm-tcp-security-02.
The working group came up with a workflow to evaluate/categorize each
recommendation. This process is explained on Fernando's slides:

Therein, you can also find some overview of the number of
recommendations and their distribution.

During the meeting, some participants volunteered to help and review
parts of the document. I'd really appreciate if those of you could just
post a small note to the list. And it would really help if some more
folks would offer help, too. If you are particularly interested in
certain sections (only), just let us know.

Due to the length of the document, it would be perfectly fine to review
only certain parts of the document.

Please also note that the document does require sufficient interest and
feedback from the working group in order to move forward.

Thanks!

Michael

---

From: Michael Welzl <[email-masked]>
Date: Sat, 2 Apr 2011 09:02:49 +0200

I agree: it was, in my opinion, a mistake for the group to take it up  
as a document. You can find me stating that I'm against that in the  
archive.
Why did I not raise my objection at the meeting: I figured, I have  
said my opinion before, it didn't help, why would it be constructive  
to stand up and say "stop" again? but, after the presentation, it  
looked obvious to me that this document doesn't have the community  
interest it needs.

Cheers,
Michael

---

From: Fernando Gont <[email-masked]>
Date: Sat, 02 Apr 2011 15:54:41 -0300

[changed the subject, since this has nothing to do with the request sent
by the chairs]

On 01/04/2011 12:52 p.m., Michael Welzl wrote:
> I disagree, I think this document should not be reviewed further at this
> stage, but removed instead.

I personally believe it is harmful that the chairs are requesting
reviewers, based on a very recent discussion, and you raise issues from
a past discussion in the thread, arguing against what the wg has agreed
upon.

> also think that we should avoid even discussing this further. 

This is false. The claims have been "Oh, this document is harmful!".
Please look at the only one or two concrete examples that were raised,
and my response to them.

And, FWIW, this is in I-D stage. If there's any recommendation that is
wrong, we have plenty of time to change it, and I urge you to state
explicitly which recommendations you think are incorrect, and we may
fix/eliminate them where necessary.

> The group's email archive could be read instead.

I did, but found nothing. Please provide references.

> published, let alone contributing to it.

I don't think the past meeting was trying to sense that. It was trying
to get reviewers, and agree on a procedure to follow when reviewing the
document.

P.S.: For the sake of keeping a good signal/noise ratio and spending the
wg's energy in getting work done, I will not respond to this thread
until it is explicitly stated what are the recommendations that are
deemed as harmful/incorrect. This thread, as is, sounds more like
flaming than anything else.

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

---

From: Michael Welzl <[email-masked]>
Date: Sat, 2 Apr 2011 21:40:52 +0200

> a past discussion in the thread, arguing against what the wg has  

Hm, you have a point there. I still have the same opinion as I had  
then, but I might be mistaken about IETF procedures.
Now that the WG approved it as a WG document, *can* it even be  
stopped? Can the WG change its mind and kick it out if there is  
consensus for doing so, or lack of interest for it?

I will wait for an answer to this from the chairs before I even  
continue. I don't want to waste everyone's time.

Cheers,
Michael

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sat, 2 Apr 2011 23:44:07 +0100

Fernando,

Well, I realized that you recommend (more or less explicitly), that all
fields in the header that SHOULD be zero, MUST BE zero, and that any
non-compliant tcp packet MUST be silently discarded (supposedly by the
intended receiver or potentially even by some middlebox)...

At least that's what I get just from the last two slides of your
presentation.

IIRC, the same recommendation is mentioned in the document for TSecr in
SYN (the very bits which my current proposal would use). Although, I
believe the wording there is more liberal, and does not say such a
packet has to be silently discarded...

I strongly object to "silently discarded". It appears to me, that this
draft goes against the spirit of "be liberal what you accept, be
conservative in what you do" (you=tcp stack in this case). Making sure
that these fields are *ignored* by implementations which can not
interpret anything other than zero is what has to be stipulated - NOT
silent discards!

However, what I think is the right way to handle unknown values in field
that (currently) have no meaning, is already specified in the protocol
docs (but as a SHOULD, and MUST ignore; at least in RFC1323 timestamps
it's written that way. Thus a improper implementation that leaks data by
not properly initializing fields, is hurting itself more, than anyone
else...

Richard Scheffenegger

> From: Fernando Gont [mailto:[email-masked]]
> Sent: Samstag, 02. April 2011 20:55
> To: Michael Welzl
> Cc: tcpm
> Subject: [tcpm] miscellaneous comments about tcp-security (was Re:
> Volunteers to review (parts of) draft-ietf-tcpm-tcp-security)
>

---

From: [email-masked] (Christos Zoulas)
Date: Sat, 2 Apr 2011 19:50:06 -0400

On Apr 2, 11:44pm, [email-masked] ("Scheffenegger, Richard") wrote:
-- Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re: Vol

| Fernando,
| 
| Well, I realized that you recommend (more or less explicitly), that all
| fields in the header that SHOULD be zero, MUST BE zero, and that any
| non-compliant tcp packet MUST be silently discarded (supposedly by the
| intended receiver or potentially even by some middlebox)...
| 
| At least that's what I get just from the last two slides of your
| presentation.
| 
| IIRC, the same recommendation is mentioned in the document for TSecr in
| SYN (the very bits which my current proposal would use). Although, I
| believe the wording there is more liberal, and does not say such a
| packet has to be silently discarded...

So what should a middlebox do? Scrub them to 0 or pass them along? If
it scrubs them to 0 again it will be compliant, but it will break future
protocol use.

| I strongly object to "silently discarded". It appears to me, that this
| draft goes against the spirit of "be liberal what you accept, be
| conservative in what you do" (you=tcp stack in this case). Making sure
| that these fields are *ignored* by implementations which can not
| interpret anything other than zero is what has to be stipulated - NOT
| silent discards!

I can see the behavior to pass as useful (no strange packet drops, if
the protocol starts using those bits, you don't need to make a middlebox
understand them), but dangerous (if a middlebox passes them along was it
supposed to interpret them somehow and act on them instead?).

| However, what I think is the right way to handle unknown values in field
| that (currently) have no meaning, is already specified in the protocol
| docs (but as a SHOULD, and MUST ignore; at least in RFC1323 timestamps
| it's written that way. Thus a improper implementation that leaks data by
| not properly initializing fields, is hurting itself more, than anyone
| else...

You are just encouraging sloppy but convenient behavior. 

christos

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sun, 3 Apr 2011 01:09:40 +0100

Hi Christos,

> You are just encouraging sloppy but convenient behavior.

s/sloppy/conservative/g
s/convenient/liberal/g

If one is paranoid, policing "unknown" behavior in a private net is fine
with me. But "policing" should not be enforced ubiquitously. But this
may be a minority view...

> it scrubs them to 0 again it will be compliant, but it will break
> future protocol use.

A middelbox should not mess with stuff it doesn't understand...  the
default should be to pass undefined bits along (it's the end hosts
responsibility to not react badly). But again, a non-default option to
scrub (or worse, silently drop) these packets MAY be provided. But do we
need a BCP for that? I don't think so...

Richard Scheffenegger

> From: Christos Zoulas [mailto:[email-masked]]
> Sent: Sonntag, 03. April 2011 01:50
> To: Scheffenegger, Richard; Fernando Gont; Michael Welzl
> Cc: tcpm
> Subject: Re: [tcpm] miscellaneous comments about tcp-security (was
> Re:Volunteers to review (parts of) draft-ietf-tcpm-tcp-security)
> 
> | it's written that way. Thus a improper implementation that leaks
data
> by

---

From: [email-masked] (Christos Zoulas)
Date: Sat, 2 Apr 2011 22:20:30 -0400

On Apr 3,  1:09am, [email-masked] ("Scheffenegger, Richard") wrote:
-- Subject: RE: [tcpm] miscellaneous comments about tcp-security (was Re:Volu

| > You are just encouraging sloppy but convenient behavior.
| 
| s/sloppy/conservative/g
| s/convenient/liberal/g
| 
| If one is paranoid, policing "unknown" behavior in a private net is fine
| with me. But "policing" should not be enforced ubiquitously. But this
| may be a minority view...

I still think it is sloppy. Why would we get non-zero bits in there
in the first place? The only reason I can think is because someone
forgot to zero them and we are getting trash from the heap or the
stack. We all keep finding information disclosure issues in code
all the time because we forget to initialize things. In this case
it is not a security issue, but we should not encourage sloppy coding
uniformly so that people improve their coding practices.

| > So what should a middlebox do? Scrub them to 0 or pass them along? If
| > it scrubs them to 0 again it will be compliant, but it will break
| > future protocol use.
| 
| A middelbox should not mess with stuff it doesn't understand...  the
| default should be to pass undefined bits along (it's the end hosts
| responsibility to not react badly). But again, a non-default option to
| scrub (or worse, silently drop) these packets MAY be provided. But do we
| need a BCP for that? I don't think so...

I like specifications that don't have "may"s. "May"s just lead to ambiguity,
and make testing more complex. I think we should be moving towards making
specifications stricter and not liberal. In this case perhaps it is too late.

christos

---

From: Michael Welzl <[email-masked]>
Date: Sun, 3 Apr 2011 09:17:45 +0200

> uniformly so that people improve their coding practices.

The reason to get non-zero bits that we are all concerned about here  
is that the IETF has developed something new that your middlebox  
doesn't yet understand. Future mechanism X could make TCP go a little  
faster, but it requires a new bit (say, one of the reserved bits);  
your middlebox drops it; because the risk of even very rarely having  
packets consistently dropped greatly outweighs the potential benefit  
of having TCP go a bit faster, people will tend to not use mechanism X.

Replace mechanism X with ECN, and you see the point, I hope.

I looked for the reserved bits in Fernando's document just now, and  
must admit that I was a bit surprised to see that it says exactly that:

"TCP MUST ignore the Reserved field of incoming TCP segments.
DISCUSSION:
Internet-Draft TCP Security Assessment January 2011 These four bits  
are reserved for future use, and must be zero. As with virtually every  
field, the Reserved field could be used as a covert channel. While  
there exist intermediate devices such as protocol scrubbers that clear  
these bits, and firewalls that drop/ reject segments with any of these  
bits set, these devices should consider the impact of these policies  
on TCP interoperability. For example, as TCP continues to evolve, all  
or part of the bits in the Reserved field could be used to implement  
some new functionality. If some middle-box or end-system  
implementation were to drop a TCP segment merely because some of these  
bits are not set to zero, interoperability problems would arise."
I have no problem with this text in the draft. (although it just  
repeats "be liberal in what you accept").

> specifications stricter and not liberal. In this case perhaps it is  

I think it is good practice to require as little as possible in  
protocol design. I'm sure that this is explained in an RFC somewhere -  
it should?!

Cheers,
Michael

---

From: Fernando Gont <[email-masked]>
Date: Sat, 02 Apr 2011 16:06:28 -0300

On 01/04/2011 08:41 p.m., Scheffenegger, Richard wrote:
> would have to be discarded 

I don't follow. Could please provide a reference to a specific paragraph
in the tcp-security I-D that argues that because a field is currently
unused, a node should drop packets that have that bit set?

-- And, if you find one of such instances, we should fix it. That's it.
-- Alas, that's the reason why the tcp-security is in I-D stage.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 03 Apr 2011 08:30:09 -0300

Hi, Richard,

> intended receiver or potentially even by some middlebox)...

I personally believe that the reserved bits MUST be zero -- actually,
that's what is generally REQUIRED by the *specs* (i.e., "Unused. MUST be
set to zero, and ignored by the receiver" stuff).

Regarding what to do with unused bits that are set, I agree the proper
thing to do would be to ignore them, such that when those bits are
specified in some future extension, that extension can be deployed. --
so if there's advice that goes against this principle, I'd be glad to
change it.

Anyway, the above is *my* view, but if the wg agreed otherwise, I'd be
happy to change the relevant text.

> interpret anything other than zero is what has to be stipulated - NOT

Which field are your referring to, in this case?

> not properly initializing fields, is hurting itself more, than anyone

Any implementation that leaks information, or has packet-of-death
attacks, etc., hurts itself. But due to programming errors, we have seen
to many of these issues.

Thanks,

---

From: Michael Welzl <[email-masked]>
Date: Sun, 3 Apr 2011 14:26:17 +0200

Hi all,

> -- Alas, that's the reason why the tcp-security is in I-D stage.

 From a quick glance, it indeed seems that Fernando has removed a lot  
of the "nailing down" text. So I will change my assertion of the  
document:
- If ALL such text is removed / fixed, I no longer consider the  
document dangerous.

In this case, I still consider it useless, because it seems (remember,  
I might be wrong, I didn't read the 100+ pages) to give just plenty of  
mundane advice, basically repeating what other specifications say in  
different words. It seems to me that it is this mundane advice that  
makes the document as long as it is.

By "mundane advice", I mean: spec. A would say "this is the length  
field. it should have the length" and this doc would say "if the  
length doesn't match, drop the packet". This isn't harmful, but not  
worth specifying, to me. Fernando says that the necessity to specify  
such things comes from real experience. I can appreciate this view; I  
take a neutral position on this (i.e. I personally consider it  
useless, but if TCPM wants to publish that, I won't object).

I repeat, this is IFF all text that would hinder future innovation as  
discussed above and in the few previous emails would be removed.  
Someone besides Fernando himself would have to make this check, and  
I'm not going to volunteer because I've read a previous version of the  
document before, and it was just painful and long.

In a nutshell, because I am getting the impression that Fernando is  
willing to remove all such dangerous advice, I take back what I said  
before about reviewing the document. If there are volunteers to take  
up the work, fine with me.

Cheers,
Michael

---

From: <[email-masked]>
Date: Sun, 3 Apr 2011 13:39:52 +0100

> discussed above and in the few previous emails would be removed.

For clarity, that is presumably the mathematicians' 'If and only if' abbreviation and not a typo...

http://en.wikipedia.org/wiki/If_and_only_if

---

From: [email-masked] (Christos Zoulas)
Date: Sun, 3 Apr 2011 12:51:54 -0400

On Apr 3,  9:17am, [email-masked] (Michael Welzl) wrote:
-- Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re:Volu

| The reason to get non-zero bits that we are all concerned about here  
| is that the IETF has developed something new that your middlebox  
| doesn't yet understand. Future mechanism X could make TCP go a little  
| faster, but it requires a new bit (say, one of the reserved bits);  
| your middlebox drops it; because the risk of even very rarely having  
| packets consistently dropped greatly outweighs the potential benefit  
| of having TCP go a bit faster, people will tend to not use mechanism X.
| 
| Replace mechanism X with ECN, and you see the point, I hope.

Now imagine the situation where half of the TCP/IP stack implementations
put random values in the reserved bits, before one of those bits
became mechanism X. This is why I am advocating to specify that
the unused bits should be zero. So that they can be used in the
future, and to promote safe coding practices.

| I think it is good practice to require as little as possible in  
| protocol design. I'm sure that this is explained in an RFC somewhere -  
| it should?!

Require as little as possible does not conflict with specify the
implementations behavior as completely as possible.

christos

---

From: Michael Welzl <[email-masked]>
Date: Sun, 3 Apr 2011 19:15:47 +0200

> future, and to promote safe coding practices.

I agree that they should by default by zeroed by the sender, and I  
think this is probably written in some RFC somewhere; but this is the  
least important aspect, I'd say, as new specifications don't normally  
require them to be zero by default, as you can't really rely on this  
in the Internet anyway. The more important thing is that middleboxes  
don't zero them (thereby a new mechanism not yet known to this  
middlebox), let alone drop them (thereby giving people a good reason  
to almost never turn the new mechanism on).

> implementations behavior as completely as possible.

Correct, and it does not conflict with what you said before, to which  
I answered. What  you said was "May's just lead to ambiguity, and make  
testing more complex. I think we should be moving towards making  
specifications stricter and not liberal."

By "require" as little as possible I meant "use only as many MUSTs as  
you have to".

Cheers,
Michael

---

From: Wesley Eddy <[email-masked]>
Date: Sun, 03 Apr 2011 20:46:52 +0200

On 4/2/2011 9:40 PM, Michael Welzl wrote:
> Hm, you have a point there. I still have the same opinion as I had then,
> but I might be mistaken about IETF procedures.
> Now that the WG approved it as a WG document, *can* it even be stopped?
> Can the WG change its mind and kick it out if there is consensus for
> doing so, or lack of interest for it?
>

Hi Michael, I'm not one of the chairs, but I used to be, so maybe I can 
help answer this :).

WG documents can expire just like any other I-D, and charter milestones 
can be removed at chairs' request, with AD approval.  In fact, this 
possibility had been considered with the tcp-security document in the 
past.  However, following the Beijing meeting, Fernando made a large 
effort to rewrite the document and make the recommendations clearly 
separated from the rationale so that the process of reviewing them that 
had begun in Anaheim could continue, and we decided to give it one more 
chance.

Prior to Prague, we'd seen only about 3 people (not including Fernando) 
volunteer to help review, but we planned to ask during the meeting, and 
were considering that we might have to drop it as a WG item if we 
couldn't find at least 5.  I saw about 6 hands in the meeting, plus the 
3 we already had.  So, this looked to me like it might have just enough 
energy to continue.

I think Richard's note in this thread actually identifies key reasons 
why TCPM needs to do this document.  Without recommendations from the 
IETF on how to harden TCP stacks without limiting innovation potential, 
recommendations from outside will almost certainly be too restrictive.

-- 
Wes Eddy
MTI Systems

---

From: "Smith, Donald" <[email-masked]>
Date: Sun, 3 Apr 2011 13:15:42 -0600

I have volunteered to review this in the past and will review the new version soon.

(coffee != sleep) & (!coffee == sleep)
 [email-masked]
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Wesley Eddy [[email-masked]]
Sent: Sunday, April 03, 2011 12:46 PM
To: [email-masked]
Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re:  Volunteers to review (parts of) draft-ietf-tcpm-tcp-security)

This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.

---

From: Shoaib Rao <[email-masked]>
Date: Sun, 03 Apr 2011 19:26:45 -0700

> it scrubs them to 0 again it will be compliant, but it will break future
RFC 3360 " Inappropriate TCP Resets Considered Harmful" already 
addresses this

Abstract

This document is being written because there are a number of
firewalls in the Internet that inappropriately reset a TCP connection
upon receiving certain TCP SYN packets, in particular, packets with
flags set in the Reserved field of the TCP header. In this document
we argue that this practice is not conformant with TCP standards, and
is an inappropriate overloading of the semantics of the TCP reset.
We also consider the longer-term consequences of this and similar
actions as obstacles to the evolution of the Internet infrastructure.

Shoaib.

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 4 Apr 2011 11:03:47 -0700

On Fri, Apr 1, 2011 at 1:41 AM, SCHARF, Michael
<[email-masked]> wrote:
> review the technical recommendations in draft-ietf-tcpm-tcp-security-02. The
> working group came up with a workflow to evaluate/categorize each
> During the meeting, some participants volunteered to help and review parts
> of the document. I'd really appreciate if those of you could just post a
> small note to the list. And it would really help if some more folks would
> offer help, too. If you are particularly interested in certain sections
> (only), just let us know.

I am interested in reviewing section 5, 6, 7, 8, 9. Is there a deadline?

---

From: Mark Allman <[email-masked]>
Date: Mon, 04 Apr 2011 14:34:52 -0400

> Prior to Prague, we'd seen only about 3 people (not including
> Fernando) volunteer to help review, but we planned to ask during the
> meeting, and were considering that we might have to drop it as a WG
> item if we couldn't find at least 5.  I saw about 6 hands in the
> meeting, plus the 3 we already had.  So, this looked to me like it
> might have just enough energy to continue.

I assume I am one of the 3.  But, don't interpret that as support for
the document.  Its more like falling on my civic-duty sword.  See my
other two notes for details, but I wanted to make sure you were counting
right. :)

allman

---

From: Mark Allman <[email-masked]>
Date: Mon, 04 Apr 2011 14:58:27 -0400

> I think Richard's note in this thread actually identifies key
> reasons why TCPM needs to do this document.

Point taken.  But, I want to disagree.  The caveat is (per my other
note) that I have only read the intro and section 9.  And, I basically
haven't tracked this document's history and did not weigh in on whether
it should be a WG item.  

However, lack of literacy skills nor lack of timeliness have ever been
an impediment to forming an opinion for me! :-)

I think at a high level what this document creates is a big mess.  Page
7 of this section document lists 18 RFCs that are "assessed".  Most of
those RFCs take security into account.  That doesn't mean they are
flawless.  To the contrary they are all likely flawed in some fashion.
But, having one massive off-to-the-side document try to fix this
situation is asking for trouble and confusion.

For instance, lets consider one example from this document.  It says:

   TCP SHOULD limit the number of duplicate acknowledgements it will
   honour to:

                   Max_DupACKs = (FlightSize / SMSS) - 1

   Where FlightSize and SMSS are the values defined in RFC 2581 [Allman
   et al, 1999].  When more than Max_DupACKs duplicate acknowledgements
   are received, the exceeding DupACKs should be silently dropped.

And, RFC 5681 [an update to RFC2581 that happened 18mos ago and which
the security document ignores] says:

   4.  For each additional duplicate ACK received (after the third),
       cwnd MUST be incremented by SMSS.  This artificially inflates the
       congestion window in order to reflect the additional segment that
       has left the network.

       Note: [SCWA99] discusses a receiver-based attack whereby many
       bogus duplicate ACKs are sent to the data sender in order to
       artificially inflate cwnd and cause a higher than appropriate
       sending rate to be used.  A TCP MAY therefore limit the number of
       times cwnd is artificially inflated during loss recovery to the
       number of outstanding segments (or, an approximation thereof).

So, in very basic terms these two things are talking about the same
mechanism.  RFC 5681 [a Draft Standard] says this bit is a MAY and the
draft [lets presume it is a BCP] says it is a SHOULD.  Which one is
normative?  We might go consult the rules and figure that out and That'd
Be The Answer.  But, to have two documents specifying the same mechanism
and assigning MUST/SHOULD/MAY differently is creating a mess.  It'd be
further madness if the mechanism was not specified uniformly.

The fact is we have considered security in our work in the past and
where we have gotten it wrong we have processes to fix it.  But, adding
some parallel specification for 18 documents here is not a good idea.
We really should let this expire and pick up any useful pieces and roll
those in where they belong.  TCP is a big enough mess across a big
enough set of specifications.  We don't need to aggravate the situation
needlessly.  

IMHO.

allman

---

From: Hal Wigoda <[email-masked]>
Date: Mon, 4 Apr 2011 15:56:13 -0400

I'd be willing to review it. 

-------

---

From: Alexander Zimmermann <[email-masked]>
Date: Mon, 04 Apr 2011 22:27:38 +0200

> enough set of specifications.  We don't need to aggravate the situation

+1

> allman

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: (49-241) 80-21422, fax: (49-241) 80-22222
// email: [email-masked]
// web: http://www.umic-mesh.net
//

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Mon, 4 Apr 2011 17:37:33 -0700

Interesting thought. Let me try to offer my few bits here. 

- Do we want to make TCP robust, by that I mean fix flaws in TCP specs
w.r.t security, address vulnerabilities etc.,  The answer seems to be
yes. We have embarked on few TCP specs relating to this effort, TCP-AO
etc., have become RFC's. We did agree to make TCP-security document as a
WG item. (right or wrong, doesn't matter for the current argument sake).

So, I would think one way to tackle this problem is to form a design
team or a separate sub WG, say TCPSec or whatever that can use the
tcp-security document as a starting point and formulate changes to
individual RFC's ("roll them to where they belong" like you say below)
in the form of errata's or documents.

Just my thought and it maybe stupid, but I see that as one way to move
forward, may not be the most optimal way.

$0.02,
-Anantha

Of
> Mark Allman
> Sent: Monday, April 04, 2011 11:58 AM
> To: Wesley Eddy
> Cc: [email-masked]
> Subject: Re: [tcpm] miscellaneous comments about tcp-security (was Re:
reasons
> > why TCPM needs to do this document.
> 
> normative?  We might go consult the rules and figure that out and
> That'd Be The Answer.  But, to have two documents specifying the same
> mechanism and assigning MUST/SHOULD/MAY differently is creating a
mess.
> It'd be further madness if the mechanism was not specified uniformly.
>