Subject: VPN security vs SD-WAN security

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Jul 2018 11:40:49 +0200

/* Adjusting the subject ... */

​Hello ​
Stewart,

​You have made the below comment in the other thread we are having: ​

Indeed, I would have expected this to be on a secure network of some sort
> either purely
> private or some form of VPN. However, I am sure I read in your text that
> you were
> considering using the Public Internet much in the way of SD-WAN.

​Would you mind as extensively as you can expand on the above statement ?

Specifically on what basis do you treat say L2VPN or L3VPN of naked
unencrypted packets often traveling on the very same links as this "bad"
Internet traffic to be even slightly more secure then IPSEC or DTLS
encrypted SD-WAN carried data with endpoints being terminated in private
systems ?

Thx,
Robert

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Jul 2018 10:55:03 +0100

On 25/07/2018 10:40, Robert Raszuk wrote:
>     Indeed, I would have expected this to be on a secure network of
>     some sort either purely
>     private or some form of VPN. However, I am sure I read in your
>     text that you were
> unencrypted packets often traveling on the very same links as this 
> "bad" Internet traffic to be even slightly more secure then IPSEC or 
> DTLS encrypted SD-WAN carried data with endpoints being terminated in 
> private systems ?
>
> Thx,
> Robert

Robert, I think that you have to take it as read that an air traffic 
control SoF system is encrypting its packets. If it is not, then it is 
clearly not fit for purpose.

What concerns me is that an air traffic system is one of the most, if 
not the most, high profile targets in civil society. You get reminded of 
this each time you travel to IETF.

The thing about safety of flight traffic is that a sustained and 
effective DDoS attack has global impact in a way that few other such 
attacks have.

A VPN system ought to sustain resistance to such an attack better than 
the proposed system which treats the SoF traffic the same as regular 
traffic.

- Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Jul 2018 12:32:29 +0200

Hi,

In purely technical terms what makes a VPN system less likely to suffer
from DDoS then wisely used Internet system as transport ?

Note that key here is *wisely used* meaning that you are relaying on
dynamic selection of your IP transport among N number of alternative paths
(in many cases could be only 1 AS hop away from your other peer).

Experience actually indicates that number of carries are offering "emulated
L2 VPN circuits" today over their IP Internet backbones and effects of this
in terms or resistance from attacks are purely imaginary at best.

Cheers,
R.

On Wed, Jul 25, 2018 at 11:55 AM, Stewart Bryant <[email-masked]>
wrote:

> What concerns me is that an air traffic system is one of the most, if not
> the most, high profile targets in civil society. You get reminded of this
> each time you travel to IETF.
>
> The thing about safety of flight traffic is that a sustained and effective
> DDoS attack has global impact in a way that few other such attacks have.
>
> A VPN system ought to sustain resistance to such an attack better than the
> proposed system which treats the SoF traffic the same as regular traffic.
>
> - Stewart
>
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 25 Jul 2018 11:21:26 +0000

From: rtgwg <[email-masked]> on behalf of Stewart Bryant <[email-masked]>
Date: Wednesday, July 25, 2018 at 5:55 AM
To: Robert Raszuk <[email-masked]>
Cc: Routing WG <[email-masked]>
Subject: Re: VPN security vs SD-WAN security

​Hello ​
Stewart,

Indeed, I would have expected this to be on a secure network of some sort either purely
private or some form of VPN. However, I am sure I read in your text that you were
considering using the Public Internet much in the way of SD-WAN.

Specifically on what basis do you treat say L2VPN or L3VPN of naked unencrypted packets often traveling on the very same links as this "bad" Internet traffic to be even slightly more secure then IPSEC or DTLS encrypted SD-WAN carried data with endpoints being terminated in private systems ?

Thx,
Robert

Robert, I think that you have to take it as read that an air traffic control SoF system is encrypting its packets. If it is not, then it is clearly not fit for purpose.

What concerns me is that an air traffic system is one of the most, if not the most, high profile targets in civil society. You get reminded of this each time you travel to IETF.

The thing about safety of flight traffic is that a sustained and effective DDoS attack has global impact in a way that few other such attacks have.

A VPN system ought to sustain resistance to such an attack better than the proposed system which treats the SoF traffic the same as regular traffic.

I guess you are making a case for your network slicing work 😉

Acee

- Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Jul 2018 14:24:24 +0200

True network slicing for IP networks means either waist of resources or
very strict multi-level queuing at each hop and 100% ingress traffic
policing. Yet while this has a chance to work during normal operation at
the time of even regular failures this all pretty much melts like cheese on
a good sandwich.

It is going to be very interesting to compare how single complex sliced
network compares for any end to end robust transport from N normal simple
IP backbones and end to end SLA based millisecond switch over between one
and another on a per flow basis. Also let's note then while the former is
still to the best of my knowledge a draft the latter is already deployed
globally in 100s of networks.

Best,
R.

On Wed, Jul 25, 2018 at 1:21 PM, Acee Lindem (acee) <[email-masked]> wrote:

>
>
>
>
> *From: *rtgwg <[email-masked]> on behalf of Stewart Bryant <
> [email-masked]>
> *Date: *Wednesday, July 25, 2018 at 5:55 AM
> *To: *Robert Raszuk <[email-masked]>
> *Cc: *Routing WG <[email-masked]>
> *Subject: *Re: VPN security vs SD-WAN security
>
>
>
>
>
>
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Jul 2018 13:32:25 +0100

