Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)
Hi Benjamin, Thank you very much for your thorough review and comments. My replies are inline. > 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. 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 > and mvpnMrouteNextHopSourceAddrs plural with the final 's'?) 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 > would aid readability. 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 2018-09-12 10:49 GMT+09:00 Benjamin Kaduk : > 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)
Dear Glenn, Thank for your advice on the the Security Considerations section. I am going to revise that section along with your advice. -- tsuno 2018-09-15 11:07 GMT+09:00 Glenn Mansfield Keeni : > 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 > > > On 2018/09/12 10:49, Benjamin Kaduk 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 >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > > ___ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)
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 On 2018/09/12 10:49, Benjamin Kaduk 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-mvpn-mib-11: (with COMMENT)
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 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
> > BESS@ietf.org
> > https://www.ietf.org/mailman/listinfo/bess
> >
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailm
[bess] I-D Action: draft-ietf-bess-vpls-multihoming-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS WG of the IETF. Title : BGP based Multi-homing in Virtual Private LAN Service Authors : Bhupesh Kothari Kireeti Kompella Wim Henderickx Florin Balus James Uttaro Filename: draft-ietf-bess-vpls-multihoming-02.txt Pages : 20 Date: 2018-09-13 Abstract: Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-vpls-multihoming/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-vpls-multihoming-02 https://datatracker.ietf.org/doc/html/draft-ietf-bess-vpls-multihoming-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-vpls-multihoming-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
