Subject: Re: [Mobopts] IRSG Poll for I-D:draft-irtf-mobopts-location-privacy-solutions

From: <[email-masked]>
Date: Wed, 11 Mar 2009 04:40:32 +0100

Hello,

The deadline for the IRSG poll for I-D: draft-irtf-mobopts-location-privacy-solutions expired on Feb 26th.

So far we have received one no objection vote. Would like to hear from a few other people.
I am extending the deadline to March 15th. Please respond to the poll.

Again the choices are:

    o  'Ready to publish' -- requires a thorough read and reasonably
        detailed review

    o  'Not ready to publish' -- requires a thorough read,
       reasonably detailed review, and actionable comments.

    o  'No objection' -- I don't object if this document
      goes forward;
       I've read the document (perhaps quickly); I have some small
       comments which are not show stoppers; I don't have great
       expertise in the area.

    o  'Request more time to review' -- a commitment to provide a
       thorough review in a specified period of time.

Rgds,
-Basavaraj

> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of
> > [email-masked]
> > Sent: Wednesday, February 11, 2009 3:25 PM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: [Mobopts] IRSG Poll for
> > I-D:draft-irtf-mobopts-location-privacy-solutions
> >
> >
> > Hello,
> >
> > The Mobopts RG I-D:
> > draft-irtf-mobopts-location-privacy-solutions has completed IRSG
> > review.
> > The revised version of the I-D (Rev 12) which incorporates the
> > comments is now available at:
> > http://www.ietf.org/internet-drafts/draft-irtf-mobopts-locatio
> > n-privacy-solu
> > tions-12.txt.
> >
> > Michael Welzl who has performed the IRSG review and the Mobopts RG
> > have approved the revised I-D to be progressed for publication.
> >
> > The IRSG review is available from the IRTF tracker web page at:
> > http://trac.tools.ietf.org/group/irtf/trac/ticket/24
> >
> > Please consider this email as the start of a two week IRSG
> poll. The
> > deadline for this poll is : Feb 26th, 2009.
> >
> > Please use one of the poll responses defined below.
> > The possible poll responses are:
> >
> >     o  'Ready to publish' -- requires a thorough read and reasonably
> >         detailed review
> >
> >     o  'Not ready to publish' -- requires a thorough read,
> reasonably
> >        detailed review, and actionable comments.
> >
> >     o  'No objection' -- I don't object if this document
> goes forward;
> >        I've read the document (perhaps quickly); I have some small
> >        comments which are not show stoppers; I don't have great
> >        expertise in the area.
> >
> >     o  'Request more time to review' -- a commitment to provide a
> >        thorough review in a specified period of time.
> >
> > The most relevant rule is that "At least two other IRSG members
> > (besides the one sponsoring the document) need to vote 'ready to
> > publish' for the document to move forward."
> >
> > Please review and submit your vote.
> >
> > -Basavaraj
> > Document Shepherd for the I-D
> >
> > _______________________________________________
> > Mobopts mailing list
> > [email-masked]
> > http://www.irtf.org/mailman/listinfo/mobopts
> >

This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.

---

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
Date: Wed, 11 Mar 2009 10:22:37 -0500

You can record a vote for "ready to publish" from me.

The document is well laid out and the relationships between it
and the many pieces of existing work are well described within
the document.

One substance nit is that the requirements listed in section
3 lack any associated "rationale" statements.  Including some
rationale alongside each requirement is general practice in
formal requirements management.

Another nit is that the document generally phrases the
problem as being to hide the mapping between "the home
address and the care-of address".  I believe it should
really be between "the home address and an in-use
care-of address", in order to ease later understanding
of the applicability to monami6, dsmip, or other
extensions that the conclusions say may be in-scope in
the future for clarification.

The problem of location privacy is very complex, and the
document does a good job of tracking each concern and
clearly explaining what appears in each relevant header
and option field in the stack so that the impact can be
readily assessed.  I appreciated this.

There are some editorial nits, but I believe they're minor
enough that the RFC Editor will fix them.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>Sent: Tuesday, March 10, 2009 11:41 PM
>To: [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: Re: [Mobopts] IRSG Poll 
>forI-D:draft-irtf-mobopts-location-privacy-solutions
>
>
>Hello,
>
>The deadline for the IRSG poll for I-D: 
>draft-irtf-mobopts-location-privacy-solutions expired on Feb 26th.
>
>This email and any attachments may contain legally privileged 
>and/or confidential information of Starent Networks, Corp. and 
>is intended only for the individual or entity named in the 
>message.  The information transmitted may not be used to 
>create or change any contractual obligations of Starent 
>Networks, Corp.  Any review, retransmission, dissemination or 
>other use of, or taking of any action in reliance upon this 
>e-mail and its attachments by persons or entities other than 
>the intended recipient is prohibited. If you are not the 
>intended recipient, please notify the sender immediately -- by 
>replying to this message or by sending an email to 
>[email-masked] -- and destroy all copies of 
>this message and any attachments without reading or disclosing 
>their contents. Thank you.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Mar 2009 16:12:03 +0000

> You can record a vote for "ready to publish" from me.

Same here.

My non-blocking comments are below. Feel free to take 'em
on board or not, as you see fit.

Stephen.

#1 Its a bit surprising that active attackers aren't considered.
Maybe adding a justification for that would be good? I guess the
danger is that someone goes and implements all of this and claims
to have produced a "secure" solution, but in fact has only produced
something good against passive attacks.

#2 section 5.1, what mode of operation is used for the generation
of the encrypted home address? For AES I think ECB is ok, but if
a block cipher with a smaller block (e.g.  3DES) is used, then you
should probably not use ECB as that'd expose some information if
Kpm is re-used and if the home address structure is sensitive.
I've no idea if that's significant or not, but specifying CBC mode
for shorter-block ciphers would I think remove the potential
vulnerability. (3DES with ECB mode might also allow some non-obvious
cut'n'paste attacks if Kpm is re-used, though those'd be active
attacks and so presumably out of scope.)

Nits:

#1 1st sentence of section 1 is missing a word, maybe "problem"

#2, p12: s/If such/If so/

---

From: "QIU Ying" <[email-masked]>
Date: Mon, 16 Mar 2009 18:37:49 +0800

Hi, Stephen

Thanks for your review and support.

For the #1 comment regarding to active attacks: we discussed this issue 
before, but it is too difficult to enumerate all of active attacks. In 
fact, if an attacker launches an active attack signaling,  the mobile 
node has 2 choices: 1) simply drop the signaling message according to 
its own access policy, hence it is not much for further discussion. 2) 
accept the signaling messages, then the MN must response the signaling. 
Hence the attacker is treated as a correspondent node and the 
correspondent node is still not able to map the real home address and 
the in-use care-of-address according to our solution.

