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

[Russ Housley <[e-mail]>]

David:

Thanks for your efforts on this document.  Your first review was in May 2011, and the document has improved greatly for you continued pushing on the concerns.

Russ


On Apr 3, 2013, at 1:04 PM, Black, David wrote:

> 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]
>>> ----------------------------------------------------
>>> 
>