idnits 2.17.1 draft-hares-i2nsf-ssls-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o 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 [RFC7296] or HIP [RFC7401] could be used to provide for rekeying management. The KMP SHOULD not create a network layer fate-sharing limitation. -- The document date (July 18, 2017) is 2467 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 274, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2NSF S. Hares 3 Internet-Draft Hickory Hill Consulting 4 Intended status: Standards Track R. Moskowitz 5 Expires: January 19, 2018 HTT Consulting 6 July 18, 2017 8 Secure Session Layer Services 9 draft-hares-i2nsf-ssls-02.txt 11 Abstract 13 Each I2NSF agent and I2NSF client needs to provide application level 14 support for management traffic during periods of DDoS and network 15 security attacks to deal with congestion (burst and/or continuous), 16 high error rates and packet loss due to the attacks, and the 17 inability to utilize a transport protocol (E.g. TCP) due to a 18 specific protocol attack. This application level support needs to be 19 able to select the key management system and provide "chunking" of 20 data (in order to fit in reduced effective MTUs), compression of data 21 (in order to fit into reduced bandwidth), small security envelope )in 22 order to maximize room for management payload), and fragmentation and 23 reassembly at the application layer for those protocols which do not 24 support fragmentation/reassembly (E.g. UDP or SMS). 26 These Secure Session Layer services may only be deployed on a the few 27 management ports which need to be protected during DDoS attacks or 28 network security attacks, and turned on/off based on need. The 29 application and the network instrumentation need to cooperate to 30 determine if this service needs to be turned on or off. This draft 31 specifies a security session layer services(SSLs) which provide these 32 features in terms of APIs (North-Bound and South-bound), and the 33 component features (interface to key management systems, data 34 compression, chunking of data, secure session envelope (SSE) to send 35 data, and fragmentation and reassembly, and ability to detect 36 existence of attack). 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 19, 2018. 55 Copyright Notice 57 Copyright (c) 2017 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. SSLS Processes . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. Chunking of Data . . . . . . . . . . . . . . . . . . . . 4 75 2.2. Secure Session Envelope . . . . . . . . . . . . . . . . . 5 76 2.3. Application Packet Fragmentation and Reassembly . . . . . 5 77 2.4. Proprietary Plugins: Detect Conditions + Select Transport 5 78 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 80 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 81 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 83 6.2. Informative References . . . . . . . . . . . . . . . . . 7 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 86 1. Introduction 88 Each I2NSF agent and I2NSF client needs to provide application level 89 support for management traffic during periods of DDoS and network 90 security attacks to deal with congestion (burst and/or continuous), 91 high error rates and packet loss due to the attacks, and the 92 inability to utilize a transport protocol (E.g. TCP) due to a 93 specific protocol attack. Some of the services the I2NSF controller 94 must provide during these periods of DDoS or network security attacks 95 are: 97 o receiving information regarding DDoS Threats from DOTS systems, 99 o Changing policy on vNSF and NSF devices during these periods, 101 o exchanging information with user security applications using I2NSF 102 to obtain information from the controller, 104 o Aid the I2NSF reporting of attacks with the the CERT (MILE) either 105 by providing data or sendign the report 107 o and manages network connnectivity of devices out of compliance 108 (SACM). 110 This application level support for I2NSF client-agent communication 111 needs to be able to select the key management system and provide 112 "chunking" of data (in order to fit in reduced effective MTUs), 113 compression of data (in order to fit into reduced bandwidth), small 114 security envelope )in order to maximize room for mangement payload), 115 and fragmentation and reassembly at the application layer for those 116 protocols which do not support fragmentation/reassembly (E.g. UDP or 117 SMS). The application layer needs to be able to turn off this 118 features if the system detects these features are no longer needed. 120 These requirements can be well met with the Secure Session Layer 121 Service [draft-hares-ssls-00]: 123 o A North-bound API from the application to the session layer 125 o A South-bound API from the session layer to the network layer 127 o interface to key management system, 129 o data compression 131 o chunking of data 133 o secure envelope, 135 o fragmentation and reassembly, 137 o detection of network conditions that require this service. 139 A diagram of the SSLS with these process is in figure 1. 141 The API for this SSLS allows the application to select the types of 142 key management, and the different types of services (data 143 compression, chunking of data, secure e) 144 Secure Session Layer Services(SSLS) 145 | API | 146 | | 147 +------------------------------+ 148 | | Key Mangement(KMP) | 149 | |........................| 150 | | Detection of network | 151 |SB===| conditions + selection | 152 |API | of transport (optional | 153 | | proprietary code) | 154 | .........................| 155 |SSLS | Compression (GPComp) | 156 | |........................| 157 |SB===| Chunking of data | 158 |API | (this draft) | 159 | .........................| 160 | | Session Security | 161 | | Envelope (SSE) | 162 | |........................| 163 | | fragmentation and | 164 |SB== | reassembly at | 165 |API | application layer | 166 | | (This draft) | 167 +------------------------------+ 169 2. SSLS Processes 171 2.1. Chunking of Data 173 The process that "chunks" data breaks down the application stream 174 after the compression process. If the compression process has 175 compressed the data, the chunking process will chunk compressed data. 176 If the user has requested no compression, this chunking process will 177 chunk uncompressed data. 179 The secure session envelope must be bigger than the chunk. 181 If the SSE is using TCP or STCP, that assembles the application flow 182 into a byte stream, then the SSE packages will contain a chunk within 183 the secure session envelope. 185 If Transports that do not fragment and re-assembly are being 186 specified, the SSL will support application layer fragmentation and 187 reassembly. (see the fragmentation section below). 189 2.2. Secure Session Envelope 191 The Secure Session Envelope (SSE) [I-D.moskowitz-sse] creates a 192 secure envelope using the SPI created by the key management and 193 running over the transport selected by the user. 195 2.3. Application Packet Fragmentation and Reassembly 197 SSE's secure envelope may be passed over UDP to avoid transport-level 198 security attacks. Alternatively SSE's secure transport may go over 199 the extremely limited SMS fabric so that some security management 200 information gets through. In both cases, the user (or the "detection 201 log") can select the transport and fragmentation. 203 If fragmentation is turned on, the individual SSE envelopes will 204 track the IP messages the SSE envelope is broken into. The SSE 205 process receiving the traffic will send back an acknowledge SSE 206 packet. It is anticipate that the fragmentation process will attempt 207 to bundle some acks. 209 2.4. Proprietary Plugins: Detect Conditions + Select Transport 211 The SSL process allows two proprietary plugins: 213 1. Plugin to detect error conditions which require SSLS services 214 which include: 216 * High levels of end-to-end congestion, 218 * High levels of error and loss, 220 * Input from IDS/IPS that detects problems 222 * Signals from other I2NSF applications 224 2. Proprietary actions may select transport based on input from 225 other standardize security services (DOTS, CERT, MILE) or 226 proprietary services. 228 Prototype code will provide instances to show plugin values, and the 229 South-Bound API to these plugins. 231 3. IANA Considerations 233 TBD 235 4. Security Considerations 237 The SSLS shares the following security considerations with the SSE 238 Technology: 240 o As SSE uses an AEAD block cipher, it is vulnerable to attack if a 241 sequence number is reused for a given key. Thus implementations 242 of SSE MUST provide for rekeying prior to Sequence Number 243 rollover. An implementation should never assume that for a given 244 context, the sequence number space will never be exhausted. Key 245 Management Protocols like IKEv2 [RFC7296] or HIP [RFC7401] could 246 be used to provide for rekeying management. The KMP SHOULD not 247 create a network layer fate-sharing limitation. 249 o As any security protocol can be used for a resource exhaustion 250 attack, implementations should consider methods to mitigate 251 flooding attacks of messages with valid SPIs but invalid content. 252 Even with the ICV check, resources are still consumed to validate 253 the ICV. 255 o SSE makes no attempt to recommend the ICV length. For constrained 256 network implementations, other sources should guide the 257 implementation as to ICV length selection. The ICV length 258 selection SHOULD be the the responsibility of the KMP. 260 o As with any layered security protocol, SSE makes no claims of 261 protecting lower or higher processes in the communication stack. 262 Each layer's risks and liabilities need be addressed at that 263 level. 265 5. Acknowledgements 267 The authos would like to thank Frank (Liang) Xia for his comments and 268 suggestions on this draft. 270 6. References 272 6.1. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, 277 . 279 6.2. Informative References 281 [I-D.moskowitz-sse] 282 Moskowitz, R., Faynberg, I., Lu, H., Hares, S., and P. 283 Giacomin, "Session Security Envelope", draft-moskowitz- 284 sse-05 (work in progress), June 2017. 286 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 287 Kivinen, "Internet Key Exchange Protocol Version 2 288 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 289 2014, . 291 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 292 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 293 RFC 7401, DOI 10.17487/RFC7401, April 2015, 294 . 296 Authors' Addresses 298 Susan Hares 299 Hickory Hill Consulting 300 Saline 301 US 303 Email: shares@ndzh.com 305 Robert Moskowitz 306 HTT Consulting 307 Oak Park, MI 48237 308 USA 310 Phone: +1-248-968-9809 311 Email: rgm@htt-consult.com