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

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Apr 2009 15:31:05 -0300

Joe Touch wrote:

> I'm not at all clear that the WG needs this document. 

Yes, we still have the option to ignore that vendors have had to figure
out by themselves how to produce a resilient implementation of TCP,
because the current IETF advice regarding this issues is close to null.

So we had tcp-secure in 2004, icmp-attacks in 2005, a claim for a
trivial attack in 2008 (Outpost24/CERT-FI), and we'll probably continue
in this line, because we do nothing about it.

> It summarizes issues already raised by the WG, 

I believe this statement is unfair with respect to our document. e.g.,
has the issues described in Section 4.3, Section 9.2, or Section 10 been
brought to tcpm before???

> and makes recommendations (IMO) in
> excess of what the WG has agreed upon for general use.
> 
> TCP itself is not a secure protocol, nor is it intended to be.

Yeah. But that does not mean that we should not do our best to improve
it. Please talk to vendors. I don't want to reproduce here what seems to
be the consensus among vendors with respect to the current state of
affairs in terms of how up-to-date our specs are.

Please let me know which implementations do not aim at doing this. If
you know of any, please produce a fingerprint for nmap, and post an
announcement to bugtraq/full-disclosure. The ecosystem will probably do
the rest to get them updated.

> IMO, if there are operational issues with deploying TCP in environments
> under attack, that is an OPSEC issue.

Yeah... problems with deploying it in the current Internet....

If tcpm agreed that opsec will be a better venue for this document, I'll
be glad to pursue this effort there. At this point, tcpm and opsec are
two possible options, with no preference for any of the two.

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

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Apr 2009 11:42:20 -0700

> in this line, because we do nothing about it.

Whether we have this document or not, we will continue to have people
who incorrectly assume that TCP is secure.

> brought to tcpm before???

I didn't say that's all it does ;-) Agreed that it raises other issues,
many of which are operational.

> it.

It means we should not try to give the incorrect impression that it
*can* be secured. Interpreting every unexpected event as an attack makes
a protocol robust but also brittle; TCP is intended to trade flexibility
for security, AFAICT, because it is agnostic about intent, and gives the
benefit of doubt at all times. This is a basic principle of design of
our protocols - we are "liberal in what we receive" exactly because we
do not interpret malicious intent where error could have occurred.

Consider packet drops. That can happen due to loss, non-malicious
corruption, or jamming, e.g. In the last case, it makes sense to blast
copies of packets in the hopes of getting something through, but that's
NOT what we assume.

> Please talk to vendors. I don't want to reproduce here what seems to

Vendors misapply our protocols then complain that they don't work. Yes,
there are operational issues, but one severe operational issue is not
using security for some policy, financial, or operation expense and then
complaining that nonsecure TCP is being attacked.

...
> Yeah... problems with deploying it in the current Internet...

Not every TCP everywhere is under attack. If it were, you wouldn't be
reading this message.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Apr 2009 16:23:05 -0300

> who incorrectly assume that TCP is secure.

That's correct. But we also have people that do know it is not mean to
be secure, but that it should be resilient enough so that it's still
usable. One way or another, most stacks implement counter-measures for
SYN-floods (on which tcpm did publish something), timers on the
FIN-WAIT-2 state, port randomization (on which tsvwg is working), ICP
ISN randomization, etc.

The reason for which they did that was to improve TCP's security/resiliency.

Would you argue in favour of predictable ISNs, predictable ports,
time-less FIN-WAIT-2 state, etc.? -- I hope you wouldn't.

> many of which are operational.

Many of which arise if you expect to use TCP in some other scenario that
just two computers in a LAN. If that makes those issues "operational", I
agree.

> *can* be secured. 

It's security/resiliency can be improved. After all, if that were not
the case, I guess you're wasting your time with TCP-AO. Or is it that
you believe the only way to improve a protocol is to throw crypto at it?

> Interpreting every unexpected event as an attack makes
> benefit of doubt at all times. 

I would prefer that instead of making this type of broad statement, you
would argue against a particular recommendation in
draft-gont-tcp-security, and explain how it makes TCP more brittle.

> copies of packets in the hopes of getting something through, but that's

Wasn't this very behavior what lead to the Internet congestion collapse
in the 80's, or am I missing something?

