Subject: [IPsec] Deep Inspecting ESP-NULL Packets

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Fri, 28 Nov 2008 15:56:48 +0530

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

---

From: "Scott Fluhrer" <[email-masked]>
Date: Fri, 28 Nov 2008 11:06:47 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bhatia, Manav (Manav)
> Sent: Friday, November 28, 2008 5:27 AM
> 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 
> 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.

Obvious problems with the packet format you have suggested:

- How does an intermediate device know how long the authentication data is
(and thus find the 'next header' field)?

- To an intermediate device that isn't aware of this extension, it would
look like an ESP packet except that the ESP sequence number doesn't
increment; instead, it stays at one particular fixed value (until a rekey,
when it abruptly switches to another fixed value).  One possible concern is
that firewalls that try to filter what they can for ESP traffic flows will
reject this.

Neither is that difficult to fix...

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

---

From: "Jack Kohn" <[email-masked]>
Date: Fri, 28 Nov 2008 23:14:58 +0530

> (and thus find the 'next header' field)?

Yes, i mentioned this to Manav and its trivial to fix this.

> that firewalls that try to filter what they can for ESP traffic flows will

Wow. You're saying that firewalls maintain state for each IPSec flow
and actually care about the sequence numbers? They'll have to maintain
state per <source IP, dest IP, ports, etc + SPI value.>. Why would you
do that? Are there firewalls that actually do that?

> Neither is that difficult to fix...

Absolutely.

I think whats important at this point is whether we want a new
protocol or some method that extends ESP for our needs. I would rather
that we go with the latter.

Jack

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Sat, 29 Nov 2008 06:08:18 +0530

Hi Scott,
 
> that firewalls that try to filter what they can for ESP 

I am not sure how big a problem this is. However, if it needs to be
fixed then this can be easily done.

You could send the original SPI and the next-header as part of the
payload, so the original ESP packet has the sequence number in the right
place. The receiver upon seeing the RSPI value of 1 would understand
that the first 4 octets give the actual SPI, while the intermediaries
could look at the 5th octet to know what the next-header is. If you want
the firewalls to be able to parse the L4 info then you could include the
ESP header length too. This could be the 6th octet. Using this the
intermediaries can determine the exact location from where the payload
starts.

0                   1                   2                   3
|  next-header  |  eESP HDRLen  |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +

> Neither is that difficult to fix...

Yes.

Cheers, Manav

---

From: "Jack Kohn" <[email-masked]>
Date: Sun, 30 Nov 2008 05:14:56 +0530

> that the first 4 octets give the actual SPI, while the intermediaries

Sounds Good.

> ESP header length too. This could be the 6th octet. Using this the

I am assuming that you're mentioning ESP header length explicitly to
account for the IV (if required, by the authentication algorithm), as
otherwise its a fixed value and can always be inferred, right?

Jack

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Sun, 30 Nov 2008 21:27:26 +0530

Hi Jack,

> otherwise its a fixed value and can always be inferred, right?

Yes, that's correct.

Cheers, Manav

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 30 Nov 2008 10:39:41 -0800

Hi Manav,

Thanks for your effort i the draft.

I noticed that the RFC4303 does not state how reserved values need to
be handled. Am I missing something?

   The set of SPI values in the range 1 through 255 are reserved by the
   Internet Assigned Numbers Authority (IANA) for future use; a reserved
   SPI value will not normally be assigned by IANA unless the use of the
   assigned SPI value is specified in an RFC.  The SPI value of zero (0)
   is reserved for local, implementation-specific use and MUST NOT be
   sent on the wire.  (For example, a key management implementation
   might use the zero SPI value to mean "No Security Association Exists"
   during the period when the IPsec implementation has requested that
   its key management entity establish a new SA, but the SA has not yet
   been established.)

What would an IPsec router do in case it gets one of the reserved SPI
values in the packet?

Thanks again,
Vishwas

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Mon, 1 Dec 2008 05:22:36 +0530

Hi Vishwas,

[ .. ]

> What would an IPsec router do in case it gets one of the reserved SPI

The transit routers would not care about this while the end routers
should ignore such packets. In this case, the latter behavior is
acceptable as end routers unaware of this extension would anyways be
unable able to parse this packet.

Cheers, Manav

---

From: [email-masked]
Date: Mon, 01 Dec 2008 12:54:58 +0900

A few comments:

SPI value 1 is already assigned.  You should let IANA assign a value,
and until that it should be To Be Assigned.

If I understand correctly, efforts has been paid to make protocol
headers align at 4-octet word boundary.  If the policy hasn't changed,
the next protocol header should align at the word boundary inside ESP
header as well.

					FUKUMOTO Atsushi
					[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Mon, 1 Dec 2008 10:55:42 +0530

Hi Atsushi,

> SPI value 1 is already assigned.  

I didn't realize that SPI of 1 was already taken. I tried searching for
it on the IANA website but couldn't find it. Can you point me to the RFC
that defines this?

> You should let IANA assign a value,

Yup, will do that.

> the next protocol header should align at the word boundary inside ESP

Its easy to align it on a word boundary - just add two reserved bytes
after the header length; these would be set to zero when transmitting
and ignored on receipt. This also leaves room for further extensions.

Cheers, Manav

---

From: [email-masked]
Date: Mon, 01 Dec 2008 16:27:33 +0900

> it on the IANA website but couldn't find it. Can you point me to the RFC

Refer to http://www.iana.org/assignments/spi-numbers .  SKIP stands for
Simple Key-Management for Internet Protocol.

> and ignored on receipt. This also leaves room for further extensions.

I was wrong, it should be 8-octets boundary.  (RFC2460, section 4)
I guess there's no difference for your case, though.

					FUKUMOTO Atsushi