Subject: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 11 Sep 2018 18:49:47 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-bess-mvpn-mib-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-mib/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A general comment that we've been making on lots of documents in this
space is that it would be nice to be in a place where the acronym "VPN"
implies transport encryption.  It's unclear that it's appropriate to request
changes to this specific document toward that end, though.

Perhaps I'm confused, but "mvpnAdvtPeerAddr" appears in the security
considerations in the list of address-related objects that may have
privacy/security impact.  That list is predicated on being "objects with a
MAX-ACCESS other than not-accessible", but all the instances of
mvpnAdvtPeerAddr I found in the body text were marked as not-accessible.
Similarly for mvpnMrouteCmcastGroupAddr, mvpnMrouteCmcastSourceAddrs,
mvpnMrouteNextHopGroupAddr, mvpnMrouteNextHopSourceAddrs, and
mvpnMrouteNextHopAddr.  (Incidentally, why ar mvpnMrouteCmcastSourceAddrs
and mvpnMrouteNextHopSourceAddrs plural with the final 's'?)

Perhaps using subsections to separate the various tables' descriptions
would aid readability.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 12 Sep 2018 10:29:49 +0200

Hi Benjamin,

> implies transport encryption.

Let me observe that for a lot of work in IETF term "VPN" does *not* imply
any form of either transport or payload encryption.

In fact here the MVPN which is derivative of L3VPNs do not imply use of any
encryption at all.

The term "VPN" here is really all about IP reachability separation.

So with this in mind can you please clarify your above comment ?

Kind regards,
Robert.

On Wed, Sep 12, 2018 at 3:49 AM, Benjamin Kaduk <[email-masked]> wrote:

> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 14 Sep 2018 19:50:54 -0500

> any form of either transport or payload encryption.

I am aware that this is the current state, yes.  That's why I used the
phrasing I did, namely, "it would be nice to be in a place", with the
implication that we currently aren't.

> So with this in mind can you please clarify your above comment ?

