Re: [secdir] secdir review of draft-ietf-dhc-relay-port-06

"Naiming Shen (naiming)" <naiming@cisco.com> Fri, 27 October 2017 18:53 UTC

Return-Path: <naiming@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D0513F3E6; Fri, 27 Oct 2017 11:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 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, 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 PWOmsEQ3KI1V; Fri, 27 Oct 2017 11:53:38 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914C913D179; Fri, 27 Oct 2017 11:53:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6722; q=dns/txt; s=iport; t=1509130418; x=1510340018; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lIBVT9UOP/kYyxSwLstqGiM87BTW6SWgo+KC5oSluok=; b=C6KFTPhFdteJEOkLVXCXPTrojwFSG7lrprX9or6I2nF2T6gpa3fMj+Gy J/EqAnxCFbfpcitWZ66wDhFByAF56wLFM12ym4IDRJdqnS2/lIG1IWflS 25IMrsDsEmIWNBV1a38QCpsu8YLz/WGhB0xdQaXoFWCr90kTkkIsU0bNR M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AAACgPNZ/5ldJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg19kbicHjhKPFJJ3hUWCEQojhRgChEs/GAECAQEBAQEBAWsohR4?= =?us-ascii?q?GeRACAQg/BzIUEQIEDgWJP2QQqziKagEBAQEBAQEBAQEBAQEBAQEBAQEBARgFg?= =?us-ascii?q?y6CB4M5KYMBhG+DWoIyBZkCiQEClHqCFYoDhxWVYwIRGQGBOAEfOIFoehV2AYI?= =?us-ascii?q?2hF93AYpTgREBAQE?=
X-IronPort-AV: E=Sophos;i="5.44,305,1505779200"; d="scan'208,217";a="313220176"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2017 18:50:58 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v9RIow3m017075 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 27 Oct 2017 18:50:58 GMT
Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 27 Oct 2017 13:50:58 -0500
Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Fri, 27 Oct 2017 13:50:58 -0500
From: "Naiming Shen (naiming)" <naiming@cisco.com>
To: "Scott G. Kelly" <scott@hyperthought.com>
CC: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-dhc-relay-port.all@tools.ietf.org" <draft-ietf-dhc-relay-port.all@tools.ietf.org>
Thread-Topic: secdir review of draft-ietf-dhc-relay-port-06
Thread-Index: AQHTTOkcXv7OQr8l1Eym+7B0D2tfN6L4YwoA
Date: Fri, 27 Oct 2017 18:50:57 +0000
Message-ID: <52A67135-4F66-47B7-B9C2-85477B6E7077@cisco.com>
References: <1508861901.825516724@apps.rackspace.com>
In-Reply-To: <1508861901.825516724@apps.rackspace.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.92.136]
Content-Type: multipart/alternative; boundary="_000_52A671354F6647B7B9C285477B6E7077ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/sRYuE1VA3MuYJLBoBOYJfhEpN9s>
Subject: Re: [secdir] secdir review of draft-ietf-dhc-relay-port-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Oct 2017 18:53:41 -0000

Hi Scott,

Thanks for the review of this draft. To answer the question in your last paragraph,
Yes, the scheme does not that, or any combination of that. I have included two
more paragraph in the new version trying to demonstrate that along with the
existing example.

The new version just posted:

https://www.ietf.org/id/draft-ietf-dhc-relay-port-07.txt

Best Regards,
- Naiming

On Oct 24, 2017, at 9:18 AM, Scott G. Kelly <scott@hyperthought.com<mailto:scott@hyperthought.com>> wrote:

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

The summary of the review is "ready" with minor editorial nits.

>From the abstract, this document proposes an extension to the DHCP protocols that allows a (DHCP) relay agent to receive packets from a server or an upstream relay agent on any UDP port, not just the default port 67 for IPv4 or default port 547 for IPv6.

Paraphrasing, it allows a relay agent to use any available source port for upstream communications, and to include a DHCP option that can be used to statelessly route responses back to the appropriate source port on downstream communications.

The security considerations section references [RFC3118] and [RFC3315], and adds that any firewalls in the path may need reconfiguration to allow DHCP flows from non-fixed addresses. I don't have anything to add, though I think that section could benefit from a little word-smithing. I'll defer to the RFC editor on that.

The draft is clear, though a simple ascii diagram illustrating a client, relay, and server (including src/dst ports) might help readers to more immediately understand what this looks like topologically. I read it through, and then went back and drew myself a picture as I read, and that helped. Just a thought.

One minor (non-security) question I had: section 6 illustrates a cascaded IPv6 example wherein Relay1 is using a non-standard port, but Relay2 is not. What happens if both Relay1 and Relay2 are using non-standard source ports? Is this allowed? If not, you might want to call this out. If so, it might be good to describe a general case of n relays with m non-standard source ports.

--Scott