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; [email protected]; [email protected]
> Cc: Black, David; Christian Vogt; Jean-Michel Combes; Jari Arkko;
> [email protected]
> 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
> [email protected] Mobile: +1 (978) 394-7754
> ----------------------------------------------------
>
