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

[Robert Raszuk <[e-mail]>]

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.

> 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.

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 <[e-mail]> wrote:

> On Wed, Sep 12, 2018 at 10:29:49AM +0200, Robert Raszuk wrote:
> > Hi Benjamin,
> >
> > > 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.
> >
> > Let me observe that for a lot of work in IETF term "VPN" does *not* imply
> > 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.
>
> > 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 ?
>
> 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
>
> >
> >
> > On Wed, Sep 12, 2018 at 3:49 AM, Benjamin Kaduk <[e-mail]> wrote:
> >
> > > 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.
> > >
> > >
> > > _______________________________________________
> > > BESS mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/bess
> > >
>