Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-dtls-07: (with DISCUSS and COMMENT)

[David Schinazi <[e-mail]>]

Thanks Ben! I've incorporated these comments in the following commit:
https://github.com/jech/babel-drafts/commit/458a9ae6b9b136122d8668b26ba403f4f3a57167

We'll submit an updated draft after this round of comments.

Detailed responses inline.

Thanks,
David



> > Our intent in this document was to leave the complex question of identity
> > to deployment profiles. For example, the homenet working group is
> interested
>
> It would be a fine thing to say explicitly that the details of identity and
> authentication are left to specific profiles.
>

Added the following paragraph to the Applicability section:
    DTLS supports several mechanisms by which nodes can identify
    themselves and prove possession of secrets tied to these identities.
    This document does not prescribe which of these mechanisms
    to use; details of identity management are left to deployment
    profiles of Babel over DTLS.


> > We already have this text in section 2.1:
> >     Nodes MUST use DTLS replay protection to prevent attackers
> >     from replaying stale information.
> > Is there something we should add to that?
>
> I did see that text in 2.1, which is why this comment was less strongly
> worded.  I am interpreting the text I quoted as a description of what
> functionality DTLS does and can provide, and in that context, DTLS provides
> optional replay protection.  If your implementation doesn't offer it, or
> you don't turn it on; you're not protected.  It seems like it would
> misconstrue things to imply that DTLS always provides replay protection,
> since that's not the case!
>

Makes sense. Changed "replay protection" to "optional replay protection".


> > > I see the text about use of multicast Hellos for discovery and the
> > > acknowledgment that an out-of-band neighbor discovery mechanism may be
> > > available.  Are there any such discovery mechanism under development?
> > >
> >
> > There aren't, at least not as standards. This text is there to
> accommodate
> > implementations/deployments that already have a non-standard out-of-band
> > discovery mechanism.
>
> "standard" is a touchy term here in the IETF :)  But I take it there are no
> published drafts or similar, either, in which case there's not anything we
> can make an informative reference to, which is what I was really getting
> at.
>

Fair enough, by "standard" I meant "being openly discussed in a
standardization organization". The only existing out-of-band discovery
mechanism that was discussed was proprietary and has nothing we
can link to.


> > > Section 2.5
> > >
> > > Do we want to talk about the potential consequences of an attacker
> > > arbitrarily delaying valid content (to justify the need for a timeout)?
> > >
> >
> > The section currently states:
> >     This attack could be used to make a node believe it has bidirectional
> >     reachability to a neighbour even though that neighbour has
> disconnected
> >     from the network.
> > What more did you have in mind?
>
> Well, I hadn't thought it through fully.  But would it be possible to delay
> distribution of metric updates, leading to the victim selecting an
> alternate path than it would have otherwise (whether to cause performance
> degredation or make the data-plan traffic go through a place that's easier
> to attack, or otherwise)?  It seems that the need for liveness detection
> would place time bounds on such an attack unless the attacker can
> selectively drop DTLS datagrams and there are Hellos not piggybacked on the
> traffic that is targeted.  I forget how much tolerance for such drastic
> reordering there would be.
>

That's fair. We've added the following text:
    Additionally, an attacker could save some packets and replay them
    later in hopes of propagating stale routing information at a later time.
    To mitigate this, nodes MUST discard received packets that have
    been reordered by more than one IHU interval.


> > > Section 3
> > >
> > >    IP, UDP and DTLS.  Nodes MUST NOT send Babel packets larger than the
> > >    attached interface's MTU adjusted for known lower-layer headers (at
> > >    least UDP and IP) or 512 octets, whichever is larger, but not
> > >    exceeding 2^16 - 1 adjusted for lower-layer headers.  Every Babel
> > >    speaker MUST be able to receive packets that are as large as any
> > >
> > > Aren't these requirements just duplicating what's in 6126bis?  We
> > > probably don't need to repeat the normative language, at least, even if
> > > there's a desire to repeat the content.
> > >
> >
> > These requirements mimic the ones in 6126bis, but with the addition of
> DTLS
> > in the list of underlying layers that add overhead. This section
> references
> > the
> > appropriate section in 6126bis so readers can compare them if need be.
>
> I carefully trimmed the sentences that actually mentioned DTLS; "adjusted
> for known lower-layer headers" is the key phrase (happens twice) that I
> thought was used unchanged.  (But I didn't do a word-by-word comparison.)
>

That sentence is the same in both documents, but "known lower-layer
headers" doesn't mean the same thing in both, since we now have
the DTLS layer. I'm not coming up with an easy way to convey this
without repeating at least some parts of the text in 6126bis.


> > I'm not sure I understand, are you saying there is a difference between
> > the terms "overhead per packet" and "per-packet overhead" ?
>
> "different amounts of overhead per packet" implies something whose
> magnitude varies on a packet-by-packet basis, potentially drastically so,
> whereas "different amounts of per-packet overhead" is more of a fixed
> (potentially range) of overhead across all packets in question.  (And yes,
> I know that CBC padding can fall into the former!)
>

Thanks for the clarification, changed to "per-packet overhead".