Re: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery
Susan Hares <shares@ndzh.com> Mon, 21 March 2022 08:55 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E493A18FB; Mon, 21 Mar 2022 01:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.94
X-Spam-Level:
X-Spam-Status: No, score=0.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1ipv45QQ6iA; Mon, 21 Mar 2022 01:55:21 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2750D3A18F9; Mon, 21 Mar 2022 01:55:20 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.107.114.225;
From: Susan Hares <shares@ndzh.com>
To: 'Minto Jeyananth' <minto=40juniper.net@dmarc.ietf.org>, 'Jeffrey Haas' <jhaas@pfrc.org>, idr@ietf.org
Cc: draft-minto-idr-bgp-autodiscovery@ietf.org
References: <20220308062429.GF17510@pfrc.org> <BYAPR05MB4359013ABE17D0296F6CEB86A5139@BYAPR05MB4359.namprd05.prod.outlook.com> <00b501d83b8b$cd5ff320$681fd960$@ndzh.com> <BYAPR05MB4359F7ACE3952027135F6F10A5169@BYAPR05MB4359.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB4359F7ACE3952027135F6F10A5169@BYAPR05MB4359.namprd05.prod.outlook.com>
Date: Mon, 21 Mar 2022 04:54:55 -0400
Message-ID: <00ad01d83d01$5d464ea0$17d2ebe0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AE_01D83CDF.D63B1740"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
Thread-Index: AQHJCt9VTBpsdTVWecrp1pQXoWaR6wMJUpmhAbsH8kcC+YhxQ6yp/SnA
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/eoKWr8ZPIy2po1SMSCNR8U86QQw>
Subject: Re: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2022 08:55:26 -0000
Minto: I see you answered the question regarding other uses (based on Link TLV). What scenarios have you tested the timers in ? Was it a test lab? Did you have any other traffic on the link. Thanks for the response. Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Minto Jeyananth Sent: Monday, March 21, 2022 1:16 AM To: Susan Hares; 'Jeffrey Haas'; idr@ietf.org Cc: draft-minto-idr-bgp-autodiscovery@ietf.org Subject: Re: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery Susan, Thanks for the review. Please see inline [minto2] From: Susan Hares <shares@ndzh.com> Date: Saturday, March 19, 2022 at 5:21 AM To: Minto Jeyananth <minto@juniper.net>, 'Jeffrey Haas' <jhaas@pfrc.org>, idr@ietf.org <idr@ietf.org> Cc: draft-minto-idr-bgp-autodiscovery@ietf.org <draft-minto-idr-bgp-autodiscovery@ietf.org> Subject: RE: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery [External Email. Be cautious of content] Jeff and Minto: [WG chair hat off] [Individual contributor hat on] I have a few additional questions below. Two high level questions: 1) What non-BGP use are you proposing for your protocol? [minto2] None. Though, technically Link tlv (section 4.2.6) could be treated as non bgp parameter. 2) What is the normal rate of your timers? [minto2] Protocol required that a sender should refresh advertise state before it expires. In steady-state refresh, the sender shall refresh the states after the advertised lifetime goes below 2/3 of the time. For e.g if the advertised remaining lifetime is 900 seconds, then it may refresh for every 300 seconds +/- jitter. In short-live fast-refresh mode, the sender will not consider the advertised remaining lifetime. And sender switches to a rapid timer, typically 250 milliseconds, for a second. Thank you for your hard work on this protocol! Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Minto Jeyananth Sent: Friday, March 18, 2022 6:42 PM To: Jeffrey Haas; idr@ietf.org Cc: draft-minto-idr-bgp-autodiscovery@ietf.org Subject: Re: [Idr] BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery Jeff, Thanks for the review. At a high level, the SA protocol design trade-off is given to simplicity(the requirement is to just bring up BGP). Any higher-level complexity can be very well handled by BGP. Please see inline [minto]. A couple of clarifications inline and will address the rest of the comments in the next version of the draft. Again thanks for the thoughtful review. From: Jeffrey Haas <jhaas@pfrc.org> Date: Monday, March 7, 2022 at 10:24 PM To: idr@ietf.org <idr@ietf.org> Cc: draft-minto-idr-bgp-autodiscovery@ietf.org <draft-minto-idr-bgp-autodiscovery@ietf.org> Subject: BGP autoconfiguration - draft-minto-idr-bgp-autodiscovery [External Email. Be cautious of content] Working Group, As noted in another thread, we had a late entrant to the BGP autoconfiguration options. In an attempt to spur along discussion of the L3ND proposal, I posted my analysis of that proposal in the same vein as the discussions we'd had over the course of the various IDR interim meetings and also as covered in the Appndices of draft-ietf-idr-bgp-autoconf-considerations.[1] While draft-minto-idr-bgp-autodiscovery[2] had been presented and received discussion at those interims, similar analysis as that in the design team's document wasn't done. The authors of L3ND have asked for similar treatment for draft-minto. Below, find my observations on the draft with questions and commentary intermixed. I finish this response with my high level analysis and personal opinion on what these properties accomplish. ----- Scoping Discussion: - The proposal starts by noting that it covers more general discovery by labeling itself "Service Advertisement". So, the scope is broader than simply BGP autoconfiguration state. [Sue: Is there extra state due to the service advertisement? - Single-hop BGP and "loopback address BGP between directly connected speakers" are use cases. [Sue: Please indicate where you find this information in the text.] [minto2] Please see section 2. Receiver could use this information to bootstrap the single hop bgp and/or loopback address bgp between directly connected bgp speakers - Advertised state is expected to be refreshed; it times out. - Messages are transmitted peridically. [sue]: What is your normal time frame. Page 9 does not provide this information. It states: A sender should periodically send PDU to refresh the advertised information before the time expires. [minto2] This is same as point 2). Will add a section on next version. ----- Protocol properties: > - PDU messages are simple 1-octet type, 2-octet length TLV format. [Sue: Type is 8 bits. Do you see any future expansion for the non-BGP use case? ]] [minto2] No. Message type also provide 8 bits. Message is provide logical grouping of TLVs. >- Two top-level PDUs defined: + Service Advertisement PDU * Defines "lifetime" properties of the advertisements. A "time to live" field. * A Config sequence TLV. Compare vs. "BGP Session Protocol State Version Number" in the requirements. * Authentication TLV. Provides authentication of Service Advertisements. * Refresh request TLV. The only message that attempts to trigger another Service advertisement speaker to send messages. Is the structure of the two PDUs due to the non-BGP use case? [minto2] 2 messages. Base message provide base operation such as timer authentication etc [minto2] excerpt from draft The document defines following messages. 1. SA Base message The SA Base message is mandatory message and mainly used for the protocol operation. 2. BGP service advertisement message BGP Service Advertisement message provides transport information to bring up the bgp session. Section 3's TLV format runs somewhat backwards from many RFCs: - The top level TLV, the SA PDU, is shown last. - The individual messages in an SA PDU is shown in the middle. - The generic TLV structure is at the top. Message ID, is per-message. It's a little unclear how individual message IDs within a given SA PDU is helpful. Should the message ID be per SA PDU instead? [minto] The message-id per message type will help in debugging per message level. The individual field definitions should list whether they are mandatory or optional. [minto] will fix it in next version. The Remaining lifetime field is 2-octets. 65k seconds is 1k hours. That's overly long. :-) [minto] We always run into not enough size. And 65k is 18hours. [Sue: Why are you cycling so much? What are the timer limits?] - This field should probably be bound to a much lower value for sending. - Implementations may wish to bound the maximum time they're willing to keep. [minto] Yes. It is not explicitly mentioned in spec. But a stateless implementation, could simply discard subsequent pdu after it bring up bgp. [Sue: It would be helpful to mention this in the specification. [minto2] Will add it next version. In short this is same as point 2) response. - Expiry of records might want to interact with Refresh request? [minto] Good suggestion. Will add it in some section in next version. [Sue] How are you keeping track of the expiry of records in your implementation? [minto2] A stateful implementation keep the peers advertised state until the remaining-life expire. The Refresh request procedure is under-specified. Since it's the one field that causes another SA speaker to respond, it should describe: - What does responding to such a trigger do to the sender's timers for the message? - What sort of rate limiting should be done for responding to the triggers? [minto] Will add a new section on the refresh request and fast send. Local address TLV: - The flags and Res fields need the standard "MUST BE ZERO on send, SHOULD BE ignored on receipt" text. - The flags field needs an IANA Considerations section. - Preference doesn't have any normative text as to how it should be used. - The contents of sections 4.2.1 and 4.2.2 blend together a bit. [minto] Will fix it in next version. Transport properties: - Being at the top level of the SA message, the implication is that these apply uniformly to the Local Address in that message. Security TTL: - Currently specified as a zero-length flag. - Some GTSM might require 254 rather than 255. This is inconsistently flagged in many pieces of configuration state across IETF. [minto] Will fix it in next version. Security authentication: - A selector for BGP's authentication mechanism. - Has TCP-MD5 and TCP-AO - Need an IANA registry. - Not bound to any particular address in the Local Address field. If security needs to vary, like any other attribute, it needs to go into a separate SA message. MSS: - 4 bytes is probably too big. :-) [Sue: Do you need the MSS of 4 bytes for some of your retransmission? } [minto2] No. will fix it next version ----- Protocol behavior: - The procedure really needs to talk about some possible default timer values. [minto] The preference be automatic. The value might change from fast(order of milliseconds) to steady state value based on local load. [Sue: Could you explain how the preference might be automatic. It would be helpful to explain this in the protocol.] [minto2] Will add timer section in next version. - The procedure indicates that it may refresh more frequently than the expiration time. It should offer advice as to how often it may do so. An example from BGP's holdtime would be to send at least once in 1/3 of that interval. Other options could be to have two timers described: retention timer (placed in PDU) and transmit timer (configuration state). - Fast transmit could use some procedure. For example, transmit X times in Y interval. + The refresh TLV provides some ability to do a "pull". [minto] will add a section in next version. [Sue:] Does the refresh have a pull. [minto2] Refresh request TLV ask for the receiver to resend the pdu, Thanks -minto - When specifying "all routers", include the multicast group in the text for clarity. [minto] will fix it in next version. - The procedure argues that you can receive the same state in multiple encapsulations; i.e. IPv4 and IPv6. Some discussion should be given as to how to recognize it's the same for puposes of "resetting state". As an example, the Identifier field being the same. - The transmit procedure supplies some of the "what is mandatory" description. That should be clarified in the TLV descriptions. - The procedure for handling the identifier vs. IP addresses should be clarified. [minto] Will fix it next version. ----- Misc: - The document should really remove references to UDP port 179. IANA hasn't assigned this. It should simply be "TBD". [minto] will fix it. - Code points should consider starting at 1 rather than 0. (Jeff's opinion.) - TLVs starting at > 16 should get some discussion as to why that number is being used. [minto] ok. My initial thought, if a need special tlv code across all message then we can use it. -minto ----- Security Properties: Authentiction TLV for Service Advertisements contain: <key-id (2-octets), Sequence number (4-octets), Hash/digest (variable)> (Defined in §4.1.3, procedure in §5.4.) - The procedure for management of key-ids is left as an opaque detail. This would require implementations to have key id management that includes inputs for cipher and shared key. - The Sequence number field has procedure somewhat similar to BFD's use of Sequence number in non-meticulous mode. (See RFC 5880, §4.3+.) + I suspect the sequence number comparison features should refer to RFC 1982. (And the authors of draft-minto may wish to refer to the Author list of that RFC. :-) - The procedure for handling the hash over the PDU is missing many of the usual bits of procedure when such hash based mechanisms are done: - What value should the PDU's Hash/digest field be set to? - Where should the key be placed in the PDU for purposes of calculating the hash? - What are the mandatory hash mechanisms? + Is there a benefit to including an authentication type along with just the key-id? Doing so might help simplify procedure by making validation always able to determine TLV lengths based on input. - The receiver procedure needs clarification as to what its desired security properties are. For example, if the receiver expects to receive packets with the Authentication TLV, it should require one on receipt. Otherwise there's possibility of an active attacker simply generating Service Advertisements without an Authentication TLV. The mechanism is currently vulnerable to replay attacks. - This can be somewhat mitigated by reasonable key rotation and limited key lifetime. - Keys really need to be rotated as part of sequence number rollover. - Sequence number increment procedures need to be bound to prevent certain scenarios where a later sequence number has been cached by an attacker and used to trigger the "this is a valid next number" and convince listeners to ignore the valid but appear to be stale packets. For fresh starting receivers, they are vulnerable to replay attacks that keep sequence numbers from synchronizing initially. + An epoch/generation value in addition to to the steps above could reduce the attack space. + See for example TCP-AO's Sequence Number Extension concept. The security TLV for the BGP session itself is incomplete. While authentication TLV indicates TCP-AO/TCP-MD5, there needs to be a hint as to what the connection properties should be. Key-id, reference to keychain RFC, etc. Is ipsec planned for? ----- Transport Layer Considerations: - The feature uses (IP) UDP multicast. - No transport reliability is implied. - IP fragmentation is implied as the mechanism to deal with packets that are too large. + Link MTU will thus define how much state can be passed around. + Possibility is left in the design (via TBD TLVs) that fragmentation might be addressable in the future. ----- Misc.: - The document is in need of a spelling and grammar review. In the interest of not cluttering functional analysis when the intent is clear, I will send comments on spelling and grammar separately to the authors. ----- Jeff's read of the proposal: The protocol is a "shout in the dark" type protocol. In general, it doesn't have any particular session layer. Receivers may, or may not be listening. For the most part, there is no expectation of a receiver with the expection of the refresh TLV which is intended to elicit a response from other senders. (Compare vs. IGMP/MLDv2.) Being sessionless, one of its big problems is that the state must be small enough to fit into link MTU. This is likely sufficient for many BGP autodiscovery scenarios, although the question of massive numbers of messages is raised in discussion about L3ND. IP fragmentation is offered as a possible method to deal with too-large messages, but fragmentation is often seen as an attack on IP infrastructure and in many cases is explicitly filtered. The draft discussses possible procedures for extending support via additional TLVs. If there's intent to do that, such procedure should be specified early since it would tend to manifest as one of a common set of prior solutions: - Split it into a number of additional messages. Compare vs. PIM Group Set Fragmentation. - Provide a session-based protocol as the extension mechanism. However, that opens attacks against sessions. Compare possibly vs. LLDPv2. The SA procedures can be exercised unidirectionally. This means that a device may volunteer to have BGP Speakers peer with it, but don't have to have the rest of the network trying to peer with them. The timer procedures are underspecified. Similarlities can be drawn to RIP and to some extent IGMP/MSDP. Security procedures for the SA PDU need tightening, as noted above. The procedure for keying of BGP sessions is absent and needs text. Since the protocol has no privacy, exchanging BGP session keys directly in the TLVs as cleartext cannot be suggested. Being sessionless, there is no session infrastructure to be under attack. The primary ready attacks against the infrastructure are volumetric attacks. Such attacks beat up on the crypto involved at a cost related to the strength of the cipher used to protect the validation of the packet. These attacks are mitigated, much as similar attacks on TCP-MD5 and TCP-AO, on the mechanism relying on GTSM. This restricts such attacks to on-link. Configuration of security mechanisms are critical for this protocol. In the absence of required security, since this protocol advertises state to be cached for BGP session configuration, unauthenticated messages can be used to: - Flood the cache of SA state for all listening receivers. - Cause those receivers to effectively attack hosts at TCP port 179 on the local network by trying to BGP peer with them, even if they're not BGP. -- Jeff (who is up way past his bedtime...) [1] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr- bgp-autoconf-considerations/__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wB JvMX_qM2LMVXeLiO3F5MbhN3o17TzPQ$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr- bgp-autoconf-considerations/__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wB JvMX_qM2LMVXeLiO3F5MbhN3o17TzPQ$> [2] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-mint o-idr-bgp-autodiscovery-01__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wBJv MX_qM2LMVXeLiO3F5MbhN2snlIPMw$ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-mint o-idr-bgp-autodiscovery-01__;!!NEt6yMaO-gk!W_mD4PG04ql6NljpkZMM_DJtZ2k23wBJv MX_qM2LMVXeLiO3F5MbhN2snlIPMw$> Juniper Business Use Only Juniper Business Use Only
- [Idr] BGP autoconfiguration - draft-minto-idr-bgp… Jeffrey Haas
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Minto Jeyananth
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Susan Hares
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Jeffrey Haas
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Susan Hares
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Jeffrey Haas
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Susan Hares
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Jeffrey Haas
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Randy Bush
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Randy Bush
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Susan Hares
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Robert Raszuk
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Susan Hares
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Robert Raszuk
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Minto Jeyananth
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Minto Jeyananth
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Susan Hares
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Susan Hares
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Minto Jeyananth
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Susan Hares
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Minto Jeyananth
- Re: [Idr] BGP autoconfiguration - draft-minto-idr… Susan Hares