Subject: [tcpm] poll for adopting draft-gont-tcp-security

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Wed, 24 Jun 2009 14:25:04 -0500

TCPMers, there was a thread a while ago about working on
draft-gont-tcp-security in this working group that didn't
conclusively give us a feeling one way or other:
http://www.ietf.org/mail-archive/web/tcpm/current/msg04489.html

Basically, my understanding is that there are at least a
handful of people in the WG that think it should be done
here as a WG item (more likely for Informational rather
than BCP), and there are also some expressed opinions on
why it shouldn't.

Given the raw size of the document, if the WG intends to
take this document on, then we need some people to clearly
commit to putting cycles into review and contributions to
the document.  Since it is quite large, and to my knowledge,
there hasn't been a specific technical review of the content
on this list, but just discussions about if the idea in
general is a good or bad thing, we still need to know if
people are willing to invest their time and energy in this.

Please let us know if there is traction for this in the
near term, and/or we can also discuss it in Stockholm.

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

---

From: Matt Mathis <[email-masked]>
Date: Wed, 24 Jun 2009 20:11:27 -0400

THIS DOCUMENT IS EXTREMELY DANGEROUS:: It is based in the same mindset
that successfully killed ECN before ECN was even conceived.  The basic
point of view is that firewalls should discard all traffic bearing
features that are not explicitly permitted by todays standards.

I read all of 2 pages before I found something that, if significantly
deployed, would haunt some Internet users for a very very long time (p
43, SACK resource exhaustion).

I fear that we can not afford to do anything except go over this
document with a fine toothed comb and correct it.  Any other response
(such as trying to dismiss it) is likely to have the consequence that
is it adopted by some other standards organization, and that TCP will
become frozen forever at it's current state of brokenness.

And then all of us who think TCP might still be improved may as well
just go home and retire, because nothing that we want to try will be
permitted by standard conforming firewalls.

No I really don't want to work on this document, but I am not ready to
retire yet, so I guess I will.

Think of it a huge gray-matter tax imposed by one standards
organization on another.

Thanks,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319   Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by mortals who think they know
"The Truth" and use force to apply it to others.

On Wed, Jun 24, 2009 at 3:25 PM, Eddy, Wesley M.
(GRC-MS00)[Verizon]<[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 24 Jun 2009 19:41:53 -0700

Hi, Wes,

> people are willing to invest their time and energy in this.

I have already provided specific technical feedback to Fernando on this
doc; I'll be glad to post them here if desired.

If the WG works on this *issue*, I would be glad to contribute cycles.
I.e., start with a blank page and put in only what the WG agrees to.

If the approach is to start with this doc and the burden of proof is on
the other contributors and the WG to take things out that we disgree
with, I fear that would be a very inefficient use of our time, and would
hesitate to participate until it had been vetted a few times by others.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Jun 2009 22:57:24 -0300

Hello, Matt,

I just wanted to make a few clarifications wrt the aforementioned document:

1) It wasn't written with the same mindset that killed ECN. Simple
counter-example: read the section on the "Reserved" bits, as I pointed
out on my post to the tcpm list.

2) UK CPNI is not a standards organization. It's a defense organization
from the UK (http://www.cpni.gov.uk). That of bringing the document to
the IETF was my personal idea (as I have been involved with the IETF for
the last 5 years or so), which CPNI accepted in the hopes of
contributing to the work the IETF does.

3) I have tried to get as many people review the document (or even look
at it) since a couple of years before the very first version of this
document was published. Some accepted, some didn't. e.g., I recall
asking both you and Joe about this document, but failed in my attempt.
Others agreed (as you may see in the Acknowledgements section). I think
that that means I wasn't just giving pedantic advice, and did try to get
that advice challenged.

4) The reason for bringing this document to the IETF is to further
discuss the issues that me and the reviewers have discussed. Chances are
that you may find something you don't agree with -- for instance, that's
the motivation of submitting this paper as an IETF I-D in the first
place. And it's okay and productive (I think) to further discuss any
issues anybody raises. That said, I don't think that makes it fair for
the document to be tagged as "extremely dangerous".

That said, your input would be really welcome.

