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

[Jari Arkko <[e-mail]>]

Joel,

I would like to close the loop on this issue.

I think we promised a change on this, and Russ is holding a Discuss until we do.

(I realize that there are bigger issues on the SAVI docs, but I'm working through the various issues this week, and this one seemed easy to solve. More e-mail on the other topics soon.)

Jari

On 17.05.2011 01:09, 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
>>>>>>
>>>>
>>>>
>>
>>
> _______________________________________________
> savi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/savi
>