Re: [i2rs] Stephen Farrell's No Objection on draft-ietf-i2rs-problem-statement-10: (with COMMENT)

Stephen: 

Resending my comments in respond to your ballot comment. 

Cheerily - Sue 
--------------------

- section 1: "different vendors' routing systems" seems like
it's assuming that there is only one vendor involved in each
box. I don't think that's consistent with what's behind i2rs so
re-wording there might be better. 

Sue: At this point, the WG considers "routing" system to be a set of
software running on some hardware, and not a box.  In a server box, you can
lots (10s or 100s) of different routing systems.  Is there something in that
paragraph that caused you to think it was a box?  If so, please let the
authors know. 

- figure 1: I'm sure you'll fix the page break
Sue: Yes - it will get fix 

- confidentiality for i2rs protocol: if I can watch i2rs traffic
I can probably infer what policies are being used and use that
to better attack networks. I think you could easily strengthen
the wording there and that'd be better.  If one has a way to
securely authenticate endpoints, then you can almost as easily
ensure confidentiality. 

Sue: The protocol requirement document specifies confidential (encrypted)
transport and securely authenticated endpoints (mutual authenticated
identities,  passed out of band - in AAA protocol) as the default. For a few
data models, we may propose that the data reported (not the configuration or
the set-up of the notification) to be in the clear.  We hope the security
directorate will work with us on these few models to minimize any potential
security attacks or issues.  

- general question: We know that govts target network admins.
What are we doing to make i2rs traffic less easily used as a
selector? (e.g. make sure it could work over Tor?)

Sue: Not sure I grok this comment.  I2RS traffic will use existing
transports (NETCONF/RESTCONF for config, IPFix/RESTCONF/NETCONF for data
transfer).  These work in virtual environments (see ODL). 

- the secdir review [1] called out some nits you may want to
consider (if you did already thanks, I didn't check in detail)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06342.html
Sue: We'll work on fixing nits in the next version.  Alia Atlas whose got
the editor pen should take care of that in a week. 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Monday, February 15, 2016 2:38 PM
To: The IESG
Cc: i2rs@ietf.org; bill.wu@huawei.com;
draft-ietf-i2rs-problem-statement@ietf.org; i2rs-chairs@ietf.org
Subject: [i2rs] Stephen Farrell's No Objection on
draft-ietf-i2rs-problem-statement-10: (with COMMENT)

Stephen Farrell has entered the following ballot position for
draft-ietf-i2rs-problem-statement-10: 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-problem-statement/

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

- section 1: "different vendors' routing systems" seems like it's assuming
that there is only one vendor involved in each box. I don't think that's
consistent with what's behind i2rs so re-wording there might be better. 

- figure 1: I'm sure you'll fix the page break

- confidentiality for i2rs protocol: if I can watch i2rs traffic I can
probably infer what policies are being used and use that to better attack
networks. I think you could easily strengthen the wording there and that'd
be better.  If one has a way to securely authenticate endpoints, then you
can almost as easily ensure confidentiality. 

- general question: We know that govts target network admins.
What are we doing to make i2rs traffic less easily used as a selector? (e.g.
make sure it could work over Tor?)

- the secdir review [1] called out some nits you may want to consider (if
you did already thanks, I didn't check in detail)

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06342.html

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs