Re: [I2nsf] [Netconf] What kind of mechanisms have NETCONF specified to prevent illegitimate"Clients" or "Agent"?

[Kent Watsen <[e-mail]>]

I think that this issue is shared by *all* remote management mechanisms - not VNFs, but knowing that the system hasn’t been compromised.   NETCONF/RESTCONF rely on server authentication, using the server’s presented SSH host key or TLS server certificate.  Only recently with draft-ietf-netconf-zerotouch is there a push to start using IDevID certificates that are bound to a TPM, but this only goes to show that the secure-tunnel termination point has access to the TPM and nothing else.   That said, if the platform is certified to implement Secure Boot, which is a necessary precondition to supporting remote attestation, it seems that client can already be satisfied that it is communicating to an uncompromised system without need for remote attestation.   However, Secure Boot only verifies that the platform is executing the right software stack, but does nothing to ensure the configuration files and the like haven’t been tweaked - this is where Trusted Boot (a.k.a. Measured Boot) comes in.  But if the platform is known to be good (via Secure Boot), then any tweaking would be the result of unauthorized access (e.g., someone stole your login credentials), which needs a different solution.  Sure, Trusted Boot can tell you something’s unexpected changed, but not what, when, who, etc..  Anyways, I think this is all well and good, but the issue has a scope that is beyond NETCONF.

Related to VNFs in particular, my understanding as of late last year is that hypervisors still lacked support for Secure Boot.  It seems like this draft might be getting ahead of what’s possible.

PS: I’m not subscribed to the i2nsf list.

Kent



From: Netconf <[e-mail]<mailto:[e-mail]>> on behalf of Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Date: Monday, February 8, 2016 at 5:23 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [Netconf] What kind of mechanisms have NETCONF specified to prevent illegitimate"Clients" or "Agent"?

NETCONF   participants,

Your Chair Mehmet suggested sending the following questions to the list.

I2NSF has a draft on remote attestation (https://datatracker.ietf.org/doc/draft-pastor-i2nsf-vnsf-attestation/ ) which documented the following security threats between Client and Controller. I  think those issues also face I2RS and NETCONF. Has NETCONF specified some mechanisms to address those issues?

o An unknown/unauthorized user can try to impersonate another user
that can legitimately access virtualized NSF services (or Network Services). This
attack may lead to accessing the policies and applications of the
attacked user or to generate network traffic outside a the
security functions with a falsified identity.

o An authorized user may misuse assigned privileges to alter the
network traffic processing of other users in the virtualization
platform. This can become especially serious when such a user has
administration privileges granted by the virtualization provider,
the ISP or the local network operator.

o A user may try to install malformed elements (policy or
application), trying to directly take the control of a NSF or
virtualization platform (for example by exploiting a vulnerability
on one of the functions or may try to intercept or modify the
traffic of other users in the same platform.

o A malicious virtualization provider can modify the software
running on it (the operating system or a concrete vNSF) to alter
the behaviour of the latter. This event has a high impact on all
users accessing vNSFs as the virtualization provider has the
highest level of privilege on the software in execution.

o A user with physical access to the virtualization platform can
modify the behavior of hardware components, or the components
themselves. Furthermore, it can access a serial console (most
devices offer this interface for maintenance reasons) to access
the NSF software with the same level of privilege of the
virtualization provider



Thanks, Linda