Subject: [LOOPS] Charter github issue #1: security, management, operations

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Jul 2020 08:34:14 +0200

In charter github issue #1 <https://github.com/loops-wg/charter/issues/1>,
cabo writes:

»

Either in the charter proposal itself or in the discussion below, we should say more about security, management, and operations of a LOOPS tunnel (comment from Colin Perkins).

draft-ietf-tsvwg-transport-encrypt-05 might inform us here with some of the issues to be addressed.

A separate deliverable could expand on this, but we wouldn’t want to ship the initial one (information model/protocol) without some thinking about this, so I'm not sure such a deliverable should be called out separately.

We would like to keep the “orchestrator” that sets up LOOPS segments as out of scope, though; this would likely be some form of SDN controller for the overlay that we don’t have to standardize to make LOOPS work. (Or maybe we want to standardize some form of it later [as a YANG model?].)

«
 
Liyizhou writes:

»

ACL can be used to direct traffic to LOOPS-enalbed tunnel. I think it is very reasonable to keep the “orchestrator” stuff out of scope. The “orchestrator” usually does more work besides LOOPS enablement. It is also responsible for path selection in our demo system. Hard to peel LOOPS alone from the whole orchestrator. So it is not necessary to standardize the LOOPS setup part.

I do not think YANG model needs to be included right now. It looks the LOOPS setup now can be a simple KV configuration file, for example, initial PSN, recovery mode (rtx/fec), no complex structure is required.

«

I added a sentence about such a K/V configuration data set in:

https://github.com/loops-wg/charter/pull/10

Does the charter need any more details on this?
(E.g., do we need to explain how such a configuration protocol could be secure?)

Grüße, Carsten

---

From: <[email-masked]>
Date: Tue, 7 Jul 2020 08:56:22 +0000

Hi Carsten, all,

Looks good to me.

If NETCONF or RESTCOF is used for example, they will come with the appropriate security tools to enable them. I'm not sure we need to touch on this in the charter. 

Likewise, we might indicate that some no-config data can also be exposed to a controller (e.g., errors). Such info can be used to tweak back the config parameters. But again I think all these additions are better handled in a spec rather than a charter text.  

Cheers,
Med 

> -----Message d'origine-----
> De : LOOPS [mailto:[email-masked]] De la part de Carsten Bormann
> Envoyé : mardi 7 juillet 2020 08:34
> À : loops
> Objet : [LOOPS] Charter github issue #1: security, management, operations
> 
> Either in the charter proposal itself or in the discussion below, we should
> say more about security, management, and operations of a LOOPS tunnel
> (comment from Colin Perkins).
> 
> A separate deliverable could expand on this, but we wouldn’t want to ship
> the initial one (information model/protocol) without some thinking about
> this, so I'm not sure such a deliverable should be called out separately.
> 
> We would like to keep the “orchestrator” that sets up LOOPS segments as out
> of scope, though; this would likely be some form of SDN controller for the
> overlay that we don’t have to standardize to make LOOPS work. (Or maybe we
> want to standardize some form of it later [as a YANG model?].)
> 
> «
> 
> Liyizhou writes:
> 
> »
> 
> ACL can be used to direct traffic to LOOPS-enalbed tunnel. I think it is
> very reasonable to keep the “orchestrator” stuff out of scope. The
> “orchestrator” usually does more work besides LOOPS enablement. It is also
> responsible for path selection in our demo system. Hard to peel LOOPS alone
> from the whole orchestrator. So it is not necessary to standardize the
> LOOPS setup part.
> 
> I do not think YANG model needs to be included right now. It looks the
> LOOPS setup now can be a simple KV configuration file, for example, initial
> PSN, recovery mode (rtx/fec), no complex structure is required.
> 
> «
> 
> --
> LOOPS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/loops

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 Jul 2020 14:17:39 +0200

So I have merged the PR #10.

I also merged #9, which is closing issue #6.

Issue #2 is still open.
In the side meeting on 2020-05-26, we seemed to have consensus to cut down the number of WGs/RGs we explicitly mention, and while I agree that PANRG is a group to watch, I see little interaction with the minimum viable protocol (MVP) that we are targeting for chartering now.  So I’m considering closing this as well now.

Grüße, Carsten

---

From: <[email-masked]>
Date: Thu, 9 Jul 2020 13:06:44 +0000

Hi Carsten, all,

I agree with this analysis. 

Cheers,
Med

> Envoyé : jeudi 9 juillet 2020 14:18
> À : loops <[email-masked]>
> Objet : [LOOPS] Remaining issues (Re: Charter github issue #1:
> security, management, operations)
> 
> In the side meeting on 2020-05-26, we seemed to have consensus to
> cut down the number of WGs/RGs we explicitly mention, and while I
> agree that PANRG is a group to watch, I see little interaction
> with the minimum viable protocol (MVP) that we are targeting for
> chartering now.  So I’m considering closing this as well now.
> 
> Grüße, Carsten
> 
> --
> LOOPS mailing list
> [email-masked]