One document matched: draft-hares-i2nsf-slss-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC6241 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6241.xml">
<!ENTITY RFC6317 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6317.xml">
<!ENTITY RFC7296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7296.xml">
<!ENTITY RFC7401 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7401.xml">
<!ENTITY I-D.moskowitz-sse SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.moskowitz-sse.xml">
<!ENTITY I-D.hares-i2nsf-mgtflow-reqs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.hares-i2nsf-mgtflow-reqs.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-hares-i2nsf-slss-00.txt" ipr="trust200902">
<front>
<title abbrev="SSLS">Secure Session Layer Services</title>
<author fullname="Susan Hares" initials="S." surname="Hares">
<organization> Huawei </organization>
<address>
<postal>
<street></street>
<city>Saline</city>
<country>US</country>
</postal>
<email>shares@ndzh.com </email>
</address>
</author>
<author fullname="Robert Moskowitz" initials="R" surname="Moskowitz">
<organization>HTT Consulting</organization>
<address>
<postal>
<street></street>
<city>Oak Park</city>
<region>MI</region>
<code>48237</code>
<country>USA</country>
</postal>
<phone>+1-248-968-9809</phone>
<email>rgm@htt-consult.com</email>
</address>
</author>
<date year="2016" />
<area>Routing Area</area>
<workgroup>I2NSF</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2NSF</keyword>
<keyword>Secure Session Layer Services</keyword>
<keyword>SSLS</keyword>
<abstract>
<t> Each I2NSF agent and I2NSF client needs to provide
application level support for management traffic during
periods of DDoS and network security attacks to
deal with congestion (burst and/or continuous),
high error rates and packet loss due to the attacks,
and the inability to utilize a transport protocol (E.g. TCP)
due to a specific protocol attack. This application
level support needs to be able to select the key management system
and provide "chunking" of data (in order to fit in reduced
effective MTUs), compression of data (in order to fit into
reduced bandwidth), small security envelope )in order to maximize room
for mangement payload), and fragmentation and reassembly
at the application layer for those protocols which do not support
fragmentation/reassembly (E.g. UDP or SMS). The application
layer needs to be able to turn off this features if the system
detects these features are no longer needed.
</t>
<t>
This draft specifies a security session layer services(SSLs) which provide
these features in terms of an API, and the component features
(interface to key management systems, data compression, chunking of data,
secure session envelope (SSE) to send data, and fragmentation and
reassembly, and ability to detect existence of attack).
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> Each I2NSF agent and I2NSF client needs to provide
application level support for management traffic during
periods of DDoS and network security attacks to
deal with congestion (burst and/or continuous),
high error rates and packet loss due to the attacks,
and the inability to utilize a transport protocol (E.g. TCP)
due to a specific protocol attack. Some of the services
the I2NSF controller must provide during these periods of
DDoS or network security attacks are:
<list style="symbols">
<t>receiving information regarding DDoS Threats from DOTS systems,
</t>
<t>Changing policy on vNSF and NSF devices during these periods, </t>
<t>exchanging information with user security applications using I2NSF
to obtain information from the controller,</t>
<t>Aid the I2NSF reporting of attacks with the the CERT (MILE)
either by providing data or sendign the report
</t>
<t> and manages network connnectivity of devices out of compliance (SACM).</t>
</list>
</t>
<t>
This application level support for I2NSF client-agent communication
needs to be able to select the key management system
and provide "chunking" of data (in order to fit in reduced
effective MTUs), compression of data (in order to fit into
reduced bandwidth), small security envelope )in order to maximize room
for mangement payload), and fragmentation and reassembly
at the application layer for those protocols which do not support
fragmentation/reassembly (E.g. UDP or SMS). The application
layer needs to be able to turn off this features if the system
detects these features are no longer needed.
</t>
<t>
This draft specifies a security session layer (SSL) which provides
these features in terms of:
<list style="symbols">
<t>an API for the layer (section 2)
</t>
<t>interface to key management system (section 3), </t>
<t>data compression (section 4)
</t>
<t>chunking of data (section 5)
</t>
<t>secure envelope (section 6), </t>
<t>fragmentation and reassembly (section 7),
</t>
<t>detection of network conditions that require this service
(section 8).</t>
</list>
A diagram of the SSLS with these process is in figure 1.
</t>
<t>
The API for this SSLS allows the application to select
the types of key management, and the different types of
services (data compression, chunking of data,
secure e)
</t>
<t>
<figure>
<artwork>
Secure Session Layer Services(SSLS)
| API |
| |
+------------------------------+
| | Key Mangement(KMP) |
| |........................|
| | Detection of network |
| | conditions + selection |
| | of transport (optional |
| | proprietary code) |
| .........................|
|SSLS | Compression (GPComp) |
| |........................|
| | Chunking of data |
| | (this draft) |
| .........................|
| | Session Security |
| | Envelope (SSE) |
| |........................|
| | fragmentation and |
| | reassembly at |
| | application layer |
| | (This draft) |
+------------------------------+
</artwork>
</figure>
</t>
</section>
<section title="API for SSLS">
<section title="SSLS socket calls">
<t>The SSLS uses socket calls to set up the application session layer.
The calls are shown below.
</t>
<t> s = int socket(int domain, int type, int protocol) </t>
<t>where: </t>
<t>
<list>
<t> domain: AF_INET and AF_INET6 supported </t>
<t> type: SOCK_SSLS</t>
<t> desired protocol: Transport protocol (TCP (6), UDP (6), SCTP (132)), SMS (xx) </t>
</list>
</t>
<t>
<figure>
<artwork>
int setsockopt(int sockfd, int level, int optname,
const void *optval, socklen_t optlen);
int getsocketopt(int sockfd, int level, int optname
const void *optval, socket
where:
sockfd: # socket file descriptor
optname: # option name (see below)
optval; # points to *sse_transport structure;
optlen; # length of option
optnam:
SSLS_AUTH_PRIV ]1]
SSLS_AES_MODE[2]
SSLS_ALGS[3]
SSLS_SSE [4]
Where the opt_val structure are define in the figure below.
Figure 2
</artwork>
</figure>
</t>
<section title="KMP related options">
<t>
<figure>
<artwork>
Security Keying structures for:
SSLS_AUTH_PRV, SSLS_AES_MODE, SSLS_ALGS
options of setsockopt, getsockopt
#struture for SSL_AUTH-PRIV optval
struct *ssls_auth-priv_opts {
*ssls-x509-auth [SSLS-X509-LIMIT]
}
#SSL-X509-limit
typedef struct ssls-x509-auth {
const char name;
void *x509-cert; #cert struture by API
}
#structure for SSL_AES_MODE optval
struct *ssls_aes_mode_opts {
... IKEV2 options # openikev2 API
... HIPv2 options # HIPv2 API
#[RFC6317 + HIPv2]
struct ssls_algs_opts;
}
#compression options
struct *ssls_algs_opts {
boolean gpcomp-kmp; # computed with keys
enum gmcomp-type; #
}
figure 3: setsockopt structure
for KMP related optins
</artwork>
</figure>
</t>
</section>
<section title="SSE Envelope related options">
<t>
<figure>
<artwork>
Security Session Envelope Related options
#structure for SSL_SSE optval
# SPI - is generated by KMP
# SSE - sequence number - by SSE
# Flags = Fragment (5 bits [0-5],
struct *ssls_sse_opts {
int nt_sockfd; # new transport socket
int *protocol; # transport protocol for SSLS SSE
# can choose from (1-n )
int *known_ports # known ports
int chunk-size; # chunk size
int frag-size; # fragment size
# greater than 0 means fragment]
int SSEs-at-once # number of SSEs sent at once
enum SSE_size; # (compact, large, extreme)
enum SSE-FLAG; # compression flags
);
Figure 4
</artwork>
</figure>
</t>
</section>
</section>
<section title="OpenSSL X.509 API calls used">
<t>TBD </t>
</section>
<section title="HIPv2 API calls used">
<t>(API calls will be added later based
on HIP <xref target="RFC6317"></xref> upgraded
to HIPv2.
</t>
<section title="HIP Structures">
<t>
<figure>
<artwork>
struct addrinfo {
int ai_flags; /* e.g., AI_CANONNAME */
int ai_family; /* e.g., AF_HIP */
int ai_socktype; /* e.g., SOCK_STREAM */
int ai_protocol; /* 0 or IPPROTO_HIP */
socklen_t ai_addrlen; /* size of *ai_addr */
struct sockaddr *ai_addr; /* sockaddr_hip */
char *ai_canonname; /* canon. name of the host */
struct addrinfo *ai_next; /* next endpoint */
int ai_eflags; /* RFC 5014 extension */
};
</artwork>
</figure>
</t>
</section>
<section title="HIP KMP calls">
<t>
<figure>
<artwork>
#HIP uses
# #include <netdb.h>
int getaddrinfo(const char *nodename,
const char *servname,
const struct addrinfo *hints,
struct addrinfo **res)
void free_addrinfo(struct addrinfo *res)
Figure 3
</artwork>
</figure>
</t>
</section>
</section>
</section>
<section title="Data Compression">
<t> The first step in making the application data
easier to send through the network is to compress the
data. The data compression algorithm is defined
in draft-moskowitz-gpcomp-00.txt. The result of
the compressed data is handed to the
chunking function.
</t>
<t>
The user can disable or enable the compression function
by setting SSE-DATA types to be one of the following:
<list style="symbols">
<t>SSLS compress only - set compression, [1]</t>
<t>SSLS compression and fragmentation [3],</t>
</list>
</t>
<t>Setting this flag to:
<list style="symbols">
<t> no compression or fragmentation [0], </t>
<t> SSLS to fragmentation only [2] </t>
</list>
will skip the data compression step.
</t>
</section>
<section title="SSLS Processes">
<section title="Chunking of Data">
<t>
The process that "chunks" data breaks down the
application stream after the compression process.
If the compression process has compressed the data,
the chunking process will chunk compressed data.
If the user has requested no compression, this
chunking process will chunk uncompressed data.
The size of chunks of data the SSLS process
creates to encapsulate in the secure session envelope (SSE)
is specified on SSL_SSE setsockopt call.
</t>
<t>
The secure session envelope must be bigger
than the chunk.
</t>
<t>
If the SSE is using TCP or STCP, that assembles
the application flow into a byte stream, then
the SSE packages will contain a chunk within the
secure session envelope.
</t>
<t>
If Transports that do not fragment and re-assembly
are being specified, the SSL will support
application layer fragmentation and reassembly.
(see the fragmentation section below
</t>
</section>
<section title="Secure Session Envelope">
<t>
The Secure Session Envelope (SSE) creates a secure envelope
using the SPI created by the key management and running
over the transport selected by the user. The SSE has three
forms: compact, Large, Extreme. The SSE compact form is
below in figure x. SSL defines 4 bytes of the reserved field in the FLAGS field.
See <xref target="I-D.moskowitz-sse"></xref> for details on
secure session envelope sizes and formats.
</t>
<t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Payload and ICV (Variable) |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 3
4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Reserve |C|
+---------------+
| Flag field |
+---------------+
Figure 5 - Compact format of SSE
</artwork>
</figure>
</t>
<t>
The SSLS utilizes 6 bits of the 8 bit flag in order
to provide provide fragmentation and reassembly checks
when the SSE gets fragmented into multiple transport packets.
Each time the SSE fragments the packet to fit in the transport,
it increments the fragment count in bits [24-28].
The bits for the flag word shown in figure 6.
</t>
<t>
<figure>
<artwork>
2 3
4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|Frag |R R|C|
+---------------+
| Flag field |
+---------------+
Flag work in SSE header
Bits [4-8] - 1-30 bit value for the fragment number
0 - no fragmentation
31 - indicates an fragmentation ACK response
Bits 5-6 - reserved
Bit 7 - compression
Figure 6 - SSLS redefined SSE Flag byte
</artwork>
</figure>
</t>
</section>
<section title="Application Packet Fragmentation and Reassembly">
<t>
SSE's secure envelope may be passed over UDP to avoid transport-level
security attacks. Alternatively SSE's secure transport may go over the
extremely limited SMS fabric so that some security management information
gets through. In both cases, the user (or the "detection log") can
select the transport and fragmentation.
</t>
<t>If fragmentation is turned on, the
individual SSE envelopes will track the IP messages the SSE envelope is
broken into by placing the fragment number in the lowest 5 bits of the
SSE Flag byte [24-28]. The SSE process receiving the traffic will send
back an acknowledge SSE packet [Flag value in bits 0-4 is 0x1F or 31] within
30 bit map of sequences acked [1-30] in first 4 bits of SSE data.
It is anticipate that the fragmentation process will attempt to
bundle some acks.
</t>
<t>
<figure>
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI | FLAGS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Payload and ICV (Variable) [4 byte flag word] [data]|
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2 3
4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|1|1|1|1|1|0|0|C|
+---------------+
| Flag field |
+---------------+
SSLS Fragment ACK
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| bit mask ack for fragments [0-31] |
+---------------------------------------------------------------+
[bit 0, 31 - are illegal, bit [1-31] fragments of sequence # ]
Figure 7 - SSLS ACK flag filed and first 4 bytes of payload
</artwork>
</figure>
</t>
<t>An example Fragmentation and ACK exchange
<figure>
<artwork>
SSLS-process-1--------IP/SMS---------SSLS Process-2
[E.g. I2NSF Client -----------------I2NSF Agent]
SSE-packet (SPI,(flags(fragment=1,C=1),
length, seq 1, data )---->
SSE-packet (SPI,(flags(fragment=2,C=1),
length, seq 1, data )---->
SSE-packet (SPI,(flags(fragment=3,C=1),
length, seq 1, data )---->
SSE-packet (SPI,(flags(fragment=1,C=1),
length, seq 2, data )---->
SSE-packet (SPI,(flags(fragment=2,C=1),
length, seq 2, data )---->
<--SSE-packet (SPI)(flags fragment=31,C=1)
length, seq1,[ack-fragment 1,2])
<--SSE-packet (SPI)(flags fragment=32,C=1)
length, seq2,[ack-fragment1,2]
SSE-packet (SPI,(flags(fragment=3,C=1),
length, seq 1, data )---->
<--SSE-packet (SPI)(flags fragment=31,C=1)
length, seq1,[ack-fragment 3])
</artwork>
</figure>
</t>
<t> Below is a set of pseudo call for the calls to socket
<figure>
<artwork>
pseudo
struct sse_opts = {};
optlen=size(sse_opts);
optname= SSLS_SSE; #4
s = int socket(int domain, int type, int protocol)
errno = int setsockopt(sockfd,level,optname,
void struct *sse_opts,optlen);
Errors: (Exact ERNOS added later)
- protocol not support
- error in known ports
- error in chunk_size
- error in fragment size
- error in SSE-at-once
- error - unsupported SSE
- error in compression flags
[Add read-write to socket ]
</artwork>
</figure>
</t>
<t>
The SSE window size for fragmentation is 30 IP fragments or 30 SMS fragments
per SSE chunk. The SSE process SHOULD assign the SSE fragments in order if possible.
The SSE process will send an error response to the SSE if the data chunk
does not fit in 30 IP/SM fragments.
</t>
<t>If the SSE transmitting process has not received an acknowlegement
for all IP fragments for a particular SSE envelope (identified by sequence number) with
a SSE-retransmit-time, it sill retransmit the unacknowledged fragments.
</t>
<t>
Several SSE envelopes may be sent with fragmentation at once.
The user signals the number sent at once with multiple SSE with fragment variable on
the options. If fragmentation is selected, each of these SSE envelopes
may need to track up to 30 IP fragments.
</t>
</section>
<section title="Proprietary Plugins: Detect Conditions + Select Transport">
<t>The SSL process allows two properitary plugins:
<list style="numbers">
<t>Plugin to detect error conditions
which require SSLS services which include:
<list style="symbols">
<t>High levels of end-to-end congestion,</t>
<t>High levels of error and loss, </t>
<t>Input from IDS/IPS that detects problems</t>
<t>Signals from other I2NSF applications</t>
</list>
</t>
<t>Proprietary actions may select transport
based on input from other standardize security services
(DOTS, CERT, MILE) or proprietary services.</t>
</list>
</t>
<t>Prototype code will provide instances to show
plugin values.
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
TBD
</t>
</section>
<section title="Security Considerations">
<t>The SSLS shares the following security considerations with the
SSE Technology:
<list style="symbols">
<t>
As SSE uses an AEAD block cipher, it is vulnerable to attack if a
sequence number is reused for a given key. Thus implementations of
SSE MUST provide for rekeying prior to Sequence Number rollover. An
implementation should never assume that for a given context, the
sequence number space will never be exhausted. Key Management
Protocols like IKEv2 <xref target="RFC7296"/> or HIP <xref
target="RFC7401"/> could be used to provide for rekeying
management. The KMP SHOULD not create a network layer fate-sharing
limitation.
</t>
<t>
As any security protocol can be used for a resource exhaustion
attack, implementations should consider methods to mitigate
flooding attacks of messages with valid SPIs but invalid content.
Even with the ICV check, resources are still consumed to validate
the ICV.
</t>
<t>
SSE makes no attempt to recommend the ICV length. For constrained
network implementations, other sources should guide the
implementation as to ICV length selection. The ICV length
selection SHOULD be the the responsibility of the KMP.
</t>
<t>
As with any layered security protocol, SSE makes no claims of
protecting lower or higher processes in the communication stack.
Each layer's risks and liabilities need be addressed at that level.
</t>
</list>
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authos would like to thank Frank (Liang) Xia for his comments and suggestions on
this draft. </t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&RFC6241;
&RFC6317;
&RFC7296;
&RFC7401;
&I-D.moskowitz-sse;
&I-D.hares-i2nsf-mgtflow-reqs;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 14:46:31 |