Subject: Re: [Rtg-ooam-dt] Comments about Overlay OAM Drafts

From: Gregory Mirsky <[email-masked]>
Date: Mon, 4 Jul 2016 02:31:26 +0000

Hi Tal and Nagendra,
great discussion on security. Too often it comes too late and then raises lots of comments from the Security AD. Hope we can be proactive.
True, we don't have any requirement explicitly related to security of OAM, whether FM or PM. But after Tal pointed to the fact I think that we can add, e.g. about inadequate security of clear password. If someone has proposal for Tuesday, then we can add security related requirement(s) for the current working version and discuss in Berlin.
I like the text Tal suggested for the Security Consideration section. Perhaps it can say:
This document presents OAM requirements for overlay networks. These requirements have security implications. For example, if proactive FM is required, the security implication is that a passive eavesdropper can know when the session is down. Or, proactive FM may be used either to launch DoS or to highjack session and impact state, e.g. cause protection switchover. These security implications are natural results of the requirements, and do not depend on the particular implementation. Whether existing security mechanisms of existing protocols proposed to be re-used in OAM for overlay networks are adequate or require enhancements is for further study. New OAM protocols for overlay networks must consider their security mechanism to on per-solution basis.

Please share your thoughts, comments, suggestions. Please feel free to update the text, offer your version as well as security related requirements.

	Regards,
		Greg

-----Original Message-----
From: Tal Mizrahi [mailto:[email-masked]] 
Sent: Sunday, July 03, 2016 4:26 AM
To: Nagendra Kumar Nainar (naikumar); Gregory Mirsky
Subject: RE: Comments about Overlay OAM Drafts

Dear Nagendra,

>The draft is listing the requirements and does not discuss about any 
>solution or machinery. Accordingly, it does not introduce any security 
>implications. I think the security consideration is applicable on the 
>document that define the solutions. Does the below works:
>
>"This document list the OAM requirement for various Overlay network and 
>does not raise any security considerations. Any document defining the 
>solution for the above requirement must consider and include the 
>relevant security mechanism².

The document presents OAM requirements. These requirements have security implications. For example, if proactive FM is required, the security implication is that a passive eavesdropper can know when the session is down. This security implication is a result of the requirement, and does not depend on the implementation. This section should either discuss these implications, or say that OAM protocols have well-known security implications that are discussed in [citation].

Another point to be discussed in the 'Security Considerations' section is: does this document include security requirements? After reading the draft, I believe the answer is no (correct me if I am wrong). This section should probably say that the draft does not present security requirements, and that security mechanisms should be considered on a per-security-solution basis.

BTW, the same comments apply to the SPRING and BIER OAM requirement drafts. It would probably be best to have the same text for the three drafts.

Cheers,
Tal.

