Subject: [Netconf] Fwd: Re: FW: David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (withDISCUSS and COMMENT)

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Thu, 03 Mar 2011 12:33:25 +0100

Forwarding this to DBH and netconf list, so everyone knows.

Bert WIjnen
Document Shpeherd

-------- Original Message --------
Subject: 	Re: FW: David Harrington's Discuss on draft-ietf-netconf-4741bis-09: (withDISCUSS and COMMENT)
Date: 	Thu, 3 Mar 2011 00:29:55 +0100
From: 	Juergen Schoenwaelder <[email-masked]>
Reply-To: 	Juergen Schoenwaelder <[email-masked]>
To: 	Ersue, Mehmet (NSN - DE/Munich) <[email-masked]>
CC: 	[email-masked], [email-masked], "ext Romascanu, Dan (Dan)" <[email-masked]>, 
[email-masked]

>  ----------------------------------------------------------------------
>  DISCUSS:
>  ----------------------------------------------------------------------
>
>  1) should there be constraints on the basic format of username? if it is expected to be specified by an operator in config files or databases, should it be human-readable? ascii? utf-8?

NETCONF content by default is UTF8.

>  2) should the format be predictable, so the operator can determine what the NC username will be, given a knowledge of the corresponding identifier in the secure transport protocol?

NETCONF uses what the secure transport natively delivers. Since there
are not size or character set constraints in NETCONF, this just works
fine and follows the model that works on a large number of deployed
CLIs.

>  3) commit MUST revert at 600 secs, but timeout is configurable., what if somebody sets it to 700 seconds? MUST it still revert at 600? Can a low timeout cause a denial of service?

600 secs is the default if a timeout is not specified:

    A confirmed commit operation MUST be reverted if a confirming commit
    is not issued within 600 seconds (10 minutes).  The confirming commit
    is a commit operation without the<confirmed>  parameter.  The timeout
    period can be adjusted with the<confirm-timeout>  parameter.

If this text is not clear enough, we can change this to:

    A confirmed commit operation MUST be reverted if a confirming
    commit is not issued within the timeout period (by default 600
    seconds = 10 minutes).  The confirming commit is a commit operation
    without the<confirmed>  parameter.  The timeout period can be
    adjusted with the<confirm-timeout>  parameter.

Setting the timeout to 0 secs likely causes an almost immediate
rollback. Is this a denial of service risk? Well, if an attacker
manages to commit configs, then he likely can do more interesting harm
that this attempt to eat some rollback CPU cycles.

/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/>