Subject: [babel] WG Last Call on draft-ietf-babel-rfc6126bis-04.txt (10/29 - 11/17)

From: Donald Eastlake <[email-masked]>
Date: Sun, 29 Oct 2017 20:51:36 -0400

This message starts a WG Last Call on draft-ietf-babel-rfc6126bis-04
running until the BABEL WG meeting at the upcoming Singapore IETF
meeting.

Please post to this mailing list indicating whether you think this
draft is an appropriate revision of RFC 6126 suitable for publication
as an IETF Proposed Standard.

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: Mon, 30 Oct 2017 15:03:34 +0000

---- On Mon, 30 Oct 2017 00:51:36 +0000 Donald Eastlake  wrote ---- 
>as an IETF Proposed Standard. 

Hello all.

As far as I understand, this specification still suffers a technical problem that makes it not ready for Standards Track.

Specifically, this is the bi-directional reachability problem, which I had described a few times during 2016. One of those times was IETF 97 Babel WG meeting, which mostly consisted of the slides explaining how the attack works and why it was possible. Excuse me if the delivery style was poor, that's only as good as I could do 3 o'clock in the morning. However, all the technical points are there, there are the slides and there was a detailed follow-up on the WG mailing list afterwards. Unfortunately, the conversation turned out to be one-way so I have to bring it up now because the problem has not fixed itself since then.

It would not be relevant for the base protocol document if Babel security was out of scope (like the Security Considerations section currently puts it). However, our working group charter clearly says: "Address security needs for BABEL". And the security mechanism, whatever it is, is likely to depend on the base protocol's ability to detect true 2-way reachability. So there is still important work to be done here before declaring success.

-- 
    Denis Ovsienko

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 31 Oct 2017 00:44:00 +0100

Dear Denis,

> Specifically, this is the bi-directional reachability problem

This was discussed on the mailing list in December 2016 in a thread called
« [PATCH 2/4] address IETF-97 slides section I point 2 ».

> Unfortunately, the conversation turned out to be one-way

