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

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 20 Apr 2020 07:28:07 +0000

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.

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.

Cheers,
-Tiru

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sat, 25 Apr 2020 03:58:48 +0000

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 <[email-masked]>のメール:
> 
> 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
> 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 

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

> (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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Sun, 26 Apr 2020 07:23:28 +0000

Hi Carlos,

Please see inline 

> -----Original Message-----
> From: Carlos Pignataro (cpignata) <[email-masked]>
> Sent: Saturday, April 25, 2020 9:29 AM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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,
> 

Thanks, I’m fine, and I hope all is well with you too.

> 
> > 2020/04/20 午前3:28、Konda, Tirumaleswar Reddy
> <[email-masked]>のメール:
> >
> > 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.
> >
> > 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.
> 

Yes.

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

Works for me.

Cheers,
-Tiru

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 26 Apr 2020 12:52:38 +0000

Hi, Tiru,

I think we are on the same page — see inline.

> 2020/04/26 午前3:23、Konda, Tirumaleswar Reddy <[email-masked]>のメール:
> 
> Hi Carlos,
> 
> Please see inline 
> 

:-)

> 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 i…

Agreed.

Checking draft-ietf-sfc-ioam-nsh, it does not have a pointer to draft-ietf-sfc-oam-framework. I believe a Reference should be added, with a citation capturing your comment.

>>   To address the above concerns, SFC and SF OAM should provide

Will make this change.

>>   and mitigate anomalies and various security  attacks.

Great. We will make this change as well.

Thanks!

Carlos.

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Mon, 27 Apr 2020 14:35:42 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Carlos,
    
    Please see inline 

    

    
    Yes.

    Works for me.
    
    Cheers,
    -Tiru

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 28 Apr 2020 05:26:31 +0000

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

> From: Nagendra Kumar Nainar (naikumar) <[email-masked]>
> Sent: Monday, April 27, 2020 8:06 PM
> To: Konda, Tirumaleswar Reddy
> <[email-masked]>; Carlos Pignataro (cpignata)
> <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Thank you for the review and the comments/suggestions. Please find the
> diff attached that incorporates the comments.
> 
> On 4/26/20, 3:24 AM, "sfc on behalf of Konda, Tirumaleswar Reddy" <sfc-
> [email-masked] on behalf of [email-masked]>
> wrote:
> 
>     Hi Carlos,
> 
>     Please see inline
> 
>     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.
> 
>     >

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 28 Apr 2020 09:45:01 +0000

Agreed. Thanks Tiru. 

Sent from my iPad

> On Apr 28, 2020, at 1:26 AM, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
> Hi Nagendra,
> 
>> <[email-masked]>

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Tue, 28 Apr 2020 13:53:31 +0000

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" <[email-masked]> wrote:

    Hi Nagendra,

    OLD:

    Cheers,
    -Tiru