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

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

Jack Kohn writes:
> Heuristics is probability and is at best just an educated guess.

Not really. For ESP-NULL there is always at least few bytes of self
describing padding, which is very easy to check. After checking those
the next ones to check is either the inner IP header (in case of
tunnel mode) or TCP/UDP headers (in case of transport mode). All that
checking nedes to only be done for the FIRST few packets, after the
heuristics have identified the ICV length (currently 5 possible values
in total, and currently only 1 of them is widely sued) and IV length
(2 possible values and currently only 1 of them is widely used) then
the information can be stored along the other flow specific
information and no heuristics is needed after that.

> I think the stakes are high as you would be dropping/forwarding
> packets based on the probability that your model returns you.

There is 1 out of 2^96 probability that random packet will pass your
HMAC-SHA1-96 message check, so that is also probabilistic approach...
If you check 8 bytes of self-describing padding and 4 bytes from the
inner IP header (for tunnel mode) you get same probability... 

> Also, do you propose to do this in HW or SW?

Either way is doable. I think the actual initial heuristics that is
run when unknown source IP, destination IP and SPI value is found,
would most likely be run on the softpath, as it makes adding things in
future easier, but the actual per packet processing would most likely
be run on the hardware. Only changes there would require adding SPI as
one of the keys used when looking up the state information and getting
ICV_len and IV_len from the per flow state and use those to get the
protocol number. 

> Is there a model that you have in mind?

I posted a example pseudocode for this earlier to this list. 
http://www.ietf.org/mail-archive/web/ipsec/current/msg03385.html

> Do you have a study that you can share with us that gives some
> numbers on how well this model works?

My earlier email listed some numbers, so check those.

There are also ways to make this even better without modifying the ESP
packet format, but that would require changes to the ESP-NULL senders.
I.e. the ESP-NULL senders could send at least 8 bytes of
self-describing padding instead of the minimal amount, and with that
change the probability of detecting ESP-NULL packet versuis
ESP-encrypted packet with just one packet would go over 2^72 (8 bits
of self-describing padding length, and 64 bits of padding).

This is change we could do without breaking existing implementations,
and it would usually be one or two line change to the code, i.e.
something like:
----------------------------------------------------------------------
  /* ... calculate normal pad_len here ... */
  if (cipher == ESP_NULL) {
     pad_len += 8;
  }
----------------------------------------------------------------------

On the other hand if the implementation is already doing deep
inspection of the packet (i.e. verifying urls and such inside the
packets) then it will be checking more than enough bytes from the
packet, that we do not need the extra bytes for the self-describing
padding. The self-describing padding already gives you 99.998% -
99.999999999999999994% probability for detecting whether the first
packet is ESP-NULL packet or ESP with encryption packet (depending
how many bytes of padding there is (2-8 bytes)).

And even then it would detect encrypted ESP packets as ESP-NULL
because they happened to have correct bytes which looked like
self-describing padding in the encrypted part. The packet would then
be passed to the deep inspection part, which could not do deep
inspection because the packet is encrypted. This would just cause some
extra resources wasted when deep inspection engine tries to inspect
those encrypted packets.

The heuristics would never get it wrong in the other way, i.e
detecting ESP-NULL packet as being encrypted, thus all ESP-NULL
packets would be passed to the deep inspection part.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Mon, 1 Dec 2008 10:19:14 -0500

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

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Tue, 2 Dec 2008 14:10:03 +0530

Hi Steve,

We're just changing how the packet needs to be parsed when using the new
SPI - the protocol still remains ESP! :-)

This isn't as you already know, new in IETF, and a lot of proposals do
this - they extend and change how an existing protocol packet needs to
be parsed/formatted. Look at OSPFv2 and OSPFv3 - you parse the packet
based on the version field that you have at the beginning. Packet
formats are different, and but they still use the same protocol number -
89.

To cite another example, you could look at the latest cryptographic
authentication draft in IS-IS. It changes how the authentication data
needs to be parsed, but continues to use the same Authentication TLV 10.
It does not introduce a new TLV within IS-IS.

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 number. How else
do we otherwise intend to use the reserved values of SPI?

Last but not the least, the protocol number field is of one byte and we
have already taken up most of the numbers
(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! ;-)

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

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 2 Dec 2008 08:13:14 -0500

Tero, I wanted to chime in briefly in support of your suggested heuristic 
approach over against the proposed drafts to modify the ESP protocol with 
new formats and/or protocol numbers.  I prefer recommending a heuristic 
approach for the following reasons:

