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

From: [email-masked]
Date: Tue, 2 Dec 2008 08:52:30 -0800 (PST)

This idea was proposed during the IETF week. First in an email by James Goodwin:

http://www.ietf.org/mail-archive/web/ipsec/current/msg03357.html

and then during the meeting in the jabber room (by Michael Richardson, I believe). 
There was some discussion that week with different folks as well. 
The idea is to effect the minimum possible changes to IPsec in order to accommodate the new usage. That is a worthy goal. But using such a fixed SPI only resolves the “determination” problem (whether the packet is ESP-NULL or encrypted ESP). 
Resolving the payload “location” in a hardware-friendly manner would end up with 
something like the WESP header immediately following the fixed SPI anyways.  

Unfortunately, hijacking the existing ESP in such a manner is a more significant 
change to the IPsec architecture than simply adding a new protocol number. 
Intermediate devices that would drop this today would need to be reconfigured, yes. 
But these filters are not static, and are being modified and tweaked on an ongoing 
basis anyways, adapting to traffic patterns. I’d be surprised if this were a real blocker.

----- Original Message ----
> From: Jack Kohn <[email-masked]>
> To: "Bhatia, Manav (Manav)" <[email-masked]>
> Cc: [email-masked]; Stephen Kent <[email-masked]>
> Sent: Tuesday, December 2, 2008 7:39:52 AM
> Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets
> 
> > (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt).
> > The only available range is from 140-252, which is quite narrow. I
> > believe we must be chary in requesting for new numbers, otherwise we'll
> > have a new extension tomorrow that expands this range from one octet to
> > two octets! ;-)
> 
> :D
> 
> Oh dont worry, its going to take some while before we exhaust all
> these numbers; then there are some left that can be reused ..
> 
> > In this case you differentiate between the different formats based on
> > the SPI value, while, the underlying protocol still remains ESP! All
> > rules applicable to ESP apply here too. We could have gone
> > down the new
> > proto-number path if there was *no* other alternative around. However,
> > we seem to have an easy way out without using up a new
> 
> I agree with the above sentiment - i dont think using a reserved SPI
> value makes the underlying protocol any different from the base ESP.
> 
> > number. How else
> > do we otherwise intend to use the reserved values of SPI?
> 
> The chairs and ADs could perhaps guide us here?
> 
> Jack
> 
> > Cheers, Manav
> >
> >> -----Original Message-----
> >> From: Stephen Kent [mailto:[email-masked]]
> >> Sent: Monday, December 01, 2008 8.49 PM
> >> To: Bhatia, Manav (Manav)
> >> Cc: Jack Kohn; [email-masked]
> >> Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets
> >>
> >> Manav,
> >>
> >> If you have two SPIs (original and the new, reserved one) then the
> >> format is no longer ESP and thus cannot reuse the ESP protocol number.
> >>
> >> the same argument applies to the proposal that the original SPI be
> >> stuffed into the payload.
> >>
> >> Steve
> >>
> > _______________________________________________
> > 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: Tue, 2 Dec 2008 22:33:39 +0530

Gabriel,

> Resolving the payload "location" in a hardware-friendly manner would end up with

Yes.

> Intermediate devices that would drop this today would need to be reconfigured, yes.

You can only reconfigure them to accept a new protocol type packet.

> basis anyways, adapting to traffic patterns. I'd be surprised if this were a real blocker.

You would need a SW upgrade to be able to do anything meaningful with
that (deep inspect, etc).

Jack