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

From: Donald Eastlake <[email-masked]>
Date: Fri, 18 May 2018 00:16:48 -0400

Hi,

This is a reminder that there is an ongoing call for adopt of
draft-ovsienko-babel-rfc7298bis. This message extends the deadline for
responding through 28 May. Please indicate if you think this draft
should or should not be adopted as a starting point by the BABEL WG.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 18 May 2018 14:55:09 +0200

> should or should not be adopted as a starting point by the BABEL WG.

I have mixed feelings, and therefore do not know whether I do or don't
support adoption at the current time.

On the one hand:

  - I am convinced that Babel needs a simple, comprehensible,
    implementable auth mechanism that introduces no heavy dependencies
    (possibly in addition to any heavier mechanism, such as DTLS);
  - Denis' draft is a good starting point for obtaining the above.

On the other hand:

  - as described on the list, the protocol appears to be vulnerable to
    replay, due to an unfortunate confusion between symmetric reachability
    (as defined by 6126bis) and security association.  I have a plan for
    fixing the vulnerability (by removing the confusion), but I'd like to
    have a chance to explain my ideas in order to see if they work;
  - the document (as opposed to the protocol) is very difficult to work
    with.  Three reasons for that: (1) an almost complete lack of
    rationale and human-readable intuitions, (2) a tendency to repeat the
    same points multiple times, and (3) a tendency to repeat what is
    already in 6126bis.  This is bad for a security document, and is
    especially worrying since the author has a poor track record of
    listening to stylistic (as opposed to technical) criticisms.

Should the stylistic issues with the document be fixed, and should my
ideas for fixing the vulnerability work out, I'd support adoption with no
hesitation.  As it currently stands, and since I do not trust the author
to fix the editorial issues once the document is adopted, I'm not sure.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 18 May 2018 15:58:44 +0000

I wonder if it might be possible to adopt under certain conditions (in-line below)?
Barbara

> From: Juliusz Chroboczek
...
>   - Denis' draft is a good starting point for obtaining the above.

I agree
 
>     have a chance to explain my ideas in order to see if they work;

I've seen many adopted drafts die without ever being sent for publication. I've helped kill a few myself. Admittedly, it is easier to kill prior to adoption than prior to WGLC -- but not that much easier. Might it be possible to agree to adopt, but with the understanding that we don't have WGLC unless there are at least 2 interoperable implementations without a replay vulnerability? That is, there exists a technical issue that *must* be resolved before WGLC.

>     listening to stylistic (as opposed to technical) criticisms.

