Subject: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 17 Mar 2016 05:21:35 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-i2rs-architecture-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- If i2rs were used to control home networks, then that would
raise more privacy issues, e.g. the agent's IP address can be
privacy sensitive. Would it be useful to rule that out of
scope? E.g. to say that i2rs SHOULD NOT be used where the
agent/router in question is specific to one person or home?

- section 2: security role, hmm..... Do netconf/restconf have
the concept of mapping identifiers to roles? If not, that
might be tricky to graft on. Not sure.

- section 4: "Mutual authentication between the I2RS Client
and I2RS Agent is required. " yay! thanks:-) Even better if
you did s/Mutual/Strong mutual/ to prevent someone saying that
TCP-MD5 is good enough.

- section 4: "The primary communication channel that is used
for client authentication and then used by the client to write
data requires integrity, confidentiality and replay
protection." yay! again! :-)

- section 4: "Other communications via I2RS may not require
integrity, confidentiality, and replay protection.  For
instance, if an I2RS Client subscribes to an information
stream of prefix announcements from OSPF, those may require
integrity but probably not confidentiality or replay
protection." sorry, boo! :-) 

It's often unsafe to mix and match differently protected sets
of data between the same sets of entities. I think you'd be
better off there saying that the requirements may
*exceptionnally* differ but usually only because of e.g. some
level of broadcast or multicast being part of the story, where
we don't have good usable security solutions today. (This is
not a DISCUSS because I think the protocol work will end up
saying "just use TLS always" as that'll be simpler and better,
so I hope this'll be a non-issue. If you know already that
there's some other plan in place, then please say so we can
chat now and avoid a trickier discussion later.) 

- section 4: I think you're heading here towards use of TLS
and not object level security. Is that right? If so, would it
be useful to say so? (Just so as to correctly set expectations
for later.)

- 7.7: Would it be useful to say that the relevant information
here is only about network state and stastics and not about
connections (e.g. who spoke to whom) or payloads?  That might
save some discussions about RFC2804 later on.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 17 Mar 2016 09:00:48 -0400

Stephen: 

Thank you for your comments.  See answers below.   I hope you will stay involved in reviews.  It is critical we consider privacy and security for this new interface.

Sue 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, March 17, 2016 8:22 AM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

>- If i2rs were used to control home networks, then that would raise more privacy issues, 
>e.g. the agent's IP address can be privacy sensitive. Would it be useful to rule that out of
 > scope? E.g. to say that i2rs SHOULD NOT be used where the agent/router in question 
> is specific to one person or home?

Sue:  I'm really not sure what you are getting at.  Data in routers is privacy sensitive.  
Data between I2RS Agent and I2RS client will be encrypted except in very, very rare circumstances where is defined to be public data in the data model. SECDIR, OPSDIR, RTGWG, Transport-directorate will be asked to review any IETF data model that claims this is the case to validate it is appropriate.   So... I think we are going beyond what people use for home networks.  

> section 2: security role, hmm..... Do netconf/restconf have the concept of mapping >identifiers to roles? If not, that might be tricky to graft on. Not sure.

Sue: 

- section 4: "Mutual authentication between the I2RS Client and I2RS Agent is required. " yay! thanks:-) Even better if you did s/Mutual/Strong mutual/ to prevent someone saying that TCP-MD5 is good enough.

Sue:  At least 15 years with BGP has taught about some mistakes. 

- section 4: "The primary communication channel that is used for client authentication and then used by the client to write data requires integrity, confidentiality and replay protection." yay! again! :-)

Sue: This is why I do not understand the first question. 

- section 4: "Other communications via I2RS may not require integrity, confidentiality, and replay protection.  For instance, if an I2RS Client subscribes to an information stream of prefix announcements from OSPF, those may require integrity but probably not confidentiality or replay protection." sorry, boo! :-) 

Sue:  I agree the bar should be high on all of our streams.  I hope you will review (as AD or sec-dir) our proposed streams for replay.   The WG indicated that if OSPF is good enough to run the network, it is secure enough to listen to.  Perhaps OSPF needs to change (smile).   

