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

Ted Lemon <mellon@fugue.com> Tue, 13 October 2020 18:00 UTC

Return-Path: <mellon@fugue.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 E5B5B3A0CB9 for <dhcwg@ietfa.amsl.com>; Tue, 13 Oct 2020 11:00:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=fugue-com.20150623.gappssmtp.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 1GgXo7Rctki8 for <dhcwg@ietfa.amsl.com>; Tue, 13 Oct 2020 11:00:09 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 8DE233A0CB4 for <dhcwg@ietf.org>; Tue, 13 Oct 2020 11:00:09 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id k25so389775ioh.7 for <dhcwg@ietf.org>; Tue, 13 Oct 2020 11:00:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ABK2azN+DNvkG2xdSz9wdGrJU6ntdGVnuB8aB1CezpA=; b=Ybu32vVGp7KUYyaZ3mBA8u1L/b56P68dBclLjYdNKc2kQZM8afurACxbzaqpx/1b89 OHw4+tQrgv/bjJ+E4pK/GX0XwAI52oV+rNtEPHmqEcHMEBuYPp6qB27b+HKeON3pYXMo j9/96UFBYqd2RcWY/w+ZuaQC3AyZVHnMEGxlDukFaJF2VqTFMLXgt5vx9+NCO14ZGo4g 8w+f3yWestLVDrXIMZfHVLcj9DQwAG3rf3SLVVMFb2MCH5TLb/d39PKFvLQCs0W7hECe TNih+lXPvK74CiX+/YxA66XdDKqJ+t97VeE6yLN39RqS8V566EV9n/In6SvEvJ/70nTo 0enA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ABK2azN+DNvkG2xdSz9wdGrJU6ntdGVnuB8aB1CezpA=; b=SkhB5aCA9853kC0zKo6D5ZYlO8TyTU3mbU3Xn/0QSlWEA7gE3cOQVwh2vaYtI2botR 2HLQh9aIgGV0xYBnMyuM6fci+k94BJcdRdjsE/SHHW4gWgMBVEOP/ls59Fd2yFB6n3GO oZnT7Xtd3HrsdYDYQ4GTHNCafifUYNRw90epuoY8nmpa8x41yIVcn+ZT8lcEY3UNXZYW JAuPYIqEgAikea1Xh+y/Fg3RLPxsmNPR0GUvdFbIiDKQ15mIb6jrkV0G/v47i+2NTTUd W1+FQWMHM+q7+dwvLgH9w4yK7MQAsm6d7JWoc7QVCGskt5MPUWjGpDJ03j9fzB5NOYBt Wlzw==
X-Gm-Message-State: AOAM530JuG32/Z15unfQu5xPM79FLMDe6JdBdDdMwtcJJ1LS4SdCLOXA 4LTb4VE7f+5ziiGgFZsWw4VZoA==
X-Google-Smtp-Source: ABdhPJxbK5H/K9pgRZVL3gZRffqvZsdi7HHZFOoeOI6s9+Z1CwFMek8uFmjXx8xJAmf/aiOMJn6qEw==
X-Received: by 2002:a6b:8dca:: with SMTP id p193mr24172iod.77.1602612008058; Tue, 13 Oct 2020 11:00:08 -0700 (PDT)
Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id z20sm480900ior.2.2020.10.13.11.00.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 11:00:07 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <4478E969-8C25-46E1-9C21-B74189F23058@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F3D0D4E9-732B-4BA8-80CE-9FFD422A360A"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.82\))
Date: Tue, 13 Oct 2020 14:00:04 -0400
In-Reply-To: <378d3420690246bbae253fb15be8c9a7@boeing.com>
Cc: 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>
To: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com>
X-Mailer: Apple Mail (2.3654.0.3.2.82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/LBm6_e6eNfvbwGmrS9F0jDScjZ0>
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 18:00:12 -0000

Fred, according to RFC6221:

>    The LDRA MUST copy the IP source address from the client-originated
>    message into the peer-address field of the Relay-Forward message.
>    The LDRA MUST copy the link-layer source address from the client-
>    originated message into the link-layer source address of the Relay-
>    Forward message.

This is also true for the destination address. So if that is what my mean by an “L2 proxy,” I don’t think that the original MAC address would be hidden by it.

> On Oct 13, 2020, at 1:44 PM, 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
> 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
>> 
>> 
>> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg