Skip to main content

Last Call Review of draft-ietf-dmm-mag-multihoming-03

Request Review of draft-ietf-dmm-mag-multihoming
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2017-06-16
Requested 2017-06-02
Authors Pierrick Seite , Alper E. Yegin , Sri Gundavelli
I-D last updated 2017-06-24
Completed reviews Intdir Early review of -02 by Sheng Jiang (diff)
Genart Last Call review of -03 by Robert Sparks (diff)
Secdir Last Call review of -03 by Hilarie Orman (diff)
Genart Telechat review of -04 by Robert Sparks (diff)
Assignment Reviewer Hilarie Orman
State Completed Snapshot
Review review-ietf-dmm-mag-multihoming-03-secdir-lc-orman-2017-06-24
Reviewed revision 03 (document currently at 07)
Result Has issues
Completed 2017-06-24
Security review of
MAG Multipath Binding Option

Do not be alarmed.  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

If you've been frustrated by being limited to only one IP tunnel
between a mobile access gateway and a local mobility anchor, then
you'll be glad to know that this draft fixes the problem and enables
multiple care-of addresses and IP tunnels.  Now mobile devices can be
assigned to any applicable tunnel between the MAG and the LMA.

For security considerations, the authors predictably defer to RFC5213,
"Proxy Mobile IPv6", and assert "no impact on the protocol security".
However, there is one security issue that is mentioned in RFC5213 that
is exacerbated by the current draft.  I.e.,

   To address the threat related to a compromised mobile access gateway,
   the local mobility anchor, before accepting a Proxy Binding Update
   message for a given mobile node, may ensure that the mobile node is
   attached to the mobile access gateway that sent the Proxy Binding
   Update message.

The RFC has no recommendation for a solution, but because there are
now multiple tunnels, this assurance may be more difficult to obtain.
For example, if the LMA expects to contact some kind of trusted entity
that is keeping track of the mobile devices that the MAG is sending on
a tunnel, then the MAG and LMA may now have to keep track of multiple
trusted entities, one for each tunnel.  Whether or not this is a
realistic scenario is not something that I can judge because RFC5213
punts on what seems to be an important security issue.

Is there any reason to worry about reuse of CoAs?  Could packets from
one tunnel get a CoA that was recently used by another tunnel, and
could delayed packets get routed through the wrong tunnel?  Just asking.

Nits.  On page 3 there is a paragraph beginning "In the continuation
of c, a Proxy Mobile IPv6 ..."  There is no explanation of "c".  Is
this a remnant of a list of items "a, b, c"?

On page 4 there is Figure 1 showing four flows and two tunnels.  The
text immediately preceding that says that "Flow-1,2 and 3 are
distributed either on Tunnel-1 (over LTE) or Tunnel-2 (over WLAN)",
but the diagram shows Flow-1 on Tunnel-1 and Flow-2,3 on Tunnel-2.
I think the text should indicate that the first three flows are
each assigned to a single tunnel.  The authors probably meant that
either Tunnel-1 or Tunnel-2 could have been assigned, but the choice
was to put Flow-1 on Tunnel-1 and the other flows on Tunnel-2.
I had to read over the text several times before I was sure of the