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

Warren Kumari <warren@kumari.net> Thu, 05 December 2013 19:28 UTC

Return-Path: <warren@kumari.net>
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 41C691AC829; Thu, 5 Dec 2013 11:28:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 N29_ZeasbcTm; Thu, 5 Dec 2013 11:28:14 -0800 (PST)
Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CCA1A802A; Thu, 5 Dec 2013 11:28:14 -0800 (PST)
Received: from [192.168.1.153] (unknown [66.84.81.107]) by vimes.kumari.net (Postfix) with ESMTPSA id CFA791B4061D; Thu, 5 Dec 2013 14:28:10 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Warren Kumari <warren@kumari.net>
In-Reply-To: <20211F91F544D247976D84C5D778A4C32E526C02@SG70YWXCHMBA05.zap.alcatel-lucent.com>
Date: Thu, 05 Dec 2013 14:28:09 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <A7238274-4657-4AA7-B776-E6D0037DE579@kumari.net>
References: <94A203EA12AECE4BA92D42DBFFE0AE470310EECD@eusaamb101.ericsson.se> <15E31E00-23FA-47A4-BE3D-705D4519D2F1@cisco.com> <20211F91F544D247976D84C5D778A4C32E526B66@SG70YWXCHMBA05.zap.alcatel-lucent.com> <E70E1BC9-F8CE-4F52-8575-F6275C7B56BE@kumari.net> <20211F91F544D247976D84C5D778A4C32E526C02@SG70YWXCHMBA05.zap.alcatel-lucent.com>
To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1510)
Cc: "<secdir@ietf.org>" <secdir@ietf.org>, "draft-ietf-ospf-rfc6506bis.all@tools.ietf.org" <draft-ietf-ospf-rfc6506bis.all@tools.ietf.org>, Acee Lindem <acee.lindem@ericsson.com>, The IESG <iesg@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: Thu, 05 Dec 2013 19:28:17 -0000

On Dec 4, 2013, at 8:38 PM, "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> wrote:

> Hi Warren,
> 
>> 
>> Well, you could punt all packet to the CPU and examine them to see it
>> they are important enough to be punted to... Oh! hang on a sec :-)
> 
> You cant do that. You look at the incoming packet at the line card, decide what internal priority and queue the packet should take via the fabric. So there is some level of deep inspecrion and differentiation that happens at line cards. Without knowing what the ESP packet is carrying, it's hard to assign it a meaningful priority. 
> 

Yup. That was the point I was (unsuccessfully) trying to make -- I guess the smiley was too subtle….

>> How about:
>> "While techniques exist to identify ESP-NULL packets
>>  [RFC5879], implementing these in line cards is not currently
>> feasible." ?
> 
> Sure, we can add something to this effect.

Cool.
W

> 
> Cheers, Manav
> 
>>> 
>>> Applying heuristics requires lot of flow information to be maintained,
>> which adds an additional complexity of flow maintenance (you need to
>> decide when a flow needs to be deleted if its not being hit often
>> enough) in the line cards.
>>> 
>>> There are many more points that go against the heuristics, especially
>> in the context that we're discussing here. If we are ever looking at
>> disambiguating ESP-NULL packets for router consumption, then I am pretty
>> sure it's going to be Wrapped ESP.
>>> 
>>> My point is that adding text about heuristics may just confuse the
>> reader who will most likely not understand the details of what it
>> entails to do heuristics on a line card. While you (being the Security
>> guru) and I (co-authored Wrapped ESP) understand that this is only
>> theoretically possible and practically will never make sense -- the same
>> cannot be assumed from somebody from the routing world, who is not so
>> security savvy, going through this standard.
>>> 
>>> Cheers, Manav
>>> 
>>> _______________________________________________
>>> secdir mailing list
>>> secdir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/secdir
>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>>> 
>> 
>> --
>> The duke had a mind that ticked like a clock and, like a clock, it
>> regularly went cuckoo.
>> 
>>    -- (Terry Pratchett, Wyrd Sisters)
>> 
> 

-- 
No man is an island, But if you take a bunch of dead guys and tie them together, they make a pretty good raft.
                --Anon.