Thanks!

Kind regards,
Fernando

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Jun 2009 05:23:41 -0100

Matt Mathis wrote:

> that successfully killed ECN before ECN was even conceived.  

Please read e.g., page 24 (Section 3.6.1) and let me know if this is the 
same mindset. Here's an excerpt of the aforementioned Section:

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

    Therefore, we recommend implementations to simply ignore the Reserved
    field."

> The basic

This document provides advice for host implementations, not for firewalls.

> 43, SACK resource exhaustion).

I guess you are arguing against the proposed limit of 16 for the maximum 
number of sack holes? I understand you could argue that this value 
could/should be raised. However, IIRC I based my proposal on existing 
data on the number of holes.

FWIW, NetBSD and others already enforce limits for this. See
the "net.inet.tcp.sack.maxholes" sysctl (which defaults to 32) in
http://osdir.com/ml/netbsd.ports.x86-64/2006-05/txtdA8OHygdEK.txt

You may even be more interested in the 
"net.inet.tcp.sack.globalmaxholes", which defaults to 1024.

Other systems (e.g., FreeBSD) already enforce limits, too.

So... why instead of knocking the document down altogether, we discuss 
e.g., whether the proper limit should be something else?

I guess/hope you are not arguing against enforcing limits, but about the 
specific value proposed in the I-D. And the reason for submiting this 
I-D as a IETF I-D is exactly to discuss these issues and get consensus 
on e.g., what the proper/safe value should be for this limit.

> retire yet, so I guess I will.

Thanks.

> Think of it a huge gray-matter tax imposed by one standards

