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

[<[e-mail]>]

Hi Benjamin,

I don't really understand the discussion here about "entropy" or "providing entropy". I can understand that from a security view point you may have a different definition or usage but in the framework of IP/MPLS, we are always using this terminology. Besides of RFC6790, RFC7348 (VXLAN) also talks about "enabling entropy" by using the source port. I think RFC7510 (MPLSoUDP) also talks about it. 
So I do not really what we could change or improve here.

Regarding your comment about the intended status. The document contains definitions that implementation should agree on. If two implementations does not use the same meaning for the ERLD, we may fall into trouble (EL inserted in a non readable position...).

" Section 4

It's a little jarring to talk of "position 1 (top)" which is (IIUC) the bottommost label in the Figure 2 depiction.  (I'm sure readers will know the intent, of course.)
"
[SLI] I like the OSI representation of protocol stacks which puts the lower layer at the bottom, it looks more natural to me. Sorry for that :) I can fix it if necessary.


I will take care about the editorial comments you made in a next revision. Thanks for pointing them.


Brgds,


-----Original Message-----
From: Benjamin Kaduk [mailto:[e-mail]] 
Sent: Tuesday, July 03, 2018 22:56
To: Stewart Bryant
Cc: The IESG; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [mpls] Benjamin Kaduk's No Record on draft-ietf-mpls-spring-entropy-label-11: (with COMMENT)

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.