[secdir] Secdir review of draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-10.txt

Catherine Meadows <catherine.meadows@nrl.navy.mil> Tue, 25 August 2009 22:00 UTC

Return-Path: <catherine.meadows@nrl.navy.mil>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCFB028C32E; Tue, 25 Aug 2009 15:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlJ4Reyq1Uv3; Tue, 25 Aug 2009 15:00:08 -0700 (PDT)
Received: from fw5540.nrl.navy.mil (fw5540.nrl.navy.mil [132.250.196.100]) by core3.amsl.com (Postfix) with ESMTP id A64E928C32F; Tue, 25 Aug 2009 15:00:08 -0700 (PDT)
Received: from chacs.nrl.navy.mil (sun1.fw5540.net [10.0.0.11]) by fw5540.nrl.navy.mil (8.13.6/8.13.6) with ESMTP id n7PM06aG028555; Tue, 25 Aug 2009 18:00:06 -0400 (EDT)
Received: from chacs.nrl.navy.mil (sun1 [10.0.0.11]) by chacs.nrl.navy.mil (8.13.6/8.13.6) with SMTP id n7PLxx30024915; Tue, 25 Aug 2009 18:00:03 -0400 (EDT)
Received: from gilgamesh.fw5540.net ([10.0.3.67]) by chacs.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2009082517595919456 ; Tue, 25 Aug 2009 17:59:59 -0400
Message-Id: <3DA42F93-811C-456E-983B-59102B9BB11F@nrl.navy.mil>
From: Catherine Meadows <catherine.meadows@nrl.navy.mil>
To: secdir@ietf.org, iesg@ietf.org, hongseok.jeon@gmail.com, maximilian.riegel@nsn.com, sjjeong@etri.re.kr, gmonte@microsoft.com
Content-Type: multipart/alternative; boundary="Apple-Mail-11-199974167"
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 25 Aug 2009 17:59:57 -0400
X-Mailer: Apple Mail (2.936)
Subject: [secdir] Secdir review of draft-ietf-16ng-ip-over-ethernet-over-802-dot-16-10.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 25 Aug 2009 22:00:09 -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 ID describes the transmission of IP4/IP6 over Ethernet in an  
access network deploying
IEEE 802.16.   Security is mentioned only in the Security  
Considerations section, which reads

This document does not introduce any new vulnerabilities to IPv4 and
    IPv6 specifications or operations.  The security of the IEEE 802.16
    air interface between SSs and BS is the subject of [802.16] and the
    security issues of Ethernet bridging are the subjects of [802.1D].
    The generic IP over Ethernet network using IEEE 802.16 emulates
    Ethernet link, since existing IPv4 and IPv6 security mechanisms over
    Ethernet can be still used.  While the public access network ensures
    secure isolation of each of upstream link between hosts and AR, it
    still adopts SEcure Neighbor Discovery (SEND) [RFC3971] for securing
    neighbor discovery processes and it does not introduce any new
    vulnerabilities over those of Ethernet bridging.

This I found very hard to draw any conclusions from, although that may  
be partly
because I don't have access to 802.16 or 802.1D.  However, I would  
like to see a little
more than just a blanket statement that this document does not  
introduce any new
vulnerabilities, e.g. some supporting information.  How are the  
security mechanisms
of IPv4 and IPv6 supposed to work together with those of 802.16? How  
do the security
issues of Ethernet bridging as described in 802.1D impact the security  
of IPv4 and IPv6?  I don't think
you need to go into a whole lot of detail here, since this is not the  
main focus of the document,
but I would like to see more evidence than this.  If there are other  
documents that address those
issues you can just point to them.

Cathy Meadows

Catherine Meadows
Naval Research Laboratory
Code 5543
4555 Overlook Ave., S.W.
Washington DC, 20375
phone: 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil