Re: [mpls] Benjamin Kaduk's No Record on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Mon, Jul 02, 2018 at 07:35:22PM +0100, Stewart Bryant wrote:
> 
> 
> On 02/07/2018 16:26, Benjamin Kaduk wrote:
> > My worldview is not represented in RFC 6790 at all, though, so the desire
> > to maintain consistency over time would contraindicate any big changes to
> > this document.  Perhaps in Section 1 "provide entropy" could be "make
> > entropy accessible", or similar, but I suspect I'm in the rough here and
> > the right answer is actually to do nothing.
> 
> I do not understand the world view comment.

In my (security-minded) worldview, if we talk about adding or providing
"entropy", this involves adding actual cryptographic randomness into the
system.  The prevailing worldview in RFC 6790 has it that "providing
entropy" means rearranging bits in the packet headers to make some bits
closer to the front of the packet more unpredictable, if you will forgive
the strained analogy.  For the target audience of the document, trying to
talk about the "adding cryptographic randomness" perspective is actively
confusing (I assume), so I don't propose to make changes that increase
confusion.

> Regarding the latter comment, it depends on your perspective. It 
> provides entropy
> in the MPLS layer where insufficient entropy otherwise existed. That entropy
> is otherwise accessible (see the Ethernet CW draft), but it is expensive in
> hardware terms and implementations make mistakes which give operators a 
> difficult time.
> 
> Providing entropy in the MPLS layer is how most MPLS engineers normally 
> think
> about this feature. It is not BTW specified how that entropy is derived 
> and that
> method may vary from packet to packet with the LSR not knowing how to 
> find it in the
> payload, if indeed, it is all in the payload at all.

"entropy" is a notoriously sticky concept to nail down.  Before I learned
about shannon entropy and information-theoretical entropy, I learned
thermodynamics and the statistical mechanics model for thermodynamic
entropy.  This (well, and most definitions of entropy) only make sense in
the context of a distribution function, whether a probability distribution
of the thermodynamic state or a potential distribution of bits in packet
headers.  The entropy relates to the various potential configurations and
the numbers of them that are "equivalent" in some sense; a key prerequisite
is to define which configuration variables are being considered.

Taking that to the immediate context, one could ask whether the "entropy"
in question is in the context of the entire packet contents, all packet
headers, just MPLS headers, just the first MSD MPLS headers, just the first
ERLD MPLS headers, etc.  I have implicitly been assuming that we are
talking about all packet headers, in which case the TCP/UDP ports are
already in scope, so hashing those bits and appending the hash output does
not add any unpredictability ("new configurations", in statistical
mechanics speak).

> I therefore think "provide" is the correct term.

If, on the other hand, we're in the first-MSD or first-ERLD mindset, then
yes, the EL is "providing" entropy, since it's making available state
information that was not previously described in the list of possible
configurations.


I hope all the readers will forgive the rather tangential digression.
Thanks for reading this far,

-Benjamin