Authors of WG drafts are assigned by the chairs and do not have to be the same as authors of individual contributions those WG drafts evolve from. If Denis were willing to work with a co-author, the chairs could assign such a co-author with the specific charter of making the draft readable. I would be willing to volunteer to do this. Alternately, the chairs could be cold-hearted and cruel and completely remove Denis as an author (which I'm not advocating, unless Denis refuses to work with a co-author or wants to completely step aside from this effort). I've seen this done several times. So this is not a reason that should prevent adoption, but is input the chairs should consider.
 
> Should the stylistic issues with the document be fixed, and should my ideas
> for fixing the vulnerability work out, I'd support adoption with no hesitation.
> As it currently stands, and since I do not trust the author to fix the editorial
> issues once the document is adopted, I'm not sure.
> 
> -- Juliusz
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_babel&d=DwICAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=kuyFIAvd4lkAsr4xOmt0IOcVUWBjZuPVIcUKHf9RgX4&s
> =24w8fbY1aQnxpOhJyK1zB-lnaFAfOawqOckSQeh8zUg&e=

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 18 May 2018 23:37:19 +0200

> I wonder if it might be possible to adopt

I think we ought to adopt at some point, but not necessarily right now.

> If Denis were willing to work with a co-author, the chairs could assign
> such a co-author with the specific charter of making the draft
> readable. I would be willing to volunteer to do this.

That's a great offer.  Denis, what do you think?

> Alternately, the chairs could be cold-hearted and cruel and completely
> remove Denis as an author

That would be unacceptable for me, we really should be giving proper credit.

-- Juliusz

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 21 May 2018 13:57:41 -0400

Hi Barbara,

Thanks,
Donald

> I've seen many adopted drafts die without ever being sent for publication. I've helped kill a few myself. Admittedly, it is easier to kill prior to adoption than prior to WGLC -- but not that much…

I suppose it's possible but I don't see much point. If people want 2
interoperable implementations, which is consistent with the way this
WG has been thinking about drafts, and such implementations don't
exist, either there won't be a WGLC or it will fail.

> Authors of WG drafts are assigned by the chairs and do not have to be the same as authors of individual contributions those WG drafts evolve from. If Denis were willing to work with a co-author, th…

It is not that common for WG chairs to exercise their authority over
authorship on WG draft. Things normally work out informally. If
substantial text changes are needed to the draft, my first through is
that people should be proposing text changes or going through and
marking up the draft and sending the result to Denis. Involuntarily
removing an author of a WG draft is extreme rare and pretty much only
happens if there is a clear WG consensus for specific changes and the
author refuses to make those changes. I don't see any point in talking
about that at this point.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Denis Ovsienko <[email-masked]>
Date: Wed, 23 May 2018 00:14:31 +0100

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 24 May 2018 16:29:59 -0400

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

On Tue, May 22, 2018 at 7:14 PM, Denis Ovsienko <[email-masked]> 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
>
>
>

---

From: Denis Ovsienko <[email-masked]>
Date: Sat, 26 May 2018 20:15:24 +0100

---- On Thu, 24 May 2018 21:29:59 +0100 Donald Eastlake <[email-masked]> wrote ----   
 > 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.  
 >   
  
Hello Donald and all.  
  
Thank you for the thorough review. There is indeed space for improvements in this document, which I am willing to discuss. Before responding on particular points let me clarify upfront that the -00 I-D of 7298-bis was derived from the -09 (last before the RFC) 7298 I-D, and my goal was to identify and try to fix problems in the core design first. The supporting text around it right now remains mostly inherited, consequently what was good in an Experimental document in 2014 in several cases is not yet good enough in a Standards Track I-D in 2018. But it all looks workable to me.

For the points you have made above: 

* Yes, 7298-bis does not need to have all the prose from RFC 7298, which ended up in the document due to a number of reasons, some of which no longer apply. That said, from my experience on the implementation side of this fence it looks like extra reasoning/background in the right place helps to get things right in the field. It would be nice eventually to have a document that strikes the right balance, I suggest to look at this again after removing some text.

* Leaving some implementation options out may be an improvement. In particular, for the outgoing TS/PC numbers this is a necessity, other points may be considered, you are welcome to make particular suggestions.

* For Section 2.1 (MTI and optional crypto hash algorithms), if the appropriateness considerations can be left up to the IETF, that would make the job a bit easier.

For the points you have made inline in the I-D text:

* Most of the I-D front page was automatically generated by the xml2rfc tool, the user has only limited control over the output, sorry.

* I appreciate general English proof-reading, RFC 7298 I-Ds incorporated as much of it as I could get from the reviewers, and still the RFC Editor team made one more round before the publication (that round is not in the 7298-bis I-D yet).

* Section 2.4 (HMAC definition) had to appear in RFC 7298 to identify and stop a technical error that was introduced in RFC 4822 and kept propagating into other RFCs. Now that it had served its intended purpose, in 7298-bis it should be OK to have just a reference to RFC 2104.

* Section 4.1 (updates to protocol encoding -> justification) had to appear in RFC 7298 to review the options and explain the design choice. Subsequent publication of RFC 7557 (now incorporated into 6126-bis) indeed made this section less useful and this is one of the things to fix (reduce/move/remove) in 7298-bis.

* The notes on byte order conversion (sections 5.3 and 5.4 and elsewhere) can be reduced in 7298-bis without impacting the document's normative quality. They were in RFC 7298 purely because of my experience with software developers that kept getting byte order wrong. That said, it should be good enough for 7298-bis to say about byte order about as much as a typical Standards Track document.

* RFC 7298 had Table 1 because the Babel protocol registry did not exist at that time. I agree that at the current time a document like this should refer to the existing registry.

Thanks.

--   
    Denis Ovsienko

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 28 May 2018 17:38:18 -0400

Hi Denis

> * Yes, 7298-bis does not need to have all the prose from RFC 7298, which ended up in the document due to a number of reasons, some of which no longer apply. That said, from my experience on the imp…

OK.

> * Leaving some implementation options out may be an improvement. In particular, for the outgoing TS/PC numbers this is a necessity, other points may be considered, you are welcome to make particula…

I think the different suggestions/options for generating TS/PC at
transmission are fine because they are handled in a uniform way on
receipt.

It seems particularly problematic to have configuration variables that
can be per-interface or per-babel-speaker. This will make any OAM
scheme significantly more complex.

> * For Section 2.1 (MTI and optional crypto hash algorithms), if the appropriateness considerations can be left up to the IETF, that would make the job a bit easier.

I think they can in general. It's fine to have a sentence or two or
three about the characteristics of suitable algorithms and you
certainly need to indicate the initial mandatory or recommended to
implement algorithms. But lots of text and lists of good/bad
algorithms are not a good idea in my opinion. Such material can never
really be complete, will get out of date, etc...

> * Most of the I-D front page was automatically generated by the xml2rfc tool, the user has only limited control over the output, sorry.

OK. (I do my drafts in nroff so I am used to having, perhaps, too much
control...)

> * I appreciate general English proof-reading, RFC 7298 I-Ds incorporated as much of it as I could get from the reviewers, and still the RFC Editor team made one more round before the publication (t…

You're welcome. I actually found very few English errors and none,
that I can recall, that was likely to mislead anyone. Mostly there
just seem to be extra words and phrases thrown in, use of passive
voice, and the like. To some extent this is a matter of taste: it
gives the document more of a conversational tone but make it more
verbose and is something the RFC Editor staff is likely to want to
change anyway.

> * Section 2.4 (HMAC definition) had to appear in RFC 7298 to identify and stop a technical error that was introduced in RFC 4822 and kept propagating into other RFCs. Now that it had served its int…

OK -- But I don't see how RFC 4822 could be a problem. Except maybe
for Errata, RFCs are immutable documents, like books a shelf. Even if
RFC 4822 updated RFC 2104, which it does not, that would only affect a
document referencing RFC 4822 or referencing RFC 4822 and RFC 2014. If
you just reference RFC 2104, they you just do what is in RFC 2104 and
even later updating RFCs that you do not reference are, at least in
principle, irrelevant.

> * Section 4.1 (updates to protocol encoding -> justification) had to appear in RFC 7298 to review the options and explain the design choice. Subsequent publication of RFC 7557 (now incorporated int…

OK.

> * The notes on byte order conversion (sections 5.3 and 5.4 and elsewhere) can be reduced in 7298-bis without impacting the document's normative quality. They were in RFC 7298 purely because of my e…

OK. As I say, mentioning this just a couple of times and having a
worked example that developers can check against should be enough.

> * RFC 7298 had Table 1 because the Babel protocol registry did not exist at that time. I agree that at the current time a document like this should refer to the existing registry.

Ah, OK, guess I wasn't quite aware of the timing with respect to the registry.

Thanks,
Donald

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 30 May 2018 00:38:41 +0200

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

Yes.

---

From: Denis Ovsienko <[email-masked]>
Date: Wed, 30 May 2018 22:01:06 +0100

---- On Fri, 18 May 2018 05:16:48 +0100 Donald Eastlake <[email-masked]> wrote ---- 
 > should or should not be adopted as a starting point by the BABEL WG. 

Greetings.

It is 30 May and I would like to get a decision.

-- 
    Denis Ovsienko