Subject: Genart last call review of draft-wu-l3sm-rfc8049bis-07

From: Jari Arkko <[email-masked]>
Date: Wed, 25 Oct 2017 13:53:12 -0700

Reviewer: Jari Arkko
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-wu-l3sm-rfc8049bis-??
Reviewer: Jari Arkko
Review Date: 2017-10-25
IETF LC End Date: 2017-10-11
IESG Telechat date: 2017-10-26

Summary: I'm not an expert on YANG *at all*. And not an expert on the topic in
question either. And I had far too little time to spend on this long document.
But as far as the textual content of the document goes, it seems reasonable. I
have a difficulty in assessing how complete and implementable this model is
however. Are there implementations?

I did enjoy the classification of Internet connectivity as a special case of
cloud service :-) You may be onto something.

I did observe a couple of question marks or issues that probably deserve some
thought or small revisions.

Major issues: -

Minor issues:

I'm not sure I fully understand the need for "SP MUST honour <requirement>"
language in the document. Are there parts of the described model that they SP
is *not* required to honour? Other than the explicit strict true/false
settings? And in any case, sizeable networks are likely to have issues that
might require negotiation/human involvement.

I don't understand how 6.9.1 can say there is no authentication support but
then 6.9.2 (encryption) talks about authentication keys. I'd suggest some
rethinking or at least clarification might be needed here.

In the security considerations, I would note that if these models are used not
merely for creation of networks, but also their modification, the consequences
of inadvertent or malicious modifications can severe and network wide. Perhaps
that could be discussed.

Nits/editorial comments:

Section 6.12.2. s/fragmented/fragment it/

---

From: Qin Wu <[email-masked]>
Date: Thu, 26 Oct 2017 07:02:13 +0000

-----邮件原件-----
发件人: Jari Arkko [mailto:[email-masked]] 
发送时间: 2017年10月26日 4:53
收件人: [email-masked]
抄送: [email-masked]; [email-masked]
主题: Genart last call review of draft-wu-l3sm-rfc8049bis-07

Reviewer: Jari Arkko

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

Summary: I'm not an expert on YANG *at all*. And not an expert on the topic in question either. And I had far too little time to spend on this long document.
But as far as the textual content of the document goes, it seems reasonable. I have a difficulty in assessing how complete and implementable this model is however. Are there implementations?

[Qin]: Yes, there are implementations, something broken in RFC8049 needs to get right.

I did enjoy the classification of Internet connectivity as a special case of cloud service :-) You may be onto something.

[Qin]:Yes, internet connectivity is special example of public cloud, in my understanding,:-)

I did observe a couple of question marks or issues that probably deserve some thought or small revisions.

Major issues: -

Minor issues:

I'm not sure I fully understand the need for "SP MUST honour <requirement>"
language in the document. Are there parts of the described model that they SP is *not* required to honour? Other than the explicit strict true/false settings? And in any case, sizeable networks are likely to have issues that might require negotiation/human involvement.

[Qin]: Explicit settings are covered by sub-section of section 6.6, such as device constraint, Site Location constraint/parameter, access type.
Unlike RFC8049, RFC8049bis change "SP SHOULD honor" into "SP MUST honor". 

I don't understand how 6.9.1 can say there is no authentication support but then 6.9.2 (encryption) talks about authentication keys. I'd suggest some rethinking or at least clarification might be needed here.

[Qin]: Authentication provides you access to a resource like a computer or a network. Encryption provides confidentiality and controls whether an object can be read or not.
Both Authentication and Encryption are site level parameters and applicable to site connection. Pre-share key as encryption parameter can be used, e.g., for routing protocol authentication.
But pre-share key parameter is not authentication parameter, one example I have for authentication parameter is authentication algorithm which is not specified in the model,
We will see how to clarify this in the model. thanks.

In the security considerations, I would note that if these models are used not merely for creation of networks, but also their modification, the consequences of inadvertent or malicious modifications can severe and network wide. Perhaps that could be discussed.

[Qin]:Security consideration section has already considered both creation of networks and but also their modification, see the text in security consideration section as follows:
"
   The data nodes defined in the "ietf-l3vpn-svc" YANG module MUST be
   carefully created, read, updated, or deleted as appropriate.
"

Nits/editorial comments:

[Qin]: Will fix this, thanks.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 26 Oct 2017 11:16:44 +0300

Thanks for your response, Qin.

> [Qin]: Yes, there are implementations, something broken in RFC8049 needs to get right.

Cool..

> Unlike RFC8049, RFC8049bis change "SP SHOULD honor" into "SP MUST honor”. 

