Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Thu, 15 October 2020 19:31 UTC

Return-Path: <Fred.L.Templin@boeing.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1803A0CBE; Thu, 15 Oct 2020 12:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=boeing.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 NiTOOjx2iLLO; Thu, 15 Oct 2020 12:31:04 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0013A1330; Thu, 15 Oct 2020 12:31:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09FJV1A0027798; Thu, 15 Oct 2020 15:31:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602790261; bh=nTM2J+hRiQef+pH2UutZ106LJN/1zHCFLWh9ppvd7O0=; h=From:To:CC:Subject:Date:From; b=pD6koPmDcQoGQD3V2foAvtvRLUeYCeu45i5KzBWtTw2brW+gt+TH/b6Cc6/EXj+ga 0PKlmJ/YxSW1GojkPUUnLdR3rsLJoB5kJR/F4xWD2JIFb8b2gKi5oGDtmYROBRQiQa jJGLruQ9IZa2MzYCdH2G7nsXA+wlGiSSFZi3x/HT/j9v9OjgP6a/TOR+U1NapjEZxU LGpy5jtYOOKMMG0ZZ+8LUEkNWf8cEhHVD1Nf7sSFD0hf9BjESUok4N0Xzfv/4Gog0k npsP+185lLb6gX+sYH8OBVp6DpIxZL8mkh8BrKqXH2pdOOCUPg1uN4f6eEVYbFCK6P i9JpC0gtB+S/g==
Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09FJUuGj027718 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 15 Oct 2020 15:30:56 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Thu, 15 Oct 2020 12:30:55 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Thu, 15 Oct 2020 12:30:55 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
CC: v6ops list <v6ops@ietf.org>, IPv6 List <ipv6@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>, dhcwg <dhcwg@ietf.org>
Thread-Topic: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
Thread-Index: AdajKLVVnwghNqrLQ4229LT3ce4i4A==
Date: Thu, 15 Oct 2020 19:30:55 +0000
Message-ID: <65f390e222244427bd3cbc1f58a3ec95@boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 399499A39F04305249E078848074FC2B5528438B2F1393D1CB6643844044F4AC2000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/e75fUExmycf1tQ9DVEOY-PgO_7I>
Subject: Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2020 19:31:07 -0000

Eduard,

Thanks for your message. The point I was trying to make is that if the upstream router
R is convinced - through whatever means - that the downstream stub router S holds
an IPv6 prefix such as 2001:db8:a:b::/64, then it will forward all IPv6 packets with
destination address from that prefix to S *even if the packets originated from S*.
That is not a new issue brought about by DHCPv6, since it is  a forwarding plane
issue and not a control plane issue.

Fred

