Private line was a common term for leased lines. Leased lines were not encrypted by the operator, AFAIK. This terminology morphed to virtual private line, Ethernet Private Line, virtual private LAN service (VPLS), etc.
"In telecommunication, a private line is typically a telephone company service that uses a dedicated, usually unswitched point-to-point circuit, but it may involve private switchingarrangements, or predefined transmission physical or virtual paths.”
Private line - Wikipedia
https://www.business.att.com/products/dedicated-internet/#/
http://etler.com/docs/AT&T%20Pub/TR54077.pdf
https://business.comcast.com/enterprise/products-services/data-networking/ethernet-virtual-private-line
VPN is a terminology consistent with past practices. It is P in all the ways discussed on this thread, and historically consistent (at least from a marketing perspective). Whether it is P enough is a reasonable discussion, everyone in I(C)T is going to be facing a wave of voter concern about privacy, IMO.
It's six and half-a-dozen.
"Private Line" isn't the same thing as "Private Network". A small, but crucial distinction, particularly for folk on a list like this. Probably interchangeable to the ordinary wi-fi user. But then again, operators always choose words carefully, and if the contract said "Private Line" in lieu of "Private Network", or vice versa, that wasn't by mistake.
Torn between two lovers: Growing voter concern about privacy & longheld, and arguably increasing, desire to intercept criminal / terrorist communication. I’d actually be curious if any operators have received public sector pushback when they tried to implement encryption.
Sounds like you're making a/the case for MACSec :-).
Anyone know how widely MACSec has been adopted? Or for that matter, large-scale encryption on the backbone side?
For me, MACSec is kind of like SyncE... great on paper and in the sales pitch, but anyone that truly wants to use those features is probably going to be architecting, deploying and managing them themselves, and not paying a 3rd party network operator for the priviledge.
As always, I could be wrong...
Mark.
For me, MACSec is kind of like SyncE... great on paper and in the sales
pitch, but anyone that truly wants to use those features is probably
going to be architecting, deploying and managing them themselves, and
not paying a 3rd party network operator for the priviledge.
I've got MACSec deployed for exactly one customer as a point solution. It works once it's in, but the documentation, vendor or otherwise, and choice of suitable equipment were fairly sparse. I certainly wouldn't want to offer it at scale.
Encrypted network conversations with customers, I always try to be very clear about what they're trying to protect against, and make them think properly about trust boundaries. Sure, I can slap a managed CPE on site if I don't already have one and provide overlay encryption - but that doesn't stop a rogue engineer on my side from capturing data before it's encrypted. If what you're concerned about is fibre taps, or security flaws in the MPLS traffic-segregation model or implementation, that helps. If you don't want to trust me as a service provider not to sniff your traffic in the middle, having me encrypt it at the edge really doesn't help - you need to encrypt it yourself, or have a different third-party that you do trust do the encryption.
Some people get it, some people are just trying to fill auditor check-boxes 
Regards,
Tim.
Agreed.
There was a time when the use-case for MACSec was to move banks away from running their own DWDM/FC networks, and letting operators do it.
I'm yet to find a bank willing to do this.
Maybe I'm not paying enough attention.
Mark.
False. Cleartext and privacy are two different things which are not mutually exclusive. Information can be in plaintext and private, it can also be encrypted and not private.
Consider multiple devices connected to a single customer instance (A) on an MPLS L2 VPN provider's network, consisting of a single VLAN/broadcast domain, all the connected devices are able to send information to each other, and they can receive the information sent to other devices not intended for itself. Any device, for example, can send a gratuitous ARP, update the control plane of the switch and pull traffic towards itself and have visibility of all the conversation on the VLAN/broadcast domain. Even if the conversations are encrypted, meaning no plaintext, which you seem to suggest means privacy, this receiving device sees all the conversations which take place, when they are taking place, between whom, for how long, how often, and so on. Encryption hasn't provided privacy if someone can see all that information.
Now consider a second customer (B) connected to a separate customer instance on the same L2 VPN provider network. Customer A can send any traffic they like and they can listen all day until the cows come home; they will never be able to send traffic to a customer B device in a separate L2 VPN instance, and they will never receive any traffic from a customer B device, they can't even see that customer B exists, if they are having any conversations, when, for how long etc, nothing.
That is privacy, which is completely different to plaintext and ciphertext.
Cheers,
James
Well, the other use case is access networks with 802.1x. With 802.1x as
long as the port stays up the session cookie (whatever is set as
authenticated) is the MAC address. So once a port is authenticated, it's
really easy to spoof a MAC and still be on the network.
With WPA2 enterprise on WiFi, this problem does not exist, because then
there is a cryptographic session. MACsec fixes that gap on wired.
Not all that relevant for long-distance links though 
-- Wilco
aaron1@gvtc.com писал 2020-09-15 20:31:
Hi Aaron,
Also, with VPN's over SRv6
would this enable automatic vpn capability over the internet? I mean
if I can do VPN's over an IPv6 network, seems that I could do that
across the Internet as well.
I think you already can do it over any kind of tunnel, and there are a lot of SDWAN solutions are available. Or do you expect from a transit provider a capability to respect and process SID stack programmed by another provider? I wouldn't bet on this From administrative PoV it's similar to Inter-AS or CsC, based on trusted relations between parties, but seems not very popular in real life.
Otherwise, it will be the same best path routing as for any general tunnel. Doesn't look as a distinctive advantage of SRv6 at least.
Information can be in plaintext and private
Three can keep a secret, if two of them are dead. -- franklin
i know you truely believe the tunnel k00laid. the security
community does not.
randy
Sounds like you're making a/the case for MACSec :-).
While I get your point, and it is a good one, no. Once lawyers, finance, and other functions get involved, it goes from being just another technology, to a pain for suppliers and customers alike. Export laws complicate implementation, and vendors can only afford and/or have the operational agility, to do an implementation once. Any security tech that is sufficiently interesting, is going to be a pain for router vendors to implement and operationalize given the government’s attitude to such tech. The lower in the stack it is, the bigger the pain.
That said, vendors are being asked to put MACSec in and I suspect more platforms supporting it will become available over time.
Totally share your view.
End-points already have plenty of methods to provide security, as do tons of "appliances" one can deploy as CPE.
We don't need to complicate the backbone further by having it do wholesale encryption. But alas, watch this space...
The best thing we can do, as operators, is not make this a reality. If gubbermints want us to, then they are welcome to fund the project.
Mark.
Are there any actual countries heading that way? Seems like most of them insist
they have the ability to snoop unencrypted traffic (where "crypto that has a baked-in
back door" counts as unencrypted).
Let's not give them a reason.
The most I've heard (from Africa) is countries making requirements for nominated information to not be stored outside of the country, especially in the U.S, and parts of Europe. To some extent, this has pushed many of the cloud bags to become present in Africa so they can comply, although I'm not sure even sleeping with one eye open counts as being safe in that respect.
Mark.
At this point, I'm beginning to think that you're trolling us with the
assertion(s) that the 'P' in "Virtual Private Network" has obviously
meant "Privacy" all along, and/or that - as of 2020 - the only suitable
definition of "Private", must now equal "suitably secure".
If you aren't just winding everyone up, then I would say that you're
skirting rather close to the reimagining of SD-WAN. That, or you are
haphazardly musing in a direction that ensures "Encrypted SRv6" will
become the next gigantic pain^Wdraft for the SPRING WG to endur^Wdebate.
One thing that is true: not all present or historical definitions (or
acceptable uses) of the word "private" strictly imply or infer privacy.
One may prefer an alternate history, but you may find more success in
expelling that energy in pursuit of creating a better future.
See/also:
"broadband"
"software defined networks"
"the cloud"
colloquialism
/kəˈləʊkwɪəlɪz(ə)m/
noun: a word or phrase that is not formal or literary and is used in
ordinary or familiar conversation.
Hi Randy,
I'm not sure what you're saying here, I never said MPLS VPNs are secure, only private. I hope others recognise that they are different concepts.
Cheers,
James.
Call me old, but I miss the days when this thread was still on the SRv6 rails. Can we get back the proper bashing to match this thread title?
-Shep
james,
I'm not sure what you're saying here, I never said MPLS VPNs are
secure, only private. I hope others recognise that they are
different concepts.
yes, privacy is one aspect of security. and, as mpls vns are not
private sans encryption, they are not secure.
randy
That is blatantly untrue. I have an MPLS VPN running from my Living
Room to my Bathroom. It is not encrypted. It is protected with 3G
security (Guards, Guns, Gates). You do not need "encryption" in order
to be "secure".
Probably not off-topic, since vendors may push SRv6 as a(n) (MPLS) VPN replacement and new money-maker for operators, all being done in IPv6 and what-not...
Mark.