OK

> We will see how to clarify this in the model. thanks.

Please do. I’m not sure the auth/encr distinction is as useful as it may appear initially. You often have to authenticate in order to encrypt. Another possible distinction might be whether you use cryptographic protection for routing protocol or payload traffic protection.

(It could be that when you say “authentication” or “encryption” you mean very specific things that I’m not understanding. Being more specific usually helps. I’m not suggesting you do describe all possible security options that might exist, but being precise would be useful.)

> “

IMHO, that is not particularly detailed, nor does it tell me useful things that I can do in my implementation or deployment.

Jari

---

From: "tom p." <[email-masked]>
Date: Thu, 26 Oct 2017 12:10:18 +0100

< see inline>
Tom Petch

----- Original Message -----
From: "Qin Wu" <[email-masked]>
Sent: Thursday, October 26, 2017 8:02 AM

> I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by the
IESG for the IETF Chair.  Please treat these comments just like any
other last call comments.
> Summary: I'm not an expert on YANG *at all*. And not an expert on the
topic in question either. And I had far too little time to spend on this
long document.
> But as far as the textual content of the document goes, it seems
reasonable. I have a difficulty in assessing how complete and
implementable this model is however. Are there implementations?
> I did enjoy the classification of Internet connectivity as a special
case of cloud service :-) You may be onto something.
> language in the document. Are there parts of the described model that
they SP is *not* required to honour? Other than the explicit strict
true/false settings? And in any case, sizeable networks are likely to
have issues that might require negotiation/human involvement.
>
> [Qin]: Explicit settings are covered by sub-section of section 6.6,
such as device constraint, Site Location constraint/parameter, access
type.
> I don't understand how 6.9.1 can say there is no authentication
support but then 6.9.2 (encryption) talks about authentication keys. I'd
suggest some rethinking or at least clarification might be needed here.
>
> [Qin]: Authentication provides you access to a resource like a
computer or a network. Encryption provides confidentiality and controls
whether an object can be read or not.

Qin

I do not see that usage as common in the IETF and I think that it
reflects a fundamental flaw in this model such that the I-D should not
go forward in its present form, except that the same flaw is present in
RFC8049:-(

Authentication is the process of establishing that a person or object is
who or what they claim to be, using e.g. pre-shared keys or
certificates, in an authentication protocol.

Authorisation is the process of granting rights, privileges, access and
such like to an authenticated identity.

Authorisation without authentication is meaningless, a fantasy of
security

Scanning the I-D, I think that the usage of authorisation and
authentication is mostly correct.  As the I-D points it, there is no
support in the standard model for authentication.  Where the I-D is
wrong, perhaps dangerously so, is in the Security Considerations where
it says that because NETCONF may have used TLS or SSH to establish the
connection, and the NETCONF Access Control may be used to control
authorisation, then somehow this is secure.

You haven't a clue what identity has been authenticated and whether or
not they should be authorised to join a VPN.  This is a common problem
with applications running over a secure transport, the transport may
have autheticated an identity but how do you get that identity up to the
application for the application to verify that the identity really is
ok?  Channel Binding is one answer but rarely used.

Tom Petch

> Both Authentication and Encryption are site level parameters and
applicable to site connection. Pre-share key as encryption parameter can
be used, e.g., for routing protocol authentication.
> But pre-share key parameter is not authentication parameter, one
example I have for authentication parameter is authentication algorithm
which is not specified in the model,
> In the security considerations, I would note that if these models are
used not merely for creation of networks, but also their modification,
the consequences of inadvertent or malicious modifications can severe
and network wide. Perhaps that could be discussed.
>
> [Qin]:Security consideration section has already considered both
creation of networks and but also their modification, see the text in

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 26 Oct 2017 12:59:22 +0100

Top-posting 'cos I'm lazy.

We need to be careful to not confuse two aspects of security in this model.
One is security in the use of the model: who can read and write to the operator, whether the data is protected in transit, etc.
The other is security within the VPN that is modelled: how sites secure their access to the VPN, how VPN data is protected.

The former is handled by the protocol used to exchange the model. We assume Netconf, and that comes with a variety of security features.
The latter is about what VPN (or VPN site) behaviour is configured.

All that said, the points about authentication and authorisation are well made. Authorisation based on unauthenticated identity is not strong security (basically equates to "guess a valid user name").

A

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of tom p.
> Sent: 26 October 2017 12:10
> To: Qin Wu; Jari Arkko; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Genart last call review of draft-wu-l3sm-rfc8049bis-07
> 
> < see inline>
> Tom Petch
> 
>