>-----Original Message-----
>From: Nagendra Kumar Nainar (naikumar) [mailto:[email-masked]]
>Sent: Friday, July 01, 2016 5:20 PM
>To: Gregory Mirsky; Tal Mizrahi; draft-ooamdt-rtgwg-oam-gap- 
>[email-masked]; draft-ooamdt-rtgwg-ooam- 
>[email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: Re: Comments about Overlay OAM Drafts
>
>Hi Tal,
>
>6.	Section 6 - certainly the OAM requirements have security implications.
>For example, OAM protocols may be subject to DoS attacks and to network 
>recon. Some of these considerations are discussed in RFC 7276.
>
>
>The draft is listing the requirements and does not discuss about any 
>solution or machinery. Accordingly, it does not introduce any security 
>implications. I think the security consideration is applicable on the 
>document that define the solutions. Does the below works:
>
>"This document list the OAM requirement for various Overlay network and 
>does not raise any security considerations. Any document defining the 
>solution for the above requirement must consider and include the 
>relevant security mechanism².
>
>Thanks,
>Nagendra
>
>On 6/26/16, 8:36 PM, "Gregory Mirsky" <[email-masked]>
>wrote:
>
>>Hi Tal,
>>many thanks for your thorough review of the documents by OOAM DT, 
>>greatly appreciated. Please find my answers and notes in-line and 
>>tagged
>GIM>>.
>>We're preparing updates to both drafts and will reflect your comments 
>>in the coming updates.
>>
>>	Regards,
>>		Greg
>>
>>-----Original Message-----
>>From: Tal Mizrahi [mailto:[email-masked]]
>>Sent: Sunday, June 26, 2016 7:20 AM
>>To: Nagendra Kumar Nainar (naikumar);
>>[email-masked];
>>[email-masked]; [email-masked]
>>Cc: [email-masked]; [email-masked]; [email-masked]
>>Subject: RE: Comments about Overlay OAM Drafts
>>
>>Dear Nagendra,
>>
>>>The comments seems to be missing in the mail. Can you please share 
>>>the same?.
>>
>>Strange... The comments seem to be visible in the mail archive 
>>(https://mailarchive.ietf.org/arch/msg/rtgwg/EPxJQcw9lOAIHV2HkRwNE6G
>VxAU).
>>
>>Nevertheless, here goes again:
>>
>>
>>Comments about draft-ooamdt-rtgwg-ooam-requirement:
>>https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-requirement-00
>>
>>A general question about the draft: does the draft define requirements 
>>for operators, requirements for vendors, or requirements for IETF 
>>working groups? These are three significantly different scopes, and 
>>reading the document I was not able to assess who the requirements are
>intended for.
>>
>>Other comments:
>>1.	Section 3: The term 'UCMP' is defined in Section 3, but not used in
>>the document.
>>GIM>> Good catch, will clear
>>2.	The following terms are used in the draft without having been
>defined:
>>-	'OAM session'
>>-	'node'
>>-	'centralized controller'
>>-	'FM'
>>GIM>> While Fault Management is straightforward
>>3.	Section 4.1.1: 'Reverse Defect Indication (RDI)' ==> RDI usually
>>stands for Remote Defect Indication.
>>GIM>> Indeed, thank you. Will update.
>>4.	Section 4.1.2: "Overlay OAM MAY support verification of the mapping
>>between its data plane state and client layer services" - please 
>>clarify further.
>>GIM>> We intend to provide solutions in the new document. But one use
>>case discussed in draft-nordmark-nvo3-transcending-traceroute.
>>5.	Section 4.2: the terms 'active' and 'passive' have not been defined in
>>the current draft (you may want to cite RFC 7799).
>>Specifically, this clarification is necessary since the term 'passive'
>>according to RFC 7799 is slightly different than the term 'passive' in 
>>draft-ietf-ippm-alt-mark-00.
>>GIM>> Yes, and we are talking about measurement methods that can be 
>>GIM>> used
>>"almost as passive" and explain the requirements toward the overlay to 
>>achieve such behavior.
>>6.	Section 6 - certainly the OAM requirements have security implications.
>>For example, OAM protocols may be subject to DoS attacks and to 
>>network recon. Some of these considerations are discussed in RFC 7276.
>>
>>
>>Comments about draft-ooamdt-rtgwg-oam-gap-analysis:
>>https://tools.ietf.org/html/draft-ooamdt-rtgwg-oam-gap-analysis-01
>>
>>1.	I believe having an OAM gap analysis draft is a good idea.
>>GIM>> Thank you.
>>2.	The current draft is still very preliminary, and some of the sections
>>are still empty.
>>GIM>> we'll post update before the cut-off date to discuss it in Berlin.
>>3.	Section 1: The introduction of the document goes way beyond the
>scope
>>of the title (Gap Analysis). The intro actually defines the baseline 
>>of an Overlay OAM solution. Either this part should be removed from 
>>the document, or the scope of the document should be redefined.
>>GIM>> I think it may justified as we list existing IETF OAM protocols.
>>Though we may move them out of the Introduction and into the new
>section.
>>4.	Section 3.3: this section is unclear, and should probably be rephrased.
>>The section discusses both in-band telemetry and passive monitoring, 
>>and it is not clear whether the two are related or not.
>>GIM>> We've discussed the telemetry and it could be collected using
>>active OAM, i.e. using injected OAM packets, or using passive-like 
>>method. Interestingly to discussion in RFC 7799, telemetry collection 
>>may use methods that could be characterized as hybrid methods as well.
>>5.	Section 5: it looks like this text was copied from another draft, and
>>is not applicable to this document.
>>GIM>> Indeed, we've removed it in the working version. Contributions 
>>GIM>> are
>>welcome and appreciated.
>>
>>Cheers,
>>Tal.
>>
>>
>>
>>>-----Original Message-----
>>>From: Nagendra Kumar Nainar (naikumar) [mailto:[email-masked]]
>>>Sent: Sunday, June 26, 2016 5:16 PM
>>>To: Tal Mizrahi; [email-masked];
>>>draft- [email-masked]; [email-masked]
>>>Cc: [email-masked]; [email-masked]; [email-masked]
>>>Subject: Re: Comments about Overlay OAM Drafts
>>>
>>>Hi Tal,
>>>
>>>The comments seems to be missing in the mail. Can you please share 
>>>the same?.
>>>
>>>Thanks,
>>>Nagendra
>>>
>>>On 6/26/16, 4:12 AM, "Tal Mizrahi" <[email-masked]> wrote:
>>>
>>>>Dear OOAM Authors,
>>>>
>>>>I have read the two OOAM drafts, and I have some comments. Please 
>>>>see below
>>

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Mon, 4 Jul 2016 11:00:29 +0000

Hi Greg/Tal,

I am traveling. But will try to include this before tomorrow meeting.

Thanks,
Nagendra

On 7/3/16, 10:31 PM, "Gregory Mirsky" <[email-masked]> wrote:

>Hi Tal and Nagendra,
>great discussion on security. Too often it comes too late and then raises
>lots of comments from the Security AD. Hope we can be proactive.
>True, we don't have any requirement explicitly related to security of
>OAM, whether FM or PM. But after Tal pointed to the fact I think that we
>can add, e.g. about inadequate security of clear password. If someone has
>proposal for Tuesday, then we can add security related requirement(s) for
>the current working version and discuss in Berlin.
>This document presents OAM requirements for overlay networks. These
>requirements have security implications. For example, if proactive FM is
>required, the security implication is that a passive eavesdropper can
>know when the session is down. Or, proactive FM may be used either to
>launch DoS or to highjack session and impact state, e.g. cause protection
>switchover. These security implications are natural results of the
>requirements, and do not depend on the particular implementation. Whether
>existing security mechanisms of existing protocols proposed to be re-used
>in OAM for overlay networks are adequate or require enhancements is for
>further study. New OAM protocols for overlay networks must consider their
>security mechanism to on per-solution basis.
>
>Please share your thoughts, comments, suggestions. Please feel free to
>update the text, offer your version as well as security related
>requirements.
>
>	Regards,
>		Greg
>
>The document presents OAM requirements. These requirements have security
>implications. For example, if proactive FM is required, the security
>implication is that a passive eavesdropper can know when the session is
>down. This security implication is a result of the requirement, and does
>not depend on the implementation. This section should either discuss
>these implications, or say that OAM protocols have well-known security
>implications that are discussed in [citation].
>
>Another point to be discussed in the 'Security Considerations' section
>is: does this document include security requirements? After reading the
>draft, I believe the answer is no (correct me if I am wrong). This
>section should probably say that the draft does not present security
>requirements, and that security mechanisms should be considered on a
>per-security-solution basis.
>
>BTW, the same comments apply to the SPRING and BIER OAM requirement
>drafts. It would probably be best to have the same text for the three
>drafts.
>
>Cheers,
>Tal.
>
>
>