Subject: [babel] Babel management info model

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 8 Apr 2016 17:06:15 +0000

Repeating what I said in the BoF...
The router in a home network that is most likely to be managed is the ISP-provided router. There are 100s of millions of those around the world, and the ones that are managed are managed using BBF TR-069. AFAIK, none are managed using netconf.

Therefore I recommend creating an information model that can be used to create any management protocol data model (e.g., YANG or TR-069).

Something I didn't say in the BoF, but would like to add...
There are many retail routers that ship today with support for SNMP management. As most consumers are unaware of what SNMP is or does and are not very knowledgeable about securing or disabling it, this SNMP is often used by hackers to get access to people's home routers. In the ISP-provided routers I've been able to influence, I've explicitly forbidden SNMP from even existing in the firmware. It's good for enterprises with remote workers who need to manage the workers' routers and have IT people who (sort of but often not really) know what they're doing. It's incredibly bad in an unmanaged environment (which is the target homenet and Babel environment). Management protocols in unmanaged or poorly-managed routers are an open invitation to hackers. 

Retail routers that do support management protocols must not have some sort of automated (no user involvement required) way of establishing a trust relationship with any management entity. And they must not use default credentials. Establishing trust must always be under the control of the user, and should not be something the user is encouraged to do without understanding the risks. It must not be tied to establishment of trust for a different purpose (e.g., do not automatically assign trust to manage just because a device is trusted to be on the physical network). A key premise of homenet is that we cannot expect users to have a good grasp of security. Therefore, it's critical that any homenet routing protocol in retail devices be able to operate well without user (or service provider) configuration/management. If management of the routing protocol is needed for it to work reasonably well, then we have already failed.

With that said, I can definitely see cases where Babel may be used in managed routers that exist inside the homenet, and where the service provider (who may be an ISP, ASP, enterprise, or a geek squad of some sort) is supplying and managing those routers. Such providers do like to be able to tweak settings in order to optimize the routing protocol function. Therefore, I do think it's a good idea to define the information model.
Barbara

---

From: Dave Taht <[email-masked]>
Date: Fri, 8 Apr 2016 10:18:28 -0700

I am sad that snmp is so underused, underappreciated, and
underconfigured today. There are many cases where I or a more advanced
(small business user) would like to be able to obtain upstream
statistics and configuration information from my isp-provided device
and to not have it be such a black box.

Compared to say, upnp, the typical read-only nature of snmp statistics
has not struck me as a "threat", per se, and with tools like mrtg,
cacti, etc, widely available to process them, still useful.

Graphical (web) monitoring of key statistics at the router is a
feature that most home routers have, in fact it is often a selling
point.

tools like collectd, vnstat, and so on have evolved beyond pure snmp

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 8 Apr 2016 17:32:31 +0000

Hi Dave, great to hear from you! We missed you.

> There are many cases where I or a more advanced (small business
> user) would like to be able to obtain upstream statistics and configuration
> information from my isp-provided device and to not have it be such a black
> box.
--snip--
> Graphical (web) monitoring of key statistics at the router is a feature that
> most home routers have, in fact it is often a selling point.

I totally agree that we need a standard (xml or json data model) that can be used by routers to provide info about themselves (WAN/LAN statistics, etc.). My thinking is that if routers supplied this via their http server, and advertised the URL using DNS-SD, that it would be really useful. I was talking with Juliusz about that just yesterday. And, yes, if something like that existed I would definitely push for it to go into ISP-provided routers.

My email was really about configuration and not statistics. Though even wrt statistics, unsecured SNMP can be dangerous, since it has been used to launch DDoS attacks against certain providers' SNMP servers.
Barbara

---

From: Henning Rogge <[email-masked]>
Date: Fri, 8 Apr 2016 19:59:45 +0200

> My email was really about configuration and not statistics. Though even wrt statistics, unsecured SNMP can be dangerous, since it has been used to launch DDoS attacks against certain providers' SNM…

