Subject: [Netconf] Netconf Notification: One last bit of Discuss: Session Accumulation

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 16 Jun 2008 07:52:51 -0400

Hi

I originally thought this would not require an update to the document,
but here it is. I propose the following text to resolve:

If a malicious or buggy NETCONF client sends a number of
<create-subscription> requests  without ever terminating any of them,
they will accumulate subscriptions and begin to use up system resources.
They do so while accumulating NETCONF sessions and when the underlying
NETCONF session is terminated, so is the Notification subscription. The
<kill-session> operation should be used to terminate any suspect NETCONF
sessions.

>There is only one remaining issue.  I identified tha following issue
from Blake Ramsdell's >secdir review as blocking:
>>
>>
>>> * Is there a risk of sessions accumulating? That is, too many
>>>   create-subscription requests without termination?
>>>
>>
>
> From the authors explanation, it is the netconf server's
responsibility to kill sessions if needed to address a DoS attack.
>
>> 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.
>>
>
>The explanation is fine, but I think a sentence or two in the security
considerations is needed to alert implementers.  I believe this can be
easily resolved with an RFC Editor Note.

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Jun 2008 08:16:36 -0700

> <kill-session> operation should be used to terminate any suspect NETCONF

I don't see why a new doc-rev is needed.
Isn't this incredibly obvious?
Isn't this the same for any session-based protocol?

IMO, there is no need to mention that the agent should
clean up underlying resources when a session is terminated.
This is either an implementation detail, or it is
already covered in RFC 4741.

Andy

>> From the authors explanation, it isFrom [email-masked]  Mon Jun 16 08:16:00 2008
Date: Mon, 16 Jun 2008 08:16:36 -0700
From: Andy Bierman <[email-masked]>
To: Sharon Chisholm <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss:
 Session Accumulation
Sender: [email-masked]

> <kill-session> operation should be used to terminate any suspect NETCONF

I don't see why a new doc-rev is needed.
Isn't this incredibly obvious?
Isn't this the same for any session-based protocol?

IMO, there is no need to mention that the agent should
clean up underlying resources when a session is terminated.
This is either an implementation detail, or it is
already covered in RFC 4741.

Andy

>> From the authors explanation, it is the n the netconf server's

etconf server's

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 16 Jun 2008 12:27:49 -0400

Hi

Why I don't disagree, this change can be made with an RFC editor's note,
so I don't see the harm.

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, June 16, 2008 11:17 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss:
Session Accumulation

> NETCONF session is terminated, so is the Notification subscription. 
> The <kill-session> operation should be used to terminate any suspect 
> NETCONF sessions.

IMO, there is no need to mention that the agent should clean up
underlying resources when a session is terminated.
ThFrom [email-masked]  Mon Jun 16 09:27:15 2008
Content-class: urn:content-classes:message
Date: Mon, 16 Jun 2008 12:27:49 -0400
From: "Sharon Chisholm" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss:
	Session Accumulation
Sender: [email-masked]

Hi

Why I don't disagree, this change can be made with an RFC editor's note,
so I don't see the harm.

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, June 16, 2008 11:17 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss:
Session Accumulation

> NETCONF session is terminated, so is the Notification subscription. 
> The <kill-session> operation should be used to terminate any suspect 
> NETCONF sessions.

IMO, there is no need to mention that the agent should clean up
underlying resources when a session is terminated.
This is is is either an implementation detail, or it is already covered in RFC
4741.

Andy

either an implementation detail, or it is already covered in RFC
4741.

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 16 Jun 2008 18:34:50 +0200

This was not so obvious for the Security AD Tim Polk who entered the
DISCUSS. If the clarification proposed by Sharon is accepted by Tim and
can be added by an RFC Editor note, we can resolve the DISCUSS. 

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Monday, June 16, 2008 6:17 PM
> To: Sharon Chisholm
> Cc: [email-masked]
> Subject: Re: [Netconf] Netconf Notification: One last bit of 
> Discuss: Session Accumulation
> 
> Sharon Chisholm wrote:
> > Hi
> > 
> > they will accumulate subscriptions and begin to use up 
> systFrom [email-masked]  Mon Jun 16 09:35:14 2008
Content-class: urn:content-classes:message
Date: Mon, 16 Jun 2008 18:34:50 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Andy Bierman" <[email-masked]>,
	"Sharon Chisholm" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss:
	Session Accumulation
Sender: [email-masked]

