Re: [DMM] Kathleen Moriarty's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS)
"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Fri, 18 August 2017 01:15 UTC
Return-Path: <sgundave@cisco.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062001326D8; Thu, 17 Aug 2017 18:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGpM84jOSw-i; Thu, 17 Aug 2017 18:15:23 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7165132677; Thu, 17 Aug 2017 18:15:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31998; q=dns/txt; s=iport; t=1503018922; x=1504228522; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bHhCW/U406hN0ztxxxemqtfQ7JJFrOQly94RGCS1d68=; b=gBsouhr/5xvTA7K3EPojKyMBudFRWjYuXjx5q3lSldvqDV/ujGz0++fG 6d9/I77nb3+CxDEol//hgjtjPulTY/ljc+vFYcMleh5z8RLQzMn/UsnG2 M4I2gWMtBilrrMorc7vdk95+ypA0jE/S9+rtXbPscJiWyTjl3kBRRMLML Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CfAAC7PpZZ/4QNJK1dGQEBAQEBAQEBAQEBBwEBAQEBgm9rZIEVB4RTiTiQEoomjWMOggQshExPAhqEPj8YAQIBAQEBAQEBayiFGQYjTwcQAgEGAj8DAgICHxEUEQIEDgUbiTFMAxUQjA+dZIImhzoNhCABAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMogRtngUyBY4MngleBaQELBgIBGwovAoJbgmEFiX6HF4cGh3I8AodSg1WEI4R2ghCFYIN7hnGJaIJOiWYBHzh/C3cVSYVMgU52AYcZAiQHgQWBDwEBAQ
X-IronPort-AV: E=Sophos;i="5.41,390,1498521600"; d="scan'208,217";a="444861376"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Aug 2017 01:15:21 +0000
Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v7I1FLgw001584 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Aug 2017 01:15:21 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Aug 2017 20:15:20 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1210.000; Thu, 17 Aug 2017 20:15:20 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-dmm-mag-multihoming@ietf.org" <draft-ietf-dmm-mag-multihoming@ietf.org>, Jouni Korhonen <jouni.nospam@gmail.com>, "dmm-chairs@ietf.org" <dmm-chairs@ietf.org>, "dmm@ietf.org" <dmm@ietf.org>
Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS)
Thread-Index: AQHTF7911UlvoXUvDEOO27BVPk/g+A==
Date: Fri, 18 Aug 2017 01:15:20 +0000
Message-ID: <D5BB8C89.287E2C%sgundave@cisco.com>
References: <150161840636.12123.2784912255737760138.idtracker@ietfa.amsl.com> <D5BA4FC7.287B1F%sgundave@cisco.com> <CAHbuEH6n9WnTZNKHk_rF9sKERQo=5c=9U0xmXdmxB56wCGsx0A@mail.gmail.com>
In-Reply-To: <CAHbuEH6n9WnTZNKHk_rF9sKERQo=5c=9U0xmXdmxB56wCGsx0A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.188.62]
Content-Type: multipart/alternative; boundary="_000_D5BB8C89287E2Csgundaveciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/E5vu2IwRMoEwXhRYjbDSjhC_hVI>
Subject: Re: [DMM] Kathleen Moriarty's Discuss on draft-ietf-dmm-mag-multihoming-04: (with DISCUSS)
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Aug 2017 01:15:26 -0000
Hi Kathleen, Thank you so much. Please see inline. Good morning, On Wed, Aug 16, 2017 at 11:04 PM, Sri Gundavelli (sgundave) <sgundave@cisco.com<mailto:sgundave@cisco.com>> 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? I assume you are referring to the below discussion point. We can add some text, but this IMHO is absolutely a non-existent scenario; not trying to ignore a valid issue. Out of order delivery with such delays, where one MAG releasing the address and another MAG obtaining the same IP address with the associated address configuration delays, MN attachment triggering a PBU at that juncture, and a PBU/PBA exchange, a tunnel establishment and a packet from the previous MAG showing up at the new MAG is not a technical possibility, IMO. I am not even sure how to frame this. But, I am happy to include any text, but IMHO it will be a text for non-existent scenario. Let me know. Regards Sri 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" <Kathleen.Moriarty.ietf@gmail.com<mailto:Kathleen.Moriarty.ietf@gmail.com>> 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
- [DMM] Kathleen Moriarty's Discuss on draft-ietf-d… Kathleen Moriarty
- Re: [DMM] Kathleen Moriarty's Discuss on draft-ie… pierrick.seite
- Re: [DMM] Kathleen Moriarty's Discuss on draft-ie… Sri Gundavelli (sgundave)
- Re: [DMM] Kathleen Moriarty's Discuss on draft-ie… Kathleen Moriarty
- Re: [DMM] Kathleen Moriarty's Discuss on draft-ie… Sri Gundavelli (sgundave)