Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId uniqueness proposed resolution

From: "Mark Scott" <[email-masked]>
Date: Tue, 19 May 2009 13:04:01 -0400

Hello,

After a series of ML discussions the following revision was reached for
the sessionId uniqueness issue:

---

session

       |_sessionId (key)

       |_transport

       |_protocol

       |_username

       |_sourceHost

       |_loginTime

sessionId (type: SessionId)

    Unique NETCONF identifier for the session, used for all supported
operations (e.g. monitoring, session kill, lock release) regardless of
protocol.

    MUST be a unique non-0 value for all sessions reported.  SessionId=0
will not be reported in the session table.

    For purposes of NETCONF management all sessions are one of:

       Known session:  any session which can be managed by the NETCONF
server SHOULD be reported in this table and MUST map to a unique
sessionId as described above

       Unknown session:  such sessions are not managed by the NETCONF
server and all map to sessionId=0.  They MUST be excluded from the
session table as a result.  SessionId=0 will continue to be reported in
error messages with sessionId=0 per existing 4741 definition.

---

This reflects consensus in the ML discussion.  In particular it
addresses concerns with 4741 backwards compatibility while providing the
ability to uniquely manage non-NETCONF sessions if an implementation
chooses to do so.

Thank you to all who participated in the discussion.   If I missed any
inputs/considerations please feel free to raise them again along with
any alternatives to be considered.

The monitoring draft will be updated accordingly.

Mark

From: Scott, Mark (CAR:2N00) 
Sent: Thursday, May 07, 2009 1:25 PM
To: [email-masked]; 'Washam Fan'; 'Martin Bjorklund'
Cc: [email-masked]
Subject: [NETCONF] Monitoring draft: sessionId uniqueness proposed
resolution

Hello,

In response to ML discussion for open item 'sessionID uniqueness' in the
NETCONF Monitoring draft:
http://tools.ietf.org/html/draft-ietf-netconf-monitoring-04

Please review the issue and in particular the 'suggested resolution'
below and reply with your agreement or suggestion for alternative in an
attempt to reach WG consensus on this issue.

ISSUE:  Key definition for ManagementSessionInfo

------------------------------------------------

Current draft assumes sessionId will be unique for both NETCONF and
non-NETCONF sessions reported via monitoring data.

SessionId uniqueness holds for NETCONF session.  An issues arises
applying same assumption to non-NETCONF sessions:

We have expressed opinion that sessionId uniqueness should also be
mandated for all non-NETCONF entries included in the monitoring data
since other protocols have similar use cases where a unique Id is
required and/or a mapping scheme needs to be provided if a NETCONF
implementation wants to manage non-NETCONF sessions.  In particular if
an implementation wants to extend support for an operation such as
<kill-session> to non-NETCONF sessions.

However there is a side discussion underway on whether or not 4741
intended for sessionId=0 to be mandatory for non-NETCONF sessions in all
cases.  Have asked for clarification in 4741bis.  Until that is resolved
we cannot mandate non-0 sessionId values in the monitoring data and
don't want to delay monitoring on that decision.

Suggestions to use a tuple of existing fields were considered.  In
particular the use of sessionId, protocol and sourceHost but this
doesn't guarantee uniqueness either.  More fields (like loginTime) could
be included but may lead to an increasing complex key as more protocols
(and more issues of uniqueness) are monitored.

It is agreed we do want to keep the ability to report non-NETCONF
sessions so a method to ensure uniqueness for non-NETCONF entries needs
to be added.

SUGGESTED RESOLUTION:  Add 'nativeSessionId', quality 'netconfSessionId'
and extend key

------------------------------------------------------------------------
----------------

Per Andy's suggestion, refine ManagementSessionInfo, changing section
2.1.4 and model:

session

       |_netconfSessionId (key)

 |_associatedSession (key)

       |_transport

       |_protocol

       |_username

       |_sourceHost

       |_loginTime

netconfSessionId (type: SessionId)

     NETCONF identifier for the session.

     This is the unique sessionId used for all NETCONF operations.

     This is not guaranteed to be unique for non-NETCONF sessions.

associatedSession (type: string)

     Identifer used within NETCONF to associate to the native session in
non-NETCONF protocol.

     For NETCONF sessions the value MUST match netconfSessionid.

     For non-NETCONF sessions, when a native session identifier is
available this value should be the equal (string equivalent).  It is
expected this value will be unique when available for each reported
particular protocol type.

     For non-NETCONF sessions, when a native session identifier is not
