Subject: [I2nsf] Eric Rescorla's No Objection on draft-ietf-i2nsf-problem-and-use-cases-11: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Fri, 07 Apr 2017 16:41:42 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-i2nsf-problem-and-use-cases-11: 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-i2nsf-problem-and-use-cases/

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

I don't have any problem with this document per se, but it's a little
odd how it's written in a vacuum as if there weren't already
technologies
which did a lot of the things you are talking about here (e.g., YANG)
and which the WG intends to use. I think this document would be a
lot stronger if it didn't act as if the WG was agnostic and instead
called out what solutions the WG intends to adopt for these.

I'm also somewhat surprised this is being advanced as Standards Track,
given that it doesn't have any normative content, and becaus ehte
writeup says that there isn't commitment to implement this.
I won't hold a DISCUSS on this, but I would suggest it be
Informational.

S 2.
  Flow-based NSF:    An NSF which inspects network flows according to a
        security policy.  Flow-based security also means that packets
are
        inspected in the order they are received,

This seems over-specific, because sometimes firewalls and the like will
store packets so that it can re-assemble them, in which case it
inspects
them in logical not time order.

S 3.1.7.
   Different policies might need different signatures or 
   profiles.  Today, the construction and use of black list databases
   can be a win-win strategy for all parties involved.

Well, except for attackers. They are involved.

S 3.1.9; bullet 3.
Symmetric keys and group keys are not the same type of category,
so I can't read this section. What are you trying to say here?

S 3.5.
"xamine" and "scnearios" are misspelled.

S 3.6.
ToR seems to be undefined.

Figure 3.
I think this dotted circle-thing is intended to tell me that the
operator
controls the stuff inside the circle, but I'm not sure. Maybe some
labels would help.

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 8 Apr 2017 19:48:50 +0100

Hi ekr, 

Welcome to the treadmill :-)

> I won't hold a DISCUSS on this, but I would suggest it be

Don't be too surprised as the shepherd write-up touches on this.

While the IESG has done some work on relaxing downref rules, the WGs still struggle with how to handle foundation documents that will be essential reading (i.e., normative references) for later work.

My advice to the WG for this document was, "Push it through as Standards Track and let the IESG worry about whether it should be Informational or not."
I think my advice will remain, "Let the IESG tell us what to do, and we will do it. But don't go making changes unless instructed to do so."

Cheers,
Adrian

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 27 Apr 2017 09:17:31 -0400

Ekr: 

Thank you for your insightful comments.  The track has been changed to
informational in version 13.  Your comments have been fixed in version 15
(or in earlier versions).  

Sue 

-----Original Message-----
From: I2nsf [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Friday, April 7, 2017 7:42 PM
To: The IESG
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: [I2nsf] Eric Rescorla's No Objection on
draft-ietf-i2nsf-problem-and-use-cases-11: (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.)

I don't have any problem with this document per se, but it's a little odd
how it's written in a vacuum as if there weren't already technologies which
did a lot of the things you are talking about here (e.g., YANG) and which
the WG intends to use. I think this document would be a lot stronger if it
didn't act as if the WG was agnostic and instead called out what solutions
the WG intends to adopt for these.

Sue: Having set-up requirements for the I2RS protocol changes to YANG,
NETCONF, and RESTCONF, I respectfully disagree with you.  In writing the
document in this style, it allows other technologies (CBOR or COAP) to be
used.   We may invent other functions in the future that may better secure
mobile devices. 

I'm also somewhat surprised this is being advanced as Standards Track, given
that it doesn't have any normative content, and becaus ehte writeup says
that there isn't commitment to implement this.
I won't hold a DISCUSS on this, but I would suggest it be Informational.

Sue: It has been changed. 

S 2.
  Flow-based NSF:    An NSF which inspects network flows according to a
        security policy.  Flow-based security also means that packets are
        inspected in the order they are received,

This seems over-specific, because sometimes firewalls and the like will
store packets so that it can re-assemble them, in which case it inspects
them in logical not time order.

Sue: This specific comment summarizes a decision by the WG to define
flow-based security in this fashion.  This definition was the source of much
debate in the WG.   I agree that logical order can be used rather than time
order, but the WG focused on time order.  

S 3.1.7.

Sue:  Nicely put - but 

S 3.1.9; bullet 3.
Symmetric keys and group keys are not the same type of category, so I can't
read this section. What are you trying to say here?

Agreed - symmetric keys and group keys are not the same type of category.
The point is that automated key management needs to support both.  Otherwise
requirements 1 + 2 cannot be met.  If you can suggest a better way to put
this section, please let me know.  

Section 3.1.9 - bullet 3: 
Old /Automated key management needs to support both symmetric keys and
group keys via the abstract key service provided by items 1 and
2. I2NSF controllers within the NSF required to exchange data
with NSFs may exchange data with individual NSFs using individual
symmetric keys or with a group of NSFs simultaneously using an IP
group address secured by a group security key(s). /

S 3.5.

Sue: Fixed in earlier version.  My apologies for the error.  (I had the joy
of finding out my spell checker had been corrupted on my tool (notepad++)).

S 3.6.

Sue: It was changed prior to version 15. 

Figure 3.
I think this dotted circle-thing is intended to tell me that the operator
controls the stuff inside the circle, but I'm not sure. Maybe some labels
would help.

Sue: Label "Service provider is within figure 3.  Any further suggestions
would help. 

_______________________________________________
I2nsf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2nsf

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Apr 2017 06:29:11 -0700

> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-problem-and-use-cases/

OK, well, this is a WG decision, but I found it kind of hard to read as an
outsider.

> order, but the WG focused on time order

So I guess my question is: say I had such a firewall. Would it not be a
flow-based
NSF? If not, what would it be? Note: My ask here is merely that the document
be clear about what's in or out. I'm not arguing about the content of the
decision.

> group address secured by a group security key(s). /

I would suggest using "pairwise" and "group" as that's the distinction I
think you
want to draw.

S 3.5.
> Sue: Label "Service provider is within figure 3.  Any further suggestions

Huh. Maybe move the label outside and have an arrow to the circle saying
"service provider boundary"?

I know that ASCII art is tough here.

-Ekr