Subject: RE: [tcpm] ICMP and TCP

From: "Bora Akyol" <[email-masked]>
Date: Mon, 22 May 2006 11:14:07 -0700

> -----Original Message-----
> From: Ted Faber [mailto:[email-masked]]

<snip>

> I do have sympathy for the position that TCP should be 
> ICMP-independent, using ICMP messages only as hints.  PMTUD seems to 
> be the big stumbling block in that perspective, and the sooner we have

> ICMP-free PMTUD the happier I'll be.
> 
> However, there are two issues on the table here:
> 
> 	1. Given the world in which we live, is the ICMP attacks draft
> 	   a reflection of group consensus yet?
> 
> 	2. Should we also be writing a draft/taking a position on
> 	   ICMP-free TCP?  Does that generalize?

I am for (2) wherever that work happens to be done. 

I can live with the draft as it is written provided that
section 4.3 requiring ICMP payload parsing in firewalls gets removed
as it has questionable value.

Regarding BCP/Info vs Standards track, the draft is making
recommendations
to the way TCP treats errors based on the state that the connection is
in,
how can this be an informational draft?

Bora

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 May 2006 11:48:18 -0700

recommendations
in,
> how can this be an informational draft?

Assuming you are still referring to 'draft-ietf-tcpm-icmp-attacks',
I checked the document for MUST/SHOULD/MAY and the only occurences
are with direct reference to RFC1122, e.g., "The Host Requirements
RFC [RFC1122] states that a TCP MUST...".

The current state of affairs is that we have non-authenticated
ICMPs which should be considered as advisory in certain situations
and suspect in others. It seems like a BCP that clarifies those
situations would be useful. 

> as it has questionable value.

Not even as BCP?

Fred
[email-masked]

---

From: Ted Faber <[email-masked]>
Date: Mon, 22 May 2006 12:52:45 -0700

> situations would be useful. 

Hard to say it better than that. :-)

I'd be happier if the document did have a paragraph that made exactly
that point in the intro.   There are a set of ICMP messages that SHOULD
terminate a TCP connection, and this document is listing some ideas for
determining when to go against that strong advice.  Going against that
SHOULD with good reason is certainly conformant behavior.

> > as it has questionable value.

IMHO, and I realize I'm not the one you asked, I'd like to see a little
justification for the additional complexity.  It seems to me like a fair
amount of work for a fairly unlikely case (spoofed ICMP payload w/o a
spoofed ICMP header).  But I'm willing to be convinced. 

If there are some implementations doing this by default, I'm curious
about that, too.  

With my chair hat off.

-- 
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: Fernando Gont <[email-masked]>
Date: Tue, 23 May 2006 02:29:32 -0300

>If there are some implementations doing this by default, I'm curious

In all those cases the same box implements both NAT and firewall 
functionality, you have to translate the inner packet in order for it 
to have any effect.

When a NAT receives an ICMP error message, it has to look up for 
state information for the inner packet, and modify that inner packet 
before forwarding the ICMP error message.

In the case of pure-firewalling, I will dig into existing 
implementations. Last year, while talking with Linux guys, they said 
they were going to implement this. Don't not what they ended up doing, though.

Kindest regards,

--
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: Tue, 23 May 2006 02:29:32 -0300

Kindest regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 May 2006 02:29:32 -0300

Kindest regards,