> complaining that nonsecure TCP is being attacked.

Joe, we're talkng about a simple web server being taken down because of
a SYN flood, a FIN-WAIT-2 flood, or the like. Even the most stupid web
server should survive these types of attacks.

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Apr 2009 18:03:11 -0300

Smith, Donald wrote:

>>>> be the consensus among vendors with respect to the current
>>>> state of affairs in terms of how up-to-date our specs are.
> I talk to vendors a lot. I don't think there is a consensus on the
> "how up-to-date our specs are".

The consensus seems to be that the current state of affairs is something
like: "a mess". Even if you do care to produce a resilient
implementation, that task is going to be much harder than necessary. You
don't know the amount of cycles we spent in producing
draft-gont-tcp-security.... let alone the time it would take to move the
advice in an actual implementation.

> I can't even get a straight answer on how they addressed the
> icmp-blind resets or the tcp-blind resets from several years ago.
> There were several possible mitigations with some trade offs on each
> of them. Yet finding out how your favorite vendor addressed those is
> likely to be difficult.

In many cases the lack of a straight answer may have to do with us being
unable to get to consensus and get something published in a timely
fashion. e.g., the last round on ICMP attacks against TCP was circa
2004. At that point an I-D was published on the subject (now
draft-ietf-tcpm-icmp-attacks). Yet we're still nitpicking on it, when
everybody did something about it five years ago.

It becomes harder to get s staright answer when it's impossible for a
vendor to point to a counter-measure that is supposed to be the result
of a thorough review process, in a *timely* fashion.

I'm aware there's an effort in the vendor community to improve the
resiliency of TCP basedon the document published by UK CPNI. Yet we're
still debating whether to ignore it or not.... maybe so that we can
publish an RFC in the future tagging those implementations as
non-compliant... or maybe to allow tcp vulnerabilities to be
"rediscovered" every few years.

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Apr 2009 14:02:14 -0700

> time-less FIN-WAIT-2 state, etc.? -- I hope you wouldn't.

These measures can be used to reduce the impact of attacks when TCP is
not secured. However, they DO NOT make TCP secure. They DO make TCP more
brittle - they limit the way in which two legitimate endpoints can do
legitimate things.

> just two computers in a LAN. If that makes those issues "operational", I

Many of those don't arise for computers in a wide area, or with millions
of other computers on the network either. They arise only when there are
active attacks, and only for some kinds of attackers (on-path, off-path,
high-speed access, etc.)

IMO, any decision which would be enabled or disabled depending on
whether security was a concern or performance was needed is operational.
E.g., port randomization helps only when attackers are off-path and when
port use is a fraction of the active port space. That's operational.
Ditto for ISN randomization.

I.e., if the protection is not needed in the absence of attacks, it may
be operational.

> you believe the only way to improve a protocol is to throw crypto at it?

I *know* that the only way to secure a protocol is to throw crypto at it.

I also *know* that unexpected packets are *not* indications of attacks.

These two things are not evident in this document, and should be.
Further, this document should make a case as to whether the improvements
are operational or not. AFAICT, most are operational.

> draft-gont-tcp-security, and explain how it makes TCP more brittle.

Randomizing ports and ISNs assumes there is a window over which some
values are NOT used; that window precludes legitimate exchanges from
occurring. That is what I mean by "brittle."

> in the 80's, or am I missing something?

Loss of a segment can mean:
	a) congestion (correlated drops)
	b) non-correlated drops (not related to increasing traffic)
	c) active removal (attack)

If (a), then you backoff. That's how congestion collapse was addressed.

If you believe that packet drops are caused by either non-correlated
drops or active removal, you send MORE - you send copies of each packet,
e.g. That is NOT what we assume, but what I presume you ought to
recommend in a document that assumes that every event that COULD have
been an attack probably is an attack.

> server should survive these types of attacks.

If you're talking about implementation advice (don't put all your
resources in pending connections), I agree that a good implementation
should be implemented well. But that's operational / implementation
advice, not protocol advice.

I do not agree that all web servers should implement SYN cookies, e.g.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Apr 2009 14:08:38 -0700

Donald,

I'm confused by your post. You appear to believe that TCP is intended to
be secure. Note that TCP does not require either the MD5 or AO extension.