1) Creating new protocols and different formats places an undue burden on 
end-node implementations when there is already a viable heuristic approach 
that would require no end-node retooling.
2) Considering that end-node adoption of these drafts is realistically 
going to be slow and incomplete, a heuristic approach will be necessary in 
any case for any intermediate-node implementation that wishes to remain 
competitive.
3) Finally, considering industry, regulatory and governmental moves to 
adopt end-to-end encryption, I suspect that in the long term the use of 
ESP-NULL may be insignificant compared to using encryption.  This would 
limit the usefulness of these drafts (or indeed any form of deep-packet 
inspection), and also make it harder for end-node implementations to 
justify spending resources to implement and support a new protocol.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Tero Kivinen <[email-masked]>
To:
"Jack Kohn" <[email-masked]>
Cc:
[email-masked], [email-masked]
Date:
12/01/2008 09:52 AM
Subject:
Re: [IPsec] Deep Inspecting ESP-NULL Packets

---

From: "Jack Kohn" <[email-masked]>
Date: Tue, 2 Dec 2008 21:09:52 +0530

> have a new extension tomorrow that expands this range from one octet to

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

> 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

The chairs and ADs could perhaps guide us here?

Jack

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 2 Dec 2008 08:31:05 -0800

At 8:13 AM -0500 12/2/08, Scott C Moonen wrote:
>Tero, I wanted to chime in briefly in support of your suggested heuristic approach over against the proposed drafts to modify the ESP protocol with new formats and/or protocol numbers.

If you want this to be a serious consideration of the WG, we need more than brief chimes. Asking us to look in the archives for multiple messages listing some heuristics is a bit challenging. Could one or both of you put together an Internet Draft that lists all of the heuristics that you consider sufficient for detecting most ESP-NULL traffic? That would help the WG greatly!

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 2 Dec 2008 18:37:49 +0200

Hi Jack,

In fact, I cannot imagine any good use for the reserved SPI values. But I
don't think that when you use a "magic" SPI value, you are allowed to change
the header format drastically. And shifting everything by 2 or 4 bytes is
certainly drastic (e.g. to protocol analyzers, deep inspection engines, load
balancers).

Thanks,
	Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jack Kohn
Sent: Tuesday, December 02, 2008 17:40
To: Bhatia, Manav (Manav)
Cc: [email-masked]; Stephen Kent
Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets

:D

Jack

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

---

From: "Jack Kohn" <[email-masked]>
Date: Tue, 2 Dec 2008 22:26:33 +0530

> the header format drastically. And shifting everything by 2 or 4 bytes is

I read the draft again (can the author please post it, as its
extremely inconvenient reading it from a mail attachment .. ) and
verified that the header remains the same; its the payload thats
modified.

> certainly drastic (e.g. to protocol analyzers, deep inspection engines, load

To each his own, because to me a new protocol number is as
inconveniencing, if not more, than changing the packet semantics.

Are you suggesting that there are protocol analyzers, deep inspection
engines, load balancers peeking inside ESP packets? What i am unable
to fathom is that if they can be updated to understand the new
protocol number, then why cant they be updated to parse the new SPI
type?

Jack

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 2 Dec 2008 19:08:06 +0200

Hi Jack,

I am not following you: the draft has the fixed SPI, then sequence number,
then another SPI, then payload. ESP has SPI, sequence number, payload. Of
course the header is changed!

Realistically, if people look at ANYTHING in these packets, it'll be the
SPI. And you've just ruined their day :-) They can certainly change their
code, but until they do, I would like them to identify the packets as
strange and unknown instead of misunderstanding them as regular ESP and
treating them incorrectly.

Thanks,
	Yaron

-----Original Message-----
From: Jack Kohn [mailto:[email-masked]] 
Sent: Tuesday, December 02, 2008 18:57
To: Yaron Sheffer
Cc: Bhatia, Manav (Manav); [email-masked]; Stephen Kent
Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets

Jack

---

From: "Grewal, Ken" <[email-masked]>
Date: Tue, 2 Dec 2008 11:03:09 -0700

Scott,
Heuristics based solutions can be expensive to implement in HW as well as being inconclusive, providing assurances based on probabilities and hence prone to false positives.
Furthermore, some HW devices (especially Network Interface Cards, NICs) currently only examine packet headers and do not load the whole packet into memory. In aggregated environments, where these devices need to maintain line rate processing, subtle changes in design such as loading the whole packet into memory and parsing the packet trailer before making a decision if the packet should be sent to one CPU core or another for processing will have drastic impact on the packet processing engines of such devices (compared with a simple, deterministic approach such as in the current draft).

As for the E2E encryption, I agree that there is some regulatory pressure to adopt this from a security perspective, but this is also competing with entrenched solutions offering valuable network services for traffic monitoring and hence require traffic visibility - this is one of the reasons that E2E encryption is not widely employed today within Enterprise environments, as it circumvents these network tools. The predominant use of IPsec today is in the remote access / VPN scenarios.
Some people have also mentioned that E2E encryption offers a secure channel for virus propagation, where the intermediate devices such as IDS/IPS are left blind to the network traffic flow.

Having said that, there was some discussion during the last IETF meeting and the mailing list on adding the 'integrity bit' back into the WESP header. This was removed from the last draft and we could add this back in as it will provide a consistent view of an IPsec packet indicating if the packet is encrypted or in the clear, as well as allowing future innovation on intermediate devices being able to examine encrypted data based on administrative policy - food for thought.

Thanks,
- Ken

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott C Moonen
Sent: Tuesday, December 02, 2008 5:13 AM
To: Tero Kivinen
Cc: [email-masked]; [email-masked]; [email-masked]; Jack Kohn
Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets

Tero, I wanted to chime in briefly in support of your suggested heuristic approach over against the proposed drafts to modify the ESP protocol with new formats and/or protocol numbers.  I prefer recommending a heuristic approach for the following reasons:

1) Creating new protocols and different formats places an undue burden on end-node implementations when there is already a viable heuristic approach that would require no end-node retooling.
2) Considering that end-node adoption of these drafts is realistically going to be slow and incomplete, a heuristic approach will be necessary in any case for any intermediate-node implementation that wishes to remain competitive.
3) Finally, considering industry, regulatory and governmental moves to adopt end-to-end encryption, I suspect that in the long term the use of ESP-NULL may be insignificant compared to using encryption.  This would limit the usefulness of these drafts (or indeed any form of deep-packet inspection), and also make it harder for end-node implementations to justify spending resources to implement and support a new protocol.

