Network Endpoint Assessment (NEA): Overview and Requirements
draft-ietf-nea-requirements-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Cullen Jennings |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Magnus Westerlund |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2012-08-22
|
07 | (System) | post-migration administrative database adjustment to the No Record position for Ronald Bonica |
2008-05-22
|
07 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2008-05-21
|
07 | (System) | IANA Action state changed to No IC from In Progress |
2008-05-21
|
07 | (System) | IANA Action state changed to In Progress |
2008-05-21
|
07 | Amy Vezza | IESG state changed to Approved-announcement sent |
2008-05-21
|
07 | Amy Vezza | IESG has approved the document |
2008-05-21
|
07 | Amy Vezza | Closed "Approve" ballot |
2008-05-21
|
07 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2008-05-20
|
07 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2008-04-21
|
07 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko |
2008-04-18
|
07 | (System) | New version available: draft-ietf-nea-requirements-07.txt |
2008-03-19
|
07 | Cullen Jennings | [Ballot Position Update] Position for Cullen Jennings has been changed to No Objection from Discuss by Cullen Jennings |
2008-02-28
|
07 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund |
2008-02-25
|
07 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-02-25
|
06 | (System) | New version available: draft-ietf-nea-requirements-06.txt |
2008-01-11
|
07 | (System) | Removed from agenda for telechat - 2008-01-10 |
2008-01-10
|
07 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Phillip Hallam-Baker. |
2008-01-10
|
07 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2008-01-10
|
07 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2008-01-10
|
07 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2008-01-10
|
07 | Magnus Westerlund | [Ballot discuss] General issue and a discuss discuss. I think the initial architecture is lacking two entities in its discussion. The initiator, i.e. the one … [Ballot discuss] General issue and a discuss discuss. I think the initial architecture is lacking two entities in its discussion. The initiator, i.e. the one that triggers a check of posture control. The second entity is the posture report receiver. The one that needs or is supposed to act on the result of the checks. Going through the use cases it seems evident that these entities are not always the same and may be in fact separate from the client and server. Or is the charter ruling out this use case. My impression is that it is not. And therefore I think this document is not describing all requirements in regards to protocol operations, transport and security. 2. Section 7. Definitions of "MUST, SHOULD or MAY" used in the text. And please don't use RFC 2119 as they are not defined for requirement language. |
2008-01-10
|
07 | Sam Hartman | [Ballot Position Update] New position, No Objection, has been recorded by Sam Hartman |
2008-01-10
|
07 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
2008-01-10
|
07 | Dan Romascanu | [Ballot comment] Comment based on input from OPS-DIR member Kurt Eril Lindqvist: NEA was brought to the IETF partly by 'real' network managers who said … [Ballot comment] Comment based on input from OPS-DIR member Kurt Eril Lindqvist: NEA was brought to the IETF partly by 'real' network managers who said they had a real problem to solve. As this is fairly unusual these days, I have all respect for the fact that they wanted to solve a problem. I would also agree that NEA seems to solve a 'inventory problem' in a good way. The above said, I do have some scaling concerns. For example, I would assume that the posture client makes sure that not all clients on a large network would start initiating posture exchanges at the same time after for example a large power outage. The document in general talks very little about how the policies are to be managed and how the interaction with users is expected to be conducted. |
2008-01-10
|
07 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2008-01-10
|
07 | Ron Bonica | [Ballot Position Update] Position for Ron Bonica has been changed to Undefined from Discuss by Ron Bonica |
2008-01-10
|
07 | Ron Bonica | [Ballot discuss] The draft permits an assignment to be documented in an Internet Draft or in a RFC. It seems to be a bad idea … [Ballot discuss] The draft permits an assignment to be documented in an Internet Draft or in a RFC. It seems to be a bad idea to permit the document to be an ID since the ID may officially disappear. I'd suggest that assignments not become official unless documented in a published RFC. Perhaps no assignment should be made until an ID has been approved for publication. I consider this an operational issue because the current proposal could result in an assignment that has no document that can be referenced. |
2008-01-10
|
07 | Ron Bonica | [Ballot discuss] The draft permits an assignment to be documented in an Internet Draft or in a RFC. It seems to be a bad idea … [Ballot discuss] The draft permits an assignment to be documented in an Internet Draft or in a RFC. It seems to be a bad idea to permit the document to be an ID since the ID may officially disappear. I'd suggest that assignments not become official unless documented in a published RFC. Perhaps no assignment should be made until an ID has been approved for publication. I consider this an operational issue because the current proposal could result in an assignment that has no document that can be referenced. |
2008-01-10
|
07 | Ron Bonica | [Ballot Position Update] New position, Discuss, has been recorded by Ron Bonica |
2008-01-10
|
07 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2008-01-10
|
07 | Jari Arkko | [Ballot discuss] I am concerned that some of the requirements on PT protocols may not be practical. For instance, EAP is not a good transport … [Ballot discuss] I am concerned that some of the requirements on PT protocols may not be practical. For instance, EAP is not a good transport protocol for large amount of data, current EAP methods do not allow such extra data transport, RADIUS may not be able to allow server-initiated exchanges in the middle of a session, etc. |
2008-01-10
|
07 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2008-01-10
|
07 | Chris Newman | [Ballot comment] This requirements effort is clearly excessive due to the length and complexity of this document. It's certainly time to start real work and … [Ballot comment] This requirements effort is clearly excessive due to the length and complexity of this document. It's certainly time to start real work and not waste time on requirements any longer. I also suspect anything that meets all the requirements will suffer second system syndrome badly and fail to deploy. Think simple. A few cautions from my applications experience based on some of the questionable requirements: * It is likely that the ease of debugging the protocol will be much more important in practice than the number of octets it consumes. A binary protocol is probably not a good idea here. If you really have bandwidth issues, a general purpose compression layer (e.g. the one available as a TLS or SSH option) is usually better than custom binary complexity that makes the protocol harder to debug. * It's my experience that trying to flatten truly structured data into attribute/value pairs (where all sorts of hierarchy semantics get some sort of nasty encoding in the attribute names) is a mistake. If you really need to get into the bowels of firewall configuration (something I doubt) then you'll want support for generic structure, and likely XML is your best choice for representing extensible generic structure. Netconf might be a good fit for this... |
2008-01-10
|
07 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2008-01-10
|
07 | Cullen Jennings | [Ballot discuss] Reading section 8.3.1 ... I would like the document to be slightly more explicit about what the requirements are around MITM. Is it … [Ballot discuss] Reading section 8.3.1 ... I would like the document to be slightly more explicit about what the requirements are around MITM. Is it a requirement that the system protect against a malware infested system joining the network by being a MITM attack on a "clean endpoint"? I can go with yes or no but if it is no, I think we need to clearly say the NEA does not do that and if yes, then make it a bit clearer that this is a requirement. It's possible the document clear says this somewhere and I just blurred over reading it - so if that happened just point me to the right place. Thanks. |
2008-01-10
|
07 | Cullen Jennings | [Ballot Position Update] New position, Discuss, has been recorded by Cullen Jennings |
2008-01-08
|
07 | Russ Housley | [Ballot comment] Comments are from Scott Brim's Gen-ART Review. Abstract - "evaluate the posture of a system" For clarity please use … [Ballot comment] Comments are from Scott Brim's Gen-ART Review. Abstract - "evaluate the posture of a system" For clarity please use "endpoint" (as you do throughout the rest of the document) instead of "system". A naive reader can't tell if "system" refers to the entire system dealt with in the reference model (just discussed, so in the reader's mind) or a client end system, a home network or what. Maybe "system" is a relict. 2. Terminology - "Attribute - Data element including any requisite meta-data describing an observed, expected or operational status of an endpoint feature (e.g. anti-virus software)." I understand the difference between observed and expected, but what's the difference between observed and operational? If there is one, maybe you could use a few more words to make the difference clear. - "Endpoint - Any host computing device that can be connected ..." Delete "host". This isn't the 1970s anymore, or even the 1980s. Most endpoints don't host anything. Make this a global change except where well-established protocols or concepts have "host" in their name. - "The owner may permit user override or augmentation of control policies or may not assert any policies limiting use of asset." "may not" is almost always dangerously ambiguous regardless of capitalization. It could mean that the owner is not allowed to assert any policies. How about: "or may not" -> "and need not". - "Posture Attributes - Attributes describing a quality or status (posture) of an feature of the endpoint." Above, in "posture", you said "configuration or status", which makes sense. Here you have "quality or status of an feature". "Quality" is undefined here. I would avoid it. By the way change "an feature" -> "a feature" if you don't delete it. 4. Problem Statement - "Endpoints that are not NEA-capable or choose not to share sufficient posture to evaluate compliance may be subject to different access policies." They are subject to the same *policies*, but the result of *applying* those policies may be different (e.g. limited access). Perhaps you can say "... subject to different application of access policies", or if you don't like that perhaps "... subject to different access policy rules". 5. Reference Model - I would expand the PA and PB acronyms the first time they are used here. They are expanded up at the beginning of Scope, but not here, where they discussed for a while before being expanded. - "The specific methods of referencing the configuration and establishing the communication channel are out of scope for the NEA reference model and should be covered in the specifications of candidate protocols for the Posture Transport (PT) protocol." I would delete "and should be ... ". Just say it's out of scope, not which draft it should be covered in. Give yourself the freedom to cover the issue in other drafts any way you like. 5.1.1 NEA client - "Endpoints lacking NEA Client software (which is out of NEA scope) or choosing not to provide the attributes required by the NEA Server could be considered non-compliant and subject to different access policies." Same comment on Section 4. To me, the access policies seem to be the same, but different rules within policies apply. For clarity I would end the sentence at "could be considered non-compliant". That's all you need to say. Stop there. 6.1.1.1 example - "The NEA Server determines that the system is lacking a recent security patch designed to fix a serious vulnerability and the system is placed on a restricted access network. ... Later, the desktop requests again to join the network and this time is allowed on the enterprise network ..." Could you be clearer about "the enterprise network" etc.? When you say placed on a restricted access network, are you talking about an L2 VPN? Obviously the endpoint is "on the network", perhaps even "the enterprise network", or you wouldn't be able to do the assessment in the first place. (This is a global, but not straightforward, change.) 7.2 PA requirements - "PA-1 The PA protocol MUST support communication of an extensible set of NEA standards defined attributes. These attributes will be uniquely identifiable from non-standard attributes." "uniquely identifiable from" -> "distinguishable from" - "PA-2 The PA protocol MUST support communication of an extensible set of vendor-specific attributes. These attributes will be segmented into uniquely identifiable vendor specific name spaces." "uniquely identifiable" -> "uniquely identified". "vendor specific" -> "vendor-specific". 7.3 PB requirements - "PB-2 The PB protocol MUST NOT interpret the contents of PA messages being carried, i.e., the data it is carrying must be opaque to it." Do you really care if PB happens to interpret PA, perhaps for some kind of monitoring? Is there a confidentiality issue between PA and PB? Or is the real requirement that there can't be a dependency -- the PB protocol MUST NOT depend on interpreting PA messages in order to meet the requirements of supporting PA. 7.4 PT requirements - Same comment as for 7.3 on "must not interpret". |
2008-01-08
|
07 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2008-01-08
|
07 | Lars Eggert | [Ballot comment] Section 7., paragraph 0: > 7. Requirements (Only Normative Section) This is an Informational document and hence cannot have any normative … [Ballot comment] Section 7., paragraph 0: > 7. Requirements (Only Normative Section) This is an Informational document and hence cannot have any normative sections. I suggest to remove the text in parens from the heading and rephrase the first sentence of the following paragraph. Section 7.3, paragraph 9: > PB-6 The PB protocol MUST support grouping of attribute messages > to optimize transport of messages and minimize round trips. If by "minimize round trips" you mean "minimize delay", grouping messages will do the exact opposite - it will end up increasing delay. Section 7.4, paragraph 7: > PT-5 The PT protocol SHOULD be able to run between a NEA Client > and NEA Server over TCP or UDP (similar to LDAP). TCP gives you the transport mechanisms that PT-3 requires. UDP does not, and in order to use UDP, NEA will need to specify mechanisms for fragmentation, reliable delivery, duplication detection and reordering for itself. As I mentioned in my DISCUSS above, I strongly urge NEA to pick a single transport protocol, such as TLS-over-TCP, which seems to have all the mechanisms needed to support requirements PT-1 to PT-4. |
2008-01-08
|
07 | Lars Eggert | [Ballot discuss] Section 5., paragraph 0: > 5. Reference Model DISCUSS: I'm missing a paragraph that discusses how NEA intersect with multihoming. On … [Ballot discuss] Section 5., paragraph 0: > 5. Reference Model DISCUSS: I'm missing a paragraph that discusses how NEA intersect with multihoming. On a multihomed end system, is a separate NEA client instatiated per network interface? Or is the same NEA client handling interactions with NEA servers across different devices, and if so, does it use the same identifier with multiple NEA servers? Section 5.1.1.2, paragraph 2: > The Posture Broker Client also multiplexes the responses from > the Posture Collector(s) and returns them to the NEA Server. The > Posture Broker Client constructs one or more PB messages using > the PA message(s) it obtains from the Posture Collector(s) > involved in the assessment. The quantity and ordering of > Posture Collector responses (PA message(s)) multiplexed into the > PB response message(s) can be determined by the Posture Broker > Client based on many factors including policy or characteristics > of the underlying network transport (e.g. MTU). A particular > NEA Client will have one Posture Broker Client. DISCUSS: (This is a discuss-discuss.) I don't understand how characteristics of a network link (such as the MTU given as an example) can be used as an identifier for multiplexing, given that an end system can have several interfaces with identical characteristics. Also, I assume that there will be posture information that isn't related to a network interface - what will be used as a multiplexing identifier for that? Section 7.1, paragraph 8: > C-7 The protocols MUST support efficient transport of a large > number of attribute messages between the NEA Client and > the NEA Server. DISCUSS: Many of the protocols mentioned in C-4 as "transport" protocols (EAP/802.1X, PANA, and IKE/IPsec) lack important features required for the transmission of significant amounts of data. TLS-over-TCP seems to be the only directly usable option among the examples; all other listed examples require additional mechanisms before they can be used for the efficient transmission of significant amounts of data. I'd like to understand why it is considered important to have NEA operate over all these different underlying protocols, instead of focusing on a single option, such as TLS-over-TCP. Different transport options will add a huge amount of complexity to NEA, and will require the definition of transport functionality that I'm not convinced the NEA WG has the expertise for. Section 7.3, paragraph 7: > PB-4 The PB protocol MUST be capable of supporting a half-duplex > PT protocol. However this does not preclude PB from > operating full-duplex when running over a full-duplex PT. DISCUSS: It's not clear to me what is meant here by "half-duplex PT protocol"; could you give an example? The way I read this, it means "must support a transport protocol where only one end emits packets", which is extremely unusual for IP communication. All of the examples you have given above as transport protocols aren't half-duplex. |
2008-01-08
|
07 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2007-12-29
|
07 | Tim Polk | Placed on agenda for telechat - 2008-01-10 by Tim Polk |
2007-12-27
|
07 | Tim Polk | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Tim Polk |
2007-12-27
|
07 | Tim Polk | [Ballot Position Update] New position, Yes, has been recorded for Tim Polk |
2007-12-27
|
07 | Tim Polk | Ballot has been issued by Tim Polk |
2007-12-27
|
07 | Tim Polk | Created "Approve" ballot |
2007-12-24
|
07 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2007-12-18
|
07 | Amanda Baber | IANA Last Call comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
2007-12-11
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2007-12-11
|
07 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker |
2007-12-10
|
07 | Amy Vezza | Last call sent |
2007-12-10
|
07 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2007-12-07
|
07 | Tim Polk | Last Call was requested by Tim Polk |
2007-12-07
|
07 | Tim Polk | State Changes to Last Call Requested from Publication Requested by Tim Polk |
2007-12-07
|
07 | (System) | Ballot writeup text was added |
2007-12-07
|
07 | (System) | Last call text was added |
2007-12-07
|
07 | (System) | Ballot approval text was added |
2007-12-07
|
07 | Tim Polk | Steve Hanna is the document shepherd. |
2007-12-07
|
07 | Tim Polk | Draft Added by Tim Polk in state Publication Requested |
2007-11-01
|
05 | (System) | New version available: draft-ietf-nea-requirements-05.txt |
2007-08-28
|
04 | (System) | New version available: draft-ietf-nea-requirements-04.txt |
2007-07-11
|
03 | (System) | New version available: draft-ietf-nea-requirements-03.txt |
2007-05-01
|
02 | (System) | New version available: draft-ietf-nea-requirements-02.txt |
2007-03-05
|
01 | (System) | New version available: draft-ietf-nea-requirements-01.txt |
2007-01-10
|
00 | (System) | New version available: draft-ietf-nea-requirements-00.txt |