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

Brian Weis <bew@cisco.com> Thu, 05 December 2013 19:51 UTC

Return-Path: <bew@cisco.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 830671A802A; Thu, 5 Dec 2013 11:51:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 DhnOR7nfNS9D; Thu, 5 Dec 2013 11:51:08 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCEA1A16F0; Thu, 5 Dec 2013 11:51:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2988; q=dns/txt; s=iport; t=1386273065; x=1387482665; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8WwhKLA/qbQ/a70b3P7B6edTPnRIqW5ohI9Rdj4QxnY=; b=ZeKxZifw0eq9jE4nlYxoxjiGh7lOMFTavHriJlEaOe7iO35kB6+O9leN wZ0cBV0otx+y7Gw9KvAIuda40an3gmkneoCfsHonUwj4UmJDP807w7Jxs pR6Nn7Zjr9i1knNbqGTsaKt44YAdPJQwkTWHuEHLkto8a7cdhkCzWn+zt E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhsFAHvYoFKrRDoH/2dsb2JhbABPBwODBzi4ck6BHBZ0giUBAQEDAQEBAWsLEAsYLicwBhOHfAUOwUwXjh4GCwEdIxAHEYMPgRMDiUKOUoEwhRWLToNKG4E1
X-IronPort-AV: E=Sophos;i="4.93,835,1378857600"; d="scan'208";a="99604117"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 05 Dec 2013 19:51:05 +0000
Received: from [10.155.28.111] ([10.155.28.111]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB5Jo5vT008751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Dec 2013 19:51:02 GMT
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Brian Weis <bew@cisco.com>
In-Reply-To: <A7238274-4657-4AA7-B776-E6D0037DE579@kumari.net>
Date: Thu, 05 Dec 2013 11:51:06 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <96652DAA-4E17-4451-BCED-454CDA819B21@cisco.com>
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> <A7238274-4657-4AA7-B776-E6D0037DE579@kumari.net>
To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
X-Mailer: Apple Mail (2.1510)
Cc: draft-ietf-ospf-rfc6506bis.all@tools.ietf.org, Acee Lindem <acee.lindem@ericsson.com>, The IESG <iesg@ietf.org>, secdir@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:51:10 -0000

Hi Manav,

On Dec 5, 2013, at 11:28 AM, Warren Kumari <warren@kumari.net> wrote:

> 
> 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

That sounds good to me too.

Thanks,
Brian

> 
>> 
>> 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.
> 
> 

-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com