Re: [babel] Benjamin Kaduk's Discuss on draft-ietf-babel-rfc6126bis-12: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Sat, Aug 17, 2019 at 04:18:51AM +0200, Juliusz Chroboczek wrote:
> >>> Section 3.8.2.1 notes that "[d]ue to duplicate suppression, only a small
> >>> number of such requests will actually reach the source." (for seqno
> >>> requests intending to avoid starvation).
> 
> [...]
> 
> > It still feels like an internal inconsistency to me.  How would you feel
> > about s/will actually reach/are expected to actually reach/?
> 
> Ok, done.
> 
> >>> I think we may need to have a discussion about the feasibility of
> >>> multicast acknowledgment requests with only a 16-bit nonce.
> >> 
> >> Section 3.3.  An acknowledgment MUST be sent to a unicast destination.
> 
> > I saw that, which is why I specified "acknowledgment requests".
> 
> The nonce is used to match an Ack with the corresponding Req.  Since the
> Ack is sent over unicast, a node only needs to match the Acks to the Reqs
> it originated.  A sequential counter is good enough if we assume that
> 65536 distinct values is enough to deal with packet duplication.
> 
> In any case, even if there's a collision, the consequences are fairly
> mild: the node will wrongly believe that a packet has been acknowledged,
> which might cause the packet to fail to be resent, but Babel is designed
> to deal gracefully with packet loss.

Fair enough, I am sufficiently convinced.

> To avoid confusion, I've renamed the Nonce to Opaque.
> 
> >>> ----------------------------------------------------------------------
> >>> COMMENT:
> >>> ----------------------------------------------------------------------
> >> 
> >>> Should there be a "changes since RFC 6126" section that is retained in
> >>> the published RFC?  (I assume that Appendix F is going to be dropped.)
> >> 
> >> Is that a hard requirement?  We've updated all implementations, so it
> >> wouldn't be too useful to anyone, and it would be a fair amount of work.
> 
> > This is the non-blocking Comment section, so no, it's not a hard
> > requirement.
> 
> I've added such a section.
> 
> >>> Section 1.2
> 
> >>>    Second, unless the optional algorithm described in Section 3.5.5 is
> >>>    implemented, Babel does impose a hold time when a prefix is
> 
> >>> Similarly to my comment on the applicability doc, I'm not sure if
> >>> there's one or two things in Section 3.5.5 that would match this
> >>> description.
> 
> >> I'm not sure what's missing.  3.5.5 clearly states that either you wait
> >> for a fixed timeout, or you do something that doesn't involve waiting for
> >> a fixed timeout.
> 
> > Grammatically, an "optional algorithm" is a single thing.
> 
> I've replaced this with "the second algorithm".
> 
> >>> I'm trying to walk through this and missing a step or two.
> [...]
> 
> >> We want to prove that the following property is preserved:
> >> 
> >> P: NH(A) = B implies FD(B) < FD(A)
> [...]
> 
> > Okay.  So it sounds like I'm supposed to read "accepts an update from B"
> > and interpret that as meaning "that causes NH(A) to be B" as opposed to,
> > say, "this is valid metric data and I am recomputing my routing  table in
> > response"?  I can get behind that conclusion, but don't know if that's just
> > a term of art I missed or some clarification should be added.
> 
> I've added "and when it switches next hops".

Great; thank you!

> >>> Section 2.5
> >> 
> >>> Using the minusculeu and majuscule forms of the same letter to mean
> >>> different things (e.g., source S and sequence number s) is something of
> >>> a readability anti-pattern.
> 
> >> I agree.  We need Greek letters in RFCs.  (No Gothic, please.)
> 
> > sadly, RFC 7997 doesn't really seem to support this cause :-/
> 
> Some people have no vision.
> 
> >>> Section 3.2.6
> >> 
> >>> It would probably be helpful to readers to note that "neighbor that
> >>> advertised" and "next-hop" can be different due to being different
> >>> address families.
> >> 
> >> They are completely different data structures.  The neighbour is (a
> >> reference to) an entry of the neighbour table, the NH is an IP address.
> 
> > That's true.  Do we want to make it more clear to the reader that is going
> > through things quickly?
> 
> It was difficult to write, there's no reason why it should be easy to
> read.  Still, I've followed your advice.

Thank you.