Smith, Donald wrote:
> 
> (coffee != sleep) & (!coffee == sleep)
> [email-masked] gcia   
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] 
>> On Behalf Of Fernando Gont
>> Sent: Monday, April 13, 2009 1:23 PM
>> To: Joe Touch
>> Cc: [email-masked]; [email-masked]; Joe Abley; [email-masked]; 
>> Lars Eggert; Eddy,Wesley M. (GRC-RCN0)[Verizon]
>> Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security
>>
>> Joe Touch wrote:
>>
> Secure is a general term. TCP was intended to address several areas of security.
> The classic tenets for computer security is:
> CIA -> Confidentiality, Integrity and Availability.
> TCP doesn't attempt to address Confidentiality.
> However it was designed to address integrity and availability so 
> failures in those areas should be documented and addressed in some
> fashion.

Can you explain this? Where is the integrity protection? Where is the
availability specified?

...
> Adding crypto improves confidentiality and integrity but is counter
> productive to availability as most
> crypto engines are prone to fairly low pps resource exhaustion
> attacks.

All prevention methods are susceptible to computational resource
attacks, since all increase the operations performed on a packet. It is
commonly assumed that this is a desirable tradeoff, and that the
computational resources can be totally protected with line-rate
dedicated computation (e.g., hardware assist).

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Apr 2009 14:16:48 -0700

> advice in an actual implementation.

Advice in making a hardened version of TCP would be useful to the
implementation community.

However, if you're saying that TCP specs in general are a mess, yes they
are. That's why we created a roadmap document, and why it needs to be
maintained. If you're suggesting we need a clean single documentation of
what TCP is, I might even agree. However:

	1) TCPM is not the place that would generate it
	(IMO, that'd be TSVWG)

	2) this document is not a step in that direction

You've produced a summary of issues you feel would harden TCP. I feel
that some of them make TCP more brittle, and some make TCP unnecessarily
complex, and in both cases the mods are not needed in the general
Internet. TCPsecure is a good example; it has caveats in its ID that
indicate where it is useful and where it is not -- it is NOT a general
solution for the entire Internet (the WG basically agreed to that with
the wording for its use cases).

> everybody did something about it five years ago.

Uh, well, we're deciding whether we agree with what's been deployed.
Deploying some of these changes hasn't always been a good idea; if it
were, we'd be agreeing to it.

> of a thorough review process, in a *timely* fashion.

Can you be as specific here as you want us to be? What exactly does a
vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing
known countermeasures?

> "rediscovered" every few years.

If the vendors are following this doc already, then we REALLY need to
ensure it's updated with advice appropriate to the context in which it
is deployed. Running around saying the sky is falling for everyone isn't
going to help.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Apr 2009 19:16:31 -0300

> implementation community.

To a large extent this is what draft-gont-tcp-security is about.

> 	2) this document is not a step in that direction

The tcp roadmap is a roadmap to the documents that the IETF has
published. There's lots of stuff that has not been published by the IETF
and that therefore is not discussed in the tcp roadmap.

This is another area in which this document tries to help.

> Internet.

Is there nothing in the document with which you agree?

> TCPsecure is a good example; it has caveats in its ID that

c'mon Joe.. IMO, tcpsecure needed to include those statements about
usefulness in large part because it was IPR-encumbered, and in part as a
political workaround that would avoid further waste of time in endless
discussions.

> were, we'd be agreeing to it.

Some people prefer to get work done instead of committing/wasting lots
of cycles in endless discussions.

> vendor want that isn't provided by IPsec, TCP MD5, etc., or the existing

What's "the existing known counter-measures"?

> is deployed. 

FWIW, vendors are following the UK CPNI document. The idea of bringing
those results to the IETF is so that these results/advice can be further
discussed, more eyes look into them, and the doc is modified if it is
felt necessary.

> Running around saying the sky is falling for everyone isn't
> going to help.

Who did that? We worked on this document very silently for a couple of
years. If we had wanted that "sky is falling" approach, we would have
gone to the press before showing anything (like quite a few folks have
been doing in the recent past). Or we could have announced part of this
stuff as "vulnerabilities" to the press..

That wasn't the case.

I tried to get many people to review the document, and have the document
be as objective as possible. At least for the ip-security counterpart, I
recall asking you to have a look at it before publication, even when I
knew that you'd most likely disagree with large parts of the document.

