Subject: [RTG-DIR] RtgDir review: draft-ietf-trill-loss-delay-04.txt

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 6 Jun 2014 15:33:28 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-trill-loss-delay-04.txt 
Reviewer: Carlos Pignataro
Review Date: June 6, 2014
IETF LC End Date: ?
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved before publication.

Comments:

This document is really well written and very comprehensive. It is clear, complete (modulo minor comments below), and accurate.

Minor Issues:

The Security Considerations of this document are oversimplified to say "check the security of all these references". I think that some more detailed description of the security aspects is necessary. For example, checking the security on the cited documents, I do not believe there is discussion of security issues introduced by measuring (effect of synthetic packets, etc). A second security element is compromising the measurement itself, and associated implications. Lastly, the OAM Authentication TLV protects against forged/crafted OAM packets. Some deeper description of the tradeoffs of using it as it pertains affecting a measurement would be useful.

Nits:

A small nit, in the Abbreviations section, it would be useful to add a citation to [OAM] next to the acronym definition to be prescriptive about the definition used for the acronym (and there's a comma missing)

OLD:
   OAM      Operations, Administration and Maintenance

NEW:
   OAM      Operations, Administration, and Maintenance [OAM]

Thanks,

Carlos.

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 9 Jun 2014 16:14:38 -0400

Carlos: 

Thank you for the feedback.  I'll talk to the authors about extending the security section.  Would you be willing to review a revised security section? 

Sue 

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:[email-masked]] 
Sent: Friday, June 06, 2014 11:33 AM
To: [email-masked]
Cc: <[email-masked]>; [email-masked]
Subject: RtgDir review: draft-ietf-trill-loss-delay-04.txt

Hello,

Summary:

Comments:

Minor Issues:

Nits:

OLD:

NEW:

Thanks,

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 9 Jun 2014 23:41:06 +0000

Hi, Sue,

Absolutely! More than happy to review proposed additions to the Security Considerations.

Thanks,

Carlos.

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 11 Jun 2014 08:22:51 +0300

Hi Carlos,

We would like to suggest the following text for the security considerations section. 
Please let us know if there are any comments.

The security considerations of TRILL OAM are discussed in [OAM-REQ] and in [OAM-FRAMEWK] and in [TRILL-FM]. General TRILL security considerations are discussed in [RFCTRILL].

As discussed in [OAM-Over], an attack on a PM protocol can create a false illusion of nonexistent performance issues, or prevent the detection of actual ones, consequently resulting in denial of service. Another security aspect is network reconnaissance; by passively eavesdropping to PM messages an attacker can gather information that can be used maliciously to attack the network.

As in [TRILL-FM], TRILL PM OAM Messages MAY include the OAM Authentication TLV. It should be noted that an Authentication TLV requires a cryptographic algorithm, which may have performance implications on the RBridges that take part in the protocol, and thus may, in some cases, affect the measurement results.

[OAM-Over]    Mizrahi, T., Sprecher, N., Bellagamba, E. and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276 (in AUTH-48), June 2014.

Regards,
Tal.

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:[email-masked]] 
Sent: Tuesday, June 10, 2014 2:41 AM
To: Susan Hares
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: RtgDir review: draft-ietf-trill-loss-delay-04.txt

Hi, Sue,

Thanks,

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 15 Jun 2014 16:00:36 +0000

Hi, Tal,

Thanks for this textual suggestions! It's a great improvement, but I would like to see a slight more in-depth discussion of implications. There's also some potential nits. Please see inline.

On Jun 11, 2014, at 2:22 AM, Tal Mizrahi <[email-masked]> wrote:

> As discussed in [OAM-Over], an attack on a PM protocol can create a false illusion

I think that a "false illusion" is a "false false impression", meaning a "true impression". I believe "illusion" implies a "false/misleading representation".