> >>>    neighbours.  However, if a seqno request is resent by its originator,
> >>>    the subsequent copies MAY be forwarded to a different neighbour than
> >>>    the initial one.
> >> 
> >>> Is MAY the appropriate level of strength?  Trying the same neighbor
> >>> would be effective if the original was unsuccessful due to packet loss,
> >>> but is it possible for a routing pathology to occur that directs the
> >>> request in the "wrong direction" with respect to a link or node failure?
> 
> [...]
> 
> > Hmm.  I might actually suggest a non-normative "may", then,
> 
> Done.
> 
> >> If we want to be consistent with the rest of Babel, it is legal to check
> >> and to ignore this TLV.  Since this TLV is ignored in any case, the
> >> distinction is somewhat uninteresting.
> >> 
> >> (I guess you're thinking about adding noise for security purposes.  Please
> >> define a new TLV if that's required, I prefer protocol extensions to be
> >> explicit about their intent.)
> 
> > I was originally going for steganographic-like side channels, but that's an
> > option, too.  I'll wait until I can think up a use for the noise before I
> > write that draft, though ;)
> 
> Heh.  It's a link-local steganographic channel, so not very interesting.
> If you find a way to encode information in route updates in such a manner
> that it gets propagated to the rest of the network, I'll be more excited.
> 
> >>> Section 4.6.3
> >> 
> >>> Sixteen bits of nonce does not provide much unguessability (I note that
> >>> LISP's rfc6830bis is recommending that their 24-bit nonce echo
> >>> functionality not be relied on for return-routability checks over the
> >>> public Internet).  However, since these acknowledgment exchanges are
> >>> only between direct neighbors, it seems that they are only needed for
> >>> correlating responses to requests and not for unguessability.  (In this
> >>> case it seems a sequence number would work just as well as a random
> >>> number, and we might want to discourage random assignment in the text to
> >>> avoid the risk of birthday collisions.)
> >>> On the other hand, multicast acknowledgment requests could be
> >>> problematic (and especially so when sequential nonces are used), and if
> >>> they are intended to be allowed then we may need to consider using a
> >>> larger and random nonce.
> >> 
> >> Section 3.3:
> >> 
> >> An acknowledgment MUST be sent to a unicast destination.
> 
> > I understand that.  Nonetheless, any time that an attacker C (e.g., on a
> > shared link) can send a message to A that changes how A interacts with B,
> > that puts up a flag that we need to think about the interaction more
> > carefully.  In this case, *probably* B will ignore spurious acks from A,
> > but is that always true?  Is that the only case we need to consider?
> 
> Without a cryptographic protection mechanism, this protocol is completely
> insecure.  The Ack nonce is not meant to be unguessable, it's just meant
> for the requestor to match the Acks it receives to the Reqs it sent.  It's
> just a counter, except that the representation is a local implementation
> matter.
> 
> To avoid confusion, I've renamed the Nonce to Opaque.
> 
> >>> Section 5
> >> 
> >>> "Specification Required" also requires Expert Review.  What guidance can
> >>> we provide to the experts for making registration decisions?
> 
> [...]
> 
> >> I think we can deal with that issue when the problem occurs.
> 
> > It's unlikely to be a timely response if we do that; I expect an RFC would
> > be needed in order to change registry policy/guidance, and that would take
> > at least a few months.
> 
> What do you suggest?

It's hard for me as an outsider to be confident about giving good advice.
Some potential options include:

(1) leave it as-is and trust that the expert will be reasonable
(2) note that the expert can ask the WG/list for further input if they are
uncertain
(3) direct the expert that requests should only be approved if they are of
general applicability, well specified, and do not have any obvious
omissions

or potentially a combination thereof.  (3) is aligned with a fairly common
pattern that we see, though it's by no means a universal pattern.

> >>> I don't understand the origin of the '256' in the MIN(1, 256/txcost)
> >>> formula (described as a probability estimate).
> 
> >> We scale the values to fit in a 16-bit integer field without excessive
> >> loss of precision.
> 
> > Sorry; I'm still confused.  If alpha is a "probability estimate", shoudln't
> > it be between 0 and 1?  MIN(1, .) then serves to cap the top of the range,
> > so I want 256/txcost to be between 0 and 1, aka txcost to be larger than
> > 256.  I see that we send the rxcost(/txcost) values in the 16-bit integer
> > IHU field, and use 0xffff to indicate infinity, but within that 0..2^15-2
> > range, assignment of costs is left fairly arbitrary.  So a scaling factor
> > would presumably also be arbitrary, but why is this
> > partial-scale-and-partial-cap procedure useful versus just scaling over the
> > full 16-bit range into a probability estimate from 0 to 1?
> 
> The scaling above gives a wireless link a cost between 256 and infinity,
> where 256 stands for lossless.  Ethernet links use 2-out-of-3, so
> a working Ethernet gets a cost of K.  Since you want to prefer Ethernet to
> Wireless, you pick K < 256.  You couldn't do that if wireless got a cost
> of 1.

Oh!  Now it makes sense; thank you!
I think I was focused too much on the details of the algorithm and forgot
that this is ETX-specific, and thus that we want to kick any/all wireless
links up into a less-preferred range since wired links are likely to be
more reliable.
On the other hand, that also means that this is less an inherent property
of the ETX algorithms and perhaps more of an implementation parameter, so I
might consider tweaking the language slightly to reiterate that this
formula is an implementation option and not a requirement (e.g., "A node
using this ETX variant for link quality estimation [...]")

> I've added a recommendation to set K=96 for Ethernet links (this is what
> current implementations use).

Great!

I think at this point that all my Discuss points have been addressed on one
way or another, so I will go update my ballot position.

Thanks again,

Ben