available (e.g. sessionless protocol) and the NETCONF implementation
chooses to report the sessions it MUST provide an associated session Id
value.      

     The key for the ManagementSessionInfo (netconfSessionId +
associatedSessionId) MUST be unique in all cases.

     xs:string is chosen to allow mapping to multiple native datatypes.

cheers,

mark

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 19 May 2009 21:20:44 +0200

Dear NETCONF WG,
 
we assume we can see this now as a WG consensus 
and close this issue.
 
If anybody disagrees please state it so _and_ provide 
a better solution (for the sake of progress I hope this 
is not the case).

Cheers,
Mehmet 

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of ext Mark Scott
	Sent: Tuesday, May 19, 2009 7:04 PM
	To: Mark Scott; [email-masked]; Washam Fan; Martin
Bjorklund
	Cc: [email-masked]
	Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId
uniquenessproposed resolution

	Hello,

	After a series of ML discussions the following revision was
reached for the sessionId uniqueness issue:

	---

	session

	       |_sessionId (key)

	       |_transport

	       |_protocol

	       |_username

	       |_sourceHost

	       |_loginTime

	    Unique NETCONF identifier for the session, used for all
supported operations (e.g. monitoring, session kill, lock release)
regardless of protocol.

	    MUST be a unique non-0 value for all sessions reported.
SessionId=0 will not be reported in the session table.

	       Known session:  any session which can be managed by the
NETCONF server SHOULD be reported in this table and MUST map to a unique
sessionId as described above

	       Unknown session:  such sessions are not managed by the
NETCONF server and all map to sessionId=0.  They MUST be excluded from
the session table as a result.  SessionId=0 will continue to be reported
in error messages with sessionId=0 per existing 4741 definition.

	---

	Thank you to all who participated in the discussion.   If I
missed any inputs/considerations please feel free to raise them again
along with any alternatives to be considered.

	Mark

	From: Scott, Mark (CAR:2N00) 
	Sent: Thursday, May 07, 2009 1:25 PM
	To: [email-masked]; 'Washam Fan'; 'Martin Bjorklund'
	Cc: [email-masked]
	Subject: [NETCONF] Monitoring draft: sessionId uniqueness
proposed resolution

	Hello,

	In response to ML discussion for open item 'sessionID
uniqueness' in the NETCONF Monitoring draft:
http://tools.ietf.org/html/draft-ietf-netconf-monitoring-04

	Please review the issue and in particular the 'suggested
resolution' below and reply with your agreement or suggestion for
alternative in an attempt to reach WG consensus on this issue.

	Current draft assumes sessionId will be unique for both NETCONF
and non-NETCONF sessions reported via monitoring data.

	SessionId uniqueness holds for NETCONF session.  An issues
arises applying same assumption to non-NETCONF sessions:

	We have expressed opinion that sessionId uniqueness should also
be mandated for all non-NETCONF entries included in the monitoring data
since other protocols have similar use cases where a unique Id is
required and/or a mapping scheme needs to be provided if a NETCONF
implementation wants to manage non-NETCONF sessions.  In particular if
an implementation wants to extend support for an operation such as
<kill-session> to non-NETCONF sessions.

	However there is a side discussion underway on whether or not
4741 intended for sessionId=0 to be mandatory for non-NETCONF sessions
in all cases.  Have asked for clarification in 4741bis.  Until that is
resolved we cannot mandate non-0 sessionId values in the monitoring data
and don't want to delay monitoring on that decision.

	Suggestions to use a tuple of existing fields were considered.
In particular the use of sessionId, protocol and sourceHost but this
doesn't guarantee uniqueness either.  More fields (like loginTime) could
be included but may lead to an increasing complex key as more protocols
(and more issues of uniqueness) are monitored.

	It is agreed we do want to keep the ability to report
non-NETCONF sessions so a method to ensure uniqueness for non-NETCONF
entries needs to be added.

	SUGGESTED RESOLUTION:  Add 'nativeSessionId', quality
'netconfSessionId' and extend key

	Per Andy's suggestion, refine ManagementSessionInfo, changing
section 2.1.4 and model:

	session

	       |_netconfSessionId (key)

	       |_transport

	       |_protocol

	       |_username

	       |_sourceHost

	       |_loginTime

	     This is the unique sessionId used for all NETCONF
operations.

	     This is not guaranteed to be unique for non-NETCONF
