idnits 2.17.00 (12 Aug 2021) /tmp/idnits24431/draft-minto-idr-bgp-autodiscovery-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (21 January 2022) is 113 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2629' is defined on line 642, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 655, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J.M. Jeganathan 3 Internet-Draft V.S.K.R. Avula 4 Intended status: Standards Track Juniper Networks 5 Expires: 25 July 2022 21 January 2022 7 BGP Peer Auto-Configuration 8 draft-minto-idr-bgp-autodiscovery-01 10 Abstract 12 This document describes a layer 3 protocol (Service advertisement) to 13 help bgp to advertise service availability and local configurations . 14 This enables bgp speakers to discover bgp peers transport endpoints 15 and peer's configuration within link. With Service advertisement, 16 receivers could successfully bring up bgp protocol session without 17 mundane configurations. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 25 July 2022. 36 Copyright Notice 38 Copyright (c) 2022 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Revised BSD License text as 47 described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Revised BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Protocol overview . . . . . . . . . . . . . . . . . . . . . . 3 55 3. PUD layers . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. SA Base message . . . . . . . . . . . . . . . . . . . . . 5 58 4.1.1. Remaining lifetime TLV . . . . . . . . . . . . . . . 5 59 4.1.2. Config sequence TLV . . . . . . . . . . . . . . . . . 5 60 4.1.3. Authentication TLV . . . . . . . . . . . . . . . . . 6 61 4.1.4. Refresh request TLV . . . . . . . . . . . . . . . . . 6 62 4.2. BGP service advertisement message . . . . . . . . . . . . 6 63 4.2.1. Local address . . . . . . . . . . . . . . . . . . . . 7 64 4.2.2. Local IPv6 address . . . . . . . . . . . . . . . . . 8 65 4.2.3. Security TTL . . . . . . . . . . . . . . . . . . . . 8 66 4.2.4. Security Authentication . . . . . . . . . . . . . . . 8 67 4.2.5. TCP MSS . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2.6. Link Address . . . . . . . . . . . . . . . . . . . . 9 69 5. Protocol operation . . . . . . . . . . . . . . . . . . . . . 9 70 5.1. Transmit procedure . . . . . . . . . . . . . . . . . . . 10 71 5.2. Receiver procedure . . . . . . . . . . . . . . . . . . . 10 72 5.3. Transport endpoint reachability . . . . . . . . . . . . . 11 73 5.4. Protocol Authentication operation . . . . . . . . . . . . 11 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 7.1. Message of SA . . . . . . . . . . . . . . . . . . . . . . 12 77 7.2. TLVs of SA base Message . . . . . . . . . . . . . . . . . 13 78 7.3. TLVs of BGP service advertisement message . . . . . . . . 13 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 82 9.2. Informative References . . . . . . . . . . . . . . . . . 14 83 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 This document describes a layer 3 protocol (Service advertisement)to 89 help bgp to advertise service availability and local configurations . 90 This enables bgp speakers to discover bgp peer's transport endpoints 91 and peer's configuration within link. With Service advertisement, 92 receivers could successfully bring up bgp protocol session without 93 mundane configurations. 95 1.1. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Protocol overview 103 This is a simple protocol to periodically send and receive UDP 104 multicast PDU that contains bgp transport information in the form of 105 messages and TLVs. Receiver could use this information to bootstrap 106 the single hop bgp and/or loopback address bgp between directly 107 connected bgp speakers. The advertised information gets expired if 108 it is not refreshed before the lifetime ends. 110 This protocol does not provide any reliability of delivery and relies 111 on UDP multicast and periodic send. The current version of this 112 protocol assumes the link MTU is good enough to encode BGP transport 113 information or underlying IP implementation is able to fragment and 114 reassemble for link local multicast PDU. But this protocol is 115 flexible enough to implement a future version of fragment TLV 116 attachment. This is to bypass smaller link MTU for a system or 117 environment preventing IP fragment. 119 Service Advertisement (SA) PDU has multiple types of messages. This 120 document defines 2 types of messages. The primary/base messages are 121 required for SA to operate and secondary type messages for BGP 122 service advertisement. 124 3. PUD layers 126 The PDU contains a header followed by variable number of messages. 127 Each message contains variable number of TLVs. 129 SA uses type-length-value format. 131 0 1 2 3 132 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | Type | Length | Value | 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | Value .. 137 +-+-+-+-+ 139 Figure 1 141 Type: 1-octet value to interpret the value with in message. Same 142 type value could be reused in different message. 144 Length: Specifies length in octets of the value field. 146 Value: Octet string that encodes information to be interpreted as 147 specified by the Type field. 149 SA uses message to group set of TLVs 151 0 1 2 3 152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 |message Type | Length | Reserved | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | message ID | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | TLVs 159 +----- 161 Figure 2 163 message Type: This 1-octet value identifies type of message. 165 Message Length: Specifies the length in octets of the Message ID and 166 TLVs. 168 Message ID :32-bit value used to identify this message. Used for 169 logging purpose. 171 SA PDU 173 0 1 2 3 174 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Version | PDU Length | Reserved | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Identifier. | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Messages 181 +----- 183 Figure 3 185 Version: This 1-octet unsigned integer indicates the protocol 186 version. This version of the specification specifies Service 187 Advertisement version 0. 189 PDU Length: This 2-octet unsigned integer specifies the length 190 Identifier: 4 octet field that uniquely identifies PDU sender. BGP 191 id could be used for this purpose. This helps to uniquely identify 192 sender across the parallel links between same nodes. 194 4. Messages 196 The document defines following messages. 198 1. SA Base message 200 2. BGP service advertisement message 202 4.1. SA Base message 204 The SA Base message is mandatory message and mainly used for the 205 protocol operation. 207 The document defines following TLVs for SA Base message. 209 1. Remaining lifetime TLV 211 2. Config sequence TLV 213 3. Authentication TLV 215 4. Refresh request TLV 217 4.1.1. Remaining lifetime TLV 219 Remaining lifetime describes how long receiver should keep the state 220 without seeing a PDU from the sender. The lifetime gets updated when 221 receiver accepts the PDU. 223 Type : 17 225 Length: 2 octets 227 Value: Remaining lifetime in seconds 229 4.1.2. Config sequence TLV 231 Specifies a 4-octet configuration sequence number. Receiver could 232 make use the number to detect config change. This will be useful to 233 restart the bgp session with new parameters. 235 Type : 18 237 Length: 4 octets 238 Value: unsigned sequence number 240 4.1.3. Authentication TLV 242 Specifies authentication. 244 ? 0 1 2 3 245 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Type | Length | key-id | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | key-id | Sequence number ..| 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Seq no | Hash/digest 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 4 256 Type : 19 258 Length: variable 260 key-id : keychain id 262 Sequence-number - 4 byte sequence number of this SA base message. 264 Digest - Hash computed for this message using key-id mapped algorithm 266 4.1.4. Refresh request TLV 268 Optional TLV to trigger receivers to immediately send SA PDU. 269 Presence of the TLV indicates sender request refresh. This will be 270 used during the restart to learn about services quickly from 271 connected devices to speed up service discovery. 273 Type : 20 275 Length: 0 octets 277 4.2. BGP service advertisement message 279 BGP Service Advertisement message provides transport information to 280 bring up the bgp session. This document defines transport 281 information TLVs and session information TLVs for BGP Service 282 Advertisement messages. 284 Message type of BGP Service Advertisement message: 2. 286 Following are the Transport information TLVs 288 1. Local Address 290 2. Security TTL 292 3. Security Authentication 294 4. Link Address 296 5. Transport Preference. 298 6. TCP MSS 300 4.2.1. Local address 302 Specifies a local address used for bgp transport connection. Address 303 encoding uses a below format. 2 octets describe the address and 304 followed by address value. 306 0 1 2 3 307 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 |L| flags | Res | pref | IPv4/v6 Address | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | IPv4/v6 Address ... 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 Address 314 L bit - Address of loopback interface. 315 pref - Preference value of 4 bits. Value from 1 to 15. 316 0 indicates dont care. 317 1 higly preferred and 15 means least preferred. 318 Address - For IPv4 4 octets and IPv6 16 octets 320 Figure 5 322 ? 0 1 2 3 323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type | Length | Address1 | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Address1 | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | Address2 ... 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 6 334 Type : 17 336 Length: variable. multiples of 6 octets 338 Value: IPv4 addresses with address encoding. 340 4.2.2. Local IPv6 address 342 Specifies a IPv6 local address used for bgp transport connection. 344 Type : 18 346 Length: multiples of 18 octets 348 Value: IPv6 addresses with address encoding used for transport 349 connection. 351 4.2.3. Security TTL 353 TTL be accepted for bgp messages 355 Type : 19 357 Length: 0 359 Value: Presence of this TLV indicates that receiver accepts only 360 packets with 255 TTL. 362 4.2.4. Security Authentication 364 Type : 20 366 Length: 1 368 Value:This supports only two values 0 and 1. 370 0 indicates TCP md5. 1 indicates TCP-AO Absence of this TLV 371 indicates, no authentication used for connection. 373 4.2.5. TCP MSS 375 TCP MSS used for the connection 377 Type : 21 379 Length: 4 381 Value:Value in bytes 382 Indicates the preference of TCP MSS for the transport connection. 384 4.2.6. Link Address 386 This could be used for receiver to get nexthop information for local 387 address TLV when sender's running IPv4 PDU and prefer IPv6 transport 388 and vice-a-versa. This could also be used to provide reachability to 389 loopback addresses with link address. 391 Type : 22 393 Length: 4 for IPv4 address and 16 for IPv6 address 6 for mac address. 395 Value:interface IPv4 or IPv6 or mac address . 397 5. Protocol operation 399 A sender should periodically send PDU to refresh the advertised 400 information before its lifetime expires. An implementation may send 401 PDU well before the lifetime expires based on specific events. These 402 events could be a local config change or discovering a new 403 advertiser. Also, implementation could switch to fast refresh when 404 content of the pdu changes and move back to regular refresh interval. 405 The fast refresh will help in quicker discovery and may help update 406 content in case of auto order delivery. As stated above, this is 407 purely an implementation technique than the protocol mandate. 409 To discover multi-data(IPv4/IPv6) protocol environment(mixed 410 transport mode in a single link) sender shall send both data-protocol 411 pdu based on local configuration. When sender choose to send both 412 data protocol PDU it should make sure that semantic content of the 413 messages should be same. An implementation may choose to use 414 preferred data protocol PDU as primary send PDU and only send other 415 data protocol PDU during the interesting events. This optimization 416 is only possible when all the known advertisers participates in both 417 data-protocol. 419 A sender should send PDU to refresh before previously advertised 420 lifetime expires. If bgp is configured with only one transport 421 address family(IPv4/v6) then sender shall only send corresponding 422 data protocol PDU. If both addresses are configured, then it shall 423 use both data protocol PDUs. PDUs are sent with source address as 424 link primary address and destination is link local all- routers with 425 TTL 255. If authentication is enabled then add authentication TLV 426 using the authentication procedure described in authentication 427 section. Populate other TLVs based on local preference and send the 428 PDU on configured link. Semantic content (transport and session 429 information) of the PDU should be same irrespective of data protocol. 431 Receiver resets the state when it accepts new PDU irrespective of the 432 data protocol. Receiver shall add a route for the address in local 433 address TLV with nexthop as source address of the PDU if PDU(PUD) 434 data protocol and local address is same address family. Otherwise if 435 link address is available, it could be used as nexthop for the 436 address in local address TLV. Receivers consolidate state from 437 various TLVs and pass it on to BGP for the session opening. An 438 implementation could only notify if the state change from previous 439 reported state to bgp or the configuration sequence number changes 440 from the receiver. How bgp uses this information is beyond the scope 441 of the document. 443 5.1. Transmit procedure 445 PDUs are sent with source address as link's primary address and 446 destination is link local all-routers with TTL 255. PDU is sent to 447 SA UDP port(179 if assigned). After the header, SA Base message 448 should be first message. If authentication is enabled then add 449 authentication TLV using the authentication procedure described in 450 authentication section. This authentication TLV should be first TLV 451 of PDU. Add lifetime and config sequence TLVs defined in this 452 document. Both these TLVs are mandatory TLVs. After the SA base 453 message, add bgp service advertisement message with appropriate TLVs. 455 5.2. Receiver procedure 457 When a SA PDU received, following sanity procedure must be followed. 459 If TTL is not 255 then discard the PDU. 461 If the version is not compatible (Only compatible version is 0) then 462 discard the PDU. 464 If the PDU length is greater than IP header length, then discard it. 466 If the first message is not SA Base, then discard the pdu. 468 If authentication is enabled and first TLV in the SA base message, 469 then discard the PDU. 471 If authentication is enabled, then follow the authentication 472 procedure. 474 If authentication is failed, then discard the PDU. 476 With above steps, sanity of the PDU header is verified. Receiver 477 should start decoding the TLV information. Once all the TLV sanity 478 checked receiver shall keep the decoded information. If the receiver 479 decides to keep the information, then it should start a timer with 480 specified lifetime or refresh lifetime with newer one. 482 The identifier in PDU header uniquely identifies the advertisement. 483 An implementation could either implement neighbor semantic or state 484 semantic from the advertised information along with identifier. This 485 document does not recommend one or other. 487 Received and decoded information shall be passed on to bgp if the 488 content does not match with last received or the local config has 489 changed. This is a desired optimization, so that SA does not 490 unnecessarily trigger failed bgp session open attempts. How bgp uses 491 this information is beyond the scope of the document. 493 5.3. Transport endpoint reachability 495 Advertised local address reachability can either be gathered from the 496 source address or a link address TLV. Source address of the PDU may 497 not give reachability for all deployment(Sender using the IPv6 data 498 protocol but prefer v4 transport). In those cases, link address TLV 499 will provide reachability. 501 5.4. Protocol Authentication operation 503 A sender that wants to authenticate Service messages should include 504 Authentication TLV as part of SA base message. 506 Sender needs to include all the fields of Authentication TLV as shown 507 in section 4.1.3. It needs to assign a unique KEY-ID to each 508 authentication combination configured on the device. Key-length 509 needs to be set to configured key's length in bytes. Sequence number 510 is a 32-bit unsigned integer that may increment by one each time a 511 new message is sent. Any change in TLVs for a previously advertised 512 local address needs to be sent with an incremented TLV. Digest value 513 can be of variable length depending upon type of authentication being 514 used. This value is calculated over all the contents of service 515 message. 517 Receiver on receiving this TLV has a sequential processing of 518 individual fields of TLV. Sequence number is read from TLV and is 519 compared against any existing state from this sender. If sequence 520 number is lesser than previously received, this packet is dropped 521 except when bgp session goes down.If last received sequence number 522 was m and current received sequence number is n, n needs be in range 523 of [m+1, m + 2^(32 - 1)]. This exception is needed to handle a 524 restarted sender who is unable to retrieve earlier sequence number 525 due to restart. This is required when SA uses bigger lifetime. 526 After getting KEY-id, it checks for a matching KEY-ID on it. If it 527 does not exist, packet is dropped. Next Key-length of locally 528 configured key is compared against key-length received in this TLV, 529 if they do not match packet is dropped. Similarly, a comparison is 530 done for authentication types of locally configured key and received 531 TLV. If they do not match, packet is dropped. After above checks, 532 hash is computed for all the contents of service with locally 533 configured key and compared against received hash value. If they are 534 same, authentication information matches with local configuration and 535 messages can be further processed with protocol operations depending 536 on type of this message. 538 6. Acknowledgements 540 Jeffrey Hass provided many useful technical and editorial comments 541 and suggestions for improvement. 543 7. IANA Considerations 545 This document requests IANA to allocate a new UDP port (179 is the 546 preferred number ) and 2 message type code for service advertisments. 548 Value TLV Name Reference ----- 549 ------------------------------------ ------------- Service Name: 550 Service advertisements Transport Protocol: UDP Assignee: IESG 551 iesg@ietf.org Description: Service advertisments for auto 552 configuration. Reference: This document -- 553 draft-minto-idr-bgp-autodiscovery.txt Port Number: 179 -- To be 554 assigned by IANA. 556 Figure 7 558 7.1. Message of SA 560 This document requests IANA to create a new registry following 561 messages "Messages of SA " with the following registration procedure: 563 ? Registry Name: Messages of SA protocol 564 Value Message name Reference 565 ------- ---------------------------------- ------------- 566 0 Reserved This document 567 1 Base message This document 568 2 BGP Service Advertisement This document 570 Figure 8 572 7.2. TLVs of SA base Message 574 This document requests IANA to create a new registry following 575 messages "TLVs of SA base Message" with the following registration 576 procedure: 578 Registry Name: TLVs of SA base Message. 579 Value TLV Name Reference 580 -------- ---------------------------------- ------------- 581 0-16 Reserved This document 582 17 Remaining lifetime TLV This document 583 18 Config sequence TLV This document 584 19 Authentication This document 585 20 Refresh request TLV This document 586 224-255 Experimental 588 Figure 9 590 7.3. TLVs of BGP service advertisement message 592 This document requests IANA to create a new registry following 593 messages "TLVs of BGP Service Advertisement" with the following 594 registration procedure: 596 ? Registry Name: TLVs of BGP Services. 597 Value TLV Name Reference 598 -------- ---------------------------------- ------------- 599 0-16 Reserved This document 600 17 Local Address This document 601 18 Local IPv6 Address This document 602 19 Security TTL This document 603 20 Security Authentication This document 604 21 TCP MSS This document 605 22 Link Address This document 606 224-255 Experimental This document 608 Figure 10 610 8. Security Considerations 612 This security considerations for BGP [RFC4271] apply equally to this 613 extension for BGP session establishment. 615 BGP sessions transport end points discovered over this protocol can 616 be protected against various attacks by using authentication for 617 packets as described in Section 5.4. 619 Usage of seqeunce number and authentication reduces likelihood of 620 replay attacks. As the protocol is not connection-oriented, it makes 621 it feasible to change authentication parameters for protocol 622 messages. This further reduces the likelihood of replay-attacks. 624 9. References 626 9.1. Normative References 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, 630 DOI 10.17487/RFC2119, March 1997, 631 . 633 9.2. Informative References 635 [bgp-autoconf-considerations] 636 Narten, T. and H. Alvestrand, "Guidelines for Writing an 637 IANA Considerations Section in RFCs", RFC 5226, 638 DOI 10.17487/RFC5226, May 2008, 639 . 642 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 643 DOI 10.17487/RFC2629, June 1999, 644 . 646 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 647 Text on Security Considerations", BCP 72, RFC 3552, 648 DOI 10.17487/RFC3552, July 2003, 649 . 651 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 652 Protocol 4 (BGP-4)", RFC 4271, 2006, 653 . 655 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 656 IANA Considerations Section in RFCs", RFC 5226, 657 DOI 10.17487/RFC5226, May 2008, 658 . 660 Appendix A. Additional Stuff 662 This becomes an Appendix. 664 Authors' Addresses 665 Jeyananth Minto Jeganathan 666 Juniper Networks 667 Juniper Networks, 1133 Innovation Way 668 Sunnyvale, CA 94089 669 United States of America 671 Email: minto@juniper.net 673 Venkata Shiva Krishna Reddy Avula 674 Juniper Networks 675 Juniper Networks, 1133 Innovation Way 676 Sunnyvale, CA 94089 677 United States of America 679 Email: venkatashiva@juniper.net