idnits 2.17.1
draft-yang-i2nsf-security-policy-translation-03.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 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.)
== There are 6 instances of lines with private range IPv4 addresses in the
document. If these are generic example addresses, they should be changed
to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x,
198.51.100.x or 203.0.113.x.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 141: '... an NSF, the NSF MUST receive at least...'
RFC 2119 keyword, line 146: '...ntence, the user MUST know that the NS...'
RFC 2119 keyword, line 154: '... policy is REQUIRED in I2NSF....'
RFC 2119 keyword, line 429: '... security policy MUST be provided abst...'
RFC 2119 keyword, line 475: '...evel policy data MUST be converted int...'
(4 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 11, 2019) is 1866 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)
-- Possible downref: Non-RFC (?) normative reference: ref. 'Automata'
** Downref: Normative reference to an Informational RFC: RFC 8329
-- Possible downref: Non-RFC (?) normative reference: ref. 'XML'
Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--).
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: Standards Track J. Kim
5 Expires: September 12, 2019 Sungkyunkwan University
6 March 11, 2019
8 Security Policy Translation in Interface to Network Security Functions
9 draft-yang-i2nsf-security-policy-translation-03
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 September 12, 2019.
37 Copyright Notice
39 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
56 3. Necessity for Policy Translator . . . . . . . . . . . . . . . 3
57 4. Design of Policy Translator . . . . . . . . . . . . . . . . . 4
58 4.1. Overall Structure of Policy Translator . . . . . . . . . 4
59 4.2. DFA-based Data Extractor . . . . . . . . . . . . . . . . 6
60 4.2.1. Design of DFA-based Data Extractor . . . . . . . . . 6
61 4.2.2. Example Scenario for Data Extractor . . . . . . . . . 7
62 4.3. Data Converter . . . . . . . . . . . . . . . . . . . . . 9
63 4.3.1. Role of Data Converter . . . . . . . . . . . . . . . 9
64 4.3.2. NSF Database . . . . . . . . . . . . . . . . . . . . 10
65 4.3.3. Data Conversion in Data Converter . . . . . . . . . . 10
66 4.3.4. Policy Provisioning . . . . . . . . . . . . . . . . . 12
67 4.4. CFG-based Policy Generator . . . . . . . . . . . . . . . 13
68 4.4.1. Content Production . . . . . . . . . . . . . . . . . 13
69 4.4.2. Structure Production . . . . . . . . . . . . . . . . 14
70 4.4.3. Generator Construction . . . . . . . . . . . . . . . 14
71 5. Implementation Considerations . . . . . . . . . . . . . . . . 18
72 5.1. Data Model Auto-adaptation . . . . . . . . . . . . . . . 18
73 5.2. Data Conversion . . . . . . . . . . . . . . . . . . . . . 19
74 5.3. Policy Provisioning . . . . . . . . . . . . . . . . . . . 19
75 6. Features of Policy Translator Design . . . . . . . . . . . . 19
76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
77 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
79 9.1. Normative References . . . . . . . . . . . . . . . . . . 20
80 9.2. Informative References . . . . . . . . . . . . . . . . . 21
81 Appendix A. Changes from draft-yang-i2nsf-security-policy-
82 translation-02 . . . . . . . . . . . . . . . . . . . 22
83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
85 1. Introduction
87 This document defines a scheme of a security policy translation in
88 Interface to Network Security Functions (I2NSF) Framework [RFC8329].
89 First of all, this document explains the necessity of a security
90 policy translator (shortly called policy translator) in the I2NSF
91 framework.
93 The policy translator resides in Security Controller in the I2NSF
94 framework and translates a high-level security policy to a low-level
95 security policy for Network Security Functions (NSFs). A high-level
96 policy is specified by I2NSF User in the I2NSF framework and is
97 delivered to Security Controller via Consumer-Facing Interface
98 [consumer-facing-inf-dm]. It is translated into a low-level policy
99 by Policy Translator in Security Controller and is delivered to NSFs
100 to execute the rules corresponding to the low-level policy via NSF-
101 Facing Interface [nsf-facing-inf-dm].
103 2. Terminology
105 This document uses the terminology specified in [i2nsf-terminology]
106 [RFC8329].
108 3. Necessity for Policy Translator
110 Security Controller acts as a coordinator between I2NSF User and
111 NSFs. Also, Security Controller has capability information of NSFs
112 that are registered via Registration Interface [registration-inf-dm]
113 by Developer's Management System [RFC8329]. As a coordinator,
114 Security Controller needs to generate a low-level policy in the form
115 of security rules intended by the high-level policy, which can be
116 understood by the corresponding NSFs.
118 A high-level security policy is specified by RESTCONF/YANG
119 [RFC8040][RFC6020], and a low-level security policy is specified by
120 NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level
121 security policy to the corresponding low-level security policy will
122 be able to rapidly elevate I2NSF in real-world deployment. A rule in
123 a high-level policy can include a broad target object, such as
124 employees in a company for a security service (e.g., firewall and web
125 filter). Such employees may be from human resource (HR) department,
126 software engineering department, and advertisement department. A
127 keyword of employee needs to be mapped to these employees from
128 various departments. This mapping needs to be handled by a policy
129 translator in a flexible way while understanding the intention of a
130 policy specification. Let us consider the following two policies:
132 o Block my son's computers from malicious websites.
134 o Drop packets from the IP address 10.0.0.1 and 10.0.0.3 to harm.com
135 and illegal.com
137 The above two sentences are examples of policies for blocking
138 malicious websites. Both policies are for the same operation.
139 However, NSF cannot understand the first policy, because the policy
140 does not have any specified information for NSF. To set up the
141 policy at an NSF, the NSF MUST receive at least the source IP address
142 and website address for an operation. It means that the first
143 sentence is NOT compatible for an NSF policy. Conversely, when I2NSF
144 Users request a security policy to the system, they never make a
145 security policy like the second example. For generating a security
146 policy like the second sentence, the user MUST know that the NSF
147 needs to receive the specified information, source IP address and
148 website address. It means that the user understands the NSF
149 professionally, but there are not many professional users in a small
150 size of company or at a residential area. In conclusion, the I2NSF
151 User prefers to issue a security policy in the first sentence, but an
152 NSF will require the same policy as the second sentence with specific
153 information. Therefore, an advanced translation scheme of security
154 policy is REQUIRED in I2NSF.
156 This document proposes an approach using Automata theory [Automata]
157 for the policy tranlation, such as Deterministic Finite Automaton
158 (DFA) and Context Free Grammar (CFG). Note that Automata theory is
159 the foundation of programming language and compiler. Thus, with this
160 approach, I2NSF User can easily specify a high-level security policy
161 that will be enforced into the corresponding NSFs with a compatibly
162 low-level security policy with the help of Policy Translator. Also,
163 for easy management, a modularized translator structure is proposed.
165 4. Design of Policy Translator
167 Commonly used security policies are created as XML(Extensible Markup
168 Language) [XML] files. A popular way to change the format of an XML
169 file is to use an XSLT (Extensible Stylesheet Language
170 Transformation) [XSLT] document. XSLT is an XML-based language to
171 transform an input XML file into another output XML file. However,
172 the use of XSLT makes it difficult to manage the policy translator
173 and to handle the registration of new capabilities of NSFs. With the
174 necessity for a policy translator, this document describes a policy
175 translator based on Automata theory.
177 4.1. Overall Structure of Policy Translator
178 High-Level Policy
179 Security |
180 Controller V Consumer-Facing Interface
181 +------------------------+-------------------------+
182 | Policy | |
183 | Translator | |
184 | +---------------------+----------------------+ |
185 | | | | |
186 | | +-------+--------+ | |
187 | | | DFA-based | | |
188 | | | Data Extractor | | |
189 | | +-------+--------+ | |
190 | | | Extracted Data from | |
191 | | V High-Level Policy | |
192 | | +-----+-----+ +--------+ | |
193 | | | Data | <-> | NSF DB | | |
194 | | | Converter | +--------+ | |
195 | | +-----+-----+ | |
196 | | | Required Data for | |
197 | | V Target NSFs | |
198 | | +--------+---------+ | |
199 | | | CFG-based | | |
200 | | | Policy Generator | | |
201 | | +--------+---------+ | |
202 | | | | |
203 | +---------------------+----------------------+ |
204 | | |
205 +------------------------+-------------------------+
206 | NSF-Facing Interface
207 V
208 Low-Level Policy
210 Figure 1: The Overall Design of Policy Translator
212 Figure 1 shows the overall design for Policy Translator in Security
213 Controller. There are three main components for Policy Translator:
214 Data Extractor, Data Converter, and Policy Generator.
216 Extractor is a DFA-based module for extracting data from a high-level
217 policy which I2NSF User delivered via Consumer-Facing Interface.
218 Data Converter converts the extracted data to the capabilities of
219 target NSFs for a low-level policy. It refers to NSF Database (DB)
220 in order to convert an abstract subject or object into the
221 corresponding concrete subject or object (e.g., IP address and
222 website URL). Policy Generator generates a low-level policy which
223 will execute the NSF capabilities from Converter.
225 4.2. DFA-based Data Extractor
227 4.2.1. Design of DFA-based Data Extractor
229 +----------+
230 | accepter |
231 +----------+
232 | ^
233 | |
234 v |
235 +------------------------------------------------------+
236 | middle 1 |
237 +------------------------------------------------------+
238 | ^ | ^ | ^
239 | | | | ... | |
240 v | v | v |
242 ... ... ...
244 +-------------+ +-------------+ +-------------+
245 | extractor 1 | | extractor 2 | ... | extractor m |
246 +-------------+ +-------------+ +-------------+
247 data:1 data:2 data:m
249 Figure 2: DFA Architecture of Data Extractor
251 Figure 2 shows a design for Data Extractor in the policy translator.
252 If a high-level policy contains data along the hierarchical structure
253 of the standard Consumer-Facing Interface YANG data model
254 [consumer-facing-inf-dm], data can be easily extracted using the
255 state transition machine, such as DFA. The extracted data can be
256 processed and used by an NSF to understand it. Extractor can be
257 constructed by designing a DFA with the same hierarchical structure
258 as a YANG data model.
260 After constructing a DFA, Data Extractor can extract all of data in
261 the enterred high-level policy by using state transitions. Also, the
262 DFA can easily detect the grammar errors of the high-level policy.
263 The extracting algorithm of Data Extractor is as follows:
265 1. Start from the 'accepter' state.
267 2. Read the next tag from the high-level policy.
269 3. Transit to the corresponding state.
271 4. If the current state is in 'extractor', extract the corresponding
272 data, and then go back to step 2.
274 5. If the current state is in 'middle', go back to step 2.
276 6. If there is no possible transition and arrived at 'accepter'
277 state, the policy has no grammar error. Otherwise, there is a
278 grammar error, so stop the process with failure.
280 4.2.2. Example Scenario for Data Extractor
282
283 block_web
284
285 Son's_PC
286 malicious_websites
287
288 block
289
291 Figure 3: The Example of High-level Policy
293 +----------+
294 | accepter |
295 +----------+
296 | ^
297 | |
298 v |
299 +------------------------------------------------------+
300 | middle 1 |
301 +------------------------------------------------------+
302 | ^ | ^ | ^
303 | | | | | |
304 v | v | v |
305 +-------------+ +----------------------+ +-------------+
306 | extractor 1 | | middle 2 | | extractor 4 |
307 +-------------+ +----------------------+ +-------------+
308 block_web | ^ | ^ block
309 | | | |
310 v | v |
311 +-------------+ +-------------+
312 | extractor 2 | | extractor 3 |
313 +-------------+ +-------------+
314 Son's_PC malicious
315 _websites
317 Figure 4: The Example of Data Extractor
319 To explain the Data Extractor process by referring to an example
320 scenario, assume that Security Controller received a high-level
321 policy for a web-filtering as shown in Figure 3. Then we can
322 construct DFA-based Data Extractor by using the design as shown in
323 Figure 2. Figure 4 shows the architecture of Data Extractor that is
324 based on the architection in Figure 2 along with the input high-level
325 policy in Figure 3. Data Extractor can automatically extract all of
326 data in the high-level policy according to the following process:
328 1. Start from the 'accepter' state.
330 2. Read the first opening tag called '', and transit to the
331 'middle 1' state.
333 3. Read the second opening tag called '', and transit to the
334 'extractor 1' state.
336 4. The current state is an 'extractor' state. Extract the data of
337 'name' field called 'block_web'.
339 5. Read the second closing tag called '', and go back to the
340 'middle 1' state.
342 6. Read the third opening tag called '', and transit to the
343 'middle 2' state.
345 7. Read the fourth opening tag called '', and transit to the
346 'extractor 2' state.
348 8. The current state is an 'extractor' state. Extract the data of
349 'src' field called 'Son's_PC'.
351 9. Read the fourth closing tag called '', and go back to the
352 'middle 2' state.
354 10. Read the fifth opening tag called '', and transit to the
355 'extractor 3' state.
357 11. The current state is an 'extractor' state. Extract the data of
358 'dest' field called 'malicious_websites'.
360 12. Read the fifth closing tag called '', and go back to the
361 'middle 2' state.
363 13. Read the third closing tag called '', and go back to the
364 'middle 1' state.
366 14. Read the sixth opening tag called '', and transit to the
367 'extractor 4' state.
369 15. The current state is an 'extractor' state. Extract the data of
370 'action' field called 'block'.
372 16. Read the sixth closing tag called '', and go back to
373 the 'middle 1' state.
375 17. Read the first closing tag called '', and go back to the
376 'accepter' state.
378 18. There is no further possible transition, and the state is
379 finally on 'accepter' state. There is no grammar error in
380 Figure 3 so the scanning for data extraction is finished.
382 The above process is constructed by an extracting algorithm. After
383 finishing all the steps of the above process, Data Extractor can
384 extract all of data in Figure 3, 'block_web', 'Son's_PC',
385 'malicious', and 'block'.
387 Since the translator is modularized into a DFA structure, a visual
388 understanding is feasible. Also, The performance of Data Extractor
389 is excellent compared to one-to-one searching of data for a
390 particular field. In addition, the management is efficient because
391 the DFA completely follows the hierarchy of Consumer-Facing
392 Interface. If I2NSF User wants to modify the data model of a high-
393 level policy, it only needs to change the connection of the relevant
394 DFA node.
396 4.3. Data Converter
398 4.3.1. Role of Data Converter
400 Every NSF has its own unique capabilities. The capabilities of an
401 NSF are registered into Security Controller by a Developer's
402 Management System, which manages the NSF, via Registration Interface.
403 Therefore, Security Controller already has all information about the
404 capabilities of NSFs. This means that Security Controller can find
405 target NSFs with only the data (e.g., subject and object for a
406 security policy) of the high-level policy by comparing the extracted
407 data with all capabilities of each NSF. This search process for
408 appropriate NSFs is called by policy provisioning, and it eliminates
409 the need for I2NSF User to specify the target NSFs explicitly in a
410 high-level security policy.
412 Data Converter selects target NSFs and converts the extracted data
413 into the capabilities of selected NSFs. If Security Controller uses
414 this data convertor, it can provide the policy provisioning function
415 to I2NSF User automatically. Thus, the translator design provides
416 big benefits to the I2NSF Framework.
418 4.3.2. NSF Database
420 The NSF Database contains all the information needed to convert high-
421 level policy data to low-level policy data. The contents of NSF
422 Database are classified as the following two: "endpoint information"
423 and "NSF capability information".
425 The first is "endpoint information". Endpoint information is
426 necessary to convert an abstract high-level policy data such as
427 Son's_PC, malicious to a specific low-level policy data such as
428 10.0.0.1, illegal.com. In the high-level policy, the range of
429 endpoints for applying security policy MUST be provided abstractly.
430 Thus, endpoint information is needed to specify the abstracted high-
431 level policy data. Endpoint information is provided by I2NSF User as
432 the high-level policy through Consumer-Facing Interface, and Security
433 Controller builds NSF Database based on received information.
435 The second is "NSF capability information". Since capability is
436 information that allows NSF to know what features it can support, NSF
437 capability information is used in policy provisioning process to
438 search the appropriate NSFs through the security policy. NSF
439 capability information is provided by Developer's Management System
440 (DMS) through Registration Interface, and Security Controller builds
441 NSF Database based on received information. In addition, if the NSF
442 sends monitoring information such as initiating information to
443 Security Controller through NSF-Facing Interface, Security Controller
444 can modify NSF Database accordingly.
446 4.3.3. Data Conversion in Data Converter
447 High-level Low-level
448 Policy Data Policy Data
449 +---------------+ +------------------------------+
450 | Rule Name | | Rule Name |
451 | +-----------+ | The Same value | +-------------------------+ |
452 | | block_web |-|------------------->|->| block_web | |
453 | +-----------+ | | +-------------------------+ |
454 | | | |
455 | Source | Conversion into | Source IPv4 |
456 | +-----------+ | User's IP address | +-------------------------+ |
457 | | Son's_PC |-|------------------->|->| [10.0.0.1, 10.0.0.3] | |
458 | +-----------+ | | +-------------------------+ |
459 | | | |
460 | Destination | Conversion into | URL Category |
461 | +-----------+ | malicious websites | +-------------------------+ |
462 | | malicious |-|------------------->|->| [harm.com, | |
463 | | _websites | | | | illegal.com] | |
464 | +-----------+ | | +-------------------------+ |
465 | | | |
466 | Action | Conversion into | Log Action Drop Action |
467 | +-----------+ | NSF Capability | +----------+ +----------+ |
468 | | block |-|------------------->|->| True | | True | |
469 | +-----------+ | | +----------+ +----------+ |
470 +---------------+ +------------------------------+
472 Figure 5: Example of Data Conversion
474 Figure 5 shows an example for describing a data conversion in Data
475 Converter. High-level policy data MUST be converted into low-level
476 policy data which are compatible with NSFs. If a ystem administrator
477 attaches a database to Data Converter, it can convert contents by
478 referring to the database with SQL queries. Data conversion in
479 Figure 5 is based on the following list:
481 o 'Rule Name' field does NOT need the conversion.
483 o 'Source' field SHOULD be converted into a list of target IPv4
484 addresses.
486 o 'Destination' field SHOULD be converted into a URL category list
487 of malicious websites.
489 o 'Action' field SHOULD be converted into the corresponding
490 action(s) in NSF capabilities.
492 4.3.4. Policy Provisioning
494 Log-keeper Low-level Web-filter
495 NSF Policy Data NSF
496 +-------------------+ +--------------------+ +-------------------+
497 | Rule Name | | Rule Name | | Rule Name |
498 | +--------------+ | | +--------------+ | | +--------------+ |
499 | | block_web |<-|<-|<-| block_web |->|->|->| block_web | |
500 | +--------------+ | | +--------------+ | | +--------------+ |
501 | | | | | |
502 | Source IPv4 | | Source IPv4 | | Source IPv4 |
503 | +--------------+ | | +--------------+ | | +--------------+ |
504 | | [10.0.0.1, |<-|<-|<-| [10.0.0.1, |->|->|->| [10.0.0.1, | |
505 | | 10.0.0.3] | | | | 10.0.0.3] | | | | 10.0.0.3] | |
506 | +--------------+ | | +--------------+ | | +--------------+ |
507 | | | | | |
508 | | | URL Category | | URL Category |
509 | | | +--------------+ | | +--------------+ |
510 | | | | [harm.com, |->|->|->| [harm.com, | |
511 | | | | illegal.com] | | | | illegal.com] | |
512 | | | +--------------+ | | +--------------+ |
513 | | | | | |
514 | Log Action | | Log Action | | |
515 | +--------------+ | | +--------------+ | | |
516 | | True |<-|<-|<-| True | | | |
517 | +--------------+ | | +--------------+ | | |
518 +-------------------+ | | | |
519 | Drop Action | | Drop Action |
520 | +--------------+ | | +--------------+ |
521 | | True |->|->|->| True | |
522 | +--------------+ | | +--------------+ |
523 +--------------------+ +-------------------+
525 Figure 6: Example of Policy Provisioning
527 Generator searches for proper NSFs which can cover all of
528 capabilities in the high-level policy. Generator searches for target
529 NSFs by comparing only NSF capabilities which is registered by Vendor
530 Management System. This process is called by "policy provisioning"
531 because Generator finds proper NSFs by using only the policy. If
532 target NSFs are found by using other data which is not included in a
533 user's policy, it means that the user already knows the specific
534 knowledge of an NSF in the I2NSF Framework. Figure 6 shows an
535 example of policy provisioning. In this example, log-keeper NSF and
536 web-filter NSF are selected for covering capabilities in the security
537 policy. All of capabilities can be covered by two selected NSFs.
539 4.4. CFG-based Policy Generator
541 Generator makes low-level security policies for each target NSF with
542 the extracted data. We constructed Generator by using Context Free
543 Grammar (CFG). CFG is a set of production rules which can describe
544 all possible strings in a given formal language(e.g., programming
545 language). The low-level policy also has its own language based on a
546 YANG data model of NSF-Facing Interface. Thus, we can construct the
547 productions based on the YANG data model. The productions that makes
548 up the low-level security policy are categorized into two types,
549 'Content Production' and 'Structure Production'.
551 4.4.1. Content Production
553 Content Production is for injecting data into low-level policies to
554 be generated. A security manager(i.e., a person (or software) to
555 make productions for security policies) can construct Content
556 Productions in the form of an expression as the following
557 productions:
559 o [cont_prod] -> [cont_prod][cont_prod] (Where duplication is
560 allowed.)
562 o [cont_prod] -> [cont_data]
564 o [cont_data] -> data_1 | data_2 | ... | data_n
566 Square brackets mean non-terminal state. If there are no non-
567 terminal states, it means that the string is completely generated.
568 When the duplication of content tag is allowed, the security manager
569 adds the first production for a rule. If there is no need to allow
570 duplication, the first production can be skipped because it is an
571 optional production.
573 The second production is the main production for Content Production
574 because it generates the tag which contains data for low-level
575 policy. Last, the third production is for injecting data into a tag
576 which is generated by the second production. If data is changed for
577 an NSF, the security manager needs to change "only the third
578 production" for data mapping in each NSF.
580 For example, if the security manager wants to express a low-level
581 policy for source IP address, Content Production can be constructed
582 in the following productions:
584 o [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication.)
586 o [cont_ipv4] -> [cont_ipv4_data]
587 o [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3
589 4.4.2. Structure Production
591 Structure Production is for grouping other tags into a hierarchy.
592 The security manager can construct Structure Production in the form
593 of an expression as the following production:
595 o [struct_prod] -> [prod_1]...[prod_n]
597 Structure Production can be expressed as a single production. The
598 above production means to group other tags by the name of a tag which
599 is called by 'struct_tag'. [prod_x] is a state for generating a tag
600 which wants to be grouped by Structure Production. [prod_x] can be
601 both Content Production and Structure Production. For example, if
602 the security manager wants to express the low-level policy for the
603 I2NSF tag, which is grouping 'name' and 'rules', Structure Production
604 can be constructed as the following production where [cont_name] is
605 the state for Content Production and [struct_rule] is the state for
606 Structure Production.
608 o [struct_i2nsf] -> [cont_name][struct_rules]
610 4.4.3. Generator Construction
612 The security manager can build a generator by combining the two
613 productions which are described in Section 4.4.1 and Section 4.4.2.
614 Figure 7 shows the CFG-based Generator construction of the web-filter
615 NSF. It is constructed based on the NSF-Facing Interface Data Model
616 in [nsf-facing-inf-dm]. According to Figure 7, the security manager
617 can express productions for each clause as in following CFG:
619 1. [cont_name] -> [cont_name_data]
621 2. [cont_name_data] -> block_web
623 3. [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication)
625 4. [cont_ipv4] -> [cont_ipv4_data]
627 5. [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3
629 6. [cont_url] -> [cont_url][cont_url] (Allow duplication)
631 7. [cont_url] -> [cont_url_data]
633 8. [cont_url_data] -> harm.com | illegal.com
634 9. [cont_action] -> [cont_action_data]
636 10. [cont_action_data] -> drop
638 11. [struct_packet] -> [cont_ipv4]
640 12. [struct_payload] -> [cont_url]
642 13. [struct_cond] ->
643 [struct_packet][struct_payload]
645 14. [struct_rules] -> [struct_cond][cont_action]
647 15. [struct_i2nsf] -> [cont_name][struct_rules]
649 Then, Generator generates a low-level policy by using the above CFG.
650 The low-level policy is generated by the following process:
652 1. Start: [struct_i2nsf]
654 2. Production 15: [cont_name][struct_rules]
656 3. Production 1: [cont_name_data][struct_rules]
659 4. Production 2: block_web[struct_rules]
662 5. Production 14: block_web[struct_cond][cont_action]
665 6. Production 13: block_web[struct_packet][struct_payload][cont_action]
667
669 7. Production 11: block_web[cont_ipv4][struct_payload]
671 [cont_action]
673 8. Production 3: block_web[cont_ipv4][cont_ipv4][struct_payload]
675 condition>[cont_action]
677 9. Production 4: block_web[cont_ipv4_data][cont_ipv4_dat
679 a][struct_payload][cont_action]
682 10. Production 5: block_web10.0.0.110.0.0.3[struct_payload][cont_action]
686 11. Production 12: block_web10.0.0.110.0.0.3[cont_url][cont_action]
691 12. Production 6: block_web10.0.0.110.0.0.3[cont_url][cont_url][cont_actio
694 n]
696 13. Production 7: block_web10.0.0.110.0.0.3[cont_url_data][cont_url_data]<
699 /payload>[cont_action]
701 14. Production 8: block_web10.0.0.110.0.0.3harm.comillegal.com
704 condition>[cont_action]
706 15. Production 9: block_web10.0.0.110.0.0.3harm.comillegal.com
709 condition>[cont_action_data]
711 16. Production 10: block_web10.0.0.110.0.0.3harm.comillegal.com<
714 /condition>drop
716 The last production has no non-terminal state, and the low-level
717 policy is completely generated. Figure 8 shows the generated low-
718 level policy where tab characters and newline characters are added.
720 +-----------------------------------------------------+
721 | +----------+ +----------+ +----------+ +----------+ |
722 Content | | Rule | | Source | | URL | | Drop | |
723 Production | | Name | | IPv4 | | Category | | Action | |
724 | +-----+----+ +-----+----+ +----+-----+ +----+-----+ |
725 | | | | | |
726 +--------------------+-----------+--------------------+
727 | | | |
728 V V V V
729 +-------+------------+-----------+------------+-------+
730 | | | | | |
731 | | V V | |
732 | | +----------+ +----------+ | |
733 | | | Packet | | Payload | | |
734 | | | Clause | | Clause | | |
735 | | +-----+----+ +----+-----+ | |
736 | | | | | |
737 | | V V | |
738 | | +---------------+ | |
739 | | | Condition | | |
740 Structure | | | Clause | | |
741 Production | | +-------+-------+ | |
742 | | | | |
743 | | V V |
744 | | +----------------------+ |
745 | | | Rule Clause | |
746 | | +-----------+----------+ |
747 | | | |
748 | V V |
749 | +-----------------------------------------+ |
750 | | I2NSF Clause | |
751 | +--------------------+--------------------+ |
752 | | |
753 +--------------------------+--------------------------+
754 |
755 V
756 Low-Level Policy
758 Figure 7: Generator Construction for Web-Filter NSF
759
760 block_web
761
762
763
764 10.0.0.1
765 10.0.0.3
766
767
768 harm.com
769 illegal.com
770
771
772 drop
773
774
776 Figure 8: Example of Low-Level Policy
778 5. Implementation Considerations
780 The implementation considerations in this document include the
781 following three: "data model auto-adaptation", "data conversion", and
782 "policy provisioning".
784 5.1. Data Model Auto-adaptation
786 Security Controller which acts as the intermediary MUST process the
787 data according to the data model of the connected interfaces.
788 However, the data model can be changed flexibly depending on the
789 situation, and Security Controller may adapt to the change.
790 Therefore, Security Controller can be implemented for convenience so
791 that the security policy translator can easily adapt to the change of
792 the data model.
794 The translator constructs and uses the DFA to adapt to Consumer-
795 Facing Interface Data Model. In addition, the CFG is constructed and
796 used to adapt to NSF-Facing Interface Data Model. Both the DFA and
797 the CFG follow the same tree structure of YANG Data Model.
799 The DFA starts at the a node and expands operations by changing the
800 state according to the input. Based on the YANG Data Model, a
801 container node is defined as a middle state and a leaf node is
802 defined as an extractor node. After that, if the nodes are connected
803 in the same way as the hierarchical structure of the data model,
804 Security Controller can automatically construct the DFA. The DFA can
805 be conveniently built by investigating the link structure using the
806 stack, starting with the root node.
808 The CFG starts at the leaf nodes and is grouped into clauses until
809 all the nodes are merged into one node. A leaf node is defined as
810 the content production, and a container node is defined as the
811 structure production. After that, if the nodes are connected in the
812 same way as the hierarchy of the data model, Security Controller can
813 automatically construct the CFG. The CFG can be conveniently
814 constructed by investigating the link structure using the priority
815 queue data, starting with the leaf nodes.
817 5.2. Data Conversion
819 Security Controller requires the ability to materialize the abstract
820 data in the high-level security policy and forward it to NSFs.
821 Security Controller can receive endpoint information as keywords
822 through the high-level security policy. At this time, if the
823 endpoint information corresponding to the keyword is mapped and the
824 query is transmitted to the NSF Database, the NSF Database can be
825 conveniently registered with necessary information for data
826 conversion. When a policy tries to establish a policy through the
827 keyword, Security Controller searches the details corresponding to
828 the keyword registered in the NSF Database and converts the keywords
829 into the appropriate and specified data.
831 5.3. Policy Provisioning
833 This document stated that policy provisioning function is necessary
834 to enable users without expert security knowledge to create policies.
835 Policy provisioning is determined by the capability of the NSF. If
836 the NSF has information about the capability in the policy, the
837 probability of selection increases.
839 Most importantly, selected NSFs may be able to performe all
840 capabilities in the security policy. This document recommends a
841 study of policy provisioning algorithms that are highly efficient and
842 can satisfy all capabilities in the security policy.
844 6. Features of Policy Translator Design
846 First, by showing a visualized translator structure, the security
847 manager can handle various policy changes. Translator can be shown
848 by visualizing DFA and Context-free Grammar so that the manager can
849 easily understand the structure of Policy Translator.
851 Second, if I2NSF User only keeps the hierarchy of the data model,
852 I2NSF User can freely create high-level policies. In the case of
853 DFA, data extraction can be performed in the same way even if the
854 order of input is changed. The design of the policy translator is
855 more flexible than the existing method that works by keeping the tag
856 's position and order exactly.
858 Third, the structure of Policy Translator can be updated even while
859 Policy Translator is operating. Because Policy Translator is
860 modularized, the translator can adapt to changes in the NSF
861 capability while the I2NSF framework is running. The function of
862 changing the translator's structure can be provided through
863 Registration Interface.
865 7. Security Considerations
867 There is no security concern in the proposed security policy
868 translator as long as the I2NSF interfaces (i.e., Consumer-Facing
869 Interface, NSF-Facing Interface, and Registration Interface) are
870 protected by secure communication channels.
872 8. Acknowledgments
874 This work was supported by Institute for Information & communications
875 Technology Promotion (IITP) grant funded by the Korea MSIT (Ministry
876 of Science and ICT) (R-20160222-002755, Cloud based Security
877 Intelligence Technology Development for the Customized Security
878 Service Provisioning).
880 This work was supported in part by the MSIT under the ITRC
881 (Information Technology Research Center) support program (IITP-
882 2018-2017-0-01633) supervised by the IITP.
884 9. References
886 9.1. Normative References
888 [Automata]
889 Peter, L., "Formal Languages and Automata, 6th Edition",
890 January 2016.
892 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
893 Network Configuration Protocol (NETCONF)", RFC 6020,
894 October 2010.
896 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
897 Bierman, "Network Configuration Protocol (NETCONF)",
898 RFC 6241, June 2011.
900 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
901 Protocol", RFC 8040, January 2017.
903 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
904 Kumar, "Framework for Interface to Network Security
905 Functions", RFC 8329, February 2018.
907 [XML] W3C, "On Views and XML (Extensible Markup Language)", June
908 1999.
910 9.2. Informative References
912 [consumer-facing-inf-dm]
913 Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares,
914 "I2NSF Consumer-Facing Interface YANG Data Model", draft-
915 ietf-i2nsf-consumer-facing-interface-dm-03 (work in
916 progress), March 2019.
918 [i2nsf-terminology]
919 Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
920 Birkholz, "Interface to Network Security Functions (I2NSF)
921 Terminology", draft-ietf-i2nsf-terminology-07 (work in
922 progress), July 2019.
924 [nsf-facing-inf-dm]
925 Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin,
926 "I2NSF Network Security Function-Facing Interface YANG
927 Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-03
928 (work in progress), March 2019.
930 [registration-inf-dm]
931 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF
932 Registration Interface YANG Data Model", draft-ietf-i2nsf-
933 registration-interface-dm-02 (work in progress), March
934 2019.
936 [XSLT] W3C, "Extensible Stylesheet Language Transformations
937 (XSLT) Version 1.0", November 1999.
939 Appendix A. Changes from draft-yang-i2nsf-security-policy-
940 translation-02
942 The following changes are made from draft-yang-i2nsf-security-policy-
943 translation-02:
945 o Section 4.3.2 is added for describing 'NSF Database'. This
946 section reinforces the ambiguous description of the NSF Database.
948 o Section 5 is added for describing 'Implementation Considerations'.
949 This section provides guidelines for a convenient implementation
950 of security policy translator.
952 Authors' Addresses
954 Jinhyuk Yang
955 Department of Computer Engineering
956 Sungkyunkwan University
957 2066 Seobu-Ro, Jangan-Gu
958 Suwon, Gyeonggi-Do 16419
959 Republic of Korea
961 Phone: +82 10 8520 8039
962 EMail: jin.hyuk@skku.edu
964 Jaehoon Paul Jeong
965 Department of Software
966 Sungkyunkwan University
967 2066 Seobu-Ro, Jangan-Gu
968 Suwon, Gyeonggi-Do 16419
969 Republic of Korea
971 Phone: +82 31 299 4957
972 Fax: +82 31 290 7996
973 EMail: pauljeong@skku.edu
974 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
976 Jinyong Tim Kim
977 Department of Computer Engineering
978 Sungkyunkwan University
979 2066 Seobu-Ro, Jangan-Gu
980 Suwon, Gyeonggi-Do 16419
981 Republic of Korea
983 Phone: +82 10 8273 0930
984 EMail: timkim@skku.edu