Re: Benjamin Kaduk's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)

Jen Linkova <furry13@gmail.com> Thu, 04 July 2019 00:42 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4B212010F; Wed, 3 Jul 2019 17:42:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Level:
X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 lWBF33DzbB6J; Wed, 3 Jul 2019 17:42:48 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF8712007C; Wed, 3 Jul 2019 17:42:48 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id i125so4341225qkd.6; Wed, 03 Jul 2019 17:42:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o3/Qrer9nEs3IKltp7b8LHBkVZUXyhcUItkcafZ9y/g=; b=MfrNU7hCTTXWyp2g0w12JpwiT3pOkIB63TBfbEvYbR/AAKwQ+J9PPInVRbOFLN9F3e EZjeNCXjbyRR0X03Rlxve7OWoXh0i+CKsxCiq2i+YzYBYkzKTDOo12pOkNQ6yrcBO39Z CbbarvYVjy8+qARg4S9fZKRLkDhG4cjcMrcJrZFGFYoUp9faILITzBCm22XSfc9uBrIE Ki30j8b5k2qx78SxnwAKYXCOKmXdhNr4a8lfbsbL74bGWGdtjyiB3U/GdC+6hzFBEuFX TNu8qsVsby8MOD8+LdywsqIgNwxgwLVoqOzfKwCPEAALnRBOziTftxNs4cmBNgYdcQsA oghw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o3/Qrer9nEs3IKltp7b8LHBkVZUXyhcUItkcafZ9y/g=; b=Aw4H3GYM5INdDf7fRHSsYpCc3agDRCWiFeHka/EwW/X1p5mu2lo6ZD+1ppENodWmXr JE0BcMpnkau4Yu4JEmmmvZR1UDJLGF0g5U0nc0BJz3+RmnTAlWiBmF5nrZOWz/FA6vCY 9cZm9yjRkAL4ADLVfSYt2Q/7oNKMucvRxTne9ftUt9iwBVlywG2J9cmCrvwgcI9atFuH YkYR9sKpCxp3c5Czd6MxwZ79Ek9zeTryDlOOqt1Zkoty/9YmzUoIMiYUUgZjgvZZZ4D0 hZFbVe6mo2o6BP2CMRZfW2lMQxtYTY3f/gEO7yD+ItQgOsIDhvRitkx/VYG1YSXEBb5G GC0Q==
X-Gm-Message-State: APjAAAWkvwhdX+eedK1qU5llF+mDANY5szBUm2yQk8j5ZfmR7AznmZk9 9E/BCSDN0lak03uhPhuGuz/bCfzRTYWJn9CN2i0=
X-Google-Smtp-Source: APXvYqwWc8EVRWEqC/clyTjr5th7oidP7Yc9RYxOAioEzBZO86JBqgCna1/bf1OeQagwbAlVHvxkfyW7g1t1kRWKpes=
X-Received: by 2002:a37:311:: with SMTP id 17mr751682qkd.466.1562200967478; Wed, 03 Jul 2019 17:42:47 -0700 (PDT)
MIME-Version: 1.0
References: <156158728441.20135.9632421726659042986.idtracker@ietfa.amsl.com> <CAFU7BASqGX1u4hiaVNxBcMi+7y6fHnP5=xi=phJeOWoymy7Rjg@mail.gmail.com> <CAHzoHbuiP9cqOv5KAkYN=oDhrU_Og98AuN_kbE73Ao9ns5ZquQ@mail.gmail.com> <20190703185314.GL13810@kduck.mit.edu>
In-Reply-To: <20190703185314.GL13810@kduck.mit.edu>
From: Jen Linkova <furry13@gmail.com>
Date: Thu, 4 Jul 2019 10:42:35 +1000
Message-ID: <CAFU7BAQGhT4FH5ia97QvmKKiz=2QerXxemg1qXxG5A=DBB9hbA@mail.gmail.com>
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-rtgwg-enterprise-pa-multihoming-08: (with COMMENT)
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Chris Bowers <chrisbowers.ietf@gmail.com>, The IESG <iesg@ietf.org>, Ronald Bonica <rbonica@juniper.net>, rtgwg-chairs <rtgwg-chairs@ietf.org>, draft-ietf-rtgwg-enterprise-pa-multihoming@ietf.org, Routing WG <rtgwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/Up1w_fmwHeXoWdNIhIMolQbJGrU>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Jul 2019 00:42:51 -0000

Hi Ben,

I've just submitted -10 version which has Chris's changes integrated
as well as all suggestions you made.

The diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rtgwg-enterprise-pa-multihoming-10

Full text:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-10

A few comments below:

On Thu, Jul 4, 2019 at 6:12 AM Benjamin Kaduk <kaduk@mit.edu>; wrote:
> > > >    To fully benefit from the RA-based solution, first-hop routers need
> > > >    to implement SADR and be able to send dedicated RAs per scoped
> > > >
> > > > It's not just the first-hop routers, though -- won't all the first-hops
> > > > need to be part of the same connected SADR domain?
> > >
> > > They are. By design/definition.
>
> Perhaps I'm still confused, but I thought other parts of this document
> admitted the possibility of having multiple SADR-capable routers that are
> not all in a connected domain, if only to say "don't do that".  For
> example, all the  SERs need to be in the same domain.  But if I look at,
> e.g., Figure 1's topology, R3 would be a first-hop router for H41, and if I
> read the quoted text literally, having R3 and the SERs support SADR but not
> R5 would seem to produce a disconnected domain and thus problems.

That's why we are saying:
"Therefore all SADR-capable routers within the domain MUST be
logically connected."
Having R3 and SERs in the SADR domain with non-SADR capable R5 between
them might lead to a routing loop.

The changes made in -10 to clarify this:
1) Replaced:
"To fully benefit from the RA-based solution, first-hop routers need
to implement SADR and be able to send dedicated RAs per scoped
forwarding table as discussed above,"

with
"To fully benefit from the RA-based solution, first-hop routers need
to implement SADR, belong to the SADR domain and be able to send
dedicated RAs per scoped forwarding table as discussed above.."

2) Added another item to the Deployment Considerations section:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-10#section-7.1
"During the incremental SADR domain expansion from the SERs down
towards first-hop routers it's important to ensure that at any
moment of time all SADR-capable routers within the domain are
logically connected (see Section 5)."

Is it less confusing now?

> That's one type of attack, yes.  I think there may be another one where the
> attacker has some wiretap in ISP_A but not ISP_B, and they can use the
> ICMPv6 message to tell the sender to use the source address from ISP_A when
> traffic would otherwise go to ISP_B or elsewhere -- the forged message
> causes the traffic to be routed where the attacker can do other things to
> it.
>
> > > I think that if such messages are required to be sent from the
> > > link-local address and the GTSM is enforced, then the attack vector is
> > > limited to the same L2 domain which is a bit better..I'll add the text
> > > to clarify it tomorrow.

After thinking about it I've realized that GTSM would not help here.
Those messages could be sent from SERs (which are a few hops away).
I've moved all security considerations from that section to Section 10:
https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-10#section-10

Please let me know if you have any comments for -10 version.

Thanks!

-- 
SY, Jen Linkova aka Furry