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

From: "Jack Kohn" <[email-masked]>
Date: Mon, 1 Dec 2008 18:39:47 +0530

Hi Scott,

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

I was hoping that somebody (Scott?) would answer this. Is this really
a concern?

Transit routers wouldnt care about the sequence number not
incrementing when forwarding IPSec packets, and i would be extremely
surprised if firewalls do.

Jack
>
>>
>> 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
>
>>
>>>
>>> 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
>>
>
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Jack Kohn" <[email-masked]>
Date: Mon, 1 Dec 2008 18:34:18 +0530

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

I dont think ESP needs to do this when its being used for integrity
only. I always thought that padding was there to facilitate the
encryption algorithms.

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

Extensibility and not alignment should be the reason for adding the two octets.

Jack

>
> Cheers, Manav
>
>>
>>
>>                                       FUKUMOTO Atsushi
>>                                       [email-masked]

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 1 Dec 2008 05:54:11 -0800

Hi Manav,

> 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.
How can we identify the difference between "unable to parse" a packet
vs "wrongly parsing a packet"?

Thanks,
Vishwas

On Sun, Nov 30, 2008 at 3:52 PM, Bhatia, Manav (Manav)
<[email-masked]> wrote:
> Hi Vishwas,
>
> [ .. ]
>
>> What would an IPsec router do in case it gets one of the reserved SPI
>> values in the packet?
>
> 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
>
>>
>> Thanks again,
>> Vishwas
>>
>> On Sun, Nov 30, 2008 at 7:57 AM, Bhatia, Manav (Manav)
>> <[email-masked]> wrote:
>> > Hi Jack,
>> >
>> >> > 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
>> >>
>> >> 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?
>> >
>> > Yes, that's correct.
>> >
>> > Cheers, Manav
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 1 Dec 2008 16:03:23 +0200

> surprised if firewalls do.

Well, firewalls do keep state about sequence numbers in TCP  
connections. They sometimes collect an entire file transferred through  
HTTP, SMTP or FTP just to run an anti-virus or DLP on it. They do much  
more than just block ports.

That said, TCP sequence  enforcement is there because there have been  
some attacks based on sequence numbers, because TCP is not secure.  
IPsec, even with ESP-NULL is secure against packet injection, dropping  
and replay, so AFAIK no firewall actually goes to the trouble of  
inspecting sequence numbers.

Yoav

Email secured by Check Point
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 1 Dec 2008 16:18:10 +0200

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

If there actually is firewalls which do inspect sequence numbers, then
your solution does not work, as they will then verify sequence numbers
for each separate SPI, and if you have multiple SAs with multiple SPIs
their sequence numbers are not synced, and even with your modified
version they would drop them.

On the other hand, I do not think there are such firewalls around, but
on the other hand your solution still requires changes to all IPsec
end nodes and all deep inspection nodes. Heuristics require changes
only to deep inspection nodes, thus are much easier to take in to use. 
-- 
[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 21:40:19 +0530

Hi Vishwas,

Let me reword my reply.

A compliant implementation upon receiving the reserved value must accept
it and process it accordingly. A non compliant implementation should
drop this packet, as it comes with a reserved SPI.

Cheers, Manav

> -----Original Message-----
> From: Vishwas Manral [mailto:[email-masked]] 
> Sent: Monday, December 01, 2008 7.24 PM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]
> Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets
> 
> Hi Manav,
>

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 1 Dec 2008 21:30:53 +0200

Hi Manav,

I think we are splitting hairs here. IMHO it's completely speculative to say
what real-life routers/firewalls will do when faced with a reserved SPI
value.

And I agree with Steve that a new protocol requires a new protocol number.
Also, it strikes me as strange that existing routers which can detect ESP
(in hardware, say) cannot be configured to pass through any packet with the
new protocol number X. Moreover, the security of this access control policy
(in the absence of deep inspection on the same router), is very debatable.

Thanks,
	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bhatia, Manav (Manav)
Sent: Monday, December 01, 2008 18:10
To: Vishwas Manral
Cc: [email-masked]
Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets

Hi Vishwas,

Let me reword my reply.

Cheers, Manav

Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Grewal, Ken" <[email-masked]>
Date: Tue, 2 Dec 2008 10:08:18 -0700

I agree with Yaron, but am open to other opinions also.  

The proposal from Manav is essentially similar (except moving a few fields
around) to the UDP-Encapsulation proposal for NAT-T from the current WG
draft (but applied to ESP, instead of/as well as NAT-T), where a reserved
value of the SPI is used to differentiate between existing ESP encapsulation
and a new one. 

Some additional observations: 
- We considered this originally and then benched it favoring a new
protocol definition for the new encapsulation. Having said that, it is good
to get the discussion officially on the table to get wider perspective from the participants. 

- The reason we added the additional reserved SPI into NAT-T and not
natively in ESP was that the additional field (Non-ESP marker) was already
present in NAT-T for demuxing between IKE and ESP traffic when using NAT-T.

- Some people made observations that there may be home brewed solutions where intermediate devices may be attempting to parse legacy ESP traffic, hence (as Yaron indicates below), it is speculative as to what real-life routers / firewalls do when faced with a reserved SPI value - hence a clean break in using a new protocol. Note** If such devices/solutions do exist, they will break if we keep the existing ESP protocol and modify the packet format. 

- In a separate thread, there have been questions on how legacy devices
behave when seeing a new, unrecognized protocol - We face the same issues
each time we introduce a new protocol (e.g. HIP, UDP-Lite, mobility headers,
etc.). Although the introduction of a new protocol is infrequent, these are
still being introduced on a periodic basis, hence legacy devices need to
cater for these, so no difference here. 

Thanks, 
- Ken

>Yaron Sheffer
>Sent: Monday, December 01, 2008 11:31 AM
>To: Bhatia, Manav (Manav); Vishwas Manral
>Cc: [email-masked]