Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?

[Ahmad Muhanna <[e-mail]>]

Alex,

Just to close on the issue that the specification does NOT have anything which requires the MN to synchronizes and send a new RREQ,

Here what the specification says:
"
3.6.2.3.  Registration Request Denied

   If the Code field indicates that service is being denied, the mobile
   node SHOULD log the error.  In certain cases, the mobile node may be
   able to "repair" the error.  These include:

.....
.....

   Code 133: (Denied by home agent, registration Identification
      mismatch)

      In this case, the Identification field in the Registration Reply
      will contain a value that allows the mobile node to synchronize
      with the home agent, based upon the style of replay protection in
      effect (Section 5.7).  The mobile node MUST adjust the parameters
      it uses to compute the Identification field based upon the
      information in the Registration Reply, before issuing any future
      Registration Requests.

"

The specification leaves that to the implementation. However, the specification describe what the MN can do to fix the error. As I said, it is the responsibility of the MN to keep its registration alive at the Home Agent.

What does this mean: 
It is GIVEN: If the MN would like to continue to being served by its Home Agent using the Home address that was allocated to the MN, the MN MUST re-register before lifetime expires. I assume we agree on this.

OK. If the MN while re-registering receives an error code 133, the MN has a choice:
1. Ignore the RRP and do nothing and consequently loses its connection to the internet and for sure will NOT be able to use its allocated home address, OR
2. The MN uses section 3.6.2.3. of how to correct the 133 error and maintain its connectivity.

I hope this makes sense.
I will respond to your detailed procedure shortly.
Cheers!

Best Regards,
Ahmad

-----Original Message-----
From: Alexandru Petrescu [mailto:[e-mail]] 
Sent: Thursday, March 21, 2013 10:30 AM
To: Ahmad Muhanna
Cc: Kent Leung (kleung); [e-mail]
Subject: Re: [Mip4] Does MIP support RegReq authentication without having to do timekeeping?

Le 14/03/2013 23:14, Ahmad Muhanna a écrit :
> Alex,
>
> The MN/MR needs to send another RRQ; It is not just a warning.
> Otherwise, its Registration will timeout and the HA will delete its 
> binding.

YEs, that is right.  But the specification doesn't say that so explicitely.

> There was a reason for the MN to send a Re-Registration, most probably 
> extends its registration lifetime, for example. If the Reply is NOT 
> successful, the MN can NOT assume its registration has been extended 
> successfully. Thus, the MN/MR needs to send another RRQ.

Yes.

> This uis the behavior I have seen many times of very popular MIP4 MNs.
>
> BTW: also, the purpose of 133 error code is to let the MN know that 
> its time stamp is NOT in synch with the HA. Usually, the Mobile node  
> will adjust its timestamp according to what is coming from the HA. I  
> have seen this a lot!! :-)

Ok.  So we now do it as well.  Our implementation of MR works with the HA from that manufacturarer - synchronizes time.  I will post separately the procedure.

Alex

