Hi everyone,
Thanks again for your feedback, we've updated the document to reflect it:
https://tools.ietf.org/html/draft-ietf-babel-dtls-02
https://www.ietf.org/rfcdiff?url2=draft-ietf-babel-dtls-02
David
On Tue, Nov 13, 2018 at 1:41 PM Juliusz Chroboczek wrote:
> > - s2.5 Not sure what
> - s2.5 Not sure what the ceremonies around flushing a neighbor are,
> but I'd make explicit signalling EOD at least a SHOULD? It seems more
> polite :-)
> I agree, I upgraded politeness to a SHOULD.
Note however that a neighbour is usually discarded when we loose too many
Hellos
> Yep, all of which speaks to some serious shortcomings of the
> HMAC-based protocol.
The scope of Babel-HMAC is deliberately limited. Babel-HMAC aims to
implement the strict minimum of features that make it useful.
Any deployment that needs features beyond what Babel-HMAC provides should
use
On Tue, Nov 13, 2018 at 12:33 PM David Schinazi
wrote:
> Our threat model should be described in the introduction. From your
> comments I'm guessing it isn't clear, so we should fix that. The basic
> idea is that any on-link device can change the routing of the entire
> network, and that's bad
Hi Martin,
Thanks for looking into this.
Our threat model should be described in the introduction. From your
comments I'm guessing it isn't clear, so we should fix that. The basic
idea is that any on-link device can change the routing of the entire
network, and that's bad for hopefully obvious
Thanks for the feedback Thomas! Responses inline.
On Wed, Nov 7, 2018 at 8:30 PM Fossati, Thomas (Nokia - GB/Cambridge) <
thomas.foss...@nokia.com> wrote:
> One high level thing which I can't extrapolate from the draft (which is
> probably due to my ignorance with Babel) is whether you envisage
*Cc:* "draft-ietf-babel-d...@ietf.org" , "
> tls@ietf.org"
> *Betreff:* Re: [TLS] Are we holding TLS wrong?
> Hi David,
>
> A few quick notes below.
>
> Cheers
>
> The 11/08/2018 09:14, David Schinazi wrote:
> > Hi everyone,
> >
> > O
On Fri, Nov 9, 2018 at 11:10 PM Juliusz Chroboczek wrote:
> > Offhand, it seems like replays are possible if you allow the possibility
> > of the node crashing and dumping state.
>
> Unless I've missed something -- they are not, assuming you have
> a sufficiently strong random number generator.
> I'm somewhat dismayed by the firm recommendation to use the HMAC
> mechanism,
Yeah, this could probably be loosened somewhat.
> which doesn't seem particularly robust.
It's designed to be fairly robust. Of course, we may have done things
wrong.
> Offhand, it seems like replays are possible
Hi David,
I couldn't find any description of the threat model involved here, nor
could I find any analysis of the security against that model. Without
that, I can't really say whether this is right or not. For instance,
there is specific mention of the certificate status request extension,
but
. This would also allow you to cover the multicast security case.
Ciao
Hannes
Gesendet: Donnerstag, 08. November 2018 um 11:30 Uhr
Von: "Fossati, Thomas (Nokia - GB/Cambridge)"
An: "David Schinazi"
Cc: "draft-ietf-babel-d...@ietf.org" , "tls@ietf.org&
Hi David,
A few quick notes below.
Cheers
The 11/08/2018 09:14, David Schinazi wrote:
> Hi everyone,
>
> Over in the Babel working group we have a draft about securing Babel with
> DTLS:
> https://tools.ietf.org/html/draft-ietf-babel-dtls-01
>
> It's 5 pages long, could any TLS experts please
Hi everyone,
Over in the Babel working group we have a draft about securing Babel with
DTLS:
https://tools.ietf.org/html/draft-ietf-babel-dtls-01
It's 5 pages long, could any TLS experts please give it a quick read and
let us know if we're using DTLS correctly?
Also, should the document contain
13 matches
Mail list logo