Maybe I could point you to http://netjson.org/ which is a
collaborative attempt for some "standardized router information via
JSON" of several mesh routing protocol people.

Henning Rogge

---

From: Denis Ovsienko <[email-masked]>
Date: Fri, 08 Apr 2016 23:33:44 +0100

---- On Fri, 08 Apr 2016 18:18:28 +0100 Dave Taht<[email-masked]> wrote ---- 
 > feature that most home routers have, in fact it is often a selling 

Hi Dave and all.

I remember in one of those plastic home routers I had some time ago there was an option for a telnet server and maybe even SNMP, and indeed software implementation quality could be better.

But the vendor managed to get two key points right, namely:
1. The protocol was disabled by default.
2. When on, it was available on the LAN side of the device only.

Does it make any sense?

-- 
    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 09 Apr 2016 13:42:38 -0300

Thanks again for volunteering, Barbara.

> The router in a home network that is most likely to be managed is the
> ISP-provided router.  There are 100s of millions of those around the
> world, and the ones that are managed are managed using BBF
> TR-069.  AFAIK, none are managed using netconf.

Noted.

> Therefore I recommend creating an information model that can be used to
> create any management protocol data model (e.g., YANG or TR-069).

Can you point us at somewhere that explains the difference between an
information model and a management protocol data model?

> With that said, I can definitely see cases where Babel may be used in
> managed routers that exist inside the homenet, and where the service
> provider [...] is [...] managing those routers. [...]  Therefore, I do
> think it's a good idea to define the information model.

Yes.

Babeld (the reference implementation) currently has an ad-hoc monitoring
and management interface that reflects the implementation's data
structures and is almost completely undocumented.  You can get at the
monitoring data by running babeld with the "-g 33123" flag, telnetting
to ::1 port 33123, and issuing the command "dump all".  I'm appending an
example of the output.  One important subtlety is that associations
("neighour relations") are between interfaces, identified by link-local
addresses, while routes are announced by nodes, identified by router-ids.
That's a fundamental property of the protocol, that is not likely to
change.

The reason the interface is undocumented is that I reserve the right to
change it at every minor version of the implementation (Babeld's version
numbering is major.menor.chiquita).  So I hope we can manage to make it so
that the output of the monitoring interface maps cleanly to the information
model (by tweaking one or the other or both).

Example Babeld's monitoring dump follows.  The "add" at the beginning can
be ignored, this is followed by one of "neighbour" (association), "xroute"
(locally redistributed route) and "route" (route learned from
a neighbour).  This is followed by a unique (at any given time)
identifier, and a sequence of keyword-value pairs.

    [...]
    add neighbour 835680 address fe80::218:84ff:fe24:8055 if wlan0 reach ffff rxcost 256 txcost 256 cost 256
    add neighbour 837ca8 address fe80::21b:b1ff:fe83:8d39 if wlan0 reach ffef rxcost 256 txcost 992 cost 992
    [...]
    add xroute 192.168.4.39/32-::/0 prefix 192.168.4.39/32 from ::/0 metric 0
    add xroute 2001:660:3301:9202::ac17:248a/128-::/0 prefix 2001:660:3301:9202::ac17:248a/128 from ::/0 metric 0
    [...]
    add route 192.168.4.3/32-838ae8-::/0 prefix 192.168.4.3/32 from ::/0 installed yes id b6:b5:2f:ff:fe:b8:35:c3 metric 96 refmetric 0 via fe80::b6b5:2fff:feb8:35c3 if gre-rhodium
    [...]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 09 Apr 2016 13:44:12 -0300

> JSON" of several mesh routing protocol people.

