Re: [Mobopts] FW: Request to review Location Privacy document
"QIU Ying" <qiuying@i2r.a-star.edu.sg> Tue, 06 November 2007 11:37 UTC
Return-path: <mobopts-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpMk0-00077p-Rm; Tue, 06 Nov 2007 06:37:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpMjz-00075e-Gx for mobopts@irtf.org; Tue, 06 Nov 2007 06:37:07 -0500
Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpMjp-0008Om-La for mobopts@irtf.org; Tue, 06 Nov 2007 06:37:07 -0500
Received: from rodin.i2r.a-star.edu.sg (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 9CA9613B6D2; Tue, 6 Nov 2007 19:35:40 +0800 (SGT)
Received: from mailfe01.teak.local.net (unknown [192.122.134.9]) by rodin.i2r.a-star.edu.sg (Postfix) with ESMTP id 8481113B6D1; Tue, 6 Nov 2007 19:35:40 +0800 (SGT)
Received: from precision5570 ([192.168.137.163]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 19:36:02 +0800
Message-ID: <060901c82069$0c71d220$a389a8c0@precision5570>
From: QIU Ying <qiuying@i2r.a-star.edu.sg>
To: Rajeev Koodli <rajeev.koodli@nokia.com>, mobopts@irtf.org
References: <C350E61B.1D09F%rajeev.koodli@nokia.com>
Subject: Re: [Mobopts] FW: Request to review Location Privacy document
Date: Tue, 06 Nov 2007 19:34:53 +0800
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-OriginalArrivalTime: 06 Nov 2007 11:36:02.0656 (UTC) FILETIME=[35D05600:01C82069]
X-Spam-Score: -97.3 (---------------------------------------------------)
X-Scan-Signature: 835ad9b9deb0975ba747bfa9d7f1aef1
Cc: heejin.jang@samsung.com
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0853594155=="
Errors-To: mobopts-bounces@irtf.org
FW: Request to review Location Privacy documentHi, Heejin Thanks for your careful review. Below are the responses for the major comments: 1. Section 4: C>> I think the difference between proposals in section 4 & 5 should be clarified here or in section 3. The proposal in section 4 can not avoid revealing of the home address to CN during RR. On the other hand, in section 5, the home address is not be shown during RR & may not be shown even to the CN. In addition, in section 4 proposal, the pseudo home address does not need to be routable because it is not used during RR. R: We will add a paragraph at the end of section 3 to describe the differences. 2. Section 4.1 C>> "In the original Return Routability -> In the original MIPv6 procedure" R: You are right, in most cases, the term "original MIPv6 procedure" is more accurate in our draft. 3. Section 5.1.1 C>> Does "Routable" covers also "globally uniqueness"? Hope that there is a clear statement for pHoA's uniqueness here. For example, "The generated pHoA should be guaranteed to be globally unique." R: A "Routable" address implies that it must be globally unique, right? So I thought it may be redundant to emphasize "globally uniqueness". 4. Section 5.3.1 C>> In the section 5 proposal, the 'P' flag in HoTI is set to 1 or not? R: No, not need to set P flag here. The message format is same as original HoTI. C>> I'm asking the use of pHoA is trasnparent or not to the CN. R: In fact, the pHoA is not transparent to CN. CN must know the pHoA inheritance otherwise a communication would be broken. C>> For the processing of identity_address in the CN, at least the CN knows that it's using the pHoA even though it can not know the real home address. How? R: After receiving BU message, the CN could confirm the relationship between CoA and pHoA. Then CN decrypts Enc(Kbm, identity_address) and gets identity_address, what is the session identity to keep the communications. C>> Which fields contains 'Enc(Kbm, identity_address)'? New option for this? R: it could be attached in field of "Mobility options" of "Binding Update Message". 5. Section 5.3.2 C>> This is also related to the earlier comment. How does the CN can know that it should process the BU based on identity_address? From the 'P' flag in the previous RR? Otherwise from the existence of the new option for identity_address? There is no mention for this. R: Because the processes of BU in our 2 proposals are different, we need a new flag to indicate, say "Q" flag. According to the BU format described in section 6.1.7, RFC 3775, original MIP6 only uses 4 bits |A|H|L|K| out of 16 bits +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|P|Q| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6. Section 5.3.2 C>> In original MIPv6, the source address of the BU (CoA) is replaced with the HoA in the destination option of BU for the transparency to the upper layer. In this proposal, the source address should be replaced not with the dest option but with the identity_address for the transparency to the upper layer. This should be mentioned clearly and looks major change of MIPv6. R: After the processing of BU, the CoA associates with HoA in BU cache in original MIP6. In our proposal, the CoA is associated with the identity_address in BU cache. The identity_address could be the HoA, or the first pHoA when set up a communication session. So the proposal is not change the processing of forwarding a packet to upperlayer . 7. Section 6.2.3 C>> This is not true. Usually the previous network (before handover) and new network (after handover) is adjecent or nearly located. Therefore the previous MN-HA/MN-CN paths are mostly overapped with the new MN-HA/MN-CN paths. R: It depends where the eavesdroppers are in the paths. If an eavesdroppers is at the end of HA/CN, your observation is correct that the eavesdropper can still capture messages on the MN-HA/MN-CN paths. However, if the eavesdropper is at the end of MN, it may not be able to get signal between MN and its access points. Anyway, it is better to delete this assumption in next version. 8. C>> Pseudo Home Address option should be illustrated in this section or in the new section for Message format. R: OK. The new version will provide the illustrated format. Regards and Thanks Qiu Ying ----- Original Message ----- From: Rajeev Koodli To: mobopts@irtf.org Cc: heejin.jang@samsung.com Sent: Saturday, November 03, 2007 5:35 AM Subject: [Mobopts] FW: Request to review Location Privacy document Hi, Review from Heejin Jang. Thanks Heejin. -Rajeev -- http://people.nokia.net/~rajeev ------ Forwarded Message From: ext Heejin Jang <heejin.jang@samsung.com> Reply-To: <heejin.jang@samsung.com> Date: Fri, 2 Nov 2007 00:45:46 -0500 To: "Koodli Rajeev (NSN - US/Palo Alto)" <rajeev.koodli@nokia.com> Conversation: Request to review Location Privacy document Subject: Re: Request to review Location Privacy document Hi, Rajeev. I reviewed the document and review results are in the attached file. The proposed idea looks valuable, but there is ambiguity in some description which needs to be clarified more. ps> Because I'm not so strong in the security, some comments may not be significant. - BR Heejin. ------ End of Forwarded Message ------------------------------------------------------------------------------ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts ------------ Institute For Infocomm Research - Disclaimer -------------This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you.--------------------------------------------------------
_______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts