RE: Problems with implementation - DoS attacks possible

Does option 2 mean that the router has to hang on to a list of hosts to
which it sent messages using the latest key, then send them messages
containing only a key disclosure element when the key changes?

> -----Original Message-----
> From: Leech, Marcus [CAR:W669:EXCH] 
> Sent: Thursday, January 23, 2003 10:50 AM
> To: Tomasz Grabowski
> Cc: [email protected]
> Subject: 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------
>