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

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

Hi, Tiru,

Many thanks for the review, and great to hear from you!

I hope all is well — Please see inline.

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

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:



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


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