This project is already done.... but nevertheless I'm still spending
some cycles to bring this to the IETF, because I truly believe the IETF
should work on it. Neither me nor UK CPNI have IPRs or anything on the
material covered in our document... so there's no hidden motivation in
all this.

Honestly, I'm not sure why you always have to knock down others' efforts
on a "by default" basis, and prejudge the motivation behind those efforts.

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Apr 2009 15:23:00 -0700

Smith, Donald wrote:
...
>> Checksumming in tcp/ip is intended to provide intregrity protection.

Error protection != integrity protection. Anyone can reconstitute the
checksum, so it is not an integrity mechanism.

>> Mind you it is NOT tamper proof but that is the intent.

What is your definition of integrity? Mine means some assurance that
what was sent is what is received. Anything that any intermediary can
reconstitute trivially is not protected.

>> Detection of lost packets, retransmitions, reassembly of fragments,
>> congestion notification, dynamic routing and many other tcp/ip features
>> are intended to address availablity.

The first group (loss detection, retransmission, reassy) address links
with errors, not 'availability' in the usual sense. The second set might
apply, but aren't part of TCP per se (TCP uses the absence of info to
indicate congestion, not the presence, at least in the required base of
the protocol).

> attacks, since all increase the operations performed on a 
> packet. 
>> GTSM is a valuable exception to this statement but other then that I tend to agree:)
> 
> It is
>> I believe that is a common assumption however I don't believe that assumption is correct.
>> I do a fair amount of router testing and although some portions of
>> ipv4 are hardware assisted and therefore line-rate there are still many
>> paths to the "slow path". IPv6 has many more routes to the slow path:(

First, I'm speaking of hardware crypto assist. I'm assuming fast-path
packets. Slow-path packets are self-correcting in many routers - they're
dumped when their queue overflows, or are simply processed *very*
slowly. If you care about computational resources, you put in line-rate
hardware, period.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 13 Apr 2009 15:38:17 -0700

> To a large extent this is what draft-gont-tcp-security is about.

Implementation advice is outside the scope of the IETF. It's not even
operational, IMO.

> This is another area in which this document tries to help.

Those are documents that the IETF may or may not agree with. Neither
"Implemented" nor "published" doesn't mean we should endorse that solution.

> Is there nothing in the document with which you agree?

That'd be harsh. I agree with some of the implementation advice as
implementation advice. I agree that, in risk-prone environments (where
packets can be tapped, e.g.), some of the recommendations are appropriate.

I'm disagreeing primarily with the general tone and balance of the document.

> political workaround that would avoid further waste of time in endless

I disagree. Even if it weren't IPR encumbered, I would disagree with
widescale deployment of a modification to TCP that answers a RST with
one *or more* ACKs. As I said numerous times w.r.t. that document, the
modifications it suggests are generally not needed, unnecessarily
complicate packet processing, and since they don't protect from
in-window injection attacks, I find them useless in the general case.

> of cycles in endless discussions.

Publishing recommendations without validating them isn't wasting time.

> What's "the existing known counter-measures"?

Limit cycles/resources available for new connections, e.g., for SYN
attacks -- as is already done for things like IKE.

> discussed, more eyes look into them, and the doc is modified if it is

I've been saying I feel that mods are necessary, and you keep
complaining. If you're here for a rubber stamp, you came to the wrong WG ;-)

> stuff as "vulnerabilities" to the press..

The sky has been falling in this WG for several years. Although this
document is the first aggregation of such recommendations, as you know
it's composed of many documents you yourself have been discussing for
that period in this WG..

> on a "by default" basis, and prejudge the motivation behind those efforts.

I'm asking the question I apparently keep needing to ask:

	Why do you think that just because something is implemented
	we should recommend it?

	Why do you think that a message that isn't expected indicates
	an attack to be defended against, vs. the actions of a
	benign endpoint?

For this document, yes, this means:

	Does the IETF need such a document at all?

	If we do need such a document, is this the right content?

I have a high bar for the need for modifications to TCP, and the need to
propagate local solutions to every endpoint in the Internet. That is the
approach I expect of others in this WG, and yes, I'll speak out when
it's not the case.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 14 Apr 2009 02:44:32 -0300

> Implementation advice is outside the scope of the IETF. It's not even

RFC 816: "MODULARITY AND EFFICIENCY IN PROTOCOL IMPLEMENTATION"
RFC 815: "IP DATAGRAM REASSEMBLY ALGORITHMS" (see Section 4)

and,

RFC 1936: "Implementing the Internet Checksum in Hardware" (of which you
are on of the co-authors :-) )

