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

From: Denis Ovsienko <[email-masked]>
Date: Fri, 03 Nov 2017 09:35:33 +0000

---- On Tue, 31 Oct 2017 19:02:15 +0000 Juliusz Chroboczek wrote ---- 
>> 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. 

Hello all.

I confirm the text says that and I understand what it means and it was an OK statement for RFC 6126 but for 6126-bis we had the security requirement upfront. 
 
The base specification has a bit to do with that requirement because the "security is not my problem" mindset tends to result in issues like DDoS amplification -- difficult or impossible to fix afterwards if was not considered early. 
 
In this case, for instance, if a random network device starts to repeat continuously the packets it has seen before, such failure should not mangle the routing topology, that would be a clear failure to fail. The correct behaviour would be to fail the affected neighbour(s) out and let the topology do its work. 
 
>> 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. 
 
Even in that case the document must explain it better. I had read RFC 6126 several times and still missed this point until years later, none of RFC 7298 reviewers noticed it either. Letting future readers of RFC 6126-bis have the same problem would be wrong.

>> 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". 
 
Let me point out that in this OSPF example I refer to the "DD sequence number", which is a field in the Database Description packet, and you respond discussing Hello packets. This very argument exchange itself follows the protocol exchange we are supposedly discussing: one speaker sends a message with a nonce, another speaker returns a packet with a different nonce, so the first speaker concludes there is no two-way communication with the second one. Does the irony of this situation help to make anything across?
 
Back to OSPF, you are right -- it didn't get Hello right, but it tried to get DBDesc right, and made enough steps in the right direction to be one of the good examples. 

>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. 
 
Excuse me, but to the best of my understanding my position did not change and what I have stated stands as before, even though we are 3 months behind the schedule. 
 
As a working group member I never intended to rush publications "no matter what". If a document makes it through, it must be accurate and it should be useful. 

-- 
 Denis Ovsienko

---

From: David Schinazi <[email-masked]>
Date: Fri, 03 Nov 2017 09:35:20 -0700

Hi Denis,

If we added a paragraph to the security considerations section that clearly explains
this issue and explicitly states that any extension that secures Babel should take
this into account, would that work for you?

Thanks,
David

> On Nov 3, 2017, at 02:35, Denis Ovsienko <[email-masked]> wrote:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Denis Ovsienko <[email-masked]>
Date: Mon, 06 Nov 2017 15:50:43 +0000

---- On Fri, 03 Nov 2017 16:35:20 +0000 David Schinazi<[email-masked]> wrote ---- 
 > this into account, would that work for you? 

Hello David.

Well, yes, stating the problem is a good first step in getting it solved.

-- 
    Denis Ovsienko