Subject: [L3sm] Stephen Farrell's Discuss on draft-ietf-l3sm-l3vpn-service-model-18: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 26 Oct 2016 06:57:52 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-l3sm-l3vpn-service-model-18: Discuss

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-l3sm-l3vpn-service-model/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) In 5.9.2, how are pre shared keys (PSK) updated or
rotated?  Don't you at least need some key id or versioning
or old/new thing defined? (Apologies if that "just works"
via some yang magic of which I'm unaware:-)

(2) When someone wants to use IPsec with PSK, wouldn't you
also need to specify algorithms etc to get interop?  I see
there's an "algorithm" string in the yang module, but that
seems too underspecified to be useful.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- 5.9.1: Just curious, the text says "   The current model
does not support any authentication parameters..." is that
because there's no user or host authentication?

- 5.9.2: I wondered why the empty "pki" container? Would it
not have been useul to define what's needed there, or do
you just never see IPsec using IKE for these VPNs? (Which
would be a bit sad;-)

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 26 Oct 2016 15:50:53 +0100

Hi Stephen,

> via some yang magic of which I'm unaware:-)

If I understand you correctly you would expect "key in use" and "new key to use"
to allow the rotation?

I think that the model assumes that key change is handled under the covers. That
means that the user simply sets the "key to use" and if process is required to
achieve rotation, the consumer of the model is responsible for transitioning the
key.

> seems too underspecified to be useful.

I think you mean to ask how the content of the "algorithm" string is interpreted
and mapped onto an algorithm in software. 
I agree a programmatic approach would be nice (using a type), but perhaps
customers and operators are used to using locally defined strings?

In the event that we can use a type, can you point us at the appropriate
registry. Is it
http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-regist
ry-4

> because there's no user or host authentication?

Hmmm?
User or host authentication would, I think, apply to the Netconf exchanges
themselves.
This would be CE-PE authentication, I suppose. To ensure the right CE is talking
to the right PE.

> you just never see IPsec using IKE for these VPNs? (Which

It seems likely that different service providers will offer different
mechanisms. The intention, therefore, was to provide a starting point (a hook)
into which implementers could add their own security mechanisms through
augmentation.

Cheers,
Adrian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 27 Oct 2016 14:20:01 +0100

Hiya,

> If I understand you correctly you would expect "key in use" and "new key to use"

Something like that, yep. There're various ways one could do it.

> achieve rotation, the consumer of the model is responsible for transitioning the

If that works, then that's fine, but I'm not seeing how it works.
A PSK has to be in at least two places to be useful, so I'm not
sure how you could ensure both change at the same time without
possibly breaking something.

> http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-regist

I'm not sure exactly what'd be best TBH, but for IPsec there're
a bunch of things that one'd want I think. If/when we need to
figure out how to write those down then I'd probably go find
someone who implements IPsec and ask them (maybe Yoav would be
good for that for example).

> User or host authentication would, I think, apply to the Netconf exchanges

Sure, I wasn't confused by that aspect.

> This would be CE-PE authentication, I suppose. To ensure the right CE is talking

The text in 5.9.1 still puzzles me tbh, but maybe that's ok:-)

> into which implementers could add their own security mechanisms through

Sure.

Cheers,
S.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Oct 2016 15:20:15 +0200

> achieve rotation, the consumer of the model is responsible for transitioning the
I agree with Adrian. We're not trying to specify all possible knobs:

    The idea of the L3 IPVPN service model is to propose an abstracted
    interface between customers and network operators to manage
    configuration of components of a L3VPN service.  A typical usage is
    to use this model as an input for an orchestration layer who will be
    responsible to translate it to orchestrated configuration of network
    elements who will be part of the service.

Regards, B.
> .

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Oct 2016 15:35:32 +0200

> possibly breaking something.
Typical example. A discussion between customer and operator:
     cust: I request encryption on the connection
     oper: Ok.
     oper: Do I manager your CE?
     cust: yes
     oper: Ok. I take care of everything (see section 5.10, 
provider-managed, co-managed)

Granted. In the customer-managed case, we need a mechanism for "key in 
use" and "new key to use"
The question is: should it be in this service model?

Regards, Benoit

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 27 Oct 2016 14:38:11 +0100

> The question is: should it be in this service model?

I'm not sure. Being able to rotate keys is needed. Whether
or not that needs to be visible in this service model,
depends on how it works I guess.

S

---

From: Benoit Claise <[email-masked]>
Date: Thu, 27 Oct 2016 18:22:21 +0200

Dear authors,

We've been discussing Stephen's DISCUSS point during the IESG telechat 
today.
I finally understood the crux of the issue. Stephen had in mind key 
rotation, _with no service interruption_, in CE customer-managed case.
Note: The provider-managed and co-managed use cases are fine, as the 
mechanics could be specified in the device YANG models.

Joel mentioned that re-provisioning, with some service interruption, was 
an acceptable solution.
The next step is for you, as operators, to express your view. Either 
some re-provisioning with service interruption is fine, or we need a 
mechanism (I guess within the service YANG model). Something around 
"current key", "new key to use", as Adrian proposed.

In the end, Stephen is after a mechanism that allows to change the keys.

Regards, Benoit

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Fri, 28 Oct 2016 14:33:44 +0900

Hi Stephane and All,

>Joel mentioned that re-provisioning, with some service interruption, was an acceptable solution.

As a co-author and an operator, re-provisioning with some service interruption is fine.

In the customer-managed CE case, a provisioning synchronization between PE and CE is always challenging and we are negotiating the maintenance time with our customer in person when any inconsistency of configurations between PE and CE causes a service interruption.
This is not only the case for PSK, but also for the other parameter like static address allocation.

Honestly, our current commercial service can allow to change the PSK in use from GUI-based web portal. Then, our customers do so at any time convenient for them. But, the perfect synchronization is still impossible.

I don't know if there is a mechanism that PE can support two PSK, in use and new, at the same time. If exists, we can add the extension to base model by augmentation.

Thanks,
Kenichi

-----Original Message-----
From: L3sm [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Friday, October 28, 2016 1:22 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; 'The IESG'; [email-masked]; [email-masked]; Stephen Farrell
Subject: Re: [L3sm] Stephen Farrell's Discuss on draft-ietf-l3sm-l3vpn-service-model-18: (with DISCUSS and COMMENT)

Dear authors, 

We've been discussing Stephen's DISCUSS point during the IESG telechat today.
I finally understood the crux of the issue. Stephen had in mind key rotation, with no service interruption, in CE customer-managed case. 
Note: The provider-managed and co-managed use cases are fine, as the mechanics could be specified in the device YANG models.

Joel mentioned that re-provisioning, with some service interruption, was an acceptable solution.
The next step is for you, as operators, to express your view. Either some re-provisioning with service interruption is fine, or we need a mechanism (I guess within the service YANG model). Something around "current key", "new key to use", as Adrian proposed.

Regards, Benoit

	

			Hiya,

				Hi Stephen,

				If I understand you correctly you would expect "key in use" and "new
				key to use"
				to allow the rotation?

				I think that the model assumes that key change is handled under the
				covers. That
				means that the user simply sets the "key to use" and if process is
				required to
				achieve rotation, the consumer of the model is responsible for
				transitioning the
				key.

		

	S

		Regards, Benoit

				I think you mean to ask how the content of the "algorithm" string is
				interpreted
				and mapped onto an algorithm in software.
				I agree a programmatic approach would be nice (using a type), but
				perhaps
				customers and operators are used to using locally defined strings?

				ry-4

					COMMENT:

				Hmmm?
				User or host authentication would, I think, apply to the Netconf
				exchanges
				themselves.

				This would be CE-PE authentication, I suppose. To ensure the right CE
				is talking
				to the right PE.

				It seems likely that different service providers will offer different
				mechanisms. The intention, therefore, was to provide a starting point
				(a hook)
				into which implementers could add their own security mechanisms through
				augmentation.

			Sure.
			
			Cheers,
			S.

				Cheers,
				Adrian

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 28 Oct 2016 07:54:51 +0100

Hiya,

On 28/10/16 06:33, Ogaki, Kenichi wrote:
> Hi Stephane and All,
> 
>> Joel mentioned that re-provisioning, with some service
>> interruption, was an acceptable solution.
> 

Ok, given that, then changing keys becomes quite possible
I guess. So I've cleared. Thanks for the clarification.

Note that I didn't at all get the impression that service
interruption would likely happen when the values discussed
here change. That may be obvious to folks working in this
space, but you might want to consider saying something
about that in the draft.

Cheers,
S.

> 
> In the customer-managed CE case, a provisioning synchronization
> between PE and CE is always challenging and we are negotiating the
> maintenance time with our customer in person when any inconsistency
> of configurations between PE and CE causes a service interruption. 
> Honestly, our current commercial service can allow to change the PSK
> in use from GUI-based web portal. Then, our customers do so at any
> time convenient for them. But, the perfect synchronization is still
> impossible.
> 
> I don't know if there is a mechanism that PE can support two PSK, in
> use and new, at the same time. If exists, we can add the extension to
> base model by augmentation.
> 
> Thanks, Kenichi
> 
> 
> 
> -----Original Message----- From: L3sm [mailto:[email-masked]]
> On Behalf Of Benoit Claise Sent: Friday, October 28, 2016 1:22 AM To:
> [email-masked] Cc: [email-masked];
> [email-masked]; 'The IESG'; [email-masked];
> [email-masked]; Stephen Farrell Subject: Re: [L3sm] Stephen
> Farrell's Discuss on draft-ietf-l3sm-l3vpn-service-model-18: (with
> DISCUSS and COMMENT)
> 
> Dear authors,
> 
> We've been discussing Stephen's DISCUSS point during the IESG
> telechat today. I finally understood the crux of the issue. Stephen
> had in mind key rotation, with no service interruption, in CE
> customer-managed case. Note: The provider-managed and co-managed use
> cases are fine, as the mechanics could be specified in the device
> YANG models.
> 
> Joel mentioned that re-provisioning, with some service interruption,
> was an acceptable solution. The next step is for you, as operators,
> to express your view. Either some re-provisioning with service
> interruption is fine, or we need a mechanism (I guess within the
> service YANG model). Something around "current key", "new key to
> use", as Adrian proposed.
> 
> Hiya,  On 26/10/16 15:50, Adrian Farrel wrote:
> 
> Hi Stephen, 
> 
> (1) In 5.9.2, how are pre shared keys (PSK) updated or rotated?
> Don't you at least need some key id or versioning or old/new thing
> defined? (Apologies if that "just works" via some yang magic of which
> I'm unaware:-)
> 
> key to use" to allow the rotation?
> 
> covers. That means that the user simply sets the "key to use" and if
> process is required to achieve rotation, the consumer of the model is
> responsible for transitioning the key.
> 
> If that works, then that's fine, but I'm not seeing how it works. A
> PSK has to be in at least two places to be useful, so I'm not sure
> how you could ensure both change at the same time without possibly
> breaking something.
> 
> Typical example. A discussion between customer and operator: cust: I
> request encryption on the connection oper: Ok. oper: Do I manager
> your CE? cust: yes oper: Ok. I take care of everything (see section
> 5.10, provider-managed, co-managed)  Granted. In the customer-managed
> case, we need a mechanism for "key in use" and "new key to use" The
> question is: should it be in this service model?
> 
>  I'm not sure. Being able to rotate keys is needed. Whether or not
> that needs to be visible in this service model, depends on how it
> works I guess.  S 
> 
>  Regards, Benoit
> 
> 
> 
> (2) When someone wants to use IPsec with PSK, wouldn't you also need
> to specify algorithms etc to get interop?  I see there's an
> "algorithm" string in the yang module, but that seems too
> underspecified to be useful.
> 
> interpreted and mapped onto an algorithm in software. I agree a
> programmatic approach would be nice (using a type), but perhaps 
> In the event that we can use a type, can you point us at the
> appropriate registry. Is it 
> I'm not sure exactly what'd be best TBH, but for IPsec there're a
> bunch of things that one'd want I think. If/when we need to figure
> out how to write those down then I'd probably go find someone who
> implements IPsec and ask them (maybe Yoav would be good for that for
> example). 
> 
> COMMENT:  - 5.9.1: Just curious, the text says "   The current model 
> does not support any authentication parameters..." is that because
> there's no user or host authentication?
> 
> Hmmm? User or host authentication would, I think, apply to the
> Netconf exchanges themselves.
> 
> This would be CE-PE authentication, I suppose. To ensure the right
> CE is talking to the right PE.
> 
> - 5.9.2: I wondered why the empty "pki" container? Would it not have
> been useul to define what's needed there, or do you just never see
> IPsec using IKE for these VPNs? (Which would be a bit sad;-)
> 
> It seems likely that different service providers will offer
> different mechanisms. The intention, therefore, was to provide a
> starting point (a hook) into which implementers could add their own
> security mechanisms through augmentation.
> 
> Sure.  Cheers, S.  
> 
> Cheers, Adrian 
> 
> 
> 
> 
> 
> 
>