Re: [OPSAWG] Alissa Cooper's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)

[Dongjie (Jimmy)]

Hi Alissa, 

Thanks for your review and comments. 

We will correct the improper normative language in section 7 in next version. 

As for the security considerations, we will discuss among coauthors and come 
back to you. 

Best regards,
Jie

> -Original Message-
> From: Alissa Cooper [mailto:ali...@cooperw.in]
> Sent: Wednesday, December 05, 2018 10:22 AM
> To: The IESG 
> Cc: draft-ietf-opsawg-ipfix-bgp-commun...@ietf.org; Tianran Zhou
> ; opsawg-cha...@ietf.org; Tianran Zhou
> ; opsawg@ietf.org
> Subject: Alissa Cooper's No Objection on
> draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)
> 
> Alissa Cooper has entered the following ballot position for
> draft-ietf-opsawg-ipfix-bgp-community-11: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Section 7:
> 
> "BGP speakers that support the extended message SHOULD be careful to
>export the BGP communities in the IPFIX message properly, so that
>they only convey as many communities as possible in the IPFIX
>message.  The Collector which receives an IPFIX message with maximum
>length and BGP communities contained in its data set SHOULD be aware
>that the BGP communities may be truncated due to limited message
>space."
> 
> This uses normative language improperly. "SHOULD be careful" and "SHOULD
> be aware" are not actionable by implementations. It seems like in the first 
> case
> this is trying to convey something more like "SHOULD only convey as many
> communities as possible without exceeding the 65536-byte limit of an IPFIX
> message." The second one seems like it should not be a normative
> recommendation.
> 
> Section 8:
> 
> "This document itself does not directly introduce any new security issues."
> 
> I question whether this is true. The motivation for the document describes the
> use of BGP communities in IPFIX as inputs to, e.g., traffic optimization
> applications. Given that there are known problems associated with the
> integrity and authenticity of BGP communities (e.g., [1]), couldn't the
> propagation of false BGP communities to these other applications cause the
> applications to misbehave in ways above and beyond whatever damage the
> false communities do to the operation of BGP itself?
> 
> [1]
> https://datatracker.ietf.org/meeting/103/materials/slides-103-grow-bgp-com
> munities-spread-their-wings-01
> 

___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

[OPSAWG] Alissa Cooper's No Objection on draft-ietf-opsawg-ipfix-bgp-community-11: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-opsawg-ipfix-bgp-community-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ipfix-bgp-community/



--
COMMENT:
--

Section 7:

"BGP speakers that support the extended message SHOULD be careful to
   export the BGP communities in the IPFIX message properly, so that
   they only convey as many communities as possible in the IPFIX
   message.  The Collector which receives an IPFIX message with maximum
   length and BGP communities contained in its data set SHOULD be aware
   that the BGP communities may be truncated due to limited message
   space."

This uses normative language improperly. "SHOULD be careful" and "SHOULD be
aware" are not actionable by implementations. It seems like in the first case
this is trying to convey something more like "SHOULD only convey as many
communities as possible without exceeding the 65536-byte limit of an IPFIX
message." The second one seems like it should not be a normative recommendation.

Section 8:

"This document itself does not directly introduce any new security issues."

I question whether this is true. The motivation for the document describes the
use of BGP communities in IPFIX as inputs to, e.g., traffic optimization
applications. Given that there are known problems associated with the integrity
and authenticity of BGP communities (e.g., [1]), couldn't the propagation of
false BGP communities to these other applications cause the applications to
misbehave in ways above and beyond whatever damage the false communities do to
the operation of BGP itself?

[1]
https://datatracker.ietf.org/meeting/103/materials/slides-103-grow-bgp-communities-spread-their-wings-01


___
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg