You might be on to something, but I'm unsure... are you suggesting that it's
any less private over SRv6 than it was over MPLS ?
neither srv6, srmpls, mpls, gre, ... provide privacy. they all
transport the payload in nekkid cleartext.
Dance like no one's watching. Encrypt like everyone is.
Nick, does CRH-16/32 and uSID change the overhead concern? I could be wrong, but I thought that's what SRm6 was for, was to shrink the overhead, perhaps amongst other things. 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.
Thanks Tom, man, I have read so much the last week or so regarding sr/spring... so if you mean that I borrowed someone else's description of the anatomy of an SRv6 SID.... then, yes, I may have and didn't know it. Hey, was it you? LOL
- Aaron
I'm not shy... this would be Cisco.
And somehow, they've managed to "convince" other vendors to go down this
rabbit hole, because it is seemingly clear that network operators
(especially mobile providers) may actually buy this cockamamie.
Mark.
As we've said many times before, MPLS is not a bad tunneling service.
And while things can always be better, it's a bit hard to find anything
else, today, that is reasonably well baked-in and efficient (as it can be).
Mark.
On a piece of paper filed under "It feels good to know it sort of does
the same thing" :-).
Mark.
Don't you just love Project Manager from vendor and Project Manager from
operator occupying a board room for all 365 days of the year, pointing
fingers at each other :-).
All the while, they are still mailing you their monthly Managed Services
invoice...
Mark.
This gets complicated quickly, and that complication can only be
solved by adding complication to silicon, which is what you want not
to do when the speed of your underlying forwarding plane is increasing
by leaps and bounds. Good, cheap, fast. Choose two - or maybe one.
More complex silicon means tons of R&D, which means big prices to
recover that from operators who "want want want" that R&D in their networks.
As Mark points out, many companies have made their fortunes with a
full stack product offering, from hardware and software to design,
engineering and operations. It's not a bad business model as long as
you realise that it's time-limited to the technology of the day. When
it draws to a close, it's hard to turn companies around that have been
used to a single-product or single-vertical cash trough which no
longer exists. Some have done this successfully; others have floundered.
The one thing you have to give Cisco is they know how to market... in
slides. That boring RFC document looks colorful, bright and full of
promi$e when Cisco have turned into a marketing slide.
It takes a lot of find the "boring" slides of some other vendors more
appealing, as a solution.
Mark.
C'mon, Randy. Don't tell the kids Santa isn't real. Where's your
humanity :-)...
Mark.
Very unlikely. You may do well to peruse some of the objections to the
network-programming draft in the SPRING WG. There are many. 
Define "privacy". In the kind of VPN I think you're suggesting (e.g.
an IPSEC based VPN) they implement the classic CIA acronym
(Confidentiality, Integrity and Authentication, with the "C"
essentially meaning "encrypted" in practice however, privacy requires
all three of "CIA", encryption alone isn't privacy). "VPN" is not
mutually dependent on "CIA", the two things can and do exist
separately.
WIth MPLS L3 VPNs for example, the traffic isn't encrypted, but by
creating a layer of abstraction (at the control plane, by signalling
via MP-BGP using RDs and RTs, and at the forwarding plane by using
MPLS tunneling) a customer's routing data and forwarding data is kept
private (not encrypted!) from my physical infa forwarding- and
control-planes, and from each other L3 VPN customer on my infra [1].
In fact, the point that customer (control- and forwarding-plane) data
is kept private from MY INFRA, is *the* fundamental aspect of MPLS L3
VPNs; they wouldn't scale at all without it. Privacy != encryption.
Cheers,
James.
[1] This doesn't mean there aren't security flaws in MPLS (there are,
but there are in things like IPSEC too), and "how secure" it is, is a
separate subject.
Privacy != encryption.
cleartext == privacy * 0
cleartext * complexity == privacy * 0
randy
It depends on the definition of VPN. In terms of services like
MPLS-based VPNs, it refers to the extension of a Private network
over a shared infrastructure, allowing entities using the shared
infrastructure to have their own private address space and routing
tables.
It depends on the definition of VPN.
in my definition, the P stands for privacy not plaintext
In terms of services like MPLS-based VPNs, it refers to the extension
of a Private network over a shared infrastructure, allowing entities
using the shared infrastructure to have their own private address
space and routing tables.
i think we wrote the paper on that
http://www.ieee-infocom.org/2003/papers/36_02.PDF
randy
My backyard is private. It offers no privacy with its chain link fence against a major street.
Mark,
Sorry guys, I'm not aware of much of what you mention as far as agenda, vendor motive, and hardware support, etc....
I'm not shy... this would be Cisco.
And that’s fine. The fact that some Intellectual Property[1] was created
by one vendor or another (disclaimer - I work for Cisco) shouldn’t be
by default something that discredits the idea. And BTW, if You look into
the history of how SR started, it was close feedback loop with at least
some of the ISPs wanting to have “easier” and SDN-ish control over the
network so the blame should be shared Having support from other
vendors was de facto requirement to even think about deploying it widely
and that's better approach IMHO than “lets patent everything out and
force everyone into our black-box-architecture that’s best in the world”.
I’m observing the discussions over the last couple of months and
generally they boil down to “leave us alone, everything sucks, we’ll
stay with what we have”. And sure, as you indisputably proven during last
30 years, running modern ISP network can be done over IP, MPLS, and the
network can even survive introduction of IPv6. And I get it - vendors
have generally failed to address your ideas and problems in timely manner,
and when we did, quality was simply not there. But really, is that all
what’s interesting in life? I doubt it. Unless the whole point of
discussing here would be to start from technical topics
(because of ‘rules’) and end up with everybodys favorite part - beating
virtual Pinata made to look like representation of most hated
salesman/vendor. Then sorry, I somehow missed that
While I personally find the idea of stacking IPv6 labels gruesome for
any non-trivial label depth[2] (and I'm really worried about software guys
coming in from the “mobile app” world soon, and finding out that they can
create those IPv6 EH stacks easily), going forward we have to think
about what will keep networks running in for the next 5, 10 or 20 years.
IPv4 with MPLS+LDP+RSVP-TE will work fine of course, so will SRoMPLS,
but IPv6 is gaining adoption and need to multiplex/demultiplex more and
more services and users will only grow. And BTW, MPLS forwarding between
ASes in the internet is still something that works mainly on slides,
highly paid consulting “proposals” and of course on the CCIE exam.
On the other side, there’s Elon Musk moving us to Mars, wretched IoT
world with “build, sell and forget" mentality w/r to firmware and good
network stacks. And yet only 59% people around the world today have internet
access. At least good portion of that heavily filtered one by the way.
IPv6 seems to be good plan forward (and would potentially unify
architecture of normal routing and overlay routing with SRv6), even
if things like MPLSoUDP or GRE would really solve everything if pushed
with enough force[3] 
It’s worth observing, that from this perspective
IPinIP would be as good as SRv6 if everyone would agree 20 years ago that
source routing is acceptable. LDP or RSVP-TE would never gain any usage
and maybe we wouldn’t learn lesson or two. BTW, we tried to somehow get
back to this simplification with LISP[4], and in the long run it seems
overloading address semantics is not something that is happily accepted
everywhere, and it doesn’t matter if that's IPv4 or IPv6.
So much hated middleboxes will also adopt faster to IPv6, as adopting MPLS
data plane after those 20 years on firewalls, load balancers and what-you
looks kind of dissapointingly. And if we are talking about network
functions - I believe it’s more important right now to agree on one way
of doing service chaining, than discussing SR or SRv6 as evil seed created
to conquer the world.
SR takes out state out, and SRv6 has the same address format on the
outside as well as inside. You can happily run it with both data planes,
and while today maybe you can’t provide migration of ALL services,
SR+IGP quite nicely interworks with MPLS+LDP.
Will HW evolve? It has to anyway, no previous change was done day one
and 128 bits times 5 or 8 or 12 seems horrible only today. Over the
years, people got used to bigger horrors
Really, it was just a way to leverage IP networks to make more money. Nothing against that, as long as “buyer be aware” applies. Mark.
And that’s fine. The fact that some Intellectual Property[1] was created
by one vendor or another (disclaimer - I work for Cisco) shouldn’t be
by default something that discredits the idea. And BTW, if You look into
the history of how SR started, it was close feedback loop with at least
some of the ISPs wanting to have “easier” and SDN-ish control over the
network so the blame should be shared
vendors was de facto requirement to even think about deploying it widely
and that's better approach IMHO than “lets patent everything out and
force everyone into our black-box-architecture that’s best in the world”.I’m observing the discussions over the last couple of months and
generally they boil down to “leave us alone, everything sucks, we’ll
stay with what we have”. And sure, as you indisputably proven during last
30 years, running modern ISP network can be done over IP, MPLS, and the
network can even survive introduction of IPv6. And I get it - vendors
have generally failed to address your ideas and problems in timely manner,
and when we did, quality was simply not there. But really, is that all
what’s interesting in life? I doubt it. Unless the whole point of
discussing here would be to start from technical topics
(because of ‘rules’) and end up with everybodys favorite part - beating
virtual Pinata made to look like representation of most hated
salesman/vendor. Then sorry, I somehow missed thatWhile I personally find the idea of stacking IPv6 labels gruesome for
any non-trivial label depth[2] (and I'm really worried about software guys
coming in from the “mobile app” world soon, and finding out that they can
create those IPv6 EH stacks easily), going forward we have to think
about what will keep networks running in for the next 5, 10 or 20 years.
IPv4 with MPLS+LDP+RSVP-TE will work fine of course, so will SRoMPLS,
but IPv6 is gaining adoption and need to multiplex/demultiplex more and
more services and users will only grow. And BTW, MPLS forwarding between
ASes in the internet is still something that works mainly on slides,
highly paid consulting “proposals” and of course on the CCIE exam.
I have no problem at all with dreaming up nice fancy features that either move the industry forward or just eliminate a great deal of personal idleness.
My problem is now using that tech. to force a business model that is no longer relevant in these times we live in. And somehow, making that tech. complicated enough to justify those business models.
I'm sure the genius engineers that thought up the idea aren't likely the suits who decide to monetize said idea in an unreasonable manner. I'm even more sure that if you had both sitting in the same room, they'd never converge on a "go to market" strategy.
So no, nothing against technology. Totally against it being commercially weaponized.
On the other side, there’s Elon Musk moving us to Mars, wretched IoT
world with “build, sell and forget" mentality w/r to firmware and good
network stacks. And yet only 59% people around the world today have internet
access. At least good portion of that heavily filtered one by the way.
That Tesla Powerwall does look awfully sexy. But no way I'm dishing out all that dosh for a measly 13kWh of storage just so it can shutdown after 48hrs of no Internet. For that price, there are many places that I can get 35kWh from, and not have to be concerned about being spied on for years just so the Powerwall can make it to the "Guaranteed for 8 years" finish line.
As you can tell, I always find the dark lining in the vendor sales pitches :-).
IPv6 seems to be good plan forward (and would potentially unify
architecture of normal routing and overlay routing with SRv6), even
if things like MPLSoUDP or GRE would really solve everything if pushed
with enough force[3]
IPinIP would be as good as SRv6 if everyone would agree 20 years ago that
source routing is acceptable. LDP or RSVP-TE would never gain any usage
and maybe we wouldn’t learn lesson or two. BTW, we tried to somehow get
back to this simplification with LISP[4], and in the long run it seems
overloading address semantics is not something that is happily accepted
everywhere, and it doesn’t matter if that's IPv4 or IPv6.So much hated middleboxes will also adopt faster to IPv6, as adopting MPLS
data plane after those 20 years on firewalls, load balancers and what-you
looks kind of dissapointingly. And if we are talking about network
functions - I believe it’s more important right now to agree on one way
of doing service chaining, than discussing SR or SRv6 as evil seed created
to conquer the world.SR takes out state out, and SRv6 has the same address format on the
outside as well as inside. You can happily run it with both data planes,
and while today maybe you can’t provide migration of ALL services,
SR+IGP quite nicely interworks with MPLS+LDP.Will HW evolve? It has to anyway, no previous change was done day one
and 128 bits times 5 or 8 or 12 seems horrible only today. Over the
years, people got used to bigger horrors
We all agree that if there is something better than MPLS, let's find it. It's just that new solutions ought to make things (look) simpler, not (look) more complex.
Mark.
It depends on the definition of VPN. In terms of services like
MPLS-based VPNs, it refers to the extension of a Private network
over a shared infrastructure, allowing entities using the shared
infrastructure to have their own private address space and routing
tables.Really, it was just a way to leverage IP networks to make more money.
For operators already offering FR/ATM services, it was a replacement, using the same principles of traffic separation over a common infrastructure, without encryption as part of the service. So from that perspective only, it was not much of a change for *existing* enterprise customers.
This community is aware of the responsibility of a network is to ensure that traffic is forwarded to the (originally?) intended destination to prevent confidential information being exposed to a third-party. It is in this respect that the term “privacy” is often used. So seems like there is a taxonomy issue here. Perhaps traffic separation is a better term than privacy, because while traffic is probablistically private with respect to other VPN customers (separated with some high level of probability), it is not private with respect to the operator (who could intercept it).
Nothing against that, as long as "buyer be aware" applies.
Sure, transparency is good.
I remember 20 years ago at a London IETF where the issue arose, and a food fight arose over who would own and manage encryption keys if traffic was encrypted. I don’t recall what the resolution of that debate was.
That said, we live in an era where there is increasing sensitivity to protecting consumer (at least) information. This sensitivity exists at multiple layers of the “stack”. So it is an interesting question / issue, and certainly would not be of any surprise if governments mandated it in the future, as long as they could intercept it for law enforcement purposes of course, and until they could, they probably would not be encouraging operators to encrypt data in any difficult to crack way (a speculation on my part).
Perhaps all the more reason why end-to-end encryption should be part of the buyer beware conversation (not arguing against operator encryption in saying that - privacy is something everyone in I[C]T has to think about today).
For operators already offering FR/ATM services, it was a replacement, using the same principles of traffic separation over a common infrastructure, without encryption as part of the service. So from that perspective only, it was not much of a change for *existing* enterprise customers.
Indeed. But the difference with Frame Relay and ATM was that telco's never called it a (V)PN. At worst, it was a leased line.
This community is aware of the responsibility of a network is to ensure that traffic is forwarded to the (originally?) intended destination to prevent confidential information being exposed to a third-party. It is in this respect that the term “privacy” is often used. So seems like there is a taxonomy issue here. Perhaps traffic separation is a better term than privacy, because while traffic is probablistically private with respect to other VPN customers (separated with some high level of probability), it is not private with respect to the operator (who could intercept it).
Or someone else who might "capture" the operator, and thus, be able to intercept it.
Sure, transparency is good.
I remember 20 years ago at a London IETF where the issue arose, and a food fight arose over who would own and manage encryption keys if traffic was encrypted. I don’t recall what the resolution of that debate was.
That said, we live in an era where there is increasing sensitivity to protecting consumer (at least) information. This sensitivity exists at multiple layers of the “stack”. So it is an interesting question / issue, and certainly would not be of any surprise if governments mandated it in the future, as long as they could intercept it for law enforcement purposes of course, and until they could, they probably would not be encouraging operators to encrypt data in any difficult to crack way (a speculation on my part).
Perhaps all the more reason why end-to-end encryption should be part of the buyer beware conversation (not arguing against operator encryption in saying that - privacy is something everyone in I[C]T has to think about today).
If gubbermints mandate that l2vpn's and l3vpn's be encrypted, the cloud bags will simply take over (not that they haven't, already).
Mark.
For operators already offering FR/ATM services, it was a replacement, using the same principles of traffic separation over a common infrastructure, without encryption as part of the service. So from that perspective only, it was not much of a change for existing enterprise customers.
Indeed. But the difference with Frame Relay and ATM was that telco’s never called it a (V)PN. At worst, it was a leased line.
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.”
https://en.wikipedia.org/wiki/Private_line
https://www.business.att.com/products/dedicated-internet/#/
http://etler.com/docs/AT&T%20Pub/TR54077.pdf
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©T is going to be facing a wave of voter concern about privacy, IMO.
Or someone else who might “capture” the operator, and thus, be able to intercept it.
Good point.
If gubbermints mandate that l2vpn’s and l3vpn’s be encrypted, the cloud bags will simply take over (not that they haven’t, already).
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.