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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 13 October 2020 17:03 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 6BB6B3A0A35; Tue, 13 Oct 2020 10:03:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 sWXjAAY5wG61; Tue, 13 Oct 2020 10:03:10 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6693B3A0A2C; Tue, 13 Oct 2020 10:03:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3E49438991; Tue, 13 Oct 2020 13:08:54 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id X6R2zw_S-2HZ; Tue, 13 Oct 2020 13:08:53 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E61733898F; Tue, 13 Oct 2020 13:08:52 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C3B5CA9A; Tue, 13 Oct 2020 13:03:06 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Templin \(US\)\, Fred L" <Fred.L.Templin@boeing.com>, "ianfarrer\@gmx.com" <ianfarrer@gmx.com>, Jen Linkova <furry13@gmail.com>, dhcwg <dhcwg@ietf.org>, v6ops list <v6ops@ietf.org>, 6man <ipv6@ietf.org>
In-Reply-To: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com>
References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Tue, 13 Oct 2020 13:03:06 -0400
Message-ID: <10487.1602608586@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/On0iJRM0w8zgJfxlbRpX2wBFuLU>
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: Tue, 13 Oct 2020 17:03:12 -0000

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