Subject: [tcpm] comments on draft-gont-tcpm-icmp-attacks-05

From: Pekka Savola <[email-masked]>
Date: Sun, 6 Nov 2005 05:00:47 +0200 (EET)

It may be needless to say this, but in any case..

I re-read draft-gont-tcpm-icmp-attacks-05 on the plane.  The last rev I had
read properly was probably -02 or -03.  I was very pleased with this
version; I was much more skeptic of certain parts of the doc (e.g., PMTUD
attacks) before, but I think the document is well written and convincing
now.

I'd recommend adopting this as a WG item (provided that Fernando would then
lift the "no derivative works" clause, because otherwise the doc can't be
used in the IETF process).  This could be any of Informational,
Experimental, Proposed Standard or BCP.  Anything works for me, but maybe
it'd be better to start with either of the first two and revisit after a
couple of years and more experience.

minor issues
------------

1) Wasn't (quite the obvious) sequence number randomization mentioned as a
subsection under 4.x at some point in the past?  I think it should be
briefly mentioned here, because even if it's obvious, I don't recall
it has been clearly documented as a security measure.

2) in below, I think you forgot to underline that the below treatment only
applies for sockets in synchronized states?

    Therefore, TCP SHOULD treat all of the above messages as indicating
    "soft errors", rather than "hard errors", and thus SHOULD NOT abort
    the corresponding connection upon receipt of them.

3) While I agree with the conclusion of section 5.2.2., I think the
justification does not hold.

Let's consider the cases systematically:

  1) hard error is spoofed, connection is progressing
  2) hard error is legitimate, connection is stalled

  a) hard errors are converted to soft errors (and ignored and/or brought up
to the application)
  b) hard errors are ignored until N retransmits have proved unsuccesful,
then b.1) converted to soft errors, or b.2) connection is aborted.

  a) + 1) and b) + 1) are pretty close to equivalent (unless the application
aborts the session without better knowledge that this is an attack).
  However, a) + 2) and b.2) + 2) are slightly different: some might view it
as *desirable* to abort the session sooner if there is legitimate reason to
believe that the error was genuinine -- rather than having to wait for
minutes for it to die out on its own.

However, as I said, I think I agree with your main point that just doing a)
is simpler and the benefit of b) compared to it in the legitimate case may
not be worth the additional 10 lines of code.

5.2.2.  Delaying the connection-reset

    An alternative counter-measure could be to delay the connection
    reset.  Rather than immediately aborting a connection, a TCP would
    abort a connection only after an ICMP error message indicating a hard
    error has been received, and the corresponding data have already been
    retransmitted more than some specified number of times.

    The rationale behind this proposed fix is that if a host can make
    forward progress on a connection, it can completely disregard the
    "hard errors" being indicated by the received ICMP error messages.

    While this counter-measure could be useful, we think that the
    counter-measure discussed in Section 5.2.1 is easier to implement,
    and provides increased protection against this type of attack.

editorial
---------

The affected systems ranged from TCP/IP implementations meant
    for desktop computers, to TCP/IP implementations meant for core
    Internet routers.

==> "," is unnecessary.

    The Internet Control Message Protocol (ICMP) is used in the Internet
    Architecture mainly to perform the fault-isolation function, that is,
    the group of actions that hosts and routers take to determine that
    there is some network failure [RFC0816]

==> missing "." at the end.

    Additional considerations for the validation of ICMP error messages
    can be found in Appendix C

==> ditto.

   When TCP is handled an ICMP error message, it will perform its fault
    recovery function, as follows:

==> s/handled/handed/ (or something a bit better)

  Those systems that do not implement the PMTUD
       mechanism should not be sending their IP packets with the DF bit
       set, and thus should not be receiving these ICMP error messages.
       Thus, it would be fair for them to treat this ICMP error message
       as indicating a soft error, therefore not aborting the
       corresponding connection when such an error message is received.
       On the other hand, and for obvious reasons, those systems
       implementing the Path-MTU Discovery (PMTUD) mechanism [RFC1191]
       should not abort the corresponding connection when such an ICMP
       error message is received.

==> I'd change the order here: describe PMTUD-enabled systems first because
they're a majority.

    ICMP "Destination Unreachable" (type 3) "fragmentation neeed and DF

==> s/neeed/needed/

    ICMP "Destination Unreachable, fragmentation needed and DF set"
    packet (or their ICMPv6 counterpart) to the sending host, advertising

