IPFIX Requirements: Document Changes and New Issues Raised Jürgen Quittek, NEC Benoit Claise, Cisco Tanja Zseby, Sebstian Zander, FhG FOKUS
2 © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 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
3 © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg Document Changes from -09 to 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 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
4 © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg Document Changes from -09 to 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)
5 © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 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?
6 © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 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-and- such 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
7 © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 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.
8 © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 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
9 © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 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
10 © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg 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...
11 © NEC Europe Ltd., 2002 Network Laboratories, Heidelberg Next Steps Agree on changes Submit version -11 in August Do we need another last call?
Thank You!