Subject: [tcpm] Removal of TCPM milestone on security hardening

From: "SCHARF, Michael" <[email-masked]>
Date: Thu, 1 Mar 2012 10:15:10 +0100

Fernando,

The document draft-ietf-tcpm-tcp-security expired more than half a year
ago, and given that lack of progress, it has been suggested several
times to remove the corresponding milestone from the TCPM charter:

   Aug 2010	Submit document on security hardening of TCP
implementations to the IESG for publication as a Best Current Practices
RFC

Unfortunately, it seems to be quite apparent that TCPM cannot meet this
milestone due to lack of progress and consensus on the document scope.
Therefore, the chairs will ask for removal of that milestone before the
Paris meeting, unless another solution for addressing that milestone is
found in the next two weeks.

I personally think that a document on security hardening would be very
valuable, but we need TCPM consensus on the scope first.

Best regards

Michael (TCPM co-chair)

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Thu, 1 Mar 2012 11:30:29 -0800

> valuable, but we need TCPM consensus on the scope first.

+1 on security hardening for TCP.  I haven't looked into the latest
document, but I would think the scope can be worked out. 

-Anantha

> 
> Best regards
> 
> Michael (TCPM co-chair)
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 2 Mar 2012 07:31:35 -0800

+1

---

From: Mark Allman <[email-masked]>
Date: Fri, 02 Mar 2012 10:35:15 -0500

> +1 on security hardening for TCP.  

We should absolutely harden TCP in places where it is vulnerable.

But, this document is a large mess of a way to go about it (as I have
previously argued).  We should let it die and pick up the useful pieces.

allman

---

From: Ted Faber <[email-masked]>
Date: Fri, 2 Mar 2012 09:30:11 -0800

> previously argued).  We should let it die and pick up the useful pieces.

As is often the case, Mark is talking sense and I agree with him.

-- 
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

---

From: "Anantha Ramaiah (ananth)" <[email-masked]>
Date: Fri, 2 Mar 2012 11:27:01 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Mark Allman
> Sent: Friday, March 02, 2012 7:35 AM
> To: Anantha Ramaiah (ananth)
> Cc: [email-masked]; Fernando Gont
> Subject: Re: [tcpm] Removal of TCPM milestone on security hardening
> 
> 
> > > I personally think that a document on security hardening would be
> > > very valuable, but we need TCPM consensus on the scope first.
> >

I am not sure about the procedure. This document does contain hardening
measures recommended for TCP, therefore I would think it is worth
pursuing it. OTOH, there are so many things (IMO) that need to be yanked
out of the document like some validation etc., which belongs to
implementation guidance sort of document in some sense.

Maybe one way is to write a fresh ID that covers only the hardening
aspects OR remove the gunk from the document and re-structure it. I
don't know. I'll let chairs chime in....

-Anantha

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 2 Mar 2012 11:29:29 -0800

It is not that I disagree with what Mark is saying, but the tcpm group has done little to help or guide Fernando on the draft either. Dropping the draft and picking up the necessary pieces is fine if there is a plan for how to go about it.

We can derive some hints from the way other groups go about a topic that is large and wieldy. In this particular case, how about we split the work into:

- What are the security vulnerabilities are (and what we want to focus on) and what the ideal state should be.
- Solutions/suggestions/BCP on those vulnerabilities. 

The second part could be one or more drafts.

---

From: Mark Allman <[email-masked]>
Date: Fri, 02 Mar 2012 15:09:50 -0500

> It is not that I disagree with what Mark is saying, but the tcpm group
> has done little to help or guide Fernando on the draft
> either.

Well, look, some of us reviewed it or portions of it.

And, Wes and David tried hard to manage this beast and get it moved
forward, IMO.

The parts I read were simply lots of words with very little in the way
of fixing of anything.

And, some of us did suggest a way forward here ... and that is instead
of a monolithic document that tries to make tweaks to a couple dozen
RFCs that we simply update the RFCs in question if there is something to
update.  Or, in some cases we just actually read what the current RFCs
say (e.g., when I read the congestion control section it was talking
about an RFC that had been updated by another RFC 18mo prior to when I
was reading it!).

> Dropping the draft and picking up the necessary pieces is fine if
> there is a plan for how to go about it.

I think that is the wrong approach.  We should drop this document,
because (1) it has received a bunch of [legitimate IMO] pushback, (2) it
.has proven too big to manage and (3) it hasn't been updated for over a
year.

Rather than trying to foist a path on Fernando and the WG what we should
do is let people who have *energy* for this suggest a path and let the
WG consider that path.  If people think this is important enough to put
*energy* into then it will happen.  If people don't, it won't happen.
But, we should realize that if there is no energy it isn't going to
happen no matter what.

allman

---

From: "SCHARF, Michael" <[email-masked]>
Date: Fri, 2 Mar 2012 22:15:45 +0100

> > has done little to help or guide Fernando on the draft either.

Mahesh, this statement is not correct.
 
> I think that is the wrong approach.  We should drop this 
> document, because (1) it has received a bunch of [legitimate 
> IMO] pushback, (2) it .has proven too big to manage and (3) 
> it hasn't been updated for over a year.
> 
> Rather than trying to foist a path on Fernando and the WG 
> what we should do is let people who have *energy* for this 
> suggest a path and let the WG consider that path.  If people 
> think this is important enough to put
> But, we should realize that if there is no energy it isn't 
> going to happen no matter what.

