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

From: Brian Weis <[email-masked]>
Date: Tue, 3 Dec 2013 18:31:54 -0800

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 replaces (obsoletes) RFC 6506, which defines an Authentication Trailer for OSPFv3. It makes modest changes to the original specification, apparently as a result of deployment experience. It includes a positive security improvement in requiring that expired keys no longer be used rather than recommending that the expired key be used indefinitely. The specification is generally ready to publish.

I would suggest one rewording. The Introduction of RFC 6505 was published with the following justification as to why ESP sometimes cannot be used, and this was not changed in this draft:

   Since there is no deterministic way to differentiate between
   encrypted and unencrypted ESP packets by simply examining the packet,
   it could be difficult for some implementations to prioritize certain
   OSPFv3 packet types, e.g., Hello packets, over the other types.

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:

   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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Wed, 4 Dec 2013 16:29:17 +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

---

From: Acee Lindem <[email-masked]>
Date: Wed, 4 Dec 2013 18:22:30 +0000

I tend to agree with Manav - this seems to be a rather extreme measure and
wouldn't be used by a router line card simply to prioritize a packet.

Thanks,
Acee

On 12/4/13 8:29 AM, "Bhatia, Manav (Manav)"
<[email-masked]> wrote:

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

---

From: Brian Weis <[email-masked]>
Date: Wed, 4 Dec 2013 10:37:13 -0800

Hi Acee & Manav,

> wouldn't be used by a router line card simply to prioritize a packet.

Agreed, but the current text essentially says "you can't do that', but in fact "you can do that but it's too much work to do on the router line card". I was suggesting you say that instead.

Thanks,
Brian

-- 
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 5 Dec 2013 00:53:43 +0000

Hi Brian,

> 
> > I tend to agree with Manav - this seems to be a rather extreme measure
> > and wouldn't be used by a router line card simply to prioritize a
> packet.
> 
> Agreed, but the current text essentially says "you can't do that', but
> in fact "you can do that but it's too much work to do on the router line
> card". I was suggesting you say that instead.

While, we can add such a text, I am convinced nobody will *ever* use heuristics to figure out the kind of packet they're receiving at their line cards. The most important reason being that using heuristics does not give you a deterministic result. While it may be acceptable to get a few false positives or negatives when forwarding traffic through the firewall, this will be unacceptable when consuming packets by the router. Then the additional overhead of applying heuristics is an issue that I am not even delving into. Most of the forwarding from line card to the main CPU card is done in HW. You cannot apply heuristics in HW. This means, we assume that all CPU bound packets are being punted from the line card to the main CPM card via software. This is not how it happens today.

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 4 Dec 2013 20:16:02 -0500

> While, we can add such a text, I am convinced nobody will *ever* use heuristics to figure out the kind of packet they're receiving at their line cards. The most important reason being that using he…

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

How about:
"While techniques exist to identify ESP-NULL packets 
  [RFC5879], implementing these in line cards is not currently feasible." ?
> _______________________________________________
> secdir mailing list
> [email-masked]
> 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)

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 5 Dec 2013 01:38:03 +0000

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. 

>   [RFC5879], implementing these in line cards is not currently

Sure, we can add something to this effect.

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 5 Dec 2013 12:36:12 +0200

Bhatia, Manav (Manav) writes:
> While, we can add such a text, I am convinced nobody will *ever* use
> heuristics to figure out the kind of packet they're receiving at
> their line cards. The most important reason being that using
> heuristics does not give you a deterministic result. While it may be
> acceptable to get a few false positives or negatives when forwarding
> traffic through the firewall, this will be unacceptable when
> consuming packets by the router. Then the additional overhead of
> applying heuristics is an issue that I am not even delving into.
> Most of the forwarding from line card to the main CPU card is done
> in HW. You cannot apply heuristics in HW. This means, we assume that
> all CPU bound packets are being punted from the line card to the
> main CPM card via software. This is not how it happens today.

First of all, heuristics is supposed to be done on hardware, but not
all of it is done on the hardware. Hardware parts only consists the
first few steps checking whether packet is ESP and whether we already
know its parameters. If not (i.e. it is new ESP flow), then we drop to
slowpath and do the full analysis. So slowpath processing is only done
on the new ESP Flows.

I.e. if you see SPI you have already analyzed you can check from your
state table whether it is ESP null or not, and process it accordingly.
If you see unknown ESP then you forward packets to the heuristics,
until it returns parameters (or make a call to your IPsec module and
ask definite answer from there :-)

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

It needs to keep mapping from the IP addresses and SPI to whether it
is ESP null (and parameters) or encrypted ESP flow. I.e few bytes per
ESP flow (+ selector: src IP, dst IP, SPI).

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

Which most likely should also be mentioned in the draft.

> 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. 
-- 
[email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Thu, 5 Dec 2013 14:28:09 -0500

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

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

> Sure, we can add something to this effect.

Cool.
W

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

---

From: Brian Weis <[email-masked]>
Date: Thu, 5 Dec 2013 11:51:06 -0800

Hi Manav,

>> Sure, we can add something to this effect.

That sounds good to me too.

Thanks,
Brian