Re: Problems with implementation - DoS attacks possible

Tomasz Grabowski wrote:
> 
> 
> In my proposition you can attack victim1 from zombie1 again after the
> KEY_C has been generated. In ICMP Traceback messages hashed with KEY_C
> Key Disclosure List element may have only KEY_B because, according to
> the draft, it "MUST contain at least one Key Disclosure subelement".
> "At least" means that it can contain only one key subelement (KEY_B) and
> not KEY_A.
> What I'm saying here is that this sentence is very bad and can lead to
> security bug in protocol specification. It must be exectly specified how
> many subelements should be in the Key Disclosure List.
> Can anyone tell me how long TAG=0x0E can be (in octets)? The problematic
> are KEY MATERIAL and SIGNATURE fields ofcourse.
>
I *think* that what you're saying here is that the document needs to specify
  reasonable upper bounds for the number of key disclosures.  I don't think that
  we need to say "must contain exactly 'N'".  The key disclosure list element
  (Tag=0x0D) is optional, so when you don't have any keys to disclose, you
  don't include the list.  Perhaps the wording should make this clear.

> 
> Agreed. But if there will be a method to authenticate an ICMP Traceback
> message after the DDoS attack has stopped, your "moving DDoS" attack will
> not work. The question is how can we do this?
> 1. Add some kind of method to get ICMP Traceback message from router (hard
> to do because only those to which we sended ICMP Traceback messages should
> be able to request another such message from us).
> 2. After key change we should send ICMP Traceback messages to hosts to
> which we sended previous ICMP Traceback messages (hashed with previous
> key).
> 
> I can tune one of this solutions (propably no.2) if we want to prevent
> "moving DDoS" attacks. I'm waiting for opinions.
> 
I like solution number 2.  It doesn't increase traffic volume appreciably, and
  I can't see that it does any harm.  In a DDoS situation, of course, it may
  get dropped.  This is better than nothing.

-- 
----------------------------------------------------------------------
Marcus Leech                             Mail:   Dept 8M70, MS 012, FITZ
Advisor                                  Phone: (ESN) 393-9145  +1 613 763 9145
Security Architecture and Planning       Fax:   (ESN) 393-9435  +1 613 763 9435
Nortel Networks                          [email protected]
-----------------Expressed opinions are my own, not my employer's------