This was not so obvious for the Security AD Tim Polk who entered the
DISCUSS. If the clarification proposed by Sharon is accepted by Tim and
can be added by an RFC Editor note, we can resolve the DISCUSS. 

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Monday, June 16, 2008 6:17 PM
> To: Sharon Chisholm
> Cc: [email-masked]
> Subject: Re: [Netconf] Netconf Notification: One last bit of 
> Discuss: Session Accumulation
> 
> Sharon Chisholm wrote:
> > Hi
> > 
> IMO, there is no need to mention that the agent should clean 
> up underlying resources when a session is terminated.
> This is either an implementation detail, or it is already 
> covered in RFC 4741.
> 
> 
> 
> Andy
> 
> 
> 
> > 

em resources.
> IMO, there is no need to mention that the agent should clean 
> up underlying resources when a session is terminated.
> This is either an implementation detail, or it is already 
> covered in RFC 4741.
> 
> 
> 
> Andy
> 
> 
> 
> >

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Jun 2008 09:44:06 -0700

> Why I don't disagree, this change can be made with an RFC editor's note,

IMO, standards should be precise, and normative text
should be as small as possible.  Tell me how to
implement the specification in an inter-operable manner,
and nothing else.  (Obviously a minority opinion in the IETF.)

The text is ambiguous.
Does it mean N sessions?
N <create-subscription> requests on 1 session?

Is this normative text in the attachment?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Jun 2008 09:44:06 -0700

The text is ambiguous.
Does it mean N sessions?

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 16 Jun 2008 12:56:15 -0400

Hi

It is going in the security considerations section. The text is more
instructions to the operator then the implementer. Do you have any
suggested improvements?

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, June 16, 2008 12:44 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss:
Session Accumulation

Sharon Chisholm wrote:
> Hi
> 
> Why I don't disagree, this change can be made with an RFC editor's 
> note, so I don't see the harm.
> 

IMO, standards should be precise, and normative text should be as small
as possible.  Tell me how to implement the specification in an
inter-operable manner, and nothing else.  (Obviously a minority opinion
in the IETF.)

The text is ambiguous.
Does it mean N sessions?

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 16 Jun 2008 12:56:15 -0400

Hi

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, June 16, 2008 12:44 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss:
Session Accumulation

The text is ambiguous.
Does it mean N sessions?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Jun 2008 19:10:06 +0200

> <kill-session> operation should be used to terminate any suspect NETCONF

I do not understand the second sentence. And who is "they" in the
first sentence? What about this wording:

  If a malicious or buggy NETCONF client sends a number of
  <create-subscription> requests, then these subscriptions accumulate
  and may use up system resources. In such a situation, subscriptions
  can be terminated by terminating the suspect underlying NETCONF
  sessions using the <kill-session> operation.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 16 Jun 2008 19:10:06 +0200

/js

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 16 Jun 2008 13:43:59 -0400

Hi

That version works for me.

Sharon 

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Monday, June 16, 2008 1:10 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss:
Session Accumulation

> The <kill-session> operation should be used to terminate any suspect 

I do not understand the second sentence. And who is "they" in the first
sentence? What about this wording:

/js

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 16 Jun 2008 13:43:59 -0400

Hi

Sharon 

-----Original Message-----

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Jun 2008 10:57:10 -0700

> That version works for me.

My concern is that is seems to imply that
an agent is going to support multiple, concurrent
notification subscriptions on the same session.
The WG never agreed to this feature.

Does this text refer to 1 subscription on each session,
or N subscriptions on 1 session, or both?  (A: yes ;-)

In my (even recent experience), when the standard is silent
on a subject, it is harder to interpret the specification incorrectly.
However, when a standard is *almost* silent (i.e., partially specified)
then it is very easy for people to interpret the standard incorrectly,
in N different ways.

It should be clear that the standard does not define what
happens when a <create-subscription> is received on a session
while in notification mode already.  Some vendors want to utilize
this feature, and I think they should be able to experiment.
Vendors who reject <create-subscription> requests while in
notification mode are also compliant to the standard.

Andy

> To: ChisholmFrom [email-masked]  Mon Jun 16 10:56:37 2008
Date: Mon, 16 Jun 2008 10:57:10 -0700

> That version works for me.

My concern is that is seems to imply that
an agent is going to support multiple, concurrent
notification subscriptions on the same session.
The WG never agreed to this feature.

Does this text refer to 1 subscription on each session,
or N subscriptions on 1 session, or both?  (A: yes ;-)

In my (even recent experience), when the standard is silent
on a subject, it is harder to interpret the specification incorrectly.
However, when a standard is *almost* silent (i.e., partially specified)
then it is very easy for people to interpret the standard incorrectly,
in N different ways.

