Minutes IETF105: i2nsf
minutes-105-i2nsf-00

?
Thurs July 25, 2019
10:00 - 12:00 (2 hours)
Room: Sainte-Catherine
?
Chairs:
  Linda Dunbar      dunbar.ll@gmail.com
  Yoav Nir                    ynir.ietf@gmail.com
AD:
  Roman Danyliw; rdd@cert.org
?
=======
?
Agenda bashing, blue sheets, and Note Well, Document status (10 min)

IPR scare on the mailing list. Now resolved. (FRAND)
Yoav: SDN IPsec cover two base scenarios. Controller based IKE is something in
between. we decided not to adopt to WG.

?draft-ietf-i2nsf-applicability is on the IESG agenda, secdir and opsdir
reviews are done.

There was a joint meeting yesterday for discussion about LPWAN.  Yang model
held up issue of how to encode IANA registries in documents.  Don't want to
have to revise our documents to track e.g. GOST documents.  By referencing the
registry, an implementation can start doing GOST without us revising the
draft.  Draft is out, ready to submit to IESG in the next few days.

Gap analysis will be kept until work (??) is finished.

IPSEC flow protection draft only covered initial flow configuration.   There's
another scenario, re-key mechanism, is covered by a different draft that was
discussed in DISPATCH.

Yoav: controller draft is a different document that is supposed to do something
different.   Our document has two modes of operation (cases).  Controller is
trying to do something in the middle.   Documents we have do rekeying just
fine.  We don't need controller IKE for that.   Controller IKE is a middle
ground that we've seen in this WG and decided not to adopt, maybe will get
adopted somewhere else.  In any case don't need it for the scenarios we are
covering.

[Information Model & Data Model slide]

[Wiki slide]

- I2NSF Hackathon Project: 5 min (Jaehoon Paul Jeong)
? https://trac.ietf.org/trac/ietf/meeting/wiki/105hackathon

?3rd year for Hackathon.

"Security on air" - security everywhere like air is the goal of the project.

Demonstrated three interfaces: Registration inferface to register via
NETconf/Yang.   Consumer-facing interface, time-based web service access
limits.  Policy will be translated by security controller.  Policy is delivered
over NSF-facing interface.  Linked using service-function-chaining. 
Implemented two scenarios: block social networks during work, and block access
to all web sites.

Lessons:

    Our system can be run on top of public cloud system.
    Verified three interfaces: consumer-facing, nsf-facing and registration
    interfaces. Showed security policy translator.   Very usable tool to
    empower deploying on top of I2NSF system in the real world: high level YANG
    already prepared, NSF-facing yang model, those high level and low level
    hang models can be linked using this translator. Integrated I2NSF on top of
    commercial platform, Wins Firewall. See slides for link to video clip that
    shows the whole process. https://github.com/kimjinyong/i2nsf-framework
    (source code)

Yoav: very encouraging that you are working with commercial firewall.   Do you
think you will be able to work with either commercial firewalls like Cisco and
Palo Alto, or is this, Wins is one I've never heard of.

Paul: In Korea it's famous, maybe not internationally.  Cisco or Juniper, in
order to integrate, they need to implement NSF-facing interface, also
Registration interface.   If they are willing to implement, we can test
together.

Diego lopes: this morning I was discussing with chair of NMRG, we are looking
for a way of formalizing intent languages.   Formalizing intent is an endless
task, but idea was to find common patters/semantics.   Do you have a formal
definition of the language?  Definition of policies?

Paul: you can see, consumer-facing interface, the basic important thing is the
ECA policy rule.   According to that, they are a yang model, so this interface
is just a 1:1 map according to yang model.  In order to provide intent-based,
my research lab has interest in it, we need to process e.g. user-specified
flexible specification of polocy, we need to understand.   Right now we just
won't do that.

Diego Lopes: So using ECA could be a valid model for the underlying semantics.