==> s/their/the/ or "its" (the're just one ICMP type you're talking about)

    results.  Another posible scenario is that in which a TCP connection
    is being secured by means of IPSec.  If the Next-Hop MTU reported by

==> s/posible/possible/
==> s/by means of/using/

    If this check is passed, claimedmtu should be compared with

==> s/is passed/passes/ ?

    EVENT: Segment is sent
         if (packet_size > maxsizesent)
              maxsizesent = packet_size;

==> logically the code might read a bit easier (at least to me) if this
read:

    EVENT: Segment is sent
         if (maxsizesent < packet_size)
              maxsizesent = packet_size;

.. but this probably isn't worth changing.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Sun, 06 Nov 2005 13:50:54 -0800

Pekka Savola wrote:
> used in the IETF process). 

IMO, the document - at least - needs to have the title changed and tone
of the argument changed as well. These are not - and cannot be put forth
as - security issues.

We can talk about them being useful in how they mitigate the effect of
stale packets, and then - as a corellary - how some attacks emulate
stale packets. The same is true for other aspects that tone down
response to what could be fluctuating conditions.

However, focusing on this as an attack issue is inappropriate; the
remaining (in-window, or on-path) attacks are still too easy to consider
these attack mitigations as a focus.

(that said, I would agree that if the focus were changed, it would be a
useful WG doc)

I've made these points before; unfortunately, the current revision did
not address them.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Sun, 06 Nov 2005 16:21:49 -0800

At 01:50 p.m. 06/11/2005, Joe Touch wrote:

>IMO, the document - at least - needs to have the title changed

Mark Allman has suggested "TCP validation of ICMP messages". This could be 
a possible alternative title for the document, if that's an issue.

>and tone

I disagree. The draft explains how an attacker can take advantage of the 
described vulnerabilities. And, indeed, the ICMP-based connection-reset 
attack is much more trivial to perform than its TCP-based counterpart.

>stale packets.

This could be true for the TCP sequence number check. But none of the 
attack-specific counter-measures have anything to do with stale packets. If 
anything, they have to do with checking progress on the connection.

If you just mitigate stale packets, you are still vulnerable to in-window 
attacks. The draft solves in-window attacks, which, as a corellary, solves 
the case of stale packets.

I agree that I could add some text on the counter-measures also solving the 
case of stale packets, but not the opposite (for the reasons stated above).

>these attack mitigations as a focus.

How can you perform in-window attacks if you have all the attack-specific 
counter-measures implemented?

You're just referring to the TCP sequence number check, which is not meant 
to be a counter-measure, but rather a very basic check we should be 
performing, that can be used as a building block for counter-measures (eh, 
the PMTUD specific fix).

Kindest regards,

--
Fernando Gont
e-mail: [email-masked] || [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Nov 2005 08:08:40 -0800

Fernando Gont wrote:
> Mark Allman has suggested "TCP validation of ICMP messages". This could
> be a possible alternative title for the document, if that's an issue.

Possible. I'm not sure 'validation' captures what I feel are basically
'sanity checks', but it might.

> attack is much more trivial to perform than its TCP-based counterpart.

It does NOT address the substantial vulnerabilities that remain, or the
effect of interpreting all invalid exchanges as attacks (which I feel is
both overkill and inappropriate).

> attack-specific counter-measures have anything to do with stale packets.
> If anything, they have to do with checking progress on the connection.

Which is another kind of validity, but one that assumes that a
connection making progress should not also incur these kinds of signals.
I've described cases where non-malicious systems can behave this way.

> If you just mitigate stale packets, you are still vulnerable to
> in-window attacks. The draft solves in-window attacks, which, as a
> corellary, solves the case of stale packets.

It doesn't identify attacks; it (over)interprets certain behaviors as
attacks.

I agree that making progress might be a reason to change the current
behavior of TCP/ICMP because TCP is making progress and the ICMPs can be
considered irrelevent - NOT AN ATTACK.

Again, this is about the tone of the doc.

> I agree that I could add some text on the counter-measures also solving
> the case of stale packets, but not the opposite (for the reasons stated
> above).
> 
> How can you perform in-window attacks if you have all the
> attack-specific counter-measures implemented?

One way would be by deploying this system ;-) The 'attack' has succeeded
if it causes changes to legitimate, correct TCP/ICMP interaction.

If you shut all in-window attacks, you've disabled a functioning
feature. Otherwise, you're arguing about when you know the difference
between an attack and a non-attack.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 07 Nov 2005 15:27:16 -0800

