[I2nsf] Capability Model - Yang Model Split and what it means for you

["Susan Hares" <[e-mail]>]

The capability model drafts have made a huge step forward between IETF 97
and IETF 98.   I'd like to comment on this progress, and what it means to
I2NSF WG.   I will present this in terms of an American slang phrase - the
good, the bad, and the ugly.    A big thanks goes to the Korean "dream team"
that implemented so much of the capability model. 

 

Sue 

 

------

The Good: 

 

The capability drafts have been split into 3 types of drafts, and it has
been partially implemented!!! 

 

1)      Capability draft -base model (Informational Model, Data Model) 

a.      draft-xibassnez-i2nsf-capability-00

b.      draft-hares-i2nsf-capability-data-model/
<https://datatracker.ietf.org/doc/draft-hares-i2nsf-capability-data-model/> 

 

2)      NSF facing interface - data model 

a.      draft-kim-i2nsf-consumer-facing-interface-dm-00

 

3)      Client facing interface information models 

draft-kumar-i2nsf-client-facing-interface-im/                     

draft-you-i2nsf-user-group-based-policy-02  

draft-you-i2nsf-user-group-policy-capability-00 (beginnings of info model) 

draft-kim-i2nsf-consumer-facing-interface-dm/ (no yang yet, hopefully after
hackathon)  

 

This break down allows the general capabilities to be common and supports
the architecture below

