Skip to main content

Last Call Review of draft-ietf-v6ops-ipv6-roaming-analysis-05

Request Review of draft-ietf-v6ops-ipv6-roaming-analysis
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-09-29
Requested 2014-09-18
Authors Gang Chen , DENG Hui , Dave Michaud , Jouni Korhonen , Mohamed Boucadair
I-D last updated 2014-10-02
Completed reviews Genart Last Call review of -05 by Peter E. Yee (diff)
Genart Telechat review of -05 by Peter E. Yee (diff)
Secdir Last Call review of -05 by Joseph A. Salowey (diff)
Opsdir Last Call review of -05 by Tim Chown (diff)
Assignment Reviewer Joseph A. Salowey
State Completed
Request Last Call review on draft-ietf-v6ops-ipv6-roaming-analysis by Security Area Directorate Assigned
Reviewed revision 05 (document currently at 07)
Result Ready
Completed 2014-10-02
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

In summary I believe the document is ready.  It does make reference to security
considerations IPV6-3GPP RFC 6459 which is appropriate. I have a few
observations below.

1) There is a brief discussion of home routed an local breakout modes which
determine how the user's traffic is routed.  This could potentially have
privacy implications, however I do not think this is the subject of the
document so I don't think additional privacy considerations are needed.  The
one exception may be if an attacker can force the selection of one of these
options.  This did not appear to be the case from the document, but I did not
follow all the 3GPP specifics.

2) Some of the failure modes  consume more network resources.  If these modes
can be externally manipulated then it may be possible for a denial of service
attack.  This did not appear to be the case from the document, but I did not
follow all the 3GPP specifics.