> -----Original Message-----
> From: Vasilenko Eduard [mailto:vasilenko.eduard@huawei.com]
> Sent: Thursday, October 15, 2020 12:12 PM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: v6ops list <v6ops@ietf.org>rg>; IPv6 List <ipv6@ietf.org>rg>; Michael Richardson <mcr+ietf@sandelman.ca>ca>; dhcwg <dhcwg@ietf.org>
> Subject: RE: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
> 
> Hi Fred,
> You need the challenge. OK. I have it for you.
> 
> Typical routing protocols would distribute to the "stub" router information about prefixes "somewhere in the network".
> Prefixes from local interfaces are inserted into the routing table in the very persistent way:-)
> 
> DHCP-PD would distribute to the "stub" router information about prefixes that should become local/interface prefixes on the "stub".
> Non-graceful reload could lead to amnesia on the "stub". Then it could attack its own uplink.
> It is a new problem. Because DHCP-PD does play the role of "automatic provisioning system", not routing protocol.
> The problem could be called "non-consistent routers configuration".
> The fact that proper protocol for prefix distribution should be very similar to routing protocol - is the secondary here (it is
> implementation), because the problem itself is new.
> 
> Eduard
> > -----Original Message-----
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Templin (US), Fred L
> > Sent: 15 октября 2020 г. 1:37
> > To: Bob Hinden <bob.hinden@gmail.com>
> > Cc: v6ops list <v6ops@ietf.org>rg>; IPv6 List <ipv6@ietf.org>rg>; Michael Richardson
> > <mcr+ietf@sandelman.ca>ca>; dhcwg <dhcwg@ietf.org>
> > Subject: RE: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay
> > Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
> >
> > > I note that the lack of “challenge” does not mean anyone agrees.   Agreement
> > needs to be affirmative.
> >
> > Fair enough, Bob; here is the assertion I made that I was referring to:
> >
> > + BTW, I am still waiting to hear how this concern is in any way
> > + specific to prefix delegation, since it seems to be generic to any
> > + case of having a “stub” router that maliciously attacks its own
> > + upstream link – no matter how that router negotiates its prefixes with
> > upstream network nodes.
> >
> > Do the individuals CC'd on this list agree that this is a generic IPv6 issue and not a
> > DHCPv6-PD-specific issue?
> >
> > Thanks - Fred
> >
> > > -----Original Message-----
> > > From: Bob Hinden [mailto:bob.hinden@gmail.com]
> > > Sent: Wednesday, October 14, 2020 3:28 PM
> > > To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > > Cc: Bob Hinden <bob.hinden@gmail.com>om>; Michael Richardson
> > > <mcr+ietf@sandelman.ca>ca>; dhcwg <dhcwg@ietf.org>rg>; IPv6 List
> > > <ipv6@ietf.org>rg>; v6ops list <v6ops@ietf.org>
> > > Subject: Re: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay
> > > Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay- requirements
> > >
> > > I note that the lack of “challenge” does not mean anyone agrees.   Agreement
> > needs to be affirmative.
> > >
> > > Bob
> > >
> > >
> > > > On Oct 14, 2020, at 3:24 PM, Templin (US), Fred L
> > <Fred.L.Templin@boeing.com> wrote:
> > > >
> > > > Bob, several messages back it was established that the issue at the
> > > > heart of this discussion is not specific to DHCPv6 nor DHCPv6-PD.
> > > > Instead, it is an issue that is common to any situation where there
> > > > are multiple "stub" IPv6 routers on a downstream link from a
> > > > "default" IPv6 router, no matter how the routing information is
> > > > established or maintained. So far, no one has challenged my
> > > > assertion that this is a generic (and not a DHCPv6-PD-specific) IPv6 issue and
> > I have been waiting to see if anyone wants to challenge that.
> > > >
> > > > Fred
> > > >
> > > >> -----Original Message-----
> > > >> From: Bob Hinden [mailto:bob.hinden@gmail.com]
> > > >> Sent: Wednesday, October 14, 2020 2:47 PM
> > > >> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > > >> Cc: Bob Hinden <bob.hinden@gmail.com>om>; Michael Richardson
> > > >> <mcr+ietf@sandelman.ca>ca>; dhcwg <dhcwg@ietf.org>rg>; IPv6 List
> > > >> <ipv6@ietf.org>rg>; v6ops list <v6ops@ietf.org>
> > > >> Subject: Re: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6
> > > >> Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> > > >> requirements
> > > >>
> > > >> With my chair hat on, is there a reason why this discussion is being copied
> > to the 6MAN w.g.?   6MAN doesn’t maintain DHCP
> > > related
> > > >> items.
> > > >>
> > > >> Please remove ipv6@ietf.org from this thread.
> > > >>
> > > >> Bob
> > > >>
> > > >>
> > > >>> On Oct 14, 2020, at 12:19 PM, Templin (US), Fred L
> > <Fred.L.Templin@boeing.com> wrote:
> > > >>>
> > > >>> Hi Michael,
> > > >>>
> > > >>>> -----Original Message-----
> > > >>>> From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]
> > > >>>> Sent: Wednesday, October 14, 2020 11:58 AM
> > > >>>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> > > >>>> Cc: ianfarrer@gmx.com; Jen Linkova <furry13@gmail.com>om>; dhcwg
> > > >>>> <dhcwg@ietf.org>rg>; v6ops list <v6ops@ietf.org>rg>; 6man
> > > >>>> <ipv6@ietf.org>
> > > >>>> Subject: Re: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to
> > > >>>> DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-
> > > >> relay-
> > > >>>> requirements
> > > >>>>
> > > >>>>
> > > >>>> Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> > > >>>>> Michael, what I was referring to below as "failure" is the proxy
> > > >>>>> case when there is an L2 proxy P between the client and relay
> > > >>>>> (e.g., RFC489). There
> > > >>>>
> > > >>>> RFC4389 describes an ND Proxy.
> > > >>>> Is that really an L2 proxy?
> > > >>>
> > > >>> Yes, I believe it is an L2 proxy.
> > > >>>
> > > >>>> It seems like it also must be contain either an L2-bridge, or
> > > >>>> must have the L3-routing table entries if it would really be
> > > >>>> capable of passing DHCPv6-PD prefixes through it.
> > > >>>
> > > >>> The only thing it has that includes L3 information is neighbor
> > > >>> cache entries that keep track of the client's actual L2 address on
> > > >>> the downstream link segment, but rewrites the client's L2 address
> > > >>> to its own L2 address when forwarding onto an upstream link
> > > >>> segment. (In the reverse direction, it receives packets destined
> > > >>> to its own L2 address but the client's L3 address on the upstream
> > > >>> link segment, then rewrites the L2 address to the client's L2
> > > >>> address when forwarding onto the downstream link segment.)
> > > >>>
> > > >>>> Can you explain how such a device would normally work for a
> > > >>>> client device A,B,C,D doing DHCPv6-PD through it?
> > > >>>
> > > >>> Sure. A sends a DHCPv6 Solicit using its IPv6 link-local address
> > > >>> as the source, and its L2 address as the link-layer source. The
> > > >>> proxy converts the link-layer source to its own L2 address when
> > > >>> forwarding the DHCPv6 solicit onto the upstream link. When the
> > > >>> DHCPv6 Reply comes back, the IPv6 destination is that of client A, but the
> > link-layer destination is the L2 address of the proxy.
> > > >>> The proxy then converts the L2 destination to the address of
> > > >>> client A and forwards it on to the client.
> > > >>>
> > > >>>> And is the failure one where the router "R" fails to drop traffic
> > > >>>> it should, one where the router "R" drops traffic that it shouldn't?
> > > >>>
> > > >>> I was thinking more along the lines of the latter; if the only way
> > > >>> that A has for talking to B, C, D, etc. is by going through R, it
> > > >>> wouldn't work if R was unconditionally dropping everything.
> > > >>>
> > > >>> Thanks - Fred
> > > >>>
> > > >>>> --
> > > >>>> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT
> > consulting )
> > > >>>>          Sandelman Software Works Inc, Ottawa and Worldwide
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>
> > > >>> ------------------------------------------------------------------
> > > >>> -- IETF IPv6 working group mailing list ipv6@ietf.org
> > > >>> Administrative Requests:
> > > >>> https://www.ietf.org/mailman/listinfo/ipv6
> > > >>> ------------------------------------------------------------------
> > > >>> --
> > > >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------