Re: [babel] Early review on draft-ietf-babel-dtls ...

[David Schinazi <[e-mail]>]

Hi everyone,

Juliusz pointed out that I forgot to mention a change that went into -01:
it is now forbidden to send IHU unencrypted. This has the advantage of
preventing reverse reachability from being established with an untrusted
peer, and makes the security boundary of the protocol much simpler to
reason about. One side effect is that the RTT extension now needs to use
unicast hellos inside the encryption, which should not be an issue.

Please let us know if you have comments on this change.

Thanks,
David


On Oct 08, 2018, at 12:25, David Schinazi <[e-mail]> wrote:
> Thank you for your review, Tony.
>


The authors have updated the draft to incorporate your comments:
> https://tools.ietf.org/html/draft-ietf-babel-dtls-01
>


A diff between -00 and -01 is available here:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-dtls-01
>


(note that the links above may take a few minutes to be functional)
>


Thanks,
> David


> On Sep 26, 2018, at 14:37, Antoni Przygienda <[e-mail]> wrote:
>> I have been selected to do a routing directorate “early” review of this
>> draft.
>> https://datatracker.ietf.org/doc/draft-ietf-babel-dtls
>>
>> Document: draft-ietf-babel-dtls
>> Reviewer: Tony Przygienda
>> Intended Status: STD
>> Summary:
>> Choose from this list...
>> I have some minor concerns about this document that I think should be
>> resolved before it is submitted to the IESG. Concerns are not defects but
>> basically request for some clarification in document and reconsideration on
>> minor issues
>> Comments:
>> ·         Draft makes inherent sense, of significance for future work in
>> the routing area IMO for other protocols if the security requirements for
>> routing keep on tightening
>> ·         I think that the draft will benefit from an explicit
>> justification why I solution based on SHA-1 cannot satisfy the security
>> profile desired. Reading the draft I assumed that the main requirement was
>> confidentiality which was incorrect. Discussions with the authors let to
>> quite interesting insights that should be captured in the draft IMO.
>
> ·          The section explaining that all the babel frames must be
>> unicast with DTLS could benefit from a small rewrite to read easier
>> ·         I recommend the authors to rethink where they want to change
>> base spec babel MTU by a hard offset. Even the DTLS can evolve in a
>> Backwards compatible manner changing sizes. From experience with tunnels
>> and routing protocols it may be better  to just keep the original spec and
>> imply than an implementation supporting DTLS has to deal with the according
>> size overhead
>>
>> thanks
>>
>> --- tony
>
>