Subject: [babel] I-D Action: draft-ietf-babel-information-model-02.txt

From: [email-masked]
Date: Thu, 05 Apr 2018 16:00:20 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Babel routing protocol WG of the IETF.

        Title           : Babel Information Model
        Author          : Barbara Stark
	Filename        : draft-ietf-babel-information-model-02.txt
	Pages           : 16
	Date            : 2018-04-05

Abstract:
   This Babel Information Model can be used to create data models under
   various data modeling regimes (e.g., YANG).  It allows a Babel
   implementation (via a management protocol such as netconf) to report
   on its current state and may allow some limited configuration of
   protocol constants.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-babel-information-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-babel-information-model-02
https://datatracker.ietf.org/doc/html/draft-ietf-babel-information-model-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-information-model-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 5 Apr 2018 23:05:19 +0000

I think this information model is ready to be reviewed by Those Who Volunteered. I have quite a collection of items to think about at the end of the draft.
Barbara

> -----Original Message-----
> Subject: [babel] I-D Action: draft-ietf-babel-information-model-02.txt
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 06 Apr 2018 02:23:22 +0200

Thanks, Barbara.  I haven't checked the security bits, but the rest looks
fine to me.  A few minor nits.

   Due to the simplicity of the Babel protocol and the fact that it is
   designed to be used in non-professionally administered environments
   (such as home networks)

Please don't say that -- Babel is a general-purpose routing protocol that
is designed to survive where other protocols die.  In particular, it can
survive in the hostile Home Network environment, but I'd like to avoid
restricting it to that case.  I suggest removing the bit from "and the
fact" up to the closing paranthesis.

      babel-supported-link-types: set of values of supported link types
      where the following enumeration values MUST be supported: 1 =
      wireless, 2 = physical-layer ethernet, 99 = other

I'd prefer this to be a list of strings, with possible values "wired",
"wireless", "tunnel" and "other".

> 3.2.  Definition of babel-constants-obj

I don't see a way to find out if this Babel instance is speaking IPv6,
IPv4, or both.  (Toke suggested we dump the IPv4 support, I'm half
inclined to agree.)

> 3.3.  Definition of babel-interfaces-obj

      babel-link-type: indicates the type of link; integer values

Same as above -- I'd prefer this to be a string.

      babel-external-cost: external input to cost of link of this
      interface (need to determine how to express this);MUST be
      configurable if implemented

I suggest "if supported, this is a value that is added to the metrics of
routes learned over this interface".  There's a space missing after the
semicolon.

      babel-neighbors: a set of babel-neighbors objects

There's a "u" missing ;-)

> 3.4.  Definition of babel-neighbors-obj

      babel-hello-mcast-history: the multicast Hello history of whether
      or not each of the 16 multicast Hello messages prior to babel-
      hello-seqno was received; represented as a 16 bit (4 hex digits)
      value where 1 = Hello received and 0 = Hello not received; see
      draft-ietf-babel-rfc6126bis [rfc6126bis] section A.1

You need to specify the endiannness of this bitstring.  The reference
implementation puts the most recent bits at the big-endian end, and shifts
right.

On a related note, shouldn't this be a bit string of an
implementation-defined length?

     babel-hello-seqno: expected Hello sequence number

This needs to be split into "babel-expected-ucast-hello-seqno" and
"babel-expected-mcast-hello-seqno".

> 3.6.  Definition of babel-routes-obj

I think there's a field missing -- the interface over which this route has
been learned.  Alternatively, you could put a reference to the neighbour
from which this route has been learned.

      babel-route-next-hop: the next-hop address of this route; this
      will be empty if this route has no next-hop address

I suggest "if this is empty, the next hop is the address of the neighbour
from which the route has been learnt."

      babel-route-metric: the metric with which this route was
      advertised by the neighbor, or maximum value (infinity) to
      [...]
      babel-route-announced-metric: a calculated metric for this route;
      how the metric is calculated is implementation-specific; either

Have you inverted the two?

Please add "if this is the value 65535, then this route has been retracted
and is temporarily unreachable (see Section 3.5.5 of [RFC6126bis])".

      babel-route-feasible: a boolean flag indicating whether this route
      is known to work; a route that is not feasible will never be
      selected