That said, to a large extent the document is provides advise about
enforcing stricter validation checks, timeouts where appropriate, and
about a number of policies that may improve TCP's resiliency/security
(e.g., how to select ISN's, etc.)

> I'm disagreeing primarily with the general tone and balance of the document.

I believe at this point in time we're deciding whether it makes sense to
work on this document, and where it would make sense to do it.
draft-gont-tcp-security-00 is just a starting point. Of course, it
represents my pov, and to some extent the pov of the reviewers. But the
idea of bringing it to the IETF is that future versions of the document
represent wg consensus.

If you have specific suggestions on how to improve the document, I'll be
more than happy to hear about them.

However, I believe at this point we are not yet discussing on any
specific issue discussed in the draft, but are trying to agree on how to
move forward. (Feedback on the technical details in the document is
nevertheless welcome, though)

> in-window injection attacks, I find them useless in the general case.

TCP is already very complicated. And the implementation of the
countermeasures in tcpsecure usually require not much more than
(literally) a couple of additional lines, or a slight modification in
some conditional statement.

> attacks -- as is already done for things like IKE.

At the point in which you actually try to put this into code, a number
of questions arise that need to be answered. Why should vendors rehash
the same analysis over an over again (with the potential of doing it
wrong, which would lead to buggy implementations), when we could put out
a document with consensus on the preferable way to do those things.

> complaining. 

That's not how I read your comments. If your point of view is "it would
be interesting to work on this. however, i believe the document should
be modified in this way, because of this reason" that's one thing.

If your pov is "we don't need this. go somewhere else", that's something
entirely different.

> If you're here for a rubber stamp, you came to the wrong WG ;-)

Rubber-stamp? No, Joe. The UK CPNI rubberstamp is more than enough, and
when it comes to advice on this issues, I believe it's even more
credible. Ask the question in bugtraq or full-disclosure, and that's
most likely the conclusion you'll get to.

I'm involved in the IETF, and honestly believe that the IETF should work
on this. I do know that the end result of that process would be such
that I probably won't be as happy with the resulting RFC than with the
UK CPNI document. But at least I would have helped to change the current
state of affairs a little bit.

> it's composed of many documents you yourself have been discussing for

I'd probably argue that the case with tcpm is that at (many) times
protocol specifications have been taken as if they were casted in stone.
And unless one is part of some small circle of people that is supposed
to have been allowed by God to modify such specs, it will be very hard
there's no effort that takes less than quite a few years.

Very loud people take the time to maintain endless discussions, and most
mere mortals that need to get work done end up completely avoiding tcpm
altogether, because it requires a huge spend of time.

Virtually every developer that I know of won't care about what the end
result in tcpm is. At most, they will post a question to hear comments.
But that's it. To a large extent people cannot believe the amount of
energy we spend for such a null progress.

Example: ICMP attacks draft (draft-ietf-tcpm-icmp-attacks).
The doc was reviewed by devolpers from Sun, FreeBSD, NetBSD, OpenBSD,
Linux, extreme networks, and Cisco (this last one "unofficially"). To
them, the draft looks okay. Many other people have also agreed with
that. But I cannot get those folks involved in our endless discussions.
The ROI for them is NULL.

Do they care about the outcome? Not really. They agree with the
proposal, it is in the code already, and has been running for years.
They just let us waste our time.

I agree that there are benefits to be gained from having a more
conservative philosophy, to put it some way. I believe that it is a good
thing to challenge proposals, to aim at improving their quality, etc.
This has helped improve many documents, including those I have authored.
But I believe at some point it starts looking as "everything that
neither me or my inner circle proposes will be banned".

> 	Why do you think that just because something is implemented

That's not how the tcp-security document was produced. For instance,
many of the recommendations had never been implemented. And the document
argues *against* some common implementation strategies.

> 	an attack to be defended against, vs. the actions of a

We simply raise the bar about what we react to. If there are packets for
which there's no legitimate use, we don't react to them (if this doesn't
cause harm).

> propagate local solutions to every endpoint in the Internet. 

And do you believe that such propagation depends on our outcome? --
Thanks God, it doesn't. Try to find any implementation that is
fully-compliant with the RFCs, and let me know if you find any.

The lack of advice on all these issues has put vendors in a position in
which they have to figure out that advice by themselves. Sometimes they
got to the right answers, sometimes not.

Have a look at the vulnerability advisories referenced in the I-D: the
same errors are committed over and over again.

draft-gont-tcp-security is an effort to help the vendor/developer
community in that area.

P.S.: My apologizes for the possible politically-incorrect comments. But
this is the best trade-off I have been able to get between being
politically-correct and being honest.

Kind regards,

---

From: Lars Eggert <[email-masked]>
Date: Tue, 14 Apr 2009 10:55:41 +0300

Hi,

<all hats off>

> Implementation advice is outside the scope of the IETF. It's not even

I do believe there is value in having a document that would inform a  
stack vendor of various potential attack vectors against a TCP stack  
and what techniques exist to harden their stacks.

I agree with Joe that some of the hardening techniques that vendors  
are implementing come with consequences (make TCP more brittle). To  
me, this is a *reason* this document should be published via the IETF  
(i.e., TCPM) - we are probably in the best position to correctly  
evaluate and classify the impact of various hardening techniques.  
Stack vendors have been putting these mechanisms in to their stacks  
without clear specifications and discussions of the potential upsides  
and downsides that would let them make an educated decision. It seems  
clear to me that the vendor community is looking for guidance here,  
and I do believe the IETF should give it.

Yes, there is a fine line here, where some of the hardening techniques  
introduce some new assumptions on what the segment flow of a valid  
connection looks like, etc. It will be important to accurately  
describe the downsides of some of these techniques, especially where  
they could result in valid connections being dropped.

Lars

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Apr 2009 07:20:28 -0700

> are on of the co-authors :-) )