From:

To:

Cc:

Date:

12/01/2008 09:52 AM

Subject:

________________________________

---

From: Stephen Kent <[email-masked]>
Date: Tue, 2 Dec 2008 13:35:32 -0500

>SPI - the protocol still remains ESP! :-)

I have to disagree. ESP specifies a format with precise locations for 
the SPI and sequence number in the header. When you hide the original 
SPI somewhere else in the ESP payload, that constitutes a change to 
the protocol format.

>formats are different, and but they still use the same protocol number -

we don't carry a version field in ESP or AH. We negotiate it via IKE. 
I think others have noted that intermediate systems need to know 
where to find the next protocol field, which

>It does not introduce a new TLV within IS-IS.

That proposal is not my responsibility :-).

>do we otherwise intend to use the reserved values of SPI?

Reserved SPI values are not defined as ways to changing how ESP/AH 
packets are parsed. They were defined for uses such as manual keying 
support. In IPsec, we allow the crypto algorithm choices to affect 
parsing, because of variability in length and location of IVs, and 
integrity info, for example. So, your proposal to use the SPI for 
this sort of demuxing is not consistent with what IPsec has chosen to 
do.

>have a new extension tomorrow that expands this range from one octet to

We are all aware of this issue. Several proposals prior to your's 
also required a new protocol number.

Steve

---

From: "Gary Hemminger" <[email-masked]>
Date: Tue, 2 Dec 2008 10:36:47 -0800

I chimed in on this earlier and want to provide feedback from a network
(L2-3) and application delivery controller (load balancer) perspective.
That perspective is that basically everyone in the industry uses
merchant silicon (ie Broadcom/Marvell) to provide network functionality.
Some kind of heuristic approach is going to be very difficult to
convince them to provide vs. having a deterministic approach, in my
opinion.   

That said, the previous emails seemed to indicate that the heuristic
approach would not require any retooling.  Can someone explain that
magic to me?

Gary

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Grewal, Ken
Sent: Tuesday, December 02, 2008 10:03 AM
To: Scott C Moonen; Tero Kivinen
Cc: [email-masked]; [email-masked]; [email-masked];
Jack Kohn
Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets

Scott, 

Heuristics based solutions can be expensive to implement in HW as well
as being inconclusive, providing assurances based on probabilities and
hence prone to false positives. 

Furthermore, some HW devices (especially Network Interface Cards, NICs)
currently only examine packet headers and do not load the whole packet
into memory. In aggregated environments, where these devices need to
maintain line rate processing, subtle changes in design such as loading
the whole packet into memory and parsing the packet trailer before
making a decision if the packet should be sent to one CPU core or
another for processing will have drastic impact on the packet processing
engines of such devices (compared with a simple, deterministic approach
such as in the current draft). 

As for the E2E encryption, I agree that there is some regulatory
pressure to adopt this from a security perspective, but this is also
competing with entrenched solutions offering valuable network services
for traffic monitoring and hence require traffic visibility - this is
one of the reasons that E2E encryption is not widely employed today
within Enterprise environments, as it circumvents these network tools.
The predominant use of IPsec today is in the remote access / VPN
scenarios. 

