Re: [secdir] [Netconf] FW: secdir review of draft-ietf-netconf-monitoring

["Ersue, Mehmet (NSN - DE/Munich)" <[e-mail]>]

Dear Alan,

I agree that the security consideration section should inform on the use
of secure transport with NETCONF.
We addressed this issue in the new version of the security
considerations template (see attached mail).

As defined in RFC 4741 NETCONF protocol has to be used on top of a
secure transport and a NETCONF implementation MUST support SSH as secure
transport.

I hope this addresses your request.

Cheers,
Mehmet
 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of ext Romascanu, 
> Dan (Dan)
> Sent: Sunday, June 13, 2010 3:44 PM
> To: [e-mail]
> Subject: [Netconf] FW: secdir review of draft-ietf-netconf-monitoring
> 
> 
>  
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of
> Alan DeKok
> Sent: Friday, June 11, 2010 11:01 AM
> To: [e-mail]; IESG IESG;
> [e-mail]
> Subject: secdir review of draft-ietf-netconf-monitoring
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed 
> by the IESG.
> These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these
> comments just like any other last call comments.
> 
>  The document defines a data model for netconf monitoring.  
> The security
> considerations section says in part:
> 
>    Some of the readable data nodes in this YANG module may be
>    considered sensitive or vulnerable in some network environments.
>    It is thus important to control read access (e.g. via get,
>    get-config or notification) to these data nodes.
> 
>   What is unclear from the document is whether or not the 
> data is secure
> *after* access is gained.  i.e. is there a secure transport layer?
> Should one be used?  If not, why?
> 
>   A statement about privacy and security, with a reference to an
> existing netconf document would be good.
> _______________________________________________
> Netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
> 

--- Begin Message ---

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Bert (IETF) Wijnen
Sent: Monday, June 14, 2010 11:16 AM
To: netmod Working Group
Subject: [netmod] [Fwd: 5th draft for yang module security
considerations]

Since the 4th draft, we have been informed of one typo that is fixed in
this revision.

Further, the security ADs wanted something added about secure transport
of the data, and the secdir review of the netconf-monitoring draft also
had questions about that. As a result, Juergen Schoenwaelder has
suggested to add some text about that.

The resulting text is now as below.

Bert

--- draft 5 for tang module security considerations:

    Each specification that defines one or more YANG
    modules MUST contain a section that discusses
    security considerations relevant to those modules.
    This section MUST be patterned after the latest
    approved template (available at [ed: URL TBD]).

    In particular, writable data nodes that could
    be especially disruptive if abused MUST be
    explicitly listed by name and the associated
    security risks MUST be spelled out.

    Similarly, readable data nodes that contain
    especially sensitive information or that raise
    significant privacy concerns MUST be explicitly
    listed by name and the reasons for the
    sensitivity/privacy concerns MUST be explained.

    Further, if new RPC operations have been defined,
    then the security considerations of each new
    RPC operation MUST be explained.

X. Security Considerations

The YANG module defined in this memo is designed to be accessed via the
NETCONF protocol [RFC4741]. The lowest NETCONF layer is the secure
transport layer and the mandatory to implement secure transport is SSH
[RFC4742].

-- if you have any writeable data nodes (those are all the
-- "config true" nodes, and remember, that is the default)
-- describe their specific sensitivity or vulnerability.

There are a number of data nodes defined in this YANG module which are
writable/creatable/deletable (i.e. config true, which is the default).
These data nodes may be considered sensitive or vulnerable in some
network environments.  Write operations (e.g. edit-config) to these data
nodes without proper protection can have a negative effect on network
operations.  These are the subtrees and data nodes and their
sensitivity/vulnerability:

  <list subtrees and data nodes and state why they are sensitive>

-- for all YANG modules you must evaluate whether any readable data
-- nodes (those are all the "config false" nodes, but also all other
-- nodes, because they can also be read via operations like get or
-- get-config) are sensitive or vulnerable (for instance, if they
-- might reveal customer information or violate personal privacy
-- laws such as those of the European Union if exposed to
-- unauthorized parties)

Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments.
It is thus important to control read access (e.g. via get, get-config or
notification) to these data nodes.  These are the subtrees and data
nodes and their sensitivity/vulnerability:

  <list subtrees and data nodes and state why they are sensitive>

-- if your YANG module has defined any rpc operations
-- describe their specific sensitivity or vulnerability.

Some of the RPC operations in this YANG module may be considered
sensitive or vulnerable in some network environments.  It is thus
important to control access to these operations.  These are the
operations and their sensitivity/vulnerability:

  <list RPC operations and state why they are sensitive>


_______________________________________________
netmod mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod

--- End Message ---