Subject: Re: [tcpm] tcp-security: Request for feedback on the outline of the document

From: <[email-masked]>
Date: Tue, 1 Sep 2009 12:11:19 +0100

I think there needs to be some form of hum relating to this. There seems
to be a relatively small number of people expressing relatively strong
opinions on this document that are clearly incompatible. One key thing,
regardless of how we actually decide to split the work, Fernando's
current ToC is too long... 3 pages of ToC is excessive. I think the
sections aren't grouped at a high enough level (e.g. connection
establishment and tear-down could be in one section on connection
management, buffer management and re-assembly could probably be grouped
into memory management, etc). This is separate to any consideration as
to whether you should be presenting things in a completely different
order... I think Joe actually raised this before...

1 inline comment as well

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Fernando Gont
> Sent: 01 September 2009 06:34
> To: Joe Touch
> Cc: Alfred ?; [email-masked]
> Subject: Re: [tcpm] tcp-security: Request for feedback on the outline
> of the document
> 
> Hello, Joe,
> 
> >> The latter is true, but the document is still meant to target
> >> implementers. If you spread the advice on a per-attack basis, or on
> a
> >> protocol-weaknesses vs. implementer's-choice-weaknesses, you're
> >> basically spreading the advice about a single protocol field or
> option
> >> among multiple sections.
> >
> > Maybe - some fields are susceptible to only a small set of attacks
> that
> > may be related.
> 
> That's the exception, not the rule.
> 
> 
> > However, we'd also be allowing (if not encouraging) use
> > of protections as appropriate, rather than encouraging everyone to
> > implement every protection -
> 
> Joe, this is about hardening a TCP implementation, not about
mitigating
> some vulnerabilities while leaving the door open to the rest of them.
> 
> 
> 
> > An implementer needs to know when they're playing inside a box the
> spec
> > created (#1), playing around in ways that could affect the protocol
> now
> > or in the future (#2), or just need to apply known algorithms rather
> > than modify the protocol.
> 
> Exactly. That's why the document does not simply provide the "what to
> do", but also provides a discussion of the mitigations, etc.
> 
> But the document is still aimed at implementers. A bunch of
> implementers
> have already reviewed the document, and found the current outline
> useful.
> 
> 
> 
> > The point is that in the outline proposed in ID-0, there are
multiple
> > top-level sections where these issues are discussed. The idea that
> "an
> > implementer wants to find things in one place" is fine, but IMO the
> > outline I proposed may to a mode useful job of aggregating this
> > information than ID-0.
> 
> Again: the goal of this document is helping TCP implementers harden
> their TCPs. And for that target, having everything about a protocol
> field in a single place is the only document outline that does not get
> in the middle of the developer and the implementation. If you spread
> the
> advice among lots of places, this is what will happen: some
mitigations
> will be missed.

So if this is entirely aimed at implementers shouldn't that be
explicitly stated in the title? I appreciate that in theory BCP is meant
to imply implementation guidance but this might be more appropriately
titled something like "Implementers guidelines for mitigating TCP
security threats" or "Guidance on secure implementation of TCP"

> 
> I'm not saying the outline you propose is "wrong". I'm saying it's not
> the best approach for the public this document targets. That doesn't
> mean that an alternative outline can be included in an appendix. --
> that
> may be useful.
> 
> Thanks!
> 
> Kind regards,
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Tue, 1 Sep 2009 08:14:28 -0500

>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: Tuesday, September 01, 2009 7:11 AM
>

This is a great point; in fact, the milestone we put on the TCPM charter
says:

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

so the titles you suggested, or something else that indicates "Secure TCP
Implementation" would probably be more appropriate than the "Security
Assessment ..." title it currently has.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

---

From: Fernando Gont <[email-masked]>
Date: Tue, 01 Sep 2009 12:09:02 -0300

> Assessment ..." title it currently has.

FWIW, I have no problem with the proposed title change to, e.g.,
"Guidance on secure implementation of the Transmission Control Protocol
(TCP)".

Will start a new thread about the document title...

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Tue, 01 Sep 2009 08:13:16 -0700

Fernando Gont wrote:
...
> mean that an alternative outline can be included in an appendix. -- that
> may be useful.

The public already has the doc you already wrote. This discussion is
about what the WG should produce.

There is no current list of threats in TCP. If this doc is intended
primarily at implementers, then we should consider splitting out the doc
that talks about the threats as a separate doc.

As to the current organization, I've proposed one that's hierarchical
and has things in predictable places. The current outline is mostly
flat, and has things in multiple places. Do you have a proposal to
organize the current outline into an alternate hierarchical structure?

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 03 Sep 2009 14:40:28 -0300

Hello, Toby,

> current ToC is too long... 3 pages of ToC is excessive. 

Well, it's a large document. Even If we reduce the number of top-level
sections, the ToC would most likely still be that large (or it wouldn't
be useful).

> I think the
> into memory management, etc). 

I agree. Please let me have another look, and try to come up with something.

> This is separate to any consideration as

I don't think this is what Joe raised. For the most part, he argued to
organize the information on a per-attack-type basis. Anyway, you did
raise it... so,.. point taken.

> security threats" or "Guidance on secure implementation of TCP"

Point taken. How about "Guidance on secure implementation of the
Transmission Control Protocol (TCP)"?

Thanks!

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Fri, 4 Sep 2009 02:30:27 +0300

On 2009-9-3, at 20:40, Fernando Gont wrote:
So if this is entirely aimed at implementers shouldn't that be
> Transmission Control Protocol (TCP)"?

Personally, I'd avoid the word "secured" in the title and maybe in  
other places in the document. Maybe use "hardened" or "robust" or  
"attack-resistant" or something, but "secure" isn't quite accurate.

Lars

---

From: Joe Touch <[email-masked]>
Date: Thu, 03 Sep 2009 16:42:06 -0700

Lars Eggert wrote:
> Personally, I'd avoid the word "secured" in the title and maybe in other
> places in the document. Maybe use "hardened" or "robust" or
> "attack-resistant" or something, but "secure" isn't quite accurate

Guidance to Mitigate TCP Implementation-Based Vulnerabilities

This makes more sense to me if this is indeed focused on
implementation-based vulnerabilities, rather than general security threats

If this is all the ways an implementer can avoid security threats in
general, then I reiterate my suggestion that we need a security
vulnerabilities doc.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 09 Sep 2009 02:36:21 -0300

Hello, Toby,

Comments in-line...

> current ToC is too long... 3 pages of ToC is excessive. 

For the most part it's a three-page ToC because it's a 130+ page
document. So no matter how the sections are reorganized, I don't think
the ToC will get much shorter.....

> management, 

I have no problem with this. Probably the only drawback is that the
corresponding sections will have a depth of four sections (i.e. one more
level). But that shouldn't be a problem. Please let me know if you still
feel this would improve the document, and I'll apply this change.

> buffer management and re-assembly could probably be grouped

If you are referring to Section 7 and Section 8, one might argue that
those are two different issues. Buffer management is memory management.
Segment reassembly algorithm (Section 8) is about e.g., what you do if
you get segments that overlap (which does not really have anything to do
with how you manage memory). Nevertheless, if you have any specific
proposal on how to merge these two sections, please let me know.

Thanks!

Kind regards,