docs: networking: convert xfrm_sync.txt to ReST
- add SPDX header; - add a document title; - adjust titles and chapters, adding proper markups; - mark code blocks and literals as such; - adjust identation, whitespaces and blank lines where needed; - add to networking/index.rst. Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
parent
da62baada5
commit
a5cfea33e5
|
@ -119,6 +119,7 @@ Contents:
|
||||||
x25
|
x25
|
||||||
xfrm_device
|
xfrm_device
|
||||||
xfrm_proc
|
xfrm_proc
|
||||||
|
xfrm_sync
|
||||||
|
|
||||||
.. only:: subproject and html
|
.. only:: subproject and html
|
||||||
|
|
||||||
|
|
|
@ -1,3 +1,8 @@
|
||||||
|
.. SPDX-License-Identifier: GPL-2.0
|
||||||
|
|
||||||
|
====
|
||||||
|
XFRM
|
||||||
|
====
|
||||||
|
|
||||||
The sync patches work is based on initial patches from
|
The sync patches work is based on initial patches from
|
||||||
Krisztian <hidden@balabit.hu> and others and additional patches
|
Krisztian <hidden@balabit.hu> and others and additional patches
|
||||||
|
@ -40,30 +45,32 @@ The netlink message types are:
|
||||||
XFRM_MSG_NEWAE and XFRM_MSG_GETAE.
|
XFRM_MSG_NEWAE and XFRM_MSG_GETAE.
|
||||||
|
|
||||||
A XFRM_MSG_GETAE does not have TLVs.
|
A XFRM_MSG_GETAE does not have TLVs.
|
||||||
|
|
||||||
A XFRM_MSG_NEWAE will have at least two TLVs (as is
|
A XFRM_MSG_NEWAE will have at least two TLVs (as is
|
||||||
discussed further below).
|
discussed further below).
|
||||||
|
|
||||||
aevent_id structure looks like:
|
aevent_id structure looks like::
|
||||||
|
|
||||||
struct xfrm_aevent_id {
|
struct xfrm_aevent_id {
|
||||||
struct xfrm_usersa_id sa_id;
|
struct xfrm_usersa_id sa_id;
|
||||||
xfrm_address_t saddr;
|
xfrm_address_t saddr;
|
||||||
__u32 flags;
|
__u32 flags;
|
||||||
__u32 reqid;
|
__u32 reqid;
|
||||||
};
|
};
|
||||||
|
|
||||||
The unique SA is identified by the combination of xfrm_usersa_id,
|
The unique SA is identified by the combination of xfrm_usersa_id,
|
||||||
reqid and saddr.
|
reqid and saddr.
|
||||||
|
|
||||||
flags are used to indicate different things. The possible
|
flags are used to indicate different things. The possible
|
||||||
flags are:
|
flags are::
|
||||||
XFRM_AE_RTHR=1, /* replay threshold*/
|
|
||||||
XFRM_AE_RVAL=2, /* replay value */
|
XFRM_AE_RTHR=1, /* replay threshold*/
|
||||||
XFRM_AE_LVAL=4, /* lifetime value */
|
XFRM_AE_RVAL=2, /* replay value */
|
||||||
XFRM_AE_ETHR=8, /* expiry timer threshold */
|
XFRM_AE_LVAL=4, /* lifetime value */
|
||||||
XFRM_AE_CR=16, /* Event cause is replay update */
|
XFRM_AE_ETHR=8, /* expiry timer threshold */
|
||||||
XFRM_AE_CE=32, /* Event cause is timer expiry */
|
XFRM_AE_CR=16, /* Event cause is replay update */
|
||||||
XFRM_AE_CU=64, /* Event cause is policy update */
|
XFRM_AE_CE=32, /* Event cause is timer expiry */
|
||||||
|
XFRM_AE_CU=64, /* Event cause is policy update */
|
||||||
|
|
||||||
How these flags are used is dependent on the direction of the
|
How these flags are used is dependent on the direction of the
|
||||||
message (kernel<->user) as well the cause (config, query or event).
|
message (kernel<->user) as well the cause (config, query or event).
|
||||||
|
@ -80,23 +87,27 @@ to get notified of these events.
|
||||||
-----------------------------------------
|
-----------------------------------------
|
||||||
|
|
||||||
a) byte value (XFRMA_LTIME_VAL)
|
a) byte value (XFRMA_LTIME_VAL)
|
||||||
|
|
||||||
This TLV carries the running/current counter for byte lifetime since
|
This TLV carries the running/current counter for byte lifetime since
|
||||||
last event.
|
last event.
|
||||||
|
|
||||||
b)replay value (XFRMA_REPLAY_VAL)
|
b)replay value (XFRMA_REPLAY_VAL)
|
||||||
|
|
||||||
This TLV carries the running/current counter for replay sequence since
|
This TLV carries the running/current counter for replay sequence since
|
||||||
last event.
|
last event.
|
||||||
|
|
||||||
c)replay threshold (XFRMA_REPLAY_THRESH)
|
c)replay threshold (XFRMA_REPLAY_THRESH)
|
||||||
|
|
||||||
This TLV carries the threshold being used by the kernel to trigger events
|
This TLV carries the threshold being used by the kernel to trigger events
|
||||||
when the replay sequence is exceeded.
|
when the replay sequence is exceeded.
|
||||||
|
|
||||||
d) expiry timer (XFRMA_ETIMER_THRESH)
|
d) expiry timer (XFRMA_ETIMER_THRESH)
|
||||||
|
|
||||||
This is a timer value in milliseconds which is used as the nagle
|
This is a timer value in milliseconds which is used as the nagle
|
||||||
value to rate limit the events.
|
value to rate limit the events.
|
||||||
|
|
||||||
3) Default configurations for the parameters:
|
3) Default configurations for the parameters:
|
||||||
----------------------------------------------
|
---------------------------------------------
|
||||||
|
|
||||||
By default these events should be turned off unless there is
|
By default these events should be turned off unless there is
|
||||||
at least one listener registered to listen to the multicast
|
at least one listener registered to listen to the multicast
|
||||||
|
@ -108,6 +119,7 @@ we also provide default threshold values for these different parameters
|
||||||
in case they are not specified.
|
in case they are not specified.
|
||||||
|
|
||||||
the two sysctls/proc entries are:
|
the two sysctls/proc entries are:
|
||||||
|
|
||||||
a) /proc/sys/net/core/sysctl_xfrm_aevent_etime
|
a) /proc/sys/net/core/sysctl_xfrm_aevent_etime
|
||||||
used to provide default values for the XFRMA_ETIMER_THRESH in incremental
|
used to provide default values for the XFRMA_ETIMER_THRESH in incremental
|
||||||
units of time of 100ms. The default is 10 (1 second)
|
units of time of 100ms. The default is 10 (1 second)
|
||||||
|
@ -120,37 +132,45 @@ in incremental packet count. The default is two packets.
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
a) XFRM_MSG_GETAE issued by user-->kernel.
|
a) XFRM_MSG_GETAE issued by user-->kernel.
|
||||||
XFRM_MSG_GETAE does not carry any TLVs.
|
XFRM_MSG_GETAE does not carry any TLVs.
|
||||||
|
|
||||||
The response is a XFRM_MSG_NEWAE which is formatted based on what
|
The response is a XFRM_MSG_NEWAE which is formatted based on what
|
||||||
XFRM_MSG_GETAE queried for.
|
XFRM_MSG_GETAE queried for.
|
||||||
|
|
||||||
The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
|
The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
|
||||||
*if XFRM_AE_RTHR flag is set, then XFRMA_REPLAY_THRESH is also retrieved
|
* if XFRM_AE_RTHR flag is set, then XFRMA_REPLAY_THRESH is also retrieved
|
||||||
*if XFRM_AE_ETHR flag is set, then XFRMA_ETIMER_THRESH is also retrieved
|
* if XFRM_AE_ETHR flag is set, then XFRMA_ETIMER_THRESH is also retrieved
|
||||||
|
|
||||||
b) XFRM_MSG_NEWAE is issued by either user space to configure
|
b) XFRM_MSG_NEWAE is issued by either user space to configure
|
||||||
or kernel to announce events or respond to a XFRM_MSG_GETAE.
|
or kernel to announce events or respond to a XFRM_MSG_GETAE.
|
||||||
|
|
||||||
i) user --> kernel to configure a specific SA.
|
i) user --> kernel to configure a specific SA.
|
||||||
|
|
||||||
any of the values or threshold parameters can be updated by passing the
|
any of the values or threshold parameters can be updated by passing the
|
||||||
appropriate TLV.
|
appropriate TLV.
|
||||||
|
|
||||||
A response is issued back to the sender in user space to indicate success
|
A response is issued back to the sender in user space to indicate success
|
||||||
or failure.
|
or failure.
|
||||||
|
|
||||||
In the case of success, additionally an event with
|
In the case of success, additionally an event with
|
||||||
XFRM_MSG_NEWAE is also issued to any listeners as described in iii).
|
XFRM_MSG_NEWAE is also issued to any listeners as described in iii).
|
||||||
|
|
||||||
ii) kernel->user direction as a response to XFRM_MSG_GETAE
|
ii) kernel->user direction as a response to XFRM_MSG_GETAE
|
||||||
|
|
||||||
The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
|
The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
|
||||||
|
|
||||||
The threshold TLVs will be included if explicitly requested in
|
The threshold TLVs will be included if explicitly requested in
|
||||||
the XFRM_MSG_GETAE message.
|
the XFRM_MSG_GETAE message.
|
||||||
|
|
||||||
iii) kernel->user to report as event if someone sets any values or
|
iii) kernel->user to report as event if someone sets any values or
|
||||||
thresholds for an SA using XFRM_MSG_NEWAE (as described in #i above).
|
thresholds for an SA using XFRM_MSG_NEWAE (as described in #i above).
|
||||||
In such a case XFRM_AE_CU flag is set to inform the user that
|
In such a case XFRM_AE_CU flag is set to inform the user that
|
||||||
the change happened as a result of an update.
|
the change happened as a result of an update.
|
||||||
The message will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
|
The message will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
|
||||||
|
|
||||||
iv) kernel->user to report event when replay threshold or a timeout
|
iv) kernel->user to report event when replay threshold or a timeout
|
||||||
is exceeded.
|
is exceeded.
|
||||||
|
|
||||||
In such a case either XFRM_AE_CR (replay exceeded) or XFRM_AE_CE (timeout
|
In such a case either XFRM_AE_CR (replay exceeded) or XFRM_AE_CE (timeout
|
||||||
happened) is set to inform the user what happened.
|
happened) is set to inform the user what happened.
|
||||||
Note the two flags are mutually exclusive.
|
Note the two flags are mutually exclusive.
|
Loading…
Reference in New Issue