Re: [secdir] Secdir review of draft-ietf-ospf-multi-instance

Acee Lindem <acee.lindem@ericsson.com> Tue, 20 December 2011 15:44 UTC

Return-Path: <acee.lindem@ericsson.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 5737B21F867F; Tue, 20 Dec 2011 07:44:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 HGni+mi5z0cY; Tue, 20 Dec 2011 07:44:18 -0800 (PST)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8116521F85DB; Tue, 20 Dec 2011 07:44:18 -0800 (PST)
Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBKFi8fO002715; Tue, 20 Dec 2011 09:44:09 -0600
Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.25]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 20 Dec 2011 10:44:03 -0500
From: Acee Lindem <acee.lindem@ericsson.com>
To: Magnus Nyström <magnusn@gmail.com>
Date: Tue, 20 Dec 2011 10:44:01 -0500
Thread-Topic: Secdir review of draft-ietf-ospf-multi-instance
Thread-Index: Acy/LjM2xBipeG47T9yYPtk4JOThuw==
Message-ID: <5B3F2069-57A3-47B6-9551-8F003EB6EE69@ericsson.com>
References: <CADajj4ZVy8vWxUDiFm5g=3_JYvBRsMaTNns+YaPqMd5LO43Fqw@mail.gmail.com>
In-Reply-To: <CADajj4ZVy8vWxUDiFm5g=3_JYvBRsMaTNns+YaPqMd5LO43Fqw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail-12-343774489"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Cc: "draft-ietf-ospf-multi-instance@tools.ietf.org" <draft-ietf-ospf-multi-instance@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-ospf-multi-instance
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, 20 Dec 2011 15:44:19 -0000

Hi Magnus, 

Thanks for the review. See inline. 

On Dec 12, 2011, at 3:10 AM, Magnus Nyström 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 describes a method for allowing multiple instances on
> the same domain in OSPFv2.
> 
> Since the Autype field in OSPFv2 will be halved by this document then
> one concern would have been if there were existing implementations
> using Autype values large enough to set bits in the higher octet.
> According to the authors this is not the case and so the risk of
> re-use of existing Autype values does apparently not exist.

Actually, values greater than 256 are reserved. We've only used two authentication types and we have a third in a WG draft. 

http://www.iana.org/assignments/ospf-authentication-codes/ospf-authentication-codes.xml

Since we made the decision a long time ago to make the authentication algorithm a property of the Security Association (SA) and not the authentication type, we do not anticipate many new authentication types in the future. 

> Conversely, when a router which does not understand this new use of
> the Autype field is presented with a packet from a router that is
> instance-aware (and uses a non-zero instance-id value) it will not
> accept it since it would represent an unknown authentication type. I
> would therefore tend to agree with the authors that the introduction
> of an InstanceID as part of the previous Autype field should not be a
> cause of concern.

Yes. 


> 
> Editorial:
> - Section 2: Unclear sentence: "In support of this capability, this
> document introduces a modified packet header format with the
> Authentication Type field is split into an Instance ID and AuType."
> (Probably the "is" should be removed/replaced)

Yes - I will update in the next revision. 

> 
> - Section 5: Refers to Appendix D but there is no Appendix D.
> Presumably the link should be to Appendix D of OSPFv2.

Yes - I will update this as well. 

I anticipate doing this next week as I'm off of work for the holidays. I will send a follow-up E-mail once it is posted. 

Thanks Again,
Acee 



> 
> -- Magnus