(this copy from draft-kim-i2nsf-security-management-architecture-03, but it
has been part of  our discussions for a while.   One thing that has been
added is the ability for the security controller to have registrations. 

 

Question:  Does the client side have registrations as well? 





   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | I2NSF User                                                        |

   |                        +-+-+-+-+-+-+-+-+-+-+-+                    |

   |                     ---|  Application Logic  |<--                 |

   |                     |  +-+-+-+-+-+-+-+-+-+-+-+  |                 |

   |                     |                           |                 |

   |                     |                           |                 |

   |              +-+-+-+v+-+-+-+-+-+         +-+-+-+v+-+-+-+          |

   |              | Policy Updater  |         |  Event      |          |

   |              +-+-+-+-+-+-+-+-+-+         |  Collector  |          |

   |                          |               +-+-+-+^+-+-+-+          |

   |                          |                      |                 |

   |                          |                      |                 |

   |                          |    -------------------                 |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              |    | Consumer-Facing Interface

   +-+-+-+-+-+-+-+-+-+-+-+-+-+|+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |Security Management System|    |                                   |

   |       +-+-+-+-+-+-+-+-+-+v+-+-+-+-+                               |

   |       |Security Controller        |                               |

   |       | +-+-+-+-+-+ +-+-+-+-+-+-+ | Registration                  |

   |       | |Security | |NSF        | |  Interface  +-+-+-+-+-+-+-+   |

   |       | |Policy   | |Capability | |<----------->| controllers |   |

   |       | |Manager  | |Manager    | |             | Mgnt System |   |

   |       | +-+-+-+-+-+ +-+-+-+-+-+-+ |             +-+-+-+-+-+-+-+   |

   |       +-+-+-+-+-+-^-+-+-+-+-+-+-+-+                               |

   +-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 |--------------------------------- NSF-Facing Interface

   +-+-+-+-+-+-+-|-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+|+-+-+-+-+-+-+-+-+-+-+

   |NSF Instances|            |                   |                    |

   |        +-+-+v+-+-+  +-+-+v+-+-+         +-+-+v+-+-+               |

   |        |   NSF   |  |   NSF   |  . . .  |   NSF   |               |

   |        +-+-+-+-+-+  +-+-+-+-+-+         +-+-+-+-+-+               |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

            Figure 1: Security Management Architecture in I2NSF

 

This architecture is capable of differentiating between trusted sources and
non-trusted source.  This is a good step forward.  Thanks to Sangwon Hyun,
SangUk Woo, YunSuk Yeo,  Paul ( Jaehoon) Jeong, and Jung-Soo Park for this
advance.  

There is a good chance this has been implemented!! 

 

   +-+-+-+-+-+            +-+-+-+-+-+             +-+-+-+-+-+-+-+
   | Source  |----------->| Firewall|------------>| Destination |
   +-+-+-+-+-+            +-+-+-+-+-+             +-+-+-+-+-+-+-+
 
             (a) Traffic flow of trusted source
 
 
   +-+-+-+-+-+     +-+-+-+-+-+     +-+-+-+-+-+     +-+-+-+-+-+-+-+
   | Source  |---->|Firewall |---->|   DPI   |---->| Destination |
   +-+-+-+-+-+     +-+-+-+-+-+     +-+-+-+-+-+     +-+-+-+-+-+-+-+
 
             (b) Traffic flow of untrusted source

 

Drawing is in: draft-hyun-i2nsf-sfc-enabled-i2nsf-01 and
draft-hyun-i2nsf-sfc-enabled-i2nsf-01.  

 

========

The BAD: 

 

.        The link between I2NSF Capabilities and Flow Policy has been broken


Operators use Flow Filter policy (aka policy based routing) in routers,
simple switches, and security devices.   We've lost the link to the NETCONF
ACLs, I2RS Filter-based policy, and the BGP Flow Specification filter
policy.   This policy has been replaced by a simple policy for flow filters
in the capability. 

 

Possible fixes:  

o   go back to I2RS FB-RIB policy link (draft-hares-pkt-eca-policy) 

o   Allow a configuration parameter to choose between simple policy,  I2RS
Filter-based Policy, extended policy.   Cost: 1 parameter that specifies
what model is being used, and Choice statement in model

.        Group policy is not in the aligned capability model IM/DM 

Group policy allows users to design policy based on the role of a group.
Grouping policy allows users to be able to think according to human groups.


 

The two models of group policy do not intermix, and overlap in concepts.
Both models have useful pieces that should be intermixed.  However, both
models do not link well to the routing and OPS area work on group policy.
It would be really useful if our chairs could organize a side-meeting on
this topic this week.  The side-meetings were very helpful at IETF 96. 

 

.        Attestations are not represented 

Attestations are a key component of the  I2NSF architecture.  Is the WG
assuming that all Security devices must do Attestations?  How are we getting
a trusted channel?  If the channel is not trusted, do we need to send a
small signal "I'm getting queried by a non-trusted node" - just like the
DOTS sends the "I'm being DOS attacked). 

 

.        Monitoring capabilities not list included in the capabilities 

draft-zhang-i2nsf-info-model-monitoring-02 suggest some monitoring in terms
of alarms, events, system log, system counters, network events, and NSF
logs.   This draft only presents some of the logical types, and does not
link them to the NETCONF/RESTCONF management work.   Three levels of things
are needed: 

 

o   Critical events (Tell me Now)  Some Alarms + some events + some network
events  are critical for the NSF controller to get. 

o   Need to know (Tell me Soon): Some events,  some network events, some
counters exceeded

o   Record (I'll process later):  some alarms, some network events, most
system counters, system log, and NSF log 

o   Telemetry - things which you want to know to decide on how flows are
going to work.  Telemetry is not setting configurations.  Telemetry is deep
reporting of status.  IPFix was built for telemetry work, but it lacks some
of the application layer management that the NETCONF pub/sub work does.   

 

I2RS spawn the work in NETCONF to support multiple event streams (push/pull)
with from a NETCONF server (aka NSF device) to NETCOFN client (NSF
controller).   Traceability in I2RS handles the System log and NSF log.
You should really look up these types of events.  

 

Another ugliness related to monitoring is the early work in the SECEVENT WG
which ignores the pub/sub work done in NETCONF/RESTCONF.   Rather than
create another protocol, it would be useful to simply create a data model
out of this security information and a new 

 

.        No document seems to global security design exists for the security
associations so that a network with multi-vendor deployments has a common
security association 

 

Choices:  (see draft-moskowitz-dots-identities-00) 

o   web PKI model (fraught with leakage challenges), 

o   IEEE 802.1AR device identity certificate model  - LDevID (used by
Netconf-zerotouch)

o   Raw public keys (some unauthenticated data will be necessary which
presents a risk) DANE [RFC6698] provides the necessary details to validate a
TLS Raw key 

o   Hierarchical HIT (based on HIP work) 

 

===========

The Ugly 

.        draft-mglt-i2nsf-ssf-collaboration and
draft-hares-i2nsf-ddos-yang-dm - are working on higher level Inter-Cloud
DDOS work.  

 

Daniel did not look at [draft-
fang-i2nsf-inter-cloud-ddos-mitigation-api-01] to see what Microsoft cloud
wanted. Luyuan Fang let the draft expire - so this may be Daniel's
confusion.  Daniel apologized for not checking this draft . Since we've been
co-authors on other I2RS drafts, we'll work this out as implementers.  

 

A second ugliness is I2NSF lacks a second Cloud provider for the API.  

 

The third ugliness is that I used the capability model at inter-domain level
so that the providers could explain their capability.  Luyuan suggested this
concept, and I think it is a good one.   My understanding is that the
inter-domain relationship would have a unique security domain. 

 

[cloud provider-1]   -----inter-domain exchange ---------- [cloud provider
2] 

              Security domain 1       ---   security domain 2
------ security domain 3 

 

.        Another ugly factor is that we really do not know how some of the
other Cloud providers want to handle DDoS API.  If the SECEVENT people are
trying to inform security events using JSON web tokens, I wonder why they
are standardizing half the solution (token + data) without standardizing how
to do the management streams (stream, stream-id, transport, rates of
transaction). 

 

.        DOTS devices are NSF devices, and should be part of the management
of the whole network 

 

DOTS devices are NSF devices focused on handling DOS attacks.  Having DOTS
disconnected from the rest of the I2NSF management creates a silo.   Linking
the I2NSF mgr with the DOTS mgr makes sense.  

 

      Client -- I2NSF mgr  --- NSF 

                               \

       DOTS client --- DOTS-mgr 

 

.        MILE disconnect from I2NSF 

(draft-mile-rolie-05.txt) states that 

 

"This document defines a resource-oriented approach for security automation
information publication, discovery, and sharing.  Using  this approach,
producers may publish, share, and exchange representations of security
incidents, attack indicators, software  vulnerabilities, configuration
checklists, and other security    automation information as Web-addressable
resources." 

 

If a node is utilizing MILE to share configuration check-list, attack
indicators and I2NSF is monitoring the same information - one has to ask
"why both are being done"?  It seems like two hands - the left handed
security protocol is not talking to the right handed security protocols.  

                 

.        SACM - records security postures (RFC7632) - using the IPFIX
telemetry to support Target endpoint discover, characterization,
classification plus collection of information and evaluation.  There is also
a portion of the data model to handle how the SACM Manager does SACM
component discovery,  component authentication, and component authorization,
and component registration. 

 

What's ugly in the I2NSF/SACM/DOTS work?  - DOTS is doing telemetry about
DOS, I2NSF needs to do telemetry in addition to events, notifications, logs,
and alarms.  SACM has mgr/client relationship and is doing component
registration.  Sound familiar?  It should since you've read it within this
message. 

 

Is the security building lots of YAP (yet another protocol) rather than
looking at the component parts? That's what it seems to me, but perhaps I'm
missing something about the security association.  

 

I hope this has stirred up a bit of conversation on the open issues for
I2NSF.   I'm looking forward to IETF 97's hackathon and I2NSF on Monday. 

 

Sue