Re: [secdir] [sfc] Secdir last call review of draft-ietf-sfc-oam-framework

["Carlos Pignataro (cpignata)" <[e-mail]>]

Agreed. Thanks Tiru. 

Sent from my iPad

> On Apr 28, 2020, at 1:26 AM, Konda, Tirumaleswar Reddy <[e-mail]> wrote:
> 
> Hi Nagendra,
> 
> You may want to update the following line:
> 
> OLD:
> To address the above concerns, SFC and SF OAM should provide mechanisms for: 
> NEW:
> To address the above concerns, SFC and SF OAM should provide mechanisms for preventing:
> 
> Rest of the changes look good.
> 
> Cheers,
> -Tiru
> 
>> -----Original Message-----
>> From: Nagendra Kumar Nainar (naikumar) <[e-mail]>
>> Sent: Monday, April 27, 2020 8:06 PM
>> To: Konda, Tirumaleswar Reddy
>> <[e-mail]>; Carlos Pignataro (cpignata)
>> <[e-mail]>
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [sfc] Secdir last call review of draft-ietf-sfc-oam-framework
>> 
>> CAUTION: External email. Do not click links or open attachments unless you
>> recognize the sender and know the content is safe.
>> 
>> Hi Tirumaleswar,
>> 
>> Hope you are doing good.
>> 
>> Thank you for the review and the comments/suggestions. Please find the
>> diff attached that incorporates the comments.
>> 
>> We will submit the new version with the changes. Let us know if you have
>> any further comments.
>> 
>> Thanks,
>> Nagendra
>> 
>> On 4/26/20, 3:24 AM, "sfc on behalf of Konda, Tirumaleswar Reddy" <sfc-
>> [e-mail] on behalf of [e-mail]>
>> wrote:
>> 
>>    Hi Carlos,
>> 
>>    Please see inline
>> 
>>> -----Original Message-----
>>> From: Carlos Pignataro (cpignata) <[e-mail]>
>>> Sent: Saturday, April 25, 2020 9:29 AM
>>> To: Konda, Tirumaleswar Reddy
>> <[e-mail]>
>>> Cc: [e-mail]; [e-mail]; [e-mail]
>>> Subject: Re: [sfc] Secdir last call review of draft-ietf-sfc-oam-framework
>>> 
>>> CAUTION: External email. Do not click links or open attachments unless
>> you
>>> recognize the sender and know the content is safe.
>>> 
>>> Hi, Tiru,
>>> 
>>> Many thanks for the review, and great to hear from you!
>>> 
>>> I hope all is well — Please see inline.
>> 
>>    Thanks, I’m fine, and I hope all is well with you too.
>> 
>>> 
>>>> 2020/04/20 午前3:28、Konda, Tirumaleswar Reddy
>>> <[e-mail]>のメール:
>>>> 
>>>> Reviewer: Tirumaleswar Reddy
>>>> Review result: Ready with issues
>>>> 
>>>> 
>>>> I reviewed this document as part of the security directorate's ongoing
>>>> effort to review all IETF documents entering the IESG..  These
>> comments
>>> are directed at the security area director(s).  Document editors and WG
>>> chairs should treat these comments like any other last call comments.
>>>> 
>>>> This document provides a reference framework for OAM for SFC.
>>>> 
>>>> Comments:
>>>> 
>>>> 1. The document in Section 8 discusses various attacks (including both
>>>> security and privacy) but does not discuss any protection mechanisms
>>> other than proposing rate-limiting.  It is suggesting drafts proposing the
>> OAM
>>> solution should address the attacks but I don’t see any security
>> mechanisms
>>> discussed in draft-ietf-sfc-ioam-nsh to address the attacks.
>>>> 
>>> 
>>> Since the document already clarifies that it does not define solutions, it
>>> cannot define security consideration for those solutions, beyond saying
>> that
>>> those solutions ought to address security considerations in those areas.
>> Any
>>> security measures must be included and explained in the respective
>> solution
>>> document. I believe this comment requires potentially action on draft-
>> ietf-
>>> sfc-ioam-nsh but not on this draft.
>> 
>>    Yup. I see three solutions from SFC WG a) sfc-ioam-nsh b) ietf-sfc-proof-
>> of-transit (Experimental) c) penno-sfc-trace (Expired). sfc-ioam-nsh is the
>> only current standards track specification and it should address these attacks.
>> 
>>> 
>>> That said you are right regarding the specifics of the rate-liming
>>> recommendation. See the next answer for text.
>>> 
>>> Also, in re-reading Section 8, seems like this:
>>> 
>>>   To address the above concerns, SFC and SF OAM may provide
>> mechanism
>>>   for:
>>> 
>>> 
>>> Should say
>>> 
>>>   To address the above concerns, SFC and SF OAM should provide
>>> mechanisms
>>>   for preventing:
>> 
>>    Yes.
>> 
>>> 
>>> 
>>> 
>>>> 2. More discussion is required on the internal attacks.
>>>> (a) How are attack packets bypassing SFC detected and blocked ?
>>>> (b) How is sensitive information protected from eavesdroppers ?
>>>> (c) How is DoS/DDoS attack of misusing the OAM channel is mitigated ?
>>>> (d) Rate-limiting blocks both good and bad OAM probes and is a weak
>>> mitigation strategy. Anomaly detection (e.g., deep learning techinques)
>> and
>>> identifying the attacker look like a better strategy.
>>>> 
>>> 
>>> 
>>> This is a good point. How about.
>>> 
>>> OLD:
>>> 
>>>   The documents proposing the OAM solution for SF component should
>>>   consider rate-limiting the OAM probes at a frequency guided by the
>>>   implementation choice.  Rate-limiting may be applied at the SFF or
>>>   the SF . The OAM initiator may not receive a response for the probes
>>>   that are rate-limited resulting in false negatives and the
>>>   implementation should be aware of this.
>>> 
>>> 
>>> NEW:
>>> 
>>> 
>>>   The documents proposing the OAM solution for SF component should
>>>   consider rate-limiting the OAM probes at a frequency guided by the
>>>   implementation choice.  Rate-limiting may be applied at the SFF or
>>>   the SF.  The OAM initiator may not receive a response for the probes
>>>   that are rate-limited resulting in false negatives and the
>>>   implementation should be aware of this. To mitigate any attacks that
>>>   Leverage OAM packets, future documents proposing OAM solutions
>>>   should describe the use of any techniques to detect
>>>   and mitigate anomalies and various security  attacks.
>> 
>>    Works for me.
>> 
>>    Cheers,
>>    -Tiru
>> 
>>> 
>>> 
>>> Would that work?
>>> 
>>> Please feel free to suggest textual improvements or changes.
>>> 
>>> Thanks,
>>> 
>>> Carlos.
>>> 
>>>> Cheers,
>>>> -Tiru
>>>> _______________________________________________
>>>> sfc mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sfc
>> 
>>    _______________________________________________
>>    sfc mailing list
>>    [e-mail]
>>    https://www.ietf.org/mailman/listinfo/sfc
>> 
>