[secdir] secdir review of draft-ietf-geopriv-dhcp-lbyr-uri-option-17

Chris Lonvick <clonvick@cisco.com> Sat, 02 February 2013 11:43 UTC

Return-Path: <clonvick@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 6BD5121F900E; Sat, 2 Feb 2013 03:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFFM+XNKwZ9v; Sat, 2 Feb 2013 03:43:13 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A6A0F21F8D8F; Sat, 2 Feb 2013 03:43:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1541; q=dns/txt; s=iport; t=1359805393; x=1361014993; h=date:from:to:subject:message-id:mime-version; bh=Y5DASA6fHxusEieINR9SrRW3+A/O0+mbxDhJojshTA0=; b=NjtOsZ1+M0/rdBY7sIH0cYXKQSuWG4b6N8XAoo6irgSOlvz6cVdWEKIZ VyVOURYtPKNS7R5V8ixBf6p96ASAV+Cg6QBweupVgazsoq1Tig2d8S7nq +jahsBEbZrlBljrh7/aM1JKFsfLkkVTk7yIXXvPZuqtoGPTjwpsvPnBIT 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAIr6DFGrRDoI/2dsb2JhbABFvzgWc4JeAoF+iCLCJ5FSA4hmngqDHQ
X-IronPort-AV: E=Sophos;i="4.84,590,1355097600"; d="scan'208";a="70244735"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 02 Feb 2013 11:43:07 +0000
Received: from sjc-xdm-114 (sjc-xdm-114.cisco.com [171.71.188.119]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r12Bh65d012385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Feb 2013 11:43:06 GMT
Date: Sat, 2 Feb 2013 03:43:06 -0800 (PST)
From: Chris Lonvick <clonvick@cisco.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-geopriv-dhcp-lbyr-uri-option.all@tools.ietf.org
Message-ID: <alpine.LRH.2.00.1302020217490.25446@sjc-xdm-114.cisco.com>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Subject: [secdir] secdir review of draft-ietf-geopriv-dhcp-lbyr-uri-option-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Sat, 02 Feb 2013 11:43:14 -0000

Hi,

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.

This is actually a re-review of this document.  It appears that James 
addressed most of my editorial comments from that review and I'm happy 
with the results.

James has separated out the components of the option described in -15 (the 
one I had previously reviewed) into two options in this document.

Overall, I see where he's going with this and again I have no overall 
problems.  Some editorial things:

- I would like to see some discussion of the potential misuse of the 
Valid-For option in the Security Considerations section.  This could be a 
simple pointer to section 2.5 but I do feel that should be explicitly 
called out in the Security Considerations.

- I would like to see some discussion of the expected bounds of the 
Valid-For option value.  There is no guidance on what could or should be 
provided by the client, nor on what should be expected by the server. 
This just makes me a bit nervous.  :-)

- I couldn't find any reason why the components needed to be separated 
into two different options.  I'm sure that there is a good reason for it 
so having an explanation would help.  If it's in there, then I just missed 
it.

Best regards,
Chris