Robert,

Perhaps the right thing here is for you to propose text to Fred on how to make sure his traffic is safe from the types of state-sponsored attack that an air traffic system might need to withstand?

Stewart

> On 25 Jul 2018, at 13:24, Robert Raszuk <[email-masked]> wrote:
> 
> 
> True network slicing for IP networks means either waist of resources or very strict multi-level queuing at each hop and 100% ingress traffic policing. Yet while this has a chance to work during normal operation at the time of even regular failures this all pretty much melts like cheese on a good sandwich. 
> 
> It is going to be very interesting to compare how single complex sliced network compares for any end to end robust transport from N normal simple IP backbones and end to end SLA based millisecond switch over between one and another on a per flow basis. Also let's note then while the former is still to the best of my knowledge a draft the latter is already deployed globally in 100s of networks. 
> 
> Best,
> R.
> 
>

---

From: <[email-masked]>
Date: Wed, 25 Jul 2018 12:51:02 +0000

Stewart,

let’s keep the discussion technical please. I’m not sure which man made technology is able to withstand state-sponsored attacks.

Regards,

Ruediger

Von: rtgwg [mailto:[email-masked]] Im Auftrag von Stewart Bryant
Gesendet: Mittwoch, 25. Juli 2018 14:32
An: Robert Raszuk <[email-masked]>
Cc: [email-masked]
Betreff: Re: VPN security vs SD-WAN security

Robert,

Stewart

On 25 Jul 2018, at 13:24, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Best,
R.

On Wed, Jul 25, 2018 at 1:21 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

From: rtgwg <[email-masked]<mailto:[email-masked]>> on behalf of Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 25, 2018 at 5:55 AM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: Routing WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: VPN security vs SD-WAN security

​Hello ​
Stewart,

Thx,
Robert

Acee

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 25 Jul 2018 14:01:49 +0100

On 25/07/2018 13:24, Robert Raszuk wrote:
>
> True network slicing for IP networks means either waist of resources 
> or very strict multi-level queuing at each hop and 100% ingress 
> traffic policing. Yet while this has a chance to work during normal 
> operation at the time of even regular failures this all pretty much 
> melts like cheese on a good sandwich.

A lot depends on the steps you take. For example we could take a leaf 
from the deterministic networks playbook and send duplicate packets on 
diverse paths, and reconcile them from time to
time to reign back the worst of the congestion.

At the end of the day, however you always pay a price for better than 
best effort.

>
> It is going to be very interesting to compare how single complex 
> sliced network compares for any end to end robust transport from N 
> normal simple IP backbones and end to end SLA based millisecond switch 
> over between one and another on a per flow basis. Also let's note then 
> while the former is still to the best of my knowledge a draft the 
> latter is already deployed globally in 100s of networks.

If the simple approach delivers what the customer needs then clearly it 
should be deployed.

- Stewart

>     *From: *rtgwg <[email-masked]
>     <mailto:[email-masked]>> on behalf of Stewart Bryant
>     <[email-masked] <mailto:[email-masked]>>
>     *To: *Robert Raszuk <[email-masked] <mailto:[email-masked]>>
>     *Cc: *Routing WG <[email-masked] <mailto:[email-masked]>>
>         Specifically on what basis do you treat say L2VPN or L3VPN of
>         naked unencrypted packets often traveling on the very same
>         links as this "bad" Internet traffic to be even slightly more
>         secure then IPSEC or DTLS encrypted SD-WAN carried data with
>         endpoints being terminated in private systems ?
>
>         Thx,
>
>         Robert
>
>
>     Robert, I think that you have to take it as read that an air
>     traffic control SoF system is encrypting its packets. If it is
>     not, then it is clearly not fit for purpose.
>
>     What concerns me is that an air traffic system is one of the most,
>     if not the most, high profile targets in civil society. You get
>     reminded of this each time you travel to IETF.
>
>     effective DDoS attack has global impact in a way that few other
>     such attacks have.
>
>     A VPN system ought to sustain resistance to such an attack better
>     than the proposed system which treats the SoF traffic the same as
>     regular traffic.
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Jul 2018 17:50:09 +0200

IMHO the main issue is that virtualization of networks and
any expectation of resource guarantees in the face of attacks opens
up a whole new slew of issues (attacks against shared infra)
which is today outside the scope of IETF focus because it does
not relate to our outdated definition of what qualifies for
IETF standardization.

If we want to help create secure virtualized network services we
need to have a lot more opinions about box internal behaviors
even to the extent of defining standards about them. Vendors
will suck at this if left unsupervised.

On Wed, Jul 25, 2018 at 01:32:25PM +0100, Stewart Bryant wrote:
> >> From: rtgwg <[email-masked]> on behalf of Stewart Bryant <[email-masked]>
> >> ???Hello ???
> >> ???You have made the below comment in the other thread we are having: ???
> >> 
> >>  
> >> 
> >> ???Would you mind as extensively as you can expand on the above statement ? 
> >> 
> >>  
> >> 
> >> I guess you are making a case for your network slicing work ????
> >> 
> >>  
> >> 
> >> Acee
> >> 
> >> 
> >> 
> >> - Stewart
> >> 
> >> 
> >> 
> > 

> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