Seconded, it would be good to start a discussion between the NetJSON and
the IETF communities (I think it's called "outreach" over here).  Not only
here, also in MANET and ROLL.

-- Juliusz

---

From: Dave Taht <[email-masked]>
Date: Sat, 9 Apr 2016 09:59:54 -0700

> Hi Dave, great to hear from you! We missed you.

Thank you. Missed y'all too! I enjoyed attending much of this past
weeks' ietf via meetecho, rather than in person. Meetecho has come a
long way in the last few years, short of adding some sort of VR
support to it and having robots walking the halls, I can't imagine a
better way to interact remotely than that. Hmm... having a robot might
be cheaper than airfare and hotel....

 I do plan to make the berlin ietf, but my primary focus has been on
trying to find ways to make wifi better as more and more users are
piled onto it. We've been making some progress on that ( see:
http://blog.cerowrt.org/post/fq_codel_on_ath10k/ for some promising
results) but I don't know how that will tie into more ietf processes,
it's more IEEE 802.11wg than anything.

Certainly if this research track pans out it could feed back into
better routing metrics, but we have a long way to go as yet.

> I totally agree that we need a standard (xml or json data model) that can be used by routers to provide info about themselves (WAN/LAN statistics, etc.). My thinking is that if routers supplied thi…

Well, I would like it if existing tools and methods could be looked
at, again, and improved, if possible, before rewriting the universe.

Me, at the moment, I'd merely like some standardized means to get the
ISP provided uplink/downlink rates widely available to applications.
upnp, for example, has this capability, but there is generally no way
to fetch it from the isp. Other things, such as packet drop rates and
bandwidth usage are handled well by snmp. (I'd like to see CE events
in a post-ecn world, and latency under load, and so on)

>
> My email was really about configuration and not statistics.

I get it. Yes, this is an area where much work is needed. TR-69
however seems like an example of how not to do it, but perhaps it too
could be improved. Is there work within the ietf on it? Or is the
trend netconf/yang/etc?

Wedging linux itself into the openwrt uci configuration tool (which is
json based) has been a PITA, but is working halfway decently these
days.

>Though even wrt statistics, unsecured SNMP can be dangerous, since it has been used to launch DDoS attacks against certain providers' SNMP servers.

Is snmp (for statistics) beyond hope? My impression had been that most
of the problems were from old versions of common snmp daemons being
widely deployed, un-updated, and insecured in the field.

I agree that snmp for configuration is probably beyond hope.

---

From: Alia Atlas <[email-masked]>
Date: Sat, 9 Apr 2016 23:32:13 -0400