It should be clear that the standard does not define what
happens when a <create-subscription> is received on a session
while in notification mode already.  Some vendors want to utilize
this feature, and I think they should be able to experiment.
Vendors who reject <create-subscription> requests while in
notification mode are also compliant to the standard.

Andy

> To: Chisholm, Shar, Sharon (CAR:ZZ00)
> Cc: [email-masked]

on (CAR:ZZ00)

---

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 16 Jun 2008 14:04:45 -0400

Hi

I most certainly don't want to preclude multiple subscriptions per
session and the intention of the text was to not preclude this but also
not assume it either. Let me use Juergen's text as the starting point to
try and be a bit more clear.

   If a malicious or buggy NETCONF client sends a number of
   <create-subscription> requests, then these subscriptions accumulate
   and may use up system resources. This is true both if the system is
   running each subscription 
   in a separate session or is supporting multiple subscriptions on the
same session.
   In such a situation, subscriptions
   can be terminated by terminating the suspect underlying NETCONF
   sessions using the <kill-session> operation.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, June 16, 2008 1:57 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]; [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss:
Session Accumulation

> That version works for me.

My concern is that is seems to imply From [email-masked]  Mon Jun 16 11:04:15 2008
Content-class: urn:content-classes:message
Date: Mon, 16 Jun 2008 14:04:45 -0400
From: "Sharon Chisholm" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss:
	Session Accumulation
Sender: [email-masked]

Hi

I most certainly don't want to preclude multiple subscriptions per
session and the intention of the text was to not preclude this but also
not assume it either. Let me use Juergen's text as the starting point to
try and be a bit more clear.

   If a malicious or buggy NETCONF client sends a number of
   <create-subscription> requests, then these subscriptions accumulate
   and may use up system resources. This is true both if the system is
   running each subscription 
   in a separate session or is supporting multiple subscriptions on the
same session.
   In such a situation, subscriptions
   can be terminated by terminating the suspect underlying NETCONF
   sessions using the <kill-session> operation.

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Monday, June 16, 2008 1:57 PM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]; [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss:
Session Accumulation

> That version works for me.

My concern is that is seems to that an agent is going to support
multiple, concurrent notification subscriptions on the same session.
The WG never agreed to this feature.

Does this text refer to 1 subscription on each session, or N
subscriptions on 1 session, or both?  (A: yes ;-)

In my (even recent experience), when the standard is silent on a
subject, it is harder to interpret the specification incorrectly.
However, when a standard is *almost* silent (i.e., partially specified)
then it is very easy for people to interpret the standard incorrectly,
in N different ways.

It should be clear that the standard does not define what happens when a
<create-subscription> is received on a session while in notification
mode already.  Some vendors want to utilize this feature, and I think
they should be able to experiment.
Vendors who reject <create-subscription> requests while in notification
mode are also compliant to the standard.

Andy

imply that an agent is going to support
multiple, concurrent notification subscriptions on the same session.
The WG never agreed to this feature.

Does this text refer to 1 subscription on each session, or N
subscriptions on 1 session, or both?  (A: yes ;-)

In my (even recent experience), when the standard is silent on a
subject, it is harder to interpret the specification incorrectly.
However, when a standard is *almost* silent (i.e., partially specified)
then it is very easy for people to interpret the standard incorrectly,
in N different ways.

It should be clear that the standard does not define what happens when a
<create-subscription> is received on a session while in notification
mode already.  Some vendors want to utilize this feature, and I think
they should be able to experiment.
Vendors who reject <create-subscription> requests while in notification
mode are also compliant to the standard.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Jun 2008 20:22:48 +0200 (CEST)

> The WG never agreed to this feature.

We agreed to NOT support multiple subscriptions per session, even if
:interleave is supported.  Section 6.5 says:

   When a <create-subscription> is sent while another subscription is
   active on that session, the following error will be returned:

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 16 Jun 2008 20:22:48 +0200 (CEST)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 16 Jun 2008 11:38:12 -0700

>    active on that session, the following error will be returned:

After I sent my mail, I remembered that you really objected
to multiple <create-subscription>s.

I think there was discussion wrt/ adding back the subscription-id
and this was rejected, so there was no way to tell multiple
subscriptions on the same session apart.  So the text you
cited was added to the draft.

However, a vendor could (and should) use their own RPC method
with explicit semantics, rather than hack the <create-subscription> RPC
in non-standard ways.

The new text in question should clearly refer to new sessions,
since N subscriptions per session iFrom [email-masked]  Mon Jun 16 11:37:39 2008
Date: Mon, 16 Jun 2008 11:38:12 -0700
From: Andy Bierman <[email-masked]>
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit of Discuss:
 Session Accumulation
Sender: [email-masked]

>    active on that session, the following error will be returned:

After I sent my mail, I remembered that you really objected
to multiple <create-subscription>s.

I think there was discussion wrt/ adding back the subscription-id
and this was rejected, so there was no way to tell multiple
subscriptions on the same session apart.  So the text you
cited was added to the draft.

However, a vendor could (and should) use their own RPC method
with explicit semantics, rather than hack the <create-subscription> RPC
in non-standard ways.

The new text in question should clearly refer to new sessions,
since N subscriptions per session is not s not supported via the
standard <create-subscription> operation.

Andy

supported via the
standard <create-subscription> operation.

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 17 Jun 2008 08:00:41 +0800

I like this proposed text much better.

dbh 

> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, June 17, 2008 1:10 AM
> To: Sharon Chisholm
> Cc: [email-masked]
> Subject: Re: [Netconf] Netconf Notification: One last bit 
> ofDiscuss: Session Accumulation
> 
> system resources.
> I do nFrom [email-masked]  Mon Jun 16 17:00:19 2008
From: "David B Harrington" <[email-masked]>
To: <[email-masked]>,
	"'Sharon Chisholm'" <[email-masked]>
Date: Tue, 17 Jun 2008 08:00:41 +0800
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit ofDiscuss:	Session
	Accumulation
Sender: [email-masked]

I like this proposed text much better.

dbh 

> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Tuesday, June 17, 2008 1:10 AM
> To: Sharon Chisholm
> Cc: [email-masked]
> Subject: Re: [Netconf] Netconf Notification: One last bit 
> ofDiscuss: Session Accumulation
> 
> system resources.
> I do not undot understand the second sentence. And who is "they" in the

erstand the second sentence. And who is "they" in the

---

From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Date: Tue, 17 Jun 2008 08:36:52 +0200

I like the proposed text too. 

This looks like a consensus. If anybody disagrees to 
use it please propose a concrete text.

Mehmet

> [mailto:[email-masked]] On Behalf Of ext David B Harrington
> Sent: Tuesday, June 17, 2008 2:01 AM
> To: [email-masked]; 'Sharon Chisholm'
> Cc: [email-masked]
> ofDiscuss: SessionAccumulation
> 
> > -----Original MFrom [email-masked]  Mon Jun 16 23:36:42 2008
Content-class: urn:content-classes:message
Date: Tue, 17 Jun 2008 08:36:52 +0200
From: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
To: "ext David B Harrington" <[email-masked]>,
	<[email-masked]>,
	"Sharon Chisholm" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last bit
	ofDiscuss:	SessionAccumulation
Sender: [email-masked]

I like the proposed text too. 

This looks like a consensus. If anybody disagrees to 
use it please propose a concrete text.

Mehmet

> [mailto:[email-masked]] On Behalf Of ext David B Harrington
> Sent: Tuesday, June 17, 2008 2:01 AM
> To: [email-masked]; 'Sharon Chisholm'
> Cc: [email-masked]
> ofDiscuss: SessionAccumulation
> 
> > -----Origessage-----

inal Message-----

---

From: Andy Bierman <[email-masked]>
Date: Tue, 17 Jun 2008 10:02:25 -0700

> use it please propose a concrete text.

The new text from Juergen is fine, now that Martin pointed
out that the text cannot possibly be interpreted to mean
multiple subscriptions on 1 session.

I think the new text suggests the opposite, but the text in 6.5
clearly says otherwise (in case it comes up in the future that
the standard is ambiguous wrt/ multiple subscriptions per session).

Andy

>>> [mailto:netconf-bounces@ietfFrom [email-masked]  Tue Jun 17 10:01:47 2008
Date: Tue, 17 Jun 2008 10:02:25 -0700
From: Andy Bierman <[email-masked]>
To: "Ersue, Mehmet (NSN - DE/Muenich)" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Netconf] Netconf Notification: One last
	bit	ofDiscuss:	SessionAccumulation
Sender: [email-masked]

> use it please propose a concrete text.

The new text from Juergen is fine, now that Martin pointed
out that the text cannot possibly be interpreted to mean
multiple subscriptions on 1 session.

I think the new text suggests the opposite, but the text in 6.5
clearly says otherwise (in case it comes up in the future that
the standard is ambiguous wrt/ multiple subscriptions per session).

Andy

>>> [mailto:netconf-bounce.org] On Behalf Of Juergen Schoenwaelder

[email-masked]] On Behalf Of Juergen Schoenwaelder