RE: Route Information Options in Redirect Messages (updated)

Mark Smith <markzzzsmith@gmail.com> Wed, 08 February 2017 20:06 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 ECF8F129461 for <ipv6@ietfa.amsl.com>; Wed, 8 Feb 2017 12:06:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 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, RCVD_IN_DNSWL_LOW=-0.7, 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 QyL1HKSgM0mK for <ipv6@ietfa.amsl.com>; Wed, 8 Feb 2017 12:06:50 -0800 (PST)
Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 EAA2D12940D for <ipv6@ietf.org>; Wed, 8 Feb 2017 12:06:49 -0800 (PST)
Received: by mail-vk0-x22d.google.com with SMTP id k127so109015153vke.0 for <ipv6@ietf.org>; Wed, 08 Feb 2017 12:06:49 -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:content-transfer-encoding; bh=oS7zDL6HoCQSxVKWeAOLKu0Ksgads6QvkaR2U+NEeGE=; b=RzHRJgxhN2T/fSEDoKo20kgc47bvVM+fqCZaX1MYomAopA0/HBxZ+oRFwuXCKMtkLV Uz2Tz8NKyhDCGHY2bMRtUy7RT6oTXxu7FBNU3kncwvgiGt4pXR4N6MecS95QjwCKDs/J K4/f3EgvcjVy31FkRL+TaETDUIhH8ZjhUv8/HQiGy7RLwFfkWS2Lciu6+bQgnr2oOTNI rB2D/mFwHZyf+q0+2ZWJeSmSt0nX7PjT6f61MCzcW0FoMvyc1pDWJzi0usCyKR0SrD0b KWn+4tc+eIe2MmUykhmH9C6Ddn2zLXaeVvmzY8dDBPRmLwEVnlihiojIZpiTQm94FFho sYJQ==
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:content-transfer-encoding; bh=oS7zDL6HoCQSxVKWeAOLKu0Ksgads6QvkaR2U+NEeGE=; b=pDsONDMumLqPoTns6ReIOzi1jhpe24NikKPnn4DJc1QjnxVd0hCSVzJJ4uMUSIKCOa OxIwQ/96Ziw2CSoXIcaBXjwz8ohiMuVW9Y4PxodqSYCT5RK7JfkbsiXWcwAuFNRIjOJ4 89AdCZiKfzkw3++OH4Zg7XE+v6KSBapyn4TjKZ74enD2shx+9qaTQfEKzkIU0gq88ECF /KYQ0INLIBz1h3W4oe7h4tABWnHzuzgUGJ3L8LZJ/gbTM9hir7KrkbTSmr4b+Yz4ILD9 m8H5APhADfgIcPZT5Grlq8UIQg0ru+NMXLJFd8Pu4xAsKgyXyh9Ycb2WcKb+TDn7FdeS j/Bg==
X-Gm-Message-State: AMke39kt6Rq/VqOhD+4EVyQV2yLpg6dGQJ4IXu71in4jHMkZ1ywH+Hobg0kS6Qb9B/HLb22RntaAtRxAJyqKIA==
X-Received: by 10.31.153.8 with SMTP id b8mr11098322vke.140.1486584408971; Wed, 08 Feb 2017 12:06:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.159.33.173 with HTTP; Wed, 8 Feb 2017 12:06:18 -0800 (PST)
In-Reply-To: <383329d88978415c9b0a12f473787c2e@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>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 9 Feb 2017 07:06:18 +1100
Message-ID: <CAO42Z2yQp7eg9hsVR_+HcePd+OcLLM+6A1yC0-kM-D5Pm2Yasg@mail.gmail.com>
Subject: RE: Route Information Options in Redirect Messages (updated)
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/FaX1iKx6SSgSdvotj3clercr5Nw>
Cc: james woodyatt <jhw@google.com>, 6man WG <ipv6@ietf.org>, =?UTF-8?B?56We5piO6YGU5ZOJ?= <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 20:06:51 -0000

Hi Fred,

On 8 Feb. 2017 06:54, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:

Hi Mark,



> Ø  I think you need to be careful of not effectively reinventing a dynamic routing protocol



> No, there is no reinvention going on here. The behavior parallels redirects