IPsec Flow Protection (15 min): Gabriel López
Report changes from WGLC comments, making it ready for submitting to IESG
?

[slide: changes from v04 to v05 1/5]
[slide: changes from v04 to v05 2/5]
[slide: changes from v04 to v05 3/5]
[slide: changes from v04 to v05 4/5]
[slide: changes from v04 to v05 5/5]
[next steps]

New version, minor changes
Request publication

Yoav: in previous meetings uyou've mentioned running code.   Can you say a few
words about that?

Gabriel: yes, we have source code to test model, currently this source code is
based on previous version, we have to update the code to this last version.  
We are waiting to have a more stable draft version bc the changes from the last
version to this one are very intensive changes, so our idea is to adapt the
source code.   Link to repo was presented in last meeting, I can send it again
to the ML if you need it.

Diego Lopes: we have a studnet working for us goal is to implement key
distribution scheme, well and IPSEC distribution schema using the models we
have, our own network orchestration OSM, to use IPSEC as defining the model.  
Demonstrating that it is applicable in the case of a any v deployments and
control service model.   And we are waiting for the new version.

?
I2NSF Data Models major changes to address YANG Doctor comments:
?
- I2NSF YANG Data Model Drafts: 20 min (Jaehoon Paul Jeong)
? I2NSF Capability YANG Data Model
? https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/
?
? I2NSF NSF-Facing Interface YANG Data Model
? https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-facing-interface-dm/
?
? I2NSF Consumer-Facing Interface YANG Data Model
?
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/
? ? I2NSF Registration Interface YANG Data Model ?
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-registration-interface-dm/ ?
? I2NSF Monitoring YANG Data Model ?
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-monitoring-data-model/ ? ?

Submitted to hang doctors who gace review.
[Slide: WG documents of Yang Data Models]

Based on base YANG data model, we produced four interface data models.  These
are revised according to YANG Doctors comments.   We hvae verified these over 9
hackathons. [Slide: Updates from previous Versions] Most comments addressed.
Except (see slide) We need to import the ACL definition, it takes time, so next
wednesday we will reflected that replacement. NSF-facing case we defined again,
so YANG doctor says why not use capability.   So we will use.   We can reflect
for one week, then go for WGLC.  Consumer-facing and registration ready for
WGLC, I think.

[Updates of Capability Data mOdel (DM) 2/2]

[Updates to NSF-Facing Interface DM 1/2]
[Updates to NSF-Facing Interface DM 2/2]

[Updates of Registration Interface DM (1/2)]
[Updates of Registration Interface DM (2/2)]

[NSF Monitoring DM]
Not ready for WGLC.  Plan to show in Singapore.

[Next Steps]

Capability DM already requested IESG evaluation.
NSF-facing, consuimer-facing, registration ready for WGLC, but NSF needs some
refactoring, so will let chairs to WGLC.

Monitoring: next IETF meeting

Diego Lopes: I saw the document about the registartion interface.  In the case
of the registration interface, based on discussion in prague, about pointing
with registration offer capabilities made, pointer to the YANG model fragment
that can be used to control that capability in another model.   If you
remember, we were talking about ?? in YANG schema to make that reference.   I'd
like to see if this can be used bc would support translation process like the
one you are working on.   If you want to touch this capability, go to this more
specific one, part of the NSF-facing interface can be useful formanaging the
capabilities.

Paul: also, the one thing is all three interfaces specify i2nsf ipsec, so right
now we can use IPsec as well.

Diego: I just remembered, please ask me when you mention this IPsec, would be
interesting to show that.  T he most detail yang schema we have now ...
probably would be nice to hae in the registration interface an example, "for
this cabaility, can point to this other schema."   We have these guys from ...
are doing a YANG schema, this capabiklity is about IKEless, IKE, SA setup,
would link to this piece of and show a schema moiunt.

Paul: so we can the schema moiunt to accommodate IPSEC?

