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

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 18 May 2006 09:26:44 -0500

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.
Thanks.

Regards,
Ahmad

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 18 May 2006 14:14:00 -0700

> Could you please comment on this and let me know if I am on the right 

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.

the text in section 11.7.3 needs to be fixed when
RFC 3775 is revised.

thanks for catching this.

Vijay

---

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

Thanks Vijay for the comments.
Please see comments inline.

Regards,
Ahmad

> not ignore the sequence number field in the

[Ahmad]
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

---

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

> 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.

> where there is manual IPsec, any man in the middle can replay an old BA

note this wont happen if dynamic keying is used.

> 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.

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.

> 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.

(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

---

From: Francis Dupont <[email-masked]>
Date: Sat, 20 May 2006 15:09:08 +0200

In your previous mail you wrote:

   2. The more serious problem is a security issue. In the case of the HA
   where there is manual IPsec,

=> with manual IPsec you are open to many replay attacks, so you simply
should never use manual IPsec...

Regards
   
[email-masked]

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 22 May 2006 08:41:50 -0500

Hi Vijay,
Comments inline.

Regards,
Ahmad

> > 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.
> 

[Ahmad]
May be we are saying the same thing in different ways. IMO, when a
mobile Node does not accept a BA, it silently discards the message. If
the MN processes the BA and acts based on the information received in
that BA, it means MN accepted the BA. I am not trying here to argue the
issue but just for clarification.
> > where there is manual IPsec, any man in the middle can 
> replay an old 
> > BA
> 

[Ahmad]
But manual IPsec is supported as per RFC3775 and we need to have a
protocol that works for all possibilities.
> trap this particular binding ack and replay it.

[Ahmad]
Agreed.
> would be able to spot the binding ack with status

{Ahmad]
That's why we need a fundamental solution.

Again, IMO, what is proposed in RFC3775 is a clear violation of the
replay protection mechanism that the RFC itself proposing. I do not
think that is a good idea. We have to maintain the replay protection in
all scenarios including error scenarios and this case is no different
than any other.

> 
> > 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

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 22 May 2006 09:16:54 -0500

The proposed idea will make the manual IPSec more secure. I don't know
what is the problem to fix this issue in the current standard???? We
can't tell people not to use manual IPSec if it is part from the
security configuration of MIP6

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Saturday, May 20, 2006 8:09 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
Cc: Vijay Devarapalli; Gopal Dommety; Charles E. Perkins;
[email-masked]; [email-masked]; Basavaraj Patil;
[email-masked]; Khalil, Mohamed [RICH2:2S20:EXCH]
Subject: Re: [Mip6] MIPv6: Using the last Accepted Sequence Number in BA

   2. The more serious problem is a security issue. In the case of the
HA
   where there is manual IPsec,

Regards

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 22 May 2006 10:11:15 -0700

> That's why we need a fundamental solution.

see below. I think you missed part of my email.
there is no problem even with the authentication
option protocol.

Vijay

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 22 May 2006 12:37:56 -0500

The major issue is with IPSec manual confg which is considered as basic
security configuration mode for MIP6. As mentioned before that this
issue is easily can be solved.

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Monday, May 22, 2006 12:11 PM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
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

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 22 May 2006 15:40:40 -0700

> issue is easily can be solved.

there is no problem with the use of manual IPsec too.

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. otherwise it sticks
to the current sequence number it is using since it is
greater than what is suggested in the binding ack.

Vijay

---

From: Francis Dupont <[email-masked]>
Date: Mon, 22 May 2006 22:05:15 +0200

The proposed idea will make the manual IPSec more secure.

=> no, it is already instrincically insecure and it will remain
insecure (ie, it is not enough to fix one of the many ways to
play with the lack of anti-replay).

   I don't know
   what is the problem to fix this issue in the current standard????

=> add a SHOULD NOT against manual keying.

   We can't tell people not to use manual IPSec

=> not only we can but we should!

   Regards

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 22 May 2006 15:21:39 -0500

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. 
MK>> replay attack can happen at anytime. the condition you mentioned
could happen in a reply attack too.

otherwise it sticks

Vijay

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 22 May 2006 15:33:39 -0500

I believe it will be more practical to remove this option from the
spec, since the replay protection for this option is not useful. this
will remove the overhead of implementing, testing etc this option and it
will save implementers money, time and effort.