Those are informational, you will note.

> (e.g., how to select ISN's, etc.)

Those 'validation checks' aren't validations when they exceed the TCP
specifications.

> nevertheless welcome, though)

Agreed. I'm suggesting that there are several possible documents, with
different possible 'homes':

1. a document that focuses on implementing a hardened TCP
	that is outside the scope of the IETF, esp. where
	it exceeds IETF recommendations for modifications to
	TCP

2. a document that summarizes and streamlines TCP modifications
	i.e., this would be somewhat like a 793-bis;
	that's a huge undertaking, and would belong in TSVWG
	rather than TCPM

If this document is intended to be an IETF product, rather than an
informational individual contribution, it needs to reflect IETF consensus.

> some conditional statement.

The number of lines alone does not reflect the complexity issue; the way
it complicates interactions is.

> a document with consensus on the preferable way to do those things.

Showing a way to do something is useful; claiming it is preferred
requires consensus. The IETF doesn't specify preferred implementations;
it does give them as examples, but they tend to be in informational
individual documents rather than as WG product.

> If your pov is "we don't need this. go somewhere else", that's something

IMO, the IETF doesn't need to spend group cycles to work on how to
implement TCP efficiently or in safe ways. That's software engineering,
and may be a good idea or even a good individual submission, but not
what I think of as WG effort.

If this doc is intended to be a WG product, it needs to focus on
reflecting IETF consensus and recommendations. Its current focus is
"what is implemented", as if that is sufficient rationale.

...
> there's no effort that takes less than quite a few years.

We are conservative. We're talking about changes that affect the core of
the Internet, so that is appropriate. Whether a modification is accepted
as standards track or not is based on whether it is **generally**
needed, not whether it has been implemented or even deployed.

I'm not quite sure of what small circle you're referring to, but the
primary mods to the standards track over the past few years have been in
ways that were supported by a large pile of analysis, e.g., increasing
TCP's initial window. When people come without that pile, they're
challenged. A pile of code is not a substitute for a pile of analysis.

> neither me or my inner circle proposes will be banned".

TCPM exists as much to protect TCP from tweaking as it is to mature
proposed tweaks. The more tweaks anyone proposes, the more they get
challenged. The less analysis behind the proposals, the more they get
challenged. Deployed code is not a substitute for analysis.

