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

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

Hi, Tiru,

I think we are on the same page — see inline.

> 2020/04/26 午前3:23、Konda, Tirumaleswar Reddy <[e-mail]>のメール:
> 
> 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.

Agreed.

Checking draft-ietf-sfc-ioam-nsh, it does not have a pointer to draft-ietf-sfc-oam-framework. I believe a Reference should be added, with a citation capturing your comment.


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

Will make this change.

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

Great. We will make this change as well.

Thanks!

Carlos.

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