Subject: [Netconf] Pre-13 Notification (take 2)

From: "Sharon Chisholm" <[email-masked]>
Date: Thu, 29 May 2008 13:01:50 -0400

Hi

Attached is the update to the Notification draft that I will be posting
later today.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada
Hi

Attached is the update to the Notification draft that I will be posting
later today.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Thu, 29 May 2008 10:19:36 -0700

> Attached is the update to the Notification draft that I will be posting

The following new paragraph is a bit confusing:

 *  Secure execution means ensuring that a secure transport is used as
   well as ensuring that the user has sufficient authorization to
   perform the function they are requesting against the specific piece
   of NETCONF content involved.  When a <get> is received against the
   content defined in this memo, clients should only be able to view the
   content for which they have sufficient privileges.  A create <create-
   subscription> operation can be considered like a deferred <get>, and
   the content that different users can access may vary.  This different
   access is reflected in the <notification> that different users are
   able to subscribe to.*

I suggest:

line 3:
s/piece/subset/

line 4:
s/against/which refers to/

I don't really understand the normative implications of the last 2 
sentences.
What do they mean for an implementor and for an operator?

(note email address change from [email-masked] -- that address is 
retired ;-)

> Sharon Chisholm

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 29 May 2008 10:19:36 -0700

I suggest:

line 3:
s/piece/subset/

line 4:

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 30 May 2008 08:38:07 -0400

Hi

I made those two changes in the version I posted last night.

I don't think there are any normative implications of the last two
sentences. It was a way of describing things that someone used (I think
it was Charlie), which seemed to be helpful in the DISCUSS discussion so
I included it in the draft.

Sharon  

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, May 29, 2008 1:20 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [Netconf] Pre-13 Notification (take 2)

Sharon Chisholm wrote:
> Hi
>
> Attached is the update to the Notification draft that I will be 
> posting later today.
>
>   

 *  Secure execution means ensuring that a secure transport is used as
   well as ensuring that the user has sufficient authorization to
   perform the function they are requesting against the specific piece
   of NETCONF content involved.  When a <get> is received against the
   content defined in this memo, clients should only be able to view the
   content for which they have sufficient privileges.  A create <create-
   subscription> operation can be considered like a deferred <get>, and
   the content that different users can access may vary.  This different
   access is reflected From [email-masked]  Fri May 30 05:39:24 2008
Content-class: urn:content-classes:message
Date: Fri, 30 May 2008 08:38:07 -0400
From: "Sharon Chisholm" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Pre-13 Notification (take 2)
Sender: [email-masked]

Hi

I made those two changes in the version I posted last night.

I don't think there are any normative implications of the last two
sentences. It was a way of describing things that someone used (I think
it was Charlie), which seemed to be helpful in the DISCUSS discussion so
I included it in the draft.

Sharon  

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Thursday, May 29, 2008 1:20 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [Netconf] Pre-13 Notification (take 2)

Sharon Chisholm wrote:
> Hi
>
> Attached is the update to the Notification draft that I will be 
> posting later today.
>
>   

   access is reflected in thein the <notification> that different users are
   able to subscribe to.*

I suggest:

line 3:
s/piece/subset/

line 4:

Andy

 <notification> that different users are
   able to subscribe to.*

I suggest:

line 3:
s/piece/subset/

line 4:

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 May 2008 07:57:33 -0700

> I included it in the draft.

I read it 3 more times.
I think I see the intent.
A <get> will return the subset of <running/>
that the user is authorized to view.   A <create-subscription>
will likewise leave out <notification> elements that the user
is not authorized to view.

NETCONF is silent wrt/ when an access-denied error is returned.
When does the agent skip over the node vs. return an error?
Is it when the agent determines the filter is so specific
there cannot be any other possible instance match?  Can the
implementation always detect this condition?

(Some of the reasons I prefer the standard to remain silent
on access control until a standard ACM exists.)

Andy

> Cc: netFrom [email-masked]  Fri May 30 07:58:23 2008
Date: Fri, 30 May 2008 07:57:33 -0700
From: Andy Bierman <[email-masked]>
To: Sharon Chisholm <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Pre-13 Notification (take 2)
Sender: [email-masked]

> I included it in the draft.

I read it 3 more times.
I think I see the intent.
A <get> will return the subset of <running/>
that the user is authorized to view.   A <create-subscription>
will likewise leave out <notification> elements that the user
is not authorized to view.

NETCONF is silent wrt/ when an access-denied error is returned.
When does the agent skip over the node vs. return an error?
Is it when the agent determines the filter is so specific
there cannot be any other possible instance match?  Can the
implementation always detect this condition?

(Some of the reasons I prefer the standard to remain silent
on access control until a standard ACM exists.)

Andy

> [email-masked]

c: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 May 2008 08:14:52 -0700

> I included it in the draft.

The text is also confusing me because access control for <get>
and <notification> are not the same at all.  A <get> response
will only exclude the unauthorized nested elements, and return
any other content the user is authorized to view.

A <notification> must be buffered by the agent so that if any
unauthorized sub-nodes are encountered, the entire <notification>
is considered unauthorized (and dropped for that session).

