Base interface, VLAN, and zone updates for observer traffic #752
Conversation
Addding core observer, network fields for tracking connection flows from e.g. netflow, firewalls (ingress, egress, etc.)
Updated change & pr #
|
somehow the inner / outer vlan fields got lost in the shuffle from multiple PRs, I'll try and get that updated tomorrow |
There was a problem hiding this comment.
Thanks @dainperkins
I notice that interface.id and vlan.id are both core and the rest is extended. What was the thinking there?
Got a few additional comments below. But we should be good to go soon, this is in line with what we discussed :-)
schemas/interface.yml
Outdated
| description: > | ||
| Optional interface name as reported by the system. Could be short (eth0), long (gigabitethernet0/2), |
There was a problem hiding this comment.
I'm all for flexibility, but I wonder if users will want to track more than of those at the same time? E.g. the computer-generated one ("eth0") as well as the customized one ("dmz").
There was a problem hiding this comment.
typically I'ver seen an observer use 1 or the other, but that begs the question of mixing interface name (gigabitethernet0/1) with logical name (outside)
Maybe we should add alias in the first go round? (for logical interface custom names in e.g. firewalls)
There was a problem hiding this comment.
I added alias - we can pick another name, but I think we would be better off NOT mixing actual interface names (eth0, gigabitethernet0/1, etc) with aliases (outside, inside, dmz, etc)
There was a problem hiding this comment.
also - dropped everything to extended
address @webmat items, added interface.aslias, fixed network nesting for vlan id/name (network.vlan.., network.inner/outer.vlan...) fixed examples
schemas/observer.yml
Outdated
| - name: egress.zone | ||
| level: extended | ||
| type: keyword | ||
| short: Observer Egress Zone |
There was a problem hiding this comment.
| short: Observer Egress Zone | |
| short: Observer egress zone |
schemas/vlan.yml
Outdated
| description: > | ||
| The VLAN fields describe information about ingress and egress vlans reported | ||
| by an observer. |
There was a problem hiding this comment.
I think we should use the vlan description to give some guidance on when to use network.vlan.* vs network.inner|outer.vlan.* e.g. when populating inner/outer, should the user also populate network.vlan.*? If so, with which value?
Same thing with observer.ingress|egress.vlan.* vs network*.vlan.*. Should they be populated at the same time? If not, when to pick one vs the other?
There was a problem hiding this comment.
good ideas - I'll put something in
There was a problem hiding this comment.
I'm going to update vlan.yml to be a little more prescriptive, both in the specific vlan fields, as well as utilizing them for network state (vlan of traffic, inner, outer, etc.
Updates pushed
There was a problem hiding this comment.
Thanks for the adjustments so far. The observer.* vs network.* vlan fields usage is clearer now.
I'm not sure we've clarified whether network.vlan.* needs to be populated, when network.inner|outer.vlan.* are populated. When we populate inner/outer VLAN info, should we also populate network.vlan.*? If so, with what?
There was a problem hiding this comment.
well thats a bugger now that you have me thinking about it... maybe we can come to a quick decision on the call
Updated descriptions to better define nesting and utilization of vlan etc.
removed outer.vlan in favor of "network.vlan" representing the native external vlan, with inner.vlan to represent an additional nested vlan for q-in-q
schemas/interface.yml
Outdated
| reported by an observer (e.g. firewall, router, load balancer) in the context of the | ||
| observer handling a network connection. In the case of a single observer interface | ||
| (e.g. network sensor on a span port) only the observer.ingress information should be | ||
| completed. |
There was a problem hiding this comment.
| completed. | |
| populated. |
schemas/vlan.yml
Outdated
|
|
||
| Observer.ingress and observer.egress VLAN values are used to record observer specific | ||
| information when observer events contain discrete ingress and egress VLAN information, | ||
| typically provided by firewalls, routera, or load balancers. |
There was a problem hiding this comment.
| typically provided by firewalls, routera, or load balancers. | |
| typically provided by firewalls, routers, or load balancers. |
Addding core observer, network, vlan, zone fields for tracking connection flows from e.g. netflow, firewalls (ingress, egress, etc.)