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

Naveen Kottapalli <naveen.sarma@gmail.com> Fri, 18 September 2020 17:08 UTC

Return-Path: <naveen.sarma@gmail.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 26D273A131B for <dhcwg@ietfa.amsl.com>; Fri, 18 Sep 2020 10:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=gmail.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 8bx-_yrxTMjc for <dhcwg@ietfa.amsl.com>; Fri, 18 Sep 2020 10:08:12 -0700 (PDT)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 7AA933A12A8 for <dhcwg@ietf.org>; Fri, 18 Sep 2020 10:07:59 -0700 (PDT)
Received: by mail-il1-x12c.google.com with SMTP id q5so382632ilj.1 for <dhcwg@ietf.org>; Fri, 18 Sep 2020 10:07:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ugjvVO+gJPXxHsxeu3H5V0Jbm9WfR2n7CD5oi1sApqg=; b=RiEDjGN0XJka3JoeM+cjVyqph5uBxruJhYwwINr4MP1Hai8hCfTlGANzgzOj0DBbpv /2+MPZ6kElpF6WzC+sew+4j7Aak9H1u7aaAgIIRnvZrHgZwKf1oOWdT7UbN5JE+Gn3fS IK7oYMs2jmn1aeQRKvVP9cNDxLjF+MzvZWEZnh/LVDRbfWUgcNdz4sBBOO/jnGRouhz4 S5GHEIxIBLki82HGLJtLgBc9VW5FsSB+xN+1X7a4Zitv4jND0eABfSGr3LseYmerxeTI bJemsT27pty33dxONgO5+O81UtzJ7Ef4I1hUj3DnxTsLdVMnXLKnuwg9AzrPG5IozEsg yORQ==
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=ugjvVO+gJPXxHsxeu3H5V0Jbm9WfR2n7CD5oi1sApqg=; b=aXk4T5v4p4CQg/mZShI5ONlntQNHhM2KGVicSiG8Soz8SR8K2r2PZ+fDtM0enZ69nt 1JBs9Es4l9zmxNb76Na0cCqXTvFiQw+cXhw5poKiygskLIXYlkP+D86yVvxuvQDo5N0+ LYpNo+b5DKwGdB5ncSG0TyJMbTaUkQX/tAzQwFWz3ck+Dh5uGWibyTxQLI+ImsVaYZFb WF1JCA4TS8DxIyXL+yLNqmKi5jsyEWVcNamMGRcC6bl5GabABqfNtQHOVvnsKim2UnPW 5yEx1XwWKPD3GI6D63rcZ4uNUai5n8Z3ZWWPSmCOd7q9U1xaAP8w8Q61ZXh9FwJyLQGO ECaA==
X-Gm-Message-State: AOAM532BMK0ZgU1wmCkFX+SQxmoRzpM4OIM5bQ8SX+llMy4ocVX+XImQ 7MayWkh+Zw63RBGqVlnInoCwhaBcyBAkQf4Dd5GbaZ5HdNI=
X-Google-Smtp-Source: ABdhPJwfpqIceRK89Q4QGnUpnG+RitDU1gzXhJVe/pa1wCwtUEJ/p8kbCuePMGsQis6+jIkVN5jNZcceEqOjdXkRHMQ=
X-Received: by 2002:a05:6e02:4cf:: with SMTP id f15mr147895ils.201.1600448878505; Fri, 18 Sep 2020 10:07:58 -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>
In-Reply-To: <BN7PR11MB2547BFE20F174B974D0442F5CF3E0@BN7PR11MB2547.namprd11.prod.outlook.com>
From: Naveen Kottapalli <naveen.sarma@gmail.com>
Date: Fri, 18 Sep 2020 22:37:47 +0530
Message-ID: <CANFmOtnp2zY9CLQDDjhOmkOiZGMvC2goz4pYhjetErFSpeooWQ@mail.gmail.com>
To: "Bernie Volz (volz)" <volz=40cisco.com@dmarc.ietf.org>
Cc: "ianfarrer@gmx.com" <ianfarrer@gmx.com>, Ole Troan <otroan@employees.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e2731a05af998a03"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/cj_pmor1RrIkQSasd-l6oMqn4PA>
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: Fri, 18 Sep 2020 17:08:20 -0000

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
>