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

["Nagendra Kumar Nainar (naikumar)" <[e-mail]>]

HI Tiru,

Thank you. We will submit the updated version by EOB today.

Thanks,
Nagendra

On 4/28/20, 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
    >