Re: [secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Wed, 04 December 2013 16:29 UTC

Return-Path: <manav.bhatia@alcatel-lucent.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 D367D1AE078; Wed, 4 Dec 2013 08:29:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 qJn7aeLL8UU8; Wed, 4 Dec 2013 08:29:26 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C1CDE1AE2B9; Wed, 4 Dec 2013 08:29:26 -0800 (PST)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rB4GTLvH011265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2013 10:29:22 -0600 (CST)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id rB4GTLgC028447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 11:29:21 -0500
Received: from SG70XWXCHHUB01.zap.alcatel-lucent.com (135.253.2.46) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 4 Dec 2013 11:29:21 -0500
Received: from SG70YWXCHMBA05.zap.alcatel-lucent.com ([169.254.5.101]) by SG70XWXCHHUB01.zap.alcatel-lucent.com ([135.253.2.46]) with mapi id 14.02.0247.003; Thu, 5 Dec 2013 00:29:18 +0800
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Brian Weis <bew@cisco.com>, "<secdir@ietf.org>" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: Secdir review of draft-ietf-ospf-rfc6506bis-03
Thread-Index: AQHO8JlV9WFla24GnUezZsX6mO0MTppEKSUA
Date: Wed, 04 Dec 2013 16:29:17 +0000
Message-ID: <20211F91F544D247976D84C5D778A4C32E5265AF@SG70YWXCHMBA05.zap.alcatel-lucent.com>
References: <8BA650DC-B09E-48D3-852A-129E4592E2B5@cisco.com>
In-Reply-To: <8BA650DC-B09E-48D3-852A-129E4592E2B5@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.253.19.17]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: "draft-ietf-ospf-rfc6506bis.all@tools.ietf.org" <draft-ietf-ospf-rfc6506bis.all@tools.ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-ospf-rfc6506bis-03
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: Wed, 04 Dec 2013 16:29:29 -0000

Hi Brian,

Thanks for the review. I have a comment inline.
> 
> But now RFC 5879 ("Heuristics for Detecting ESP-NULL Packets") has been
> published, which does describe some techniques to deterministically
> detect an unencrypted ESP packet. It may be still be difficult to
> prioritize certain OSPFv3 packets, but the justification is no longer
> precisely accurate. I would suggest something like the following
> rewording:

The justification still holds good as I don't think we will ever use heuristics for detecting ESP-NULL control packets that need to be consumed.

Its afaik primarily meant for firewalls that want to deep inspect packets. Obviously, there is nothing there in the standard that precludes it from being implemented on router's CPU path, but I doubt if we will ever go down that path. If this is really required on the routers, then WESP (RFC 5840) will probably be the path to go down on -- but that would require protocol extensions. 

Cheers, Manav

> 
>    Implementations desiring to prioritize certain OSPFv3 packet types,
>    e.g., Hello packets, over the other types, often perform the
>    prioritization prior to decryption. Parsing ESP packets is
> problematic
>    when the prioritization code does not know whether the ESP packets
>    include an encryption algorithm, or are instead ESP-NULL packets
> [RFC2410].
>    Techniques exist to identify ESP packets using ESP-NULL packets
>    [RFC5879], which would allow these packets to be examined  and
>    prioritized. However, the techniques may not be practically applied
>    within the prioritization code.
> 
> Brian