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

[Joel Halpern <[e-mail]>]

Antiquity lives on.  This draft is back from the dead.
Somehow, it made it to the IESG review without my finishing addressing 
your comments.  My apologies for that.   I am trying to finish this off.

You will see Monday afternoon a new draft in the repository, with a 
section 4.1.2 on LACP, and a new paragraph in 5.2.3 to note the issues 
around (virtual) host relocation.

I hope that these properly address your old but very well-taken comments.

(I can send it to you if you want itsooner.)

Thank you,
Joel M. Halpern

On 5/16/2011 1:09 PM, Joel M. Halpern wrote:
> I can plan to make these changes at the end of the last call.
> Joel
>
> On 5/16/2011 12:56 PM, [e-mail] wrote:
>> Joel,
>>
>> I think the LACP discussion could be added to 4.1.1.
>>
>> I also think that there's a general theme that needs to be covered
>> across all of 4.1.1 - 4.1.4: When there are multiple traffic egress
>> points from a domain (4.1.1 - 4.1.4 cover four different types of
>> domains), the SAVI checks on all the egresses should be coordinated
>> and consistent in order to avoid surprises when the traffic switches
>> to a different egress point.
>>
>> Thanks,
>> --David
>>
>>> -----Original Message-----
>>> From: Joel M. Halpern [mailto:[e-mail]]
>>> Sent: Monday, May 16, 2011 11:29 AM
>>> To: Black, David
>>> Cc: [e-mail]; [e-mail];
>>> [e-mail]; [e-mail];
>>> [e-mail]; [e-mail]; [e-mail]
>>> Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05
>>>
>>> Looking at the draft more carefully (when I am more awake, sorry), I
>>> think what you are asking is that more text be put in section 4.1, maybe
>>> a subsection?  That additional text would talk about placement on a
>>> switch that is not directly attached to the client, but is not as far
>>> upstream as the first hop router?  That text would include mention of
>>> the effect of spanning tree variation and LACP path changes.
>>>
>>> Sorry I was dense,
>>> Joel
>>>
>>> On 5/15/2011 9:45 PM, [e-mail] wrote:
>>>> Joel,
>>>>
>>>> If LACP is running active-passive across links to two different
>>>> switches, there may be no physical
>>> network node common to the currently active and currently passive
>>> paths for some traffic.  If SAVI
>>> is set up poorly, a switch to the currently passive link could remove
>>> validation checks or black-
>>> hole traffic that was flowing on the previously active link. For
>>> example, binding an IP address to a
>>> single port or ports on a single switch is insufficient in such an
>>> environment (address validation
>>> binding needs to span switches).
>>>>
>>>> The material in 5.2.4 on Multi-LAN Hosts looks like a starting point
>>>> - wrt SAVI, active-passive
>>> link aggregation across multiple switches can be a way to get into
>>> that sort of trouble on a single
>>> LAN (!).  Beyond that, I think the notion that SAVI checks should be
>>> consistent across alternate
>>> paths for the same traffic is applicable at other scopes, e.g., all
>>> egresses from a multi-homed
>>> network to the ISP networks involved.
>>>>
>>>> Thanks,
>>>> --David
>>>>
>>>>> -----Original Message-----
>>>>> From: Joel M. Halpern [mailto:[e-mail]]
>>>>> Sent: Friday, May 13, 2011 11:28 AM
>>>>> To: Black, David
>>>>> Cc: [e-mail]; [e-mail];
>>>>> [e-mail]; [e-mail];
>>>>> [e-mail]; [e-mail];
>>>>> [e-mail]
>>>>> Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05
>>>>>
>>>>> Thank you David.
>>>>> I think I understand the second part of your comment (about
>>>>> multi-instance hosts), and will have to look at the document more
>>>>> to see
>>>>> how to address that.
>>>>>
>>>>> I am not sure I understand what the question is regarding the LACP /
>>>>> link group issue.  Is this really different from the issues that arise
>>>>> whenever the SAVI functionality is not on the leaf switch?  Where
>>>>> in the
>>>>> document do you think it would help to discuss this?
>>>>>
>>>>> Thank you,
>>>>> Joel
>>>>>
>>>>> On 5/13/2011 1:03 AM, [e-mail] wrote:
>>>>>> 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]
>>>>>> ----------------------------------------------------
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> savi mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/savi
>>>>>>
>>>>
>>>>
>>
>>