> of nonexistent performance issues, or prevent the detection of actual ones, consequently resulting in denial of service. Another security aspect is network reconnaissance; by passively eavesdropping to PM messages an attacker can gather information that can be used maliciously to attack the network.

Are there also potential network side-effects for the introduction of synthetic packets? In other words, compromise the network and compromise the measurement are different attacks.

> As in [TRILL-FM], TRILL PM OAM Messages MAY include the OAM Authentication TLV. It should be noted that an Authentication TLV requires a cryptographic algorithm, which may have performance implicat…

Thanks for discussing these trade-offs. Are there scenarios where you'd recomment to use or to not use OAM Auth?

Thanks,

Carlos.

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Mon, 16 Jun 2014 12:24:22 +0000

Hi Tal,

This looks great — many thanks!

Carlos.

-----Original Message-----
From: Tal Mizrahi <[email-masked]>
Date: Monday, June 16, 2014 at 7:48 AM
To: Carlos Pignataro <[email-masked]>
Cc: Susan Hares <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>,
"[email-masked]"
<[email-masked]>
Subject: RE: RtgDir review: draft-ietf-trill-loss-delay-04.txt

>Hi Carlos,
>
>Thanks again for the thorough review.
>Based on your comments, here is a revised version of the security
>considerations section.
>Please let us know if there are any further comments/concerns.
>
>
>
>8. Security Considerations
>
>The security considerations of TRILL OAM are discussed in [OAM-REQ] and
>in [OAM-FRAMEWK] and in [TRILL-FM]. General TRILL security considerations
>are discussed in [RFCTRILL].
>
>As discussed in [OAM-Over], an attack on a PM protocol can falsely
>indicate nonexistent performance issues, or prevent the detection of
>actual ones, consequently resulting in DoS (Denial of Service).
>Furthermore, synthetic PM messages can be used maliciously as a means to
>implement DoS attacks on RBridges. Another security aspect is network
>reconnaissance; by passively eavesdropping to PM messages an attacker can
>gather information that can be used maliciously to attack the network.
>
>As in [TRILL-FM], TRILL PM OAM Messages MAY include the OAM
>Authentication TLV. It should be noted that an Authentication TLV
>requires a cryptographic algorithm, which may have performance
>implications on the RBridges that take part in the protocol, and thus
>may, in some cases, affect the measurement results. Based on a
>system-specific threat assessment, the benefits of the security TLV must
>be weighed against the potential measurement inaccuracy it may inflict,
>and based on this tradeoff operators should take a decision whether to
>use authentication.
>
>
>
>
>Regards,
>Tal Mizrahi.
>
>
>Sent: Sunday, June 15, 2014 7:01 PM
>To: Tal Mizrahi
>Cc: Susan Hares; [email-masked]; [email-masked];
>[email-masked]
>Thanks for this textual suggestions! It's a great improvement, but I
>would like to see a slight more in-depth discussion of implications.
>There's also some potential nits. Please see inline.
>
>> The security considerations of TRILL OAM are discussed in [OAM-REQ] and
>>in [OAM-FRAMEWK] and in [TRILL-FM]. General TRILL security
>>considerations are discussed in [RFCTRILL].
>> 
>I think that a "false illusion" is a "false false impression", meaning a
>"true impression". I believe "illusion" implies a "false/misleading
>representation".
>
>> of nonexistent performance issues, or prevent the detection of actual
>>ones, consequently resulting in denial of service. Another security
>>aspect is network reconnaissance; by passively eavesdropping to PM
>>messages an attacker can gather information that can be used maliciously
>>to attack the network.
>
>Are there also potential network side-effects for the introduction of
>synthetic packets? In other words, compromise the network and compromise
>the measurement are different attacks.
>
>> 
>> As in [TRILL-FM], TRILL PM OAM Messages MAY include the OAM
>>Authentication TLV. It should be noted that an Authentication TLV
>>requires a cryptographic algorithm, which may have performance
>>implications on the RBridges that take part in the protocol, and thus
>>may, in some cases, affect the measurement results.
>> 
>
>> [OAM-Over]    Mizrahi, T., Sprecher, N., Bellagamba, E. and Y.
>>Weingarten, "An Overview of Operations, Administration, and Maintenance
>>(OAM) Tools", RFC 7276 (in AUTH-48), June 2014.
>> 
>> 
>> Regards,
>> Tal.
>> 
>> 
>> Cc: [email-masked]; [email-masked];
>>[email-masked]
>>> Thank you for the feedback.  I'll talk to the authors about extending
>>>the security section.  Would you be willing to review a revised
>>>security section?
>>> 
>>> Sue 
>>> 
>>> I have been selected as the Routing Directorate reviewer for this
>>>draft. The Routing Directorate seeks to review all routing or
>>>routing-related drafts as they pass through IETF last call and IESG
>>>review, and sometimes on special request. The purpose of the review is
>>>to provide assistance to the Routing ADs. For more information about
>>>the Routing Directorate, please see
>>>​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>>> 
>>> Although these comments are primarily for the use of the Routing ADs,
>>>it would be helpful if you could consider them along with any other
>>>IETF Last Call comments that you receive, and strive to resolve them
>>>through discussion or by updating the draft.
>>> 
>>> This document is really well written and very comprehensive. It is
>>>clear, complete (modulo minor comments below), and accurate.
>>> 
>>> Minor Issues:
>>> 
>>> The Security Considerations of this document are oversimplified to say
>>>"check the security of all these references". I think that some more
>>>detailed description of the security aspects is necessary. For example,
>>>checking the security on the cited documents, I do not believe there is
>>>discussion of security issues introduced by measuring (effect of
>>>synthetic packets, etc). A second security element is compromising the
>>>measurement itself, and associated implications. Lastly, the OAM
>>>Authentication TLV protects against forged/crafted OAM packets. Some
>>>deeper description of the tradeoffs of using it as it pertains
>>>affecting a measurement would be useful.
>>> 
>>> Nits:
>>> 
>>> A small nit, in the Abbreviations section, it would be useful to add a
>>>citation to [OAM] next to the acronym definition to be prescriptive
>>>about the definition used for the acronym (and there's a comma missing)
>>> 
>>> OLD:

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 16 Jun 2014 13:48:08 +0300

Hi Carlos,

Thanks again for the thorough review.
Based on your comments, here is a revised version of the security considerations section.
Please let us know if there are any further comments/concerns.

As discussed in [OAM-Over], an attack on a PM protocol can falsely indicate nonexistent performance issues, or prevent the detection of actual ones, consequently resulting in DoS (Denial of Service). Furthermore, synthetic PM messages can be used maliciously as a means to implement DoS attacks on RBridges. Another security aspect is network reconnaissance; by passively eavesdropping to PM messages an attacker can gather information that can be used maliciously to attack the network.

As in [TRILL-FM], TRILL PM OAM Messages MAY include the OAM Authentication TLV. It should be noted that an Authentication TLV requires a cryptographic algorithm, which may have performance implications on the RBridges that take part in the protocol, and thus may, in some cases, affect the measurement results. Based on a system-specific threat assessment, the benefits of the security TLV must be weighed against the potential measurement inaccuracy it may inflict, and based on this tradeoff operators should take a decision whether to use authentication.

Regards,
Tal Mizrahi.

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:[email-masked]] 
Sent: Sunday, June 15, 2014 7:01 PM
To: Tal Mizrahi
Cc: Susan Hares; [email-masked]; [email-masked]; [email-masked]
Subject: Re: RtgDir review: draft-ietf-trill-loss-delay-04.txt

Hi, Tal,

Thanks,

Carlos.

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 18 Jun 2014 10:13:31 +0100

Carlos, Thanks for diligence is pushing on with the review.
Tal and Sue, thanks for the efforts to make Carlos happy :-)

Adrian

> Sent: 16 June 2014 13:24