Subject: [homenet] comments on babel-profile-03

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Nov 2017 06:15:55 +0000

Hiya,

I re-read babel-profile-03 and have a few comments (below)
offered as a WG participant (i.e. chair hat off) as part of
WGLC.

If any of these were discussed already, then just pointing
me at the archive is a fine answer. (And apologies for not
having been active in the WG earlier if there are such cases.)

- Req5: Is "MUST be... of a similar magnitude..." clear enough?

- 2.2: I'm not sure this entire section is useful. If there is
something specific we'd like to avoid (at a MUST NOT or NOT
RECOMMENDED level), it'd be better to say exactly what.

- NR2: I don't see the point of that. If

- section 3: "...using the existing redistribution mechanisms"
could maybe do with a reference for seme well known OS.

- NR3: I don't see what is not required here, that seems like a
straightforward 2119 MAY statement

- section 4: "only susceptible" seems like overstatment.  If
babel picks up routes from the OS and then annouces those,
then it seems the statement is not true, as any way of getting a
route into the OS will cause babel to propogate that, or am I
wrong? If not, then the babel profile seems to be susceptible to
any problems that cause a dodgy route to be installed in the OS
kernel.

- section 4: "secured at a lower layer" includes links with no
security (in reality), is that right?

- section 4: "trusted X" is not a good term unless you say
who/what is trusting whom/what for what. So, s/trusted
links/links/ would be better.

- section 4: The security properties here seem to be directly
and wholly dependent on nodes being able to safely identify
interfaces into the categories in 5.1 of 7788. I need to do
some more reading to convince myself that that's a good thing
to assume. If there are weaknesses in that assumption, then
it'd be better to call those out here, as that'd help folks
who're implementing and might also help in the later process
for this draft. (IOW, I won't be the only one to ask, so we
might as well be up-front if there are weak points in that
argument;-)

- section 4: I dislike the plan of assuming lower layer security
but if that's the WG consensus, then that's what it is. Is
there a link to the discussion that concluded that in the WG
archive? I suspect we'll be asked by directorate reviewers/IESG
so good to have that now. If there's no such link, then we
probably should start a specific thread that ends with that
conclusion (or changes the draft.)

Cheers,
S.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 19 Nov 2017 17:05:43 +0100

> offered as a WG participant (i.e. chair hat off) as part of

Thanks, this is appreciated.

> - Req5: Is "MUST be... of a similar magnitude..." clear enough?

Yes.  Minor tweaks to metrics don't cause suboptimal routing -- if one
router vendor chooses 64 as the cose of a wired link, and another uses 96,
then one hop is still preferred to two hops, which is what matters at the
end.

On the other hand, if one router vendor picks a cost of 1 and another one
chooses 256, then bad routing will occur.  Here, the costs are not of
similar magnitude.

The reason we don't want to be too precise here is that we want to
encourage vendors to experiment with smarter out-of-the-box metrics.  For
example, a vendor that cares about powerline ethernet should be allowed to
do something smart to prefer Ethernet to powerline.

> RECOMMENDED level), it'd be better to say exactly what.

"Non-recommendations" are just MAYs.  Perhaps the term is badly chosen, if
you have a better suggestion, I'm listening.

What this section says is basically "if you want to be smart, that's cool,
but if you're in a rush, don't bother, it's not expected to be
particularly useful in a home network".  Let me know if you have
suggestions to make it clearer.

> - NR2: I don't see the point of that. If

See above.  The point here is the rationale -- we're explaining why the
smarter metric computation algorithms are not going to matter in a home
network.

> could maybe do with a reference for seme well known OS.

I think redistribution is a standard term -- it's used by Quagga and by
Cisco, at least.

> straightforward 2119 MAY statement

Yes.  See above.

> babel picks up routes from the OS and then annouces those,

[...]

> security (in reality), is that right?

[...]

> links/links/ would be better.

[...]

> to assume.

[...]

> If there are weaknesses in that assumption, then it'd be better to call
> those out here,

[...]

> - section 4: I dislike the plan of assuming lower layer security

[...]

You're right on all counts, as usual.  However, this document is called
"Homenet Babel Profile", it's not called "Security Considerations for the
Homenet Protocol Suite".

I think the right thing to do would be to replace all of Section 4 with
a single sentence that says

  "This document describes the profile of Babel that is implement in
  Homenet implementations and the interaction between HNCP and Babel.  It
  does not in any way change the security properties of those two protocols."

and let somebody competent write another document, called "Security
Considerations for the Homenet Protocol Suite".  Is that a plan?