Some people have also mentioned that E2E encryption offers a secure
channel for virus propagation, where the intermediate devices such as
IDS/IPS are left blind to the network traffic flow. 

Having said that, there was some discussion during the last IETF meeting
and the mailing list on adding the 'integrity bit' back into the WESP
header. This was removed from the last draft and we could add this back
in as it will provide a consistent view of an IPsec packet indicating if
the packet is encrypted or in the clear, as well as allowing future
innovation on intermediate devices being able to examine encrypted data
based on administrative policy - food for thought.  

Thanks, 

- Ken

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Scott C Moonen
Sent: Tuesday, December 02, 2008 5:13 AM
To: Tero Kivinen
Cc: [email-masked]; [email-masked]; [email-masked];
Jack Kohn
Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets

Tero, I wanted to chime in briefly in support of your suggested
heuristic approach over against the proposed drafts to modify the ESP
protocol with new formats and/or protocol numbers.  I prefer
recommending a heuristic approach for the following reasons: 

1) Creating new protocols and different formats places an undue burden
on end-node implementations when there is already a viable heuristic
approach that would require no end-node retooling. 
2) Considering that end-node adoption of these drafts is realistically
going to be slow and incomplete, a heuristic approach will be necessary
in any case for any intermediate-node implementation that wishes to
remain competitive. 
3) Finally, considering industry, regulatory and governmental moves to
adopt end-to-end encryption, I suspect that in the long term the use of
ESP-NULL may be insignificant compared to using encryption.  This would
limit the usefulness of these drafts (or indeed any form of deep-packet
inspection), and also make it harder for end-node implementations to
justify spending resources to implement and support a new protocol. 

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/ <http://scott.andstuff.org/> 
http://www.linkedin.com/in/smoonen <http://www.linkedin.com/in/smoonen>

From: 

To: 

Cc: 

Date: 

12/01/2008 09:52 AM 

Subject: 

I posted a example pseudocode for this earlier to this list. 
http://www.ietf.org/mail-archive/web/ipsec/current/msg03385.html
<http://www.ietf.org/mail-archive/web/ipsec/current/msg03385.html> 

<https://www.ietf.org/mailman/listinfo/ipsec>

---

From: "Grewal, Ken" <[email-masked]>
Date: Tue, 2 Dec 2008 11:44:17 -0700

Jack, 
I think we are splitting hairs here!
In either case, the packet format changes. If there are legacy devices parsing ESP packets, then these will need to change for the reserved SPI based solution, as well as the new protocol based solution. 

If a legacy intermediate device is assuming a fixed ESP format (it has not changed in the last 10 years) and looking inside a packet based on a generic policy that all traffic is ESP-Null, than it does not even need to parse the SPI and may be dumb in so far as skipping x number of bytes for the ESP header and parsing the payload - in such a case, changing the packet format, while preserving the protocol number will certainly break such implementations. Not sure if such implementations or deployments exist?

The new protocol approach appears to be a cleaner solution and will not have any compatibility issues.

I look forward to other opinions...

Thanks, 
- Ken

>Sent: Tuesday, December 02, 2008 8:57 AM
>To: Yaron Sheffer
>Cc: [email-masked]; Bhatia, Manav (Manav); Stephen Kent

---

From: Dan McDonald <[email-masked]>
Date: Tue, 2 Dec 2008 13:53:14 -0500

<mucho snippage deleted!>
> approach would not require any retooling.  Can someone explain that

The problem with any deep-inspection-friendly ESP comes down to two
complaints from two mostly-disjoint sets of developers:

End-node/OS types:
------------------

I'm not putting in a THIRD IPsec protocol (or SECOND if I blew off AH) if I
can help it.  I put in IPv6 a while ago and not many of my customers/users
are using it.  And do you know how hard it is to get customers to
*upgrade*?!?  They all want the new features in the same *&^%&%$# revision
number so they won't have to pay high-priced con-art^H^H^H^Hsultants to
"recertify" their setup.  I thought this whole 430x movement was about
*SIMPLIFYING* things!

Middlebox/Router/Firewall types:
--------------------------------

You expect me to go begging to my {silicon vendor, in-house polygon pushers}
and put in all sorts of can't-make-it-run-fast inspection that needs to
guess?  It's all just software at the end-nodes - let them figure it out!  I
thought this whole 430x movement was about *SIMPLIFYING* things!

My apologies for not injecting enough humor into the 2nd point of view.

If anyone's scheme can overcome both of those complaints, we all win.
Anything else is going to be painful for someone.  I am a fan of Kivenen's
middlebox heuristic scheme, mostly because I fall into the first category of
complainers.

Dan

---

From: "Gary Hemminger" <[email-masked]>
Date: Tue, 2 Dec 2008 12:03:32 -0800

