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 04:26:21 -0700

Hi Owen.  As mentioned by Zhen, replay protection is provided by the ID field.  The draft brings up replay attack as a problem for sequence number.  So, not clear what you mean by interception problem?  Can you explain more?

Kent 

> -----Original Message-----
> From: Owen.Lai [mailto:[email-masked]] 
> Sent: Monday, June 26, 2006 1:24 AM
> To: zhen cao
> Cc: [email-masked]
> Subject: Re: [Mip4] Re: Fwd: 
> I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt
> 
> Hi, Zhen,
> 
> Thanks for your question!
> 
> We made mistake before, this is interception problem other 
> than anti-replay problem.
> 
> All the best
> 
> Shouwen
> 
> 
> 
> 在 06-6-26，zhen cao<[email-masked]> 写道：
> >
> > Hi, Shouwen
> >
> >      I have one question about your draft:
> >
> >      Isn't timestamp in identification of rrq will be used 
> for anti-reply?
> >
> > Many thanks,
> > Zhen
> >
> >
> > ------------Original
> > Message--------------------------------
> > Hi folks,
> >
> > We've published a new draft, "Problem of Replay Protection Using
> Sequence
> > Number in Proxy Mobile IPv4".
> >
> > The document presents the problems of replay protection 
> using sequence
> number in proxy Mobile IPv4 solution. The sequence number
> > cannot
> prevent registration message from replay attack.
> >
> > Any comments are welcome.
> >
> > Thanks,
> Shouwen,
> >
> >
> > ---------- Forwarded message ---------- From: Internet-Drafts at 
> > ietf.org <Internet-Drafts at ietf.org> Date: 2006-6-23 
> 上午6:50 Subject: 
> > I-D ACTION:draft-lai-mip4-proxy-sequence-problem-00.txt
> > To: i-d-announce at ietf.org
> >
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories.
> >
> >
> >  Title : Problem of Replay Protection Using Sequence
> Number in Proxy Mobile
> > IPv4
>  Author(s) : S. Lai, H. Deng
>  Filename :
> > draft-lai-mip4-proxy-sequence-problem-00.txt
>  Pages : 7
> > Date : 2006-6-22
> >
> >  The document presents the problems of replay protection using
>  sequence
> > number in proxy Mobile IPv4 solution. The sequence number
>  cannot prevent
> > registration message from replay attack.
> >
> >
> > A URL for this Internet-Draft
> > is:
> http://www.ietf.org/internet-drafts/draft-lai-mip4-proxy-seque
> nce-problem-00.txt
> >
> > To remove yourself from the I-D Announcement list, send a message to
> i-d-announce-request at ietf.org with the word unsubscribe in the body
> > of
> the message.
> You can also visit
> > https://www1.ietf.org/mailman/listinfo/I-D-announce
> > to change your subscription settings.
> >
> >
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the 
> > username
> "anonymous" and a password of your e-mail address. After logging
> > in,
> type "cd internet-drafts" and then
>  "get
> > draft-lai-mip4-proxy-sequence-problem-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
>  mailserv at ietf.org.
> In the body type:
>  "FILE
> > /internet-drafts/draft-lai-mip4-proxy-sequence-problem-00.txt".
> >
> > NOTE: The mail server at ietf.org can return the document in
>  MIME-encoded
> > form by using the "mpack" utility. To use this
>  feature, insert the command
> > "ENCODING mime" before the "FILE"
>  command. To decode the response(s), you
> > will need "munpack" or
>  a MIME-compliant mail reader. Different
> > MIME-compliant mail readers
>  exhibit different behavior, especially when
> > dealing with
>  "multipart" MIME messages (i.e. documents which have been
> > split
>  up into multiple messages), so check your local documentation on  how
> > to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of
> > the
> Internet-Draft.
> >
> >
> >
> >
> >
> > _______________________________________________
> I-D-Announce
> > mailing list
> I-D-Announce at ietf.org
> > https://www1.ietf.org/mailman/listinfo/i-d-announce
> >
> >
> > --
> > 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/
> >
> >
> >
> 

-- 
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: Mon, 26 Jun 2006 21:32:18 +0800

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