That's not fair, Denis.  It wasn't discussed at the meeting (since you
weren't present in the flesh), but it was discussed in detail on the
mailing list.

If I understand it correctly, the "issue" is that the draft deliberately
puts very few constraints on a neighbourship association (Section 3.4).
A node can create an association whenever it suits it, and may likewise
destroy it at any time.  This, apparently, makes RFC 7298 vulnerable to
the attack that you described at IETF-97.

There was a lengthy discussion on the mailing list in December 2016, and
the consensus that emerged was the following:

  - Section 3.4 needed to be rewritten (this has been done);
  - all three active implementers of Babel (Toke, David and myself)
    prefer the time of neighbourship creation to remain an implementation
    detail and not become normative;
  - the issue you outlined is not an issue with RFC6126(bis), it's an
    issue in RFC 7298, and should therefore be fixed in that document.

Unless something has happened in the meantime, this is still the consensus
of the Babel working group.

Regards,

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Mon, 30 Oct 2017 17:28:26 -0700

Hi Denis,

I agree with Juliusz on this topic.

I think the right solution to this security issue is an RFC 7298 bis
document that adds more constraints on neighbor acquisition,
in the context of giving the HMAC the right properties.

As it stands, the neighbor acquisition described in RFC 6126 bis
provides the properties required to make Babel work, and should
not be encumbered by extra requirements needed to make the
HMAC extension work.

I agree the working group should give guidance on securing Babel,
however that does not need to hold back this document, as we
have not reached consensus on how to achieve security.
Proposed solutions include HMAC, DTLS and IPsec; and the last
two do not require the state machine you proposed.

Thanks,
David

> On Oct 30, 2017, at 16:44, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Dear Denis,
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 31 Oct 2017 02:05:37 +0100

> document that adds more constraints on neighbor acquisition,

Alternatively, 7298bis could decouple neighbour acquisition from security
association.  There's no reason why the two lifetimes should be closely
coupled.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 31 Oct 2017 12:33:40 +0100

> two do not require the state machine you proposed.

+1

-Toke

---

From: Denis Ovsienko <[email-masked]>
Date: Tue, 31 Oct 2017 12:54:44 +0000

---- On Mon, 30 Oct 2017 23:44:00 +0000 Juliusz Chroboczek  wrote ---- 
>&laquo; [PATCH 2/4] address IETF-97 slides section I point 2 &raquo;. 
> 

Hello all.

I am sorry to say there was _no_ consensus on this specific matter in 2016 and there is still _no_ consensus on this matter now, as nothing happened in this regard since the problem was stated (looks like we concur on this little specific point in a way).

"Not fair." -- I could respond to that statement, but for the sake of getting the work done let's try to focus on the quality of deliverables -- the only thing that actually matters in this whole story.

The problem, as it was already explained before, is the bi-directional reachability -- a concept used in many other protocols. When the base Babel protocol spec uses a well-known term to mean a non-standard behaviour, it misleads the implementers. This is the property of the document and it is not a good property. Authors of derivative works may misunderstand the meaning and I myself is an example of this (and I am a valid case, I can re-introduce myself if really necessary). I was OK to admit the facts as well as to work to understand why it happened.

As much as I could tell after examining both documents, some blame belongs to RFC 7298 and some blame belongs to RFC 6126. Just stating on the mailing list that Babel does not care, that RFC 6126-bis is perfect and any blame belongs elsewhere cannot improve RFC 6126-bis as the output document of the working group. The normative reference needs to be put right carefully to avoid more mistakes downstream at a later time. Without this the specification would not be fit for Standards Track.

-- 
    Denis Ovsienko

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 31 Oct 2017 14:13:55 +0100

> The problem, as it was already explained before, is the bi-directional
> reachability -- a concept used in many other protocols. When the base
> Babel protocol spec uses a well-known term to mean a non-standard
> behaviour, it misleads the implementers.

I'm terribly sorry if I'm being obtuse here, but from this comment it
seems to me that your objection is specifically to the use of the term
'bidirectional reachability', because you read that to imply something
stronger than what Babel does?

If so, what term would you suggest to use instead? Or would it suffice
to explicitly spell out that this is a weaker property than in some
other places (which?)?

-Toke

---

From: Denis Ovsienko <[email-masked]>
Date: Tue, 31 Oct 2017 16:46:42 +0000

---- On Tue, 31 Oct 2017 13:13:55 +0000 Toke Høiland-Jørgensen<[email-masked]> wrote ---- 
 > to explicitly spell out that this is a weaker property than in some 

No problem, let me explain one more time.

The way Babel is currently specified allows a protocol instance think it has a 2-way exchange with a neighbour, whereas in reality it can be just fed with replayed old packets. That's the way the protocol is literally specified, no matter what was originally meant and what comments were made on the mailing list or in person.

The way it is commonly specified for other protocols involves a nonce or another proof of freshness. For example, completing a 3-way TCP handshake on behalf of a random remote host is impossible with just replayed packets. TCP-based protocols rely on this property; non-TCP protocols have to implement this property themselves: DD sequence numbers in OSPF, nonces in IKE, MPTCP, IPv6 mobility and even almost (but not really, because the nonce is not in the right TLV type) Babel. There are examples in many other protocol designs as this is quite an old problem.

To answer your question with the above in mind, the specification should say what it means and mean what it says. I see at least the following ways to achieve that:

1. If the Babel base spec really really needs to replace a standard wheel with a square one, it must not call it a "wheel", it should explain the design choice and its gains and it must discuss the drawbacks implied by the custom solution. This includes the burden of 2-way reachability proof on the security mechanism. I cannot suggest a good term for calling it at the moment.

2. Alternatively, the 2-way reachability should be a straightforward, no-catch, no-surprise, nonce-based reachability a typical implementor expects to see in a routing protocol.

As far as I can see, any of the above would be better than the present state. Which approach is better than the other is an open question, as well as if anybody would like to suggest other ways to fix this problem in this document.

Thanks.

-- 
    Denis Ovsienko

---

From: David Schinazi <[email-masked]>
Date: Tue, 31 Oct 2017 10:06:46 -0700

Hi Denis,

When I implemented RFC6126 from spec only
(without looking at existing implementations nor discussing with other implementors),
I was not confused by bidirectional reachability. The document clearly specifies what that
means. I wouldn't assume your definition is better than the one in RFC6126.

Are you suggesting we should only have 4 bits of metric for implementors that are used to RIP?

David

> On Oct 31, 2017, at 09:46, Denis Ovsienko <[email-masked]> wrote:
>

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 31 Oct 2017 18:25:26 +0100

Denis Ovsienko <[email-masked]> writes:

> The way Babel is currently specified allows a protocol instance think
> it has a 2-way exchange with a neighbour, whereas in reality it can be
> just fed with replayed old packets. That's the way the protocol is
> literally specified, no matter what was originally meant and what
> comments were made on the mailing list or in person.
>
> The way it is commonly specified for other protocols involves a nonce
> or another proof of freshness. For example, completing a 3-way TCP
> handshake on behalf of a random remote host is impossible with just
> replayed packets. TCP-based protocols rely on this property; non-TCP
> protocols have to implement this property themselves: DD sequence
> numbers in OSPF, nonces in IKE, MPTCP, IPv6 mobility and even almost
> (but not really, because the nonce is not in the right TLV type)
> Babel. There are examples in many other protocol designs as this is
> quite an old problem.

Yeah, this is what I meant: You're saying that "bidirectional
reachability" has a specific, well-defined and ubiquitous meaning which
implies certain security properties (such as replay protection).

However, prior to you brining it up, I have not been aware of any such
well-defined meaning of the term. For TCP, for instance, it's called the
"3-way handshake". So I would agree with you that if the term used was
"handshake", your point stands. But simply using "bidirectional
reachability" in the informal way it is used in the Babel spec does not
imply such a specific term to me. So I would ask you to point me any
definitions that include this implication of the wording currently in
the Babel spec?

-Toke

P.S., as I said, I'm fine with adding a note to, say, section 3.4.2 that
makes it clear that the protocol does *not* have this stronger property.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 31 Oct 2017 20:02:15 +0100

> The way Babel is currently specified allows a protocol instance think it
> has a 2-way exchange with a neighbour, whereas in reality it can be just
> fed with replayed old packets.

Correct.  Without any extra security protocol, Babel is vulnerable to
spoofed or replayed packets.  It is expected that it is layered over
a security protocol that protects against spoofed and replayed packets
(be it DTLS, IPsec, WPA2 or 7298bis).

I've tried to make that clear in the Security Considerations section.

> That's the way the protocol is literally specified, no matter what was
> originally meant and what comments were made on the mailing list or in
> person.

That is the way the protocol is specified, and that is the intent.

> The way it is commonly specified for other protocols involves a nonce or
> another proof of freshness.

This is simply not true, Denis.  To take an example that you quote
(incorrectly) in your previous mail, OSPF does not use a stateful
handshake (see Section A.3.2 of RFC 2328).  Yet, Section 7.1 of RFC 2328
says this:

        The Hello Protocol is responsible for establishing and
        maintaining neighbor relationships.  It also ensures that
        communication between neighbors is bidirectional.

        [...]

        After a neighbor has been discovered, bidirectional
        communication ensured...

In other words, RFC 2328 uses "bidirectional communication" to mean
exactly the same property that Babel calls "bidirectional reachability".

Denis, I'll remind you what you said at IETF-97:

        The base protocol specification defines no means
        to relate a received IHU TLV to any of the recently
        sent Hello TLVs. The authentication mechanism
        design did not account for this property at the time
        and hence did not include its own measures to
        address it.

        On the bright side is that now the time would be
        good to solve this in either the base protocol or
        the authentication mechanism or both.

I'd like to understand why your position has changed so radically since
then, and why you now believe that this must absolutely be solved in the
base protocol.

-- Juliusz