Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security

From: Fernando Gont <[email-masked]>
Date: Mon, 01 Jun 2009 20:21:18 -0300

Lars Eggert wrote:

>> P.S.: Is there any specific proposal/advice to pursue this effort?
>> There's has been some talk about tcpm vs opsec, but so far it is not
>> clear to me how to proceed here.
> 
> if the IETF decides to work on this, I believe TCPM would be the most
> appropriate group, given that that's where the TCP expertise is. I'm
> fully OK with doing this in cooperation with OPSEC, maybe via a joint WG
> last call or other means, if they desire this.

Any plans on how to proceed? So far we have version -00 of the
individual submission, but it's not clear to me how to proceed....

> One question: If the IETF decides to publish a document in this space,
> and if you decide to offer draft-gont-tcp-security as a starting point
> for this work, are the UK CNPI and you as the author OK with the IETF WG
> obtaining change control? The WG consensus process would likely lead to
> changes compared to the current version, probably even significant changes.

Both UK CPNI and me are OK with the document being modified to reflect
IETF consensus. However, we do expect me to continue as the document
author, and UK CPNI to continue as the author's affiliation (there's
nothing unusual with this... but considering that strictly speaking once
a document is accepted by a WG the author may be changed, I'm just
clarifying that while neither UK CPNI nor me have problems with the
document reflecting WG consensus, we do expect the author (Fernando
Gont) and the author's affiliation (UK CPNI) to remain "as is").

Thanks!

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

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 03 Jun 2009 13:47:47 -0700

It's a tough question. In part I think the answer is up to you, I think
there's some understanding on the part of tcpm that if this work were to
progress on a standards track that tcpm (no opsec) is the place for that
to happen. That said there's also some question as what sort of general
recommendations about hardening tcp would actually be consider
acceptable (in narrow use cases a lot more of them may well be).

	The diligent blacksmith knows that hardening a tool also
	makes it more brittle...

The result of any such effort is likely to be greatly different than
what you have today.

An alternative track would have the document headed for informational
status either as a working group document or as indivdual submission
with an understanding of what sort of advice is provided and who should
consider it and the limitations of implmentation based on it's
recomendations. It still think exposure to a working group is very
important and useful in this context, as a purely independant submission
it's simply documentary evidence of the uk cpni's effort's at
documenting some percieved flaws in tcp and recomned mitigation strategy
which is useful but not dramatically better than putting it on a website.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Jun 2009 04:32:24 -0300

Hello, Joel,

Comments in-line...

> to happen.  

Ok. My proposal is, that unless there's any alternative proposal, I'd
like this document to be pursued as "Informational" within opsec.

> That said there's also some question as what sort of general

This is a nice quote, but... I'd like examples. e.g., start discussing
about which specific hardening proposal makes TCP more brittle.

> The result of any such effort is likely to be greatly different than

That's not a problem.

> important and useful in this context, 

Ok. Good. As I mentioned, unless somebody else comes up with an
alternative proposal, I'd like the document to target "Informational" at
opsec. I guess that at some point tcpm may want to work on some of the
stuff in the document on a piecemeal basis.

> as a purely independant submission

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Jun 2009 06:42:27 -0700

Fernando Gont wrote:
...
> about which specific hardening proposal makes TCP more brittle.

1) any security mechanism that increases complexity - of actions, state,
or message exchanges - any of which increases the potential for
implementation error

2) any security mechanism that has false positives, i.e., that discards
messages deemed a security threat when they were sent for legitimate reasons

#1 includes basically everything, from TCP MD5 (and TCP-AO) to tcpsecure
and ICMP filtering

#2 includes anything with nonzero false positives, such as tcpsecure and
ICMP filtering

I.e., AFAICT, *everything* that makes TCP more secure also makes it
brittle, by definition (ditto for metal hardening, FWIW). The key issue
is "when/where is the benefit worth the cost".

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Jun 2009 16:36:23 -0300

> or message exchanges - any of which increases the potential for

Agreed.

> messages deemed a security threat when they were sent for legitimate reasons

Why would this make e.g., TCP more brittle?

In any case, the actual response to such packets may vary (e.g., in the
case of ICMP hard errors, discard vs. process as soft errors). I believe
that no matter what the recommended response is, it is important to
discuss these issues, and try to get consensus on what's the right thing
to do in each case.

> #1 includes basically everything, from TCP MD5 (and TCP-AO) to tcpsecure

ICMP filtering actually decreases complexity.

> is "when/where is the benefit worth the cost".

As I said before, I'd like to have concrete examples from the tcp
security i-d that are deemed to make TCP more brittle.

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Jun 2009 13:06:37 -0700

> Why would this make e.g., TCP more brittle?

It makes a TCP that used to work not work anymore.

> discuss these issues, and try to get consensus on what's the right thing

Agreed. In a document that aimes to describe just what has been
implemented, there's no goal of gaining community consensus, though.
There is still utility, however, in providing the alternate viewpoint on
the potential impacts of implementations.

> ICMP filtering actually decreases complexity.

It requires more code to check that an ICMP is in-window than to not
check. Nearly everything requires more code, at least.

> security i-d that are deemed to make TCP more brittle.

I did above in both cases.

Joe