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

["Dongjie (Jimmy)" <[e-mail]>]

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:[e-mail]]
> Sent: Wednesday, December 05, 2018 10:22 AM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Tianran Zhou
> <[e-mail]>; [e-mail]; Tianran Zhou
> <[e-mail]>; [e-mail]
> 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
>