Subject: [Gen-art] Gen-ART review of draft-ietf-savi-threat-scope-06

From: "Black, David" <[email-masked]>
Date: Mon, 25 Mar 2013 21:04:08 -0400

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

---

From: "Black, David" <[email-masked]>
Date: Mon, 25 Mar 2013 21:08:04 -0400

> Review Date: March 27, 2013

Copy/paste glitch - that should be March 25 for obvious reasons ...

Thanks,
--David

> Sent: Monday, March 25, 2013 9:04 PM
> Cc: Jean-Michel Combes; Ted Lemon; [email-masked]; Black, David; [email-masked]
> Subject: Gen-ART review of draft-ietf-savi-threat-scope-06
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 26 Mar 2013 01:37:54 +0000

On Mar 25, 2013, at 9:04 PM, "Black, David" <[email-masked]> wrote:
> Summary: This draft is on the right track, but has open issues, described in the review.

While I identified the same issue you did with switching systems that do link aggregation and other magic, I think that the document is useful whether this is fixed or not.  It's true that it doesn't have a full section that talks specifically about this problem, but I think it's unlikely that the authors are going to add one—when I mentioned it to Joel, he didn't express excitement at the prospect.

I think Fred's response, while a little salty, accurately represents the situation: the working group produced this document, the document does what it's supposed to do, one could continue to polish it indefinitely, but then the document would never get published.

Remembering that this is an informational draft, which does a pretty good job of informing the reader about the problem space, is it your opinion that the issues you have raised _must_ be addressed before the document is published, or do you think the document is still valuable even if no further text is added to address your concern?

---

From: "Black, David" <[email-masked]>
Date: Tue, 26 Mar 2013 19:45:04 -0400

Ted,

> Remembering that this is an informational draft, which does a pretty good job
> of informing the reader about the problem space, is it your opinion that the
> issues you have raised _must_ be addressed before the document is published,
> or do you think the document is still valuable even if no further text is
> added to address your concern?

At a minimum, in section 4.1.2, this should be addressed:

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.

I'm not sure I've seen Fred's response, but that change would suffice.  An RFC
Editor note should suffice.