-- 
---
[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Jul 2018 18:34:38 +0200

Agreed.

And very honestly I am not sure if accomplishing high service robustness is
best done via complicating any particular network or rather freedom to
dynamically choose your end to end path among many cadidate and globally
independent transports.

That was what I meant by *wise* use of Internet in the former message.

Vendor locking is as bad as operator's lock.

Cheers,
R.

On Wed, Jul 25, 2018, 17:50 Toerless Eckert <[email-masked]> wrote:

> > Perhaps the right thing here is for you to propose text to Fred on how
> to make sure his traffic is safe from the types of state-sponsored attack
> that an air traffic system might need to withstand?
> >
> > Stewart
> >
> or very strict multi-level queuing at each hop and 100% ingress traffic
> sliced network compares for any end to end robust transport from N normal
> simple IP backbones and end to end SLA based millisecond switch over
> between one and another on a per flow basis. Also let's note then while the
> former is still to the best of my knowledge a draft the latter is already
> deployed globally in 100s of networks.
> > >
> > > Best,
> > > R.
> > >
> > >
> than the proposed system which treats the SoF traffic the same as regular
> traffic.
> > >>
> > >>
> > >>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Jul 2018 20:12:04 +0200

> dynamically choose your end to end path among many cadidate and globally

Sure, the financial services industry has a long history of doing that.
And probably continues to learn about unexpected shared fates every day.
Would be great to see a nice BCP about all those aspects one day. Especially
when it includes those non-packet-networking dependencies. Constructions
that unexpectedly kill whats supposed to be two independent fiber trunks,
redundant power supplies that fail together, shared operations infra, etc. pp.

And there are new risks coming up. The more vendors start to reduce cost
sharing single-sourced (likely open source) software, the more that becomes
a single point of failure for example.

> That was what I meant by *wise* use of Internet in the former message.

Right. Except that i fear its less and less failure diverse as well
the more the market evolves. Cost reduction does not favor diversity.

> Vendor locking is as bad as operator's lock.

Or single open source lock.

You don't only want to be accepting of diversity, you want to encourage/enforce it.

Heck. Now i found my reason to justify the ongoing coexistance of ISIS and OSPF
that i usually lament. Except that this new LSR WG will probably
create a lot more consistency and less diversity ;-)

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 25 Jul 2018 12:31:42 -0700

Hi Robert,
great discussion, thank you.
I'd expect that the level of resource isolation and protection, guaranteed
or assured performance metrics will be applied as constraints and,
potentially, limit the use of the common infrastructure in favor of TE'd
and more controlled networks. For these premium services, as
Stewart suggested, different technologies, e.g., packet replication and
duplicate elimination, could be used.

Regards,
Greg

On Wed, Jul 25, 2018 at 9:34 AM, Robert Raszuk <[email-masked]> wrote:

> Agreed.
>
> And very honestly I am not sure if accomplishing high service robustness
> is best done via complicating any particular network or rather freedom to
>> if not the most, high profile targets in civil society. You get reminded of

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Jul 2018 21:49:40 +0200

> different technologies, e.g., packet replication and duplicate
elimination, could be used.

As long as the packet split and reassemble (dup removal) is in my own hands
and control and not something I would need to trust service provider to do
for me for x time the normal IP transport cost - it will be fine.

On Wed, Jul 25, 2018 at 9:31 PM, Greg Mirsky <[email-masked]> wrote:

>>> traffic control SoF system is encrypting its packets. If it is not, then it
>>> is clearly not fit for purpose.
>>> > >>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 28 Jul 2018 07:51:12 +0000

Hi Robert,

IMO the two approaches are targeting at different use cases and customers.

The former (network slicing) is to provide the demanding services with guaranteed performance in a converged network, while the latter (switching between multiple paralleled networks) provides the customer with the best performance that is available among those candidates. To me the latter is still some kind of best effort, and as Toerless said, it depends on the diversity you can have in the multiple networks.

And I agree with Stewart on “you always pay a price for better than best effort.”

Best regards,
Jie

