Re: [babel] Éric Vyncke's Discuss on draft-ietf-babel-applicability-07: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

About my DISCUSS, the explanatory text is good but it is 'just an explanation' and not a proven property of Babel. If you remove the 'robust wrt bugs' from the list below the assertation of protocol robustness then I will be satisfied and will remove the DISCUSS. Simply add the text below the enumeration bullets and starts with "Experience gained in implementation interoperation testing shows that ....".

For the text about security, what about something like:
"     Babel-HMAC [HMAC] is a simple and easy to implement mechanism that
       only guarantees authenticity, integrity, and anti-replay of the routing traffic,
       and only supports symmetric keying with a small number of keys
       (typically just one or two).  Babel-DTLS [DTLS] is a more complex
       mechanism, that requires some minor changes to be made to a typical
       Babel implementation and depends on a DTLS stack being available, but
       inherits all of the features of DTLS, notably authenticity, integrity,  confidentiality, and the
       ability to use asymmetric keys.
"   (unsure about anti-replay of DTLS though)


-éric



On 05/08/2019, 14:51, "Juliusz Chroboczek" <[e-mail]> wrote:

    Dear Eric,
    
    Thanks for your review.
    
    > == DISCUSS ==
    
    > -- Section 2.2 --
    
    > The 'bug resistance' property of Babel was perhaps learned during the
    > implementation, but, I wonder whether the document may simply state 'robust
    > with respect to bugs', this is quite a strong statement that needs to be backed
    > by facts or proof.
    
    Would you be satisfied if I added the following paragraph?  Or would you
    prefer some other resolution?
    
      For example, an early version of the reference implementation would very
      occasionally corrupt the contents of its receive buffer.  With high
      probability, the bug would corrupt the destination address of an IPv6
      host route, which would cause a spurious "martian" route to be announced
      to the network and then silently time out, with no ill effects.
    
    (For the sake of old times, I'll recall that I was the guilty party, and
    that the bug was fixed by Grégoire Henry and Julien Cristau who spent
    almost a whole night observing a Babel node.  They weren't pleased.)
    
    > The title of the document is about 'applicability'; but, should it also
    > include 'use cases' in the title ?
    
    I prefer shorter titles, but I don't feel strongly either way.  Perhaps
    the list can chime in?
    
    > Section 3.1
    
    > The 2nd paragraph is too dense: should explain why Babel is a good fit.
    
    Agreed, I'll reword.
    
    > -- Section 5 --
    
    > Comparison between HMAC & DTLS variants is probably irrelevant in this
    > document. Though, a use case with security in mind would be benefitial.
    
    There are no known use cases.  Our users run Babel over secure link
    layers, and nobody has requested security mechanisms embedded within the
    protocol.  The security mechanisms were designed solely in order to
    satisfy IETF requirements.  (To be fair, it was a lot of fun.)
    
    > Also, the comparison should include all aspects including confidentiality and
    > anti-reply for both HMAC & DTLS.
    
    The document currently says:
    
       Babel-HMAC [HMAC] is a simple and easy to implement mechanism that
       only guarantees authenticity and integrity of the routing traffic,
       and only supports symmetric keying with a small number of keys
       (typically just one or two), but is invulnerable to replay even in
       the absence of persistent state.  Babel-DTLS [DTLS] is a more complex
       mechanism, that requires some minor changes to be made to a typical
       Babel implementation and depends on a DTLS stack being available, but
       inherits all of the features of DTLS, notably confidentiality and the
       ability to use asymmetric keys.
    
    Please let me know if you feel that this paragraph needs to be expanded or
    otherwise reworded, and, if so, in what way.
    
    Thanks again,
    
    -- Juliusz