Subject: [i2rs] updated draft-atlas-i2rs-problem-statement-01

From: Alia Atlas <[email-masked]>
Date: Tue, 26 Feb 2013 14:50:32 -0800

I updated the problem-statement draft, but requested manual posting to
get the name-change and meta-data right.
While waiting for that to happen, I've attached the draft so there's
more time to review it before IETF.

Regards,
Alia

---

From: "George, Wes" <[email-masked]>
Date: Thu, 28 Feb 2013 10:53:26 -0500

This is a fairly high-level review, but I do have two substantive comments:

I see a glaring omission in section 5... Security.
I see that the security considerations hint at this, but I think we need at least a placeholder here to underscore its relative importance. Here's a crack at some text...

Secure: The communication both between applications and I2RS client and between I2RS client and I2RS agent (and others?) should use secure (authenticated and encrypted) transport. Further, a fine-grained trust model should be defined to ensure that the payload communications (both read-only and read-write access) are properly authenticated (you are who you say you are and I trust you to communicate with me), and to give tight control over what a given communicator is and is not permitted to know or manipulate. These controls should include the ability to limit the manipulation to a range of acceptable values or even limit the rate of change. IOW - if the knob goes from 0 to 11, but I only want to allow application X to be able to turn it between 2 and 5, the framework needs to support that.

Given the amount of control possible with I2RS or other SDN-style control surfaces, security and trust model for any of these software manipulation tools MUST be designed in from day one. Bolt-on security (that is, security that is not integral to the protocol specification) has the potential to sharply limit the application of these tools because it would require a level of trust and coordination between those maintaining applications and those maintaining the routing network that simply does not exist today in most companies.

Section 6 - there are XML interfaces to some router OSes now. You may have intended this to be covered under CLI, since it shares similarities, but when we're talking about existing interfaces and protocols, that might be an important distinction.
http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r4.1/xml/programming/guide/xl41apidoc.html

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alia Atlas
> Sent: Tuesday, February 26, 2013 5:51 PM
> To: [email-masked]
> Subject: [i2rs] updated draft-atlas-i2rs-problem-statement-01
>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 28 Feb 2013 16:34:15 +0000

Thanks for the review!

>I see that the security considerations hint at this, but I think we need
>at least a placeholder here to underscore its relative importance. Here's
>a crack at some text...

	The omission was not intentional in the sense that we didn't feel it was
necessary; just that we did not have time to get inputs on this. Its
definitely planned for the future.

>Secure: The communication both between applications and I2RS client and
>between I2RS client and I2RS agent (and others?) should use secure
>(authenticated and encrypted) transport. Further, a fine-grained trust
>model should be defined to ensure that the payload communications (both
>read-only and read-write access) are properly authenticated (you are who
>you say you are and I trust you to communicate with me), and to give
>tight control over what a given communicator is and is not permitted to
>know or manipulate. These controls should include the ability to limit
>the manipulation to a range of acceptable values or even limit the rate
>of change. IOW - if the knob goes from 0 to 11, but I only want to allow
>application X to be able to turn it between 2 and 5, the framework needs
>to support that.
>
>Given the amount of control possible with I2RS or other SDN-style control
>surfaces, security and trust model for any of these software manipulation
>tools MUST be designed in from day one. Bolt-on security (that is,
>security that is not integral to the protocol specification) has the
>potential to sharply limit the application of these tools because it
>would require a level of trust and coordination between those maintaining
>applications and those maintaining the routing network that simply does
>not exist today in most companies.

	That sounds reasonable.

>Section 6 - there are XML interfaces to some router OSes now. You may
>have intended this to be covered under CLI, since it shares similarities,
>but when we're talking about existing interfaces and protocols, that
>might be an important distinction.

	Good point.

	--Tom

>This E-mail and any of its attachments may contain Time Warner Cable
>proprietary information, which is privileged, confidential, or subject to
>copyright belonging to Time Warner Cable. This E-mail is intended solely
>for the use of the individual or entity to which it is addressed. If you
>are not the intended recipient of this E-mail, you are hereby notified
>that any dissemination, distribution, copying, or action taken in
>relation to the contents of and attachments to this E-mail is strictly
>prohibited and may be unlawful. If you have received this E-mail in
>error, please notify the sender immediately and permanently delete the
>original and any copy of this E-mail and any printout.
>_______________________________________________
>i2rs mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i2rs
>