It's unfortunate if you feel personally affected by that approach, but
it's simply cause and effect. **ALL** documents in this WG are
challenged, and the bar in this WG is higher than in other WGs - and it
should be.

If your goal is making progress more quickly, you need to create your
own protocol to modify.

> argues *against* some common implementation strategies.

Agreed; those are not the parts I'm as concerned with.

> which there's no legitimate use, we don't react to them (if this doesn't

When a packet arrives that *could* have been legitimate, i.e., for which
there is *any* legitimate use, you have an obligation to react to it. I
don't agree that some of what you're proposing takes this into account.

> draft-gont-tcp-security is an effort to help the vendor/developer

I agree that vendors need some sort of implementation advice. I don't
agree that the IETF needs to be the place where that is made.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Apr 2009 08:30:09 -0700

Inline...

> Given that this is opsec and that my major concern is the network elements 
> I am much more concerned about "off-path" or "blind attacks" then direct attacks.
> Customers generally don't attack the router they are connected to.
> Peers generally don't attack the router they are connected to.

Some routers are on shared-access media. Other routers are connected
across unsecured network elements - e.g., to network management
components, etc. On-path doesn't mean directly connected on one hop - it
includes the entire path.

...
> Now I think I understand what you mean by secure.
> I don't agree with your opinion. For example SSL is a form of encryption 
> but has done little to
> secure http as sites have trained customers to ignore cert errors.
> Banks put lock bitmaps on their pages to show how "safe" they are.
> Phishers depend on this user confusion!

Mechanism cannot compensate for users that ignore it.

> In the router world packets destined towards my routers that are
> "unexpected" are often an indication of attack or a misconfigured
> system either can cause problems for the network and blocking it
> TOWARDS the router is a BCP.

I'm talking about expectations within a TCP connection, or about the
establishment of TCP connections. This doc addresses TCP, not the
Internet in general.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 14 Apr 2009 15:13:43 -0300

Lars Eggert wrote:

> I agree with Joe that some of the hardening techniques that vendors are
> implementing come with consequences (make TCP more brittle). To me, this
> is a *reason* this document should be published via the IETF (i.e.,
> TCPM) - we are probably in the best position to correctly evaluate and
> classify the impact of various hardening techniques. Stack vendors have
> been putting these mechanisms in to their stacks without clear
> specifications and discussions of the potential upsides and downsides
> that would let them make an educated decision. It seems clear to me that
> the vendor community is looking for guidance here, and I do believe the
> IETF should give it.

This is the reason for which the output of the CPNI project was
submitted as an IETF I-D.

Kind regards,

---

From: "Smith, Donald" <[email-masked]>
Date: Mon, 13 Apr 2009 13:55:30 -0600

However it was designed to address integrity and availability so failures in those areas should be documented and addressed in some fashion.

> >>> TCP itself is not a secure protocol, nor is it intended to be.
Again, it was intended to help ensure integrity and availability.

> > It means we should not try to give the incorrect impression that it
It can be made better that is not an incorrect impression it is a fact.

> you believe the only way to improve a protocol is to throw 

Adding crypto improves confidentiality and integrity but is counter productive to availability as most 
crypto engines are prone to fairly low pps resource exhaustion attacks.
 
> >> affairs in terms of how up-to-date our specs are.
I talk to vendors a lot. I don't think there is a consensus on the "how up-to-date our specs are".
I can't even get a straight answer on how they addressed the icmp-blind resets or the tcp-blind resets from several years ago. There were several possible mitigations with some trade offs on each of them. Yet finding out how your favorite vendor addressed those is likely to be difficult.

> > complaining that nonsecure TCP is being attacked.
Again the use of a generic "secure". What do you mean by "nonsecure" here?

> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec
>

---

From: Todd Glassey <[email-masked]>
Date: Tue, 14 Apr 2009 12:21:23 -0700

> submitted as an IETF I-D.
Yeah - so then this would be tested across all of the local TCP 
implementations including the MS, AT&T *(i.e. Lachman Associates Inc) 
and possibly Mentat's fast system?
> Kind regards,
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.0.238 / Virus Database: 270.11.57/2059 - Release Date: 04/14/09 14:52:00
>
>

---

From: Lars Eggert <[email-masked]>
Date: Wed, 15 Apr 2009 10:17:19 +0300

Hi, Todd,

> and possibly Mentat's fast system?

Nothing would be "tested", the IETF isn't in the business of auditing  
TCP stacks. What we're talking about is describing attack vectors,  
potential countermeasures and the the impact (downsides) those  
countermeasures might come with. Implementors will need to decide for  
themselves if and how to apply any of these techniques to their stacks.

Lars

---

From: Todd Glassey <[email-masked]>
Date: Wed, 15 Apr 2009 07:47:09 -0700

Lars Eggert wrote:
>>>> are
> TCP stacks. 
Yo Lars Good-morning, let me respond. "Sure it is..." let me amplify -

Don't the IETF standards processes "require the development of two or 
more independent implementations of any given protocol specification and 
the associated interoperability testing to document that the suite runs 
as advertised in the specification?" - I generally refer to that as IOT 
(Inter-Operability Testing). And for what its worth the IETF's mergence 
towards a leading edge standards process also reinforces the importance 
of that testing too by the way.

By comparison, in trailing edge standards processes the IOT is 
accomplished in the various implementations which are done in the 
industry. In leading edge models where there is genesis happening the 
testing would have to be included in the implementation of any 
prototypes of the stack or system and its operations.

This IMHO is the real issue with the worlds abuse of the IETF's 
processes - they seem to think that RFC's are standards and there are 
many here who use that to substantiate their technological advantage in 
their marketing, meaning that they derive financial value from 
misrepresenting this to the commercial community as well I think. The 
fix for that is to make RFC's unreliable for use as a protocol 
specification for anything other than a Standards Track effort as they 
should be - a Request For Comments rather than something the Trust's 
selling access to.

Todd Glassey
> What we're talking about is describing attack vectors, potential 
> countermeasures and the the impact (downsides) those countermeasures 
> might come with. Implementors will need to decide for themselves if 
> and how to apply any of these techniques to their stacks.
Which would be filed as a Use Case Document as a set lf BCP's for a 
protocol stanadard. This by the way is where the real value of the IETF 
comes in - in also telling people how to and how not to use these protocols.

Todd

---

From: Lars Eggert <[email-masked]>
Date: Wed, 15 Apr 2009 18:14:13 +0300

Hi,

On 2009-4-15, at 17:47, Todd Glassey wrote:
> as advertised in the specification?"

this is required when moving from Proposed Standard to Draft Standard.  
(Also, what RFC are you quoting in the previous paragraph?) This  

> comes in - in also telling people how to and how not to use these  

Yes, it is likely that whatever the outcome is, the document would be  
published as Informational or BCP.

Lars

---

From: "Tom.Petch" <[email-masked]>
Date: Tue, 21 Apr 2009 18:44:51 +0200

----- Original Message -----
From: "Fernando Gont" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "'Joe Abley'" <[email-masked]>;
<[email-masked]>; "'Lars Eggert'" <[email-masked]>; "'Eddy,Wesley M.
(GRC-RCN0)[Verizon]'" <[email-masked]>
Sent: Tuesday, April 14, 2009 7:44 AM
Subject: Re: [OPSEC] [tcpm] draft-gont-tcp-security
> Joe Touch wrote:
<snip>

> >> discussed, more eyes look into them, and the doc is modified if it is
<snip>

> most likely the conclusion you'll get to.

Which is for me the crux of the issue.  This document is a done deal, let it go.

On the other hand, looking at the references, I see that while much of it is
based on IETF RFC, there are also a number of IETF I-D cited and I think that
our efforts would be better spent progressing these to RFC, after which, this
document may be worth revisiting.

Tom Petch

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Apr 2009 10:54:28 -0700

Tom.Petch wrote:
...
> Which is for me the crux of the issue.  This document is a done deal, let it go.

If the document is a done deal, it should not be published as an RFC -
individual or otherwise.

If the document is being proposed as a WG item, then modifying it to be
in line with the WG's viewpoint is not only appropriate, it is required.
What that viewpoint is will be determined in the WG by consensus, but
assuming that we cannot modify the document is a non-starter.

> document may be worth revisiting.

Not all of those RFCs or IDs are standards track or BCPs; some are
informational, and many give more conservative advice than this document
does. If this document is intended to reflect the sum of current IETF
views, then it is *definitely* not done.

Joe