Re: [L3sm] Next Step of RFC8049

[Qin Wu <[e-mail]>]

Sort of,:-),how about add a few texts in security section to discuss security risk of disclosing customer name, hope this will address your comment . Thanks!

Sent from HUAWEI AnyOffice
发件人： daviball
收件人： Qin Wu; Ogaki, Kenichi; stephane.litkowski; l3sm;
主题： Re: [L3sm] Next Step of RFC8049
时间： 2017-06-28 17:36:30


Hi Qin,

You have cycled this round to the start of the thread. :)  There must be some out-of-band way of identifying and authenticating the customer from whom the request is being received, otherwise customer foo could request a service for customer bar just by filling in a different value for this leaf in the model!  You are right that the VPN service is a list, but a given customer should only ever be able to use the model to access their own services, they should not be able to access services for any other customer.

    David

On 28/06/2017 03:37, Qin Wu wrote:
David:
A few thoughts and comments below.
发件人: David Ball [mailto:[e-mail]]
发送时间: 2017年6月27日 19:53
收件人: Ogaki, Kenichi; [e-mail]<mailto:[e-mail]>; Qin Wu; [e-mail]<mailto:[e-mail]>
主题: Re: [L3sm] Next Step of RFC8049


Thanks Kenichi - there is one of your answers that I'm still confused about, see below:

On 26/06/2017 04:23, Ogaki, Kenichi wrote:

4.   Under the VPN service, there is a leaf for the customer name.  If the model is supposed to represent the request from a customer to the SP, I would have thought the customer name would be known out-of-band, e.g. from the AAA for the request?  It would be bad if one customer could request things for another customer by filling in a different customer name in the model!



     [KO] A customer can only access the model instance of that customer. Please see section 10.





[DB] Yes exactly - if a customer can only access their own instance of the model, why does the customer name need to be specified within the model?  You already know you are dealing with that customer's instance of the model.  It seems like the customer-name leaf is unnecessary?



[KO] As common usecases, a VPN service is provided not only by Tier 1 providers, but also by Tier 2 providers or IT divisions of enterprises in order to provide their own end users by using a Tier 1 provider's VPN service. Such customers usually requires this kind of attributes for their management purposes.

[DB2]

I didn't really follow this, sorry.  The module contains the

information that needs to be sent from the customer to the SP, right?

If the customer using the model (i.e. the Tier2 in your above example)

needs to track which of their own customers the service is for, that's

something that's internal to them, isn't it?

[KO3] Yes, that's internal to them, but they (i.e. our customers) really request and are currently using this. Then, we need to model this.

Perhaps I am misunderstanding the scenario.

If I understand correctly, the case is where the yang is being used between a Tier2 provider (lets call them T2-telecom) and Tier1 provider (lets call them T1-networks).  In other words, from the perspective of the RFC and the yang module, T1-networks is the SP and T2-telecom is the customer.

T2-telecom has their own customers call them (foo-bank, bar-supermarket and baz-advertising).  Whenever T2-telecom orders a new VPN from T1-networks, they want to record, in their internal systems, which of their end customers the new VPN is for.  Of course there is probably a lot of other information they want to store in their internal systems about their customers, such as contact info, billing and invoicing info, trouble tickets, etc.

What I don't understand is why T2-telecom would want to send the name of their end-customer (foo-bank, bar-supermarket or baz-advertising) to T1-networks as part of the netconf request when they order a new VPN.  What is T1-networks going to do with this information?

[Qin]:
1.With customer name,you could use it as a key to lookup detailed customer information such as contact info, billing info if needed.
2. You forget that VPN service is defined as a list of VPN Service. That is to say different VPN service could belong to different customer,
Adding customer name, we could know which customer has which VPN service.
3. customer name is just defined as an optional parameter. You don’t need to specify it in the case you don’t need it.
    David



--

David Ball

<[e-mail]><mailto:[e-mail]>


--
David Ball
<[e-mail]><mailto:[e-mail]>