I think you pretty much nailed it.  Very accurate depiction of the
issues on both sides.

Gary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dan McDonald
Sent: Tuesday, December 02, 2008 10:53 AM
To: [email-masked]
Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets

End-node/OS types:
------------------

I'm not putting in a THIRD IPsec protocol (or SECOND if I blew off AH)
if I
can help it.  I put in IPv6 a while ago and not many of my
customers/users
are using it.  And do you know how hard it is to get customers to
*upgrade*?!?  They all want the new features in the same *&^%&%$#
revision
number so they won't have to pay high-priced con-art^H^H^H^Hsultants to
"recertify" their setup.  I thought this whole 430x movement was about
*SIMPLIFYING* things!

You expect me to go begging to my {silicon vendor, in-house polygon
pushers}
and put in all sorts of can't-make-it-run-fast inspection that needs to
guess?  It's all just software at the end-nodes - let them figure it
out!  I
thought this whole 430x movement was about *SIMPLIFYING* things!

If anyone's scheme can overcome both of those complaints, we all win.
Anything else is going to be painful for someone.  I am a fan of
Kivenen's
middlebox heuristic scheme, mostly because I fall into the first
category of
complainers.

Dan

---

From: Scott C Moonen <[email-masked]>
Date: Tue, 2 Dec 2008 16:05:41 -0500

Thanks to Dan for his excellent analysis. :)  I'm certainly willing to 
look for solutions that try to bridge the concerns of both camps.

In 2007, on August 27th Dan and I almost simultaneously proposed something 
simpler on-list.  We suggested reserving by convention portions of the SPI 
space to signal the use of ESP NULL and even possibly distinct IV lengths:

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

I'm not able to find any replies to our notes, although perhaps I'm 
missing them.

For this approach, the burden on end-node implementations would be 
substantially reduced compared to the WG draft, as the TCP/IP stack no 
longer needs any involvement with new protocols; the only thing that needs 
to be changed is the SPI selection algorithm.  Furthermore, this will not 
break existing intermediate-node implementations or even require any 
configuration changes to permit new protocols.  It will even allow for 
unidirectional packet inspection if only one endpoint supports the 
proposal.  Finally, I don't think it would be any more burdensome on 
intermediate-node implementations than the current WG draft.

It is true that existing end-node implementations will create both false 
positives and false negatives by not honoring this convention.  But any 
architected solution will be hampered by incomplete adoption -- and in 
this case a simpler solution may actually be adopted more quickly by end 
nodes.

From:
"Gary Hemminger" <[email-masked]>
To:
"Dan McDonald" <[email-masked]>, <[email-masked]>
Date:
12/02/2008 03:05 PM
Subject:
Re: [IPsec] Deep Inspecting ESP-NULL Packets

Gary

-----Original Message-----

End-node/OS types:
------------------

Dan

---

From: Dan McDonald <[email-masked]>
Date: Tue, 2 Dec 2008 16:20:58 -0500

> I'm not able to find any replies to our notes, although perhaps I'm 

Yeah... the thread-view on the mail archive website is kinda *off* around
this thread.

> to be changed is the SPI selection algorithm.

Even stronger than "no TCP/IP stack changes", a decent user/kernel split will
require no kernel-level changes as well.  And for embedded/single-level
implementations, you can probably isolate the changes if the system is
well-architected.

> intermediate-node implementations than the current WG draft.

And trapping 0xfffe0000/15 for deep-inspection-happiness should be easy to
put in your silicon, if not a firmware update for middle-box vendors.

> positives and false negatives by not honoring this convention.

My proposal causes that to happen 1/32768 of assigned SAs.

> But any architected solution will be hampered by incomplete adoption -- and
> in this case a simpler solution may actually be adopted more quickly by end
> nodes.

The only real drawback I can see is if an SPD entry and subsequent proposal
(IKEv1 or IKEv2) has a mix of with-and-without-encryption for possible
actions (kinda silly, but it is possible).  The SPI selection in those cases
cannot be guaranteed to be deep-inspectable, and therefore the reserved SPI
range cannot be used.

Besides, end-nodes might not WANT their packets deep-inspected, and those
that do can configure their SPD accordingly -- setting ESP encryption to NULL
explicitly.

Dan

---

From: "Grewal, Ken" <[email-masked]>
Date: Tue, 2 Dec 2008 14:47:06 -0700

One observation with this proposal (call it the SPI semantics proposal) is legacy incompatibility.

All endpoint implementations would need to ensure they follow these rules and change their implementations accordingly. If there are any implementations within a network that do not follow these rules, we are back to invalid inferences.

Another observation along similar lines is any HW devices that are encoding additional lookup information directly into the Rx SPI (which is under the control of the recipient) to allow optimized Rx SA lookup (e.g. masking some SPI bits to extract a direct SA index into the SADB) will now need to be changed also. I actually did one of these in my previous life.

