Transcript PPT Version
IPFIX Requirements: Document Changes and New Issues Raised <draft-ietf-ipfix-reqs-10.txt> Jürgen Quittek, NEC Benoit Claise, Cisco Tanja Zseby, Sebstian Zander, FhG FOKUS Recent History • • • • WG last call before IETF56 -> version -09 received comments from IESG reviewers in April updated draft in June (version -10) since then – received additional comments from IESG – received feedback on our changes from IESG © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 2 Document Changes from -09 to -10 1. timestamp resolution reference 2. reporting TOS/traffic class octet or reporting DSCP • DHCP part of TOS/traffic class octet 3. location of reference to RFC 2119 4. bad wording in section 6.3.3, last paragraph 5. describe potential problem of faked DoS attack 6. location of appendix 7. consistency of appendix • 17 changes © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 3 Document Changes from -09 to -10 8. More concrete definition of byte counter • number of bytes of IP header and IP payload 9. More concrete definition of multicast replication factor • At the time of reporting 10. More concrete definition of BGP-related attributes: • BGP source, destination, next-hop AS number 11. Address the reliability issue of usage based accounting 12. & 13. Confidentiality from SHOULD to MUST & Anonymization from MAY to MUST • MUST be covered by the IPFIX protocol specification • The protocol specification may declare the feature as MUST, SHOULD or MAY for implementations 14. Move paragraph on remote configuration up (out of section 7.2) © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 4 Responses • Allison Mankin on Confidentiality and Anonymization: „The document still leaves it the case that ipfix implementations will generally have a strong option not to implement anonymization, and will have some choice not to implement confidentiality. These are not mandatory-to-use, but the requirements should be indicating they are recommended or mandatory-to-implement.“ • What is the working group‘s position? © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 5 Further Comments • Steve Bellovin – 4.2(4) What about link-layer distinguisher of IP version? – 4.3 What about SCTP? – 4.4, 4.5, and others: This document can't say "If the observation point is located at a foo". At most, it can say "a foo-capable box MUST" or "a box SHOULD do such-andsuch so that it can be located at a foo". – 4.6 strikes me as dubious for compression. – What about the IPv6 Flow Label as a flow separator? • Randy Presuhn – 20 editorial comments © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 6 What about link-layer distinguisher of IP version? 4.2. IP Header Fields The metering process MUST, SHOULD, or MAY be able to separate flows by the following fields of the IP header as indicated. 1. source IP address (MUST) 2. destination IP address (MUST) 3. protocol type (TCP,UDP,ICMP,...) (MUST) 4. IP version number (SHOULD) This requirement only applies if the observation point is located at a device that is supporting more than IP version. For source address and destination address, separating by full match MUST be supported as well as separation by prefix match. © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 7 What about SCTP? 4.3. Transport Header Fields The metering process MUST be able to separate flows by the port numbers of the transport header in case of TCP or UDP being used as transport protocol. Both, source and destination port number MUST be supported for distinguishing flows, individually as well as in combination. Suggestion: add a SHOULD clause on SCTP © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 8 Dubious for compression 4.6. Header Compression and Encryption If header compression or encryption is used, the metering process might not be able to access all header fields. A metering process MUST meet the requirements stated in this section 4 only for packets that have the relevant header fields not compressed and not encrypted. Suggestion: remove header compression © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 9 What about the IPv6 Flow Label as a flow separator? Suggestions: (1) add a MAY clause or (2) ignore If we choose (1) we also can add a lot of other attributes in MAY clauses ... © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 10 Next Steps • Agree on changes • Submit version -11 in August • Do we need another last call? © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 11 Thank You!