[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    RE: Genart last call review of draft-wu-l3sm-rfc8049bis-07
From:       Qin Wu <bill.wu () huawei ! com>
Date:       2017-10-26 14:42:13
Message-ID: B8F9A780D330094D99AF023C5877DABA9AC18CCE () nkgeml513-mbx ! china ! huawei ! com
[Download RAW message or body]

This is exactly what I like to clarify in the previous email, both authentication and \
key parameters defined in service model are only applicable to site connection(e.g., \
CE-PE connectivity) rather than secure channel or connection setup between customer \
and the management system (Let's say orchestrator). 

So "authentication" described in the 3rd paragraph of section 6.9.2 is actually \
referred to message authentication that is applied to site-connection, one example of \
such authentication could be routing protocol authentication, Authentication \
parameter could be authentication type, authentication method, authentication \
algorithm. using PSK within encryption of service model, in my understanding could be \
used to prove identity arranged between CE and PE for CE-PE connectivity. Note that \
for routing protocols, only key and authentication are discussed, e.g., some of work \
                produced in KARP.
-----邮件原件-----
发件人: Adrian Farrel [mailto:adrian@olddog.co.uk] 
发送时间: 2017年10月26日 19:59
收件人: 'tom p.' <daedulus@btconnect.com>; Qin Wu <bill.wu@huawei.com>; 'Jari \
Arkko' <jari.arkko@piuha.net>; gen-art@ietf.org 抄送: ietf@ietf.org; \
draft-wu-l3sm-rfc8049bis.all@ietf.org 主题: RE: Genart last call review of \
draft-wu-l3sm-rfc8049bis-07

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:ietf-bounces@ietf.org] On Behalf Of tom p.
> Sent: 26 October 2017 12:10
> To: Qin Wu; Jari Arkko; gen-art@ietf.org
> Cc: ietf@ietf.org; draft-wu-l3sm-rfc8049bis.all@ietf.org
> Subject: Re: Genart last call review of draft-wu-l3sm-rfc8049bis-07
> 
> < see inline>
> Tom Petch
> 
> 
> ----- Original Message -----
> From: "Qin Wu" <bill.wu@huawei.com>
> Sent: Thursday, October 26, 2017 8:02 AM
> 
> > -----邮件原件-----
> > 发件人: Jari Arkko [mailto:jari.arkko@piuha.net]
> > 发送时间: 2017年10月26日 4:53
> > 
> > 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?
> > 
> > [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.
> 
> 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,
> > 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:
> > 
> > Section 6.12.2. s/fragmented/fragment it/
> > 
> > [Qin]: Will fix this, thanks.
> > 


[prev in list] [next in list] [prev in thread] [next in thread]