The -07 version of this draft resolves all of the issues raised by the Gen-ART review of the -06 version. Discussion of the review with the authors has resulted in a common understanding that there is no need for additional text on statically allowing all source addresses through all links in a set of teamed/aggregated links - that's at best "nice to have" for this draft, but not essential. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Monday, March 25, 2013 9:04 PM > To: McPherson, Danny; Fred Baker; joel.halpern at ericsson.com; gen-art at ietf.org > Cc: Jean-Michel Combes; Ted Lemon; savi at ietf.org; Black, David; ietf at ietf.org > Subject: Gen-ART review of draft-ietf-savi-threat-scope-06 > > 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 at ericsson.com; gen- > art at ietf.org > > Cc: Black, David; Christian Vogt; Jean-Michel Combes; Jari Arkko; > > savi at ietf.org > > 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 at emc.com        Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > >