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

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