[Nea] Comments on draft-thomson-nea-problem-statement-00.txt

[Sean Convery <sconvery at gmail.com>]

Hello all,

I'm new to the list so apologies if my comments tread on well worn
ground. Overall I found the document does a good job of describing the
ultimate goal and then a brief framework for an architecture to
address the goal. I think it may be useful to have something in
between which discusses some of the challenges in realizing the goal
which helped inform the choices in the summarized architecture. I also
think more discussion around higher-layer approaches to NEA might be
useful in the doc. These higher layer approaches may in the end use
the same components defined in the current draft but they may be
invoked and initially provisioned in different ways. This could
possibly be addressed through an expansion of Section 5. Specific
comments below and some nits.

Thanks,

Sean

Section 2: Is "Network access requestor" the right term? Can't the
protocol that makes the network access request be distinct from the
one who responds if challenged by the network for posture information?
Would "NEA network interface" or something similar be better? The
existing naming implies a tighter linkage between NEA and existing
network AAA systems that may be desired especially at the problem
stage.

Section 2: Similar to my comment on the "network access requestor"
name, network access authority implies a similar linkage to existing
AAA which we may not want at this stage of the work. I agree AAA is a
natural home for NEA functions but there are others.

Section 3, access technologies (should we include either Web
authentication / captive portal or SSL based VPN?)

Section 4 bullet 1: Should we mention heterogeneous vendor support of
all the main components or is that assumed since this is the IETF? :)

Section 4 bullet 2: Again introducing user and device seems odd but if
we keep it in, it should be "or all three", not or both. Overall I
think we need more words on the interactions of the existing AAA
system with NEA if we want to be linked so closely in terms of
capabilities.

Section 4 bullet 3 - What about things operating above L3 to control
network access such as captive portals?

Section 4 last bullet - Is agent vs. no agent really binary? What
about a downloadable applet at the time the user hits a captive
portal? Couldn't there be a mix of the NEA subcomponents some of which
are static on an endpoint and some of which are dynamically loaded to
do the posture check? This may not materially affect the standards but
some mention of it might be useful since this is a problem statement
doc. In fact, I wonder if this whole document needs more discussion of
the challenges to solving the NEA problem; discussions about
resistance to run new client code, challenges in troubleshooting NEA
deployments, etc.. This is the first IETF problem statement doc I've
reviewed so pardon my ignorance if that sort of thing is not generally
discussed. It seems that as the IETF evaluates potential solutions to
the problem statement in this doc, some more words around what
deployment challenges to keep in mind would be useful. This could be
an expansion of section 4.

6.1 -  if you put this section earlier in the doc and expanded it some
of my earlier comments around the AAA discussion would be addressed.

6.2.1.1 Bullet 3 - Shouldn't this be instead indicating when the
posture of a security element under the purview of that particular
plug-in has changed?

9.3 - This seems like an important security consideration but not one
which could be obviously addressed through the proposed scope of
standardization.

*Nits*

Be consistent with capitalization of terms.

Section 5.4 - Third paragraph seems like a viable use in its own right
so perhaps it should precede the migration paragraph.

Section 6 - Suggest rewording the first sentence as follows: Figure 1
shows the a high-level diagram of the overall NEA system and
interfaces, each of which is elaborated in subsequent subsections.

6.1 Radius should be RADIUS.

6.2.1.1 - software that provide  -> software that provides

there may be many plug-ins in an agent, one per vendor and application
type -> there may be many plug-ins in an agent (i.e. one per vendor or
application type).

Bullet 2 - information any actions --> information on any actions


9.2 - Server Broker should only communicate with authorized NEA -->
Server Broker should only communicate with an authorized NEA

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea