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

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 3 Dec 2015 16:37:34 +0000

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

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.

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.

It's possible (see comments on part 1) that other informative references might help.
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************