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 17:44 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 4B20B3A0C44; Tue, 13 Oct 2020 10:44:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_H4=0.001, RCVD_IN_MSPIKE_WL=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 wzAc9HwWKjL2; Tue, 13 Oct 2020 10:44:36 -0700 (PDT)
Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 4BC7A3A0C43; Tue, 13 Oct 2020 10:44:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09DHiVt0021625; Tue, 13 Oct 2020 13:44:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602611074; bh=9O6RlLKBiVL9a/i/HRHNs+1X5gKeCX5zDidjUEvZMf0=; h=From:To:Subject:Date:References:In-Reply-To:From; b=EpEkl1HzvLVM335E19Gy40AvMtfS+AyElWaBdoEbONxAgGjDQ8xv0qTXgsNA2nQlj JWZAjxlijZ4ws19BqySyHG+tFLpCA6vurvd2qUB7tsklspcSR/dTxXi2GS2iBlOSme Y/qcshW3G4UIgUXEFjwHICoOj2JjJYui4tJBRpqsuPIbREWg2sJy56hgLAG/yh4tqB UzvrANDB2Pi7m279s6F50j3KwWFzQ78ZuICvvaqXfLh5PNDiHMXVi7W3WqWghu7KYz 5Tx6iN4pSWXvnXkkUGVJ+G5QCeMlzTrvm7YTKpTJiQLtshF97XKs1ozEu2bBpFgdqF 3WQ2q3rQhuf9A==
Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09DHiTIh021336 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 13:44:29 -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; Tue, 13 Oct 2020 10:44:27 -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 10:44:27 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "ianfarrer@gmx.com" <ianfarrer@gmx.com>, Jen Linkova <furry13@gmail.com>, dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@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: AdahZz7s2M1crQrvQoqZsITGBawESAAViWEAAA15P3A=
Date: Tue, 13 Oct 2020 17:44:27 +0000
Message-ID: <378d3420690246bbae253fb15be8c9a7@boeing.com>
References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost>
In-Reply-To: <10487.1602608586@localhost>
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: B3F8A8C1C34F44DB199A02F3082FB4FAE0AFB241DDCE0F6D2CC4A8BBEC46325E2000: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/Eu56cnwtfCOy-tAoHVh0Z7Wcwaw>
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 17:44:38 -0000

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
could be many clients A, B, C, D, etc. on downstream link segments of
the proxy, with the relay R on an upstream link segment. The relay would
then not see the individual client MAC addresses A, B, C, D, etc. - it would
see only the proxy MAC address P in all cases. So, it is true that an RPF
check in the relay would drop a packet from client A addressed to itself,
but it would also drop any of client A's packets addressed to clients B,
C, D, etc. That is what I meant by "failure" in this context.

Fred

> -----Original Message-----
> From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]
> Sent: Tuesday, October 13, 2020 10:03 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>om>; 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: [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:
>     >> 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.
> 
> okay, but let's be clear about what "failure" here means.
> If the client has multiple MAC addresses, then the router *fails* to
> eliminate the loop.  It does not drop traffic it shouldn't.
> So this policy doesn't make the situation worse.
> 
> I don't know what kind of relay you are talking about.
> If it's a L2 switching fabric, and it rewrites mac addressess, then there is
> a problem.
> 
> If it's an L3 router, then yes, the MAC address will change.
> But, that L3 router will *also* need a route to the client.
> That first L3 router should be the one dropping the traffic.
> 
>     > 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.
> 
> I agree that it should *also* be fixed on the client.
> 
> 1) The client will never do any forwarding if the the client has forwarding
>    turned off.
> 
> 2) There are many cases where there are legitimate reasons to have an
>    one-armed router like this.  So, whatever text you right must be sure that
>    the client is looking at the same packet, and not the IPsec transformed one.
>    (The Linux kernel does not make this trivial to get right, for instance)
> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>