Subject: RE: [Mip4] Re: Fwd: I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Tue, 27 Jun 2006 08:37:25 -0700

Pls read RFC 3344 section 5.7.1:

   Note, however, that when using timestamps, the 64-bit Identification
   used in a Registration Request from the mobile node MUST be greater
   than that used in any previous Registration Request, as the home
   agent uses this field also as a sequence number.

So the replayed RRQ with older ID value than the current binding will
not be accepted by the HA.

Kent 

> -----Original Message-----
> From: Owen.Lai [mailto:[email-masked]] 
> Sent: Monday, June 26, 2006 10:30 PM
> To: Kent Leung (kleung)
> Cc: zhen cao; [email-masked]
> Subject: Re: [Mip4] Re: Fwd: 
> I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt
> 
> Hi, Kent,
> 
> I agree that code 133 can be used to inform the sender of the 
> RRQ the correct timestamp, and future timestamp is based on 
> this correct value.
> 
> HA rejects a RRQ with code 133 when it find out that the 
> timestamp in ID field of RRQ is invalid.
> 
> However, the Intercepted RRQ probably has the CORRECT 
> timestamp which is in the range of time difference between 
> sender and HA, 3~7s in default as in RFC 3344. And then HA 
> may accept the intercepted RRQ.
> 
> All the best,
> 
> Owen
> 
> 
> 2006/6/27, Kent Leung (kleung) <[email-masked]>:
> > Hi Owen.  The flaw in your logic is that the timestamp is based on 
> > HA's value.  The HA uses error code 133 to inform the sender of the 
> > RRQ the correct timestamp.
> >
> > Kent
> >
> > > -----Original Message-----
> > > From: Owen.Lai [mailto:[email-masked]]
> > > Sent: Monday, June 26, 2006 6:32 AM
> > > To: Kent Leung (kleung)
> > > Cc: zhen cao; [email-masked]
> > > Subject: Re: [Mip4] Re: Fwd:
> > > I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt
> > >
> > > Hello, Kent,
> > >
> > > Sorry for my previous mistake,
> > >
> > > "Interception problem" is a kind of Man-in-Middle attack.
> > >
> > > Supposing the following scenario, MS first connected with 
> AR1, then 
> > > move to AR2's link.
> > > If an malicious node intercepted RRQ from AR1 and wait until
> > > AR2 send RRQ to HA, then malicious node sent intercepted 
> RRQ to HA , 
> > > it could cause HA fall back to AR1 registration.
> > >
> > > And I think Identification field in RRQ cannot prevent 
> the attack, 
> > > because Timestamps in the ID fields may be from two different ARs 
> > > and it is invalid to make comparison between two Timestamps from 
> > > different nodes.
> > >
> > > Regards,
> > >
> > > Owen
> > > <snip>
> > >
> >
> 

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Owen.Lai <[email-masked]>
Date: Wed, 28 Jun 2006 10:56:10 +0800

Hi, Kent,

Sorry, I didn't explain issue clearly, let me try to redo it again.

In proxy MIP4,
1) MS first connected with MPA1,
2) MPA1 send RRQ to HA
3) An malicious node intercepts RRQ from MPA1 to HA, so this RRQ will
not arrive at HA
4) MS move from MPA1 to the MPA2 in a very short time
5) MPA2 send RRQ to HA to update BCE.
6) An malicious node send MPA1 RRQ to HA, to invalidate MPA2 RRQ.

Although timestamp is based on HA's value, MPA can only guarantee that
its RRQ timestamp is close to HA's time of day. It's not necessay that
MPA1 RRQ has a less Identification then that in MPA2 RRQ.

So MPA1 RRQ MAY have a greater Identification then that in MPA2 RRQ,
and hence HA will accetp MPA1 RRQ, causeing Man-in-Middle attack.

Best Regards,

Owen