IETF Logo Mail Archive

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

"Templin (US), Fred L" <Fred.L.Templin@boeing.com> Tue, 13 October 2020 18:57 UTC

Return-Path: <Fred.L.Templin@boeing.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 B07D63A10F9; Tue, 13 Oct 2020 11:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_MSPIKE_H2=-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=boeing.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 OcDT94Mq8b9C; Tue, 13 Oct 2020 11:57:38 -0700 (PDT)
Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8849D3A10DF; Tue, 13 Oct 2020 11:57:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09DIvWHV015977; Tue, 13 Oct 2020 14:57:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602615456; bh=lUzzD92RS2NRa3MOBCqzQhzRcf83Y8jmTSZO4TPghkg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=XuxvtHrDo53bnHrL+G0NMOux9hMnEjJCDFuxbplkSSUsPN+Cyfoq4GS8GweE8aCRo 42+1APV1F9f/5uR6OMUxe/SKsx7phD6A5/2CU+r3u+G6x/s5K//e5LOnX3Vw3S7Coo CY+h5UVMGZtlXMWaiYpp94Vd7Z9PHjR8rpM5mpINNOo9NDNEmM5DROnTsqaS3LXto0 t4eddWfSGu/Jqdd658eL/K4WoSMMDuw+T/qRXxcED3NiVXdu6NBE9HCj/UQnoYcFI2 bKJvpdH4NNqYUqg3hC6Z/U0kpRp13K9IzLLrNdxbsENDoC+Jh5GU8xOofz3hHDr9Bl uqkIRGnyZYLmw==
Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09DIvOc2014806 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 14:57:24 -0400
Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 13 Oct 2020 11:57:23 -0700
Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 13 Oct 2020 11:57:23 -0700
From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com>
To: Ted Lemon <mellon@fugue.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>
Thread-Topic: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements
Thread-Index: AQHWoZACP+11iV2gnk+uDowUHAjjrKmWU22A//+Lh0A=
Date: Tue, 13 Oct 2020 18:57:22 +0000
Message-ID: <d94b3649149c433ca6853f7c977aea65@boeing.com>
References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <4478E969-8C25-46E1-9C21-B74189F23058@fugue.com> <9428b888a7c046a38f85de8fcc260857@boeing.com> <9944583D-57D2-47D8-9A35-F5E9BCA3EE11@fugue.com>
In-Reply-To: <9944583D-57D2-47D8-9A35-F5E9BCA3EE11@fugue.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [137.137.12.6]
x-tm-snts-smtp: 1EF203FD0EA3D28B898830A8794F20C1BF92D990F91A937DE0096FE6CE86307D2000:8
Content-Type: multipart/alternative; boundary="_000_d94b3649149c433ca6853f7c977aea65boeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/Td7PD1Rfoh3fEtyAUbBC61v6pn4>
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:57:48 -0000

Ted – the proxy is not acting as an RFC6221 LDRA – that is not what is being implied.
In fact, let’s forget about LDRA because it is not really applicable to this discussion.

The case we have is that the proxy ‘P’ sees the link-layer address ‘C’ of the client
on a downstream link segment and sees the link-layer address ‘R’ of the relay on
an upstream link segment. When the client sends a DHCPv6 solicit, it will arrive at
the proxy which changes the source link-layer address from ‘C’ to ‘P’ before
forwarding (at layer-2) to the relay. The relay (however it is implemented) will
then see the DHCPv6 Solicit arriving with ‘P’ as the link-layer source address
and will know nothing about the client address ‘C’.

BTW, I am still waiting to hear how this concern is in any way specific to prefix
delegation, since it seems to be generic to any case of having a “stub” router
that maliciously attacks its own upstream link – no matter how that router
negotiates its prefixes with upstream network nodes.

Fred

From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Tuesday, October 13, 2020 11:42 AM
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>; ianfarrer@gmx.com; Jen Linkova <furry13@gmail.com>; dhcwg <dhcwg@ietf.org>; v6ops list <v6ops@ietf.org>; 6man <ipv6@ietf.org>
Subject: Re: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements


This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.




On Oct 13, 2020, at 2:38 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com<mailto:Fred.L.Templin@boeing.com>> wrote:
Think of the L2 proxy as a middlebox that occurs between the client and the relay (even
for the RFC6221 LDRA case). The client is on a “downstream link segment” of the proxy,
and the relay is on an “upstream link segment” of the proxy. When the LDRA running in
the same physical box as the relay gets the DHCPv6 Solicit message, the link-layer source
address it will see is ‘P’ (i.e., the upstream link segment address of the proxy).

If it’s an LDRA, and that’s the behavior, it’s not following the RFC. I can’t speak to other types of proxies, of course.

v2.23.0 | Report a Bug | By Email