Sure!  In recent years, the IETF as a whole seems to have shifted toward
placing a greater emphasis on the privacy protection of user data from "the
network" (not the network operators, necessarily, but an attacker that has
coopted or compromised core nodes).  This is, in some sense, the core point
of RFC 7258.  With this renewed interest in "private" and "privacy"
referring to obscuring user data from intermediates (i.e., encryption), 
using the same word "private" to refer to a different concept ("not
shared", as the IP reachability separation embodies) can lead to confusion.
This is particularly pronounced in the case of the acronym "VPN", when
(encrypting) corporate VPNs are nigh-ubiquitous, and end users have
(encrypting) VPNs to pierce firewalls that get in their way, avoid
geographic-based content restrictions, and the like.

While the network engineers and RFC authors know there are different
contexts for the term in current usage, the popular media really does not,
and there are many consumers of RFCs that are not intimately involved in
their development.  So as a matter for the "good of the Internet", my
position is that reducing this potential for confusion is desirable.
>From my view as Security AD, it would be quite a shame if we ended up in an
Internet world where some corporate purchaser buys a product labelled "VPN"
thinking it will protect (encrypt) his company's data, when in fact it only
provides IP reachability separtaion.

I don't have an alternative term I want to push for the "not shared" case
(though just "Virtual Network" and its parallels to network virtualization
does come to mind); even a passing mention that this instance of VPN does
not provide data confidentiality would be a big improvemnet, in my mind.
But this is a very broad topic, and it needs to be eased into gradually, so
I'm starting by just mentioning the potential issue when it comes up, with
no expectation of changing the *current* document -- this is more of a
long-term goal.

-Benjamin

---

From: Glenn Mansfield Keeni <[email-masked]>
Date: Sat, 15 Sep 2018 11:07:53 +0900

Dear Tsuno,
      I agree with Benjamin Kaduk's comment on the Security
Considerations section. I understand the following sentence copied
verbatim from The Security Guidelines for IETF MIB modules
  >>     Some of the readable objects in this MIB module (i.e., objects
  >>     with a MAX-ACCESS other than not-accessible) may be considered
  >>     sensitive or vulnerable in some network environments.
is causing the confusion. The scope of the readable objects restricted
to "objects with a MAX-ACCESS other than not-accessible" is inadequate
here.

Please change the "i.e" to "e.g.". That will clear the confusion and
make the statement accurate.

Glenn

---

From: Hiroshi Tsunoda <[email-masked]>
Date: Sat, 15 Sep 2018 11:20:05 +0900

Dear Glenn,

Thank for your advice on the the Security Considerations section.
I am going to revise that section along with your advice.

-- tsuno

---

From: Hiroshi Tsunoda <[email-masked]>
Date: Sat, 15 Sep 2018 11:38:30 +0900

Hi Benjamin,

Thank you very much for your thorough review and comments.
My replies are inline.

> mvpnMrouteNextHopAddr.

I have received the advice from the MIB doctor on this matter and
I am going to update the draft along with the advice.

> (Incidentally, why ar mvpnMrouteCmcastSourceAddrs

For example, the DESCRPIPTION of mvpnMrouteCmcastSourceAddrs
says as follows.

         "The network address which, along with the
          corresponding mvpnMrouteCmcastSourcePrefixLength object,
          identifies the sources for which this entry contains
          multicast routing information."

Thus, this object identifies the (multiple) multicast sources, not a
single source.
Consequently, I prefer that the names of these objects are in plural form.

> Perhaps using subsections to separate the various tables' descriptions

Please let me confirm one thing.
I assume that you are talking about "Sec 3.1. Summary of MIB Module."
Do you mean that the description of each table should be in each
different subsection?
Or, do you mean that there should be one subsection including a set of
tables' descriptions?

Thanks in advance,

-- tsuno

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 15 Sep 2018 12:21:45 +0200

Hi Benjamin,

Yes now I see your point and all I can do is to agree with it.

As you know the story with right terminology is evolved to be even more
"funny". The real true and encrypted VPNs in the Internet are called SD-WAN
these days without any indication that there is privacy assurance while VPN
term is merely separating default IP reachability between parties if we
look at say L3VPNs. Sure there are also point to point IPSec VPNs which do
either encrypt or assure not compromised payload delivery.

So I guess indeed terminology is pretty confusing - and in fact it is
confusing even to technical people who are just not that ultimately
familiar with RFC4364 protocol and vendor's implementation details. Also
let's note that RFC4364 is often used outside of Internet and perhaps there
in those enterprise private networks encryption is not that much of a
necessity.

> provides IP reachability separtaion.

Well I think the market is here to help us ...

Today I see use of L3VPNs from SPs as rather fading away. SD-WAN have clear
advantages from both technical and economical points of view that I am not
sure if struggle to either rename or add mandatory or even optional
encryption to RFC4364 is really worth the effort.

A bit side observation is that the example described above leads me to
believe that the main fundamental problem is that today IETF does not (at
least to the best of my knowledge) coordinate names for new protocols or
protocol extensions in any way. Anyone can invent his own name and once the
document passes WG validating its technical merits I have not heard of many
cases where IESG or IETF wide review would change the name itself of the
proposal. And maybe in some cases it should ....

Kind regards,
Robert.

On Sat, Sep 15, 2018 at 2:51 AM Benjamin Kaduk <[email-masked]> wrote:

> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 15 Sep 2018 21:15:57 -0500

> I am going to update the draft along with the advice.

Excellent, I am sure the MIB doctor's advice is better than mine in this
matter.

> Consequently, I prefer that the names of these objects are in plural form.

Ah, thank you for the explanation.

> Or, do you mean that there should be one subsection including a set of

I was thinking about each table having its own subsection.
In particular, when I was reading, it was easy for me to miss the comments
like "-- Table of PMSI information", especially when the comment was on a
different page from the actual MIB contents.  Having a section number might
make those boundaries more clear.

Thanks,

Benjamin

---

From: Hiroshi Tsunoda <[email-masked]>
Date: Mon, 17 Sep 2018 10:58:59 +0900

Hi Benjamin,

> make those boundaries more clear.

Thank you for your clarification.
I have carefully considered your suggestion, but it looks a bit redundant
for me when each table has its own subsection.
Consequently, I have decided to keep the original style.
I would appreciate your understanding of my decision.

Thanks,

-- tsuno

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 16 Sep 2018 22:05:28 -0500

> I would appreciate your understanding of my decision.

It is entirely your decision and I can see how my suggestion would not
necessarily be the best choice.

Thanks for letting me know,

Benjamin