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

[Stephen Farrell <[e-mail]>]

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.
> 
> 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.

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.

> 
>> - 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.
> 
> "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 
> 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.
> 
>> - section 3: "...using the existing redistribution mechanisms" 
>> 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.

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.

> 
>> - NR3: I don't see what is not required here, that seems like a 
>> straightforward 2119 MAY statement
> 
> Yes.  See above.
> 
>> - section 4: "only susceptible" seems like overstatment.  If babel
>> picks up routes from the OS and then annouces those,
> 
> [...]
> 
>> - 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,
> 
> [...]
> 
>> - 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".

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.)

> 
> "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?

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 
> [e-mail] https://www.ietf.org/mailman/listinfo/homenet
>