Guidelines for IPFIX Implementations on Middleboxes Juergen Quittek, Martin Stiemerling 59th IETF meeting, IPFIX WG

IETF 59 IPFIX WG2 Middleboxes “A middlebox is defined as any intermediary device performing functions other than the normal, standard functions of an IP router on the datagram path between a source host and destination host.” (RFC3234)

IETF 59 IPFIX WG3 Middleboxes in RFC NAT, 2. NAT-PT, 3. SOCKS gateway, 4. IP tunnel endpoints, 5. packet classifiers, markers, schedulers, 6. transport relay, 7. TCP performance enhancing proxies, 8. load balancers that divert/munge packets, 9. IP firewalls, 10. application firewalls, 11. application-level gateways, 12. gatekeepers / session control boxes, 13. transcoders, 14. proxies, 15. caches, 16. modified DNS servers, 17. content and applications distribution boxes, 18. load balancers that divert/munge URLs, 19. application-level interceptors, 20. application-level multicast, 21. involuntary packet redirection, 22. anonymizers. Bold printed middleboxes act per packet do not modify application level payload do not insert additional packets Only those are considered.

IETF 59 IPFIX WG4 Middlebox Traffic Flow Scenarios Uni-directional traffic flow traversing a middlebox Uni-directional traffic flow traversing a middlebox with multicast function Bi-directional unicast traffic traversing a middlebox Bi-directional traffic flow traversing a tunnel endpoint TT’ Middlebox TT’’ T’ T’’’ Middlebox T_lT_r Middlebox T_lT_r2 T_r1 T_r3

IETF 59 IPFIX WG5 Location of Observation Point MUST clearly indicate location of observation point Observation point located within middlebox:  Leads to ambiguous result since packet properties may change in middlebox  Example NAT: must be clear if reported source IP address was observed before or after address translation Observation point should be located outside of the middlebox Observation point at composed middleboxes  May be inside  But MUST be located between middlebox functions

IETF 59 IPFIX WG6 Reporting Flow-related Mbox Internals Even if observation point is located outside of middlebox reporting middlebox internals might be desirable. Recommendations given for  Packet dropping middleboxes  Middleboxes changing DSCP  Middleboxes changing addresses  IP addresses and port numbers  Tunnel endpoints

IETF 59 IPFIX WG7 Packet Dropping Middleboxes SHOULD report number of dropped packets per reported flow Considered middleboxes: 1. NAT, 2. NAT-PT, 3. SOCKS gateway, 5. packet classifiers, markers, schedulers, 9. IP firewalls, 10. application firewalls

IETF 59 IPFIX WG8 Middleboxes changing DSCP SHOULD report beside observed value of the DSCP also the value of the DSCP on the ‘other’ side if the middlebox Considered middleboxes: 5. Packet markers

IETF 59 IPFIX WG9 Middleboxes changing addresses SHOULD report beside observed value also the ‘translated’ value  Translated value means value on other side of middlebox, independent of flow direction Considered middleboxes: 1. NAT 2. NAPT 3. SOCKS gateway 21. Involuntary packet redirection Those middleboxes potentially modify:  IP version field  IP source and destination address field  TCP source and destination port number  UDP source and destination port number

IETF 59 IPFIX WG10 Tunnel endpoints SHOULD report corresponding tunnel ID Middlebox T_lT_r2 T_r1 T_r3 Report Tunnel ID Report nothing

IETF 59 IPFIX WG11 Open Issues Do NATS change DSCP? Investigate security implications of reporting middlebox internals Shall this become an IPFIX WG work item?