Age | Commit message (Collapse) | Author | Files | Lines |
|
Type: feature
- use tunnel_encap_decap_flags to control the copying of DSCP/ECN/etc
during IPSEC tunnel mode encap.
- use DSCP value to have fixed encap value.
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: If4f51fd4c1dcbb0422aac9bd078e5c14af5bf11f
|
|
Type: improvement
Signed-off-by: Florin Coras <fcoras@cisco.com>
Change-Id: Id13f33843b230a1d169560742c4f7b2dc17d8718
|
|
Not all ESP crypto algorithms require padding/alignment to be the same
as AES block/IV size. CCM, CTR and GCM all have no padding/alignment
requirements, and the RFCs indicate that no padding (beyond ESPs 4 octet
alignment requirement) should be used unless TFC (traffic flow
confidentiality) has been requested.
CTR: https://tools.ietf.org/html/rfc3686#section-3.2
GCM: https://tools.ietf.org/html/rfc4106#section-3.2
CCM: https://tools.ietf.org/html/rfc4309#section-3.2
- VPP is incorrectly using the IV/AES block size to pad CTR and GCM.
These modes do not require padding (beyond ESPs 4 octet requirement), as
a result packets will have unnecessary padding, which will waste
bandwidth at least and possibly fail certain network configurations that
have finely tuned MTU configurations at worst.
Fix this as well as changing the field names from ".*block_size" to
".*block_align" to better represent their actual (and only) use. Rename
"block_sz" in esp_encrypt to "esp_align" and set it correctly as well.
test: ipsec: Add unit-test to test for RFC correct padding/alignment
test: patch scapy to not incorrectly pad ccm, ctr, gcm modes as well
- Scapy is also incorrectly using the AES block size of 16 to pad CCM,
CTR, and GCM cipher modes. A bug report has been opened with the
and acknowledged with the upstream scapy project as well:
https://github.com/secdev/scapy/issues/2322
Ticket: VPP-1928
Type: fix
Signed-off-by: Christian Hopps <chopps@labn.net>
Change-Id: Iaa4d6a325a2e99fdcb2c375a3395bcfe7947770e
|
|
Type: feature
thus allowing NAT traversal,
Signed-off-by: Neale Ranns <nranns@cisco.com>
Change-Id: Ie8650ceeb5074f98c68d2d90f6adc2f18afeba08
Signed-off-by: Paul Vinciguerra <pvinci@vinciconsulting.com>
|
|
Type: feature
Signed-off-by: Damjan Marion <damarion@cisco.com>
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
Signed-off-by: Fan Zhang <roy.fan.zhang@intel.com>
Signed-off-by: Piotr Bronowski <piotrx.bronowski@intel.com>
Signed-off-by: Dariusz Kazimierski <dariuszx.kazimierski@intel.com>
Signed-off-by: Piotr Kleski <piotrx.kleski@intel.com>
Change-Id: I4c3fcccf55c36842b7b48aed260fef2802b5c54b
|
|
Type: feature
Change-Id: Ifee2b3dca85ea915067b9285e3636802bf0c19a8
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
the sequence number increment and the anti-replay window
checks must be atomic. Given the vector nature of VPP we
can't simply use atomic increments for sequence numbers,
since a vector on thread 1 with lower sequence numbers could
be 'overtaken' by packets on thread 2 with higher sequence
numbers.
The anti-replay logic requires a critical section, not just
atomics, and we don't want that.
So when the SA see the first packet it is bound to that worker
all subsequent packets, that arrive on a different worker,
are subject to a handoff.
Type: feature
Change-Id: Ia20a8645fb50622ea6235ab015a537f033d531a4
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
APIs for dedicated IPSec tunnels will remain in this release and are
used to programme the IPIP tunnel protect. APIs will be removed in a
future release.
see:
https://wiki.fd.io/view/VPP/IPSec
Type: feature
Change-Id: I0f01f597946fdd15dfa5cae3643104d5a9c83089
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Type: fix
Change-Id: I382499061ff4b1c2cc1b70ebbf9725ff0e1be325
Signed-off-by: Filip Tehlar <ftehlar@cisco.com>
|
|
Instead of all clients directly RR sourcing the entry they are tracking,
use a deidcated 'tracker' object. This tracker object is a entry
delegate and a child of the entry. The clients are then children of the
tracker.
The benefit of this aproach is that each time a new client tracks the
entry it doesn't RR source it. When an entry is sourced all its children
are updated. Thus, new clients tracking an entry is O(n^2). With the
tracker as indirection, the entry is sourced only once.
Type: feature
Change-Id: I5b80bdda6c02057152e5f721e580e786cd840a3b
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
- this remove the need to iterate through all state when deleting an SA
- and ensures that if the SA is deleted by the client is remains for use
in any state until that state is also removed.
Type: feature
Change-Id: I438cb67588cb65c701e49a7a9518f88641925419
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
please consult the new tunnel proposal at:
https://wiki.fd.io/view/VPP/IPSec
Type: feature
Change-Id: I52857fc92ae068b85f59be08bdbea1bd5932e291
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
An SA can be used only for ESP or AH nver both, so it needs only one
coresponding DPO.
Type: refactor
Change-Id: I689060f795ee352245a0eaed0890a6b234c63d71
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
there's no use case to just change the key of an SA. instead the SA
should be renegociated and the new SA applied to the existing SPD entry
or tunnel.
the set_key functions were untested.
Type: refactor
Change-Id: Ib096eebaafb20be7b5501ece5a24aea038373002
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: I45618347e37440263270baf07b2f82f653f754a5
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Icd76769d841792eb2d59ffc23c557dcca9ddc580
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Crypto algorithms have different requirements on key length. As we do
not support key stretching (eg. PBKDF2), user must provide the exact
key length used by the algorithm.
Failing that means low-level crypto functions might read garbage (eg.
aes128_key_expand() will read 16-bytes, regardless of the key provided
by the user).
Change-Id: I347a1ea7a59720a1ed07ceaad8b00a31f78458c9
Signed-off-by: Benoît Ganne <bganne@cisco.com>
|
|
Change-Id: Ide2a9df18db371c8428855d7f12f246006d7c04c
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: If96f661d507305da4b96cac7b1a8f14ba90676ad
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Id2ddb77b4ec3dd543d6e638bc882923f2bac011d
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
refactor the IPSEC tests a bit so we can parameterise
the setup.
Change-Id: I777e5eb8f29ca1dce3dd273ebd05dae5846790af
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Iff6f81a49b9cff5522fbb4914d47472423eac5db
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Idb661261c2191adda963a7815822fd7a27a9e7a0
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I0b47590400aebea09aa1b27de753be638e1ba870
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Icf83c876d0880d1872b84e0a3d34be654b76149f
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ib828ea5106f3ae280e4ce233f2462dee363580b7
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: I81ecdf9fdcfcb017117b47dc031f93208e004d7c
Signed-off-by: Damjan Marion <damarion@cisco.com>
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ibe7f806b9d600994e83c9f1be526fdb0a1ef1833
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
Change-Id: Ie8986bd3652d25c4befe681cea77df95aba37ebc
Signed-off-by: Damjan Marion <damarion@cisco.com>
|
|
1) stats are accessed via the stat segment which is more condusive to
monitoring
2) stats are accurate in the presence of multiple threads. There's no
guarantee that an SA is access from only one worker.
Change-Id: Id5e217ea253ddfc9480aaedb0d008dea031b1148
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
Change-Id: Ib2ad196bec1005d6678589d5b5c199b8a541c720
Signed-off-by: Kingwel Xie <kingwel.xie@ericsson.com>
|
|
Change-Id: I5852ca02d684fa9d59e1690efcaca06371c5faff
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
in the same maaner as with other tunnel tyeps we use
the FIB to cache and track the destination used to reach
the tunnel endpoint. Post encap we can then ship the packet
straight to this adjacency and thus elide the costly second
lookup.
- SA add and del function so they can be used both directly
from the API and for tunnels.
- API change for the SA dump to use the SA type
- ipsec_key_t type for convenience (copying, [un]formating)
- no matching tunnel counters in ipsec-if-input
Change-Id: I9d144a59667f7bf96442f4ca66bef5c1d3c7f1ea
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
- return the stats_index of each SPD in the create API call
- no ip_any in the API as this creates 2 SPD entries. client must add both v4 and v6 explicitly
- only one pool of SPD entries (rhter than one per-SPD) to support this
- no packets/bytes in the dump API. Polling the stats segment is much more efficient
(if the SA lifetime is based on packet/bytes)
- emit the policy index in the packet trace and CLI commands.
Change-Id: I7eaf52c9d0495fa24450facf55229941279b8569
Signed-off-by: Neale Ranns <nranns@cisco.com>
|
|
No function change. Only breaking the monster ipsec.[hc]
into smaller constituent parts
Change-Id: I3fd4d2d041673db5865d46a4002f6bd383f378af
Signed-off-by: Neale Ranns <nranns@cisco.com>
|