Subject: [Netconf] FW: [secdir] secdir review of draft-ietf-netconf-notification-12

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Thu, 27 Mar 2008 11:05:36 +0100

Here are Sharon's responses to review comments from
the security directorate.

Bert Wijnen

-----Original Message-----
From: Blake Ramsdell [mailto:[email-masked]]
Sent: Sunday, March 23, 2008 8:18 PM
To: [email-masked]; [email-masked]; Chisholm, Sharon (CAR:ZZ00);
[email-masked]
Subject: Re: [secdir] secdir review of
draft-ietf-netconf-notification-12

On Tue, Mar 04, 2008 at 07:47:43PM -0800, Blake Ramsdell wrote:
> * Is there a risk of sessions accumulating? That is, too many
>   create-subscription requests without termination?

The subscription terminates when the underlying NETCONF session goes
way. In order to accumulate subscriptions, you need to accumulate
NETCONF sessions. These may well be a finite resource, but the base
protocol provides a <kill-session> command to kill a particular session
from another session if there is an issue.

>
> * How important is the accuracy of the eventTime field for notification
nodes?
>   If you put in something that doesn't parse, or that's deliberately bad,
is
>   that a problem?
The eventTime field provides the time the event occurred within the
network element. If it was corrupted, the NETCONFrom [email-masked]  Thu Mar 27 03:08:00 2008
From: "Bert Wijnen - IETF" <[email-masked]>
To: "Netconf" <[email-masked]>
Date: Thu, 27 Mar 2008 11:05:36 +0100
Importance: Normal
Subject: [Netconf] FW: [secdir] secdir review of
	draft-ietf-netconf-notification-12
Sender: [email-masked]

Here are Sharon's responses to review comments from
the security directorate.

Bert Wijnen

-----Original Message-----
From: Blake Ramsdell [mailto:[email-masked]]
Sent: Sunday, March 23, 2008 8:18 PM
To: [email-masked]; [email-masked]; Chisholm, Sharon (CAR:ZZ00);
[email-masked]
Subject: Re: [secdir] secdir review of
draft-ietf-netconf-notification-12

On Tue, Mar 04, 2008 at 07:47:43PM -0800, Blake Ramsdell wrote:
> * Is there a risk of sessions accumulating? That is, too many
>   create-subscription requests without termination?

The subscription terminates when the underlying NETCONF session goes
way. In order to accumulate subscriptions, you need to accumulate
NETCONF sessions. These may well be a finite resource, but the base
protocol provides a <kill-session> command to kill a particular session
from another session if there is an issue.

>
> * How important is the accuracy of the eventTime field for notification
nodes?
>   If you put in something that doesn't parse, or that's deliberately bad,
is
>   that a problem?
The eventTime field provides the time the event occurred within the
network element. If it was corrupted, the NETCONF client would need to
substitute the time the event was received on the client side, which is
less then ideal as often the client needs to understand the order that
events occurred in order to correlate. So, there is a workaround if this
were to happen, but I'm not sure how likely it is.

>
> * The filtering and the complexity associated with arbitrary XPath syntax
for
>   specifying filter criteria concerns me. Is there any risk of someone
gaming
>   the events to elude the filter criteria? Any case matching rules that
might
>   need to be specified or anything like that?
We did not introduce the XPATH mechanism, just applied it to
notifications so we are not introducing any new risks that are not in
the base protocol. I can't think of any expressions that would be
problematic, but I'm not familiar with the more complex XPath syntax.
I'm also not exactly sure what 'gaming the events to elude the filter
criteria means'. If you mean to use it to get access to events that you
should not have access to, since the implementations would be applying
access control to the resulting events, not the xpath expression, I
don't think this is an issue.

Sharon

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

F client would need to
substitute the time the event was received on the client side, which is
less then ideal as often the client needs to understand the order that
events occurred in order to correlate. So, there is a workaround if this
were to happen, but I'm not sure how likely it is.

>
> * The filtering and the complexity associated with arbitrary XPath syntax
for
>   specifying filter criteria concerns me. Is there any risk of someone
gaming
>   the events to elude the filter criteria? Any case matching rules that
might
>   need to be specified or anything like that?
We did not introduce the XPATH mechanism, just applied it to
notifications so we are not introducing any new risks that are not in
the base protocol. I can't think of any expressions that would be
problematic, but I'm not familiar with the more complex XPath syntax.
I'm also not exactly sure what 'gaming the events to elude the filter
criteria means'. If you mean to use it to get access to events that you
should not have access to, since the implementations would be applying
access control to the resulting events, not the xpath expression, I
don't think this is an issue.

Sharon

_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf