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

From: "Kent Leung \(kleung\)" <[email-masked]>
Date: Mon, 26 Jun 2006 11:17:43 -0700

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: Tue, 27 Jun 2006 13:29:42 +0800

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