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

[Tero Kivinen <[e-mail]>]

Bhatia, Manav (Manav) writes:
> > 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.

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.

> 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. 
-- 
[e-mail]