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

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

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