From: rtgwg [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, July 25, 2018 8:24 PM
To: Acee Lindem (acee) <[email-masked]>
Cc: [email-masked]
Subject: Re: VPN security vs SD-WAN security

Best,
R.

​Hello ​
Stewart,

Thx,
Robert

Acee

- Stewart

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 28 Jul 2018 15:02:13 +0200

Hi Jie,

> (network slicing) is to provide the demanding services with guaranteed
performance in a converged network,

Foundation of converged IP network is based on statistical multiplexing of
traffic demands. As such it is in its principle quite contradictory to
"guaranteed" characteristics (performance, delays, jitter, drops -- you
name it).

Application layers usually deal very well with all of the above I would
state - normal characteristics of IP networks..

No doubt there will be those trying to offer some network slicing with
guarantees and even those who will buy it. Just like today there are those
who offer you L2 circuit between endpoints except such L2 circuit is an
emulated one with zero OEM visibility to the IP infrastructure underneath.

Now the network slicing is clearly aiming for even more complexity under
the hood. And that is not the only problem. The issue is cost. When SP is
building the IP network the goal is to mux as many services on it as it
simply results in given's SP revenue. Network slicing is promising as
potentially just by configuration of few knobs they will be claiming
guarantees as RFC says - except RFC will not likely tell you to stop
over-provisioning.

Unless the idea is to use strict policing with dedicated queuing on active
and back paths or do something like RSVP IntServ also on active and backup
paths per customer - I really don't think you can really guarantee much.
And if you do that the cost would likely grow really steep.

So what is IMO the solution for assured/guaranteed global IP transit:

*A*  get diversely routed  dark fiber paths between your POPs (can be
unprotected) which btw today do not cost that much anymore
*B*  get diversely routed  optical channels alsol between your POPs (can be
unprotected)

*C*  use N disjoined by design (single AS Internet providers between your
end-points) + proper SD-WAN with active SLA monitoring

Clearly I am big supporter of *C* model for reasons discussed on this and
few other recent threads.

I assume network slicing will try to get into be something between A/B & C
but it is bounded up front with the cost of the two.

Many thx,
Robert.

On Sat, Jul 28, 2018 at 9:51 AM, Dongjie (Jimmy) <[email-masked]>
wrote:

> The former (network slicing) is to provide the demanding services with
> guaranteed performance in a converged network, while the latter (switching
> between multiple paralleled networks) provides the customer with the best
> performance that is available among those candidates. To me the latter is
> still some kind of best effort, and as Toerless said, it depends on the
> diversity you can have in the multiple networks.
>
>
>
> *From:* rtgwg [mailto:[email-masked]] *On Behalf Of *Robert Raszuk
> *Sent:* Wednesday, July 25, 2018 8:24 PM
> *To:* Acee Lindem (acee) <[email-masked]>
> *Cc:* [email-masked]
>
> *Subject:* Re: VPN security vs SD-WAN security
>
>
>
>
>

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 28 Jul 2018 12:34:45 -0700

Hi Robert,
very much agree with all you're saying and find us in violent agreement on
"C". Proactive performance monitoring, in my view as well, is the
reasonable path to provide "soft" SLA and, to a degree, prevent
oversubscription of the network. And that, as you've said, is one way
to "assured/guaranteed
global IP transit".
But I think that there will be demand for "hard" guarantees for
URLLC applications. But these, in my view, would not require global transit
and likely be contained within access or, at most, metro domains. Because
of the limited size of the domain, IntServ may work, though that may be not
the most efficient technique. We shall find out.
Hence my view on slicing:

   - different applications will have different requirements and use
   different degrees of isolation and guarantees;
   - "soft" slices may not need much of additional standardization and use
   available VPN technologies in combination with PM OAM for SLA monitoring
   and assurance;
   - "hard" slices would span within a single access and/or metro domain.
   Networking solutions likely will be coupled with architecture and
   interfaces developed in Multi-access Edge Computing (MEC).

Regards,
Greg

On Sat, Jul 28, 2018 at 6:02 AM, Robert Raszuk <[email-masked]> wrote:

> *B*  get diversely routed  optical channels alsol between your POPs (can
> be unprotected)
>

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 28 Jul 2018 22:39:05 +0200

+1

The main issue with "hart" services is that you need to find the
niche bootstrap market where one can own the underlay and invest
into those new technologies required to support the "hart" services.

On Sat, Jul 28, 2018 at 12:34:45PM -0700, Greg Mirsky wrote:
> > emulated one with zero OEM visibility to the IP infrastructure underneath..
> >
> >> And I agree with Stewart on ???you always pay a price for better than best
> >> effort.???
> >>
> >>
> >>
> >> Best regards,
> >>
> >> Jie
> >>
> >>
> >>

-- 
---
[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 29 Jul 2018 00:10:41 +0200

Hey Greg,

would not require global transit and likely be contained within access or,
at most, metro domains.

That's news to me, but perhaps on the positive side :) I always think WAN
.. really wide one !

The separation on "soft" vs "hard" guarantees is eventually all about
amount of network robustness and level of over provisioning.  I sincerely
hope it will not be yet another EVPN overlay over IP network just painted
with different marketing colors.

Besides if any customer is serious and actually counts on those guarantees
he better purchase two of such services coming from independent operators.
That means that to be attractive financially cost of such premium service
must not be higher then half of the p2p local fiber or cost of local access
to closest IX ports + port subscription in a given MAN where non blocking
IX fabric spans given geography.

It seems to me that at the end of the day the space for those operators
wishing to offer hard network slicing is actually pretty narrow, but time
will tell ...

Rgs,
r.

On Sat, Jul 28, 2018 at 9:34 PM, Greg Mirsky <[email-masked]> wrote:

> oversubscription of the network. And that, as you've said, is one way to "assured/guaranteed
> global IP transit".
> URLLC applications. But these, in my view,
> would not require global transit and likely be contained within access or,
> at most, metro domains. Because of the limited size of the domain, IntServ
> may work, though that may be not the most efficient technique. We shall
> find out.
>    - "soft" slices may not need much of additional standardization and
>    use available VPN technologies in combination with PM OAM for SLA
>    monitoring and assurance;
>> Foundation of converged IP network is based on statistical multiplexing
>> of traffic demands. As such it is in its principle quite contradictory to
>> Unless the idea is to use strict policing with dedicated queuing on
>> active and back paths or do something like RSVP IntServ also on active and
>> backup paths per customer - I really don't think you can really guarantee
>> much. And if you do that the cost would likely grow really steep.
>>
>> I assume network slicing will try to get into be something between A/B &
>> C but it is bounded up front with the cost of the two.
>>
>> Many thx,
>> Robert.
>>
>>
>>
>>
>>> Hello
>>> You have made the below comment in the other thread we are having:
>>>
>>>
>>>
>>> Would you mind as extensively as you can expand on the above statement ?
>>>
>>>
>>>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 30 Jul 2018 11:07:44 +0100

Hi Robert

I think that summarises the situation well.

Ultimately the market will decide how much it is prepared to pay for the 
guarantee, and that will be based on a risk benefit analysis. That in 
turn will determine the viability of the market as a whole.

I think that there are certain types of network that may be more 
attracted to an NS system, for example safety of life services, or 
services that need real-time low latency such as a distributed recording 
studio, or services that fail safe but have wide impact such as a rail 
network controller are more likely to want this. On the other hand, the 
back end systems of Acme corp will largely be fine with parallel best 
effort mitigated across multiple providers.

- Stewart

On 28/07/2018 08:51, Dongjie (Jimmy) wrote:
> guaranteed performance in a converged network, while the latter 
> (switching between multiple paralleled networks) provides the customer 
> with the best performance that is available among those candidates. To 
> me the latter is still some kind of best effort, and as Toerless said, 
> it depends on the diversity you can have in the multiple networks.
>
> *From:*rtgwg [mailto:[email-masked]] *On Behalf Of *Robert Raszuk

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 30 Jul 2018 11:22:34 +0100

On 28/07/2018 14:02, Robert Raszuk wrote:
> Hi Jie,
>
> > (network slicing) is to provide the demanding services with 
> guaranteed performance in a converged network,
>
>
> Foundation of converged IP network is based on statistical 
> multiplexing of traffic demands. As such it is in its principle quite 
> contradictory to "guaranteed" characteristics (performance, delays, 
> jitter, drops -- you name it).
>
> Application layers usually deal very well with all of the above I 
> would state - normal characteristics of IP networks..
>
> guarantees and even those who will buy it. Just like today there are 
> those who offer you L2 circuit between endpoints except such L2 
> circuit is an emulated one with zero OEM visibility to the IP 
> infrastructure underneath.
>
> Now the network slicing is clearly aiming for even more complexity 
> under the hood.

We are not aiming for complexity

We are aiming to satisfy a need, and unfortunately with than comes a 
measure of complexity.

> And that is not the only problem. The issue is cost. When SP is 
> building the IP network the goal is to mux as many services on it as 
> it simply results in given's SP revenue. Network slicing is promising 
> as potentially just by configuration of few knobs they will be 
> claiming guarantees as RFC says - except RFC will not likely tell you 
> to stop over-provisioning.

Well that depends on how you do the over provisioning.

If I buy a dedicated network I pay the fully loaded costs.

The goal here is to provide dedicated resources, but sell them  to lower 
priority services
when they are unused. That  is more complex than simple best effort, but 
the high priority
service is a premium service.

The question for the SP is whether they can make money on selling the 
underusage, or
whether the commercial reality is that they need to build a number of 
networks.

> active and back paths or do something like RSVP IntServ also on active 
> and backup paths per customer - I really don't think you can really 
> guarantee much. And if you do that the cost would likely grow really 
> steep.

> So what is IMO the solution for assured/guaranteed global IP transit:

I am not yet sure how much of the market will be global as opposed to 
regional or sub-regional.

> *B* get diversely routed  optical channels alsol between your POPs 
> (can be unprotected)
>
> *C* use N disjoined by design (single AS Internet providers between 
> your end-points) + proper SD-WAN with active SLA monitoring
>
> Clearly I am big supporter of *C* model for reasons discussed on this 
> and few other recent threads.

C will clearly satisfy some parts of the market. There is no question 
about that.

>
> I assume network slicing will try to get into be something between A/B 
> & C but it is bounded up front with the cost of the two.

I think we need to build a network that operates as A/B for premium 
customers and provides C
for cost conscious customers.

- Stewart

>
> Many thx,
> Robert.
>
>
>
>
> On Sat, Jul 28, 2018 at 9:51 AM, Dongjie (Jimmy) <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Robert,
>
>     The former (network slicing) is to provide the demanding services
>     with guaranteed performance in a converged network, while the
>     latter (switching between multiple paralleled networks) provides
>     the customer with the best performance that is available among
>     those candidates. To me the latter is still some kind of best
>     effort, and as Toerless said, it depends on the diversity you can
>     have in the multiple networks.
>
>     *From:*rtgwg [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Robert Raszuk
>     *To:* Acee Lindem (acee) <[email-masked] <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>
>
>     True network slicing for IP networks means either waist of
>     resources or very strict multi-level queuing at each hop and 100%
>     ingress traffic policing. Yet while this has a chance to work
>     during normal operation at the time of even regular failures this
>     all pretty much melts like cheese on a good sandwich.
>
>     normal simple IP backbones and end to end SLA based millisecond
>     switch over between one and another on a per flow basis. Also
>     let's note then while the former is still to the best of my
>     knowledge a draft the latter is already deployed globally in 100s
>     of networks.
>
>     Best,
>     R.
>
>     On Wed, Jul 25, 2018 at 1:21 PM, Acee Lindem (acee)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Specifically on what basis do you treat say L2VPN or L3VPN
>             of naked unencrypted packets often traveling on the very
>             same links as this "bad" Internet traffic to be even
>             slightly more secure then IPSEC or DTLS encrypted SD-WAN
>             carried data with endpoints being terminated in private
>             systems ?
>
>             Thx,
>
>             Robert
>
>
>         What concerns me is that an air traffic system is one of the
>         most, if not the most, high profile targets in civil society.
>         You get reminded of this each time you travel to IETF.
>
>         The thing about safety of flight traffic is that a sustained
>         and effective DDoS attack has global impact in a way that few
>         other such attacks have.
>
>         A VPN system ought to sustain resistance to such an attack
>         better than the proposed system which treats the SoF traffic
>         the same as regular traffic.
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 30 Jul 2018 11:29:42 +0100

On 28/07/2018 20:34, Greg Mirsky wrote:
> Hi Robert,
> very much agree with all you're saying and find us in violent 
> agreement on "C". Proactive performance monitoring, in my view as 
> well, is the reasonable path to provide "soft" SLA and, to a degree, 
> prevent oversubscription of the network. And that, as you've said, is 
> one way to "assured/guaranteed global IP transit".
> URLLC applications. But these, in my view, would not require global 
> transit and likely be contained within access or, at most, metro 
> domains. Because of the limited size of the domain, IntServ may work, 
> though that may be not the most efficient technique.. We shall find out.
>   * different applications will have different requirements and use
>   * "soft" slices may not need much of additional standardization and
I agree up to here.

>   * "hard" slices would span within a single access and/or metro domain.
>
I agree that this is likely to be the majority case, but would not rule 
out a larger network
for some applications.

>   * Networking solutions likely will be coupled with architecture and
That is true, but may not be exclusively true.

- Stewart

> Regards,
> Greg
>
> On Sat, Jul 28, 2018 at 6:02 AM, Robert Raszuk <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Jie,
>
>     multiplexing of traffic demands. As such it is in its principle
>     quite contradictory to "guaranteed" characteristics (performance,
>     delays, jitter, drops -- you name it).
>
>     No doubt there will be those trying to offer some network slicing
>     with guarantees and even those who will buy it. Just like today
>     there are those who offer you L2 circuit between endpoints except
>     such L2 circuit is an emulated one with zero OEM visibility to the
>     IP infrastructure underneath.
>
>     under the hood. And that is not the only problem. The issue is
>     cost. When SP is building the IP network the goal is to mux as
>     many services on it as it simply results in given's SP revenue.
>     Network slicing is promising as potentially just by configuration
>     of few knobs they will be claiming guarantees as RFC says - except
>     RFC will not likely tell you to stop over-provisioning.
>
>     Unless the idea is to use strict policing with dedicated queuing
>     on active and back paths or do something like RSVP IntServ also on
>     active and backup paths per customer - I really don't think you
>     can really guarantee much. And if you do that the cost would
>     likely grow really steep.
>
>     *A* get diversely routed  dark fiber paths between your POPs (can
>     be unprotected) which btw today do not cost that much anymore
>     *C* use N disjoined by design (single AS Internet providers
>     between your end-points) + proper SD-WAN with active SLA monitoring
>
>     Clearly I am big supporter of *C* model for reasons discussed on
>     this and few other recent threads.
>
>     I assume network slicing will try to get into be something between
>     A/B & C but it is bounded up front with the cost of the two.
>
>     Many thx,
>     Robert.
>
>
>
>
>     On Sat, Jul 28, 2018 at 9:51 AM, Dongjie (Jimmy)
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi Robert,
>
>         The former (network slicing) is to provide the demanding
>         services with guaranteed performance in a converged network,
>         while the latter (switching between multiple paralleled
>         networks) provides the customer with the best performance that
>         is available among those candidates. To me the latter is still
>         some kind of best effort, and as Toerless said, it depends on
>         the diversity you can have in the multiple networks.
>
>         resources or very strict multi-level queuing at each hop and
>         100% ingress traffic policing. Yet while this has a chance to
>         work during normal operation at the time of even regular
>         failures this all pretty much melts like cheese on a good
>         sandwich.
>
>         It is going to be very interesting to compare how single
>         complex sliced network compares for any end to end robust
>         transport from N normal simple IP backbones and end to end SLA
>         based millisecond switch over between one and another on a per
>         flow basis. Also let's note then while the former is still to
>         the best of my knowledge a draft the latter is already
>             <mailto:[email-masked]>> on behalf of Stewart
>             Bryant <[email-masked]
>             <mailto:[email-masked]>>
>                     Indeed, I would have expected this to be on a
>                     secure network of some sort either purely
>                 Specifically on what basis do you treat say L2VPN or
>                 L3VPN of naked unencrypted packets often traveling on
>                 the very same links as this "bad" Internet traffic to
>                 be even slightly more secure then IPSEC or DTLS
>                 encrypted SD-WAN carried data with endpoints being
>                 terminated in private systems ?
>
>                 Thx,
>
>                 Robert
>
>
>             Robert, I think that you have to take it as read that an
>             air traffic control SoF system is encrypting its packets.
>             If it is not, then it is clearly not fit for purpose.
>
>             What concerns me is that an air traffic system is one of
>             the most, if not the most, high profile targets in civil
>             society. You get reminded of this each time you travel to
>             IETF.
>
>             The thing about safety of flight traffic is that a
>             sustained and effective DDoS attack has global impact in a
>             way that few other such attacks have.
>
>             better than the proposed system which treats the SoF
>             traffic the same as regular traffic.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/rtgwg>
>
>
>
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 30 Jul 2018 10:38:42 +0000

Hi Robert,

Thanks for your comments. Please see my replies inline:

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Saturday, July 28, 2018 9:02 PM
To: Dongjie (Jimmy) <[email-masked]>
Cc: Acee Lindem (acee) <[email-masked]>; [email-masked]
Subject: Re: VPN security vs SD-WAN security

Hi Jie,

> (network slicing) is to provide the demanding services with guaranteed performance in a converged network,

Foundation of converged IP network is based on statistical multiplexing of traffic demands. As such it is in its principle quite contradictory to "guaranteed" characteristics (performance, delays, jitter, drops -- you name it).

[Jie] Totally agree that statistic multiplexing is the foundation of IP network. Adding guarantee would reduce the benefit of multiplexing, while statistic multiplexing is still possible under some constraints. For example, traffic within the same slice could have some multiplexing gains.

Application layers usually deal very well with all of the above I would state - normal characteristics of IP networks..

No doubt there will be those trying to offer some network slicing with guarantees and even those who will buy it. Just like today there are those who offer you L2 circuit between endpoints except such L2 circuit is an emulated one with zero OEM visibility to the IP infrastructure underneath.

Now the network slicing is clearly aiming for even more complexity under the hood. And that is not the only problem. The issue is cost. When SP is building the IP network the goal is to mux as many services on it as it simply results in given's SP revenue. Network slicing is promising as potentially just by configuration of few knobs they will be claiming guarantees as RFC says - except RFC will not likely tell you to stop over-provisioning.

Unless the idea is to use strict policing with dedicated queuing on active and back paths or do something like RSVP IntServ also on active and backup paths per customer - I really don't think you can really guarantee much. And if you do that the cost would likely grow really steep.

[Jie] With network slicing SPs aim to introduce more diverse services onto their network, including the demanding services. While the cost of providing such service would be higher than for best effort, the price of such service would also be higher due to the added guarantee it can provide.

Policing, dedicated queueing and IntServ are useful tools to provide the guarantee. There may be scalability concerns, which needs some further discussion.

*A*  get diversely routed  dark fiber paths between your POPs (can be unprotected) which btw today do not cost that much anymore
*B*  get diversely routed  optical channels alsol between your POPs (can be unprotected)

*C*  use N disjoined by design (single AS Internet providers between your end-points) + proper SD-WAN with active SLA monitoring

Clearly I am big supporter of *C* model for reasons discussed on this and few other recent threads.

I assume network slicing will try to get into be something between A/B & C but it is bounded up front with the cost of the two.

[Jie] A/B are below packet (IP) , C is based on multiple operator diversity, we need to understand what can be done between them.

Best regards,
Jie

Many thx,
Robert.

On Sat, Jul 28, 2018 at 9:51 AM, Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Best regards,
Jie

From: rtgwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Wednesday, July 25, 2018 8:24 PM
To: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>

Best,
R.

​Hello ​
Stewart,

Thx,
Robert

Acee

- Stewart

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 30 Jul 2018 12:23:56 +0000

(Adding TEAS as it is where the VPN+ framework draft is discussed)

Hi Robert and Greg,

As discussed during the VPN+ presentation in TEAS at IETF 102, the scope is not the internet, as we know it would quite difficult or even impossible to achieve the required guarantee at the scope of internet.

And clearly the VPN overlays cannot provide the required guarantee, deep integration with the underlay resource would be necessary.

Another aspect we may take into consideration is the factor of overprovisioning. The current network only has one overprovisioning factor, which may not meet the requirement of different services/customers. With network slicing, it is possible to have different overprovisioning policy and factor in different slices.

Best regards,
Jie

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Sunday, July 29, 2018 6:11 AM
To: Greg Mirsky <[email-masked]>
Cc: Dongjie (Jimmy) <[email-masked]>; [email-masked]
Subject: Re: VPN security vs SD-WAN security

Hey Greg,

would not require global transit and likely be contained within access or, at most, metro domains.

That's news to me, but perhaps on the positive side :) I always think WAN .. really wide one !

The separation on "soft" vs "hard" guarantees is eventually all about amount of network robustness and level of over provisioning.  I sincerely hope it will not be yet another EVPN overlay over IP network just painted with different marketing colors.

Besides if any customer is serious and actually counts on those guarantees he better purchase two of such services coming from independent operators. That means that to be attractive financially cost of such premium service must not be higher then half of the p2p local fiber or cost of local access to closest IX ports + port subscription in a given MAN where non blocking IX fabric spans given geography.

It seems to me that at the end of the day the space for those operators wishing to offer hard network slicing is actually pretty narrow, but time will tell ...

Rgs,
r.

On Sat, Jul 28, 2018 at 9:34 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,
very much agree with all you're saying and find us in violent agreement on "C". Proactive performance monitoring, in my view as well, is the reasonable path to provide "soft" SLA and, to a degree, prevent oversubscription of the network. And that, as you've said, is one way to "assured/guaranteed global IP transit".
But I think that there will be demand for "hard" guarantees for URLLC applications. But these, in my view,
would not require global transit and likely be contained within access or, at most, metro domains. Because of the limited size of the domain, IntServ may work, though that may be not the most efficient technique. We shall find out.
Hence my view on slicing:

  *   different applications will have different requirements and use different degrees of isolation and guarantees;
  *   "soft" slices may not need much of additional standardization and use available VPN technologies in combination with PM OAM for SLA monitoring and assurance;
  *   "hard" slices would span within a single access and/or metro domain. Networking solutions likely will be coupled with architecture and interfaces developed in Multi-access Edge Computing (MEC).
Regards,
Greg

On Sat, Jul 28, 2018 at 6:02 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jie,

Many thx,
Robert.

Best regards,
Jie

Best,
R.

Hello
Stewart,

Thx,
Robert

Acee

- Stewart

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 30 Jul 2018 11:04:46 -0400

Actually, assuming I understand the statement properly, "deep 
integration with the underlay resource would be necessary" does not 
appear to be an accurate statement derivable from the requirements that 
I have seen.

Yours,
Joel

On 7/30/18 8:23 AM, Dongjie (Jimmy) wrote:
> As discussed during the VPN+ presentation in TEAS at IETF 102, the scope 
> is not the internet, as we know it would quite difficult or even 
> impossible to achieve the required guarantee at the scope of internet.
> 
> And clearly the VPN overlays cannot provide the required guarantee, deep 
> integration with the underlay resource would be necessary.
> 
> Another aspect we may take into consideration is the factor of 
> overprovisioning. The current network only has one overprovisioning 
> factor, which may not meet the requirement of different 
> services/customers. With network slicing, it is possible to have 
> different overprovisioning policy and factor in different slices.
> 
> Best regards,
> 
> Jie
> 
> *From:[email-masked] [mailto:[email-masked]] *On Behalf Of 
> *Robert Raszuk
> *Sent:* Sunday, July 29, 2018 6:11 AM
> *To:* Greg Mirsky <[email-masked]>
> *Cc:* Dongjie (Jimmy) <[email-masked]>; [email-masked]
> amount of network robustness and level of over provisioning.  I 
> sincerely hope it will not be yet another EVPN overlay over IP network 
> just painted with different marketing colors.
> 
> Besides if any customer is serious and actually counts on those 
> guarantees he better purchase two of such services coming from 
> independent operators. That means that to be attractive financially cost 
> of such premium service must not be higher then half of the p2p local 
> fiber or cost of local access to closest IX ports + port subscription in 
> a given MAN where non blocking IX fabric spans given geography.
> 
> wishing to offer hard network slicing is actually pretty narrow, but 
> time will tell ...
> 
> Rgs,
> 
> r.
> 
>     prevent oversubscription of the network. And that, as you've said,
>     is one way to "assured/guaranteed global IP transit".
> 
>     would not require global transit and likely be contained within
>     access or, at most, metro domains. Because of the limited size of
>     the domain, IntServ may work, though that may be not the most
>     efficient technique. We shall find out.
> 
>       * "soft" slices may not need much of additional standardization
>         and use available VPN technologies in combination with PM OAM
>         for SLA monitoring and assurance;
>       * "hard" slices would span within a single access and/or metro
>         domain. Networking solutions likely will be coupled with
>         architecture and interfaces developed in Multi-access Edge
>         Computing (MEC).
> 
>     Regards,
> 
>     Greg
> 
>         quite contradictory to "guaranteed" characteristics
>         (performance, delays, jitter, drops -- you name it).
> 
>         Application layers usually deal very well with all of the above
>         I would state - normal characteristics of IP networks..
> 
>         No doubt there will be those trying to offer some network
>         slicing with guarantees and even those who will buy it. Just
>         like today there are those who offer you L2 circuit between
>         endpoints except such L2 circuit is an emulated one with zero
>         OEM visibility to the IP infrastructure underneath.
> 
>         Now the network slicing is clearly aiming for even more
>         complexity under the hood. And that is not the only problem. The
>         issue is cost. When SP is building the IP network the goal is to
>         mux as many services on it as it simply results in given's SP
>         revenue. Network slicing is promising as potentially just by
>         configuration of few knobs they will be claiming guarantees as
>         RFC says - except RFC will not likely tell you to stop
>         over-provisioning.
> 
>         on active and back paths or do something like RSVP IntServ also
>         on active and backup paths per customer - I really don't think
>         you can really guarantee much. And if you do that the cost would
>         *A*  get diversely routed  dark fiber paths between your POPs
>         (can be unprotected) which btw today do not cost that much anymore
> 
>         I assume network slicing will try to get into be something
>         between A/B & C but it is bounded up front with the cost of the
>         two.
> 
>         Many thx,
> 
>         Robert.
> 
>             networks) provides the customer with the best performance
>             that is available among those candidates. To me the latter
>             is still some kind of best effort, and as Toerless said, it
>             depends on the diversity you can have in the multiple networks.
> 
>             100% ingress traffic policing. Yet while this has a chance
>             to work during normal operation at the time of even regular
>             transport from N normal simple IP backbones and end to end
>             SLA based millisecond switch over between one and another on
>             a per flow basis. Also let's note then while the former is
>             still to the best of my knowledge a draft the latter is
>             already deployed globally in 100s of networks.
> 
>             Best,
>             R.
> 
>                     L3VPN of naked unencrypted packets often traveling
>                     on the very same links as this "bad" Internet
>                     traffic to be even slightly more secure then IPSEC
>                     or DTLS encrypted SD-WAN carried data with endpoints
>                     being terminated in private systems ?
> 
>                     Thx,
> 
>                     Robert
> 
> 
>                 air traffic control SoF system is encrypting its
>                 packets. If it is not, then it is clearly not fit for
>                 purpose.
> 
>                 society. You get reminded of this each time you travel
>                 to IETF.
> 
>                 sustained and effective DDoS attack has global impact in
>                 a way that few other such attacks have.
> 
>                 A VPN system ought to sustain resistance to such an
>                 attack better than the proposed system which treats the
>                 SoF traffic the same as regular traffic.
>