I really don't understand this statement. The only standard organization 
involved in this is the IETF. UK CPNI is *NOT* a standards organization 
(please see http://www.cpni.gov.uk).

Thanks,

---

From: Matt Mathis <[email-masked]>
Date: Mon, 29 Jun 2009 13:12:42 -0400

Fernando Gont wrote:
> Please read e.g., page 24 (Section 3.6.1) and let me know if this is 
> the same mindset. Here's an excerpt of the aforementioned Section:
>
>    with virtually every field,
--Snip--
Consider sect 4.4.1, SACK-permitted option length must be 2:  This 
forbids ever extending SACK by adding a subtype, for example to 
negotiate non-renege-able SACK, by putting a 1 in an optional sub-type 
carried in additional bytes in the SACK-permitted option.  As far as I 
know every implementation today correctly parses the option length (e.g. 
skips forward by the relevant amount), but ignores the option data, so 
such a change would be backwards compatible with all existing 
implementations.

Even though this is not the target audience, the mere existence  of 
these  documents increases the chances that some over eager firewall 
implementer will add the check to some future pix-bis-bis, and our 
ability to extend SACK might be gone forever.

> This document provides advice for host implementations, not for 
Sorry, I didn't read the introduction.   But I would not assume that 
host implementors  would be the only readers.
> I guess you are arguing against the proposed limit of 16 for the 
> maximum number of sack holes? I understand you could argue that this 
> value could/should be raised. However, IIRC I based my proposal on 
> existing data on the number of holes.
>
> I guess/hope you are not arguing against enforcing limits, but about 
> the specific value proposed in the I-D. And the reason for submiting 
> this I-D as a IETF I-D is exactly to discuss these issues and get 
> consensus on e.g., what the proper/safe value should be for this limit.
The current limits are workaround for using inappropriate algorithms for 
maintaining the  SACK scoreboard.   The easy way to implement the 
scoreboard has cost O(N^2).  However there is at least one OS that uses 
an O(N*ln(N)) scoreboard, and O(N) might be possible.  (These are the 
total cost of the worst case recovery at window size N, so O(N) total 
cost is constant cost per ACK.)

If you have a moderately fast continental  scale Ethernet (1500 Byte 
MTU, 1 Gb/s, 100 ms RTT), you need a window size of 9000-18000 
packets.    Slow start typically loses ever other or every third packet, 
so you might hypothetically need to recover from 3000 to 9000 holes 
following a slow-start.    Telling host implementers that they should 
limit the number of holes rather than investing in better algorithms is 
pushing them in the wrong direction.   Kludges in existing 
implementations, or arguments about typical users are no excuse to tell 
implementers that they should not do this correctly for all users, 
including users who need the very highest performance.

Here is a hint about RFC 2018 (which probably applies to many other 
RFCs):  Every single SHOULD is a clue that we knew of something that 
might be done better than permitted by the document at hand.   Going 
through a spec and "tightening" it, by changing SHOULDs into MUSTs, is 
guaranteed to close of opportunities for improvement (although  some 
might be closed already for other reasons).

> I really don't understand this statement. The only standard 
> organization involved in this is the IETF. UK CPNI is *NOT* a 
> standards organization (please see http://www.cpni.gov.uk).
Yes, but it issued a document full of advice to implementers, that has 
the potential to have lasting negative repercussions.  If they really 
are not high profile, then there is a chance that we can get away with 
just ignoring their report.

Once I have had time to actually read the whole thing, I will comment 
further.   (I am traveling for another couple of days).

Thanks,
--MM--

---

From: Fernando Gont <[email-masked]>
Date: Mon, 29 Jun 2009 17:14:42 -0100

Matt Mathis wrote:

> carried in additional bytes in the SACK-permitted option.  

Are you sure this would ever work regardless of the advice we are 
giving? I could check if you want, but I bet most stacks have been 
performing this type of checks for quite some time now.

Also, why not using a different option type for that?

> As far as I 

I will check this and come back to you.

>> existing data on the number of holes.
[....]
> maintaining the  SACK scoreboard.

It's more than that. If you don't enforce any limits, you could get a 
system to commit lots of memory for the scoreboard. Not enforcing limits 
is a highway to buffer overflows and other type of attacks. You must 
impose *some* limit.

> The easy way to implement the 

Could you provide details of the algorithms you mention, references, etc.?

> pushing them in the wrong direction.   

As I mentioned above, as a general rule to security problems, you need 
to enforce limits. We can argue about the specific value, But I don't 
think you'd want any data structure to be able to grow without bounds 
these days. You recommend this, somebody implements it, and the next day 
you have the attack tool posted on bugtraq.

> Kludges in existing 

Nobody had brought up this issue of the algorithm. And, again, the 
reason for publishing the I-D was to provide the means to discuss this 
stuff within the IETF. If there's anything that can be improved, I'd be 
happy to do it.

> might be done better than permitted by the document at hand.   
> Going through a spec and "tightening" it, by changing SHOULDs into MUSTs, is 

In this particular case, we didn't change any SHOULD into a MUST. The 
only reference to the option length in RFC 2018 is in the option figure.

> just ignoring their report.

I don't really know what "high profile" is supposed to mean. The 
motivation for producing this document is explained in the 
Preface/Introduction of the document. This type of document clearly has 
an impact on implementations, because it provides help to developers 
that before this document was only available (if anything) by going 
through the 100+ papers referenced in this I-D. Many developers have 
payed attention to this document.

We have been in very close contact with the developer community of a 
number of operating systems, and the document was very welcome. It was 
felt that such a document was needed. And many of them are working on 
document.

The motivation for bringing this document to the IETF was to further 
polish the document, and give the IETF the chance to publish something 
on these issues. Even for things like "SYN floods" or "ICMP attacks", 
the IETF has provided advice/discussion at least ten or twenty years 
*later* from when many implementations had to do something about it.

There's too much stuff that an implementer of TCP has to figure out by 
himself. And many of the problems that have been found in real 
implementations have to do with that. This document simply tries to 
change that state of affairs.

Think about any TCP vulnerability that has ever been discussed in, say, 
bugtraq or full-disclosure, and I bet at least 95% have been ignored by 
the IETF (or put another way, nothing was published about them). This is 
not good.

Thanks!

I look forward to your feedback.

Kind regards,

---

From: "Ilpo Järvinen" <[email-masked]>
Date: Mon, 29 Jun 2009 21:48:43 +0300 (EEST)

On Mon, 29 Jun 2009, Fernando Gont wrote:

> > > could/should be raised. However, IIRC I based my proposal on existing data
> > > on the number of holes.
> [....]
> > > specific value proposed in the I-D. And the reason for submiting this I-D
> > > as a IETF I-D is exactly to discuss these issues and get consensus on
> > > e.g., what the proper/safe value should be for this limit.
> It's more than that. If you don't enforce any limits, you could get a system
> to commit lots of memory for the scoreboard. Not enforcing limits is a highway
> to buffer overflows and other type of attacks. You must impose *some* limit.

To me most sensible limit seems to be number of outstanding segments (not 
bytes) divided by two. There should be really very little reason to go 
beyond that. But of course not all implementations can directly 
determinate the number of outstanding segments (and would have to use some 
divided by MSS heurestics).

> > The easy way to implement the scoreboard has cost O(N^2).  However there is
> > at least one OS that uses an O(N*ln(N)) scoreboard, and O(N) might be
> > possible.  (These are the total cost of the worst case recovery at window
> > size N, so O(N) total cost is constant cost per ACK.)
> 

Any linked-list based implementation is basically O(n^2) under 
worst case attack, but they can also end up being that even in 
non-malicious cases too depending on the direction of lookups
and/or loss pattern.

O(n) for normal patterns seems well possible due to rather well 
predictable order of processing, obviously O(n*log n) is necessary
for malicious.

Also similar issues easily exist in the out-of-order segment handling at 
the receiver side.

-- 
 i.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Jun 2009 07:17:30 -0100

Hello, Matt,

> such a change would be backwards compatible with all existing 

I had promised to come back to you on this one. FreeBSD ignores those 
options whose length is not equal to the expected value. Excerpt of the 
tcp_dooptions() function from netinet/tcp_input.c:

		case TCPOPT_SACK_PERMITTED:
			if (optlen != TCPOLEN_SACK_PERMITTED)
				continue;
			if (!(flags & TO_SYN))
				continue;
			if (!V_tcp_do_sack)
				continue;
			to->to_flags |= TOF_SACKPERM;
			break;

The same thing is done for all other TCP options.

Linux does exactly the same thing. Excerpt of the tcp_parse_options() 
function from net(ipv4/tcp_input.c (available online at: 
http://lxr.linux.no/linux+v2.6.30/net/ipv4/tcp_input.c#L3763):

3763                        case TCPOPT_SACK_PERM:
3764                                if (opsize == TCPOLEN_SACK_PERM && 
th->syn &&
3765                                    !estab && sysctl_tcp_sack) {
3766                                        opt_rx->sack_ok = 1;
3767                                        tcp_sack_reset(opt_rx);
3768                                }
3769                                break;

This suggests that extending SACK while still using the same option type 
is not a good idea, or at least not a backwards-compatible one. (It's 
worth noting that about 220 of the 256 available TCP option numbers are 
currently unassigned... so it doesn't look like there's a TCP 
option-number shortage problem, either)

That said, the point you raised is worth noting (i.e., that TCP 
implementations ignore options that do not match the expected option 
length), so it doesn't come as a surprise to anybody trying to extend an 
existing TCP option.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Jun 2009 08:08:35 -0700

> Hello, Matt,
...
> options whose length is not equal to the expected value.
...
> Linux does exactly the same thing.
...
> is not a good idea, or at least not a backwards-compatible one. 
...

It may also suggest a bug.

This is a key flaw in the approach taken in this document. A proper scan
of all aspects of TCP for security vulnerabilities would be useful, but
the doc focuses on implementations as if they provide unique or correct
insight into the issue. The state of implementations may provide a
reason to look at this issue, but do not necessarily provide the right
basis for determining how to proceed.

TCP is not secure; it was not intended to be. We cannot make it secure
simply by dropping vulnerable components. We cannot make it secure by
focusing on poor implementation choices.

If the WG is to proceed on this, there are two viable choices:

	1) a from-scratch analysis of every aspect of TCP
	for security, not just the ones implementers have
	either tripped over or misdesigned

	2) a from-scratch design of a new secure transport
	protocol (in TSVWG)

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Jun 2009 09:36:47 -0700

Wes,

Taking a look at your proposed objectives:

> As a systems engineer, my first thought is always for requirements, so
> when I looked at Fernando's document, my question was if we're intending
> to do a "TCP implementation profile" for security, then what are the
> actual requirements to build to ... something like:
> 
> - TCP MUST be able to be implemented in a way free of exploitable
>   conditions leading to:
>   - unbounded memory utilization
>   - unbounded CPU utilization
>   - data injection by off-path third-parties
>   - connection breakage by off-path third-parties
>   - packet amplification by off-path third parties
>   - ...

I don't understand why TCP must be able to be implemented in a secure
fashion. It wasn't designed that way.

It would be more useful, IMO, to at least admit that and change the
above to acknowledge that, e.g., (changing the wording and the level
down to SHOULD):

- - TCP SHOULD be able to be implemented in a way that mitigates, to the
extent possible, the impact of exploitable conditions leading to:

- - Where further protection from exploitable conditions is required, a
protocol designed for security may be required; TCP is not intended to
serve this purpose, either with or without security extensions.

Joe

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Tue, 30 Jun 2009 11:18:53 -0500

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
>Joe Touch
>Sent: Tuesday, June 30, 2009 11:09 AM
>
> ...
>

Since 2 is out of our scope in TCPM, we'd have to move that to discussion
on TSVWG.

Just my personal thoughts here ... not co-chairing yet ...

As for from-scratch analysis, my personal thought is that Fernando's list
of issues identified is a strong starting point, even if we don't agree
about some of the mitigations suggested.  I 100% agree with Matt and Joe's
warnings that we need to come at the mitigations from the standpoint of
reducing risks without closing off our potential to continue innovating,
extending, and keeping TCP working as a key part of the Internet.  To me,
this task resembles some of the BEHAVE working group's work, where we know
that people are doing bad things in implementation, so we have need to
write guidelines documents to tell the implementers what they should be
doing.

I think much of Fernando's analysis is quite good, at least in terms of
identifying potential areas that can be exploited.  However, I do think
it could benefit from taking another step back in order to organize and
make sure the set of issues and recommendations is complete.

- Recommended mitigations to security issues identified in legacy TCP
  specifications MUST NOT further limit TCP properties of:
  - interoperability
  - scalability (data rates, loss rates, RTT, etc.)
  - extensibility (new options, congestion control, use of reserved
    bits, etc.)
  - ...

If we can clearly state the goals like this, then we can both organize
the issues found more logically, and we can evaluate the potential harm
of the proposed implementation techniques very systematically.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Jun 2009 14:49:13 -0300

> It may also suggest a bug.

Where's the bug? The spec says the length field is e.g. 2. If you
implement the standard, and receive an option with a length field that
is different than 2, how are you supposed to process the option? If you
don't know how to process it, it seems sensible to ignore the option.

> insight into the issue. 

It doesn't focus on implementations. The advice provided in the document
is not motivated for the simple fact that there's some implementation
implementing the recommended behavior, but because it was considered the
proper thing to do.

> The state of implementations may provide a

Please read the document and let me know which recommendation is
motivated by the simple fact that somebody did something in their stack.

> 	either tripped over or misdesigned

This is exactly what the document does.

> 	2) a from-scratch design of a new secure transport

It is amazing that you don't consider as a viable choice that of
adopting draft-gont-tcp-security as a wg item, and using this document
as the starting point.

It's the result of 2+ years of work, and the result of lots of my own
time and lots of time spent by the reviewers, and the developer community.

IMHO, the main issue with this document when it comes to your assessment
of the document is "NWH": Not Written Here.

This is very frustrating and sad.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Jun 2009 15:09:15 -0300

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:

> extending, and keeping TCP working as a key part of the Internet.  

These considerations were made when writing the document. As stated by
other tcpm'ers, no document is meant to be perfect. If anybody catches
any recommendation that is deemed to go against this principle, we can
fix the document, and that's it.

Simply knocking down an entire effort of many people during many years
simply because some people do not agree with some of the proposed
mitigations seems simply ridiculous.

> make sure the set of issues and recommendations is complete.

Bringing the document to the IETF, and having the tcpm wg adopt this I-D
is taking that step back. Is assessing the entire document, and applying
changes where deemed necessary.

> of the proposed implementation techniques very systematically.

While not explicitly mentioned, this was the standpoint from which this
document was produced. Yes, there may be things to fix.... every
document can be improved. And by bringing this to the IETF it's implicit
that the resulting RFC would differ from the version of the document
originally published by the UK CPNI.

Thanks!

Kind regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Jun 2009 15:18:29 -0300

Joe Touch wrote:

> fashion. 

Because we don't want our systems to be trivially hacked. C'mon Joe...
Should we CC this thread to full-disclosure & bugtraq... it will
probably make the day of most of the subscribers. I really feel tempted
to do so. (I also feel tempted to CC this thread to every relevant
mailing-list of open source OSes).

> - TCP SHOULD be able to be implemented in a way that mitigates, to the

Do we really need to nit-pick at every document and waste cycles in
end-less discussions that get nowhere, instead of getting stuff done?

Why don't we work on the document itself? Is there anything you think
could be improved? Post feedback, and let's improve the document.

Thanks,

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Jun 2009 11:32:03 -0700

Fernando Gont wrote:
> Because we don't want our systems to be trivially hacked.

We agree on that.

However, there are different issues here:

	1- protecting a particular TCP connection from attack
	2- protecting an endsystem from resource overload
	3- protecting the data a user transfers

TCP was never intended for any of these. IPsec, and TCP's MD5 and AO
options are intended to address some of these. If you're concerned with
hackers, you protect all three above - which means assuming IPsec and/or
MD5/AO, *then* talking about other issues.

Addressing vulnerabilities in unprotected TCP is like caulking the
windows of a car. It won't make it float.

> could be improved? Post feedback, and let's improve the document.

I've repeatedly said why I don't want to proceed on this path. It puts
the WG in the position of repeating ourselves on issues we've already
decided. Specific example - ICMP in-window checking. We acknowledge
systems do this, but do NOT recommend it as a security check. I've said
why in at least 3 different IETF meetings, as have others. Yet this doc
recommends it. That exceeds advice of the WG.

If you want this doc to be the basis of work in this WG, why don't
**YOU** start by revising it to at least apply the existing WG positions
on previously discussed advice?

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Jun 2009 11:44:18 -0700

> don't know how to process it, it seems sensible to ignore the option.

OK, since this is supposed to be a security doc, can you explain why you
take a segment with a mis-formed option and ignore it, even when the
length - the field that tells you where the next option starts - is
nonsensical?

Why don't you drop the segment or send a RST?

> implementing the recommended behavior, but because it was considered the

OK, so explain why ignoring segments with misformed option lengths is
"proper". Feel free to link in pointers to posted discussions that came
to that conclusion.

> This is exactly what the document does.

A thorough analysis would have listed what to do with every option, not
just those deemed "commonly implemented", e.g.

It would also have caught the above bug issue, rather than deeming
current implementations to have thoughtfully considered the proper solution.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 30 Jun 2009 16:49:39 -0300

Joe Touch wrote:

> TCP was never intended for any of these. 

TCP was not designed with congestion control in mind... so what? Will
you knock down RFC2581, too?

Whether it was designed with those issues in mind or not, doesn't
matter. TCP operates in hostile environments and therefore, to the
extent that it's possible, it's is desirable that it is as resilient as
possible.

> IPsec, and TCP's MD5 and AO options are intended to address some of these. 

>From your perspective, why would you work on TCP-AO if TCP is not meant
to provide security??

> If you're concerned with

You use a helmet when you ride a motorcycle, right? Does that mean that
a motorcycle becomes secure? No it doesn't. But it does mean that you
probably will not get very injured if you fall from your motorcycle at
20 km/h.

C'mon Joe...

> recommends it. That exceeds advice of the WG.

I had meant to remove most of that ICMP stuff. This is a pending change,
and I thought I had already removed most of that stuff (and replace it
with a small discussion, and a pointer to the ICMP attacks I-D).

> on previously discussed advice?

As I said, this is no problem, and I thought I had already applied this
change.

That said, I don't believe this is a show stopper.... (issues solved, as
far as I can tell).

Thanks,