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