Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-07

["Black, David" <[e-mail]>]

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; [e-mail]; [e-mail]
> Cc: Jean-Michel Combes; Ted Lemon; [e-mail]; Black, David; [e-mail]
> 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; [e-mail]; gen-
> [e-mail]
> > Cc: Black, David; Christian Vogt; Jean-Michel Combes; Jari Arkko;
> > [e-mail]
> > 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
> > [phone]             FAX: [phone]
> > [e-mail]        Mobile: [phone]
> > ----------------------------------------------------
> >