I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-savi-threat-scope-05 Reviewer: David L. Black Review Date: 12 May 2011 IETF LC End Date: 18 May 2011 Summary: This draft is on the right track, but has open issues, described in the review. This draft discusses the threats and deployment environment for IP source address validation with particular attention to finer-grain validation that could be used within a network to validate IP addresses closer to the sources of network traffic than ingress to an ISP's network. Major issues: There is no discussion of link teaming or aggregation (e.g., via LACP); this may affect source address validation functionality by requiring the same validation checks on all aggregated ports. An important case to discuss is where the aggregated host links are connected to ports on different switches (e.g., in an active/passive configuration). The discussion of multi-instance hosts in section 5.2.3 is incomplete in several important aspects: (1) Some of the software switch implementations are single instance switches whose implementation is distributed across multiple physical servers. This results in concerns similar to the link aggregation discussion above. (2) Live migration of virtual machines among physical servers causes relocation of MAC addresses across switch ports. A so-called "gratuitous ARP" is often used to inform the network of the MAC address move; port-based source address validation information needs to move in response to such ARPs. (3) MAC address relocation is also used as a failure recovery technique; the surviving hardware element (e.g., host in a cluster) takes over the MAC addresses of the failed hardware; like the previous case, a "gratuitous ARP" is a common means of informing the network that the MAC address has moved, and source address validation information needs to move in response to it. Minor issues: There doesn't seem to be much discussion of dynamic network reconfiguration, which may change traffic egress points. VRRP may be a useful example to discuss beyond the typical routing protocol updates to forwarding tables. Nits/editorial comments: idnits 2.12.11 ran clean. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [email protected] Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
