Mobile IPv6 Location Privacy Solutions
RFC 5726
Yes
(Jari Arkko)
No Objection
(Adrian Farrel)
(Cullen Jennings)
(Lisa Dusseault)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 16 and is now closed.
Jari Arkko Former IESG member
Yes
Yes
()
Adrian Farrel Former IESG member
No Objection
No Objection
()
Cullen Jennings Former IESG member
No Objection
No Objection
()
Lisa Dusseault Former IESG member
(was No Record, Discuss)
No Objection
No Objection
()
Pasi Eronen Former IESG member
No Objection
No Objection
(2009-06-17)
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).
Ralph Droms Former IESG member
No Objection
No Objection
()
Robert Sparks Former IESG member
No Objection
No Objection
()
Ron Bonica Former IESG member
No Objection
No Objection
()
Ross Callon Former IESG member
No Objection
No Objection
()
Russ Housley Former IESG member
No Objection
No Objection
()
Tim Polk Former IESG member
(was Discuss, No Record, No Objection)
No Objection
No Objection
(2009-07-02)
(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"?