For some thoughts on information models,  take a look at RFC 3444(
https://tools.ietf.org/html/rfc3444).  That's what I did when I first
started thinking about them for I2RS.

I do believe that information models can be useful when there are multiple
data modeling languages necessary, as Barbara suggested.   I am a bit leery
if them otherwise,  because after one,  there's still nothing to implement.

Regards,
Alia
On Apr 9, 2016 1:42 PM, "Juliusz Chroboczek" <[email-masked]>
wrote:

>     add xroute 2001:660:3301:9202::ac17:248a/128-::/0 prefix
> 2001:660:3301:9202::ac17:248a/128 from ::/0 metric 0
>     [...]
>     add route 192.168.4.3/32-838ae8-::/0 prefix 192.168.4.3/32 from ::/0
> installed yes id b6:b5:2f:ff:fe:b8:35:c3 metric 96 refmetric 0 via
> fe80::b6b5:2fff:feb8:35c3 if gre-rhodium
>     [...]
>
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 11 Apr 2016 11:17:11 -0400

Barbara,

That sounds like an excellent way forward.  It sounds like we should put
some text in the charter for interacting with the BBF
potentially.

Alia

On Mon, Apr 11, 2016 at 10:08 AM, STARK, BARBARA H <[email-masked]> wrote:

> https://tools.ietf.org/html/rfc3444).
> > That's what I did when I first started thinking about them for I2RS.
> > I do believe that information models can be useful when there are
> multiple data modeling languages
> > necessary, as Barbara suggested.   I am a bit leery of them otherwise,
> because after one,  there's still nothing to implement.
>
> Yes, that's a good RFC for understanding info vs data model.
> For a tangible example, you can see what's been going on in lmap wg.
> https://tools.ietf.org/html/draft-ietf-lmap-information-model is the info
> model.
> https://tools.ietf.org/html/draft-ietf-lmap-yang is the YANG data model
> being created simultaneously.
> And in BBF there is a TR-069 data model that is being created
> simultaneously. Tim Carey has been revising the TR-069 data model with
> every info model update and providing very detailed feedback into lmap (to
> the info model). IMO, this has improved the info model considerably, by
> having 2 distinct implementations of the info model, instead of just one.
> Many issues have been raised that might not otherwise have been noticed.
>
> I'm quite sure a TR-069 data model would get created if IETF were to
> create the info model (and we could follow a similar simultaneous process).
> BBF could also share iterations of the TR-069 data model, if people thought
> that would be useful.
> I would leave it to others to create other data models.
>
> BTW, I think a Babel info model would be considerably simpler than the
> lmap info model. lmap has many more moving parts.
> Barbara
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 11 Apr 2016 12:42:34 -0300

> It sounds like we should put some text in the charter for interacting
> with the BBF potentially.

What about leaving the charter sufficiently open to allow interaction with
the BBF should it work out, but without spelling it out explicitly?

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 11 Apr 2016 14:08:26 +0000

> For some thoughts on information models,  take a look at RFC 3444( https://tools.ietf.org/html/rfc3444).  
> I do believe that information models can be useful when there are multiple data modeling languages 
> necessary, as Barbara suggested.   I am a bit leery of them otherwise,  because after one,  there's still nothing to implement.

Yes, that's a good RFC for understanding info vs data model.
For a tangible example, you can see what's been going on in lmap wg.
https://tools.ietf.org/html/draft-ietf-lmap-information-model is the info model.
https://tools.ietf.org/html/draft-ietf-lmap-yang is the YANG data model being created simultaneously.
And in BBF there is a TR-069 data model that is being created simultaneously. Tim Carey has been revising the TR-069 data model with every info model update and providing very detailed feedback into lmap (to the info model). IMO, this has improved the info model considerably, by having 2 distinct implementations of the info model, instead of just one. Many issues have been raised that might not otherwise have been noticed.

I'm quite sure a TR-069 data model would get created if IETF were to create the info model (and we could follow a similar simultaneous process). BBF could also share iterations of the TR-069 data model, if people thought that would be useful.
I would leave it to others to create other data models.

BTW, I think a Babel info model would be considerably simpler than the lmap info model. lmap has many more moving parts.
Barbara

---

From: Alia Atlas <[email-masked]>
Date: Mon, 11 Apr 2016 19:02:01 -0400

> the BBF should it work out, but without spelling it out explicitly?

Yes - something like working on an Information Model for Babel Management
and coordinating
with any organizations that are interested in using it as a basis for their
data model and management.

More word-smithing is needed.  It is useful to specify the management
protocols anticipated so
that everyone is on the same page.

Alia

---

From: "Russ White" <[email-masked]>
Date: Fri, 15 Apr 2016 08:49:26 -0400

> I get it. Yes, this is an area where much work is needed. TR-69 however
> seems like an example of how not to do it, but perhaps it too could be
> improved. Is there work within the ietf on it? Or is the trend
> netconf/yang/etc?

The trend is definitely yang over Netconf/restconf -- it would be good if we
could settle a direction here early on, and use the collaboration between
open source and open standards to map out a useful direction for other
projects to follow. 

> Is snmp (for statistics) beyond hope? My impression had been that most of
> the problems were from old versions of common snmp daemons being

The IETF, at large, has said "no more snmp..." I think the main point is the
difficult nature of working with around snmp, rather than security
specifically. XML based models are more flexible and useable, which means
they have more hope for widespread implementation across many different
devices. 

What we don't want to get into is, "we have this for home routers, that for
the upstream headend, and this thing over there for laptops, and that one
over there for televisions." I suspect we're going to end up there anyway
(it's the nature of the beast -- closed management interfaces are just part
of the competitive landscape any longer), but I'd like to avoid it where
possible, if possible...

:-)

Russ