Subject: Re: [Mobopts] Reviews on draft-irtf-mobopts-ro-enhancements-01

From: Christian Vogt <[email-masked]>
Date: Thu, 06 Oct 2005 16:51:01 +0200

Hi Fan.

>>> 3. Security analysis does not distinguish between eavesdropper
>>> and man_in_middle. There are situations where malicious node can
>>> only eavesdrop rather than intercept the message, for example, in
>>> the Internet exchange point, ISP router may not select a
>>> malicious router as the next hop because of its policy but the
>>> malicious router can still eavesdrop the data traffic. MIP6
>>> network is a little bit less secure than normal IPv6 network
>>> because an eavesdropper can turn itself into a man in the middle.
>>>  This also brings out another topic: how to detect the attack
>>> reliably and without interfering other optimization approaches.
>>
>> There is certainly a difference between an eavesdropper and a
>> man-in-the-middle.  Yet, I'm not quite sure that I fully understand
>> the rest of what you are saying, in particular because your
>> attacker sits in the MN's network.  Are you aware of the
>> IPsec-protected tunnel between the MN and its HA through which the
>> Home Keygen Token will be brought to the MN?
>
> NO, actually I do not assume that the attacker resides in the MN's
> network, instead the attacker could access either HA-CN path or MN-CN
> path.

Ah, I see.  The security analysis was actually already describing the
new thread of man-in-the-middle attacks by off-path impersonators.  But
I added some text to make it clearer that this threat is new when we
introduce mobility.  Thanks!

- Christian

--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

Fan Zhao wrote:
> Dear Christian,
>
> Thanks for your reply.
>
> On Mon, 1 Aug 2005, Christian Vogt wrote:
>
>
>> Hi Fan,
>>
>> thanks for your comments on
>> draft-irtf-mobopts-ro-enhancements-01.txt. There are some more
>> outstanding modification that we have yet to do, so your comments
>> will be considered for the 02 version.
>>
>
> No problem. 01 version has addressed many issues I had with 00
> version and has been improved significantly since then. Thanks for
> writing this draft, it has helped me a lot in understanding this
> probelm.
>
>
>> Below are some responses to your comments from my side.
>>
>>> 1. The paragraph at the end of page 19, �It should be mentioned
>>> that �� is very similar with the next paragraph. Remove one?
>>
>> Ooops, thanks for catching this.  Yes, one paragraph should be
>> enough. ;-)
>>
>>> 2. Is it better to list section 7.6 �Future Research� as a
>>> separate section, e.g. section 8?
>>
>> Actually, it could, yes.  One of the objectives why this draft was
>> written was to provide directions for future research.  So the
>> topic should be important enough to make it a dedicated section
>> (unless people in the group feel otherwise).
>>
>>> 3. Security analysis does not distinguish between eavesdropper
>>> and man_in_middle. There are situations where malicious node can
>>> only eavesdrop rather than intercept the message, for example, in
>>> the Internet exchange point, ISP router may not select a
>>> malicious router as the next hop because of its policy but the
>>> malicious router can still eavesdrop the data traffic. MIP6
>>> network is a little bit less secure than normal IPv6 network
>>> because an eavesdropper can turn itself into a man in the middle.
>>>  This also brings out another topic: how to detect the attack
>>> reliably and without interfering other optimization approaches.
>>
>> There is certainly a difference between an eavesdropper and a
>> man-in-the-middle.  Yet, I'm not quite sure that I fully understand
>> the rest of what you are saying, in particular because your
>> attacker sits in the MN's network.  Are you aware of the
>> IPsec-protected tunnel between the MN and its HA through which the
>> Home Keygen Token will be brought to the MN?
>
> NO, actually I do not assume that the attacker resides in the MN's
> network, instead the attacker could access either HA-CN path or MN-CN
>  path.
>
>
>>> 4. Hash chain could be an alternative to home address test (or in
>>>  other words, authentication of identity). It should be listed in
>>>  section 6, Enhancements Toolbox.
>>
>> See below.
>>
>>> 5. draft-zhao-mobopts-rr-ext-00 discusses about the security and
>>> performance improvement. It should be added to the reference
>>> section.
>>
>> Your draft was somewhere in my stack anyway.  It's on top of it,
>> now. ;-)
>>
>> Your draft also talks about hash chains, which is good.  Jari and I
>> also did something in that direction in
>> draft-arkko-mipv6-binding-lifetime-extension-00.txt.
>
> Yes, I have read this too. That is an interesting idea that is
> worthwhile being explored more.
>
> BTW, I could not attend this IETF due to the time conflict. I really
> appreciate your comments on my draft in the mailing list. Thanks.
>
> Sincerely, fan
>
>
>> Regards, - Christian
>>
>> -- Christian Vogt, Institute of Telematics, University of Karlsruhe
>>  www.tm.uka.de/~chvogt/pubkey/

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

---

From: Fan Zhao <[email-masked]>
Date: Sat, 8 Oct 2005 14:29:43 -0700 (PDT)

Hello Christian,

Looks good to me. Thanks for updating.

Sincerely,
fan