Re: [DMM] Kathleen Moriarty's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS)

[Kathleen Moriarty <[e-mail]>]

Good morning,

On Wed, Aug 16, 2017 at 11:04 PM, Sri Gundavelli (sgundave)
<[e-mail]> 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" <[e-mail]>
> 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