>It does NOT address the substantial vulnerabilities that remain, or the

You mean man in the middle attacks, or what?

>both overkill and inappropriate).

You implement the proposed mechanisms as counter-measures for ICMP-based 
attacks. In the event some packet is not part of an attack, the 
counter-measures will not hurt you, anyway, because ICMP is unreliable.

>I've described cases where non-malicious systems can behave this way.

Yes. And what is the problem if an ICMP message does not pass the proposed 
checks, not because it's part of an attack, but because it was caused by a 
stale TCP segment or whatever?

>It doesn't identify attacks; it (over)interprets certain behaviors as

 From the receiver's point of view, you cannot tell the difference. That's 
why, given the current hostile environments, it's fair to think bad guys 
may be behind these packets.

>considered irrelevent - NOT AN ATTACK.

The draft does not mean that . It just means that we will implement a set 
of mechanisms that in the presence of blind ICMP-based attacks, it will 
protect us from them. It does not aim to guess whether the packet 
correspond to an attack, or not.

And if there's some wording that suggests that, I will try to make it clear.

>One way would be by deploying this system ;-)

Have a look at the vulnerability reports of virtually every major vendor.

>The 'attack' has succeeded

No, the attack has succeeded if you have been DoS'ed.

>feature.

A feature you cannot depend on?

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Mon, 07 Nov 2005 20:38:10 -0800

> You mean man in the middle attacks, or what?

Yes.

> counter-measures will not hurt you, anyway, because ICMP is unreliable.

We've been over this one before; you make the system less functional by
dismissing correct ICMPs that end up reaching you.

> Yes. And what is the problem if an ICMP message does not pass the
> proposed checks, not because it's part of an attack, but because it was
> caused by a stale TCP segment or whatever?

Stale is OK. The cases I'm talking about are TCP connections making
progress over multipath routing where one path is flakey and sends
ICMPs. That's not stale.

> From the receiver's point of view, you cannot tell the difference.
> That's why, given the current hostile environments, it's fair to think
> bad guys may be behind these packets.

So why aren't ALL packets considered an attack in such an environment?

Yes, it's fair to think that bad guys MAY be behind the packets, but
only if you also think that good guys MAY as well. I consider it
dangerous to consider correct behavior as an attack.

> The draft does not mean that . It just means that we will implement a
> set of mechanisms that in the presence of blind ICMP-based attacks, it
> will protect us from them. It does not aim to guess whether the packet

Yes it does; it guesses that any unexpected ICMP _is_ an attack that
should thus be ignored.

...
> A feature you cannot depend on?

A feature that works for legitimate hosts. Short of doing
authentication, you can't "depend" on any packet.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Nov 2005 07:20:52 +0200 (EET)

> progress over multipath routing where one path is flakey and sends

Uhh.  So, could you be a bit more specific on what you proposing 
instead?  Ignore all ICMPs, always?

I don't see how the mechanisms ICMP errors draft make this any worse 
compared to vanilla TCP which honors ICMP.  Actually this spec makes 
this better, because errors in synchronized states are treated as soft 
errors and the host does _not_ reset the sessions.

---

From: Ted Faber <[email-masked]>
Date: Tue, 8 Nov 2005 09:19:41 -0800

> errors and the host does _not_ reset the sessions.

I think a reasonable interpretation of 1122 says that the TCP connection
SHOULD reset.  Relevant sections include Section 3.2.2.1:

            A Destination Unreachable message that is received MUST be
            reported to the transport layer.  The transport layer SHOULD
            use the information appropriately; for example, see Sections
            4.1.3.3, 4.2.3.9, and 4.2.4 below.  A transport protocol
            that has its own mechanism for notifying the sender that a
            port is unreachable (e.g., TCP, which sends RST segments)
            MUST nevertheless accept an ICMP Port Unreachable for the
            same purpose.

            A Destination Unreachable message that is received with code
            0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a
            routing transient and MUST therefore be interpreted as only
            a hint, not proof, that the specified destination is
            unreachable [IP:11].  For example, it MUST NOT be used as
            proof of a dead gateway (see Section 3.3.1).

And Section 4.2.3.9 ICMP messages (which is too long to excerpt), says
that hard errors (ICMP Destination Unreachable 2-4) SHOULD abort the
connection.