This will impact HW and SW.

Thanks,
- Ken

>Dan McDonald
>Sent: Tuesday, December 02, 2008 1:21 PM
>To: [email-masked]

---

From: "Grewal, Ken" <[email-masked]>
Date: Tue, 2 Dec 2008 14:55:39 -0700

LOL - Nice analysis :-)

If we want a common solution amenable to all parties, without letting the 'other guy' worry about it, we need a common language, hence the new protocol. 

BTW, some of your text appears encrypted (*&^%&%$#) - any pointers on how to parse this? ;-)

Thanks, 
- Ken

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 3 Dec 2008 15:00:24 +0200

Grewal, Ken writes:
> All endpoint implementations would need to ensure they follow these
> rules and change their implementations accordingly. If there are any
> implementations within a network that do not follow these rules, we
> are back to invalid inferences.

I.e it as exactly same problems as what modifying ESP in general
has... 

> Another observation along similar lines is any HW devices that are
> encoding additional lookup information directly into the Rx SPI
> (which is under the control of the recipient) to allow optimized Rx
> SA lookup (e.g. masking some SPI bits to extract a direct SA index
> into the SADB) will now need to be changed also. I actually did one
> of these in my previous life.

I would guess those changes would also be quite small.

On the other hand another problem with that proposal is that there is
no ICV length information there. I assume that when those were
proposed we had only ICV length of 12 to consider, but now we also
have ICV lengths of 12, 16, 20, 24, and 32 to consider...

Of course that information could also be encoded to the SPI if this
proposal would go forward, but this still has the problem you listed
first, meaning it requires changes to the all end nodes thus it will
be very slow to deploy (faster than WESP though, as the changes to
implementations would be smaller). 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 3 Dec 2008 15:16:28 +0200

> convince them to provide vs. having a deterministic approach, in my

It will be about same to get the IPsec chip vendors to provide support
for WESP. In either case silicon vendors need to implement new
functionality and it will be slow before the actual chips are out. On
the other side the good thing is that most of those complicated deep
inspection engines (and actually security processors too) are very
programmable already thus they might not require actual silicon
changes, but just some tweaking on the firmware.

> approach would not require any retooling.  Can someone explain that

If you use heuristic approach then the ESP and all end nodes would
remain intact, i.e. no changes is required to them. Also no changes
will be done on the normal firewalls or routers (i.e. the ones not
doing deep inspection).

Only devices which do require changes will be the deep inspection
middleboxes, and there the changes required for the fastpath are going
to be quite small (add SPI to the flow lookup, load ICV_len and IV_len
from the state information so they can know the offsets where the
protocol number is located and where the actual payload starts).

All the more complicated heuristics would most likely be done on the
slowpath anyways, and even there it would be too complicated (much
simplier than checking TCP headers).

Also all deep inspection engines need to load the full packet to the
deep inspection engine anyways (usually they also need to reassemble
IP fragments to get full packet, and even reorder out of order TCP
segments and remove overlapping TCP segments before doing inspection),
so I do not really belive there is any deep inspection engines where
getting the protocol number from the end of the packet would really be
problem.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 3 Dec 2008 15:27:05 +0200

Grewal, Ken writes:
> Heuristics based solutions can be expensive to implement in HW as
> well as being inconclusive, providing assurances based on
> probabilities and hence prone to false positives.

Note, that false positivies could only happen for very few first
packets, after the SPI is known to be either encrypted ESP or
ESP-NULL, then there will not be any false positives or negatives.

On the other hand implementing deep inspection on hardware on the TCP
or HTTP request is several orders of magnitude more complicated than
to check the SPI and see if that is known and do processing based on
the SPI.

> Furthermore, some HW devices (especially Network Interface Cards,
> NICs) currently only examine packet headers and do not load the
> whole packet into memory. In aggregated environments, where these
> devices need to maintain line rate processing, subtle changes in
> design such as loading the whole packet into memory and parsing the
> packet trailer before making a decision if the packet should be sent
> to one CPU core or another for processing will have drastic impact
> on the packet processing engines of such devices (compared with a
> simple, deterministic approach such as in the current draft).

In normal case NIC does not need to find the protocol number to decide
what to do with the packet, the SPI will be enough. If SPI is unknown,
then packet is dropped to CPU so CPU can run heuristics. If SPI is
known and is known to be ESP encrypted, then packet is passed directly
forward as no deep inspection can be done.

If SPI is known and is known to be ESP-NULL and SPI is marked as one
that requires deep inspection (if there is cases where ESP-NULL
packets can also be marked as bypassing deep inspection) then packet
is thrown to the deep inspection engine, which will require the full
packet anyways, so getting the protocol number from the end of the
packet will not cause any problems.
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 3 Dec 2008 09:30:25 -0700

Comments inline...

>From: Tero Kivinen [mailto:[email-masked]]
>Sent: Wednesday, December 03, 2008 5:00 AM
>To: Grewal, Ken
>Cc: Dan McDonald; [email-masked]

[Ken] Slightly different - SPI semantics requires all nodes to be upgraded before it can be deployed (else there will be collisions in SPI usage between legacy and new), whereas WESP does not require all nodes to be upgraded immediately, as it is a new protocol and can co-exist with the legacy solutions.  

>I would guess those changes would also be quite small.

[Ken] Depends on your implementation...and this will require a forklift upgrade to ensure it is collision free. 

>implementations would be smaller).

