1 / 35

NEA Working Group IETF 72

NEA Working Group IETF 72. nea[-request]@ietf.org http://tools.ietf.org/wg/nea Co-chairs: Steve Hanna shanna@juniper.net Susan Thomson sethomso@cisco.com. Agenda Review. 0900 Administrivia Blue Sheets Jabber & Minute scribes Agenda bashing 0905 WG Status

kacy
Download Presentation

NEA Working Group IETF 72

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NEA Working GroupIETF 72 nea[-request]@ietf.org http://tools.ietf.org/wg/nea Co-chairs: Steve Hanna shanna@juniper.net Susan Thomson sethomso@cisco.com

  2. Agenda Review 0900 Administrivia Blue Sheets Jabber & Minute scribes Agenda bashing 0905 WG Status 0910 Protocol Overview 0915 Changes in -01 version of PB-TNC and PA-TNC: http://www.ietf.org/internet-drafts/draft-ietf-nea-pa-tnc-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nea-pb-tnc-01.txt 0930 Protocol Flows 1015 Proposed Changes in -02 version of PB-TNC and PA-TNC 1100 Open Discussion 1125 Review Milestones 1130 Adjourn

  3. WG Accomplishments since IETF71 • Consensus Check on PA-TNC, PB-TNC as WG docs (Mar 2008) • PA-TNC and PB-TNC -00 I-D (April 2008) • WG Last Call for NEA requirements (April 2008) • NEA Requirements published as RFC 5209 (May 2008) • PA-TNC and PB-TNC -01 I-D (July 2008) http://www.ietf.org/internet-drafts/draft-ietf-nea-pa-tnc-01.txt http://www.ietf.org/internet-drafts/draft-ietf-nea-pb-tnc-01.txt

  4. NEA Protocol Overview

  5. NEA Reference Modelfrom RFC 5209 NEA Client NEA Server Posture Attribute (PA) protocol Posture Collectors Posture Validators Posture Broker (PB) protocol Posture Broker Client Posture Broker Server Posture Transport Client Posture Transport Server Posture Transport (PT) protocols

  6. PA-TNC Within PB-TNC PT PB-TNC Header PB-TNC Message (Type=PB-Batch-Type, Batch-Type=CDATA) PB-TNC Message (Type=PB-PA, PA Vendor ID=0, PA Subtype= OS) PA-TNC Message PA-TNC Attribute (Type=Product Info, Product ID=Windows XP) PA-TNC Attribute (Type=Numeric Version, Major=5, Minor=3, ...)

  7. Changes in PB-TNC , PA-TNC Version -01

  8. Changes in -01 versions ofPB-TNC and PA-TNC Steve Hanna <shanna@juniper.net> Kaushik Narayan <kaushik@cisco.com> IETF 72

  9. Common changes • Scaled back text on TCG/TNC • Added Design Considerations • Added evaluation for Requirement C-11 • Added Appendix A (flows/use cases) • Added Kaushik Narayan as co-editor

  10. Changes only in PB-TNC -01 • MUST send error if message len < 12

  11. PB-TNC Design Considerations (Section 2) • Efficiency • Binary TLVs • Vendor ID • SMI PEN, assigned by IANA • Avoids collisions between vendor-defined values • IETF Standard values use Vendor ID 0 • Two Choices for Message Addressing • PB-TNC Message Type (when EXPL = 0) • PVs and PCs Subscribe To Message Types • Message Type = PB-TNC Vendor ID + PA Subtype • Explicit Delivery (when EXPL = 1) • PBC/PBS delivers message only to one PC/PV • PC/PV identified by PC ID or PV ID field

  12. Changes only in PA-TNC -01 • Added Field Types • Defines commonly used primitive types in the value field of attributes. • Types include • OctetArray (Binary data) • Integer (32 bit unsigned integer) • String (UTF-8 encoded Octet Array) • IPv4Address • IPv6Address • TimeString (UTC, RFC3339 compliant string) • VersionNum (64 bit value with major & minor version)

  13. PA-TNC Design Considerations (Section 2) • Standard attribute namespace • Standard PA sub-types and attributes to enable multi-vendor interoperability. • Vendor specific namespace • Vendor specific PA sub-types and attributes to enable vendor differentiation and agility • TLV encoding • Binary encoding to optimize for bits-on-the-wire and CPU utilization.

  14. NEA Protocol Flows

  15. Proposed Changes in PB-TNC, PA-TNC Version -02

  16. Proposed updates toPosture Broker protocoldraft-ietf-nea-pb-tnc-01.txt Ravi SahitaIETF 72 NEA WGJuly 31, 2008

  17. Outline of proposed changes to NEA Posture Broker protocol • Simplification items • New proposed changes • Protocol changes to allow unsolicited retries • Evaluation results

  18. Simplification: Reduce Message Types • Move PB-Batch-Type into PB-TNC header • PB-Batch-Type carried with every batch 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version|D|Reserved | Batch Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Batch Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  19. Proposed Addition of unsolicited retries to Posture Broker Protocol • Allow Unsolicited Retry from NEA Client or Server at any time (if PT allows) • Support matching requests to response messages by adding a Message Id to the protocol • Update error reporting parameters message to allow indicating erroneous message by specifying Message Id • See updated state machine on next slide

  20. Posture Broker - Updated State Machine

  21. Proposed Addition of Global Assessment Decision • Indicates posture assessment result to the posture broker client • Does not replace Access-Recommendation message type • Suggested Values • Compliant • Non-compliant • Non-compliant major issue • Error • Don’t Know Result

  22. Proposed updates toPosture Attribute protocoldraft-ietf-nea-pa-tnc-01.txtPaul SangsterIETF 72 NEA WGJuly 31, 2008

  23. PA-TNC Proposed Changes • New Approach to Attribute Correlation • Add PA-TNC Assessment Result Attribute • Add PA-TNC Remediation Attribute

  24. Correlation ID • Correlation ID • Only used when PC reports posture on multiple implementations of component • ID allows PV to associate attributes describing same implementation • Attributes are atomic so PV needs to know which implementation associated with attribute (e.g. which AV has version 1.2.3?) • Not expected to be the common case

  25. Proposed New Approach to Correlation • Proposal • Remove PA-TNC Correlation ID • Integrate semantics into PB-TNC Header’s Posture Collector ID (PC ID) • PC ID is source identifier for use by PV • Now some PCs might have multiple PC IDs • Each component implementation needs separate PA-TNC message (with different PC IDs) • PV doesn’t know that single PC supporting multiple implementations of same component • Both appear as separate PCs • PC associates different PC IDs with different implementations of same component type

  26. Before Correlation Change PT PB-TNC Header PB-TNC Message TLV (Type=PB-Batch-Type, Batch-Type=CDATA) PB-TNC Message TLV (Type=PB-PA, PA Vendor=0, PA Subtype=OS) PB-PA TNC Header PA-TNC Attribute TLV (Type=Prod Info, Prod ID=Norton AV, C=1) PA-TNC Attribute TLV (Type=Numeric Version, Maj=5, Min=3, C=1) PA-TNC Attribute TLV (Type=Prod Info, Prod ID=McAfee AV, C=2) PA-TNC Attribute TLV (Type=Numeric Version, Maj=1, Min=2, C=2)

  27. After Correlation Change PT PB-TNC Header PB-TNC Message TLV (Type=PB-Batch-Type, Batch-Type=CDATA) PB-TNC Message TLV (Type=PB-PA, PA Vendor=0, PA Subtype=OS) PB-PA TNC Header -4B PA-TNC Attribute TLV (Type=Prod Info, Prod ID=Norton AV) -4B PA-TNC Attribute TLV (Type=Numeric Version, Maj=5, Min=3) PB-TNC Message TLV (Type=PB-PA, PA Vendor=0, PA Subtype=OS) +12B +12B PB-PA TNC Header -4B PA-TNC Attribute TLV (Type=Prod Info, Prod ID=McAfee AV) -4B PA-TNC Attribute TLV (Type=Numeric Version, Maj=1, Min=2)

  28. Correlation ID Trade-Off • Benefit • Simplifies PA-TNC Attribute Header • Removes optional Attribute Header field and flag • Less bits on wire when many attributes sent for same component (more common case) • Cost • Attributes about each implementation must be in separate PB-TNC messages • More bits on wire when fewer attributes for multiple products reported (less common case) • Potentially more complex PBC, PBS implementation

  29. Proposed Addition of Assessment Result Attribute • PA Result Attribute conveys PV’s compliance decision about component • Not mandatory to send • Largely informational for Posture Collector • Posture Collector would learn if assessment was deemed compliant only for its peer Posture Validator • Could be accompanied by new Remediation Attribute

  30. Proposed Addition of Remediation Attribute • PA-TNC Remediation Attribute allows PV to provide repair instructions to PC • Remediation instructions allows for standard and vendor-defined data formats • Parallels current PB-Remediation-Parameters TLV • Exclusive delivery may be required so only one PC performs remediation

  31. Open Mic

  32. Additional Attribute? • What additional standard attributes should be included in the standard? • Currently have: • Attribute Request • Product Information • Numeric Version • String Version • Operational Status • Port Filter • Installed Packages • PA-TNC Error

  33. Additional Components? • What additional standard components should be included in the standard? • Currently have: • Operating System • Anti-Virus • Anti-Spyware • Anti-Malware • Firewall • Host-based Intrusion Detection/Prevention Software • Virtual Private Network

  34. Milestones Done Proposals for PA and PB due Done Review and resolve proposals at IETF 71 Done Post first WG version of PA and PB Done Post second version of PA and PB Jul 2008 Resolve issues at IETF 72 Aug 2008 Post third version of PA and PB Sep 2008 WGLC on PA and PB Nov 2008 Resolve WGLC comments at IETF 73 Post fourth version of PA and PB Dec 2008 IETF LC for PA and PB Jan 2009 IESG considers PA and PB for Proposed Standard

  35. Next Steps • Raise proposed changes on mailing list. • Submit -02 version of PA-TNC, PB-TNC protocols based on comments received

More Related