RE: Route Information Options in Redirect Messages (updated)

Mark Smith <markzzzsmith@gmail.com> Wed, 08 February 2017 22:11 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65CC1295F0 for <ipv6@ietfa.amsl.com>; Wed, 8 Feb 2017 14:11:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 MhQmYVbX6vZ4 for <ipv6@ietfa.amsl.com>; Wed, 8 Feb 2017 14:10:57 -0800 (PST)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 227E812961F for <ipv6@ietf.org>; Wed, 8 Feb 2017 14:10:57 -0800 (PST)
Received: by mail-ua0-x231.google.com with SMTP id 96so120653281uaq.3 for <ipv6@ietf.org>; Wed, 08 Feb 2017 14:10:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dg2gW61wMzUdtjaJt69UpdtNb46dHLN2/GJvf7h4eRA=; b=JCtLBoQN/NNNif+jmCd0yZkf9yiyeTCFINgzyGYzsRDk8i/aeFOicuFMvvdT+v2Bfp jEz5sg2Iug8NoIwO2rkJlAdJ2/fXI6ZecjgF3KEYvF4LPF8aApOHNGXiCKvrtgPovugz mVtCLi9EZ0PB5yN0iwtn6X9pJRspnN9Iz//oVOkUWTYFmEySIZyzYp1b+HGB1nORjSLm 67eOU7T85u+Qifc1xJH8DMIooo9pWyCV+nxM4uCcc1pxBytWcMPf8qiB27Fx7r58Z/eb Z/xJ5tXV29dSt/VODU0w/4tUed288g5bgq+x3ziBWH+SlfP5o2LkMk/viCJrMqpo/U/E WOsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dg2gW61wMzUdtjaJt69UpdtNb46dHLN2/GJvf7h4eRA=; b=SJ0nloomSf/H4ukdzzKiQdZkgov37LDB50yEm9cU65sCG75sZLl9OvhfJsUZ1ZVB9h kp6y0oCMwQFW1S4x7drYgcLKV6EL+nRR6QxdsvZ5VNzWH0Uywgzth5KklP1J/ZRIWtSW FVNvV9zw1elNuBw/yKUxNKW8r3+utW68HyAbhOzXi7MQB9BjDCy+Vk3nKfw8Jj1+coq5 6EbLT/cxsHQF7dPnl41eVb9qFvaZ/jP5Vdaxvms4SI6Xpim15kmRVhb2nhCitduzQ4W3 44ukjy+1+WC28JDW9Fc0FLXCFTewMaR5mb3axIgmt8tXI4rDd1VzoxvoCLsKzFIdjBjb paFA==
X-Gm-Message-State: AIkVDXL5xN7kc4aP++qHGKC9cz355Ow0mHrAlLSMqtjYlsm4cZxv36WrZeCSeg333NjqrEv1X4fA2x7/n446Gw==
X-Received: by 10.176.3.44 with SMTP id 41mr12110369uat.157.1486591856127; Wed, 08 Feb 2017 14:10:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.33.173 with HTTP; Wed, 8 Feb 2017 14:10:55 -0800 (PST)
Received: by 10.159.33.173 with HTTP; Wed, 8 Feb 2017 14:10:55 -0800 (PST)
In-Reply-To: <c6407d1889fb4a72864e690a7be13cee@XCH15-06-08.nw.nos.boeing.com>
References: <9910b4acd87044e89fad83bb5c795b77@XCH15-06-08.nw.nos.boeing.com> <CAJE_bqfJMW5SRDxm04rC67Xvf4YqaxihyCRUXfGW3TUq42Xk-A@mail.gmail.com> <5ebd374f4ec8454b8a3796cffe5e1919@XCH15-06-08.nw.nos.boeing.com> <CAJE_bqfN9x031TXBd8Hpiv5168=zXXN+U02gGqsxyXhpQ-SDWA@mail.gmail.com> <E291D7B9-7492-4043-BE4F-E45CB54985D7@google.com> <CAJE_bqePL1bKAZL53=oebn=2eiYKdxyULd5jS4uJk9jo1sFrcA@mail.gmail.com> <614ead862aa54a548ed4835a998a42e4@XCH15-06-08.nw.nos.boeing.com> <CAO42Z2x4WZ6ObVBkawXEhtO2SqWfoQrOCvNCNXVrkpNKrzj=LQ@mail.gmail.com> <383329d88978415c9b0a12f473787c2e@XCH15-06-08.nw.nos.boeing.com> <CAO42Z2yQp7eg9hsVR_+HcePd+OcLLM+6A1yC0-kM-D5Pm2Yasg@mail.gmail.com> <69bcbba5c2af4dfd92c3fea706805da7@XCH15-06-08.nw.nos.boeing.com> <CAO42Z2yjDfep-WxZj9roHAwXfP6nh6mC2x4-+jyemPQ8B8qTTQ@mail.gmail.com> <c6407d1889fb4a72864e690a7be13cee@XCH15-06-08.nw.nos.boeing.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 09 Feb 2017 09:10:55 +1100
Message-ID: <CAO42Z2zAMrqRD-ESkoKAHZQebvx6P6Szg8Yw5svKz22yLXo2xQ@mail.gmail.com>
Subject: RE: Route Information Options in Redirect Messages (updated)
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Content-Type: multipart/alternative; boundary="001a113d0df682b4ce05480c237c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/yK0bThf5I5WNgr1bBpBu65ZyErY>
Cc: james woodyatt <jhw@google.com>, 6man WG <ipv6@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Feb 2017 22:11:00 -0000