As I read it, an established connection receiving a hard error has some
discretion as to whether to abort the TCP connection, and that the
internal sanity checks (e.g. checking TCP sequence numbers) that the
draft advocates would be an excellent mechanism for deciding when to
exercise that discretion.

That's my reading, and I'm not sure that someone else wouldn't read it
differently.

-- 
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
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Nov 2005 10:04:05 -0800

> instead?  Ignore all ICMPs, always?

No. I favor checking the staleness of ICMPs and checking whether signed
payloads are intact before checking such staleness. Non-stale ICMPs,
properly signed if signed, should be acted on.

(with regard to the signing stuff - e.g., IPsec or TCP/MD5, none of the
discussion I posted to the list made it into the draft)

> errors and the host does _not_ reset the sessions.

There are cases where this throws away ICMPs that are not attacks. I
don't consider that making things better.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 08 Nov 2005 16:35:44 -0800

>That's my reading, and I'm not sure that someone else wouldn't read it

That would be a first step. But it puts you at the starting point of where 
tcp-secure started.

If we don't treat hard errors as soft errors when a connection is in any of 
the synchronized states, we should be prepared for...mm... an "icmp-secure" 
draft?

Why would attackers bother to perform TCP-based attacks if they can perform 
them more easily with ICMP?

And the solution for ICMP-based conenction-reset attacks is much more 
trivial than the one for its TCP counter-part.

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 08 Nov 2005 16:40:55 -0800

> > You mean man in the middle attacks, or what?

Look at the name of the attacks: "Blind xxxx". That's the trivial attacks 
my draft addresses.

>progress over multipath routing where one path is flakey and sends

That would be completely broken. See the references included in my draft to 
D. Clark's papers.

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Nov 2005 18:09:54 -0800

Fernando Gont wrote:
...
> Why would attackers bother to perform TCP-based attacks if they can
> perform them more easily with ICMP?

TCP attacks are all spoofing based; for some paths, spoofing can be
harder to trace, and harder to ingress filter.

(this would depend on the path, but there are cases where properties of
a path favor TCP attacks rather than ICMP ones)

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 08 Nov 2005 18:13:16 -0800

Fernando Gont wrote:
> Look at the name of the attacks: "Blind xxxx". That's the trivial
> attacks my draft addresses.

That doesn't mean the vulnerabilities don't remain. It's not in the
title OR the abstract. So they ought to be discussed.

> That would be completely broken. See the references included in my draft
> to D. Clark's papers.

That is the behavior the spec currently requires. But we've already been
over that.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 08 Nov 2005 19:27:32 -0800

>a path favor TCP attacks rather than ICMP ones)

I strongly disagree. ICMP-based attacks don't even depend on IP address 
sppofing. TCP ones does.
Simple ingress/egress filtering serves as a counter-measure for TCP-based 
attacks. But it does not serve as a counter-measure for ICMP-based ones.

ICMP-based attacks have been used for ages. Even by script-kiddies, for 
taking over IRC channels.

Guess why they didn't use TCP-based ones.

And guess what a knowledgeable attacker would do.

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 08 Nov 2005 19:31:04 -0800

>title OR the abstract. So they ought to be discussed.

You are objecting the draft because it does not address attacks it is not 
meant to address.
If you think it would be good to make it clear that it does not address MIM 
attacks, fine, I can make it clear.
But that's not a stop-gap.

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Nov 2005 00:51:11 -0800

Fernando Gont wrote:
> You are objecting the draft because it does not address attacks it is
> not meant to address.

It seems that either the title or abstract would explain what attacks
are being addressed; neither limits this to blind attacks.

> If you think it would be good to make it clear that it does not address
> MIM attacks, fine, I can make it clear.

Agreed, but that's not the only issue; I've already explained the other.

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Nov 2005 00:54:22 -0800

> I strongly disagree. ICMP-based attacks don't even depend on IP address

That's what I said above.

> Simple ingress/egress filtering serves as a counter-measure for
> TCP-based attacks. But it does not serve as a counter-measure for
> ICMP-based ones.

This depends on the paths, the filters, and the location of the
attacker. In some cases, it's easier to spoof a source address than the
address of an arbitrary router.

> Guess why they didn't use TCP-based ones.

Existence of cases where ICMP is easier than TCP does not preclude cases
where the converse is true.

JOe

---

From: Pekka Savola <[email-masked]>
Date: Wed, 9 Nov 2005 17:00:37 +0200 (EET)

> address of an arbitrary router.

