Re: [dhcwg] draft-ietf-dhc-relay-port-10 & Reconfigure

"Bernie Volz (volz)" <volz@cisco.com> Tue, 06 February 2018 18:27 UTC

Return-Path: <volz@cisco.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 D869112D868; Tue, 6 Feb 2018 10:27:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Level:
X-Spam-Status: No, score=-14.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 szY-0BedzKy6; Tue, 6 Feb 2018 10:27:39 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52AB127333; Tue, 6 Feb 2018 10:27:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27636; q=dns/txt; s=iport; t=1517941658; x=1519151258; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1tuKyoGYpEz/vfihf2TIrCeXA/E331ZSqogOlFr98CI=; b=BSrs8JgmOIEeQfwQmnd6XNF+rrW/BZUa6kPsOe+xH/hAFRshymRq2XGQ fD5KPxC81VU2dM8Wxe/TQt6eFVVHZaTiIwq1jDeXCuxk1oqsmwuZuRGxl 0v2s+CCzxuSCVlLWd5eJyvvU5HXtDJ0POTQp9rxF+NPh2AWkie/NaDeBP 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAADu8nla/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJZeGZwFRMKg1uKJI4xggKJE441FYIDCiOFGAIagkJUGAEBAQE?= =?us-ascii?q?BAQEBAmsohSMBAQEEIwo6EhACAQgRBAEBIQcDAgICHxEUCQgBAQQOBQiJSUwDF?= =?us-ascii?q?RC1H4Inhz0NgTGCBgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhGqCFYZtgmtEAQE?= =?us-ascii?q?CAYEyJi0fgmGCZQWaI4lNPgKIGIQDhFCEfpRFjXFIiRoCERkBgTsBHzmBUHAVg?= =?us-ascii?q?wOEd3iMQiyBBoEXAQEB?=
X-IronPort-AV: E=Sophos; i="5.46,469,1511827200"; d="scan'208,217"; a="67152674"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 18:27:38 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w16IRbmr022562 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Feb 2018 18:27:37 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 6 Feb 2018 12:27:37 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1320.000; Tue, 6 Feb 2018 12:27:36 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "Naiming Shen (naiming)" <naiming@cisco.com>
CC: "dhcwg@ietf.org" <dhcwg@ietf.org>, "draft-ietf-dhc-relay-port@ietf.org" <draft-ietf-dhc-relay-port@ietf.org>, Suresh Krishnan <suresh.krishnan@gmail.com>
Thread-Topic: draft-ietf-dhc-relay-port-10 & Reconfigure
Thread-Index: AdOfY6gaEFANtBC7Rt+MHUK/8rJcBwAQJRAAAAtogiA=
Date: Tue, 6 Feb 2018 18:27:36 +0000
Message-ID: <7d17cee12a5f48a89ac29b841c8f4d89@XCH-ALN-003.cisco.com>
References: <a1104b1b903d4e319c59c1459dbfd701@XCH-ALN-003.cisco.com> <599A596D-0213-4F67-9391-B6E6217B1806@cisco.com>
In-Reply-To: <599A596D-0213-4F67-9391-B6E6217B1806@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.131.34.37]
Content-Type: multipart/alternative; boundary="_000_7d17cee12a5f48a89ac29b841c8f4d89XCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/tV7nl7rUoiYoHKyI_5OlTFbB5cs>
Subject: Re: [dhcwg] draft-ietf-dhc-relay-port-10 & Reconfigure
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
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, 06 Feb 2018 18:27:41 -0000

Yes, as -10 is written it requires the server record that a non-standard port was in use.

This also has an impact to Failover protocol (RFC 8156) and Leasequery (RFC 5007), as there is no carrier defined for this data.

For our server, I’m thinking we’ll avoid adding yet something else to save this data and instead store it in the outermost (closet to server) Relay-Forw “Downsteam Source Port” field (which would normally have 0 in it). That way, it is also available to Leasequery (perhaps a bit non-standard but better than defining more options).

I still think it would be much better to change:

      Downstream Source Port:  16 bit value.  To be set by the IPv6
               relay either to the downstream relay agent's UDP source
               port used for the UDP packet, or to zero if only the
               local relay agent uses the non-DHCP UDP port (not 547).

To:


      Downstream Source Port:  16 bit value.  To be set by the IPv6

               relay either to the downstream relay agent's UDP source

               port used for the UDP packet, or to the port used by the

               local relay agent if it does not use port 547.


That way, the port value is already there.

For DHCPv4, I’m less concerned about this (mostly because almost no one uses ForceRenew with that). But even there it would be nice if the option just stored the port number.

If we’re concerned about security, you would always add: “A relay or server MAY validate that the port number in the option matches the source port on which the packet was received and discard the received message is not.”


-          Bernie

From: Naiming Shen (naiming)
Sent: Tuesday, February 06, 2018 12:43 PM
To: Bernie Volz (volz) <volz@cisco.com>;
Cc: dhcwg@ietf.org; draft-ietf-dhc-relay-port@ietf.org; Suresh Krishnan <suresh.krishnan@gmail.com>;
Subject: Re: draft-ietf-dhc-relay-port-10 & Reconfigure


Hi Bernie,

This can be a server implementation also, as long as the server saves the encapsulated
relay stack on the client’s record. My thinking is this, some other relay options may also needs
to be saved in order for Reconfigure message through the relays to work properly.

thanks.
- Naiming

On Feb 6, 2018, at 8:05 AM, Bernie Volz (volz) <volz@cisco.com<mailto:volz@cisco.com>> wrote:

One issue that sadly was not addressed in https://tools.ietf.org/html/draft-ietf-dhc-relay-port-10 is what to do about Reconfigure message. There are two ways to deliver Reconfigure messages:

1.       Via the relay
2.       Via unicast to the client

If #1 is used (perhaps because the client and server do not have direct communication because of VPNs or for other reasons), what should the server do? Options are:

1.       Always use the standard port (547).
2.       Record the relay port and use that (since the relay will also be used). I would assume that this would be the “correct” behavior?

I’m not sure if we should (or can) put a hold on RFC-to-be to add something about this?

BTW: This would also have been a good reason to put the port number into the option ALWAYS. This avoids the server from having to record something “else” (the port number), since the server can just extract the value from the outermost (closest to server) Relay Port option.

-          Bernie