I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-savi-threat-scope-06 Reviewer: David L. Black Review Date: March 27, 2013 IESG Telechat Date: (if known) Summary: This draft is on the right track, but has open issues, described in the review. Looking at the original Gen-ART review of the -05 draft and checking the diffs between -05 and -06, the issues raised by that review have only been partially addressed: > 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). This is partially addressed on 4.1.2 (new section in -06), but only in terms of moving validation state when something like LACP reconfigures. This has a couple of shortcomings: a) the alternative of statically allowing all source addresses through all teamed/aggregated links (decouples SAVI state from link teaming/aggregation state) should also be mentioned, and b) the new text implies that LACP is the only way to cause this situation - it's not, so LACP should be used as an example. VRRP is another example. > (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. I don't think this has been addressed, but the notion of single-instance switches could be added to the generalization of the new text in 4.1.2. > (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. A paragraph has been added to 5.2.3 to address all three of the above concerns. I guess that's ok, but I would have liked to see some text pointing out that a MAC move can be detected by the switches and used to update SAVI state about which port(s) a MAC is accessed through. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, May 13, 2011 1:03 AM > To: McPherson, Danny; Fred Baker; joel.halpern@xxxxxxxxxxxx; gen-art@xxxxxxxx > Cc: Black, David; Christian Vogt; Jean-Michel Combes; Jari Arkko; > savi@xxxxxxxx > Subject: Gen-ART review of draft-ietf-savi-threat-scope-05 > > 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 > david.black@xxxxxxx Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >