Subject: RE: [Mip6] MIPv6: Using the last Accepted Sequence Number in BA

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 19 May 2006 10:54:03 -0500

All,

One very minor correction to both scenarios,

In step 6, sequence number should have been 1001 and in step 8 sequence
number should have been 1002.

Regards,
Ahmad

> -----Original Message-----
> From: Khalil, Mohamed [RICH2:2S20:EXCH] 
> Sent: Friday, May 19, 2006 10:47 AM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Muhanna, Ahmad [RICH2:2Q30:EXCH]; [email-masked]'; 'Gopal 
> Dommety'; 'Charles E. Perkins'; [email-masked]'; 
> [email-masked]'; 'Basavaraj Patil'; 'Vijay Devarapalli'
> Subject: RE: [Mip6] MIPv6: Using the last Accepted Sequence 
> Number in BA
> 
> 
> 
> Ahmad,
> 
> Thank you for making it clear that we need a clean solution. 
> Let us repeat this scenario Ahamd's brought up with the clean solution
> 
> 1. MN accidentally reboots and loose track of the last 
> accepted sequence number e.g. (1000). 2. MN sends a BU with 
> seq. number = 1 
> 3. HA sends a BA with status 135 and sequence number = 1, 
> with a new proposed SQ option = 1000. 4. Man in the middle 
> capture BA from step 3 and save. 5. MN receives BA (from step 
> 3) and process successfully according to the new proposal 6. 
> MN sends a BU with seq. # of 1000 to the HA. 7. MN receives a 
> successful BA with seq. # 1000. 8. After some time, MN sends 
> another BU with seq. # = 1001, for example. 9. Man in the 
> middle replay BA captured in step 4. 
> 10. MN receives BA (step 9) and reject it because SQ# 
> mismatch (replay protection). 11. MN receives BA with seq 
> =1001 and process it successfully
> 
> no replay attack with the new proposal
> 
> 
> [Ahmad wrote]
> 
> I see this issue has two folds which we need to address.
> 
> 1. The solution, as per RFC3775, in communicating the last 
> accepted sequence number violates the basic principle of 
> replay protection mechanism using sequence number. In other 
> word, when we allow the Mobile Node to accept the BA based on 
> the status (135) ONLY, we are asking the MN to ignore replay 
> protection mechanism all together. 
> 
> 2. The more serious problem is a security issue. In the case 
> of the HA where there is manual IPsec, any man in the middle 
> can replay an old BA with a status of 135 and makes the 
> Mobile Node to think that the sequence number in BA is the 
> last accepted sequence number.
> 
> Here is an example:
> 
> 1. MN accidentally reboots and loose track of the last 
> accepted sequence number e.g. (1000). 2. MN sends a BU with 
> seq. number = 1 
> 3. HA sends a BA with status 135 and sequence number = 1000.
> 4. Man in the middle capture BA from step 3 and save.
> 5. MN receives BA (from step 3) and process successfully 
> according to current RFC3775. 6. MN sends a BU with seq. # of 
> 1000 to the HA. 7. MN receives a successful BA with seq. # 
> 1000. 8. After some time, MN sends another BU with seq. # = 
> 1001, for example. 9. Man in the middle replay BA captured in step 4. 
> 10. MN receives BA (step 9) and process successfully.
> 
> In my opinion, this a successful replay attack.
> 
> 
> Thanks,
> Ahmad
> 
> 
> > 
> > the text in section 11.7.3 needs to be fixed when
> > RFC 3775 is revised.
> > 
> > thanks for catching this.
> > 
> > Vijay
> > 
> > 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 
> 

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 19 May 2006 12:24:41 -0700

Mohamed Khalil wrote:
> Vijay,
> 
> 
> the status 135 combined with the sequence number in the
> binding ack *tells* the mobile node what sequence number
> it used last. this works.
> 
> MK>> The proposed solution goes in line and consistent with what MIPv6
> standard mentioned that the sequence number should be copied into the
> BA. The current solution for 135 makes an exception for the sequence
> number rule which is not needed. I still believe going with a clean
> solution is better.

going forward I think we might be embedding more
information in a failed binding ack. IMO, we should
remove the text about ignore all binding acks with
status > 128.

Vijay

