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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 13 October 2020 16:42 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 6013B3A09DB; Tue, 13 Oct 2020 09:42:14 -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=unavailable 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 ks4vIdiQfGoW; Tue, 13 Oct 2020 09:42:12 -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 2E1D23A09CC; Tue, 13 Oct 2020 09:42:11 -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 09DGg5sZ031670; Tue, 13 Oct 2020 12:42:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602607330; bh=Q14ZRlMrvxSzp0SUJGSGPg4EDjomy1SdfLeDfXPtPhA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=mSllvAULmtt7gjiOFufmhojVQKejG6xp9xAevqGhNv51zn4Ek4MeFAyQ8YBURnhSj x45cUWZXja9HDg2AXz0Qo3Ru4rFXVxzQu0AZaH8Titqn1B725vrb/Nljp3wmjtZ3N2 6l2x61dTjtkrTqnRrDqE5TPmuyZ/ThvhJS6QPZ5pimMYSywrMAnM/KDHZTXU0NNzqF SORxnM7MkcG92QyMnuApqMlipFbpcu9fC3Azj9wMg2FvhVI8/nQGC6QVnk/sBv3KTg PjQ8Ds6gGs8ZsBQDc43vbsFqy/CBtW2OFabRacE9uCyEyLQOR7wqjL6SM2ik24/R90 D1FetQHkXf1JA==
Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09DGg2bp031350 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 12:42:02 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 13 Oct 2020 09:42:01 -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; Tue, 13 Oct 2020 09:42:01 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: "ianfarrer@gmx.com" <ianfarrer@gmx.com>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, Jen Linkova <furry13@gmail.com>, dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@ietf.org>, "Bernie Volz (volz)" <volz=40cisco.com@dmarc.ietf.org>, 6man <ipv6@ietf.org>
Thread-Topic: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
Thread-Index: AdahZz7s2M1crQrvQoqZsITGBawESAATn5SAAA4dvgA=
Date: Tue, 13 Oct 2020 16:42:01 +0000
Message-ID: <86d4e46a49c046dfabd1375210fefbce@boeing.com>
References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <9C612486-C25D-463F-8FB4-5BAAF9A96AE5@gmx.com>
In-Reply-To: <9C612486-C25D-463F-8FB4-5BAAF9A96AE5@gmx.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: 338B30B65CABCC84017E479834CE865B2967EEF4F532FC53FC2650F852FFBAD92000: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/M8sGMUWoNOzfEmsw7uKAm5emLgM>
Subject: Re: [dhcwg] [EXTERNAL] Re: [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: Tue, 13 Oct 2020 16:42:15 -0000

Hi Ian,

> -----Original Message-----
> From: ianfarrer@gmx.com [mailto:ianfarrer@gmx.com]
> Sent: Tuesday, October 13, 2020 9:08 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
> Cc: Michael Richardson <mcr+ietf@sandelman.ca>; Jen Linkova <furry13@gmail.com>; dhcwg <dhcwg@ietf.org>; v6ops list
> <v6ops@ietf.org>; Bernie Volz (volz) <volz=40cisco.com@dmarc.ietf.org>; 6man <ipv6@ietf.org>
> Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
> 
> This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and
> know that the content is safe.
> 
> 
> HI Fred,
> 
> Please see inline below.
> 
> Thanks,
> Ian
> 
> > On 13. Oct 2020, at 15:55, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
> >
> > Ian,
> >
> >> For multi-access links, when the packet's
> >> ingress and egress interface match, and the source MAC and next-hop MAC addresses
> >> match.
> >
> > As I said, this gets very tricky if the client has multiple MACs. If Client A has MAC addresses
> > a1, a2, a3, a4, etc. it becomes very difficult for the relay to know that a packet received
> > from one of the MAC addresses (e.g., a1) must not be sent back to another of the MAC
> > addresses (e.g., a3). I think another failure case is if there is a proxy between the client
> > and relay. In that case, the relay will see the MAC address of the proxy and not the
> > MAC address of client A. And, if there were multiple additional clients B, C, D, etc.
> > sharing the same proxy then the proposed check could block legitimate traffic.
> 
> [if - The client would have to source DHCP multicast messages from MAC a3 and source egress traffic from MAC a1. Have you got an
> example of why the client might be configured in this way?

It is called "multilink", and some interfaces types such as OMNI understand
how to do multilink where the upstream and downstream MAC addresses
may be asymmetric.

> Isn’t the worst case here that the results would be no different to R-4 not existing, but for the (I would guess more common) single
> client MAC address case, we can improve things?
 
Even with the single client MAC address case, it would not work if there were a proxy.

> For the proxy case, I can see the problem that you describe and in this case, the best
> course of action would be to disable the drop policy.]

I think the proxy case is real, and may be quite common for some interface types.

> > As I said before, I think the better fix is to instrument the client. If the client receives
> > a packet on its relay-facing interface, and the routing system determines that the
> > packet should be forwarded out the same interface via a default route, the client
> > must drop the packet. That way, the relay never sees a looped packet, and there
> > is no extraneous traffic on the client/relay interface.
> 
> [if - There’s a couple of problems that this requirement is trying to address:
> 
> 1, A misbehaving client (accidentally or otherwise)

The check I outlined prevents the accidental case. A misbehaving client that
receives a legitimate prefix delegation and then proceeds to do bad things
with it is one who should be denied service in the future.

But in terms of a misbehaving client, how would this be any different than the
case where a stub router uses a routing protocol (RIP, OSPF, etc.) and advertises
a prefix that causes the upstream router to add the prefix to the RIB/FIB, but
then the stub router sends bad self-addressed traffic to the upstream router
causing a ping-ponging loop?

> 2, The volume of traffic being forwarded by the relay consumes the available bandwidth meaning
> that DHCP configuration can’t complete
> 
> In both cases, the client can’t be relied on to solve the problem]

How do routing protocols (RIP, OSPF, etc.) address the misbehaving stub
router case?

Thanks - Fred

 > 
> >
> > Fred
> >
> >> -----Original Message-----
> >> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of ianfarrer@gmx.com
> >> Sent: Tuesday, October 13, 2020 6:16 AM
> >> To: Michael Richardson <mcr+ietf@sandelman.ca>; Jen Linkova <furry13@gmail.com>
> >> Cc: dhcwg <dhcwg@ietf.org>; v6ops list <v6ops@ietf.org>; Bernie Volz (volz) <volz=40cisco.com@dmarc.ietf.org>; 6man
> >> <ipv6@ietf.org>
> >> Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> >> requirements
> >>
> >> Hi,
> >>
> >> Thanks for all of the discussion on this. We’ve reworked the requirement as follows:
> >>
> >> R-4
> >> To prevent routing loops, the relay SHOULD implement a configurable policy to
> >> drop client traffic as follows:  For point-to-point links, when the packet's
> >> ingress and egress interfaces match. For multi-access links, when the packet's
> >> ingress and egress interface match, and the source MAC and next-hop MAC addresses
> >> match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to
> >> destination) error message MAY be sent back to the client.  The ICMP policy
> >> SHOULD be configurable.
> >>
> >> Thanks,
> >> Ian
> >>
> >>> On 9. Oct 2020, at 17:41, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> >>>
> >>>
> >>> Jen Linkova <furry13@gmail.com> wrote:
> >>>> I think there is confusion re: the scenario we are talking about. I've
> >>>> attached the diagram for the case which concerns me.
> >>>> So:
> >>>> - The Relay R has an interface eth0 connected to a switch S.
> >>>> - Devices A and B are connected to the same switch and using R as a
> >>>> default gateway.
> >>>> - The prefix 2001:db8::/56 was delegated to a client A via the relay R.
> >>>
> >>> a friendly amendment to your example to aid in human comprehension:
> >>>    } - The prefix 2001:db8:0000:0123:/64 was delegated to a client A via the relay R.
> >>>    }  - R installs a route for 2001:db8:0000:0123:/64 towards A via eth0.
> >>>
> >>>> - The device B (which has an address NOT from the delegated prefix,
> >>>> but from another /64 assigned to that common link, let's sat
> >>>> 2001:db8:cafe::/64) sends a packet to an address from the delegated
> >>>
> >>> now, my brain can more clearly see that 2001:db8:cafe::/64 is not
> >>> within 2001:db8:0000:0123:/64, while I had to use a few extra brain cells to
> >>> see that it wasn't in that ::/56 :-)
> >>>
> >>>> What I'd expect to happen (with DHCP-PD or without - e.g. if R has a
> >>>> static route towards A, not a dynamic route produced by PD):
> >>>> - the packet is sent to A. Well, if A does not have a route to
> >>>> 2001:db8::42 then indeed a routing loop might happen. But if A does
> >>>> have a route, the packet will be delivered.
> >>>
> >>>> What seems to be required by R4:
> >>>> - R detects that the packet is received via eth0 and needs to be sent
> >>>> back to eth0. R4 seems to require such packets to be dropped.
> >>>> So if B would never be able to communicate to any address in the
> >>>> delegated prefix, right?
> >>>
> >>>> Am I missing anything?
> >>>
> >>> I think that you got it right.
> >>>
> >>>>> Perhaps the missing piece of the rule is don’t send it back to where it came from, based on link layer addresses (or link if point-
> to-
> >> point).
> >>>
> >>>> Yes. If R4 was saying 'drop the packet if it comes from the same
> >>>> link-layer address you are going to send it back' - it would make
> >>>> total sense. But I don't think routers do *that*.
> >>>
> >>> Yes, if we made the check on L2 address, then it would work.
> >>> And I agree that routers are exactly doing that.
> >>>
> >>> I think that it also works if B is a router with additional interfaces
> >>> downstream, unless there are multiple paths.
> >>>
> >>> --
> >>> 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
> >>> --------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> dhcwg mailing list
> >> dhcwg@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dhcwg