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 <[email protected]> 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
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/bess
> >
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
