Re: [babel] Extension of Call for WG adoption of draft-ovsienko-babel-rfc7298bis through 2018-05-28

[Donald Eastlake <[e-mail]>]

Hi,

Commenting at a slightly higher level, although it is obviously up to the
WG whether or not to adopt this draft, the replay discussion seem good and
is typical of discussions that happen on security draft that have been
adopted. So, I would say that the current questions would not, by most WGs,
be considered a bar to acceptance.

I have attempted to review the draft. It seems clear that a lot of work
went into but it is very wordy and also has a lot of justification and
design background material that usually does not appear in an IETF protocol
specification. The "bits-on-the-wire" and any necessary state /
state-machine at the end points are usually the focus for an IETF protocol
specification.
     The draft seems to provide a lot of implementation options. For
example, quantities that can either be implemented as per-interface or
implemented per-babel-speaker -- I would have said that if there is clear
need for it sometimes being per-interface, then just specify it as always
being per-interface. It's an operator interface issue, which is mostly not
in scope for a typical protocol specification, whether or not to provide a
command to set it for all interfaces or set a default or whatever.
     On cryptographic algorithms, I think it should just say what you
MUST/SHOULD implement and very briefly give the necessary characteristics
for the crypto algorithms. Lots of detail about algorithms considered bad
by the crypto community and listing possibly good algorithms that could be
used does not seem necessary. Assuming this is adopted as an IETF Proposed
Standard, or whatever, any future changes will be by a document that will
go through the IETF process including security review and it should just be
assumed that bad algorithms won't be approved in the future. There is no
need to try to give commands about future IETF actions ("MUST NOT consider
hash algorithms ... meaningful attacks exist or that are commonly viewed as
deprecated") since they are unnecessary and unenforceable.
     I have a number of other detailed suggestions that I am sending
directly to Denis.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]

On Tue, May 22, 2018 at 7:14 PM, Denis Ovsienko <[e-mail]> wrote:

> Hello all.
>
> Thank you for making your reasons, let me provide a digest of the main
> technical points of the proposed work item.
>
> HMAC result(s) prove a packet was not modified in transit and was send by
> a speaker that has the shared secret. This will require adding the packet
> destination address into the HMAC input in 7298-bis as discussed.
>
> RFC 7298 specifies a simple optional way to guarantee that the
> per-interface outgoing TS/PC number is strictly increasing over the
> lifetime of a speaker. 7298-bis will need to mandate this property. This
> way any speaker can tell if any other speaker's sequence of packets runs
> strictly uphill and never repeats itself.
>
> In addition to the above, the IHU-specific TS/PC sub-TLV and the sent
> TS/PC numbers table in 7298-bis make it possible to tell if an IHU proves
> (because the local TS/PC number also runs strictly uphill and never
> repeats) freshness (not just uphill but roughly at the same elevation) that
> does not exceed the configured threshold. This threshold is specified in
> real time seconds but does not require the clocks to be synchronous.
>
> The latest technical problem Juliusz had pointed out was that the main
> protocol instance could change its state in response to replayed/delayed
> [authentic, non-duplicate, in-order] packets with Update(s) but without
> IHU, and then a fresh IHU could activate those old routes regardless if the
> speaker currently intends to advertise respective prefixes. I suggested to
> let only Hello and IHU TLVs through before the first freshness proof occurs.
>
> Having thought about it for some time, it seems to me this attack could
> also work _after_ the freshness has been proved for the first time, it just
> requires a long enough time span and many enough topology changes to
> prepare the Update(s) to be sent before the next IHU. At the moment it
> seems to me to make the most sense to maintain an age timer in 7298-bis for
> every proof of freshness (i.e. to add a column to ANM table and to use it
> to tell what TLVs can reach the main protocol instance).
>
> Although the proposed concept has slightly moved ahead of the I-D, my
> understanding is the job is doable and the document is an OK work item.
> That said, the working group makes the decision, I just need to know what
> specifically it is to be able to plan my further contributions.
>
> Thanks.
>
> --
>     Denis Ovsienko
>
>
>