| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
(IKEv2 equiv cp_payload) and data_attribute (IKEv2 equiv configuration_attribute) payload types. Did not combine with IKEv2 because it wasn't trivial to do so. This might be a task worth investigating in the future, because there is a decent amount of shared code here.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
messages.
|
| |
|
| |
|
|
|
|
|
| |
Since INFORMATIONAL "exchanges" are actually unidirectionally sent
message we don't have any responder rules.
|
|
|
|
|
| |
These are basically the same as for ID_PROT but no payloads are expected
to be encrypted (at least if using PSK or signatures for authentication).
|
|
|
|
|
| |
These rules are quite broad and cover main mode with at least PSK and
signature based authentication.
|
| |
|
|
|
|
| |
Payloads
|
| |
|
|
|
|
| |
Mostly found by 'codespell'.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
invocation twice
|
| |
|
| |
|
| |
|
|
|
|
| |
payload type
|
|
|
|
| |
sufficient
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
integrity and syntax errors
|
| |
|
| |
|
| |
|
| |
|
|
|