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

From: "Jayshree Bharatia" <[email-masked]>
Date: Wed, 6 Aug 2003 13:17:43 -0500

Pete,

I disagree with the proposed text for the reason mentioned earlier for
option 1 on this thread. 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). 

Regards,
Jayshree
> -----Original Message-----
> From: Pete McCann [mailto:[email-masked]] 
> Sent: Wednesday, August 06, 2003 12:37 PM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Henrik Levkowetz; [email-masked]; Bharatia, Jayshree 
> [RICH1:2H13:EXCH]; [email-masked]'
> Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis 
> challenges in s olicited ag ent advertisements
> 
> 
> 
> Hi, Ahmad,
> 
> See below.
> 
> Ahmad Muhanna writes:
>  > > How about this for the security considerations:
>  > > 
>  > >   Note that an active attacker may try to prevent successful
>  > >   registrations by sending a large number of Agent 
> Solicitations or
>  > >   bogus Registration Requests, each of which could cause 
> the FA to
>  > >   respond with a fresh challenge, invalidating the 
> challenge that the
>  > >   MN is currently trying to use.  To prevent such attacks, the FA
>  > >   SHOULD repeat the same challenge value in successive unicast
>  > >   responses to Agent Solicitations or in Registration Replies to
>  > >   Requests that did not contain valid MN-AAA or MN-FA 
> authentication
>  > >   extensions for some limited period of time.  Note that each
>  > >   challenge returned to an MN MUST be previously unused 
> by that MN.
>  > > 
>  > 
>  > Honestly, I am not sure if we are trying to restrict the 
> standard for remote  > attacks that is not frequently happens 
> nor absolutely prevented.  > It is usually hard to prevent 
> any of these attacks anyway. 
> 
> Yes, denial of service is possible for anyone that has access 
> to the channel (just flood it with traffic); however, we 
> should make every effort to ensure that our standards do not 
> introduce new possible attacks to Mobile IP registration or 
> make existing attacks any easier. I think that is what the 
> current 3012-bis document may have done, unless the 
> implementation is very careful to prevent it.
> 
>  > The robust solution in my opinion is the one which offers 
> a mechanism for  > the REAL MN to fight and recover from the 
> consequences of such attack.
> 
> Agreed.
> 
>  > Let us assume that one of these attacks happens. 
>  > RFC3012bis offers a recovery solution for the real MN.
>  > In any of the mentioned scenarios happened, the REAL MN 
> would be able to  > solicit and use the challenge received to 
> register.
> 
> The scenario I have in mind is where an attacker inserts a 
> new solicitation (or even bogus registration request) right 
> after every advertisement or registration reply to the MN.  
> This enables denial of service to the MN without requiring 
> the attacker to completely flood the channel; i.e., it is a 
> stronger kind of attack that we have opened up with the 
> Challenge mechanism.
> 
>  > The main concern is what the standard mandating, FA does 
> not send a  > previously used challenge to MN.  > FA sends a 
> fresh one in RRP or AA messages, let us leave it to  > 
> implementation with the unused challenge restriction.
> 
> We should be writing a document that enables anyone to 
> implement the specification in a robust way, even those that 
> have not participated in or seen this e-mail thread.  We 
> should not be hiding easter-eggs for deployments to trip over 
> later.  Do you really object to the note that I suggested for 
> the security considerations section?
> 
> -Pete
> 
> 

_______________________________________________
Mip4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mip4

---

From: Pete McCann <[email-masked]>
Date: Wed, 6 Aug 2003 16:40:20 -0500

Hi, Jayshree,

Jayshree Bharatia writes:
 > 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

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