Mobile IPv6 Location Privacy Solutions
draft-irtf-mobopts-location-privacy-solutions-16

[Ballot comment]
(Moving to NoObj)

Section 5.1

If I understand correctly, the encrypted home address is generated by the mobile node
and accepted without re-computation by the home agent.  If this is correct, there is no way
to enforce use of a particular encryption algorithm (or even verify it was used...)  In this case,
the text describing AES as the "default" algorithm should be replaced with text recommending
the use of AES, and 8.1 in security considerations should get some text explaining why it
would be bad for the mobile node to select a weak algorithm.

If I am wrong, and the home agent (or any other participant) also computes the encrypted
home address we have a different problem.  To have crypto agility we need a mechanism
to communicate which symmetric algorithm is in use, and I didn't see any evidence of that
in the new messages/payloads.

Also in section 5.1, in the third message: should destination be "home agent" instead of
"home address"?

[Ballot discuss]
This is probably a trivial discuss, but I would like to see one issue resolved before publication.

Section 5.1

If I understand correctly, the encrypted home address is generated by the mobile node
and accepted without re-computation by the home agent.  If this is correct, there is no way
to enforce use of a particular encryption algorithm (or even verify it was used...)  In this case,
the text describing AES as the "default" algorithm should be replaced with text recommending
the use of AES, and 8.1 in security considerations should get some text explaining why it
would be bad for the mobile node to select a weak algorithm.

If I am wrong, and the home agent (or any other participant) also computes the encrypted
home address we have a different problem.  To have crypto agility we need a mechanism
to communicate which symmetric algorithm is in use, and I didn't see any evidence of that
in the new messages/payloads.

[Ballot comment]
Couple of technical comments that are not relevant for the
RFC 3932 check, but may be useful for the RFC Editor and/or
the authors:

- It looks like pseudo home addresses won't work as-is when IPsec is
used to protect Mobile IPv6 signalling (it looks like they assume
Mobile IPv6 part modifies the IPsec Security Policy Database
on-the-fly in some unspecified fashion).

- Pseudo home addresses also seems to introduce a rather big change to
Mobile IP: the home agent has to intercept and modify some
reverse-tunneled payload packets between the MN and CN (at least
HoTI). Currently, these are just normal payload traffic (since the
Home Agent is not listed in the "Destination Address" field, it just
forwards them without doing any processing). This seems like an ugly
layer violation: if the MN has a Mobile IPv6 signalling packet it
wants the HA to process somehow, it should put the HA in the
"Destination Address" field instead of relying the HA to perform
deep packet inspection and "intercept" them.

- Despite the claim in Section 11, most of this stuff probably doesn't
work DSMIPv6 because DSMIPv6 cannot use tunnel mode IPsec to protect
binding updates to home agents (when using IPv4 CoA at least).

[Ballot discuss]
I'd like to understand more about this recommendation.  Did the RG already consider experimental codepoints? Is the RG they receptive to changing them?  Are these codepoints really rare?

This DISCUSS is just to talk about the specific recommendation the IESG will make to the RFC Editor.

There are reserved field bits and several IANA allocations for IETF-controlled spaces in this draft. Need to make a decision whether the allocations are reasonable for this RFC.

This is a request for the IESG to perform a RFC3932bis review of
draft-irtf-mobopts-location-privacy-solutions-13.txt [1] to be published
an an Informational IRTF RFC. The document has been approved for
publication by the IRSG. See below for details on prior reviews.
Please copy all correspondence to the document shepherd, Basavaraj Patil
.

--aaron

[1]
http://trac.tools.ietf.org/html/draft-irtf-mobopts-location-privacy-solutions-13.txt

---
Aaron Falk
Chair
Internet Research Task Force
http://www.irtf.org

-------- Original Message --------
Subject: Request to publish IRTF I-D
draft-irtf-mobopts-location-privacy-solutions-13.txt
Date: Wed, 27 May 2009 19:27:54 +0200
From:
To: ,
CC:



Hello Aaron,

This is a request to publish the Mobopts RG document
draft-irtf-mobopts-location-privacy-solutions-13 as an Experimental
RFC.

The draft has undergone several revisions based on earlier
reviews. The latest version of the draft (rev 13) includes the changes
and edits that were suggested as part of the the IRSG Review/Poll
process. The IRSG Review/Poll was done on Rev 12 of the I-D.

There were 3 votes for "Ready to publish" and none opposing the
publication.

During the development of this document in the mobopts RG, several
people have reviewed it and the changes have been incoroporated.
The issue tracker entry includes the versions of the draft since the
IRSG review started:
http://trac.tools.ietf.org/group/irtf/draft-irtf-mobopts-location-privacy-solutions/

-Basavaraj