Thanks,
--David

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Monday, March 25, 2013 9:38 PM
> To: Black, David
> Cc: McPherson, Danny; Fred Baker; [email-masked]; [email-masked];
> Jean-Michel Combes; [email-masked]; [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-savi-threat-scope-06
> 
> While I identified the same issue you did with switching systems that do link
> aggregation and other magic, I think that the document is useful whether this
> is fixed or not.  It's true that it doesn't have a full section that talks
> specifically about this problem, but I think it's unlikely that the authors
> are going to add one-when I mentioned it to Joel, he didn't express excitement
> at the prospect.
> 
> I think Fred's response, while a little salty, accurately represents the
> situation: the working group produced this document, the document does what
> it's supposed to do, one could continue to polish it indefinitely, but then
> the document would never get published.
> 
> Remembering that this is an informational draft, which does a pretty good job
> of informing the reader about the problem space, is it your opinion that the
> issues you have raised _must_ be addressed before the document is published,
> or do you think the document is still valuable even if no further text is
> added to address your concern?
>

---

From: Joel Halpern <[email-masked]>
Date: Wed, 27 Mar 2013 00:16:05 +0000

I think I can add text to address this. I will look more closely tomorrow, and send you a proposal.
Thank you for all your efforts reviewing this.

Yours,
Joel

Sent from my Android phone using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Black, David [[email-masked]]
Received: Tuesday, 26 Mar 2013, 7:45pm
To: Ted Lemon [[email-masked]]
CC: McPherson, Danny [[email-masked]]; Fred Baker [[email-masked]]; Joel Halpern [[email-masked]]; [email-masked] [[email-masked]]; Jean-Michel Combes [[email-masked]]; [email-masked] [[email-masked]]; [email-masked] [[email-masked]]
Subject: RE: Gen-ART review of draft-ietf-savi-threat-scope-06

Ted,

Thanks,
--David

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 27 Mar 2013 12:30:28 -0400

Would it suffice to replace
Old:
    If the bridging topologies which connects the switches changes, or
    if LACP [IEEE802.3ad] changes which links are used to deliver
    traffic, the switch may need to move the SAVI state to a different
    port, are the state may need to be moved or reestablished on a
    different switch.
New:
    If the bridging topologies which connects the switches changes, or
    if LACP [IEEE802.3ad], VRRP, or other link management
    operations, change which links are used to deliver
    traffic, the switch may need to move the SAVI state to a different
    port, are the state may need to be moved or reestablished on a
    different switch.
?

Proposed changes on the second - fourth lines above.
Yours,
Joel

On 3/26/2013 7:45 PM, Black, David wrote:
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi
>

---

From: "Black, David" <[email-masked]>
Date: Wed, 27 Mar 2013 12:42:40 -0400

That would do nicely.

Thanks,
--David

> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Wednesday, March 27, 2013 12:30 PM
> To: Black, David
> Cc: Ted Lemon; McPherson, Danny; [email-masked]; [email-masked]; gen-
> [email-masked]; Jean-Michel Combes; [email-masked]
> Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-06
>

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 27 Mar 2013 12:45:34 -0400

Then it will be done.  I will wait for the AD to decide what other 
changes are needed, and then will either make this change or include it 
in an RFC Editor note.

Thank you,
Joel

---

From: Ted Lemon <[email-masked]>
Date: Thu, 28 Mar 2013 02:56:30 +0000

On Mar 27, 2013, at 12:45 PM, Joel Halpern Direct <[email-masked]> wrote:

> Then it will be done.  I will wait for the AD to decide what other changes are needed, and then will either make this change or include it in an RFC Editor note.

>   port, are the state may need to be moved or reestablished on a

I think you probably meant "or", not "are", in the second word of the second-to-last line of the new text.

As far as I am concerned, given that David is happy with your recent change, I'm happy with it too.   However, since you are asking, if you were willing to also accommodate David's other request (see below) by adding some text to the document in section 5, that would be an added bonus:

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

So if you can do this, it would be much appreciated; if you can't do it, I think the document is valuable enough to move forward without this additional work.

---

From: Joel Halpern <[email-masked]>
Date: Thu, 28 Mar 2013 03:04:09 +0000

I will try to come up with a way to address the MAC move topic.  The challenge is to word it in such a way that it does not imply a new protocol for communicating such a move (Savi was/is prohibited by charter from doing protocol development.)
Yours,
Joel

> Sent: Wednesday, March 27, 2013 10:57 PM
> To: Joel Halpern Direct
> Cc: Black, David; Joel M. Halpern; McPherson, Danny; 
> [email-masked]; [email-masked]; [email-masked]; Jean-Michel 
> Combes; Joel Halpern
> > Then it will be done.  I will wait for the AD to decide 
> what other changes are needed, and then will either make this 
> change or include it in an RFC Editor note.
> 
> > Old:
> I think you probably meant "or", not "are", in the second 
> word of the second-to-last line of the new text.
> 
> As far as I am concerned, given that David is happy with your 
> recent change, I'm happy with it too.   However, since you 
> are asking, if you were willing to also accommodate David's 
> other request (see below) by adding some text to the document 
> in section 5, that would be an added bonus:
> 
> > 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 
> So if you can do this, it would be much appreciated; if you 
> can't do it, I think the document is valuable enough to move 
> forward without this additional work.
> 
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 29 Mar 2013 18:07:44 -0400

I have a draft version with this correction.
David, would adding:
           When such a move
           is done without changing the MAC address, the SAVI switches
           will need to update their state.  While the ARP may be
           helpful,
           traffic detection, switch based neighbor solicitation,
           interaction with orchestration system, or other means may be
           used.
to the end of 5.2.3 address your concern?  I am not sure whether I have 
the right end of the question here, given that SAVI can not create new 
protocol.

Yours,
Joel

---

From: "Black, David" <[email-masked]>
Date: Fri, 29 Mar 2013 18:58:55 -0400

Joel,

Yes, I think you do have the right end of the question, and that new text looks
ok, as the previous sentence introduces the gratuitous ARP.

To summarize, we've decided to address two of the three concerns from the review
of -06.  The third concern that will not be addressed is: 

>	state) should also be mentioned,

I'm satisfied with this outcome.

Thanks,
--David

> Sent: Friday, March 29, 2013 6:08 PM
> To: Ted Lemon
> Cc: Black, David; McPherson, Danny; [email-masked]; [email-masked]; gen-
> >> Then it will be done.  I will wait for the AD to decide what other changes
> are needed, and then will either make this change or include it in an RFC
> Editor note.
> >
> >> Old:
> > As far as I am concerned, given that David is happy with your recent change,
> I'm happy with it too.   However, since you are asking, if you were willing to
> also accommodate David's other request (see below) by adding some text to the
> document in section 5, that would be an added bonus:
> >
> >> 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.
> >
> > So if you can do this, it would be much appreciated; if you can't do it, I
> think the document is valuable enough to move forward without this additional
> work.
> >
> >