Diego: would be a good way to make a self-contained set of the group
?
Security Policy Translation Draft: 5 min (Jaehoon Paul Jeong)
?
https://datatracker.ietf.org/doc/draft-yang-i2nsf-security-policy-translation/
? ? This document specifies linkage btw two YANG data models, provide
implementation guideline for architectural translation, also process of
translation.

[Necessity for Policy Translator]

Right now we are using priprietary mechanism to populate this information into
the firewall database.   "malicious websites -> harm.com, illegal.com"

Goal is given this high-level policy, translate into low-level policy "block
malicious web site on my son's computer" -> low level policy

[Proposed Translation]

XSLT has been used to map from high-level to low-level, this provides a more
flexible link from high-level to low-level.

[Updates from Previous Version]

Roman: why does that mapping need to be standardized?

Paul: because without, the designer or software engineer figure it out.  
Sometimes mapping is not 1:1 but 1:many.   In that case, we specify
consumer-facing and NSF-facing.  Developer time, it will be hard to figure out
how to map.

Roman: I understand the gap, as in what the SW engineer doesn't understand, but
that seems like that would happen in the same org building the controler, so
why would we want to standardize?   Don't we only want to standardize cross-org
links?

Paul: this information should be populated by operator.   NSF capability caze
provided by vendors, data structure should be shared by each other, what kind
of field should be populated.   Wiothout that it is difficult to translate.  
Somehow we need to define relationship between capability and endpoint
information.   Second, this mapping, (points to slide)
policy/rule/conditoin/ddos/source-target/src-target -> ... -> mapping
i2nsf-security-policy/rule/date.   So developer can understand how to implement
their interface.

Susan Hares: SO Roman, I was encouraging him to put this out as a standard.  I
was hoping an example like this might give them an idea.   I don't know if this
goes on to be a published standard, I just want to get to where when we get
into a BGP security situation we have an example to point to.  I'm happy to see
this for a different reason than the security vendors.   I'm working with
routing security, VPNs, this may be of some clue.   Whether it is or not
depends on how security vendors look.  Diego may have more pointers.

Linda: informational?

Paul: yes.

Diego: I think that this is as Sue said, valuable as an example.  What I think
we should try to standardize is how we serialize these mappings, the mechanisms
for showing the mappings, not the mappings themselves, bc these will be
app-specific or function-specific.   Would be applicable not only in case of
security but all other cases.   I see it's very much connected with some
activities that have been discussed to start here in this meeting in a couple
of sac meetings, netmod group, etc., about bringing yang one or a couple of
steps forward so it can be more useful for real network operations.   How do
you build these kind of mappings from one model to another.  Which are the
mechanisms to show this relationsupi, not the relationships themselves, but how
do yo make the binding?

Roman: point of clarification, draft says "standards track."

Paul: I will fix.

Frank Xia Huawei: I haven't heard detail about this document, but my current
feeling is that of course this document will have its valuable for this work,
but only when document does not only cover mapping between customer-facing
interface model and NSF-facing data model.   The more important part, the
better way to write this document should be to write something about your
internal arch design and the process how to do the mapping, but not the mapping
itself.   That be a valuable contribution to the industry bc I can see that not
only in i2nsf, but a lot of service provision model we have two levels of data
kodel, we need this kind of general mapping.   I'm hoping to see this kind of
things, but not only the mapping.

Another point I want to see in this doc is if you give some example from i2nsf
perspective for how to translate sercurity service model to security
configuration model, but please give some more advanced example.   First pasge
you just give very very simple example.   We want to see e.g. end-to-end way to
see security service, maybe in the past there are several security functions,
how we chain them together, how we map this kind of ?? model to the several
part of models, NSF-interface facing model.   Would be more useful.

Paul: currently we explain simple web filter, we can combine firewall and web
filter logging together.  In SFC case we need to improve example.

[Architecture of Security pOlicy Tranlsator]

