Subject: RE: [mobile-ip] RFC3012-bis question

From: "Woojune Kim" <[email-masked]>
Date: Wed, 29 Jan 2003 19:16:11 -0500

Siva,

Yes, that is more or less the same conclusion I reached. 

But while it wouldn't be correct to change the FA's behaviour, wouldn't it be better to one of the following ?

1) change MN's reaction to MISSING_CHALLENGE and state that for cases where it was received when MN had actually included it, the MN should do something, such as stop sending it to this HA as you suggested.

2) have the FA use a new error code (say MISSING_HA_CHALLENGE)..

But wouldn't it also be possible to soften the sec 3.2 requirement to say if Challenge Ext is not in the HA RRP, we just pass it on to the MN ? After all, I don't think just the fact that the HA doesn't understand the Challenge Ext should be the reason for not being able to connect to the network. It doesn't seem to be very robust. 

Of course, this may raise various security issues. Actually, what was the original reasoning behind including the challenge ext for the MN and demanding that it be the same ?

thanks

Woojune

-----Original Message-----
From: Sivasundar Ramamurthy [mailto:[email-masked]]
Sent: Wednesday, January 29, 2003 7:09 PM
To: Woojune Kim
Cc: [email-masked]
Subject: Re: [mobile-ip] RFC3012-bis question 

Hi Woojune,

With the spec as is, the "infinite loop" is what should happen. 

It is the MN that should probably end this loop by stopping to send
requests for this HA. When the MN receives this error code, it can
conclude that it is the HA that is the reason for the FA setting the
error code since the MN _did_ include the challenge in the request.

I dont think the FA should adjust its rules and accomodate a HA that
does not understand challenges.

Siva

> Hi,
> 
> I've been reading RFC3012-bis-v4 and found something that doesn't seem to fit (at least in my mind). Please enlighten me.
> 
> Near the end of  Sec 3.2, it says
> 
> " .. 
>    If the Foreign Agent does not remove the Challenge extension, then
>    the Foreign Agent SHOULD store the Challenge value as part of the
>    pending registration request list [7].  Also in this case, the
>    Foreign Agent MUST reject any Registration Reply message coming from
>    the Home Agent that does not also include the Challenge Extension
>    with the same Challenge Value that was included in the Registration
>    Request.  The Foreign Agent MUST send the rejected Registration
>    message to the mobile node, and change the status in the Registration
>    Reply to the Code value MISSING_CHALLENGE (see section 10).
> .."
> 
> Now this seems to imply that if the FA decides to keep the
> challenge ext in the RRQ it forwards to the HA, it expects the HA
> to return it in the Reply, and notify the MN of this fact with the
> MISSING_CHALLENGE value.
> 
> But if you look at what the MN does when it receives a
> MISSING_CHALLENGE in sec 3.1
> 
> "..
>    MISSING_CHALLENGE: A Mobile Node that does not include a Challenge
>    when the Mobile-Foreign Authentication extension is present may
>    receive a MISSING_CHALLENGE error.  In this case, the Mobile Node
>    SHOULD send an unused Challenge extension in the next Registration
>    Request.
> .."
> 
> So presumably the MN will again send a RRQ with a challenge extension.
> 
> Assuming the FA and HA act in the same manner as before, we get into a loop. 
> 
> Now the root cause is the HA returns a RRP without a challenge
> extension when the FA is expecting one. But can the HA ever return
> a RRP without a challenge ? Again in Sec 3.4 it says ..
> 
> " ..
>    Since the extension type for the Challenge extension is within the
>    range 128-255, the Home Agent MUST process such a Registration
>    Request even if it does not recognize the Challenge extension [7].
>    In this case, the Home Agent will send a Registration Reply to the
>    Foreign Agent that does not include the Challenge extension.
> .."
> 
> Assuming the HA doesn't understand the challenge extension, it
> will ignore it, presumably make a correct RRP and send it back to
> the FA. But, as it doesn't understand the challenge extension, it
> will NOT be included in the RRP.
> 
> So, the end result is that it looks like we have the potential to
> get into a infinite loop.
> 
> Am I missing something basic here ?
> 
> thanks
> 
> Woojune 
> 
> 

--------
Regards,

Siva

====================================
Sivasundar Ramamurthy		
Mobile IP Project
(408) 447 7255
====================================

---

From: Sivasundar Ramamurthy <[email-masked]>
Date: Wed, 29 Jan 2003 16:36:55 -0800 (PST)

> But while it wouldn't be correct to change the FA's behaviour,
> wouldn't it be better to one of the following ?
> 
> 1) change MN's reaction to MISSING_CHALLENGE and state that for
> cases where it was received when MN had actually included it, the
> MN should do something, such as stop sending it to this HA as you
> suggested.
> 

In this case the MN can directly conclude, rather than deduce, that
it is the HA. But we can live without it...
 
> But wouldn't it also be possible to soften the sec 3.2 requirement
> to say if Challenge Ext is not in the HA RRP, we just pass it on
> to the MN ? After all, I don't think just the fact that the HA
> doesn't understand the Challenge Ext should be the reason for not
> being able to connect to the network. It doesn't seem to be very
> robust.
> 
> Of course, this may raise various security issues. Actually, what
> was the original reasoning behind including the challenge ext for
> the MN and demanding that it be the same ?

Sometimes the FA has to include the challenge in the request, as when
the request is processed by a Diameter AAA server.

But I dont know why it is a MUST that the HA send it back in the
reply. In the first place, it is optional for the FA to include the
challenge when forwarding the request directly to the HA. I can only
conclude that it is some kind of an optional security enhancement...??

Siva