For the #2 comment regarding to using ECB in DES: since KM is derived 
from Kbm: Kpm = HMAC_SHA1(Kbm, 0), and Kbm is always changed by every RR 
process, a Kpm can not be re-used during the communication. By the way, 
the example you describe here, I prefer to call it as passive attack 
because it does not tempt messages from MN or HA directly.

Please correct me if I am wrong.

Regards and Thanks
Qiu Ying

----- Original Message ----- 
From: "Stephen Farrell" <[email-masked]>
To: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, March 12, 2009 12:12 AM
Subject: Re: [Mobopts] [IRSG] IRSG 
PollforI-D:draft-irtf-mobopts-location-privacy-solutions

> #2, p12: s/If such/If so/

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."

---

From: "QIU Ying" <[email-masked]>
Date: Mon, 16 Mar 2009 18:50:34 +0800

Hi, Wesley

Thanks for your review and support. My response inline

> formal requirements management.

Do you mean we should brief the home/correspondent binding update and 
the RR procedure? OK, we will add it.

> the future for clarification.

OK. Thanks for your observation.

Regards and Thanks
Qiu Ying

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Tue, 17 Mar 2009 18:22:26 -0400

Hi Wes,

> formal requirements management.

This is just a very basic set of requirements (such as use MIP6
framework, do not alter IPsec etc.) set forth for the solutions. We feel
it is fairly self-explanatory, and prefer to refer the reader to a basic
understanding of MIP6. 
 
> address and the care-of address".  I believe it should really 
> be between "the home address and an in-use care-of address", 
> in order to ease later understanding of the applicability to 
> monami6, dsmip, or other extensions that the conclusions say 
> may be in-scope in the future for clarification.
> 

Multiple CoAs may be in-use (in the future), right? If so, the document
is equally applicable.

> document does a good job of tracking each concern and clearly 
> explaining what appears in each relevant header and option 
> field in the stack so that the impact can be readily 
> assessed.  I appreciated this.

Thanks.

> enough that the RFC Editor will fix them.

Okay.

Regards,

-Rajeev

---

From: "Eddy, Wesley M. (GRC-RCN0)[Verizon]" <[email-masked]>
Date: Tue, 17 Mar 2009 20:38:06 -0500

All of my comments are non-blocking, and I trust the authors/editors
to just take them as suggestions, and nothing more serious.  Your
logic makes sense to me with the explanations below.

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Koodli, Rajeev [[email-masked]]
Sent: Tuesday, March 17, 2009 6:22 PM
To: [email-masked]
Subject: Re: [Mobopts] IRSG PollforI-D:draft-irtf-mobopts-location-privacy-solutions

Hi Wes,

Thanks.

Okay.

Regards,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 17 Mar 2009 22:00:50 -0700

Hi Stephen,

I agree with Qiu Ying's reply.

We can address the nits as part of RFC Editor revisions.

So, I request that the ID be progressed forward.

Thanks for your review.

Regards,

-Rajeev

On Mon, Mar 16, 2009 at 3:37 AM, QIU Ying <[email-masked]> wrote:
> before, but it is too difficult to enumerate all of active attacks. In fact,
> if an attacker launches an active attack signaling,  the mobile node has 2
> choices: 1) simply drop the signaling message according to its own access
> policy, hence it is not much for further discussion. 2) accept the signaling
> messages, then the MN must response the signaling. Hence the attacker is
> treated as a correspondent node and the correspondent node is still not able
> to map the real home address and the in-use care-of-address according to our
> solution.
>
> For the #2 comment regarding to using ECB in DES: since KM is derived from
> Kbm: Kpm = HMAC_SHA1(Kbm, 0), and Kbm is always changed by every RR process,
> a Kpm can not be re-used during the communication. By the way, the example
> you describe here, I prefer to call it as passive attack because it does not
> tempt messages from MN or HA directly.
>
> ----- Original Message ----- From: "Stephen Farrell"
> <[email-masked]>
> 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."