Secure Session Layer Services

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: receiving information regarding DDoS Threats from DOTS systems, Changing policy on vNSF and NSF devices during these periods, exchanging information with user security applications using I2NSF to obtain information from the controller, Aid the I2NSF reporting of attacks with the the CERT (MILE) either by providing data or sendign the report and manages network connnectivity of devices out of compliance (SACM). 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. These requirements can be well met with the Secure Session Layer Service [draft-hares-ssls-00]: A North-bound API from the application to the session layer A South-bound API from the session layer to the network layer interface to key management system, data compression chunking of data secure envelope, fragmentation and reassembly, detection of network conditions that require this service. A diagram of the SSLS with these process is in figure 1. 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)

Secure Session Layer Services(SSLS) | API | | | +------------------------------+ | | Key Mangement(KMP) | | |........................| | | Detection of network | |SB===| conditions + selection | |API | of transport (optional | | | proprietary code) | | .........................| |SSLS | Compression (GPComp) | | |........................| |SB===| Chunking of data | |API | (this draft) | | .........................| | | Session Security | | | Envelope (SSE) | | |........................| | | fragmentation and | |SB== | reassembly at | |API | application layer | | | (This draft) | +------------------------------+

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 secure session envelope must be bigger than the chunk. 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. 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).

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.

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. If fragmentation is turned on, the individual SSE envelopes will track the IP messages the SSE envelope is broken into. The SSE process receiving the traffic will send back an acknowledge SSE packet. It is anticipate that the fragmentation process will attempt to bundle some acks.

The SSL process allows two proprietary plugins: Plugin to detect error conditions which require SSLS services which include: High levels of end-to-end congestion, High levels of error and loss, Input from IDS/IPS that detects problems Signals from other I2NSF applications Proprietary actions may select transport based on input from other standardize security services (DOTS, CERT, MILE) or proprietary services. Prototype code will provide instances to show plugin values, and the South-Bound API to these plugins.

TBD

The SSLS shares the following security considerations with the SSE Technology: 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 or HIP could be used to provide for rekeying management. The KMP SHOULD not create a network layer fate-sharing limitation. 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. 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. 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.

The authos would like to thank Frank (Liang) Xia for his comments and suggestions on this draft.