It's often unsafe to mix and match differently protected sets of data between the same sets of entities. I think you'd be better off there saying that the requirements may
*exceptionnally* differ but usually only because of e.g. some level of broadcast or multicast being part of the story, where we don't have good usable security solutions today. (This is not a DISCUSS because I think the protocol work will end up saying "just use TLS always" as that'll be simpler and better, so I hope this'll be a non-issue. If you know already that there's some other plan in place, then please say so we can chat now and avoid a trickier discussion later.) 

Sue:  90% answer is "just use TLS as always.  For the first version of I2RS protocol we will use NETCONF/RESTCONF as the base for configuration, publication/subscription of large data, and action commands.  NETCONF has definitions over TLS and over SSH.  RESTCONF runs of HTTP and requires TLS.    We are finalizing requirements for insecure stream and multicast - so I would really like to hear your concerns in person.  

- section 4: I think you're heading here towards use of TLS and not object level security. Is that right? If so, would it be useful to say so? (Just so as to correctly set expectations for later.)

Sue: We are using TLS, but we are indicating that certain data models are only allowed to be accessed (read, write, or both) by certain users.  This fits within the NETCONF/RESTCONF concepts.  

- 7.7: Would it be useful to say that the relevant information here is only about network state and stastics and not about connections (e.g. who spoke to whom) or payloads?  That might save some discussions about RFC2804 later on.

Sue: Yes, sections about network state.   It is about network connections and topologies -  but not about "who spoke to whom" or payloads.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Mar 2016 13:10:55 +0000

Hiya,

Just on that one point (the rest seems fine):

> Sue:  I'm really not sure what you are getting at.  Data in routers
> is privacy sensitive. Data between I2RS Agent and I2RS client will be
> encrypted except in very, very rare circumstances where is defined to
> be public data in the data model. SECDIR, OPSDIR, RTGWG,
> Transport-directorate will be asked to review any IETF data model
> that claims this is the case to validate it is appropriate.   So... I
> think we are going beyond what people use for home networks.

Let's assume all client/agent stuff is wonderfully protected
e.g. via TLS.

Normally, the fact that a client at IP1 is managing an agent at
IP2, which is still visible despite the TLS, is not much of a
deal. Nor is it a deal when that happens, e.g. in reaction to
some other event, perhaps even one triggered by an attacker.

But if the agent is my home g/w, then the sensitivity level goes
up I think, or at least it can. The reason is that the agent's
address (IP2) is tied to me. If the agent was on my phone (e.g.
for tethering) then it'd be even more of a deal perhaps, as I
carry it with me.

If i2rs just isn't intended for such use-cases, it may be worth
saying that was all I meant.

Cheers,
S.

---

From: Joel Halpern <[email-masked]>
Date: Thu, 17 Mar 2016 13:15:50 +0000

I would hope that I2RS could be used for that (applying policy to home 
devices) use case.

But I am not at all clear how I2RS could protect the IP address of the router 
containing the communicating I2RS agent.  We have to have an available IP 
address for IP Routing.

I am also not clear why this IP address is particularly more sensitive than an 
enterprise device IP address, or a router inside an ISP.

Yours,
Joel

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Thursday, March 17, 2016 2:11 PM
To: Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; 
[email-masked]; [email-masked]
Subject: Re: Stephen Farrell's No Objection on 
draft-ietf-i2rs-architecture-13: (with COMMENT)

Hiya,

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Mar 2016 13:23:04 +0000

