Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020

otroan@employees.org Tue, 15 September 2020 12:31 UTC

Return-Path: <otroan@employees.org>
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 6C5C13A0F32 for <dhcwg@ietfa.amsl.com>; Tue, 15 Sep 2020 05:31:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 huLaQ4aE9VaD for <dhcwg@ietfa.amsl.com>; Tue, 15 Sep 2020 05:31:38 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93413A0F2F for <dhcwg@ietf.org>; Tue, 15 Sep 2020 05:31:38 -0700 (PDT)
Received: from astfgl.hanazo.no (76.84-234-131.customer.lyse.net [84.234.131.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id C97A94E11B81; Tue, 15 Sep 2020 12:31:37 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id C015D3D64F3D; Tue, 15 Sep 2020 14:31:32 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: otroan@employees.org
In-Reply-To: <7358EA97-7E61-45CB-8D32-3AF405B60768@gmx.com>
Date: Tue, 15 Sep 2020 14:31:32 +0200
Cc: Bernie Volz <volz@cisco.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D7610587-E894-46D9-B3FC-18EF2B90D788@employees.org>
References: <BN7PR11MB254783295780CA79CDA1FAB3CF4F0@BN7PR11MB2547.namprd11.prod.outlook.com> <BN7PR11MB254779A3599EFC466605CD92CF450@BN7PR11MB2547.namprd11.prod.outlook.com> <BN7PR11MB25477ED8552DF78132E2F089CF5F0@BN7PR11MB2547.namprd11.prod.outlook.com> <DFF9367A-5D78-4795-988A-FCD37F3C6377@employees.org> <BN7PR11MB25472678D6ACAB82912141A6CF5C0@BN7PR11MB2547.namprd11.prod.outlook.com> <C503DF9C-7798-43A3-9E7F-7D7E09B0D98B@gmx.com> <BN7PR11MB25475DCDA3E215609BF3D8F5CF260@BN7PR11MB2547.namprd11.prod.outlook.com> <263B0965-AF60-4008-B55C-AF9803EB419F@gmx.com> <BN7PR11MB25473F7EBE67E1B51DE7AD46CF230@BN7PR11MB2547.namprd11.prod.outlook.com> <A2A9F390-5B5A-4DAC-9E8A-7F6BA51F7ECB@employees.org> <7358EA97-7E61-45CB-8D32-3AF405B60768@gmx.com>
To: ianfarrer@gmx.com
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/50nDNDRCxvaOlSRpomMOU7n_dLw>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements - respond by August 17th, 2020
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, 15 Sep 2020 12:31:40 -0000

Ian,

> [if - There’s been quite a lot of iterations on this since -01. The current working version is:
> 
> R-4:
> If the relay has learned a route for a
> delegated prefix via a given interface, and receives traffic
> on this interface with a destination address within the
> delegated prefix (that is not an on-link prefix for the relay),
> then it MUST be dropped.  This is to prevent routing loops.
> 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.]
> 
>> 
>> 
>> Two questions:
>> 
>> 1) What is the case where this would triggered? That wouldn't be caught by uRPF (R-2)?
> 
> [if - The traffic is originated from a valid source prefix so uRPF (R-2) doesn't cover it. This requirement is concerned with the destination.]

Would you mind ellaborating on how exactly the setup (or attack) would be constructed for this to happen?

>> 2) On a multi-access link, how should this even be implemented?
>>  drop if rx-interface == tx-interface and packet source mac == next-hop mac?
> 
> [if - That sounds like it would cover it.]

I think it would be useful to get implementors to chime in how practical this is to implement.

>> - Is it supposed to be a silent discard or should you send a destination unreachable?
> 
> [if - Please see current text above.]

Ack.

Best regards,
Ole