idnits 2.17.1
draft-yang-i2nsf-security-policy-translation-00.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 2, 2018) is 2126 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 Network Working Group J. Yang
3 Internet-Draft J. Jeong
4 Intended status: Informational J. Kim
5 Expires: January 3, 2019 Sungkyunkwan University
6 July 2, 2018
8 Security Policy Translation in Interface to Network Security Functions
9 draft-yang-i2nsf-security-policy-translation-00
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 to IETF 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), its areas, and its working groups. Note that
27 other groups may also distribute working documents as Internet-
28 Drafts.
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 The list of current Internet-Drafts can be accessed at
36 http://www.ietf.org/ietf/1id-abstracts.txt.
38 The list of Internet-Draft Shadow Directories can be accessed at
39 http://www.ietf.org/shadow.html.
41 This Internet-Draft will expire on January 3, 2019.
43 Copyright Notice
45 Copyright (c) 2018 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 3. Necessity for Policy Translator . . . . . . . . . . . . . . . . 3
63 4. Design of Policy Translator . . . . . . . . . . . . . . . . . . 4
64 4.1. Overall Structure of Policy Translator . . . . . . . . . . 4
65 4.2. DFA-based Data Extractor . . . . . . . . . . . . . . . . . 6
66 4.3. Data Converter . . . . . . . . . . . . . . . . . . . . . . 6
67 4.4. Context-free Grammar-based Policy Generator . . . . . . . . 7
68 5. Features of Policy Translator Design . . . . . . . . . . . . . 7
69 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
70 7. Informative References . . . . . . . . . . . . . . . . . . . . 8
72 1. Introduction
74 This document defines a scheme of a security policy translation in
75 Interface to Network Security Functions (I2NSF) Framework [RFC8329].
76 First of all, this document explains the necessity of a security
77 policy translator (shortly called policy translator) in the I2NSF
78 framework.
80 The policy translator resides in Security Controller in the I2NSF
81 framework and translates a high-level security policy to a low-level
82 security policy for Network Security Functions (NSFs). A high-level
83 policy is specified by I2NSF User in the I2NSF framework and is
84 delivered to Security Controller via Consumer-Facing Interface
85 [consumer-facing-inf-dm]. A low-level policy is translated by Policy
86 Translator in Security Controller and is delivered to NSFs to execute
87 the rules corresponding to the low-level policy via NSF-Facing
88 Interface [nsf-facing-inf-dm].
90 2. Terminology
92 This document uses the terminology specified in [i2nsf-terminology]
93 [RFC8329].
95 3. Necessity for Policy Translator
97 Security Controller acts as a coordinator between I2NSF User and
98 NSFs. Also, Security Controller has capability information of NSFs
99 that are registered via Registration Interface [registration-inf-dm]
100 by Developer's Management System [RFC8329].
102 As a coordinator, Security Controller needs to generate a low-level
103 policy in the form of security rules intended by the high-level
104 policy, which can be understood by the corresponding NSFs.
106 A high-level security policy is specified by RESTCONF/YANG
107 [RFC8040][RFC6020], and a low-level security policy is specified by
108 NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level
109 security policy to the corresponding low-level security policy will
110 be able to rapidly elevate I2NSF in real-world deployment. A rule in
111 a high-level policy can include a broad target object, such as
112 employees in a company for a security service (e.g., firewall and web
113 filter). Such employees are from human resource (HR) department,
114 software engineering department, and advertisement department. A
115 keyword of employee needs to be mapped to these employees from
116 various departments. This mapping needs to be handled by a policy
117 translator in a flexible way while understanding the intention of a
118 policy specification.
120 This document proposes an approach using Automata theory for the
121 policy tranlation, such as deterministic finite automaton (DFA) and
122 context-free grammar. Note that Automata theory is the foundation of
123 programming languates and compilers. Thus, with this approach, I2NSF
124 User can easily specify a high-level security policy that will be
125 enforced into the corresponding NSFs with a compatible low-level
126 security policy with the help of Policy Translator. Also, for easy
127 managment of Policy Translator, a modularized translator structure is
128 proposed.
130 4. Design of Policy Translator
132 Commonly used security policies are created as xml files. A popular
133 way to change the format of an xml file is to use an xslt document.
134 However, the use of xslt makes it difficult to manage the policy
135 translator and to handle the registration of new capabilities of
136 NSFs. With the nessity for policy translator, this document a policy
137 translator based on Automata.
139 4.1. Overall Structure of Policy Translator
141 Figure 1 shows the overall design for Policy Translator in Security
142 Controller. There are three main parts for Policy Translator:
143 Extractor, Capability Converter, and Policy Generator.
145 Extractor is a DFA-based tool for extracting data from a high-level
146 policy which I2NSF User delivered via Consumer-Facing Interface.
147 Data Converter converts the extracted data to the capabilities of
148 target NSFs for a low-level policy. Policy Generator generates a
149 low-level policy which will execute the NSF capabilities from
150 Converter.
152 +------------+
153 | I2NSF User |
154 +-----+------+
155 Security | I2NSF 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 | | |
173 | | | Converter | | |
174 | | +-----+-----+ | |
175 | | | Capabilities of | |
176 | | V Low-Level Policy | |
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 I2NSF 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 capability. NSF registration is
238 performed through Registration Interface, and the registration
239 process is dedicated to Security Controller. Therefore, Security
240 Controller already has all information about the capabilities of the
241 NSFs. This means that Security Controller can find target NSFs with
242 only the data of the high-level policy. Data Converter selects
243 target NSFs and converts the extracted data into the capabilities of
244 selected NSFs. This eliminates the need for I2NSF User to set the
245 target NSFs one by one.
247 4.4. Context-free Grammar-based Policy Generator
249 The grammar that makes up the low-level security policy is
250 categorized into two types, Structure Grammar and Content Grammar.
251 Structure Grammar is for grouping other tags into a hierarchy. A
252 security administrator called manager constructs Structure Grammar in
253 the form of an expression as the following equation:
255 o [structure_grammar] -> [policy:1][policy:
256 2]...[policy:n]
258 Content Grammar is for injecting data into low-level policies to be
259 generated. The manager can construct Content Grammar in the form of
260 an expression as following equation:
262 o [content_grammar] -> [content_data]
264 o [content_data] -> data:1 | data:2 | ... | data:n
266 o [content_grammar] -> [content_grammar][content_grammar] (When
267 duplication is allowed)
269 5. Features of Policy Translator Design
271 First, by showing the visualized translator structure, the manager
272 can handle various policy changes. Translator can be shown by
273 visualizing DFA and Context-free Grammar so that the manager can
274 easily understand the structure of Policy Translator.
276 Second, if I2NSF User only keeps the hierarchy of the data model,
277 I2NSF User can freely create high-level policies. In the case of
278 DFA, data extraction can be performed in the same way even if the
279 order of input is changed. The design of the policy translator is
280 more flexible than the existing method that works by keeping the tag
281 's position and order exactly.
283 Third, the structure of Policy Translator can be updated even while
284 Policy Translator is operating. Because Policy Translator is
285 modularized, the translator can adapt to changes in the NSF
286 capability while the I2NSF framework is running. The function of
287 changing the translator's structure can be provided through
288 Registration Interface.
290 6. Acknowledgments
292 This work was supported by Institute for Information & communications
293 Technology Promotion (IITP) grant funded by the Korea MSIT (Ministry
294 of Science and ICT) (R-20160222-002755, Cloud based Security
295 Intelligence Technology Development for the Customized Security
296 Service Provisioning).
298 This work was supported in part by the MSIT under the ITRC
299 (Information Technology Research Center) support program (IITP-2018-
300 2017-0-01633) supervised by the IITP.
302 7. Informative References
304 [i2nsf-terminology] Hares, S., Strassner, J., Lopez, D., Xia,
305 L., and H. Birkholz, "Interface to Network
306 Security Functions (I2NSF) Terminology",
307 draft-ietf-i2nsf-terminology-05 (work in
308 progress), January 2018.
310 [RFC8329] Lopez, D., Lopez, E., Dunbar, L.,
311 Strassner, J., and R. Kumar, "Framework for
312 Interface to Network Security Functions",
313 RFC 8329, February 2018.
315 [consumer-facing-inf-dm] Jeong, J., Kim, E., Ahn, T., Kumar, R., and
316 S. Hares, "I2NSF Consumer-Facing Interface
317 YANG Data Model", draft-ietf-i2nsf-
318 consumer-facing-interface-dm-01 (work in
319 progress), July 2018.
321 [nsf-facing-inf-dm] Kim, J., Jeong, J., Park, J., Hares, S.,
322 and Q. Lin, "I2NSF Network Security
323 Function-Facing Interface YANG Data Model",
324 draft-ietf-i2nsf-nsf-facing-interface-data-
325 model-01 (work in progress), July 2018.
327 [registration-inf-dm] Hyun, S., Jeong, J., Roh, T., Wi, S., and
328 J. Park, "I2NSF Registration Interface YANG
329 Data Model",
330 draft-hyun-i2nsf-registration-dm-04 (work
331 in progress), July 2018.
333 [RFC6020] Bjorklund, M., "YANG - A Data Modeling
334 Language for the Network Configuration
335 Protocol (NETCONF)", RFC 6020,
336 October 2010.
338 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen,
339 "RESTCONF Protocol", RFC 8040,
340 January 2017.
342 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J.,
343 and A. Bierman, "Network Configuration
344 Protocol (NETCONF)", RFC 6241, June 2011.
346 Authors' Addresses
348 Jinhyuk Yang
349 Department of Computer Engineering
350 Sungkyunkwan University
351 2066 Seobu-Ro, Jangan-Gu
352 Suwon, Gyeonggi-Do 16419
353 Republic of Korea
355 Phone: +82 10 8520 8039
356 EMail: jin.hyuk@skku.edu
358 Jaehoon Paul Jeong
359 Department of Software
360 Sungkyunkwan University
361 2066 Seobu-Ro, Jangan-Gu
362 Suwon, Gyeonggi-Do 16419
363 Republic of Korea
365 Phone: +82 31 299 4957
366 Fax: +82 31 290 7996
367 EMail: pauljeong@skku.edu
368 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
370 Jinyong Tim Kim
371 Department of Computer Engineering
372 Sungkyunkwan University
373 2066 Seobu-Ro, Jangan-Gu
374 Suwon, Gyeonggi-Do 16419
375 Republic of Korea
377 Phone: +82 10 8273 0930
378 EMail: timkim@skku.edu