A boolean flag indicating whether this route is feasible, as defined in
Section 3.5.1 of [RFC6126bis].

   5.   Do we need a registry for the supported security mechanisms?

No.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sat, 07 Apr 2018 20:47:18 +0200

"STARK, BARBARA H" <[email-masked]> writes:

> I think this information model is ready to be reviewed by Those Who
> Volunteered. I have quite a collection of items to think about at the
> end of the draft.

Generally looks good! A few comments:

> babel-ucast-hello-interval: the current unicast hello interval in
>      use for this interface

Shouldn't this be per-neighbour?

>      babel-message-log: log entries that have timestamp of a received
>      Babel message and the entire received Babel message, including
>      Ethernet frame and IP headers; an implementation must restrict the
>      size of this log, but how and what size is implementation-specific

A userspace implementation doesn't necessarily have access to the
Ethernet and IP headers.

>      babel-neighbor-ihu-interval: current IHU interval for this
>      neighbor

The IHU interval (i.e. the value put into an IHU TLV) is not necessarily
available; it is perfectly sensible to just store the expiry time.

>      babel-security-supported: list of supported security mechanisms

So every security object contains the entire list of supported security
mechanisms? Until this point I was under the impression that the logic
was one security object per mechanism...

>    1.   babel-interfaces-obj: Juliusz:"This needs further discussion, I
>        fear some of these are implementation details."  [In the absence
>        of discussion, the current model stands.  Note that all but
>        link-type and the neighbors sub-object are optional; if an
>        implementation does not have any of the optional elements then
>        it simply doesn't have them and that's fine.]

The information currently in the draft (apart from the message log), I
also added as debug output in Bird, so I think it makes sense to include
it. I also output current v4/v6 nexthop addresses used for routes
announced over each interface; may be useful to include, since the
mapping from addresses assigned to the interface is not always obvious,
so may be useful to see what a particular implementation picked?

-Toke

---

From: David Schinazi <[email-masked]>
Date: Tue, 10 Apr 2018 16:04:15 -0700

Thanks for writing this, Barbara!

I read -02, and it looks good to me, it reads well. Also I agree with Juliusz's and Toke's comments.

Two minor comments:

1) babel-hello-[mu]cast-history is an implementation detail documented in an appendix, should it be exposed?
Isn't rxcost/txcost/cost sufficient?

2) Regarding security, should it be possible to pull the private key from a router? Is that common practice?

Thanks,
David

> On Apr 7, 2018, at 11:47, Toke Høiland-Jørgensen <[email-masked]> wrote:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Markus Stenberg <[email-masked]>
Date: Wed, 11 Apr 2018 07:05:55 +0300

> 2) Regarding security, should it be possible to pull the private key from a router? Is that common practice?

No. I think what is written in the spec now is good.

In general only public keys should ever go anywhere from a device. Any scheme that involves private key distribution is quite a bit less secure.

That’s why e.g. certificate (= glorified public key) enrollment practises involve device making requests with the public key, and getting signed one back in return. Similarly, why HSMs and such are all the rage (keep your private key on a box you don’t have even access to the actual private key, just encryption and decryption functions and public key).

As a matter of fact, if one were to use HSM with routing protocol (not impossible although I guess it is mostly done nowadays with https/ipsec/ssh keys), providing private key would not be possible as only public key (and-or certificate) would even be available.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 11 Apr 2018 14:50:36 +0200

> in an appendix, should it be exposed?

It's a useful piece of data when debugging issues with wireless links --
it's easier to understand than the xxcost values.  It's optional in
Barbara's model, so implementations can ignore it if they don't use
a Hello history.

I argue for keeping it (as optional).

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Wed, 11 Apr 2018 09:19:05 -0700

> On Apr 10, 2018, at 21:05, Markus Stenberg <[email-masked]> wrote:
> 

To clarify, I entirely agree with you - I think we should NOT allow extracting the private key. But my incorrect understanding of the doc was that it allowed grabbing them. I just reread it and agree that I does not allow it, only addition and deletion.

David

---

From: David Schinazi <[email-masked]>
Date: Wed, 11 Apr 2018 09:19:38 -0700

> On Apr 11, 2018, at 05:50, Juliusz Chroboczek <[email-masked]> wrote:
> 

Fair enough. That works for me.

David