Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements

From: "Jayshree Bharatia" <[email-masked]>
Date: Thu, 7 Aug 2003 11:04:44 -0500

Hi Pete,

I am struggling between the scope of this document and the problem we are
trying to solve. Your current proposal is applicable when FA identifies that
it is being attacked. By that time, chances are that the synchronization
(wrt challenge) between the mobile node and the FA may not be maintained.
The purpose of this draft is to provide challenge-response mechanism for the
replay protection. If it is not possible to maintain challenges the way this
draft is proposing (due to DOS attack), how far can we go in providing
solution? Although, you are suggesting to use previously unused challenge,
it still has to fall in the challenge window as per the current text in this
draft.

If the FA already knows that it is being attacked, I would think that it can
also take actions like not sending the response or sending the response
without challenge. For me, this will have same impact of repeating previous
challenge (at least in this context). So my earlier email indicated that
leave it up to the FA how it wants to recover. 

So the question I have is, in this document, are we trying to maintain the
correct challenge window or are we trying to recover from the attack? This
will help formulating the text for the "security consideration" section.

Regards,
Jayshree
 
> -----Original Message-----
> From: Pete McCann [mailto:[email-masked]] 
> Sent: Wednesday, August 06, 2003 4:40 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Henrik Levkowetz; 
> [email-masked]; [email-masked]'
> Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis 
> challenges in s olicited ag ent advertisements
> 
> 
> 
> Hi, Jayshree,
> 
> Jayshree Bharatia writes:
>  > Pete,
>  > 
>  > I disagree with the proposed text for the reason mentioned 
> earlier for  > option 1 on this thread. 
> 
> Let me see if I understand your objection.  Here is your 
> statement about Option 1:
> 
>  > Option 1: Not preferred since the whole point of using the 
> challenge in the  > agent advertisement is so that the MN can 
> use this challenge information in  > the registration 
> procedure if needed. Restricting new challenge value breaks  
> > the mechanism. I have reservation toward treating this 
> specific case  > differently especially since it has side 
> effect (mentioned above).
> 
> So, are you worried that if we duplicate the Challenge, then 
> it might not be a fresh challenge that the MN can use?
> 
> However, any challenge that is sent to the MN in either an 
> RRQ or an Advertisement must be previously unused, as stated 
> explicitly in the body of the document and in the text I 
> proposed for the security considerations.  So by definition, 
> this challenge will be useful to the MN for its next RRQ.  Is 
> there something I have misunderstood?
> 
>  > If we have solution to the problem Henrik has
>  > pointed out, I agree that we must include that in this 
> document. From the  > discussion we are having so far, it 
> seems we don't have clean solution to  > survive 
> challenge-response mechanism from the DOS attack. If the FA  
> > identifies that it is attacked, it can take actions like 
> what it could have  > done normally (when no 
> challenge-response mechanism is used). 
> 
> What mechanisms are you referring to?  There is a statement 
> about rate-limiting agent advertisements in RFC 3344; 
> however, it does not apply to unicast advertisements.
> 
> -Pete
> 
> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 11 Aug 2003 07:54:57 -0500

> 
> Hi, Ahmad,
> 
> Ok, good... do you have a suggestion for how to handle the 
> security considerations text?
> 
> In light of our discussion, it seems like the FA should be 
> repeating the challenge from its data structure for the MN, 
> if it has a valid visitor list entry.  Otherwise, it is ok to 
> repeat the last value from the Challenge-Window.  This 
> "latest" challenge can be changed (either on a global or 
> per-MN basis) on a relatively slow timescale, but should not 
> be changed by un-authenticated RRQs or agent solicitations.  
> Could you capture this with some wording you are happy with?
>
 
Hi Pete, Mr. Co-Chair,

Beside what general requirement any box needs to have for defeating a DOS
attack, I do not think we need any special handling with respect to the
MN-FA Challenge.

Regards,
Ahmad