Given this architecture, vendor can easily implement.  This morning engineer
doing ACTM they also met yesterdya working for HTN he has a lot of interest in
this work.  IMO we try to focus this concrete example i2nsf first, then try to
generalize.   If we broaden at this moment, it takes maybe 2 years.   This is
not easy.   Will be starting point for other area.

Frank Xia: you still need to give us a general system how it work to do this
mapping.   My point there is mapping is not important, HOW to do mapping is
important.

Paul: "how too map" means given higher level yang, low level yang, how to map
some leaf node to some other leaf node automatically?   What do you mean by
"mapping?"   Currently this is not ML, this is operator populating manually.  
Maybe in the future, given high-level YANG< low-level YANG, ML case can figure
out, but takes several years.  I have interest in it, but right now I try to
using rule-based mpaping, is feasible for right now.

Susan: Clarifying question for Frank.   My understanding is that you treasure
the ability to have the arch and methodology of doing the translation btw
high-level YANG data extractor and the policy detail, but what you are really
looking for is the draft to specify that it is just an example.

Frank: I thikn youa re right, you understand my point.  My pojnt is that the
example is not our goal, but just to clarify how we do this mapping.  
Appplicable to other use cases, policy mappings.   Increases values of
document, just truing to help you to make your document more useful.   If it is
only useful for i2nsf, maybe it's useful but not so useful.

Susan: For use case I'm doing in routing, this general use case is helpful for
understanding high level policy that we've developed for security, esp. IPsec
stuff.   So I appreciated this oducment, wha tthe WG does with it, what the AD
does it, the fact that it is currently existing is very helpful.

Roman: the doucments I've seen today from 2insf, was primarily first enumerate
the arch, then describe what is the role of those boxes, and what goes in and
out of those boxes.   Information flow, APIs, data models.   As I read this,
this strikes me as something diffgerent, going insdie one of those boxes, not
API in and out of the box, but about what's happening inside the box.

Paul: right.   So the thing is, I think last three yaers, hackathon project,
this translation is very useful part, I want to share to IETF< our community,
this can be expanded for the general, e.g. for some network configuration, so
Ibelieve we need to decide we can adopt this work for i2nsf first and then
expand to other areas.

Roma; that's helpful, that seems like a difgferent scope, we might wan tto talk
about what that means relative to the charter.   I agree about the utility.

Pual: may I ask for WGLC, as a group we can decide?

Roman: it's not a WG draft.

Paul, sorry, adoption, not last call.

Roman: I will squint at the charter.

Yoav: please give results of squint on ML.

OPEN MIC (ANY OTHER BUSINESS)

Paul: right now Roman mentioned charter, as I understand i2nsf is focued on
framework and interfaces, and those are primarily our goals.   Maybe after our
main primary task such as we are promising or interfaces data models, we can
recharter, consider some deployment of i2nsf.   I think security policy
translator is one thing.   Other is, during our hackathon project, SFC, SDN
controller, that kind of interface that are not specified, so to realize i2nsf
mayhbe we can add new item, data model for those SFC i2nsf interaction, i2nsf
SDN interaction.

Yoav: I'd like to mentiont that a couple of days ago I submitted an individual
draft that's profile of IPsec ...that is use case in the data center, not a WG
draft, not asking for adoption, might do after SDN IPsec draft goes through
IESG.  Might ask for adoption.  Will talk with SDN IPsec authors, others who
are interested in i2nsf and encryption.

Linda: question for Paul: you have NFV arch draft?   Plan for other draft to be
dropped?

Paul: we have another doucment about reference architecture based on i2nsf.  
That one is for how to develop i2nsf on top of cloud system such as ..
reference architecture.  nfv.  How to impleent i2nsf on top of ETSI Netwokr
Function Virtualization architecture.   How to build I2NSF ... and link to NFV
reference model.   If WG thinks this is useful, we target the informational
RFC, if WG have interest in it.

Right now we didn't discuss yet.