Hi Fred,

On 9 Feb. 2017 08:37, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:

Hi Mark,

> -----Original Message-----
> From: Mark Smith [mailto:markzzzsmith@gmail.com]
> Sent: Wednesday, February 08, 2017 1:06 PM
> To: Templin, Fred L <Fred.L.Templin@boeing.com>
> Cc: james woodyatt <jhw@google.com>; 神明達哉 <jinmei@wide.ad.jp>; 6man WG <
ipv6@ietf.org>
> Subject: Re: Route Information Options in Redirect Messages (updated)
>
> Hi Fred,
>
> On 9 February 2017 at 07:33, Templin, Fred L <Fred.L.Templin@boeing.com>
wrote:
> > Hi Mark,
> >
> > What you are digging into here is out of scope for this document in the
same
> > way that orchestrating redirects for singleton destinations is out of
scope for
> > RFC4861.
>
> What RFC covers redirects? RFC4443 doesn't.

No, I am only talking about RFC4861.


I'm afraid I don't still don't understand what you're saying.

This mechanism is, at face value, nothing more than a single message
carrying a redirect for a range of addresses.

However, because it can carry a range of addresses, it may be useful in
other contexts where single address redirects are either or nearly
worthless. For example, RFC4861 explicitly prohibits routers from
processing single address redirects, so there is no point sending them to
routers.

I think one of those scenarios where a prefix redirect would be useful (but
a single address redirect isn't) is a router control plane client/server
relationship, where this mechanism operates following the same model as the
Next Hop Resolution Protocol does - the server router instructs the client
routers to establish more direct paths between themselves across the shared
multi-access link, but the client routers do not make those shorter path
decisions. If they did, they would be control plane peers, not clients.

The validation rule you're describing allows the client routers to make
their own best path choices, which means the server router has lost its
ability to be the single decision maker and the single source of truth.



> >  All it says in the validation checks is:
> >
> >   - The IP source address of the Redirect is the same as the current
first-hop
> >      router for the specified ICMP Destination Address.
> >
> > It does not say anything about how all of the potential first-hop
routers on
> > the link coordinate among themselves to make sure that the Redirects
don't
> > steer hosts into a rat's nest of endless loops.
> >
> > Yes, just the same as for redirects of singleton destinations, there is
an
> > implied trust basis that routers that send Redirects will behave
truthfully
> > and consistently. It is no different for Redirects that contain RIOs.
> >
>
> Then my use case is not a use case for this. I have to provide
> services to stub routers, but cannot trust them to act entirely
> benevolently, because I don't own, operate or even have much influence
> over what brand they are. I want to provide a the best and possibly
> better service to them because their owners are paying me to e.g.,
> local layer 2 switching in the exchange, but I cannot let one customer
> impact the service of any other customer.

OK, but then that sounds like either a different document or a Security
Considerations note for this document. But, the mainline validity check
needs to stay generic.


It seems to me that the default validity check needs to be the one that
provides the most robustness, which usually means the default setting needs
to suit the likely deployment environment it will be deployed in.

In my scenario, if you trusted and operated all of the routers, you could
run a dynamic IGP on them to provide optimal path information to them. A
new mechanism like a prefix redirect is an alternative to existing
mechanisms in this scenario.

If you can't trust the routers, then you either provide them with a default
route (either they configure statically or you provide via RAs) or run BGP
with them, which has all the policy knobs necessary to provide and receive
routing information securely. BGP of course isn't scalable to residential
broadband.

The latter case is the most common, in the order of 100s of millions of
instances around the world. So I think the default validation for these
sorts of messages for stub routers should suit that scenario (requiring
non-technical users to switch on increased security features just doesn't
work.)


Regards,
Mark.



Thanks - Fred
fred.l.templin@boeing.com

> Regards,
> Mark.