I read bogus as spoofed or forged.
if (initial_ttl!=255) then (rfc5082_compliant==0) donald.sm...@centurylink.com ________________________________________ From: Job Snijders [j...@ntt.net] Sent: Thursday, December 14, 2017 10:20 AM To: Smith, Donald Cc: bruno.decra...@orange.com; Ben Campbell; grow-cha...@ietf.org; draft-ietf-grow-bgp-gs...@ietf.org; grow@ietf.org; The IESG Subject: Re: [GROW] Ben Campbell's Yes on draft-ietf-grow-bgp-gshut-12: (with COMMENT) On Thu, Dec 14, 2017 at 05:12:52PM +0000, Smith, Donald wrote: > I don't see anything around MD5/TCPAO authentication. > > >From https://tools.ietf.org/html/rfc6198 > > " Security considerations MUST be addressed by the proposed solutions. > In particular, they SHOULD address the issues of bogus g-shut > messages and how they would affect the network(s), as well as the > impact of hiding a g-shut message so that g-shut is not performed." > > I may have missed it somewhere? I have trouble parsing this requirements text. What makes a "bogus g-shut" a "bogus g-shut"? How is 'hiding' (I interpret this as 'removing the gshut community) a g-shut any different than the other BGP speaker not supporting g-shut? How is any of this different than NO_EXPORT or NO_ADVERTISE? Kind regards, Job This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
