[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IPSEC SMIB
IPSP "SMIB Variables"
The following are (in a very general sense) parameters for an IPSPE
SMIB. The first set are for the IPSPE in general, and the second set
are for each SA. I'm not a MIB/SMIB kind'a guy, so please excuse the
inappropriate format, etc. This is a first cut, in which I am just
trying to get the fundamental ideas across and provide a basis for
discussion. Another reason for examining these values, is that they
enter into the security attribute negotiation procedure and this list
will provide a starting point for a discussion of what should be
negotiable. I'm sure there are some things I have omitted, but I've
gotten to a point where I thought it would be useful to distribute
this brief document to the list
Steve
--------------------------------------------------------------
LOCAL-ADDRESS
This is the IP address for this IPSPE. Note that an IPSPE
at a router will need to distinguish this IP address from those
of its clients.
CLIENTS
{If this is a router implementation of IPSP, then it needs
to be aware of the addresses, or address range, for hosts that
are clients "behind" it. Depending on the key management
approach, it may be necessary to present a signed list or address
range to the peer IPSPE in order to convince it that this IPSPE
is authorized to represent the clients. However, this variable
is just the list of client address. It could be a sorted list,
by IP address, or one might adopt some form of sparse
representation, ... I'm not sure what to do here yet.}
ALGORITHMS
This structure lists the algorithms that this IPSPE is
prepared to negotiate for an SA. Each list is ordered in terms
of preference, but no algorithms should be used that would be
considered insecure. The structure is organized according to the
security services being provided. An IPSPE in an end system
should allow an application to request services from this list
for each SA created on its behalf. This is used as part of the
SA negotiation procedure. Each of these lists must contain at
least one entry if the security service is supported, but it need
not contain more than one entry.
KEY-MANAGEMENT
This is the ordered list of supported key management
techniques.
ENCRYPTION
This is the ordered list of encryption algorithms.
INTEGRITY
This is the ordered list of integrity algorithms.
COMPRESSION
This is the ordered list of compression algorithms.
{Compression of the IPSP payload is likely to be needed for low
speed IP access links when encryption is employed, due to the
loss of compression ability after encryption has been applied.}
ALGROTIHM-SELECTORS
This structure provides selectors to be applied to inbound
and outbound packets in order to determine what security services
must be negotiated for these packets. There are separate
selectors for inbound vs. outbound traffic.
OUTBOUND
In an end system, if applications always make explicit
requests for security services, this structure may be null, i.e.,
no screening is required. Otherwise, for administrative control
over what services are afforded to what traffic, this structure
is applied. In principle, each outgoing IP packet would have to
be screened against the entries in this data structure to
determine what, if any, IPSP processing is required. This could
be either a positive or a negative screen, depending on what the
most common case is. For example, if most packets will be
subject to IPSP processing, then the screen should be designed to
make that most efficient, while if only some packets are to
receive IPSP processing, then the bypass of packets should be the
most efficient outcome of the screen.
For an end system, the most likely implementation approach
would entail taking advantage of the state information present in
a streams, sockets, or similar interface. One can then screen
"connection" establishment calls to these interface to make a
determination of what IPSP processing, if any, may be applicable.
Then subsequent calls to transfer data on the established data
stream can have any IPSP processing applied automatically. In
the case of a router implementation, there is no standard
facility for maintaining the sort of state information described
above, and so every outbound packet must be screened to determine
if it is a candidate for IPSP processing.
Each entry in this data structure is nominally a triple.
The first element is a filter applied to selected fields of the
IP header and the transport layer header. The following fields
may be used for this filter, but not all fields need to be used
in all IPSPEs:
IP-DESTINATION-ADDRESS
IP-SOURCE-ADDRESS
NEXT-PROTOCOL
IP-SECURITY-LABEL
TRANSPORT-DESTINATION-PORT
TRANSPORT-SOURCE-PORT
The second element is a flag indicating whether a packet matching
the mask is or is not to be processed by IPSP. The third element
is a pointer to the SA entry if one exists for data matching this
filter, or it is an indication of the IPSP services to be
provided to this class of traffic, when an SA is established.
INBOUND
Screening is required only if the traffic is not
already IPSP protected, and if the IPSPE has a security policy
that requires IPSP use on traffic flows not initiated by its
client(s). In this case, there is a need to screen non-IPSP
packets as above and to send an ICMP Unreachable, Destination
Requires IPSP {a new ICMP sub code} message to trigger SA
establishment by the source of the traffic.
{more to be supplied ...}
---------------------------------------------------------------
The following is a set of possible parameters for each security
association (SA), e.g., candidate MIB data items where each SA
has its own MIB entry. They may be negotiated or pre-determined,
but all are important for each SA in the most general case.
SAID.INBOUND
SAID.OUTBOUND
These variables contain the SAIDs for this SA and thus are
used to select this MIB entry for IPSP protected traffic.
ENCAPSULATION
This Boolean indicates whether IPSP is used to encapsulate
packets on this SA. If TRUE, then encapsulation is employed,
otherwise packets are not encapsulated.
INBOUND-CRITERIA
This data structure specifies the checking applied to
inbound packet received on this SA before releasing the packets
to the client. Each data item is either null, or is a value
against which the inbound packet is checked. If encapsulation is
employed, the checks are applied to the encapsulated header(s),
otherwise the checks are applied to the outer header(s). {needs
work, e.g., to express star names}
IP-DESTINATION-ADDRESS
IP-SOURCE-ADDRESS
NEXT-PROTOCOL
IP-SECURITY-LABEL
TRANSPORT-DESTINATION-PORT
TRANSPORT-SOURCE-PORT
PEER-ADDRESS
This variable specifies the IP address of the IPSPE that
defines the other end of the SA. For a multicast SA, this is an
IP multicast address.
ENCRYPTION
This data structure provides the parameters required for
provision of a connectionless confidentiality service, if
employed for this SA.
ENABLED
This is a Boolean and is TRUE if encryption is to be
employed for this SA.
ALGORTIHM
This is a structured, IANA-registered algorithm ID that
also specifies the mode of use, e.g., DES-CBC or DES-EDE2-CBC, or
DES-CFB-8.
KEY.INBOUND
KEY.OUTBOUD
If the same key is used for encryption in both
directions, then the values are the same for both of these
variables, otherwise different values must be present. (For some
algorithms and modes, this value may be an interchange key, and
the key to be used to decrypt an individual packet may encrypted
by this key and carried in the packet in the manner of an IV.)
The size of the key is determined by ENCRYPTION.ALGORITHM and if
a multi-key algorithm mode is employed, e.g., DES-EDE, all of the
keys for a given direction are stored in the appropriate
variable, and the algorithm mode specifies how each key is
extracted from the variable.
IV.INBOUND
IV.OUTBOUND
If the algorithm and mode require use of an IV, and if
the IV (or a portion thereof) is constant for the SA, then these
per-SA values are stored here. The size of these variable and
the portion used in forming an IV is determined by
ENCRYPTION.ALGORITHM.
INTEGRITY
This data structure contains all of the parameters required
for provision of a connectionless integrity service, if employed
for this SA.
ENABLED
This is a Boolean that is TRUE if an integrity
transformation is applied for this SA.
PLAINTEXT
This value is TRUE if the integrity transformation is
applied to plaintext, and is FALSE if it is applied to
ciphertext; FALSE may be selected only if ENCRYPTION.ENABLED =
TRUE
DIRECTION.ENABLED
This is a Boolean that is TRUE if a direction flag is used
in packets.
DIRECTION.VALUE
This is a Boolean that specifies the one-bit direction
flag value inserted into outbound packets. The value is
meaningful only if INTEGRITY.DIRECTION.ENABLED is TRUE.
ALGORITHM
This is a structured, IANA-registered algorithm ID that
specifies the integrity algorithm employed and the mode of use,
e.g., MD5, MD5-keyed, SHA, DES-MAC, etc.
KEY.OUTBOUND
KEY.INBOUND
These items have meaning only if a keyed integrity
function is employed, as defined in INTEGRITY.ALGORITHM. If
ENCRYPTION.ENABLED = FALSE, then a keyed integrity function must
be employed, if INTEGRITY.ENABLED = TRUE. If the same key is used
in both directions, then these variables have the same value,
otherwise different values must be present. The size of key is a
function of the algorithm selected in INTEGRITY.ALGORIHTM and if
a multi-key algorithm mode is employed, all of the keys for a
given direction are stored in the appropriate variable, and the
algorithm mode specifies how each key is extracted from the
variable.
COMPRESSION
This data structure provides parameters required for
provision of compression (and corresponding decompression) of
plaintext data.
ENABLED
This Boolean is TRUE if compression is to be applied to
traffic on this SA.
ALGORITHM
This is a structured, IANA-registered algorithm ID that
specifies the compression algorithm employed.
REPLAY
This data structure provides the parameters required for
provision of replay countermeasures, if employed for this SA.
ENABLED
This Boolean is TRUE if a sequence number is included
in each outbound packet and is checked on each inbound packet for
this SA.
SIZE
This item defines the size of sequence number,
expressed in 16-bit words. {we could bound this at 64 bits}
NUMBER.OUTBOUND
This is the value of the sequence number to be assigned
to next outbound packet. The size of this variable is determined
by REPLAY.SIZE.
NUMBER.INBOUND
This is the sequence number expected in next inbound
packet; if an integrity checked packet arrives with a sequence
number greater than or equal to this value, the variable is
updated to be one greater than that received value, and
REPLAY.WINDOW is updated to reflect the received packet sequence
number.
WINDOW.SIZE
This is the size of the window within which late
arriving packets will be checked for duplication. {we could fix
this value, or allow it to be only one of a few small values,
e.g., 32/64/128, rather than allowing arbitrary window sizes}
WINDOW
This is logically an array of packet sequence numbers
for packets received within the current window. Its dimension is
REPLAY.WINDOW.SIZE. It may be implemented as a bit map, rather
than an array of sequence numbers, using OR operations and end-
off shifts to efficiently manage the list. It is checked only
when a packet arrives with a sequence number less than
REPLAY.NUMBER.INBOUND and greater than REPLAY.NUMBER.INBOUND -
REPLAY.WINDOW.SIZE + 1 (since all sequence numbers less than this
are, by definition, too old). It is updated every time a
sequence numbered packet is received
FRAGMENTATION
This data structure provides the parameters required for
provision of denial of service protection with regard to attacks
exploiting the fragmentation features of IP.
INBOUND
If FALSE, no fragments are accepted on inbound traffic,
otherwise fragments are acceptable for inbound traffic.
OUTBOUND
If FALSE, no fragments may be transmitted by the IPSPE
(unless encapsulated), otherwise fragments may be transmitted.
KEY-MANAGEMENT
This data structure provides the key management parameters
associated with this SA.
NEGOTIATED
If TRUE, then IKMP is used to negotiate the key
management technique for this SA. If FALSE, a pre-defined key
management technique is used.
TECHNIQUE
This variable specifies the key management technique
used for this SA. The identifier used here is structured, e.g.,
to specify symmetric vs. asymmetric techniques, and is IANA
registered.
PARAMETERS
Technique-specific parameters ???
REKEY
This data structure indicates what criteria are used to
determine when a new key must be established for this traffic
flow. When a new key is established, the traffic will be
migrated to a new SA, identified by the NEXT.SA pointer below.
GRACE
This is the time value (in seconds) that incoming
traffic is permitted to be processed on the old SA after a new SA
has been established, in response to a rekey.
NEXT-SA
This is a pointer to the data structure for the
new SA to which traffic will be routed when the rekey is
complete.
TIME-BASED
This data structure contains variables for time
based rekey management.
ENABLE
This Boolean is TRUE if time-based rekey
management is employed.
TRIGGER
This is a local time value that specifies
when a new key and SAID should be created, after which the
traffic for this SA will be transferred to the new SAI. This
variable should be zero unless this IPSPE initiated the SA and
unless REKEY.TIME-BASED.ENABLE is TRUE. {is this an acceptable
simplification, or should either end be able to initiate a
rekey?}
TRAFFIC-BASED
This structure contains parameters for traffic-
based rekey control.
ENABLE
This Boolean is TRUE if traffic-based rekey
management is employed.
PACKET-COUNT.INBOUND
PACKET-COUNT.OUTBOUND
These are counters for traffic that will be
used to trigger a rekey. They are maintained only if
REKEY.TRAFFIC-BASED.ENABLE is TRUE.
TRIGGER.INBOUND
TRIGGER.OUTBOUND
These are values that are compared against
the packet counters to trigger a rekey. They are non-zero only if
REKEY.TRAFFIC-BASED.ENABLE is TRUE.