[Ken] Once we start consuming a few bits from the SPI, there will always be a need to consume some more at a later stage (new algorithms, IVs, Lengths, etc.), hence this does not make for an elegant or scalable solution.

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 3 Dec 2008 09:56:47 -0700

Some comments inline...

>Sent: Wednesday, December 03, 2008 5:27 AM
>To: Grewal, Ken
>Cc: [email-masked]
[Ken] This assumes the intermediate device HW keeps state on each flow, including knowledge of SPI, algorithms, IV lengths, etc., which is not done today. This is a huge overhead for these devices, especially using expensive SRAM to keep state and ensuring all the lookups fit into the current design / pipeline. By contrast, the WESP solution is stateless, as all needed info is carried in the packet. 

>to check the SPI and see if that is known and do processing based on
[Ken] I agree that higher layer protocol offloads such as TCP is more expensive, but this depends on your device capabilities and not all devices do TCP offload. In either case, it goes back to the comment from Dan - you want me to add state for thousands or millions of SAs into an already complicated HW design - easier way is to parse a simple protocol and make it stateless. 

>packet will not cause any problems.

[Ken] I disagree. Protocols numbers and ports are commonly used for assigning flows to a CPU core. Gone are the days of a single CPU and we are now in a world of multi-core environment. In a multi-core system, it is imperative to ensure that a given flow (e.g. TCP) is sent to the same core as the previous one with the same characteristics (protocol / ports), as that core has any state information associated with the flow. If this not done, it leads to considerable performance degradation, as data now needs to be moved between memory / cache of different cores unnecessarily. 
So, visibility into protocol / ports is imperative.  This was one of the motivations of adding the protocol number to the header, so we do not need to load the whole packet into memory to extract this from the trailer.

---

From: "Jack Kohn" <[email-masked]>
Date: Wed, 3 Dec 2008 22:30:13 +0530

>
> [Ken] Slightly different - SPI semantics requires all nodes to be upgraded before
> it can be deployed (else there will be collisions in SPI usage between legacy and

This is incorrect. There will never be a conflict as the bhatia
proposal uses a reserved SPI value, something that the legacy
implementations will never allocate.

> new), whereas WESP does not require all nodes to be upgraded immediately,
> as it is a new protocol and can co-exist with the legacy solutions.>
>>
>
>>

Why would a new algorithm require a new reserved SPI? Similarly IVs,
if required, are always a part of the payload. So whats the problem?

Jack

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 3 Dec 2008 10:06:32 -0700

Jack, 
This discussion is in the context of a different thread from the reserved SPI discussion - this is in the context of reserving bits from the SPI and the protocol / packet format remains unchanged - please see the whole thread started by Dan McDonald and Scott Moonen.

Thanks, 
- Ken

>Sent: Wednesday, December 03, 2008 9:00 AM
>To: Grewal, Ken
>Cc: [email-masked]; Dan McDonald; Tero Kivinen
>> [Ken] Once we start consuming a few bits from the SPI, there will always
>be a need to consume some more at a later stage (new algorithms, IVs,
>Lengths, etc.), hence this does not make for an elegant or scalable
>solution.
>

---

From: "Grewal, Ken" <[email-masked]>
Date: Wed, 3 Dec 2008 10:07:55 -0700

Comments inline...

>Tero Kivinen
>Sent: Wednesday, December 03, 2008 5:16 AM
>To: Gary Hemminger
>Cc: [email-masked]

[Ken] Adding knowledge about each SA based on SPI, algorithms, IV/ICV lengths, etc., when that info does not exist in the hardware is hardly tweaking. It is major surgery.

>getting the protocol number from the end of the packet would really be

[Ken] Please see my comments on the other email regarding need for protocol number in a multi-core environment.
[Ken]

---

From: "Gary Hemminger" <[email-masked]>
Date: Wed, 3 Dec 2008 13:06:20 -0800

GRE

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tero Kivinen
Sent: Wednesday, December 03, 2008 5:00 AM
To: Grewal, Ken
Cc: [email-masked]; Dan McDonald
Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 4 Dec 2008 14:36:31 +0200

