Subject: [Netconf] FW: DISCUSS: draft-ietf-netconf-notification

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Thu, 27 Mar 2008 10:46:50 +0100

Forwarding this to the WG list, so everyone can see
what sort of DISCUSSes we are getting from IESG and
what our responses are.

Sharon, I have prefixed the actual comment lines with 
a ">" sign, so it is easier to see what were the comments
and what are your answers.

All, 
We have received more comments (will follow in more postings)
So we need to check it all. It seems that we may need 
another revision of the document to address all comments
received sofar.

Sharon, can you start preparing text for the security 
considerations section that we can then propose to the
IESG as a resolution. I suggest that you share that 
with us on the WG mailing list and with Tim, so we can
get consensus on th text before we actually do a new
revision of the document.
send

Bert Wijnen 

----- Original -----
From: Sharon Chisholm [mailto:[email-masked]]
Sent: donderdag 27 maart 2008 3:31
To:   Tim Polk; [email-masked]
CC:   [email-masked];
      [email-masked];
      [email-masked];
      [email-masked]
Subject: RE: DISCUSS: draft-ietf-netconf-notification

Hi

Here are my responses. I believe I addressed the other issues From [email-masked]  Thu Mar 27 02:49:15 2008
From: "Bert Wijnen - IETF" <[email-masked]>
To: "Netconf" <[email-masked]>
Date: Thu, 27 Mar 2008 10:46:50 +0100
Importance: Normal
Subject: [Netconf] FW: DISCUSS: draft-ietf-netconf-notification
Sender: [email-masked]

Forwarding this to the WG list, so everyone can see
what sort of DISCUSSes we are getting from IESG and
what our responses are.

Sharon, I have prefixed the actual comment lines with 
a ">" sign, so it is easier to see what were the comments
and what are your answers.

All, 
We have received more comments (will follow in more postings)
So we need to check it all. It seems that we may need 
another revision of the document to address all comments
received sofar.

Sharon, can you start preparing text for the security 
considerations section that we can then propose to the
IESG as a resolution. I suggest that you share that 
with us on the WG mailing list and with Tim, so we can
get consensus on th text before we actually do a new
revision of the document.
send

Bert Wijnen 

----- Original -----
From: Sharon Chisholm [mailto:[email-masked]]
Sent: donderdag 27 maart 2008 3:31
To:   Tim Polk; [email-masked]
CC:   [email-masked];
      [email-masked];
      [email-masked];
      [email-masked]
Subject: RE: DISCUSS: draft-ietf-netconf-notification

Hi

Here are my responses. I believe I addressed the other issues in a
separate email, but I've include and edited those response here now for
completeness. The text is written as a response to the discuss, but can
be turned easily into text for the security considerations section of
the document.

>1. "In Section 7, Security Considerations, the document states:
>
>   It is recommended that care be taken to secure execution:
>
>   o  <create-subscription> invocation
>
>   o  <get> on read-only data models
>
>   o  <notification> content
>
>First, what does "secure execution of" mean?  I expected the subsequent
>text to elaborate on the intent for each of the bulleted items, but
>there wasn't a very clear linkage."

Secure execution means ensuring that a secure transport is used (SSH, or
using HTTPS with SOAP or Beep transport mappings) as well as ensuring
that the user has sufficient authorization to perform the function they
are requesting against the specific bit of NETCONF content involved.
This has the same meaning as it did in the base protocol, which I
suspect is why we did not elaborate.

<get> may be filtered, in the sense that some users may get access to a
subset of the data and different users may get access to different
subsets.

<create-subscription> is like a deferred <get>, and the data that
different users can access may vary (probably with the same rules as
apply to <get>). This different access is reflected in the
<notification> that different users are able to subscribe to

>2. "Second, why isn't important to secure execution of <get> on
>   read-write data models?  Are we really referring to retrieving the
>   list of supported event streams?"

It is important to secure the <get> because the name of the streams may
provide information about the system such as what services are available
on the box, or what other customers getting service from the box, which
may be sensitive. 

>3. "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.

>4. "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
detect this and substitute the time the event was received on the client
side, which is less then ideal as often the client needs to understand
the correct order that events occurred in order to correlate. Note a
corruption could easily be detected by either the timestamp making no
sense or being different then the expected difference between NE time
and NETCONF client time. I don't think this scenario is more likely then
any other piece of data being corrupted though.

>5. "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.orgin a
separate email, but I've include and edited those response here now for
completeness. The text is written as a response to the discuss, but can
be turned easily into text for the security considerations section of
the document.

>1. "In Section 7, Security Considerations, the document states:
>
>   It is recommended that care be taken to secure execution:
>
>   o  <create-subscription> invocation
>
>   o  <get> on read-only data models
>
>   o  <notification> content
>
>First, what does "secure execution of" mean?  I expected the subsequent
>text to elaborate on the intent for each of the bulleted items, but
>there wasn't a very clear linkage."

Secure execution means ensuring that a secure transport is used (SSH, or
using HTTPS with SOAP or Beep transport mappings) as well as ensuring
that the user has sufficient authorization to perform the function they
are requesting against the specific bit of NETCONF content involved.
This has the same meaning as it did in the base protocol, which I
suspect is why we did not elaborate.

<get> may be filtered, in the sense that some users may get access to a
subset of the data and different users may get access to different
subsets.

<create-subscription> is like a deferred <get>, and the data that
different users can access may vary (probably with the same rules as
apply to <get>). This different access is reflected in the
<notification> that different users are able to subscribe to

>2. "Second, why isn't important to secure execution of <get> on
>   read-write data models?  Are we really referring to retrieving the
>   list of supported event streams?"

It is important to secure the <get> because the name of the streams may
provide information about the system such as what services are available
on the box, or what other customers getting service from the box, which
may be sensitive. 

>3. "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.

>4. "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
detect this and substitute the time the event was received on the client
side, which is less then ideal as often the client needs to understand
the correct order that events occurred in order to correlate. Note a
corruption could easily be detected by either the timestamp making no
sense or being different then the expected difference between NE time
and NETCONF client time. I don't think this scenario is more likely then
any other piece of data being corrupted though.

>5. "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

/mailman/listinfo/netconf