This makes some assumptions about how/why the
internal ACM is behaving in certain ways.  Why is is OK
for a <get> to drop only the unauthorized content, but
it is not OK for a <notification> to do the same thing,
even for the exact same subset of data?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 May 2008 08:14:52 -0700

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 30 May 2008 14:36:12 -0400

> even for the exact same subset of data?

I agree with this concern about embedded assumptions.

In SNMPv3, if a principal is not allowed access to all the varbinds in
the notification, the notification gets dropped. This makes sense in
SNMP because we define the varbinds that must be in the notification
(although even if an appended varbind is not authorized the whole
thing gets dropped). 

I am not sure this must-drop-behavior should be a requirement for the
**protocol** definition of Netconf notifications, especially if
Netconf notifications might carry data from SNMP or syslog. This
should probably be a function of the access control model(s), not the
protocol.

--
There may be a case for arguing that notifications are different than
<gets>. If a system reports on an event, specifying certain related
information, and the subscription only allows the operator to see a
subset of the information, might that be misleading to the operator?
In SNMPv1, we had to deal with implementations that, when they didn't
support a counter, returned a zero value. This was misleading because,
even if the underlying functionality was operating, and the events
that were to be counted (e.g., packets out) occurred, the SNMP
counters still said '0'. We want to avoid misleading the operator. 

Would reporting only part of the data, and not reporting exceptions
for the missing data, be worse than reporting no data for some events?
Would reporting exceptions for the missing data be a problem because
it gives an attacker information about what a user is not authorized
to see?

Maybe the data model for notification definitions should be able to
specify whether 1) all info must be authorized or do not send, or 2)
unauthorized data should have an exception reported, or 3) partial
data is acceptable.

I think an access control model is a better place than either the
protocol or the data model to make such a determination. I can
envision wanting to let the helpdesk (support level 1) receive an
alert with only partial information to make him aware that an event
occurred, while a level 2 support person can subscribe for the same
notification, and get more (potentially sensitive) information in the
notification he receives. 

But I am not an operator, and operators may be fine with an
all-or-nothing decision.

dbh

---

From: "David B Harrington" <[email-masked]>
Date: Fri, 30 May 2008 14:36:12 -0400

dbh

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 May 2008 12:30:26 -0700

David B Harrington wrote:
> I aFrom [email-masked]  Fri May 30 12:30:34 2008
Date: Fri, 30 May 2008 12:30:26 -0700
From: Andy Bierman <[email-masked]>
To: David B Harrington <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Pre-13 Notification (take 2)
Sender: [email-masked]

David B Harrington wrote:
> I am not m not sure this must-drop-behavior should be a requirement for the

I am also concerned about a MUST drop directive cast-in-stone,
without much thought about the overall access control model or
security use cases.

Clearly, the <get> method needs to work as currently defined.
NETCONF would be completely unusable if an operator had to
specify exact leafs to retrieve because access control on some
nested subtree causes normal <get> filters to be unusable.

Won't the all-or-nothing restriction cause similar problems
for operators wrt/ notification receiver applications?
Won't this force data model writers to create multiple
versions of any notification that includes some (but not all)
sensitive data?

SNMP is somewhat different because the varbinds are all leafs
and non-extensible.  NETCONF content can be complex, nested,
and include multiple namespaces.  The likelihood that a
complex structure sill have some optional (yet sensitive) data
is much higher. SNMP is UDP-based, and very few mandatory varbinds
are usually defined for a notification.  If implementors take
advantage of NETCONF's unlimited notification payload size,
this all-or-nothing restriction is going to become a DM design
factor.  This would be a serious protocol design flaw.

It should be up to the network administrator, not the protocol,
to decide how access control should handle notification content
(and all other content).

At a minimum, the draft should explain in detail why the
entire notification must be dropped but no access control
restrictions for other types of NETCONF operations exist at all.
Explain the access control model in detail or take out the
ad-hoc bits and pieces.

Andy

sure this must-drop-behavior should be a requirement for the
> should probably be a function of the access control model(s), not the

I am also concerned about a MUST drop directive cast-in-stone,
without much thought about the overall access control model or
security use cases.

Clearly, the <get> method needs to work as currently defined.
NETCONF would be completely unusable if an operator had to
specify exact leafs to retrieve because access control on some
nested subtree causes normal <get> filters to be unusable.

Won't the all-or-nothing restriction cause similar problems
for operators wrt/ notification receiver applications?
Won't this force data model writers to create multiple
versions of any notification that includes some (but not all)
sensitive data?

SNMP is somewhat different because the varbinds are all leafs
and non-extensible.  NETCONF content can be complex, nested,
and include multiple namespaces.  The likelihood that a
complex structure sill have some optional (yet sensitive) data
is much higher. SNMP is UDP-based, and very few mandatory varbinds
are usually defined for a notification.  If implementors take
advantage of NETCONF's unlimited notification payload size,
this all-or-nothing restriction is going to become a DM design
factor.  This would be a serious protocol design flaw.

It should be up to the network administrator, not the protocol,
to decide how access control should handle notification content
(and all other content).

At a minimum, the draft should explain in detail why the
entire notification must be dropped but no access control
restrictions for other types of NETCONF operations exist at all.
Explain the access control model in detail or take out the
ad-hoc bits and pieces.

Andy