>
> Anyhow; enjoy your IETF meeting!
>
> Best Regards, Ahmad
>
> -----Original Message----- From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Alexandru Petrescu Sent:
>  Thursday, March 14, 2013 4:41 PM To: Kent Leung (kleung) Cc:
> [e-mail] Subject: Re: [Mip4] Does MIP support RegReq 
> authentication without having to do timekeeping?
>
> Kent,
>
> Thanks for the discussion and clarification.  Thanks for the pointer  
> to the spec RFC5944 says:
>
> "   Code 133: (Denied by home agent, registration Identification
> mismatch)
>
> In this case, the Identification field in the Registration Reply will 
> contain a value that allows the mobile node to synchronize with the 
> home agent, based upon the style of replay protection in effect 
> (Section 5.7).  The mobile node MUST adjust the parameters it uses to 
> compute the Identification field based upon the information in the 
> Registration Reply, before issuing any future Registration Requests."
>
> When we read this last phrase we didnt see an incentive to send 
> another RREQ containing the Id copied from the RREP.  Reads more like 
> a warning to take care next time, but it doesnt explicitely say that 
> the HA expects a RREQ in the immediate, and that the MR should send 
> it.
>
> We could only rely on the error log in the HA, which doesnt invite to 
> send another RREQ either, it says:
>
> "Mar 11 09:35:55.107: MobileIP: HA rejects registration for MN
> 13.8.9.3 - registration id mismatch (133) Mar 11 09:35:55.107:
> MobileIP: Sending Registration Reply message for MN 13.8.9.3 with 
> Lifetime 40, Home Address 13.8.9.3, Home Agent 13.8.9.4 Code 133 "
>
> Alex
>
> Le 14/03/2013 21:15, Kent Leung (kleung) a écrit :
>> Timestamp is one of the fields in the message that is protected by  
>> key using a hash function. Since we are at IETF, let's talk offline 
>> as this seems to need some clarification and hand waving.
>> :)
>>
>> Kent
>>
>> -----Original Message----- From: Alexandru Petrescu 
>> [mailto:[e-mail]] Sent: Thursday, March 14,
>> 2013 1:12 PM To: Kent Leung (kleung) Cc: [e-mail] Subject:
>> Re: [Mip4] Does MIP support RegReq authentication without having to 
>> do timekeeping?
>>
>> Le 14/03/2013 21:07, Kent Leung (kleung) a écrit :
>>> The Authenticator value is different for RRQ vs RRP. The extension 
>>> carries different value based on the message. The way to calculate 
>>> the value requires the shared key between MR and HA.
>>> So it's not easy for an attacker to know the key.
>>
>> Yes, there is a key which is hardly guessable.
>>
>> Do you think the same key could be used precisely in the same manner 
>> in the first place, for the first RREQ, without timestamp?
>>
>> Alex
>>
>>>
>>> Kent
>>>
>>> -----Original Message----- From: Alexandru Petrescu 
>>> [mailto:[e-mail]] Sent: Thursday, March 14,
>>> 2013 1:03 PM To: Kent Leung (kleung) Cc: [e-mail] Subject:
>>> Re: [Mip4] Does MIP support RegReq authentication without having  to 
>>> do timekeeping?
>>>
>>> Le 14/03/2013 20:59, Kent Leung (kleung) a écrit :
>>>> The RRP1 cannot be faked since the MN-HA Auth Ext protects the 
>>>> message.
>>>
>>> I strongly doubt that.  Were it so, then the same extension could 
>>> protect the first RRQ1 as well.
>>>
>>> I believe it is possible for an attacker HA to intercept the initial 
>>> RRQ1(time=1970), and the RRP1(time=2013) and fake a RREP  towards 
>>> the MR. No?
>>>
>>> Alex
>>>
>>>>
>>>> Kent
>>>>
>>>> -----Original Message----- From: Alexandru Petrescu 
>>>> [mailto:[e-mail]] Sent: Thursday, March 14, 
>>>> 2013 12:58 PM To: Kent Leung (kleung) Cc: [e-mail]
>>>> Subject: Re: [Mip4] Does MIP support RegReq authentication without 
>>>> having to do timekeeping?
>>>>
>>>> Le 14/03/2013 20:47, Kent Leung (kleung) a écrit :
>>>>> Hmm, I'm not clear with your response.
>>>>>
>>>>> Let's assume the following scenario.
>>>>>
>>>>> 1. MR sends initial RRQ1 (time=a) to HA 2. HA sends RRP1
>>>>> (time=b) with code 133
>>>>
>>>> Ok.  Do you think MR receiving this RRP1 will be able to safele 
>>>> verify it is legitimate?  Or is it possible than an attacker HA 
>>>> fakes this RRP1 message?
>>>>
>>>>> 3. MR sends RRQ2 (time=b+) 4. HA sends RRP2(time=b+) => 
>>>>> registration successful 5. After MR recovers from failure, MR 
>>>>> sends RRQ3(time=c) 6. HA sends RRP3(time=d) with code 133 7.
>>>>> MR sends RRQ4(time=d+) 8. HA sends RRP4(time=d+) => reregistration 
>>>>> successful
>>>>
>>>> These latter steps 3-8 make sense.
>>>>
>>>> Alex
>>>>
>>>>>
>>>>> We would need to confirm if #6 happens properly for a specific 
>>>>> vendor. :) But I would expect #7 should happen if code 133 is 
>>>>> received.
>>>>>
>>>>> Kent
>>>>>
>>>>> -----Original Message----- From: [e-mail] 
>>>>> [mailto:[e-mail]] On Behalf Of Alexandru Petrescu 
>>>>> Sent: Thursday, March 14, 2013 12:40 PM To:
>>>>> [e-mail] Subject: Re: [Mip4] Does MIP support RegReq 
>>>>> authentication without having to do timekeeping?
>>>>>
>>>>> Le 14/03/2013 20:38, Kent Leung (kleung) a écrit :
>>>>>>
>>>>>> It needs to have the time, even if it does second registration. 
>>>>>> It's not a problem it takes longer (we can send easily two 
>>>>>> messages). But the second message will also be refused by the HA 
>>>>>> because it still has the wrong time.
>>>>>>
>>>>>> KL> Why is the timestamp in the 2nd RRQ wrong?
>>>>>
>>>>> Because the computer has lost its time, because it was turned off 
>>>>> long time (vehicle in garage for several weeks in winter time). It 
>>>>> now has year 1970.
>>>>>
>>>>> Alex
>>>>>
>>>>>>
>>>>>> Kent
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> -- Mip4 mailing list: [e-mail] Web interface:
>>>>> https://www.ietf.org/mailman/listinfo/mip4 Charter page:
>>>>> http://www.ietf.org/html.charters/mip4-charter.html
>>>>> Supplemental site: http://www.mip4.org/
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
> -- Mip4 mailing list: [e-mail] Web interface:
> https://www.ietf.org/mailman/listinfo/mip4 Charter page:
> http://www.ietf.org/html.charters/mip4-charter.html Supplemental
> site: http://www.mip4.org/
>
>