> 
> 
> this was added to address the case where the mobile node reboots
> suddenly and forgets about its binding cache entries at the HA or the CN
> when it comes up again.
> 
> MK>> I can understand that, thx.
> 
> Vijay
> 
>> From: Vijay Devarapalli [mailto:[email-masked]]
>> Sent: Thursday, May 18, 2006 4:14 PM
>> Cc: [email-masked]; Gopal Dommety; Charles E. Perkins;
>> [email-masked]; [email-masked]; Basavaraj Patil; Khalil,
>> Mohamed [RICH2:2S20:EXCH]
>> Subject: Re: [Mip6] MIPv6: Using the last Accepted Sequence Number in
> BA
>>
>> Ahmad Muhanna wrote:
>>> Hi all,
>>>
>>> In response to a Binding Update which contains an out of range
>>> sequence
>>> number, as per sections 9.5.1 and 11.7.1, the CN or HA is allowed to 
>>> send a Binding Acknowledgement with a status of 135 after inserting
>> the
>>> last accepted sequence number received in the last valid Binding
>> Update
>>> in the sequence number field (Different from the sequence number
>>> received in the outstanding BU)
>>>
>>> According to MN processing of the Binding Acknowledgement as 
>>> specified under section 11.7.3., the MN will silently discard the 
>>> received BA rather than picking the last accepted sequence number and
> 
>>> then
>> generate
>>> a new sequence number.
>>>
>>> I think the intention was to allow the HA or CN to communicate back 
>>> to the MN the last accepted sequence number, however, we are breaking
> 
>>> the
>>> protocol by using this mechanism.
>>>
>>> Could you please comment on this and let me know if I am on the right
> 
>>> track.
>> when the mobile node receives a binding ack with
>> status 135, it should pick a sequence number
>> greater than what was returned in the binding ack
>> and re-try with another binding update. it should
>> not ignore the sequence number field in the
>> binding ack.
>>

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 19 May 2006 15:15:10 -0700

Mohamed Khalil wrote:
> Vijay,
> 
> The protocol should be robust enough and accommodate all cases. There is
> no guarantee that the BU will be sent encrypted. also there is no
> guarantee that we will be using dynamic IPSec.

I took all these into account when I replied. it will work
even with the authentication option protocol. let me know
if I missed something.

The proposed solution
> doesn't require encryption for the payload to protect against replay
> attacks in case of IPSec manual configuration, and auto authentication.
> It is clean and simple solution which goes in line with the standard
> protocol.

sure. but I am trying to see if the existing spec (with one
clarification in section 11.7.3) would be sufficient.

Vijay

> Sent: Friday, May 19, 2006 2:39 PM
> Subject: Re: [Mip6] MIPv6: Using the last Accepted Sequence Number in BA
> 
> 
> Ahmad Muhanna wrote:
>> 1. The solution, as per RFC3775, in communicating the last accepted 
>> sequence number violates the basic principle of replay protection 
>> mechanism using sequence number. In other word, when we allow the 
>> Mobile Node to accept the BA based on the status (135) ONLY, we are 
>> asking the MN to ignore replay protection mechanism all together.
> 
> the mobile node does not actually accept the BA.
> when the status is 135, it checks only the
> sequence number field to figure out which sequence
> number it should be using.
> 
>> 2. The more serious problem is a security issue. In the case of the HA
> 
>> where there is manual IPsec, any man in the middle can replay an old 
>> BA
> 
> note this wont happen if dynamic keying is used.
> 
>> with a status of 135 and makes the Mobile Node to think that the 
>> sequence number in BA is the last accepted sequence number.
> 
> if ESP with non-null encryption is used, the
> binding ack is encrypted. the attacker cannot
> obviously figure out that this is a binding ack
> with status '135'. the attacker won't be able to
> trap this particular binding ack and replay it.
> 
> 
> MK>> what about if it is not encrypted??
> 
> 
> if you use the authentication option protocol,
> then the status field is visible. an attacker
> would be able to spot the binding ack with status
> 135 and replay it.
> 
>> Here is an example:
>>
>> 1. MN accidentally reboots and loose track of the last accepted 
>> sequence number e.g. (1000). 2. MN sends a BU with seq. number = 1
>> 5. MN receives BA (from step 3) and process successfully according to
>> current RFC3775.
>> 6. MN sends a BU with seq. # of 1001 to the HA.
>> 7. MN receives a successful BA with seq. # 1001.
>> 8. After some time, MN sends another BU with seq. # = 1002, for
> example.
>> 9. Man in the middle replay BA captured in step 4.
> MK>> if MN sends 8 and receive 10 before the BA (seq=1002) is received
> it will process it.
> 
> (I have modified the text in steps 6,7 and 8 with
> the right sequence numbers)
> 
> nope. if the binding update list on the MN says
> it has received a binding ack with status 1001
> with "success" status (in step 7), it would drop
> the binding ack in step 10. only when the sequence
> number in the binding update list is less than the
> sequence number in the BA with status 135, does
> the MN start using a sequence number greater than
> the one returned in the BA with status 135.
> 
> Vijay
> 
>>
>> Thanks,
>> Ahmad
>>
>>