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

["Joel M. Halpern" <[e-mail]>]

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