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

[Denis Ovsienko <[e-mail]>]

---- On Tue, 31 Oct 2017 17:25:26 +0000 Toke Høiland-Jørgensen<[e-mail]> wrote ---- 
 > Denis Ovsienko <[e-mail]> writes: 
 >  
 > >  > 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?)?  
 > > 
 > > 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. 
 >  
 > 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? 

3.4.  Neighbour Acquisition

   Neighbour acquisition is the process by which a Babel node discovers
   the set of neighbours heard over each of its interfaces and
   ascertains bidirectional reachability.  On unreliable media,
   neighbour acquisition additionally provides some statistics that may
   be useful for link quality computation.


The text says "ascertains bidirectional reachability" and in the network protocols language this is a statement with a meaning. Then Section 3.4.2 further elaborates on how this is done and it takes to stare at the TLV diagrams for quite a while to realize the actual behaviour is different.

If the protocol does not deliver this property either the text or the protocol need to be fixed. What actually is in the box must be what is says on the box.

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

Yes, exactly.

-- 

    Denis Ovsienko