> I would hope that I2RS could be used for that (applying policy to home 

Ah. Good to know.

> containing the communicating I2RS agent.  We have to have an available IP 

I didn't say it needed protecting (as in encrypting) necessarily,
but that it could be more sensitive.

> enterprise device IP address, or a router inside an ISP.

In general, if an identifier is also something one can correlate
with a person, or with a person's movements or presence, then it
is more privacy sensitive. If you can tell I'm at home because of
an i2rs event say.

For a router on the 4th floor of an office building, those are
less likely interesting issues.

In the home case, one needs to think more about such stuff than
in the office case basically.

Whether/how that impacts on protocol design is hard to say. But
it's good to know that it's something that i2rs needs to consider.

Cheers,
S.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 17 Mar 2016 09:23:54 -0400

Stephen: 

+1 to Joel's comment.   
Home IP for your phone == enterprise CEO's IP phone. 
Both need to be secure.   Access to some information is limited to administrator. 

I must be missing something. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Joel Halpern
Sent: Thursday, March 17, 2016 9:16 AM
To: Stephen Farrell; Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

But I am not at all clear how I2RS could protect the IP address of the router containing the communicating I2RS agent.  We have to have an available IP address for IP Routing.

I am also not clear why this IP address is particularly more sensitive than an enterprise device IP address, or a router inside an ISP.

Yours,
Joel

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Thursday, March 17, 2016 2:11 PM
To: Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's No Objection on

Hiya,

On 17/03/16 13:00, Susan Hares wrote:
>>> - If i2rs were used to control home networks, then that would raise 
>>> more privacy issues, e.g. the agent's IP address can be privacy 
>>> sensitive. Would it be useful to rule that out of

> Sue:  I'm really not sure what you are getting at.  Data in routers is 
> privacy sensitive. Data between I2RS Agent and I2RS client will be 

Let's assume all client/agent stuff is wonderfully protected e.g. via TLS.

Normally, the fact that a client at IP1 is managing an agent at IP2, which is still visible despite the TLS, is not much of a deal. Nor is it a deal when that happens, e.g. in reaction to some other event, perhaps even one triggered by an attacker.

But if the agent is my home g/w, then the sensitivity level goes up I think, or at least it can. The reason is that the agent's address (IP2) is tied to me. If the agent was on my phone (e.g.
for tethering) then it'd be even more of a deal perhaps, as I carry it with me.

If i2rs just isn't intended for such use-cases, it may be worth saying that was all I meant.

Cheers,
S.

---

From: Joel Halpern <[email-masked]>
Date: Thu, 17 Mar 2016 13:25:12 +0000

Can you suggest wording to add to the architecture document to reflect this 
consideration?

Yours,
Joel

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]]
Sent: Thursday, March 17, 2016 2:23 PM
To: Joel Halpern; Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Subject: Re: Stephen Farrell's No Objection on 
draft-ietf-i2rs-architecture-13: (with COMMENT)

Ah. Good to know.

Cheers,
S.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 17 Mar 2016 09:26:51 -0400

Stephen: 

I think my last email covered it.  Most operators tree Routing information as sensitive info. 

Sue 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, March 17, 2016 9:23 AM
To: Joel Halpern; Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

Ah. Good to know.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Mar 2016 13:28:13 +0000

> Can you suggest wording to add to the architecture document to reflect this 

Maybe something along the lines of:

"If an i2rs agent or client is such that it is likely
tightly correlated with a person (say if an agent is
running on someone's phone to control tethering) then
that can raise privacy issues, over and above.the
security and privacy issues that normally need to be
handled in i2rs. For example, if an i2rs interaction
enabled easier location tracking in the above example.
i2rs protocols should consider if such privacy issues
can arise when clients or agents are used for such
use-cases."

Cheers
S.

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 17 Mar 2016 09:28:29 -0400

Stephen: 

Thank you for the suggestion. 

Sue 

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, March 17, 2016 9:28 AM
To: Joel Halpern; Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Stephen Farrell's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

Cheers
S.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 22 Mar 2016 22:46:58 -0400

> might be tricky to graft on. Not sure.

There may be room in the future protocol specific work for I2RS across a
transport such as netconf/restconf to further refine this.  However, as one
example of role-binding, a given user (identity) may have access to specific
resources such as portions of the configuration tree.  

Basically, typical user to configuration privileges.

An example of this is user jeff is allowed to configure bgp, but should
enver be allowed to interact with the device's security settings.

NACM already provides something rather similar to this behavior in netconf,
but discussion with the netconf working group is ongoing in terms of further
bindings that are i2rs specific, such as priority.

-- Jeff