Technically, adding a new milestone is fairly trivial, if there is enough energy in the community _and_ if there is consensus about the content of a draft.

A good first step would be a submission of one (or more) individual draft(s) that address the past discussions and reviews.

Michael

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 2 Mar 2012 13:25:04 -0800

Mark,

Do we agree that there is a need to identify and secure TCP? I think I did hear a yes.

> .has proven too big to manage and (3) it hasn't been updated for over a

If I get this right then for

(1) identify which parts received pushbacks. For the parts that you reviewed can you identify which were areas that you felt needed to stay. I can do the same for the parts I read. I know Anantha has reviewed the document.

(2) As I suggested in my last e-mail, if it is too big to manage, we can split it up. If not along the lines I suggested, then suggest which other way. I am sure Fernando will not have a problem with splitting the draft if it helps move it forward.

(3) will take of itself if we agree on (1) and (2).

---

From: Mark Allman <[email-masked]>
Date: Fri, 02 Mar 2012 16:38:50 -0500

> Do we agree that there is a need to identify and secure TCP? 

If there are places where TCP is vulnerable then I agree it would be
good to fix those.

But, for instance, I do not believe this document says anything over and
above what the RFCs already say in terms of congestion control.

> (1) identify which parts received pushbacks. For the parts that you
>     reviewed can you identify which were areas that you felt needed to
>     stay. I can do the same for the parts I read. I know Anantha has
>     reviewed the document. 

I provided detailed reviews of sections 9 & 14.  Neither provided
anything useful in terms of identifying vulnerabilities or fixing them
over the current RFCs.

> (2) As I suggested in my last e-mail, if it is too big to manage, we
>     can split it up. If not along the lines I suggested, then suggest
>     which other way. I am sure Fernando will not have a problem with
>     splitting the draft if it helps move it forward. 

I **did** suggest something.  In the email you are responding to, in
fact.  I suggest we fix the root documents.  If there is a problem in
RFC 5681 then lets fix that document.  There may be some cases where a
new document is needed for something because the root document is just
untenable to deal with directly or something.  Thats fine.  But, as I
have said many times, the way to fix small problems in a couple of dozen
document is NOT to write some monolithic document that conflicts with
those couple dozen other documents.  That is a giant MESS.

Please stop pretending the WG hasn't done anything in this space.  We
have discussed this document.  We have tried to help.  We have made
suggestions.  Any number of members have done so.  The previous chairs
did so.

> (3) will take of itself if we agree on (1) and (2).

I listed (3) to basically indicate this WG has had very little energy
for this work for some time now.  If there is good energy for something
that needs fixed then lets do it.

allman

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Mar 2012 13:46:26 -0800

> Do we agree that there is a need to identify and secure TCP? I think I

"Securing" TCP is done with RFC 5925 (TCP-AO).

Fixing bugs in TCP is done with the RFC 2525 (implementation issues), 
which may be due for an update.

We do NOT need a doc that teaches best-practices of implementing TCP 
using techniques any protocol programmer should already know (check your 
fields before acting on them, etc.)

We do NOT need a doc that paints every undesired or unexpected behavior 
as an attack. Be liberal in what you receive, even if it means ignoring it.

If there is a specific security problem, a specific ID might prove 
useful. But we should evaluate each issue on its own merits. There's no 
need to call for a crusade here.

Joe

---

From: Mark Allman <[email-masked]>
Date: Fri, 02 Mar 2012 16:50:39 -0500

> Fixing bugs in TCP is done with the RFC 2525 (implementation
> issues), which may be due for an update.
> 
> using techniques any protocol programmer should already know (check
> your fields before acting on them, etc.)
> 
> We do NOT need a doc that paints every undesired or unexpected
> behavior as an attack. Be liberal in what you receive, even if it
> means ignoring it.
> 
> useful. But we should evaluate each issue on its own merits. There's
> no need to call for a crusade here.

Holy crap ... I don't think Joe wrote anything above I disagree with!

Spooky .... :-) :-)

allman

---

From: "SCHARF, Michael" <[email-masked]>
Date: Fri, 2 Mar 2012 23:27:38 +0100

> I think I did hear a yes.

The current milestone text is about security hardening of TCP _implementations_.

My personal understanding is that such guidance to stack implementors could, for instance, also be achieved by a short informational survey document like RFC 4614 that just points to the relevant sections in standard track RFCs. But it is really useless to discuss about hypothetical documents that do not exist.

Michael

---

From: Fernando Gont <[email-masked]>
Date: Sun, 04 Mar 2012 05:29:59 -0300

Joe,

> "Securing" TCP is done with RFC 5925 (TCP-AO).

1) Is this deployable for the general case, in the real world?
2) Even if it was (which I don't think it's the case), that just
"authenticates" the remote endpoint. That doesn't mean that an
authenticated endpoint (whether because it's infected with malware or
because it simply wants to have fun) won't be able to mess with others'
connections.

> fields before acting on them, etc.)

Have you bothered to check e.g. US-CERT's web site, and see what is
going on in the real world?

> as an attack. 

Agreed. We just need implementations that do not break under any
undesired or unexpected behavior.

> useful. 

Joe, you even argued against the publication of RFC 6528. Are you being
serious?

> But we should evaluate each issue on its own merits. There's no

No crusades. Just caring about that thing called "running code".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492