idnits 2.17.1
draft-yang-i2nsf-security-policy-translation-01.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 :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (July 17, 2018) is 2109 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
No issues found here.
Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 I2NSF Working Group J. Yang
3 Internet-Draft J. Jeong
4 Intended status: Informational J. Kim
5 Expires: January 18, 2019 Sungkyunkwan University
6 July 17, 2018
8 Security Policy Translation in Interface to Network Security Functions
9 draft-yang-i2nsf-security-policy-translation-01
11 Abstract
13 This document proposes a scheme of security policy translation (i.e.,
14 Security Policy Translator) in Interface to Network Security
15 Functions (I2NSF) Framework. When I2NSF User delivers a high-level
16 security policy for a security service, Security Policy Translator in
17 Security Controller translates it into a low-level security policy
18 for Network Security Functions (NSFs).
20 Status of This Memo
22 This Internet-Draft is submitted in full conformance with the
23 provisions of BCP 78 and BCP 79.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF). Note that other groups may also distribute
27 working documents as Internet-Drafts. The list of current Internet-
28 Drafts is at https://datatracker.ietf.org/drafts/current/.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 This Internet-Draft will expire on January 18, 2019.
37 Copyright Notice
39 Copyright (c) 2018 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents
44 (https://trustee.ietf.org/license-info) in effect on the date of
45 publication of this document. Please review these documents
46 carefully, as they describe your rights and restrictions with respect
47 to this document. Code Components extracted from this document must
48 include Simplified BSD License text as described in Section 4.e of
49 the Trust Legal Provisions and are provided without warranty as
50 described in the Simplified BSD License.
52 Table of Contents
54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
56 3. Necessity for Policy Translator . . . . . . . . . . . . . . . 2
57 4. Design of Policy Translator . . . . . . . . . . . . . . . . . 3
58 4.1. Overall Structure of Policy Translator . . . . . . . . . 3
59 4.2. DFA-based Data Extractor . . . . . . . . . . . . . . . . 6
60 4.3. Data Converter . . . . . . . . . . . . . . . . . . . . . 6
61 4.4. Context-free Grammar-based Policy Generator . . . . . . . 7
62 5. Features of Policy Translator Design . . . . . . . . . . . . 7
63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
64 7. Informative References . . . . . . . . . . . . . . . . . . . 8
65 Appendix A. Changes from draft-yang-i2nsf-security-policy-
66 translation-00 . . . . . . . . . . . . . . . . . . . 10
67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
69 1. Introduction
71 This document defines a scheme of a security policy translation in
72 Interface to Network Security Functions (I2NSF) Framework [RFC8329].
73 First of all, this document explains the necessity of a security
74 policy translator (shortly called policy translator) in the I2NSF
75 framework.
77 The policy translator resides in Security Controller in the I2NSF
78 framework and translates a high-level security policy to a low-level
79 security policy for Network Security Functions (NSFs). A high-level
80 policy is specified by I2NSF User in the I2NSF framework and is
81 delivered to Security Controller via Consumer-Facing Interface
82 [consumer-facing-inf-dm]. A low-level policy is translated by Policy
83 Translator in Security Controller and is delivered to NSFs to execute
84 the rules corresponding to the low-level policy via NSF-Facing
85 Interface [nsf-facing-inf-dm].
87 2. Terminology
89 This document uses the terminology specified in [i2nsf-terminology]
90 [RFC8329].
92 3. Necessity for Policy Translator
94 Security Controller acts as a coordinator between I2NSF User and
95 NSFs. Also, Security Controller has capability information of NSFs
96 that are registered via Registration Interface [registration-inf-dm]
97 by Developer's Management System [RFC8329].
99 As a coordinator, Security Controller needs to generate a low-level
100 policy in the form of security rules intended by the high-level
101 policy, which can be understood by the corresponding NSFs.
103 A high-level security policy is specified by RESTCONF/YANG
104 [RFC8040][RFC6020], and a low-level security policy is specified by
105 NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level
106 security policy to the corresponding low-level security policy will
107 be able to rapidly elevate I2NSF in real-world deployment. A rule in
108 a high-level policy can include a broad target object, such as
109 employees in a company for a security service (e.g., firewall and web
110 filter). Such employees are from human resource (HR) department,
111 software engineering department, and advertisement department. A
112 keyword of employee needs to be mapped to these employees from
113 various departments. This mapping needs to be handled by a policy
114 translator in a flexible way while understanding the intention of a
115 policy specification.
117 This document proposes an approach using Automata theory for the
118 policy tranlation, such as deterministic finite automaton (DFA) and
119 context-free grammar. Note that Automata theory is the foundation of
120 programming languates and compilers. Thus, with this approach, I2NSF
121 User can easily specify a high-level security policy that will be
122 enforced into the corresponding NSFs with a compatible low-level
123 security policy with the help of Policy Translator. Also, for easy
124 managment of Policy Translator, a modularized translator structure is
125 proposed.
127 4. Design of Policy Translator
129 Commonly used security policies are created as xml files. A popular
130 way to change the format of an xml file is to use an xslt document.
131 However, the use of xslt makes it difficult to manage the policy
132 translator and to handle the registration of new capabilities of
133 NSFs. With the nessity for policy translator, this document a policy
134 translator based on Automata theory.
136 4.1. Overall Structure of Policy Translator
138 Figure 1 shows the overall design for Policy Translator in Security
139 Controller. There are three main parts for Policy Translator:
140 Extractor, Capability Converter, and Policy Generator.
142 Extractor is a DFA-based tool for extracting data from a high-level
143 policy which I2NSF User delivered via Consumer-Facing Interface.
145 Data Converter converts the extracted data to the capabilities of
146 target NSFs for a low-level policy. It refers to NSF Database (DB)
147 in order to convert an abstract subject or object into the
148 corresponding concrete subject or object (e.g., IP address and
149 website URL). Policy Generator generates a low-level policy which
150 will execute the NSF capabilities from Converter.
152 +------------+
153 | I2NSF User |
154 +-----+------+
155 Security | Consumer-Facing Interface
156 Controller V
157 +------------------------+-------------------------+
158 | High-Level |
159 | Policy |
160 | (from I2NSF User) |
161 | Policy | |
162 | Translator V |
163 | +---------------------+----------------------+ |
164 | | | | |
165 | | +-------+--------+ | |
166 | | | DFA-based | | |
167 | | | Data Extractor | | |
168 | | +-------+--------+ | |
169 | | | Extracted Data from | |
170 | | V High-Level Policy | |
171 | | +-----+-----+ | |
172 | | | Data | <-> Refer to | |
173 | | | Converter | NSF DB | |
174 | | +-----+-----+ | |
175 | | | Required Data for | |
176 | | V Target NSFs | |
177 | | +-------+-------+ | |
178 | | | Context-free | | |
179 | | | Grammar-based | | |
180 | | | Policy | | |
181 | | | Generator | | |
182 | | +-------+-------+ | |
183 | | | | |
184 | +---------------------+----------------------+ |
185 | | |
186 | Low-Level Policy |
187 | (for NSFs) |
188 | | |
189 +------------------------+-------------------------+
190 |
191 V NSF-Facing Interface
193 Figure 1: The Overall Design of Policy Translator
195 4.2. DFA-based Data Extractor
197 Figure 2 shows a design for Data Extractor in the policy translator.
198 If the high-level policy contains data along the hierarchical
199 structure of the standard YANG data model, data can be easily
200 extracted using the state transition machine, DFA.
202 The extracted data is processed and used by an NSF to understand it.
203 Extractor can be constructed by designing a DFA with the same
204 hierarchical structure as a YANG data model.
206 Since the translator is modularized into a DFA structure, a visual
207 understanding is feasible. Also, the following structure of
208 Extractor is easy to manage. If I2NSF User wants to modify the data
209 model of a high-level policy, it only needs to change the connection
210 of the relevant DFA node.
212
213 +----------+ ------> +----------+ -------> +-------------+
214 | accepter | | | . . . | extractor 1 |
215 +----------+ <------ | | <------- +-------------+
216 | |
217 | |
218 | |
219 | | -------> +-------------+
220 | | . . . | extractor 2 |
221 | | <------- +-------------+
222 | middle 1 |
223 | | .
224 | | .
225 | | .
226 | |
227 | | -------> +-------------+
228 | | . . . | extractor N |
229 | | <------- +-------------+
230 | |
231 +----------+
233 Figure 2: The Design of Data Extractor
235 4.3. Data Converter
237 Every NSF has its own unique capabilities. The capabilities of an
238 NSF are registered into Security Controller by a Developer's
239 Management System, which manages the NSF, via Registration Interface.
240 Therefore, Security Controller already has all information about the
241 capabilities of NSFs. This means that Security Controller can find
242 target NSFs with only the data (e.g., subject and object for a
243 security policy) of the high-level policy by comparing all
244 capabilities of each NSF. This search process for appropriate NSFs
245 is called by NSF provisioning, and it eliminates the need for I2NSF
246 User to specify the target NSFs explicitly. Data Converter selects
247 target NSFs and converts the extracted data into the capabilities of
248 selected NSFs. If Security Controller uses this data convertor, it
249 can provide the NSF provisioning function to the I2NSF User
250 automatically. Thus, the translator design provides big benefits to
251 I2NSF Framework.
253 4.4. Context-free Grammar-based Policy Generator
255 The productions that makes up the low-level security policy are
256 categorized into two types, Structure Production and Content
257 Production. Structure Production is for grouping other tags into a
258 hierarchy. A security manager constructs Structure Production in the
259 form of an expression as the following equation:
261 o [structure_prod] ->
262 [policy:1][policy:2]...[policy:n]
264 Content Production is for injecting data into low-level policies to
265 be generated. The manager can construct Content Production in the
266 form of an expression as following equation:
268 o [content_prod] -> [content_data]
270 o [content_data] -> data:1 | data:2 | ... | data:n
272 o [content_prod] -> [content_prod][content_prod] (Where duplication
273 is allowed.)
275 5. Features of Policy Translator Design
277 First, by showing the visualized translator structure, the manager
278 can handle various policy changes. Translator can be shown by
279 visualizing DFA and Context-free Grammar so that the manager can
280 easily understand the structure of Policy Translator.
282 Second, if I2NSF User only keeps the hierarchy of the data model,
283 I2NSF User can freely create high-level policies. In the case of
284 DFA, data extraction can be performed in the same way even if the
285 order of input is changed. The design of the policy translator is
286 more flexible than the existing method that works by keeping the tag
287 's position and order exactly.
289 Third, the structure of Policy Translator can be updated even while
290 Policy Translator is operating. Because Policy Translator is
291 modularized, the translator can adapt to changes in the NSF
292 capability while the I2NSF framework is running. The function of
293 changing the translator's structure can be provided through
294 Registration Interface.
296 6. Acknowledgments
298 This work was supported by Institute for Information & communications
299 Technology Promotion (IITP) grant funded by the Korea MSIT (Ministry
300 of Science and ICT) (R-20160222-002755, Cloud based Security
301 Intelligence Technology Development for the Customized Security
302 Service Provisioning).
304 This work was supported in part by the MSIT under the ITRC
305 (Information Technology Research Center) support program (IITP-
306 2018-2017-0-01633) supervised by the IITP.
308 7. Informative References
310 [consumer-facing-inf-dm]
311 Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares,
312 "I2NSF Consumer-Facing Interface YANG Data Model", draft-
313 ietf-i2nsf-consumer-facing-interface-dm-01 (work in
314 progress), July 2018.
316 [i2nsf-terminology]
317 Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
318 Birkholz, "Interface to Network Security Functions (I2NSF)
319 Terminology", draft-ietf-i2nsf-terminology-06 (work in
320 progress), July 2018.
322 [nsf-facing-inf-dm]
323 Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin,
324 "I2NSF Network Security Function-Facing Interface YANG
325 Data Model", draft-ietf-i2nsf-nsf-facing-interface-data-
326 model-01 (work in progress), July 2018.
328 [registration-inf-dm]
329 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF
330 Registration Interface YANG Data Model", draft-hyun-i2nsf-
331 registration-dm-05 (work in progress), July 2018.
333 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
334 Network Configuration Protocol (NETCONF)", RFC 6020,
335 October 2010.
337 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
338 Bierman, "Network Configuration Protocol (NETCONF)",
339 RFC 6241, June 2011.
341 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
342 Protocol", RFC 8040, January 2017.
344 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
345 Kumar, "Framework for Interface to Network Security
346 Functions", RFC 8329, February 2018.
348 Appendix A. Changes from draft-yang-i2nsf-security-policy-
349 translation-00
351 The following changes are made from draft-yang-i2nsf-security-policy-
352 translation-00:
354 o In Section 3, the necessity for the proposed translation design is
355 clarified.
357 o In Section 4.3, the description of Data Converter is clarified.
359 o In Section 4.4, "Structure Grammar" and "Content Grammar" are
360 replaced with "Structure Production" and "Content Production",
361 respectively.
363 o The references are updated to reflect the latest documents.
365 Authors' Addresses
367 Jinhyuk Yang
368 Department of Computer Engineering
369 Sungkyunkwan University
370 2066 Seobu-Ro, Jangan-Gu
371 Suwon, Gyeonggi-Do 16419
372 Republic of Korea
374 Phone: +82 10 8520 8039
375 EMail: jin.hyuk@skku.edu
377 Jaehoon Paul Jeong
378 Department of Software
379 Sungkyunkwan University
380 2066 Seobu-Ro, Jangan-Gu
381 Suwon, Gyeonggi-Do 16419
382 Republic of Korea
384 Phone: +82 31 299 4957
385 Fax: +82 31 290 7996
386 EMail: pauljeong@skku.edu
387 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
388 Jinyong Tim Kim
389 Department of Computer Engineering
390 Sungkyunkwan University
391 2066 Seobu-Ro, Jangan-Gu
392 Suwon, Gyeonggi-Do 16419
393 Republic of Korea
395 Phone: +82 10 8273 0930
396 EMail: timkim@skku.edu