idnits 2.17.1
draft-yang-i2nsf-security-policy-translation-04.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 148: '... an NSF, the NSF MUST receive at least...'
RFC 2119 keyword, line 153: '...ntence, the user MUST know that the NS...'
RFC 2119 keyword, line 161: '... policy is REQUIRED in I2NSF....'
RFC 2119 keyword, line 436: '... security policy MUST be provided abst...'
RFC 2119 keyword, line 538: '...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 (July 24, 2019) is 1709 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)
** Downref: Normative reference to an Informational RFC: RFC 8329
Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 I2NSF Working Group J. Jeong
3 Internet-Draft J. Yang
4 Intended status: Standards Track C. Chung
5 Expires: January 25, 2020 J. Kim
6 Sungkyunkwan University
7 July 24, 2019
9 Security Policy Translation in Interface to Network Security Functions
10 draft-yang-i2nsf-security-policy-translation-04
12 Abstract
14 This document proposes a scheme of security policy translation (i.e.,
15 Security Policy Translator) in Interface to Network Security
16 Functions (I2NSF) Framework. When I2NSF User delivers a high-level
17 security policy for a security service, Security Policy Translator in
18 Security Controller translates it into a low-level security policy
19 for Network Security Functions (NSFs). For this security policy
20 translation, this document specifies the mapping between a high-level
21 security policy based the Consumer-Facing Inteface YANG data model
22 and a low-level security policy based on the NSF-Facing Interface
23 YANG data model. Also, it describes an architecture of a security
24 policy translator along with an NSF database, and the process of
25 security policy translation with the NSF database.
27 Status of This Memo
29 This Internet-Draft is submitted in full conformance with the
30 provisions of BCP 78 and BCP 79.
32 Internet-Drafts are working documents of the Internet Engineering
33 Task Force (IETF). Note that other groups may also distribute
34 working documents as Internet-Drafts. The list of current Internet-
35 Drafts is at https://datatracker.ietf.org/drafts/current/.
37 Internet-Drafts are draft documents valid for a maximum of six months
38 and may be updated, replaced, or obsoleted by other documents at any
39 time. It is inappropriate to use Internet-Drafts as reference
40 material or to cite them other than as "work in progress."
42 This Internet-Draft will expire on January 25, 2020.
44 Copyright Notice
46 Copyright (c) 2019 IETF Trust and the persons identified as the
47 document authors. All rights reserved.
49 This document is subject to BCP 78 and the IETF Trust's Legal
50 Provisions Relating to IETF Documents
51 (https://trustee.ietf.org/license-info) in effect on the date of
52 publication of this document. Please review these documents
53 carefully, as they describe your rights and restrictions with respect
54 to this document. Code Components extracted from this document must
55 include Simplified BSD License text as described in Section 4.e of
56 the Trust Legal Provisions and are provided without warranty as
57 described in the Simplified BSD License.
59 Table of Contents
61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
63 3. Necessity for Policy Translator . . . . . . . . . . . . . . . 3
64 4. Design of Policy Translator . . . . . . . . . . . . . . . . . 4
65 4.1. Overall Structure of Policy Translator . . . . . . . . . 4
66 4.2. DFA-based Data Extractor . . . . . . . . . . . . . . . . 6
67 4.2.1. Design of DFA-based Data Extractor . . . . . . . . . 6
68 4.2.2. Example Scenario for Data Extractor . . . . . . . . . 7
69 4.3. Data Converter . . . . . . . . . . . . . . . . . . . . . 9
70 4.3.1. Role of Data Converter . . . . . . . . . . . . . . . 9
71 4.3.2. NSF Database . . . . . . . . . . . . . . . . . . . . 10
72 4.3.3. Data Conversion in Data Converter . . . . . . . . . . 12
73 4.3.4. Policy Provisioning . . . . . . . . . . . . . . . . . 19
74 4.4. CFG-based Policy Generator . . . . . . . . . . . . . . . 21
75 4.4.1. Content Production . . . . . . . . . . . . . . . . . 21
76 4.4.2. Structure Production . . . . . . . . . . . . . . . . 22
77 4.4.3. Generator Construction . . . . . . . . . . . . . . . 22
78 5. Implementation Considerations . . . . . . . . . . . . . . . . 26
79 5.1. Data Model Auto-adaptation . . . . . . . . . . . . . . . 26
80 5.2. Data Conversion . . . . . . . . . . . . . . . . . . . . . 27
81 5.3. Policy Provisioning . . . . . . . . . . . . . . . . . . . 27
82 6. Features of Policy Translator Design . . . . . . . . . . . . 27
83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
86 9.1. Normative References . . . . . . . . . . . . . . . . . . 28
87 9.2. Informative References . . . . . . . . . . . . . . . . . 29
88 Appendix A. Changes from draft-yang-i2nsf-security-policy-
89 translation-03 . . . . . . . . . . . . . . . . . . . 30
90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
92 1. Introduction
94 This document defines a scheme of a security policy translation in
95 Interface to Network Security Functions (I2NSF) Framework [RFC8329].
96 First of all, this document explains the necessity of a security
97 policy translator (shortly called policy translator) in the I2NSF
98 framework.
100 The policy translator resides in Security Controller in the I2NSF
101 framework and translates a high-level security policy to a low-level
102 security policy for Network Security Functions (NSFs). A high-level
103 policy is specified by I2NSF User in the I2NSF framework and is
104 delivered to Security Controller via Consumer-Facing Interface
105 [consumer-facing-inf-dm]. It is translated into a low-level policy
106 by Policy Translator in Security Controller and is delivered to NSFs
107 to execute the rules corresponding to the low-level policy via NSF-
108 Facing Interface [nsf-facing-inf-dm].
110 2. Terminology
112 This document uses the terminology specified in [i2nsf-terminology]
113 [RFC8329].
115 3. Necessity for Policy Translator
117 Security Controller acts as a coordinator between I2NSF User and
118 NSFs. Also, Security Controller has capability information of NSFs
119 that are registered via Registration Interface [registration-inf-dm]
120 by Developer's Management System [RFC8329]. As a coordinator,
121 Security Controller needs to generate a low-level policy in the form
122 of security rules intended by the high-level policy, which can be
123 understood by the corresponding NSFs.
125 A high-level security policy is specified by RESTCONF/YANG
126 [RFC8040][RFC6020], and a low-level security policy is specified by
127 NETCONF/YANG [RFC6241][RFC6020]. The translation from a high-level
128 security policy to the corresponding low-level security policy will
129 be able to rapidly elevate I2NSF in real-world deployment. A rule in
130 a high-level policy can include a broad target object, such as
131 employees in a company for a security service (e.g., firewall and web
132 filter). Such employees may be from human resource (HR) department,
133 software engineering department, and advertisement department. A
134 keyword of employee needs to be mapped to these employees from
135 various departments. This mapping needs to be handled by a policy
136 translator in a flexible way while understanding the intention of a
137 policy specification. Let us consider the following two policies:
139 o Block my son's computers from malicious websites.
141 o Drop packets from the IP address 10.0.0.1 and 10.0.0.3 to harm.com
142 and illegal.com
144 The above two sentences are examples of policies for blocking
145 malicious websites. Both policies are for the same operation.
146 However, NSF cannot understand the first policy, because the policy
147 does not have any specified information for NSF. To set up the
148 policy at an NSF, the NSF MUST receive at least the source IP address
149 and website address for an operation. It means that the first
150 sentence is NOT compatible for an NSF policy. Conversely, when I2NSF
151 Users request a security policy to the system, they never make a
152 security policy like the second example. For generating a security
153 policy like the second sentence, the user MUST know that the NSF
154 needs to receive the specified information, source IP address and
155 website address. It means that the user understands the NSF
156 professionally, but there are not many professional users in a small
157 size of company or at a residential area. In conclusion, the I2NSF
158 User prefers to issue a security policy in the first sentence, but an
159 NSF will require the same policy as the second sentence with specific
160 information. Therefore, an advanced translation scheme of security
161 policy is REQUIRED in I2NSF.
163 This document proposes an approach using Automata theory [Automata]
164 for the policy translation, such as Deterministic Finite Automaton
165 (DFA) and Context Free Grammar (CFG). Note that Automata theory is
166 the foundation of programming language and compiler. Thus, with this
167 approach, I2NSF User can easily specify a high-level security policy
168 that will be enforced into the corresponding NSFs with a compatibly
169 low-level security policy with the help of Policy Translator. Also,
170 for easy management, a modularized translator structure is proposed.
172 4. Design of Policy Translator
174 Commonly used security policies are created as XML(Extensible Markup
175 Language) [XML] files. A popular way to change the format of an XML
176 file is to use an XSLT (Extensible Stylesheet Language
177 Transformation) [XSLT] document. XSLT is an XML-based language to
178 transform an input XML file into another output XML file. However,
179 the use of XSLT makes it difficult to manage the policy translator
180 and to handle the registration of new capabilities of NSFs. With the
181 necessity for a policy translator, this document describes a policy
182 translator based on Automata theory.
184 4.1. Overall Structure of Policy Translator
185 High-Level Policy
186 Security |
187 Controller V Consumer-Facing Interface
188 +------------------------+-------------------------+
189 | Policy | |
190 | Translator | |
191 | +---------------------+----------------------+ |
192 | | | | |
193 | | +-------+--------+ | |
194 | | | DFA-based | | |
195 | | | Data Extractor | | |
196 | | +-------+--------+ | |
197 | | | Extracted Data from | |
198 | | V High-Level Policy | |
199 | | +-----+-----+ +--------+ | |
200 | | | Data | <-> | NSF DB | | |
201 | | | Converter | +--------+ | |
202 | | +-----+-----+ | |
203 | | | Required Data for | |
204 | | V Target NSFs | |
205 | | +--------+---------+ | |
206 | | | CFG-based | | |
207 | | | Policy Generator | | |
208 | | +--------+---------+ | |
209 | | | | |
210 | +---------------------+----------------------+ |
211 | | |
212 +------------------------+-------------------------+
213 | NSF-Facing Interface
214 V
215 Low-Level Policy
217 Figure 1: The Overall Design of Policy Translator
219 Figure 1 shows the overall design for Policy Translator in Security
220 Controller. There are three main components for Policy Translator:
221 Data Extractor, Data Converter, and Policy Generator.
223 Extractor is a DFA-based module for extracting data from a high-level
224 policy which I2NSF User delivered via Consumer-Facing Interface.
225 Data Converter converts the extracted data to the capabilities of
226 target NSFs for a low-level policy. It refers to an NSF Database
227 (DB) in order to convert an abstract subject or object into the
228 corresponding concrete subject or object (e.g., IP address and
229 website URL). Policy Generator generates a low-level policy which
230 will execute the NSF capabilities from Converter.
232 4.2. DFA-based Data Extractor
234 4.2.1. Design of DFA-based Data Extractor
236 +----------+
237 | accepter |
238 +----------+
239 | ^
240 | |
241 v |
242 +------------------------------------------------------+
243 | middle 1 |
244 +------------------------------------------------------+
245 | ^ | ^ | ^
246 | | | | ... | |
247 v | v | v |
249 ... ... ...
251 +-------------+ +-------------+ +-------------+
252 | extractor 1 | | extractor 2 | ... | extractor m |
253 +-------------+ +-------------+ +-------------+
254 data:1 data:2 data:m
256 Figure 2: DFA Architecture of Data Extractor
258 Figure 2 shows a design for Data Extractor in the policy translator.
259 If a high-level policy contains data along the hierarchical structure
260 of the standard Consumer-Facing Interface YANG data model
261 [consumer-facing-inf-dm], data can be easily extracted using the
262 state transition machine, such as DFA. The extracted data can be
263 processed and used by an NSF to understand it. Extractor can be
264 constructed by designing a DFA with the same hierarchical structure
265 as a YANG data model.
267 After constructing a DFA, Data Extractor can extract all of data in
268 the entered high-level policy by using state transitions. Also, the
269 DFA can easily detect the grammar errors of the high-level policy.
270 The extracting algorithm of Data Extractor is as follows:
272 1. Start from the 'accepter' state.
274 2. Read the next tag from the high-level policy.
276 3. Transit to the corresponding state.
278 4. If the current state is in 'extractor', extract the corresponding
279 data, and then go back to step 2.
281 5. If the current state is in 'middle', go back to step 2.
283 6. If there is no possible transition and arrived at 'accepter'
284 state, the policy has no grammar error. Otherwise, there is a
285 grammar error, so stop the process with failure.
287 4.2.2. Example Scenario for Data Extractor
289
290 block_web
291
292 Son's_PC
293 malicious_websites
294
295 block
296
298 Figure 3: The Example of High-level Policy
300 +----------+
301 | accepter |
302 +----------+
303 | ^
304 | |
305 v |
306 +------------------------------------------------------+
307 | middle 1 |
308 +------------------------------------------------------+
309 | ^ | ^ | ^
310 | | | | | |
311 v | v | v |
312 +-------------+ +----------------------+ +-------------+
313 | extractor 1 | | middle 2 | | extractor 4 |
314 +-------------+ +----------------------+ +-------------+
315 block_web | ^ | ^ block
316 | | | |
317 v | v |
318 +-------------+ +-------------+
319 | extractor 2 | | extractor 3 |
320 +-------------+ +-------------+
321 Son's_PC malicious
322 _websites
324 Figure 4: The Example of Data Extractor
326 To explain the Data Extractor process by referring to an example
327 scenario, assume that Security Controller received a high-level
328 policy for a web-filtering as shown in Figure 3. Then we can
329 construct DFA-based Data Extractor by using the design as shown in
330 Figure 2. Figure 4 shows the architecture of Data Extractor that is
331 based on the architecture in Figure 2 along with the input high-level
332 policy in Figure 3. Data Extractor can automatically extract all of
333 data in the high-level policy according to the following process:
335 1. Start from the 'accepter' state.
337 2. Read the first opening tag called '', and transit to the
338 'middle 1' state.
340 3. Read the second opening tag called '', and transit to the
341 'extractor 1' state.
343 4. The current state is an 'extractor' state. Extract the data of
344 'name' field called 'block_web'.
346 5. Read the second closing tag called '', and go back to the
347 'middle 1' state.
349 6. Read the third opening tag called '', and transit to the
350 'middle 2' state.
352 7. Read the fourth opening tag called '', and transit to the
353 'extractor 2' state.
355 8. The current state is an 'extractor' state. Extract the data of
356 'src' field called 'Son's_PC'.
358 9. Read the fourth closing tag called '', and go back to the
359 'middle 2' state.
361 10. Read the fifth opening tag called '', and transit to the
362 'extractor 3' state.
364 11. The current state is an 'extractor' state. Extract the data of
365 'dest' field called 'malicious_websites'.
367 12. Read the fifth closing tag called '', and go back to the
368 'middle 2' state.
370 13. Read the third closing tag called '', and go back to the
371 'middle 1' state.
373 14. Read the sixth opening tag called '', and transit to the
374 'extractor 4' state.
376 15. The current state is an 'extractor' state. Extract the data of
377 'action' field called 'block'.
379 16. Read the sixth closing tag called '', and go back to
380 the 'middle 1' state.
382 17. Read the first closing tag called '', and go back to the
383 'accepter' state.
385 18. There is no further possible transition, and the state is
386 finally on 'accepter' state. There is no grammar error in
387 Figure 3 so the scanning for data extraction is finished.
389 The above process is constructed by an extracting algorithm. After
390 finishing all the steps of the above process, Data Extractor can
391 extract all of data in Figure 3, 'block_web', 'Son's_PC',
392 'malicious', and 'block'.
394 Since the translator is modularized into a DFA structure, a visual
395 understanding is feasible. Also, the performance of Data Extractor
396 is excellent compared to one-to-one searching of data for a
397 particular field. In addition, the management is efficient because
398 the DFA completely follows the hierarchy of Consumer-Facing
399 Interface. If I2NSF User wants to modify the data model of a high-
400 level policy, it only needs to change the connection of the relevant
401 DFA node.
403 4.3. Data Converter
405 4.3.1. Role of Data Converter
407 Every NSF has its own unique capabilities. The capabilities of an
408 NSF are registered into Security Controller by a Developer's
409 Management System, which manages the NSF, via Registration Interface.
410 Therefore, Security Controller already has all information about the
411 capabilities of NSFs. This means that Security Controller can find
412 target NSFs with only the data (e.g., subject and object for a
413 security policy) of the high-level policy by comparing the extracted
414 data with all capabilities of each NSF. This search process for
415 appropriate NSFs is called by policy provisioning, and it eliminates
416 the need for I2NSF User to specify the target NSFs explicitly in a
417 high-level security policy.
419 Data Converter selects target NSFs and converts the extracted data
420 into the capabilities of selected NSFs. If Security Controller uses
421 this data convertor, it can provide the policy provisioning function
422 to I2NSF User automatically. Thus, the translator design provides
423 big benefits to the I2NSF Framework.
425 4.3.2. NSF Database
427 The NSF Database contains all the information needed to convert high-
428 level policy data to low-level policy data. The contents of NSF
429 Database are classified as the following two: "endpoint information"
430 and "NSF capability information".
432 The first is "endpoint information". Endpoint information is
433 necessary to convert an abstract high-level policy data such as
434 Son's_PC, malicious to a specific low-level policy data such as
435 10.0.0.1, illegal.com. In the high-level policy, the range of
436 endpoints for applying security policy MUST be provided abstractly.
437 Thus, endpoint information is needed to specify the abstracted high-
438 level policy data. Endpoint information is provided by I2NSF User as
439 the high-level policy through Consumer-Facing Interface, and Security
440 Controller builds NSF Database based on received information.
442 The second is "NSF capability information". Since capability is
443 information that allows NSF to know what features it can support, NSF
444 capability information is used in policy provisioning process to
445 search the appropriate NSFs through the security policy. NSF
446 capability information is provided by Developer's Management System
447 (DMS) through Registration Interface, and Security Controller builds
448 NSF Database based on received information. In addition, if the NSF
449 sends monitoring information such as initiating information to
450 Security Controller through NSF-Facing Interface, Security Controller
451 can modify NSF Database accordingly.
453 NSF Capability Information Endpoint Information
454 +-------------------+ has convert +------------------+
455 | NSF +||---+ +-------||+ Endpoint |
456 +-------------------+ | | +------------------+
457 | *nsf_id (INT) | | | | *end_id (INT) |
458 | nsf_name (STRING) | | | | keyword (STRING) |
459 | inbound (INT) | | | +------------------+
460 | outbound (INT) | | |
461 | bandwidth (INT) | | |
462 | activated (BOOL) | | |
463 +-------------------+ | |
464 +---------------+ |
465 /|\ |
466 +--------------------+ has |
467 | Capability +||---+ |
468 +--------------------+ | |
469 | *capa_id (INT) | | |
470 | capa_name (STRING) | | |
471 | capa_index (INT) | | |
472 +--------------------+ | |
473 /|\ /|\
474 +-----------------------+
475 | Field |
476 +-----------------------+
477 | *field_id (INT) |
478 | field_name (STRING) |
479 | field_index (INT) |
480 | mapped_data (STRING) |
481 +-----------------------+
483 Figure 5: Entity-Relationship Diagram of NSF Database
485 Figure 5 shows an Entity-Relationship Diagram (ERD) of NSF Database
486 designed to include both endpoint information received from I2NSF
487 User and NSF capability information received from DMS. By designing
488 the NSF database based on the ERD, all the information necessary for
489 security policy translation can be stored, and the network system
490 administrator can manage the NSF database efficiently.
492 ERD was expressed by using Crow's Foot notation. Crow's Foot
493 notation represents a relationship between entities as a line and
494 represents the cardinality of the relationship as a symbol at both
495 ends of the line. Attributes prefixed with * are key values of each
496 entity. A link with two vertical lines represents one-to-one
497 mapping, and a bird-shaped link represents one-to-many mapping. An
498 NSF entity stores the NSF name (nsf_name), NSF specification
499 (inbound, outbound, bandwidth), and NSF activation (activated). A
500 Capability entity stores the capability name (capa_name) and the
501 index of the capability field in a Registration Interface Data Model
502 (capa_index). An Endpoint entity stores the keyword of abstract data
503 conversion from I2NSF User (keyword). A Field entity stores the
504 field name (field_name), the index of the field index in an NSF-
505 Facing Interface Data Model, and converted data by referring to the
506 Endpoint entity and a 'convert' relationship.
508 4.3.3. Data Conversion in Data Converter
510 High-level Low-level
511 Policy Data Policy Data
512 +---------------+ +------------------------------+
513 | Rule Name | | Rule Name |
514 | +-----------+ | The Same value | +-------------------------+ |
515 | | block_web |-|------------------->|->| block_web | |
516 | +-----------+ | | +-------------------------+ |
517 | | | |
518 | Source | Conversion into | Source IPv4 |
519 | +-----------+ | User's IP address | +-------------------------+ |
520 | | Son's_PC |-|------------------->|->| [10.0.0.1, 10.0.0.3] | |
521 | +-----------+ | | +-------------------------+ |
522 | | | |
523 | Destination | Conversion into | URL Category |
524 | +-----------+ | malicious websites | +-------------------------+ |
525 | | malicious |-|------------------->|->| [harm.com, | |
526 | | _websites | | | | illegal.com] | |
527 | +-----------+ | | +-------------------------+ |
528 | | | |
529 | Action | Conversion into | Log Action Drop Action |
530 | +-----------+ | NSF Capability | +----------+ +----------+ |
531 | | block |-|------------------->|->| True | | True | |
532 | +-----------+ | | +----------+ +----------+ |
533 +---------------+ +------------------------------+
535 Figure 6: Example of Data Conversion
537 Figure 6 shows an example for describing a data conversion in Data
538 Converter. High-level policy data MUST be converted into low-level
539 policy data which are compatible with NSFs. If a system
540 administrator attaches a database to Data Converter, it can convert
541 contents by referring to the database with SQL queries. Data
542 conversion in Figure 6 is based on the following list:
544 o 'Rule Name' field does NOT need the conversion.
546 o 'Source' field SHOULD be converted into a list of target IPv4
547 addresses.
549 o 'Destination' field SHOULD be converted into a URL category list
550 of malicious websites.
552 o 'Action' field SHOULD be converted into the corresponding
553 action(s) in NSF capabilities.
555 Figure 7 shows a mapping list of data fields between Consumer-Facing
556 Interface Data Model and NSF-Facing Interface Data Model. Figure 7
557 describes the process of passing the data value to the appropriate
558 data field of the Data Model in detail after the data conversion.
560 /consumer-facing/policy/policy-name
561 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy
562 /system-policy-name
564 /consumer-facing/policy/rule/rule-name
565 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy
566 /rules/rule-name
568 /consumer-facing/policy
569 /rule/event/time-information/time/begin-time
570 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy
571 /rules/time-zone/absolute-time-zone/start-time
573 /consumer-facing/policy
574 /rule/event/time-information/time/end-time
575 -> mapping: /nsf-facing/i2nsf-security-policy/system-policy
576 /rules/time-zone/absolute-time-zone/end-time
578 /consumer-facing/policy/rule/condition
579 /firewall-condition/source-target/src-target
580 -> reference: /consumer-facing/policy
581 /endpoint-group/user-group/name
582 -> extract: /consumer-facing/policy
583 /endpoint-group/user-group/date
584 -> mapping: /nsf-facing/i2nsf-security-policy
585 /rule/date
586 -> extract: /consumer-facing/policy
587 /endpoint-group/user-group/ip-address
588 -> mapping: /nsf-facing/i2nsf-security-policy
589 /system-policy/rules
590 /condition-clause-container
591 /packet-security-ipv4-condition
592 /pkt-sec-ipv4-src/ipv4-address/ipv4
593 -> extract: /consumer-facing/policy
594 /endpoint-group/user-group/range-ip-address
595 /start-ip-address
596 -> mapping: /nsf-facing/i2nsf-security-policy
597 /system-policy/rules
598 /condition-clause-container
599 /packet-security-ipv4-condition
600 /pkt-sec-ipv4-src/range-ipv4-address
601 /start-ipv4-address
602 -> extract: /consumer-facing/policy
603 /endpoint-group/user-group/range-ip-address
604 /end-ip-address
605 -> mapping: /nsf-facing/i2nsf-security-policy
606 /system-policy/rules
607 /condition-clause-container
608 /packet-security-ipv4-condition
609 /pkt-sec-ipv4-src/range-ipv4-address
610 /end-ipv4-address
612 /consumer-facing/policy/rule/condition
613 /firewall-condition/destination-target/dest-target
614 -> reference: /consumer-facing/policy
615 /endpoint-group/user-group/name
616 -> extract: /consumer-facing/policy
617 /endpoint-group/user-group/date
618 -> mapping: /nsf-facing/i2nsf-security-policy
619 /system-policy/rule/date
620 -> extract: /consumer-facing/policy
621 /endpoint-group/user-group/ip-address
622 -> mapping: /nsf-facing/i2nsf-security-policy
623 /system-policy/rules
624 /condition-clause-container
625 /packet-security-ipv4-condition
626 /pkt-sec-ipv4-dest/ipv4-address/ipv4
627 -> extract: /consumer-facing/policy
628 /endpoint-group/user-group
629 /range-ip-address/start-ip-address
630 -> mapping: /nsf-facing/i2nsf-security-policy
631 /system-policy/rules
632 /condition-clause-container
633 /packet-security-ipv4-condition
634 /pkt-sec-ipv4-dest/range-ipv4-address
635 /start-ipv4-address
636 -> extract: /consumer-facing/policy
637 /endpoint-group/user-group
638 /range-ip-address/end-ip-address
639 -> mapping: /nsf-facing/i2nsf-security-policy
640 /system-policy/rules
641 /condition-clause-container
642 /packet-security-ipv4-condition
643 /pkt-sec-ipv4-dest/range-ipv4-address
644 /end-ipv4-address
646 /consumer-facing/policy/rule/condition
647 /ddos-condition/source-target/src-target
648 -> reference: /consumer-facing/policy
649 /endpoint-group/device-group/name
650 -> extract: /consumer-facing/policy
651 /endpoint-group/device-group/date
652 -> mapping: /nsf-facing/i2nsf-security-policy/rule/date
653 -> extract: /consumer-facing/policy
654 /endpoint-group/device-group/ip-address
655 -> mapping: /nsf-facing/i2nsf-security-policy
656 /system-policy/rules
657 /condition-clause-container
658 /packet-security-ipv4-condition
659 /pkt-sec-ipv4-src/ipv4-address/ipv4
660 -> extract: /consumer-facing/policy
661 /endpoint-group/device-group
662 /range-ip-address/start-ip-address
663 -> mapping: /nsf-facing/i2nsf-security-policy
664 /system-policy/rules
665 /condition-clause-container
666 /packet-security-ipv4-condition
667 /pkt-sec-ipv4-src/range-ipv4-address
668 /start-ipv4-address
669 -> extract: /consumer-facing/policy
670 /endpoint-group/device-group
671 /range-ip-address/end-ip-address
672 -> mapping: /nsf-facing/i2nsf-security-policy
673 /system-policy/rules
674 /condition-clause-container
675 /packet-security-ipv4-condition
676 /pkt-sec-ipv4-src/range-ipv4-address
677 /end-ipv4-address
679 /consumer-facing/policy/rule/condition
680 /ddos-condition/destination-target/dest-target
681 -> reference: /consumer-facing/policy
682 /endpoint-group/device-group/name
683 -> extract: /consumer-facing/policy
684 /endpoint-group/device-group/date
685 -> mapping: /nsf-facing/i2nsf-security-policy/rule/date
686 -> extract: /consumer-facing/policy
687 /endpoint-group/device-group/ip-address
688 -> mapping: /nsf-facing/i2nsf-security-policy
689 /system-policy/rules
690 /condition-clause-container
691 /packet-security-ipv4-condition
692 /pkt-sec-ipv4-dest/ipv4-address/ipv4
693 -> extract: /consumer-facing/policy
694 /endpoint-group/device-group
695 /range-ip-address/start-ip-address
696 -> mapping: /nsf-facing/i2nsf-security-policy
697 /system-policy/rules
698 /condition-clause-container
699 /packet-security-ipv4-condition
700 /pkt-sec-ipv4-dest/range-ipv4-address
701 /start-ipv4-address
702 -> extract: /consumer-facing/policy
703 /endpoint-group/device-group
704 /range-ip-address/end-ip-address
705 -> mapping: /nsf-facing/i2nsf-security-policy
706 /system-policy/rules
707 /condition-clause-container
708 /packet-security-ipv4-condition
709 /pkt-sec-ipv4-dest/range-ipv4-address
710 /end-ipv4-address
712 /consumer-facing/policy/rule/condition
713 /ddos-condition/rate-limit/packet-per-second
714 -> mapping: /nsf-facing/i2nsf-security-policy
715 /system-policy/rules/condition-clause-container
716 /packet-security-ddos-condition/pkt-sec-alert-rate
718 /consumer-facing/policy/rule/condition
719 /custom-condition/source-target/src-target
720 -> reference: /consumer-facing/policy
721 /threat-prevention/payload-content/name
722 -> extract: /consumer-facing/policy
723 /threat-prevention/payload-content/date
724 -> mapping: /nsf-facing/i2nsf-security-policy
725 /system-policy/rules/date
726 -> extract: /consumer-facing/policy
727 /threat-prevention/payload-content/content
728 -> mapping: /nsf-facing/i2nsf-security-policy
729 /system-policy/rules
730 /condition-clause-container
731 /packet-security-payload-condition
732 /pkt-payload-content
734 /consumer-facing/policy/rule/condition
735 /custom-condition/destination-target/dest-target
736 -> reference: /consumer-facing/policy
737 /threat-prevention/payload-content/name
738 -> extract: /consumer-facing/policy
739 /threat-prevention/payload-content/date
740 -> mapping: /nsf-facing/i2nsf-security-policy
741 /system-policy/rules/date
743 -> extract: /consumer-facing/policy
744 /threat-prevention/payload-content/content
745 -> mapping: /nsf-facing/i2nsf-security-policy
746 /system-policy/rules
747 /condition-clause-container
748 /packet-security-payload-condition
749 /pkt-payload-content
751 /consumer-facing/policy/rule/condition
752 /custom-condition/threat-feed-condition
753 /source-target/src-target
754 -> reference: /consumer-facing/policy
755 /threat-prevention/threat-feed-list/name
756 -> extract: /consumer-facing/policy
757 /threat-prevention/threat-feed-list/date
758 -> mapping: /nsf-facing/i2nsf-security-policy
759 /system-policy/rules/date
760 -> extract: /consumer-facing/policy
761 /threat-prevention/threat-feed-list
762 /threat-feed-server/ip-address
763 -> mapping: /nsf-facing/i2nsf-security-policy
764 /system-policy/rules
765 /condition-clause-container
766 /packet-security-ipv4-condition
767 /pkt-sec-ipv4-src/ipv4-address/ipv4
768 -> extract: /consumer-facing/policy
769 /threat-prevention/threat-feed-list
770 /threat-feed-server/range-ip-address
771 /start-ip-address
772 -> mapping: /nsf-facing/i2nsf-security-policy
773 /system-policy/rules
774 /condition-clause-container
775 /packet-security-ipv4-condition
776 /pkt-sec-ipv4-src/range-ipv4-address
777 /start-ipv4-address
778 -> extract: /consumer-facing/policy
779 /threat-prevention/threat-feed-list
780 /threat-feed-server/range-ip-address
781 /end-ip-address
782 -> mapping: /nsf-facing/i2nsf-security-policy
783 /system-policy/rules
784 /condition-clause-container
785 /packet-security-ipv4-condition
786 /pkt-sec-ipv4-src/range-ipv4-address
787 /end-ipv4-address
788 -> extract: /consumer-facing/policy
789 /threat-prevention/threat-feed-list
790 /threat-feed-server
791 /threat-feed-description
792 -> mapping: /nsf-facing/i2nsf-security-policy
793 /system-policy/rules
794 /condition-clause-container
795 /packet-security-ipv4-condition
796 /ipv4-description
798 /consumer-facing/policy/rule/condition
799 /custom-condition/threat-feed-condition
800 /destination-target/dest-target
801 -> reference: /consumer-facing/policy
802 /threat-prevention/threat-feed-list/name
803 -> extract: /consumer-facing/policy
804 /threat-prevention/threat-feed-list/date
805 -> mapping: /nsf-facing/i2nsf-security-policy
806 /system-policy/rules/date
807 -> extract: /consumer-facing/policy
808 /threat-prevention/threat-feed-list
809 /threat-feed-server/ip-address
810 -> mapping: /nsf-facing/i2nsf-security-policy
811 /system-policy/rules
812 /condition-clause-container
813 /packet-security-ipv4-condition
814 /pkt-sec-ipv4-dest/ipv4-address/ipv4
815 -> extract: /consumer-facing/policy
816 /threat-prevention/threat-feed-list
817 /threat-feed-server/range-ip-address
818 /start-ip-address
819 -> mapping: /nsf-facing/i2nsf-security-policy
820 /system-policy/rules
821 /condition-clause-container
822 /packet-security-ipv4-condition
823 /pkt-sec-ipv4-dest/range-ipv4-address
824 /start-ipv4-address
825 -> extract: /consumer-facing/policy
826 /threat-prevention/threat-feed-list
827 /threat-feed-server/range-ip-address
828 /end-ip-address
829 -> mapping: /nsf-facing/i2nsf-security-policy
830 /system-policy/rules
831 /condition-clause-container
832 /packet-security-ipv4-condition
833 /pkt-sec-ipv4-dest/range-ipv4-address
834 /end-ipv4-address
835 -> extract: /consumer-facing/policy
836 /threat-prevention/threat-feed-list
837 /threat-feed-server
838 /threat-feed-description
840 -> mapping: /nsf-facing/i2nsf-security-policy
841 /system-policy/rules
842 /condition-clause-container
843 /packet-security-ipv4-condition
844 /ipv4-description
846 /consumer-facing/policy/rule/action/name
847 -> mapping: /nsf-facing/i2nsf-security-policy
848 /system-policy/rules/action-clause-container
849 /packet-action/ingress-action
850 -> mapping: /nsf-facing/i2nsf-security-policy
851 /system-policy/rules/action-clause-container
852 /packet-action/egress-action
853 -> mapping: /nsf-facing/i2nsf-security-policy
854 /system-policy/rules/action-clause-container
855 /packet-action/log-action
856 -> mapping: /nsf-facing/i2nsf-security-policy
857 /system-policy/rules/action-clause-container
858 /advanced-action/content-security-control
859 -> mapping: /nsf-facing/i2nsf-security-policy
860 /system-policy/rules/action-clause-container
861 /advanced-action/attack-mitigation-control
863 /consumer-facing/policy/rule/ipsec-method
864 -> mapping: /nsf-facing/i2nsf-ipsec
866 /consumer-facing/policy-domain/name
867 -> mapping: /nsf-facing/i2nsf-security-policy
868 /system-policy/rule-group/groups/group-name
870 Figure 7: Mapping Information for Data Conversion
872 4.3.4. Policy Provisioning
873 Log-keeper Low-level Web-filter
874 NSF Policy Data NSF
875 +-------------------+ +--------------------+ +-------------------+
876 | Rule Name | | Rule Name | | Rule Name |
877 | +--------------+ | | +--------------+ | | +--------------+ |
878 | | block_web |<-|<-|<-| block_web |->|->|->| block_web | |
879 | +--------------+ | | +--------------+ | | +--------------+ |
880 | | | | | |
881 | Source IPv4 | | Source IPv4 | | Source IPv4 |
882 | +--------------+ | | +--------------+ | | +--------------+ |
883 | | [10.0.0.1, |<-|<-|<-| [10.0.0.1, |->|->|->| [10.0.0.1, | |
884 | | 10.0.0.3] | | | | 10.0.0.3] | | | | 10.0.0.3] | |
885 | +--------------+ | | +--------------+ | | +--------------+ |
886 | | | | | |
887 | | | URL Category | | URL Category |
888 | | | +--------------+ | | +--------------+ |
889 | | | | [harm.com, |->|->|->| [harm.com, | |
890 | | | | illegal.com] | | | | illegal.com] | |
891 | | | +--------------+ | | +--------------+ |
892 | | | | | |
893 | Log Action | | Log Action | | |
894 | +--------------+ | | +--------------+ | | |
895 | | True |<-|<-|<-| True | | | |
896 | +--------------+ | | +--------------+ | | |
897 +-------------------+ | | | |
898 | Drop Action | | Drop Action |
899 | +--------------+ | | +--------------+ |
900 | | True |->|->|->| True | |
901 | +--------------+ | | +--------------+ |
902 +--------------------+ +-------------------+
904 Figure 8: Example of Policy Provisioning
906 Generator searches for proper NSFs which can cover all of
907 capabilities in the high-level policy. Generator searches for target
908 NSFs by comparing only NSF capabilities which is registered by Vendor
909 Management System. This process is called by "policy provisioning"
910 because Generator finds proper NSFs by using only the policy. If
911 target NSFs are found by using other data which is not included in a
912 user's policy, it means that the user already knows the specific
913 knowledge of an NSF in the I2NSF Framework. Figure 8 shows an
914 example of policy provisioning. In this example, log-keeper NSF and
915 web-filter NSF are selected for covering capabilities in the security
916 policy. All of capabilities can be covered by two selected NSFs.
918 4.4. CFG-based Policy Generator
920 Generator makes low-level security policies for each target NSF with
921 the extracted data. We constructed Generator by using Context Free
922 Grammar (CFG). CFG is a set of production rules which can describe
923 all possible strings in a given formal language(e.g., programming
924 language). The low-level policy also has its own language based on a
925 YANG data model of NSF-Facing Interface. Thus, we can construct the
926 productions based on the YANG data model. The productions that makes
927 up the low-level security policy are categorized into two types,
928 'Content Production' and 'Structure Production'.
930 4.4.1. Content Production
932 Content Production is for injecting data into low-level policies to
933 be generated. A security manager(i.e., a person (or software) to
934 make productions for security policies) can construct Content
935 Productions in the form of an expression as the following
936 productions:
938 o [cont_prod] -> [cont_prod][cont_prod] (Where duplication is
939 allowed.)
941 o [cont_prod] -> [cont_data]
943 o [cont_data] -> data_1 | data_2 | ... | data_n
945 Square brackets mean non-terminal state. If there are no non-
946 terminal states, it means that the string is completely generated.
947 When the duplication of content tag is allowed, the security manager
948 adds the first production for a rule. If there is no need to allow
949 duplication, the first production can be skipped because it is an
950 optional production.
952 The second production is the main production for Content Production
953 because it generates the tag which contains data for low-level
954 policy. Last, the third production is for injecting data into a tag
955 which is generated by the second production. If data is changed for
956 an NSF, the security manager needs to change "only the third
957 production" for data mapping in each NSF.
959 For example, if the security manager wants to express a low-level
960 policy for source IP address, Content Production can be constructed
961 in the following productions:
963 o [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication.)
965 o [cont_ipv4] -> [cont_ipv4_data]
966 o [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3
968 4.4.2. Structure Production
970 Structure Production is for grouping other tags into a hierarchy.
971 The security manager can construct Structure Production in the form
972 of an expression as the following production:
974 o [struct_prod] -> [prod_1]...[prod_n]
976 Structure Production can be expressed as a single production. The
977 above production means to group other tags by the name of a tag which
978 is called by 'struct_tag'. [prod_x] is a state for generating a tag
979 which wants to be grouped by Structure Production. [prod_x] can be
980 both Content Production and Structure Production. For example, if
981 the security manager wants to express the low-level policy for the
982 I2NSF tag, which is grouping 'name' and 'rules', Structure Production
983 can be constructed as the following production where [cont_name] is
984 the state for Content Production and [struct_rule] is the state for
985 Structure Production.
987 o [struct_i2nsf] -> [cont_name][struct_rules]
989 4.4.3. Generator Construction
991 The security manager can build a generator by combining the two
992 productions which are described in Section 4.4.1 and Section 4.4.2.
993 Figure 9 shows the CFG-based Generator construction of the web-filter
994 NSF. It is constructed based on the NSF-Facing Interface Data Model
995 in [nsf-facing-inf-dm]. According to Figure 9, the security manager
996 can express productions for each clause as in following CFG:
998 1. [cont_name] -> [cont_name_data]
1000 2. [cont_name_data] -> block_web
1002 3. [cont_ipv4] -> [cont_ipv4][cont_ipv4] (Allow duplication)
1004 4. [cont_ipv4] -> [cont_ipv4_data]
1006 5. [cont_ipv4_data] -> 10.0.0.1 | 10.0.0.3
1008 6. [cont_url] -> [cont_url][cont_url] (Allow duplication)
1010 7. [cont_url] -> [cont_url_data]
1012 8. [cont_url_data] -> harm.com | illegal.com
1013 9. [cont_action] -> [cont_action_data]
1015 10. [cont_action_data] -> drop
1017 11. [struct_packet] -> [cont_ipv4]
1019 12. [struct_payload] -> [cont_url]
1021 13. [struct_cond] ->
1022 [struct_packet][struct_payload]
1024 14. [struct_rules] -> [struct_cond][cont_action]
1026 15. [struct_i2nsf] -> [cont_name][struct_rules]
1028 Then, Generator generates a low-level policy by using the above CFG.
1029 The low-level policy is generated by the following process:
1031 1. Start: [struct_i2nsf]
1033 2. Production 15: [cont_name][struct_rules]
1035 3. Production 1: [cont_name_data][struct_rules]
1038 4. Production 2: block_web[struct_rules]
1041 5. Production 14: block_web[struct_cond][cont_action]
1044 6. Production 13: block_web[struct_packet][struct_payload][cont_action]
1046
1048 7. Production 11: block_web[cont_ipv4][struct_payload]
1050 [cont_action]
1052 8. Production 3: block_web[cont_ipv4][cont_ipv4][struct_payload]
1054 condition>[cont_action]
1056 9. Production 4: block_web[cont_ipv4_data][cont_ipv4_dat
1058 a][struct_payload][cont_action]
1061 10. Production 5: block_web10.0.0.110.0.0.3[struct_payload][cont_action]
1065 11. Production 12: block_web10.0.0.110.0.0.3[cont_url][cont_action]
1070 12. Production 6: block_web10.0.0.110.0.0.3[cont_url][cont_url][cont_actio
1073 n]
1075 13. Production 7: block_web10.0.0.110.0.0.3[cont_url_data][cont_url_data]<
1078 /payload>[cont_action]
1080 14. Production 8: block_web10.0.0.110.0.0.3harm.comillegal.com
1083 condition>[cont_action]
1085 15. Production 9: block_web10.0.0.110.0.0.3harm.comillegal.com
1088 condition>[cont_action_data]
1090 16. Production 10: block_web10.0.0.110.0.0.3harm.comillegal.com<
1093 /condition>drop
1095 The last production has no non-terminal state, and the low-level
1096 policy is completely generated. Figure 10 shows the generated low-
1097 level policy where tab characters and newline characters are added.
1099 +-----------------------------------------------------+
1100 | +----------+ +----------+ +----------+ +----------+ |
1101 Content | | Rule | | Source | | URL | | Drop | |
1102 Production | | Name | | IPv4 | | Category | | Action | |
1103 | +-----+----+ +-----+----+ +----+-----+ +----+-----+ |
1104 | | | | | |
1105 +--------------------+-----------+--------------------+
1106 | | | |
1107 V V V V
1108 +-------+------------+-----------+------------+-------+
1109 | | | | | |
1110 | | V V | |
1111 | | +----------+ +----------+ | |
1112 | | | Packet | | Payload | | |
1113 | | | Clause | | Clause | | |
1114 | | +-----+----+ +----+-----+ | |
1115 | | | | | |
1116 | | V V | |
1117 | | +---------------+ | |
1118 | | | Condition | | |
1119 Structure | | | Clause | | |
1120 Production | | +-------+-------+ | |
1121 | | | | |
1122 | | V V |
1123 | | +----------------------+ |
1124 | | | Rule Clause | |
1125 | | +-----------+----------+ |
1126 | | | |
1127 | V V |
1128 | +-----------------------------------------+ |
1129 | | I2NSF Clause | |
1130 | +--------------------+--------------------+ |
1131 | | |
1132 +--------------------------+--------------------------+
1133 |
1134 V
1135 Low-Level Policy
1137 Figure 9: Generator Construction for Web-Filter NSF
1138
1139 block_web
1140
1141
1142
1143 10.0.0.1
1144 10.0.0.3
1145
1146
1147 harm.com
1148 illegal.com
1149
1150
1151 drop
1152
1153
1155 Figure 10: Example of Low-Level Policy
1157 5. Implementation Considerations
1159 The implementation considerations in this document include the
1160 following three: "data model auto-adaptation", "data conversion", and
1161 "policy provisioning".
1163 5.1. Data Model Auto-adaptation
1165 Security Controller which acts as the intermediary MUST process the
1166 data according to the data model of the connected interfaces.
1167 However, the data model can be changed flexibly depending on the
1168 situation, and Security Controller may adapt to the change.
1169 Therefore, Security Controller can be implemented for convenience so
1170 that the security policy translator can easily adapt to the change of
1171 the data model.
1173 The translator constructs and uses the DFA to adapt to Consumer-
1174 Facing Interface Data Model. In addition, the CFG is constructed and
1175 used to adapt to NSF-Facing Interface Data Model. Both the DFA and
1176 the CFG follow the same tree structure of YANG Data Model.
1178 The DFA starts at the node and expands operations by changing the
1179 state according to the input. Based on the YANG Data Model, a
1180 container node is defined as a middle state and a leaf node is
1181 defined as an extractor node. After that, if the nodes are connected
1182 in the same way as the hierarchical structure of the data model,
1183 Security Controller can automatically construct the DFA. The DFA can
1184 be conveniently built by investigating the link structure using the
1185 stack, starting with the root node.
1187 The CFG starts at the leaf nodes and is grouped into clauses until
1188 all the nodes are merged into one node. A leaf node is defined as
1189 the content production, and a container node is defined as the
1190 structure production. After that, if the nodes are connected in the
1191 same way as the hierarchy of the data model, Security Controller can
1192 automatically construct the CFG. The CFG can be conveniently
1193 constructed by investigating the link structure using the priority
1194 queue data, starting with the leaf nodes.
1196 5.2. Data Conversion
1198 Security Controller requires the ability to materialize the abstract
1199 data in the high-level security policy and forward it to NSFs.
1200 Security Controller can receive endpoint information as keywords
1201 through the high-level security policy. At this time, if the
1202 endpoint information corresponding to the keyword is mapped and the
1203 query is transmitted to the NSF Database, the NSF Database can be
1204 conveniently registered with necessary information for data
1205 conversion. When a policy tries to establish a policy through the
1206 keyword, Security Controller searches the details corresponding to
1207 the keyword registered in the NSF Database and converts the keywords
1208 into the appropriate and specified data.
1210 5.3. Policy Provisioning
1212 This document stated that policy provisioning function is necessary
1213 to enable users without expert security knowledge to create policies.
1214 Policy provisioning is determined by the capability of the NSF. If
1215 the NSF has information about the capability in the policy, the
1216 probability of selection increases.
1218 Most importantly, selected NSFs may be able to perform all
1219 capabilities in the security policy. This document recommends a
1220 study of policy provisioning algorithms that are highly efficient and
1221 can satisfy all capabilities in the security policy.
1223 6. Features of Policy Translator Design
1225 First, by showing a visualized translator structure, the security
1226 manager can handle various policy changes. Translator can be shown
1227 by visualizing DFA and Context-free Grammar so that the manager can
1228 easily understand the structure of Policy Translator.
1230 Second, if I2NSF User only keeps the hierarchy of the data model,
1231 I2NSF User can freely create high-level policies. In the case of
1232 DFA, data extraction can be performed in the same way even if the
1233 order of input is changed. The design of the policy translator is
1234 more flexible than the existing method that works by keeping the tag
1235 's position and order exactly.
1237 Third, the structure of Policy Translator can be updated even while
1238 Policy Translator is operating. Because Policy Translator is
1239 modularized, the translator can adapt to changes in the NSF
1240 capability while the I2NSF framework is running. The function of
1241 changing the translator's structure can be provided through
1242 Registration Interface.
1244 7. Security Considerations
1246 There is no security concern in the proposed security policy
1247 translator as long as the I2NSF interfaces (i.e., Consumer-Facing
1248 Interface, NSF-Facing Interface, and Registration Interface) are
1249 protected by secure communication channels.
1251 8. Acknowledgments
1253 This work was supported by Institute of Information & Communications
1254 Technology Planning & Evaluation (IITP) grant funded by the Korea
1255 MSIT (Ministry of Science and ICT) (R-20160222-002755, Cloud based
1256 Security Intelligence Technology Development for the Customized
1257 Security Service Provisioning).
1259 This work was supported in part by the MSIT under the ITRC
1260 (Information Technology Research Center) support program (IITP-
1261 2018-2017-0-01633) supervised by the IITP.
1263 9. References
1265 9.1. Normative References
1267 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the
1268 Network Configuration Protocol (NETCONF)", RFC 6020,
1269 October 2010.
1271 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
1272 Bierman, "Network Configuration Protocol (NETCONF)",
1273 RFC 6241, June 2011.
1275 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1276 Protocol", RFC 8040, January 2017.
1278 [RFC8329] Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
1279 Kumar, "Framework for Interface to Network Security
1280 Functions", RFC 8329, February 2018.
1282 9.2. Informative References
1284 [Automata]
1285 Peter, L., "Formal Languages and Automata, 6th Edition",
1286 January 2016.
1288 [consumer-facing-inf-dm]
1289 Jeong, J., Kim, E., Ahn, T., Kumar, R., and S. Hares,
1290 "I2NSF Consumer-Facing Interface YANG Data Model", draft-
1291 ietf-i2nsf-consumer-facing-interface-dm-06 (work in
1292 progress), July 2019.
1294 [i2nsf-terminology]
1295 Hares, S., Strassner, J., Lopez, D., Xia, L., and H.
1296 Birkholz, "Interface to Network Security Functions (I2NSF)
1297 Terminology", draft-ietf-i2nsf-terminology-08 (work in
1298 progress), July 2019.
1300 [nsf-facing-inf-dm]
1301 Kim, J., Jeong, J., Park, J., Hares, S., and Q. Lin,
1302 "I2NSF Network Security Function-Facing Interface YANG
1303 Data Model", draft-ietf-i2nsf-nsf-facing-interface-dm-07
1304 (work in progress), July 2019.
1306 [registration-inf-dm]
1307 Hyun, S., Jeong, J., Roh, T., Wi, S., and J. Park, "I2NSF
1308 Registration Interface YANG Data Model", draft-ietf-i2nsf-
1309 registration-interface-dm-05 (work in progress), July
1310 2019.
1312 [XML] W3C, "On Views and XML (Extensible Markup Language)", June
1313 1999.
1315 [XSLT] W3C, "Extensible Stylesheet Language Transformations
1316 (XSLT) Version 1.0", November 1999.
1318 Appendix A. Changes from draft-yang-i2nsf-security-policy-
1319 translation-03
1321 The following changes are made from draft-yang-i2nsf-security-policy-
1322 translation-03:
1324 o In Section 4.3.2, an Entity-Relationship Diagram (ERD) is added
1325 for describing the architecture of NSF Database. It describes the
1326 design of the NSF Database.
1328 o In Section 4.3.3, a mapping list between Consumer-Facing Interface
1329 Data Model and NSF-Facing Interface Data Model is added for
1330 describing the data mapping process in detail after the data
1331 conversion. This section provides guidelines of data converter
1332 for a security policy translator developer. Also, this mapping
1333 helps this document to be useful as a standard document.
1335 Authors' Addresses
1337 Jaehoon Paul Jeong
1338 Department of Computer Science and Engineering
1339 Sungkyunkwan University
1340 2066 Seobu-Ro, Jangan-Gu
1341 Suwon, Gyeonggi-Do 16419
1342 Republic of Korea
1344 Phone: +82 31 299 4957
1345 Fax: +82 31 290 7996
1346 EMail: pauljeong@skku.edu
1347 URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
1349 Jinhyuk Yang
1350 Department of Electronic, Electrical and Computer Engineering
1351 Sungkyunkwan University
1352 2066 Seobu-Ro, Jangan-Gu
1353 Suwon, Gyeonggi-Do 16419
1354 Republic of Korea
1356 Phone: +82 10 8520 8039
1357 EMail: jin.hyuk@skku.edu
1358 Chaehong Chung
1359 Department of Electronic, Electrical and Computer Engineering
1360 Sungkyunkwan University
1361 2066 Seobu-Ro, Jangan-Gu
1362 Suwon, Gyeonggi-Do 16419
1363 Republic of Korea
1365 Phone: +82 10 8541 7158
1366 EMail: darkhong@skku.edu
1368 Jinyong Tim Kim
1369 Department of Electronic, Electrical and Computer Engineering
1370 Sungkyunkwan University
1371 2066 Seobu-Ro, Jangan-Gu
1372 Suwon, Gyeonggi-Do 16419
1373 Republic of Korea
1375 Phone: +82 10 8273 0930
1376 EMail: timkim@skku.edu