Subject: Re: [manet] DLEP-17 review, part 4

From: Rick Taylor <[email-masked]>
Date: Tue, 8 Mar 2016 17:56:54 +0000

Continuing my reply to Chris' comments....

On 03/12/15 16:37, Dearlove, Christopher (UK) wrote:
> I’m now going to be non-sequential. I will get back to sections 8 to 10,
> but here will consider Sections 11, 12 and references.
>
> Section 11. The main issue is that using TLS only helps with the TCP
> messages, it doesn’t help with the UDP ones. If I read correctly, an
> unauthenticated UDP message could send a modem off to the wrong address
> and port, so it ignores the correct one.
>
> The denial of service mitigation creates its own denial of service
> opportunity. If you maintain a database of peers that fail
> initialisation, then create fake traffic apparently from the real peer
> in order to get the real peer on the blacklist.
>
> There’s no discussion of confidentiality. Yes, TLS can manage that, but
> that still needs to be said. And still the UDP problem. (Does
> confidentiality matter? I can think of cases it might.)
>
> There’s no discussion of key management. Again that’s down to TLS (but
> what about UDP as usual?) but probably needs saying. Are you expecting
> to pre-share keys or negotiate? If latter do we consider MitM as an issue?
>
> That security is only considered for multi-hop still leaves
> possibilities of injection of false messages (if, say, that one hop is
> an Ethernet bus) and confidentiality. These you may think are
> acceptable, but need to say so.
>
> (In short, I’m expecting this section not to pass. I may be wrong, but
> that’s my guess.)

There has been extensive discussion over security since this review 
which we have taken on board.

>
> Section 12
>
> Biggest problem here is that this is not self-contained. That’s not the
> first time I’ve said that. I’ve had IANA unhappy with things
> significantly more picky than that Table 1 is off elsewhere. Again, I
> can only base on my experience, but I believe you need a fully
> self-contained section. References from outside into it, OK. So tables
> need moving here or duplicating. And Reserved is misused in this section
> (see previous part, and I think I’ve said this before).
>
> Because of this, I’m not going to attempt to review details in this
> section, that will have to be in another draft. You will need policies
> for adding new entries.

We have revisited the IANA text, but the tables are still out of the 
section.  It is a really quick edit to move them, so we are willing to 
wait until IANA tells us where they want them.

>
> References
>
> I think I forgot to say this in my last part, but I’m still in favour of
> making [CREDIT] non-normative and not coupling the fate/delay of this
> document to that.
>
> You will probably need RFC 5226 once the IANA section is revised.

Added.

>
> It’s possible (see comments on part 1) that other informative references
> might help.
>

Many have been added.

And on to part 5...

Rick