-- Juliusz

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 19 Nov 2017 23:52:28 +0000

Hiya,

On 19/11/17 16:05, Juliusz Chroboczek wrote:
>> I re-read babel-profile-03 and have a few comments (below) offered
>> as a WG participant (i.e. chair hat off) as part of WGLC.
> 
> Yes.  Minor tweaks to metrics don't cause suboptimal routing -- if
> one router vendor chooses 64 as the cose of a wired link, and another
> uses 96, then one hop is still preferred to two hops, which is what
> matters at the end.
> 
> On the other hand, if one router vendor picks a cost of 1 and another
> one chooses 256, then bad routing will occur.  Here, the costs are
> not of similar magnitude.
> 
> encourage vendors to experiment with smarter out-of-the-box metrics.
> For example, a vendor that cares about powerline ethernet should be
> allowed to do something smart to prefer Ethernet to powerline.

I've no problem with some vagueness in this case, but combining that
with a MUST may cause various folks to argue that a MUST needs to be
clear enough that one can determine if some code complies or not and
that the current text doesn't do that. Others may argue that this is
a bogus use of 2119's MUST as it doesn't affect interop. Regardless
of the above, my own approach would be to avoid the argument by not
using a MUST if it's not really needed for interop or security.

> "Non-recommendations" are just MAYs.  Perhaps the term is badly
> chosen, if you have a better suggestion, I'm listening.

I'd suggest just dropping the 2.x and 3.x headings. (And maybe
change NR1 to OPTION1 or something.) While the meaning of 2.1
and 3.1 is clear, 2.2 and 3.2 are, I think, confusing. But if
nobody else finds that confusing, then better to ignore me.

> 
> What this section says is basically "if you want to be smart, that's
> cool, but if you're in a rush, don't bother, it's not expected to be 
> See above.  The point here is the rationale -- we're explaining why
> the smarter metric computation algorithms are not going to matter in
> a home network.
> 
> I think redistribution is a standard term -- it's used by Quagga and
> by Cisco, at least.

Sorry, I didn't mean a reference defining the term but rather a
reference to a non-HNCP way in which routes get installed in some
relevant OS.

That'd also help a bit with the security stuff below I think,
(but we might not agree about that), as it means that the set of
risks related to routes to be considered here is not limited to
those risks that can be realised via HNCP, but needs to ack the
other ways in which routes can be installed into an OS.

>> - section 4: "only susceptible" seems like overstatment.  If babel
>> picks up routes from the OS and then annouces those,
> 
> [...]
> 
>> - section 4: "trusted X" is not a good term unless you say who/what
>> is trusting whom/what for what. So, s/trusted links/links/ would be
>> better.
> 
> [...]
> 
>> - section 4: The security properties here seem to be directly and
>> wholly dependent on nodes being able to safely identify interfaces
>> into the categories in 5.1 of 7788. I need to do some more reading
>> to convince myself that that's a good thing to assume.
> 
> [...]
> 
>> If there are weaknesses in that assumption, then it'd be better to
>> call those out here,
> 
> [...]
> 
> You're right on all counts, as usual.  However, this document is
> called "Homenet Babel Profile", it's not called "Security
> Considerations for the Homenet Protocol Suite".

Nonetheless there are security considerations arising and IETF
processes (whatever one thinks of them), do call for those to be
documented.

> 
> I think the right thing to do would be to replace all of Section 4
> with a single sentence that says

I don't agree. (I bet you guessed:-)

While I am not arguing that this document needs to document a way
of running babel in a homenet in some more highly secure manner,
you do need to call out the risks I think, and I don't think that
that's currently been done quite right yet.

In this case I think the current text is nearly ok. I'd say there
are a few wording things as mentioned above that could be better,
and two substantive additions to make: 1) to recognise that any
bogusly installed route (via HNCP or not) is a risk and 2) that
security here depends on the HNCP interface type identification
being done correctly, which we know has risks/imperfections.

(I'd be happy to chat about detailed words for the above if
that's useful - could be done offline bringing text back to the
list.)

> Homenet implementations and the interaction between HNCP and Babel.
> It does not in any way change the security properties of those two
> protocols."
> 

It might be a good plan to do that in addition, I'm not sure. Whether
or not such a document is a good plan or not will depend on a few
things (capable editors with time, the WG reaching consensus and on
that consensus being feasible and effective etc.)

Cheers,
S.

PS: Since we've gotten into commenting on this and will hopefully
chat more, I think it'll be best if Barbara calls consensus on the
results from this thread, be that doing something or nothing.

> 
> -- Juliusz
> 
> _______________________________________________ homenet mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>