Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets

From: "Jack Kohn" <[email-masked]>
Date: Fri, 28 Nov 2008 20:19:15 +0530

I love the idea however i see one teeny weeny problem.

If you want your ASICs to do your processing then you would do good if
you have the next-header field in a fixed position. In your way of
things, this is not possible, which is btw doable in the current
proposal (WESP) on the table. However, like you and many others here,
i detest the idea of introducing a new ESP protocol number. You could
do a couple of things - (a) add another octet after the RSPI that
gives the next-header or (2) work on some common ground and see if the
two ideas can be merged.

Jack

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Bhatia, Manav (Manav)
> Sent: Friday, November 28, 2008 3.57 PM
> To: [email-masked]
> Subject: [IPsec] Deep Inspecting ESP-NULL Packets
>
>
> Hi,
>
> I was working on prioritizing some control traffic that's protected
> using ESP and it was in this context that I was pointed towards the WG
> doc - "Wrapped ESP for Traffic Visibility". The problem that
> I am trying
> to solve is the same as being addressed in this draft - providing
> explicit means to signal that ESP-NULL is being used to protect the
> packet. Besides firewalls, this also becomes very important on routers
> since a lot of applications and protocols use ESP-NULL for data
> integrity protection and source authentication purposes.
>
> I wouldn't expend cycles extolling the virtues of being able to
> disambiguate ESP encrypted and ESP-NULL packets as everyone in this WG
> is very well aware of this.
>
> I went through the WG document and I think its good and it solves the
> problem. However, I am a tad uncomfortable with introducing a new ESP
> protocol type. This imo is a major change and would require all the
> intermediary boxes to upgrade so that they can support this. There are
> currently firewalls configured that drop all traffic that they don't
> recognize. Wouldn't such firewalls drop all traffic using W-ESP?
>
> I was thinking of an alternative solution which uses one of
> the reserved
> values of SPI to indicate that it's a ESP-NULL packet. IANA could, for
> instance, allocate a value of 1 to indicate this. Now, we
> continue using
> the existing protocol type (i.e. 50 for ESP) and add 4 octets of RSPI
> before the original ESP packet. Existing implementations only need to
> add the RSPI of 1 before the ESP payload, without needing to
> change the
> body of the packet.
>
> Since we're using the existing ESP protocol number, the intermediary
> devices can still forward the packet and there is little change
> required. Implementation of this extension is *extremely* *extremely*
> easy as one only needs to add a RSPI of 1 (or whatever is assigned by
> IANA) for all ESP-NULL packets.
>
> An extended ESP packet using NULL encryption would thus look
> like this:
>
> 0                   1                   2                   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |        Reserved Security Parameters Index (RSPI) = 1          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |          Original Security Parameters Index (SPI)             |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                      Sequence Number                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                    Payload Data* (variable)                   |
> ~                                                               ~
> |                                                               |
> +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |               |     Padding (0-255 bytes)                     |
> +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                               |  Pad Length   | Next Header   |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                  Authentication Data  (variable)              |
> ~                                                               ~
> |                                                               |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Intermediaries (routers, firewalls, IDS, etc) interested in inspecting
> the packets en route can look at the SPI value at the start of the ESP
> header. If its 1 and if they are aware of this extension, then they
> understand that what follows is a normal ESP-NULL packet, which can be
> inspected. Intermediaries that don't understand this extension of ESP
> would treat this like a normal ESP packet	
>
> This extension aware end nodes (routers) can similarly inspect the
> packet. If the SPI value is 1, they can deep inspect the packet and
> assign it to the right CPU queue/remark/apply ACLs/filters,
> based on the
> kind of payload the packet carries.
>
> Would like to hear from the folks on what they think about this
> proposal?
>
> Cheers, Manav
>
> --
> Manav Bhatia,
> IP Division, Alcatel-Lucent,
> Bangalore - India
>
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 28 Nov 2008 18:41:13 +0200

> gives the next-header or (2) work on some common ground and see if the

If you are doing deep inspection anyways then finding the next header
by using heuristics isn't really a problem. On the other hand if you
are doing heuristics (which do not require any changes to sending, or
receiving ends, or any middle boxes who do not do deep inspection)
then you do not even need the reserved SPI...
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Jack Kohn" <[email-masked]>
Date: Fri, 28 Nov 2008 22:44:11 +0530

Tero,

Heuristics is probability and is at best just an educated guess. I
think the stakes are high as you would be dropping/forwarding packets
based on the probability that your model returns you. Also, do you
propose to do this in HW or SW? Is there a model that you have in
mind? Do you have a study that you can share with us that gives some
numbers on how well this model works?

Jack.

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Sat, 29 Nov 2008 05:54:34 +0530

Hi Jack,

Thanks for your comments.

> I love the idea however i see one teeny weeny problem.

Not a problem :-)

> do a couple of things - (a) add another octet after the RSPI that

Yup, this can be done.

Cheers, Manav