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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

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
>