[Swan] IPsec PFP support on linux

[Sowmini Varadhan]

On (05/03/17 13:09), Paul Wouters wrote:
> I'm not familiar with those acronyms, and do not understand what
> "retaining entropy" means.

entropy: see, for example, the figure in
http://www.brocade.com/content/html/en/brocade-validated-design/brocade-ip-fabric-bvd/GUID-2CCB485C-96B8-4D18-AF70-2EF7EEC33C95.html

There are 4 equal cost paths between a node in rack1 and
a node in rack2 (because you go up to the leaf, and there
are 4 spine switches to choose from). (and the attractive
property of the spine-leaf, aka CLOS, architecture, is that
you can scale this easily by adding more spine switches, so
it grows easily)

So for things like vxlan etc (basically anything that tunnels
over udp, including RoCE) the recommendation is to randomize
the udp src port. The switches calculate a hash based
on the udp (saddr, sport, faddr, fport) 4-tuple/flow, and
will spread flows across the 4 available paths. The hash
will stay the same for any given flow so packets will
not get re-ordered within the flow. The 4-tuple is 
provides the "entropy".
 https://tools.ietf.org/html/draft-ietf-nvo3-dataplane-requirements-03

Entropy can come from other sources as well, e.g., from
the mpls label:
  https://datatracker.ietf.org/doc/rfc6790/?include_text=1
IPv6 flow id, or, even SPI:
  https://tools.ietf.org/html/draft-herbert-gue-00

BTW, even in tunnel mode, you can have traffic from different tenants
taking different spine paths by giving them either different udp sports,
or by giving them different SPIs..

Retaining entropy: if I send my udp traffic in the clear,
each sport can be used to get a different spine path.

After IPsec, without PFP, unless the client does an explicit
bind (which most clients dont) the sadb/spd end up being something
like *.5001 or 5001.*, so you end up clumping all the sports into
2 SPIs, thereby losing parallelism.


--Sowmini