I do not see how this holds.  TCP RST requires spoofing the source 
address of the victim.  It's equally easy to generate an ICMP error 
with source address of the victim (in the IP header), AND the the 
victim also in the encapsulated ICMP data.  You don't need to spoof a 
router on the path, and you actually don't need to spoof at all if you 
aren't concerned about traceability.

The only case where there may be a difference is if either the 
attacker or the victim is behind a firewall which drops all outgoing 
or incoming (respectively) ICMP messages -- even the valid ones.

...
> where the converse is true.

Could you please explain at least one concrete example of the 
converse?

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Nov 2005 09:38:51 -0800

Pekka Savola wrote:
> address of the victim.  It's equally easy to generate an ICMP error with
> source address of the victim (in the IP header), AND the the victim also
> in the encapsulated ICMP data.  You don't need to spoof a router on the
> path, and you actually don't need to spoof at all if you aren't
> concerned about traceability.
> 
> The only case where there may be a difference is if either the attacker
> or the victim is behind a firewall which drops all outgoing or incoming
> (respectively) ICMP messages -- even the valid ones.
> 
> ...
> Could you please explain at least one concrete example of the converse?

The above one you gave (all ICMPs dropped) is good enough.

JOe

---

From: Ted Faber <[email-masked]>
Date: Wed, 9 Nov 2005 10:55:56 -0800

> The above one you gave (all ICMPs dropped) is good enough.

Joe, can you just work the example in more detail?  I can't help but
notice that the shorter everyone's replies get, the longer the e-mail thread
gets and the less actually gets said.  It seems to me that's because
people are each discussing what's in their own head.

If there's a concrete case to discuss, please lay it out and we'll all
be talking about the same thing.

Thanks.

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Nov 2005 11:11:06 -0800

Ted Faber wrote:
> Joe, can you just work the example in more detail? 

That doesn't seem useful; it's trivial:

	- all border routers drop ICMPs
	- it's now easier to attack with TCP spoofing than with ICMP

That's the case Fernando provided.

The case I had been considering was different, and allowed for some
ICMPs to still get through:

	- border routers drop ICMPs except from
	'blessed' router addresses, perhaps a list of
	'authorized routers' somewhere

	- the attacker shares some property of the path
	to the endpoint being attacked that means the traffic
	can't be filtered (trivial case he's in the same
	domain as the one he's attacking, but other cases
	can occur depending on filter policy)

Again, it's easier to spoof than to send an ICMP.

Joe

---

From: Pekka Savola <[email-masked]>
Date: Wed, 9 Nov 2005 21:31:24 +0200 (EET)

> 	- it's now easier to attack with TCP spoofing than with ICMP

"Trivial"? Could you provide some data, especially around "all"? (and 
possibly "easier")

> 	'authorized routers' somewhere

Do you have data whether this kind of configuration actually exists 
somewhere?

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Nov 2005 14:00:04 -0800

