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

Timothy Winters <tim@qacafe.com> Mon, 21 September 2020 12:19 UTC

Return-Path: <tim@qacafe.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 EB5B13A0D69 for <dhcwg@ietfa.amsl.com>; Mon, 21 Sep 2020 05:19:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 (1024-bit key) header.d=qacafe.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 tWvh7BHBJez3 for <dhcwg@ietfa.amsl.com>; Mon, 21 Sep 2020 05:19:19 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 4FB7A3A0D64 for <dhcwg@ietf.org>; Mon, 21 Sep 2020 05:19:19 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id q8so13749826lfb.6 for <dhcwg@ietf.org>; Mon, 21 Sep 2020 05:19:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rolGCgDtzVe4w4eVqH9u0UEvbokVg8ISSTb1J0eBP+g=; b=GqqUoTwrhHofhHkGJifZ8UB/d+u0mSXonMO1XZEqV1I+buxDkdhdcCeYYgkadVmkhA dsN0k34FGJ34po0lliM8q675ZwyzUkC0LDhQFa5dvoY+o2cIcaLu767/Fos3D1r7Hf7r VDyz5mRdbjG0uV3urVVLoFmKE8//GWKeh/Tow=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rolGCgDtzVe4w4eVqH9u0UEvbokVg8ISSTb1J0eBP+g=; b=ij6nlAhB8fKkR6Ee+U5dXWE1RgUVcOoMHjmaPy9Rsly3q3rgscm3Ul4pAbiBwgynUA d68shk9nq0vECaxDx7SNKh2QyR3JChFZDfpu7PWViXqUybVLJ67I6dl2xqm/wijtLoIu yaUd0MWfvPpvC9MniX1HJMHHReH7XWbvvq+eC1JyNNx+58VB9M6jooyEmCTYGdvhgVv4 HZC4Vqhuz11lTdcCyp32/Z6zkF1//pG9kMN2nJVF/QgrJ6RMKZwANo66FLfY2ibAwztZ KL+4lAUPk8/3xqRfgDfiyedGa4kkcfwc7Lf+nI2yfhEr5moYcRRMe3wdUidkk7tQmjTG chNw==
X-Gm-Message-State: AOAM530zhghd3s26wc/ChBxPc+EnHpuiANcFJ2MtFV9H4qdVE+bm6Jyg V8aa6zZ+QcRs44JnBQOg8HM34p80QgsQt8MDUfDsxw==
X-Google-Smtp-Source: ABdhPJzYt3uQriYkeGBkaeUmeqdTgvfnhKaS8/oOtIOjST50Uj3XrRtEGdNela/GbaItmSFaRll5ECWpV8IgU+tnuxo=
X-Received: by 2002:a19:4b84:: with SMTP id y126mr13659756lfa.360.1600690757053; Mon, 21 Sep 2020 05:19:17 -0700 (PDT)
MIME-Version: 1.0
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> <D7610587-E894-46D9-B3FC-18EF2B90D788@employees.org> <9E774175-356D-4E72-A3BF-3ACCA41A14FD@gmx.com> <BN7PR11MB2547BFE20F174B974D0442F5CF3E0@BN7PR11MB2547.namprd11.prod.outlook.com> <CANFmOtnp2zY9CLQDDjhOmkOiZGMvC2goz4pYhjetErFSpeooWQ@mail.gmail.com> <804782AC-6400-4ECA-B8D5-77F205E77327@cisco.com>
In-Reply-To: <804782AC-6400-4ECA-B8D5-77F205E77327@cisco.com>
From: Timothy Winters <tim@qacafe.com>
Date: Mon, 21 Sep 2020 08:19:06 -0400
Message-ID: <CAJgLMKvwPuVDAmJPApGOeSkq-YYU6X7rtNO960V75udquRf-gA@mail.gmail.com>
To: "Bernie Volz (volz)" <volz=40cisco.com@dmarc.ietf.org>
Cc: Naveen Kottapalli <naveen.sarma@gmail.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f8473705afd1db35"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/JAyHVritbiK9VsKk9B6bA5zsm9E>
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: Mon, 21 Sep 2020 12:19:23 -0000

As Bernie mentioned we discussed this recently.  I was under the impression
that this requirement was to prevent a forwarding loop when the CPE/Relay
don't have the same information.  For example,

   1.  the CPE has forgotten or lost the PD given to it.
   2. The Relaying Router will continue to forward traffic to the CPE.
   3. Since the CPE doesn't have the PD it will use it's default route
   (Relay Router)
   4. Relay Router will forward the traffic back to the CPE.
   5. Forwarding Loop until PD happens.

If this is what we are trying to prevent I think we might want to keep this
in.  I have seen situations were the CPE can't get a PD due to network
congestion in this state.

~Tim

On Fri, Sep 18, 2020 at 2:02 PM Bernie Volz (volz) <volz=
40cisco.com@dmarc.ietf.org> wrote:

> In our co-chair call today, Tim and I dicussed this and he should be
> sending some comments which may help with the issue. Please wait for those
> before making changes.
>
> - Bernie
>
> On Sep 18, 2020, at 1:09 PM, Naveen Kottapalli <naveen.sarma@gmail.com>
> wrote:
>
> 
> Hello Bernie,
>
> As suggested we are of opinion that the requirement will be dropped.
>
> Yours,
> Naveen.
>
>
> On Thu, 17 Sep 2020 at 21:55, Bernie Volz (volz) <volz=
> 40cisco.com@dmarc.ietf.org> wrote:
>
>> Hi:
>>
>> One thing to ask is whether this issue is worth continuing debate on this
>> document? Removing it would probably let the document move forward ...
>>
>> Regarding your answer Ian: [if - The 2 cases would be a bug in the HGW
>> (prefix delegated but routing table not updated so default route is still
>> used), or an attack where rogue clients deliberately send this traffic.]
>>
>> - An attacker could always send lots of traffic; sure if it is sent back
>> by the relay router, it causes more traffic but eventually the hop limit
>> will be hit and the packet will be dropped. Though wouldn't fixing this at
>> the CPE router (which this document does not cover) be a better place to
>> fix it?
>> - If there's a bug, perhaps better to learn about it earlier and get it
>> fixed? Someone might notice if they see their throughput drop?
>>
>> I'm still wondering what a normal router would do in this case and why
>> this needs to be different than general router behavior? Also, could the
>> CPE use this to test connectivity over the WAN link (i.e., send a packet to
>> itself using an address in the PD expecting it to be looped back by the
>> next hop (relay) router)?
>>
>> And, is this something that someone has actually seen occur, or just a
>> theoretical issue that could happen.
>>
>> - Bernie
>>
>> -----Original Message-----
>> From: ianfarrer@gmx.com <ianfarrer@gmx.com>
>> Sent: Thursday, September 17, 2020 11:17 AM
>> To: Ole Troan <otroan@employees.org>
>> Cc: Bernie Volz (volz) <volz@cisco.com>om>; dhcwg@ietf.org
>> Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-pd-relay-requirements
>> - respond by August 17th, 2020
>>
>> Hi,
>>
>> Please see inline.
>>
>> Thanks,
>> Ian
>>
>> > On 15. Sep 2020, at 14:31, otroan@employees.org wrote:
>> >
>> > 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?
>>
>> [if - The 2 cases would be a bug in the HGW (prefix delegated but routing
>> table not updated so default route is still used), or an attack where rogue
>> clients deliberately send this traffic.]
>>
>> >
>> >>> 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
>>
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
>>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>