I2NSF S. Hares
Internet-Draft Hickory Hill Consulting
Intended status: Standards Track R. Moskowitz
Expires: January 4, 2018 HTT Consulting
July 3, 2017

Secure Session Layer Services
draft-hares-i2nsf-ssls-01.txt

Abstract

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 management payload), and fragmentation and reassembly at the application layer for those protocols which do not support fragmentation/reassembly (E.g. UDP or SMS).

These Secure Session Layer services may only be deployed on a the few management ports which need to be protected during DDoS attacks or network security attacks, and turned on/off based on need. The application and the network instrumentation need to cooperate to determine if this service needs to be turned on or off. This draft specifies a security session layer services(SSLs) which provide these features in terms of APIs (North-Bound and South-bound), 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).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 4, 2018.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.


Table of Contents

1. Introduction

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:

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 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)           |
  +------------------------------+
	

2. SSLS Processes

2.1. Chunking of Data

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).

2.2. Secure Session Envelope

The Secure Session Envelope (SSE) [I-D.moskowitz-sse] creates a secure envelope using the SPI created by the key management and running over the transport selected by the user.

2.3. Application Packet Fragmentation and Reassembly

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.

2.4. Proprietary Plugins: Detect Conditions + Select Transport

The SSL process allows two proprietary plugins:

  1. Plugin to detect error conditions which require SSLS services which include:

  2. 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.

3. IANA Considerations

TBD

4. Security Considerations

The SSLS shares the following security considerations with the SSE Technology:

5. Acknowledgements

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

6. References

6.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.

6.2. Informative References

[I-D.moskowitz-sse] Moskowitz, R., Faynberg, I., Lu, H., Hares, S. and P. Giacomin, "Session Security Envelope", Internet-Draft draft-moskowitz-sse-05, June 2017.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P. and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014.
[RFC7401] Moskowitz, R., Heer, T., Jokela, P. and T. Henderson, "Host Identity Protocol Version 2 (HIPv2)", RFC 7401, DOI 10.17487/RFC7401, April 2015.

Authors' Addresses

Susan Hares Hickory Hill Consulting Saline, US EMail: shares@ndzh.com
Robert Moskowitz HTT Consulting Oak Park, MI 48237 USA Phone: +1-248-968-9809 EMail: rgm@htt-consult.com