> "Trivial"? Could you provide some data, especially around "all"? (and

Consider borders with firewalls that drop all ICMPs; I'm not proposing
that all border routers on the planet do so, I'm proposing a case in
which a domain is so configured.

Now TCP attacks are possible, and ICMP attacks are not - thus 'easier'
is defined as 'more possible than not at all'.

> Do you have data whether this kind of configuration actually exists

The point of this thread was existence of legitimate configurations that
are mistaken as attacks, including cases where TCP is preferred.

Just because ICMP attacks are more likely doesn't mean, for example,
that changing semantics and standards to close that 'preferred' door
actually secures the house. That's the high-order point here, and why
that needs to be discussed in at least the security considerations of
this doc.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 09 Nov 2005 15:08:09 -0800

>address of an arbitrary router.

Why do you think you need to spoof the IP address of a router?

If anything, you need to spoof the values that are in the ICMP payload. 
Which is not where simple ingress/egress filters look at to decide whether 
to filter a packet or not.

>where the converse is true.

Can you please mention a few cases?

Kindest regards,

---

From: Joe Touch <[email-masked]>
Date: Wed, 09 Nov 2005 15:46:04 -0800

Fernando Gont wrote:
> Which is not where simple ingress/egress filters look at to decide
> whether to filter a packet or not.
> 
> 

You already did - where ICMP is blocked. One is more than sufficient.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 09 Nov 2005 17:11:25 -0800

>is defined as 'more possible than not at all'.

C'mon Joe, that's far from being realistic. What's the next thing you will 
object?

>are mistaken as attacks, including cases where TCP is preferred.

Do you know which is the only case in which a TCP-based connection reset 
attack is preferred?
In those scenarios such as ones with BSD-derived or Mentat-derived 
implementations, in which you will not be able to perform ICMP-based ones 
because those systems already implement draft-gont-tcm-icmp-attacks-05.txt.

I have built some tools for these attacks. You have them available at 
http://www.gont.com.ar/tools/icmp-attacks/index.html .
Get some unpatched Windows system (IIRC, by now they are already 
implementing draft-gont).

Try to perform the ICMP-based attacks, and try to perform the TCP-based 
ones. And tell me which one was easier to perform.

>that needs to be discussed in at least the security considerations of

Let me try to be super-clear, in case I have not been:
My draft is about mitigating ICMP based ones. Simply that. And it impoves 
TCP's robustness.

At least in the last couple of days you have objected my draft because it 
doesn't do things it is NOT supposed to do.

By now, you have argued against:

* hard errors -> soft errors
* TCP SEQ check being completely unacceptable
* Draft title
* Draft focus
* That the draft does not address attacks it has never been supposed to address
* That it is easier to perform a TCP-based attack than an ICMP-based ones.
* You have argued that even if there are still working paths to get to the 
destination host, you should abort a connection upon receipt of a so-called 
ICMP hard error.

IMHO, you're arguments tend to kill TCP's robustness. But, given that this 
type of discussion has lasted for more than one year, I don't aim to change 
your mind.

I do recommend that you raise your issues in the TCPM WG meeting, probably 
cross-post them to the tsvwg mailing-list, and also post them to security 
mailing lists such as bugtraq and full-disclosure.

And convince the 50+ vendors that have already implemented draft-gont to 
unpatch their systems, to make them look like honepots to script kiddies.

Kindest regards,

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 10 Nov 2005 07:49:46 -0800

Fernando Gont wrote:

> I do recommend that you raise your issues in the TCPM WG meeting,
> probably cross-post them to the tsvwg mailing-list, and also post them
> to security mailing lists such as bugtraq and full-disclosure.
> 

There is no question that most, if not all, vendors have
implemented all or most of the mechanisms described in this
draft.  Unless the TCPM WG really wants to have the IETF
"documented" TCP standard to deviate from real world running
code, I'd suggest the WG to adopt this draft as a WG document
and decide which track it is suitable for.

-- 

						K. Poon.
						[email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 10 Nov 2005 08:45:52 -0800

Fernando Gont wrote:
> C'mon Joe, that's far from being realistic. What's the next thing you
> will object?

To this post ;-)

...
> My draft is about mitigating ICMP based ones. Simply that. And it
> impoves TCP's robustness.

Here's MY summary:

1) the doc puts forth validity checks as security protections

2) the validity checks are incorrect
	Appendix C concerns need to be addressed where the checks
	are discussed, as a requisite precursor to checks of
	ICMPs from end-hosts

3) the doc indirectly protects from blind attacks but not non-blind or
TCP attacks
	this needs to be highlighted very early, e.g., in the abstract

	note that non-blind, which I have referred to as on-path,
	is NOT the same as MITM; MITM have the ability not only to
	snoop but to selectively remove traffic. On path do not remove
	traffic.

I've made my case; the WG can decide how to move forward.

...
> to security mailing lists such as bugtraq and full-disclosure.

Certainly.

> unpatch their systems, to make them look like honepots to script kiddies.

Hmmm - like TCP-probs (RFC2525) did? We'll just do another round of that
in a few years entitled "hazards of non-security security solutions".

Vendors aren't the measure of the IETF; we regularly need to remind them
of specs and the unforseen effects of changing them to address immediate
or local concerns without considering the big picture and long-term.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 10 Nov 2005 08:51:11 -0800

> and decide which track it is suitable for.

See my other post about TCP-probs.

This WG should decide the utility and necessity of this code of its own
merit; this is not a vendor popularity contest.

Joe

---

From: "Armando L. Caro, Jr." <[email-masked]>
Date: Thu, 10 Nov 2005 20:00:05 -0500

> and decide which track it is suitable for.

I thought the IETF was suppose to be the standards body, not some
collection of vendors. I don't think we should alter the role of the
IETF to simply document and recommend mechanisms that are popular with
vendors. IMHO, the IETF should make recommendations independently of how
popular they are with vendors.

-- 
Armando
www.armandocaro.net