Good morning, On Wed, Aug 16, 2017 at 11:04 PM, Sri Gundavelli (sgundave) <[email protected]> wrote: > Hi Kathleen and Hilarie, > > Thank you for reviewing the documents and the feedback. Please see inline. > > > >> 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. > > > A MAG is required to prove the presence of a mobile node’s presence on its > (ingress) access link. That assertion needs to be validated by the LMA. But, > MAG using a single tunnel or multiple tunnels has no relation to this issue. > The LMA identifies the MAG using the MAG-NAI and not using Care-of Address; > a new option, MAG Identifier option is defined in section 4.2 for this > purpose. >
Could you add some text to the security considerations to explain why there is no concern then related to split tunneling/data leakage to the incorrect tunnel? > > > > >> 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. > > The tunnels between LMA and MAG are dynamically established after protocol > signaling. The idea of CoA re-use between MAG’s and delayed packets getting > delivered to a different MAG is impossible to realize even in lab > conditions. It is possible there are two MAG’s in a given access network and > one looses the CoA and the other MAG gets the name address. But, the tunnels > comes up after PBU/PBA exchange which introduces some delay, and so the > possibility of packets from previous MAG-era getting showing up at the new > MAG is nearly impossible and is not worth mentioning it, IMO. > > > > > >> 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"? > > Fixed in -04 version > > > > > >> On page 4 there is Figure 1 showing four flows and two tunnels. The > > We just wanted to hint that the Flow-4 is based on per-packet load balancing > using both the paths, whereas the other flows are routed based on Per-flow > load balancing. But, I think the comment is still valid. We should show the > use of a single forwarding mode and not mix both the modes. Minor nit, will > fix it. Thank you for fixing this. Kathleen > > > Thank you for your review. > > > Regards > Sri > > > > > > > > ————————————————— > Security review of > MAG Multipath Binding Option > draft-ietf-dmm-mag-multihoming-03.txt > > 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 > comments. > > 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 > intent. > > Hilarie > > On 8/1/17, 1:13 PM, "Kathleen Moriarty" <[email protected]> > wrote: > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-dmm-mag-multihoming-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-mag-multihoming/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for your work on this draft. I had the same concern as the SecDir > reviewer in reading the draft, the concern about leaking traffic as a result > of > multiple tunnels is not addressed in the security considerations section. > Hilary's writeup is quite helpful > > https://www.ietf.org/mail-archive/web/secdir/current/msg07446.html > > > > > -- Best regards, Kathleen _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
