Subject: RE: [tcpm] ICMP and TCP

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

Thanks for your replies.

Please see comments in-line:

> -----Original Message-----
> From: Ted Faber [mailto:[email-masked]] 
> Sent: Monday, May 22, 2006 12:53 PM
> To: Templin, Fred L
> Cc: Bora Akyol; Fernando Gont; [email-masked]
> Subject: Re: [tcpm] ICMP and TCP
> 
> On Mon, May 22, 2006 at 11:48:18AM -0700, Templin, Fred L wrote:
> > > 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?
> > 
> > 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.
> 
> 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.

I did not say I disagree with what the draft recommends as far treatment
of hard errors in certain states within TCP, what I am saying is that
the draft recommends **modifications** to TCP implementation on how to
deal
with these and therefore it MUST NOT be left as an informational
document.
IMHO, it should be classified as standards track and should receive the
scrutiny
that a standards track document receives.

For long term, I think handling all of the signaling (including PMTUD)
without ICMP
is the better way to go IMHO.

> > 
> > > 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.
> > 
> > Not even as BCP?
> 
> 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.  

I could not have said this better. Things that seem simple enough
when one is writing code for a 100 Mbps firewall seem to get
a lot more difficult when one is designing hardware that can
do that 100 Gbps or more.

I would like to see more justification of this particular
recommendation.

Regards,

Bora

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

---

From: Ted Faber <[email-masked]>
Date: Mon, 22 May 2006 19:20:36 -0700

On Mon, May 22, 2006 at 02:31:37PM -0700, Bora Akyol wrote:
> I did not say I disagree with what the draft recommends as far
> treatment of hard errors in certain states within TCP, what I am
> saying is that the draft recommends **modifications** to TCP
> implementation on how to deal with these and therefore it MUST NOT be
> left as an informational document.  IMHO, it should be classified as
> standards track and should receive the scrutiny that a standards track
> document receives.

Ummm, I must have nodded off again.  Too much multitasking, I guess.

What change to TCP semantics are we discussing?  I think the strongest
thing that 1122 says about reacting to an ICMP is that the host SHOULD
abort the connection.  I'm pretty sure that this draft doesn't advocate
being more strict than the SHOULD, and is only laying out criteria by
which the SHOULD might be taken exception to.

What am I missing?

-- 
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:22:42 -0300

>which the SHOULD might be taken exception to.

That's exactly the case.

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:22:42 -0300

That's exactly the case.

Kindest regards,

---

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

That's exactly the case.

Kindest regards,

---

From: Ted Faber <[email-masked]>
Date: Tue, 23 May 2006 10:59:20 -0700

> >which the SHOULD might be taken exception to.

I really think that the draft should state that right in the intro,
since we seem to have to have this discussion every time the draft is
discussed.  It'll be much nicer when I can say "read the intro" rather
than typing out that paragraph every time.

Don't be shy about it.  There's a SHOULD in 1122 and this draft suggests
criteria for taking exception to that SHOULD.  Point the SHOULD section
of 1122 right out.

---

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

>criteria for taking exception to that SHOULD.  Point the SHOULD section

That is one of the changes that I will made in the draft. (Although, 
IMO, confusion has raised among the ones that have been discussing 
the draft since version draft-gont -00 ;-))

Kindest regards,

---

From: Mark Allman <[email-masked]>
Date: Tue, 30 May 2006 12:20:18 -0400

> > >What change to TCP semantics are we discussing?  I think the
> > >strongest thing that 1122 says about reacting to an ICMP is that
> > >the host SHOULD abort the connection.  I'm pretty sure that this
> > >draft doesn't advocate being more strict than the SHOULD, and is
> > >only laying out criteria by which the SHOULD might be taken
> > >exception to.
> > 
> > That's exactly the case.
> 
> Don't be shy about it.  There's a SHOULD in 1122 and this draft
> suggests criteria for taking exception to that SHOULD.  Point the
> SHOULD section of 1122 right out.

I'd take this one step further and I'd say as the document steps through
things that we should be reminded exactly what the relevant specs say
before we go through other possible avenues that would fit within the
current specs.

(no hats)

allman