[I combined the to replies to one]

Grewal, Ken writes:
> [Ken] This assumes the intermediate device HW keeps state on each
> flow, including knowledge of SPI, algorithms, IV lengths, etc.,
> which is not done today. This is a huge overhead for these devices,
> especially using expensive SRAM to keep state and ensuring all the
> lookups fit into the current design / pipeline. By contrast, the
> WESP solution is stateless, as all needed info is carried in the
> packet.

We are talking here about DEEP INSPECTION devices. All of such devices
need to be stateful to do anything useful. The ACL list based on the
TCP/UDP port numbers are not really useful for deep inspection or
protection, thus I do not consider stateless cases for this case
useful.

Almost every modern firewall / IDS / IPS system around now is already
keeping lots of state, so adding SPI there isn't really a problem.

WESP solution is stateless, and it can be used by the firewalls around
year 2020, not before. Before that firewall vendors and such still
need to provide some method of doing the same thing, thus they will
need to implement the heuristics anyways regradless whether we have
WESP or not and the only benefit for using WESP instead of heauristics
at year 2020 when both area available is that WESP can be used also
for stateless devices. The trend I am seeing is that more and more
security devices are going to be statefull even in the very small
ones, I do not think there will be that many stateless security
devices around year 2020.

Do you really see there will be lots of stateless security devices
inspecting WESP-NULL traffic around year 2020?

> [Ken] I agree that higher layer protocol offloads such as TCP is
> more expensive, but this depends on your device capabilities and not
> all devices do TCP offload. In either case, it goes back to the
> comment from Dan - you want me to add state for thousands or
> millions of SAs into an already complicated HW design - easier way
> is to parse a simple protocol and make it stateless.

If you are doing deep inspection device you need to cope with at least
10 or 100 times more of TCP/UDP flows inside single SA, so the cost of
storing the per SA information is quite small compared to the TCP/UDP
state.

I agree it would be easier, but I claim it would be completely doable,
and actually much easier than most of the things the complicated HW
designs already do. I mean there are full security prosessors out
there who can save the same amount of SA information and also keep the
track of keying material and encrypt and authenticate all packets
going in and coming out from the SA... Keeping track of the SPI, ICV
len, IV len is very simple compared to that.

And I do not think you have option, your customers will want the
solution now, not year 2020, thus you need to implement the heuristics
now anyways, and I would rather only implement one method of doing the
same thing than multiple different methods. If you do not implement
the heuristics then your competitors will implement it and you will
loose deals to them.

I am pretty much sure that our customers will require us to implement
the solution now, not in 10 years timeframe.

> [Ken] I disagree. Protocols numbers and ports are commonly used for
> assigning flows to a CPU core. Gone are the days of a single CPU and
> we are now in a world of multi-core environment. In a multi-core
> system, it is imperative to ensure that a given flow (e.g. TCP) is
> sent to the same core as the previous one with the same
> characteristics (protocol / ports), as that core has any state
> information associated with the flow. If this not done, it leads to
> considerable performance degradation, as data now needs to be moved
> between memory / cache of different cores unnecessarily.

As in this case the SPI number will be part of the flow, so IP and SPI
numberswill select the CPU core for that specific flow.

> So, visibility into protocol / ports is imperative.  This was one of
> the motivations of adding the protocol number to the header, so we
> do not need to load the whole packet into memory to extract this
> from the trailer.  

You do not need protocol or port numbers to demux packets to correct
CPU, you can simply use IP and SPI numbers for that. You already have
protocol number, that is 50, then you already have flow information
per that protocol number, i.e. the SPI, you just demux packets based
on that to the correct CPU core, and the CPU core will then demux
things further based on the inner protocol number and port numbers.

> [Ken] Adding knowledge about each SA based on SPI, algorithms,
> IV/ICV lengths, etc., when that info does not exist in the hardware
> is hardly tweaking. It is major surgery.

Most of the modern security processor I know do use microcode to do
part of the packet processing and modifying those do not require major
surgery. There are limitations how much can be done with those and
there are usually size constraints also, but this kind of changes
(i.e. using SPI for flow lookup if protocol is ESP, and loading 2
bytes of extra data (ICV_len and IV_len) when loading flow data)
should be doable with current hardware by just changing the firmware.

I already commented earlier that it is doable in our own SafeXce-5160
hardware, or Octeon from Cavium. It should also be doable in Intel
Tolapai chips too as far as I have understood things. Unfortunately I
only know security coprocessor chips, I do not know that much what
they use in deep inspection engines but I would guess they use even
more programmable devices there.

Can you give some examples in which modern chips that are used in deep
inspection devices this is not doable?
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec