Re: [secdir] secdir review of draft-ietf-netext-pmip-lr-08

Carl Wallace <carl@redhoundsoftware.com> Tue, 06 March 2012 13:47 UTC

Return-Path: <carl@redhoundsoftware.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 33F9D21F87CC for <secdir@ietfa.amsl.com>; Tue, 6 Mar 2012 05:47:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1YrzQ-wb-aw for <secdir@ietfa.amsl.com>; Tue, 6 Mar 2012 05:47:15 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 52F5B21F87EB for <secdir@ietf.org>; Tue, 6 Mar 2012 05:47:14 -0800 (PST)
Received: by vbbez10 with SMTP id ez10so5062825vbb.31 for <secdir@ietf.org>; Tue, 06 Mar 2012 05:47:13 -0800 (PST)
Received-SPF: pass (google.com: domain of carl@redhoundsoftware.com designates 10.52.99.169 as permitted sender) client-ip=10.52.99.169;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of carl@redhoundsoftware.com designates 10.52.99.169 as permitted sender) smtp.mail=carl@redhoundsoftware.com
Received: from mr.google.com ([10.52.99.169]) by 10.52.99.169 with SMTP id er9mr41076251vdb.126.1331041633758 (num_hops = 1); Tue, 06 Mar 2012 05:47:13 -0800 (PST)
Received: by 10.52.99.169 with SMTP id er9mr35198176vdb.126.1331041633656; Tue, 06 Mar 2012 05:47:13 -0800 (PST)
Received: from [192.168.1.4] (pool-173-79-133-63.washdc.fios.verizon.net. [173.79.133.63]) by mx.google.com with ESMTPS id e18sm17928555vdh.20.2012.03.06.05.47.11 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 05:47:12 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.14.0.111121
Date: Tue, 06 Mar 2012 08:47:06 -0500
From: Carl Wallace <carl@redhoundsoftware.com>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
Message-ID: <CB7B7F3B.1472A%carl@redhoundsoftware.com>
Thread-Topic: secdir review of draft-ietf-netext-pmip-lr-08
In-Reply-To: <4F4EF893.1060201@ericsson.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Gm-Message-State: ALoCoQkFgZszZR/uElrUbQEXvG+9vu4aqqFgBb4iLmDi0npWZNrS3246SUDz1GyUCDwenmOI4pSY
Cc: "draft-ietf-netext-pmip-lr.all@tools.ietf.org" <draft-ietf-netext-pmip-lr.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-netext-pmip-lr-08
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: Tue, 06 Mar 2012 13:47:15 -0000

It's probably more a style thing than anything else.  I don't like to see
requirements introduced in the security considerations section.  I do not
feel particularly strongly about this though.

On 2/29/12 11:18 PM, "Suresh Krishnan" <suresh.krishnan@ericsson.com>
wrote:

>Hi Carl,
>  Thanks for your review. I will add the reference to RFC4832 like you
>stated. Is there a specific reason why you prefer the security related
>text be moved to the body of the document instead of the Security
>Considerations section?
>
>Regards
>Suresh
>
>On 02/28/2012 08:00 AM, Carl Wallace 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.
>> 
>> 
>> This document proposes initiation, utilization and termination
>>mechanisms
>> for localized routing between mobile access gateways within a proxy
>>mobile
>> IPv6 domain.  The security considerations section introduces (for this
>> document) the requirement for IPSec and the reuse of a security
>> association described in RFC 5213.  This text belongs in the body of the
>> document in my opinion, with the security considerations possibly
>>changed
>> to simply reference RFC 4832 and RFC 5213 security considerations.
>> 	
>> 
>> 
>