sessions.

	     Identifer used within NETCONF to associate to the native
session in non-NETCONF protocol.

	     For non-NETCONF sessions, when a native session identifier
is available this value should be the equal (string equivalent).  It is
expected this value will be unique when available for each reported
particular protocol type.

	     For non-NETCONF sessions, when a native session identifier
is not available (e.g. sessionless protocol) and the NETCONF
implementation chooses to report the sessions it MUST provide an
associated session Id value.      

	     xs:string is chosen to allow mapping to multiple native
datatypes.

	cheers,

	mark

---

From: "David B Harrington" <[email-masked]>
Date: Thu, 21 May 2009 08:40:07 -0400

Hi,

I have not been able to actively follow these discussions. I have a
concern about netconf actively modifying locks of other NM interfaces.
Monitoring makes sense for troubleshooting purposes; monitoring could
raise security issues of disclosure, but I think that risk is fairly
minimal. Modifying locks across NM systems raises serious security
concerns.

SNMP is designed to be extensible. It can have multiple PDU types,
multiple access control models, etc. Netconf does not understand SNMP
access controls, such as VACM. If a new PDU type or a new access
control were added to an SNMP implementation, netconf would not
necesarily know about the details. That means that a person with
netconf rights could modify SNMP locks, even if they were not
authorized to set or release SNMP locks using SNMP. Or a person with
netconf rights could modify CLI locks, even if they were not
authorized to set or release CLI locks using CLI.

In the same way, an SNMP user should not be allowed to set or release
netconf locks. SNMP knows nothing about netconf access controls, so
the SNMP user might not have the authority to set or release such
locks via netconf. Allowing one NM system to ignore or alter the locks
of another NM system is BAD! This could cause misconfigurations and/or
security vulnerabilities.

The only time this should be allowed is if an administrator realizes
that a lock must be overridden, and uses "root" access (e.g., via a
CLI) to forcibly remove a lock for a different NM interface.

dbh

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mark Scott
Sent: Tuesday, May 19, 2009 1:04 PM
To: Mark Scott; [email-masked]; Washam Fan; Martin Bjorklund
Cc: [email-masked]
Subject: Re: [Netconf] [NETCONF] Monitoring draft: sessionId
uniquenessproposed resolution

Hello,

After a series of ML discussions the following revision was reached
for the sessionId uniqueness issue:

---

session

       |_sessionId (key)

       |_transport

       |_protocol

       |_username

       |_sourceHost

       |_loginTime

       Unknown session:  such sessions are not managed by the NETCONF
server and all map to sessionId=0.  They MUST be excluded from the
session table as a result.  SessionId=0 will continue to be reported
in error messages with sessionId=0 per existing 4741 definition.

---

This reflects consensus in the ML discussion.  In particular it
addresses concerns with 4741 backwards compatibility while providing
the ability to uniquely manage non-NETCONF sessions if an
implementation chooses to do so.

Mark

Hello,

In response to ML discussion for open item 'sessionID uniqueness' in
the NETCONF Monitoring draft:
http://tools.ietf.org/html/draft-ietf-netconf-monitoring-04

Please review the issue and in particular the 'suggested resolution'
below and reply with your agreement or suggestion for alternative in
an attempt to reach WG consensus on this issue.

However there is a side discussion underway on whether or not 4741
intended for sessionId=0 to be mandatory for non-NETCONF sessions in
all cases.  Have asked for clarification in 4741bis.  Until that is
resolved we cannot mandate non-0 sessionId values in the monitoring
data and don't want to delay monitoring on that decision.

Suggestions to use a tuple of existing fields were considered.  In
particular the use of sessionId, protocol and sourceHost but this
doesn't guarantee uniqueness either.  More fields (like loginTime)
could be included but may lead to an increasing complex key as more
protocols (and more issues of uniqueness) are monitored.

It is agreed we do want to keep the ability to report non-NETCONF
sessions so a method to ensure uniqueness for non-NETCONF entries
needs to be added.

----------------------------------------------------------------------
------------------

session

       |_netconfSessionId (key)

       |_transport

       |_protocol

       |_username

       |_sourceHost

       |_loginTime

     Identifer used within NETCONF to associate to the native session
in non-NETCONF protocol.

     For non-NETCONF sessions, when a native session identifier is not
available (e.g. sessionless protocol) and the NETCONF implementation
chooses to report the sessions it MUST provide an associated session
Id value.      

 

cheers,

mark