> for singleton destination addresses, where Redirects are accepted from the

> current first-hop router, be it a default or non-default.


So in my proposed case of a stub router receiving and accepting a
prefix redirect, that is where there would be more of behaviour
change, as, per RFC4861,

A router MUST NOT update its routing tables upon receipt of aRedirect.

For these stub routers, accepting a prefix redirect from more than
just a default router is where I think it starts encroaching on the
functionality of a dynamic routing protocol. It starts being possible
to have all the stub routers in the set sending each other prefix
redirects (perhaps maliciously) and ending up with a variety of
different, possibly random paths across the link, with some of those
paths creating forwarding loops. Dynamic routing protocols would
resolve this situation to a single best path as well as eliminating
forwarding loops. That is the sort of functionality that would be (and
should be to keep it simple) missing from a simple prefix redirect
mechanism.

I think limiting the problem space to that of providing a better entry
point into the "proper" routing system/forwarding domain for stub
routers, by only accepting them from default routers learned via RAs
or static configuration, avoids the possibility of encountering and
having to mitigate these more complex issues.

Perhaps that means there needs to be two different validation rules
for the two different types of devices:

- for hosts, accept prefix redirects from current first-hop router for
a destination covered by the prefix

- for stub routers, only accept prefix redirects from default routers

with the fundamental distinguisher between the device types being
whether they forward non-local packets or not, and whether a stub
router accepts them or not being dependent on whether there is a
dynamic routing protocol enabled on the prefix redirect receiving
interface.


Regards,
Mark.








Thanks - Fred



From: Mark Smith [mailto:markzzzsmith@gmail.com]
Sent: Tuesday, February 07, 2017 11:38 AM


To: Templin, Fred L <Fred.L.Templin@boeing.com>
Cc: 6man WG <ipv6@ietf.org>rg>; james woodyatt <jhw@google.com>om>; 神明達哉
<jinmei@wide.ad.jp>
Subject: RE: Route Information Options in Redirect Messages (updated)







On 8 Feb. 2017 05:43, "Templin, Fred L" <Fred.L.Templin@boeing.com> wrote:

Hi Jinmei-san,

<snip>
>
> Hmm, maybe I'm so dumb but I'm afraid I still don't understand intent
> clearly.  Do you mean an operational assumption of this proposal is to
> use it in a link where RA guard isn't deployed?  If so, it's far
> better (at least to me) to just say so.
>
> BTW, if this proposal keeps the concept of "unsolicited redirect" and
> also allows the destination address of '::' to bypass the host's
> validity check of whether it's really the first hop router for the
> destination,

No, that is not what we want to have happen. The document doesn't
say this currently, but we want to retain a revised version of the validity
check. The revised version of the check would say:

OLD:
      - The IP source address of the Redirect is the same as the current

        first-hop router for the specified ICMP Destination Address.

NEW:
      - The IP source address of the Redirect is the same as the current
        first-hop router for the specified ICMP Destination Address, or
        (when the ICMP Destination Address is '::') the same as the current
        first-hop router for the specified RIOs

Would welcome better wording than this, but we definitely do want
to retain the validity check. Comments?



I think you need to be careful of not effectively reinventing a
dynamic routing protocol that ends up missing the necessary
capabilities required of one to keep this method simple.



When I've thought about this sort of capability, I've thought of it as
a hint from the routing system to the users of the forwarding domain -
hosts and stub routers (default and connected route only routers,
possibly with other static routes) - of a better entry point for their
packets into the forwarding domain.



In the case of a stub router, if it needs or would benefit from more
dynamic network information than just a prefix redirect hint, then I
think that is really saying that the stub router shouldn't be a stub
router - it needs to be a full and proper participant in the routing
system (running dynamic routing protocol, discovering and conveying
network topology information etc.), rather than a user of it via
default route to the forwarding domain.



That's why I thought the validation should be that these prefix
redirects are only accepted from a default router learned via an RA or
static default router configuration, as a default router has the role
of offering an entry point into the forwarding domain. It would
enforce the existing boundary between the devices that are users of
the forwarding domain, and the devices that are participants in the
routing system that decide the paths through the forwarding domain.



Regards,

Mark.