ietf
[Top] [All Lists]

Re: Genart last call review of draft-ietf-grow-large-communities-usage-06

2017-04-19 09:19:15
On Wed, Apr 19, 2017 at 09:46:53AM +0100, Stewart Bryant wrote:
    Operations and Security [RFC7454].

SB> You do not address the question of whether there are new
SB> considerations, or considerations that are of increased importance?

It is my understanding that RFC 8092 "BGP Large Communities" are
just like RFC 1997 "BGP Communities", but ...  larger (for lack of
better words). Referencing RFC 7454 seems plenteous.

So, what if there are not any additional considerations, If there
were, they would've been (or are) covered in RFC 8092's security
section, right?

This is an Internet-Draft targetted for Informational status, I'm
not sure what you expect here.

I was wondering if there was more scope to make mischief at a distance
in a less less obvious way than before.

If everyone is happy that there is no additional risk then I am fine,
but seems to me the more knobs you give the mischeif maker to turn the
more security risks you have.

Ah, I see now. This document does not create new knobs. RFC 8092
definded the BGP Large Community attribute, and this internet-draft
reflects on possible use cases, much like RFC 1998 was a companion for
RFC 1997.

SB> Is there is text somewhere that discusses the integrity and
SB> synchronization of the parameters and any consequences that arise?

the what now? Can you elaborate on the above?

So you rely on the nodes that receive these community strings to
interpret them in a common way. Maybe this is an already solved
problem, or an known risk, but what if the dictionaries get out of
sync?

Yes, there is not anything novel here. How to keep a list of integers
like UN M.49 up to date (or how to write bug-free software) is out of
scope for this internet draft. ;-)

Deploy coherent routing policy configurations on an autonomous
system-wide level is not for this document to cover.

Kind regards,

Job