Re: [secdir] Secdir review of draft-ietf-tcpm-tcp-lcd-02

[Alexander Zimmermann <[e-mail]>]

Hi Lars, Hi Catherine,

due to vacation, we are a little bit behind our schedule...
Please give us one more week. We will definitely incorporate
the feedback.

Alex

Am 31.08.2010 um 10:57 schrieb Lars Eggert:

> Hi,
> 
> this is a good suggestion. Authors, would you work this into the text?
> 
> Lars
> 
> On 2010-8-27, at 23:08, Catherine Meadows wrote:
> 
>> Hi Lars:
>> 
>> Thanks for your comments.  I perhaps did not appreciate completely the significance of this being an experimental ID.
>> 
>> Still, I think that the security considerations section could use some improving.
>> Simply presenting one example of an attack without adequate motivation as to why this
>> attack is the most relevant one merely confuses the reader (or at least that was the effect on me).
>> I would suggest that the authors add more motivation such as you give in your email,
>> namely that the only behavior change required by this protocol is in the response
>> to ICMP messages, and thus that the only way an attacker could cause a change in behavior
>> of the protocol is by either causing more or few ICMP messages to be generated than would have
>> occurred otherwise.  Then you could discuss the goals of the attacker;  I think it is reasonable to assume,
>> as the authors do, that the only possible goal is denial of service, since the ICMP messages are not used
>> for authentication or to control access to sensitive information.  But it wouldn't hurt to point this out.
>> Then you could discuss the contribution of spurious or suppressed ICMP messages to a denial of service attack (minimal).
>> You could then discuss the problem of spoofing or suppressing ICMP messages, although this may not be necessary
>> if the effect is minimal.   At any case,  this would give you a more convincing argument that the protocol does not introduce
>> any security vulnerabilities, and it doesn't require much more than bringing forward and tying together information that is
>> already in the ID.
>> 
>> Cathy
>> 
>> On Aug 26, 2010, at 1:17 PM, Lars Eggert wrote:
>> 
>>> Hi, authors,
>>> 
>>> please respond to the point Catherine raises.
>>> 
>>> (Catherine, a few comments from my side are included below.)
>>> 
>>> 
>>> On 2010-8-24, at 1:28, Catherine Meadows wrote:
>>>> I have reviewed this document as part of the security directorate's
>>>> ongoing effort to review all IETF documents being processed by the
>>>> IESG.  These comments were written primarily for the benefit of the
>>>> security area directors.  Document editors and WG chairs should treat
>>>> these comments just like any other last call comments.
>>>> 
>>>> This document proposes an algorithm to make TCP more robust to long connectivity
>>>> disruptions.  Currently TCP has no way of distinguishing disruptions due to connectivity
>>>> loss from disruptions due to congestion.   Thus, TCP will back off when faced with connectivity
>>>> loss, which will lead to further delays.  The proposed algorithm uses the ICMP destination unreachable
>>>> messages as indications of a connectivity disruption, and alters the behavior of TCP accordingly.
>>>> 
>>>> My impression from reading this draft is that the behavior and utility of this algorithm will depend on
>>>> further research and experimentation.  There are a number of situations in which it will still be possible
>>>> to confuse congestion and long connectivity disruptions that may need further exploration.  The authors of the document do a good job of pointing
>>>> these out, but I would have liked to have seen more evidence that the solutions recommended are the optimal
>>>> ones, and under what situations.
>>> 
>>> The goal of this mechanism is not to be optimal (TCP as a whole is not trying to be optimal). The goal is to improve things in many cases and not cause harm in realistic all cases.
>>> 
>>>> This is especially the case for the security issues, although it is not
>>>> limited to those.  For example, in the discussion of probing frequency in Section 5.4 the authors make a claim
>>>> that in their belief the approach of their algorithm is preferable to others that would give higher probing
>>>> frequency, but they need to provide more evidence to back this up.
>>> 
>>> I think it is fine for an Experimental document to state a belief and ask people to verify it with experiments. For a standards-track document, yes, we'd absolutely like to see which one is the one to pick.
>>> 
>>>> The security considerations section itself is rather sketchy, and doesn't support that authors' assertions
>>>> that the algorithm is "considered to be secure."  The greatest security threat posed by this
>>>> algorithm is that an attacker could exploit it to persuade a TCP sender that communication problems
>>>> due to congestion are actually due to a connectivity problem, leading the sender to further contribute to the
>>>> congestion.
>>> 
>>> Remember that this mechanism only makes a difference during timeout-based loss recovery, i.e., when TCP at most sends a packet or two over often many seconds. And even when it fires, it doesn't result in a flood of packets, all it results in is that a slow-start restart will be attempted earlier than without this mechanism. So the potential for harm is really low.
>>> 
>>>> However, the authors mention only one possible attack: forging ICMP destination unreachable
>>>> messages, which they present only as an "example" of an attack.
>>> 
>>> It's presented of an example where even if the attacked could pull it off, the mechanism is still unaffected. 
>>> 
>>>> I would recommend a more complete
>>>> discussion, considering each of the potential ambiguity cases discussed in the document, and discussing
>>>> how an attacker could exploit them and how such exploitation could be prevented or mitigated.  You might
>>>> also want to discuss the opposite problem: how an attacker could convince a sender that a connectivity
>>>> problem is a congestion problem.  This is less serious, at least for the moment, since in the current
>>>> situation that is exactly what happens, but it could be more of a threat further down the line if people come
>>>> to rely more on this ability to disambiguate.
>>> 
>>> If the authors can think of any other attacks, they should absolutely include them, but since ICMPs are the only signal the mechanism reacts to, generating fake ones or suppressing real ones are pretty much the only attack angles I can think of.
>>> 
>>> Lars
>>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> Catherine Meadows
>>>> Naval Research Laboratory
>>>> Code 5543
>>>> 4555 Overlook Ave., S.W.
>>>> Washington DC, 20375
>>>> phone: [phone]
>>>> fax: [phone]
>>>> email: [e-mail]<mailto:[e-mail]>
>>>> 
>>> 
>>> Lars
>> 
>> Catherine Meadows
>> Naval Research Laboratory
>> Code 5543
>> 4555 Overlook Ave., S.W.
>> Washington DC, 20375
>> phone: [phone]
>> fax: [phone]
>> email: [e-mail]
>> 
> 

//
// Dipl.-Inform. Alexander Zimmermann
// Department of Computer Science, Informatik 4
// RWTH Aachen University
// Ahornstr. 55, 52056 Aachen, Germany
// phone: [phone], fax: [phone]
// email: [e-mail]
// web: http://www.umic-mesh.net
//