[secdir] Review of draft-ietf-hip-rfc5202-bis-05

Shawn M Emery <shawn.emery@oracle.com> Mon, 23 June 2014 06:03 UTC

Return-Path: <shawn.emery@oracle.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC331A01A5; Sun, 22 Jun 2014 23:03:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.451
X-Spam-Level:
X-Spam-Status: No, score=-3.451 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
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 Ci5MIOfRKFnP; Sun, 22 Jun 2014 23:03:23 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924AD1B2991; Sun, 22 Jun 2014 23:03:23 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s5N63L1s027535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jun 2014 06:03:22 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s5N63JuV028297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2014 06:03:20 GMT
Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s5N63IRG009983; Mon, 23 Jun 2014 06:03:19 GMT
Received: from [10.159.122.68] (/10.159.122.68) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 22 Jun 2014 23:03:18 -0700
Message-ID: <53A7C33A.9040202@oracle.com>
Date: Mon, 23 Jun 2014 00:03:38 -0600
From: Shawn M Emery <shawn.emery@oracle.com>
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140508 Thunderbird/17.0.11
MIME-Version: 1.0
To: secdir@ietf.org
References: <53389B18.9060305@oracle.com>
In-Reply-To: <53389B18.9060305@oracle.com>
Content-Type: multipart/alternative; boundary="------------090009040502040302020309"
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/fF49zc9n1BDZ1T9GBjhj4j0U5_8
Cc: draft-ietf-hip-rfc5202-bis.all@tools.ietf.org, iesg@ietf.org
Subject: [secdir] Review of draft-ietf-hip-rfc5202-bis-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 23 Jun 2014 06:03:25 -0000

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 standards track draft is intended to obsolete RFC 5202.  5202-bis
describes Host Identity Protocol (HIP) extensions which uses the Encapsulated
Security Payload (ESP) mechanism for the exchange of user data.

The security considerations section does exist and defers to ESP's (RFC 4303)
security considerations.  The section goes on to describe the security features
of the draft, but does not provide insight to what attacks are possible and how
the protocol extensions does or does not mitigate against said attacks.

General comments:

It would be easier to discern differences between the original RFC and bis
update if there was a section that described these changes.  This would be
beneficial to reviewers, such as myself, and implementers alike.

Editorial comments:

None.

Shawn.
--