Subject: RE: [tcpm] feedcback on tcp-secure-05

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Sat, 15 Jul 2006 15:59:36 -0700

Fernando, 

> -----Original Message-----
> From: Fernando Gont [mailto:[email-masked]] 
> Sent: Saturday, July 15, 2006 11:43 AM
> To: Anantha Ramaiah (ananth); Joe Touch; [email-masked]
> Subject: RE: [tcpm] feedcback on tcp-secure-05
> 
> At 15:04 13/07/2006, Anantha Ramaiah \(ananth\) wrote:
> 
> > > The doc should also indicate that preventing these 
> attacks does NOT 
> > > prevent ICMP attacks (and cite Gont's draft in this regard); it 
> > > would be useful for the security considerations to 
> address whether 
> > > ICMPs should be blocked altogether and what the impact of 
> that would 
> > > be. Without such blocking, it's not clear what the 
> utility of this 
> > > solution would be.
> >
> >Ok.
> 
> I don't think tcpsecure should make any advice on what to do 
> with ICMP.
> 
> Just make it clear that the introduced mechanisms do not 
> prevent ICMP-based attacks against TCP, and provide a pointer 
> to draft-ietf-tcpm-icmp-attacks-00.txt .

I agree.. 

May be we should just say something like : "The mitigations discussed in
this document does not prevent ICMP attacks" and provide a citation to
your document.

One of the reasons why it was felt that the above isn't necessary is
because : tcpsecure refers Joe's antispoof which in turn refers your
document. 

> 
> If you are going to make any other statement on this issue, 
> state that the ICMP-based attacks are easier to perform, and 
> thus should be mitigated (if not, it's ICMP that is the 
> "weakest link in the chain").
> 
> You could also add that, fortunately, virtually every 
> implementation has mitigated the ICMP attacks described in 
> draft-ietf-tcpm-icmp-attacks-00.txt, by implementing most (if not
> all) the counter-measures described in that draft.

We really don't want to cause a bloat to the security considerations
section. Also the scope the document is limited and it is better to
stick to that. 
 
-Anantha
> 
> Kindest regards,
> 
> 
> --
> Fernando Gont
> e-mail: [email-masked] || [email-masked] PGP 
> Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
> 

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

---

From: "Mitesh Dalal \(mdalal\)" <[email-masked]>
Date: Mon, 17 Jul 2006 21:03:04 -0700

I second Ted's opinion.

-----Original Message-----
From: Ted Faber [mailto:[email-masked]] 
Sent: Monday, July 17, 2006 11:03 AM
To: Joe Touch
Cc: [email-masked]
Subject: Re: [tcpm] feedcback on tcp-secure-05

As a participant, not a chair.

On Sun, Jul 16, 2006 at 10:00:21PM -0700, Joe Touch wrote:
> The ICMP document is a general document; this document [tcpsecure 
> --tvf]  (IMO) is more about what to do when under suspected attack (or

> should be, to some extent).

That's more broad a view of tcpsecure than the one I have.  It's a
mitigation of a specific attack vector, not a handbook for dealing with
off-path TCP attacks.  Personally I prefer to keep it more tightly
scoped so there's a chance of finishing it.

> If tcp-secure doesn't recommend blocking when tcp-secure is active 
> (i.e., when such attacks are suspected), then there is no point to the

> rest of tcp-secure. It is useless to address the more challenging 
> spoofing attack vector and not address the easier one.

While I'm not opposed to adding text to that effect, I don't think it's
a requirement.  There are plenty of other possibilities for attack when
the tcpsecure code additions are exercised, and I don't see that this
document needs to address them all.  For that matter, the tcpsecure
document has never proposed a detection mechanism for those attacks.
All that is new work, and IMHO, well beyond the scope of the document
that the WG agreed to.  I'm happy to be convinced otherwise.

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

---

From: "Anantha Ramaiah \(ananth\)" <[email-masked]>
Date: Tue, 18 Jul 2006 08:21:22 -0700

> From: Joe Touch [mailto:[email-masked]] 
> Sent: Tuesday, July 18, 2006 6:33 AM
> To: Anantha Ramaiah (ananth)
> Cc: Fernando Gont; [email-masked]
> Anantha Ramaiah (ananth) wrote:
> >  
> > 
> >> From: Joe Touch [mailto:[email-masked]]
> >> Sent: Monday, July 17, 2006 7:31 AM
> >> To: Anantha Ramaiah (ananth)
> >> Cc: Fernando Gont; [email-masked]
> >> Anantha Ramaiah (ananth) wrote:
> >> ..
> >>> Another point to note is that TCP SHOULD act (not a MUST) on ICMP 
> >>> reported hard errors. Also in some cases like "port
> >> unreachable" can
> >>> be ignored since TCP uses the RST for the purpose of port
> >> unreachability.
> >>> This is as per RFC 1122. 
> >> 1122 actually states exactly the opposite:
> >>
> >>             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.
> > 
> > Yep, I stand corrected but one of main points above was to 
> point out 
> > the SHOULD language (which makes sense) instead of MUST.
> 
> So you're changing 1122? That needs to be highlighted.

Nope, I was never advocating a change of RFC 1122. I was referring to
the SHOULD language used in the RFC for treatment of 2,3 and 4 "hard
errors" which also includes "port unreachable".

4.2.3.9  ICMP Messages
.....
.....
o    Destination Unreachable -- codes 2-4

                 These are hard error conditions, so TCP SHOULD abort
                 the connection.

Hope this is clear.

> 
> >>> - Some applications would chose to ignore the so called 
> hard errors 
> >>> for a TCP connection. In other words the behaviour can be
> >> controlled
> >>> by a CLI and the default would be to ignore this hard
> >> errors. So the
> >>> connection reset wouldn't happen.
> >> The default SHOULD be to act on hard errors unless 
> overridden by the 
> >> application; to do otherwise would be to redefine 1122 in this 
> >> regard.
> > 
> > Going neutral here, since the systems which I have worked do ignore 
> > them by default and it isn't an RFC voilation.
> > 
> > As per RFC 2119 :
> > 
> > "3. SHOULD   This word, or the adjective "RECOMMENDED", 
> mean that there
> >    may exist valid reasons in particular circumstances to ignore a
> >    particular item, but the full implications must be understood and
> >    carefully weighed before choosing a different course."
> > 
> > Most of the applications would like to have a say in the 
> treatment of 
> > ICMP errors by requesting the errors to be passed to it and then 
> > determine the course of action to take. For the ICMP hard errors 
> > described, the action generally doesn't result in 
> connection closure 
> > and also some applications don't even register for some of the hard 
> > errors and also expect TCP not to close the connection instead 
> > silently ignore them
> 
> 1122 fairly directly indicates that ICMP port unreachable 
> MUST be handled exactly as a RST ("accept for the same purpose").

I agree that it says "accept for same purpose". But it also goes ahead
to suggest the "hard errors" SHOULD abort the connection instead of MUST
and the hard errors include the "port unreachable". I don't want to
argue further on this and I'll stick my point that applications today
(in many implementations) has a say in interpreting the ICMP hard errors
and it does not voilate RFC 1122.

> 
> A SHOULD would be a change to that, and needs to be 
> highlighted as a change to 1122.

We aren't changing the RFC 1122 language inside tcp-secure. I brought
this up to highlight that ICMP errors can be blocked by configuration,
firewalls etc.,..

> 
> Further, as you note above, negating a should implies that 
> the document indicate the "particular circumstances" that 
> apply. The doc doesn't currently discuss interpreting 
> violating messages as an attack and after a threshold is 
> reached THEN negating the SHOULD. That's key.
> 
> 
> > Actually application or TCP level keepalives or retransmission 
> > timeouts act as a catalyst for the connection closure generally and 
> > not ICMP errors. But YMMV and I do not intend to argue on 
> this point. 
> > Just stating my experience.
> > 
> >> ...
> >>> I guess my point is ICMP attacks may be a weakest link, but
> >> wouldn't
> >>> cause connection resets with proper installed workarounds 
> in place. 
> >>> Yes, I mean without voilating the current RFC's.
> >> Those workarounds MUST be in place, or they ARE the weakest link. 
> >> That's the point that this document must discuss at least.
> > 
> > I don't think that tcpsecure document should discuss these 
> workarounds 
> > or advise anything of that sort. It is always good to keep 
> the scope 
> > of the document right and tight.
> 
> "right and tight" isn't a justification for not discussing 
> the "particular circumstances" above.

Justification for not discussing are pretty straightforward : We feel
that it does not fir into the scope the document and adding that would
only cause incompleteness to the document.

> 
> >>> Also with or without ICMP mitigations in place, one could
> >> still cause
> >>> a TCP connection to RESET, if the mitigations described in
> >> tcp-secure
> >>> isn't present.
> >> Without ICMP protection, why bother with a RST when the ICMP is 
> >> _easier_ to generate?
> > 
> > Easier to generate but workarounds can be planted if 
> necessary like I 
> > have described in earlier emails. On the other hand there 
> aren't any 
> > known "generic workarounds" available for the issues described in 
> > tcp-secure. I say generic workarounds since MD5 is used only by a 
> > handful of applications like BGP, LDP and is a costly workaround and
> > 
> > Anyways just to summarize :
> > 
> > The tcp-secure document, can, at the most state something 
> informative 
> > like "ICMP attacks aren't covered in this document blah 
> blah..." and 
> > provide a pointer to the icmp draft if needed.
> > 
> > To suggest about blocking ICMP etc., calls for stretching 
> too far the 
> > scope of the doc and also it introduces obvious incompleteness.
> 
> I'm not going to debate this further. I'll be glad to note 
> the omission to the Security AD; if they think this doc is 
> useful without it, fine.

Ok. We would be glad to incorporate suggestions on ICMP blocking in the
tcp-secure document if there is consensus in the WG list. As it stands
now (based on the emails), the general feeling seems the other way round
ie., not to talk about blocking etc.,

So, lets keep it simple.

Thanks for the discussion though.

-Anantha
> 
> > What if
> > somebody wants to provide some pointer and suggest some 
> > blocking/mitigation mechanisms for something else..? I see 
> no end to 
> > this that way..
> > 
> > Agree/dis-agree ?
> > 
> > :)
> > -Anantha
> >> Joe
> >>
> >>
> 
>