idnits 2.17.00 (12 Aug 2021) /tmp/idnits8090/draft-lu-fn-transport-04.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 25, 2013) is 3372 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-enyedi-rtgwg-mrt-frr-algorithm-02 ** Downref: Normative reference to an Informational draft: draft-enyedi-rtgwg-mrt-frr-algorithm (ref. 'I-D.enyedi-rtgwg-mrt-frr-algorithm') == Outdated reference: draft-ietf-rtgwg-mrt-frr-architecture has been published as RFC 7812 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Lu 3 Internet-Draft S. Kini 4 Intended status: Standards Track A. Csaszar, Ed. 5 Expires: August 29, 2013 G. Enyedi 6 J. Tantsura 7 Ericsson 8 February 25, 2013 10 Transport of Fast Notification Messages 11 draft-lu-fn-transport-04 13 Abstract 15 This document specifies mechanisms for fast and light-weight 16 dissemination of event notifications. The purpose is to enable 17 dataplane dissemination of Fast Notifications (FNs). The draft 18 discusses the design goals, the message container and options for 19 delivering the notifications to all routers within a routing area. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 29, 2013. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Transport Logic - Distribution of the Notifications . . . . . 4 60 3.1. Flooding mode . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1.1. Duplicate Check with Flooding . . . . . . . . . . . . 5 62 3.2. Spanning Tree Mode . . . . . . . . . . . . . . . . . . . . 6 63 4. Message Encoding . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Seamless Encapsulation . . . . . . . . . . . . . . . . . . 6 65 4.2. Dedicated FN Message . . . . . . . . . . . . . . . . . . . 7 66 4.2.1. Authentication . . . . . . . . . . . . . . . . . . . . 8 67 4.2.1.1. Area-scoped and Link-scoped Authentication . . . . 9 68 4.2.1.2. Simple Password Authentication . . . . . . . . . . 9 69 4.2.1.3. Cryptographic Authentication for FN . . . . . . . 10 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 6. FN Packet Processing Summary . . . . . . . . . . . . . . . . . 13 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 76 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 77 Appendix A. Further Options for Transport Logic . . . . . . . . . 15 78 A.1. Multicast Tree-based Transport . . . . . . . . . . . . . . 15 79 A.1.1. Fault Tolerance of a Single Distribution Tree . . . . 16 80 A.1.2. Pair of Redundant Trees . . . . . . . . . . . . . . . 16 81 A.2. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 A.2.1. Method . . . . . . . . . . . . . . . . . . . . . . . . 18 83 A.2.2. Sample Operation . . . . . . . . . . . . . . . . . . . 19 84 A.3. Gated Multicast through RPF Check . . . . . . . . . . . . 19 85 A.3.1. Loop Prevention - RPF Check . . . . . . . . . . . . . 20 86 A.3.2. Operation . . . . . . . . . . . . . . . . . . . . . . 20 87 A.4. Further Multicast Tree based Transport Options . . . . . . 21 88 A.4.1. Source Specific Trees . . . . . . . . . . . . . . . . 21 89 A.4.2. A Single Bidirectional Shared Tree . . . . . . . . . . 22 90 A.5. Layer 2 Networks . . . . . . . . . . . . . . . . . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Introduction 95 Enabling fast dissemination of a network event to routers in a 96 limited area could benefit multiple applications. Existing use cases 97 are centered around new approaches for IP Fast ReRoute such as 98 [I-D.csaszar-ipfrr-fn]. In the future, however, multiple innovative 99 applications may take advantage of a Fast Notification service. 101 A hop by hop control plane based flooding mechanism is used widely 102 today in link state routing protocols such as OSPF and ISIS to 103 propagate routing information throughout an area. In this mechanism, 104 the information is processed in the control plane at each hop before 105 being forwarded to the next. The extra processing, scheduling, and 106 communications overhead causes unnecessary delays in the 107 dissemination of the information. 109 This draft proposes a generic fast notification (FN) protocol as a 110 separate transport layer, which focuses on delivering notifications 111 quickly in a secure manner. It can be used by many existing 112 applications to enhance the performance of those applications, as 113 well as to enable new services in the network. This draft does not 114 specify the payload of the notification. Each application is 115 required to create an own spec and define its payload as well as the 116 preferred transport options separately. 118 1.1. Requirements Language 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 1.2. Acronyms 126 FN - Fast Notification 128 IGP - Interior Gateway Protocol 130 IS-IS - Intermediate System to Intermediate System 132 MD5 - Message Digest 5 134 OSPF - Open Shortest Path First 136 RPF - Reverse Path Forwarding 137 SHA - Secure Hash 139 SPT - Shortest Path Tree 141 STP - Spanning Tree Protocol 143 2. Design Goals 145 A light-weight event notification mechanism that could be used to 146 facilitate quick dissemination of information in a limited area 147 should have the following properties. 149 1. The mechanism should be fast. It should provide low end to end 150 propagation delay for the notifications. 152 2. The signaling mechanism should offer a high degree of reliability 153 under network failure conditions. 155 3. The mechanism should be secure; that is, it should provide means 156 to verify the authenticity of the notifications. 158 4. The new protocol should not be dependent upon routing protocol 159 flooding procedures. 161 5. The mechanism should have low processing overhead. 163 These design goals present a trade-off. Proper balance needs to be 164 found that offers good authentication and reliability while keeping 165 processing complexity sufficiently low to enable implementation in 166 dataplane. This draft proposes solutions that take the above goals 167 and trade-offs into considerations. 169 It is important to note that information contained by the 170 notification packet may needed to be processed at multiple points in 171 the router (e.g. multiple linecards may need to react on that 172 message). This document describes the way of sending the information 173 between nodes, but distributing this information inside the node (if 174 needed) is out of the scope of this document. 176 3. Transport Logic - Distribution of the Notifications 178 The distribution of a notification to multiple receivers can be 179 implemented in many ways. The main body of this draft describes some 180 such options, however, other application specific distribution 181 mechanisms may exist. Some more details can be found in the 182 Appendix. 184 3.1. Flooding mode 186 In flooding mode, the IGP configures the dataplane cards to replicate 187 each received FN message to each interface with a neighbour router in 188 the same area. 190 This happens by making use of bidirectional multicast forwarding. In 191 bidir multicast, all interfaces added to the multicast group can be 192 incoming and outgoing interfaces as well. The principle is that a 193 router replicates the incoming packet to *all* assigned interfaces 194 except the incoming interface. If the local router is the source of 195 the packet to be forwarded, then the packet is replicated to all 196 interfaces. That is, the decision about which interfaces should 197 actually be used as outgoing is determined on demand. 199 First, the FN service is assigned a multicast group address, let us 200 call this MC-FN address. Then, the IGP assigns all interfaces to 201 MC-FN which lead to neighbouring routers selected by the IGP. 203 When the FN service is instructed to disseminate a message, it 204 creates an IP packet (as described below in Section 4) and sets its 205 IP destination address to the MC-FN multicast address. This IP 206 packet is then multicasted to all IGP neighbours in the area. 208 Recipients of FN multicast-forward the packet according to the rules 209 of bidirectional multicast, i.e. to all interfaces which the local 210 IGP pre-configured except the incoming interface. As this may cause 211 loops without pre-caution (consider three routers in a triangle), 212 before forwarding, therefore, the forwarding engine has to perform 213 duplicate check. 215 3.1.1. Duplicate Check with Flooding 217 Duplicate check can be performed in numeruous ways. 219 Duplicate check can be performed by maintaining a short queue of 220 previously forwarded FN messages. Before forwarding, if the FN 221 message is found in the queue, then it was forwarded beforehand, so 222 it may be dropped. Otherwise it should be forwarded and it should be 223 added to the queue. 225 Alternatively, the queue may contain a signature of the previously 226 forwarded FN messages, such as an MD5 or SHA256 signature or any 227 other hash. This signature may be carried in the packet, e.g. due to 228 authentication purposes, such as with the authentication mechanisms 229 described in Section 4.2.1. 231 In either of the above queue-based mechanisms, the size of the queue 232 can be set to a value that corresponds to the maximal number of legal 233 FN messages generated by a single event. For instance, if FN is used 234 to broadcast failure identifiers in case of failures, then it is 235 likely that the failure of the node with the most neighbours will 236 trigger the most FN messages (1 from each neighbour). 238 It is also possible to use application-dependent duplicate check: the 239 state machine of the FN-application can be left responsible to decide 240 whether the information carried in the packet contains new 241 information or it is a duplicate. This is only useful in the case if 242 the application can perform the duplicate check more efficiently than 243 the above generic mechanisms. Presently, [I-D.csaszar-ipfrr-fn] 244 specifies an application-specific duplicate check procedure. 246 3.2. Spanning Tree Mode 248 If reliable forwarding of notification packet is not always a strict 249 requirement, spanning trees may be used for forwarding. In the 250 simplest case, the nodes can build up a single spannig tree, and 251 notification packets can be forwarded along this tree with 252 bidirectional forwarding. This solution has the advantage that no 253 duplicate check is needed. The tree may be built up with 254 bidirectional PIM [RFC5015]. 256 Another possibility is to use Maximally Redundant Trees 257 [I-D.ietf-rtgwg-mrt-frr-architecture], a pair of spanning trees which 258 give some failure tolerance. Since the common root of these trees 259 can always be reached in the case of a single failure, and since the 260 root can reach all the nodes, notification packets sent on both trees 261 can tolerate any single failure, if the root propagates the packets 262 it received on both trees. Further details about spanning trees are 263 described in the Appendix. 265 4. Message Encoding 267 4.1. Seamless Encapsulation 269 An application may define its own message for FN to distribute 270 quickly. In this case, only the special destination address (e.g. 271 MC-FN) shows that the message was sent using the FN service. 273 In this case, the entire payload of the IP packet is determined by 274 the application including sequence numbering and authentication. The 275 IP packet's protocol field can also be set by the application. 277 4.2. Dedicated FN Message 279 An alternative option is for the FN messages to be distributed in UDP 280 datagrams with well-known port values in the UDP header that need to 281 be allocated by IANA. 283 The FN packet format inside a UDP datagram is the following: 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | | 289 +- -+ 290 | IP Header | 291 +- +-------------+ -+ 292 | | Protocol=UDP| | 293 +- +-------------+ -+ 294 | | 295 +- -+ 296 | | 297 +---------------------------------------------------------------+ 298 | UDP Source Port = FN | UDP Destination Port = FN | 299 +---------------------------------------------------------------+ 300 | UDP Header cont'd | 301 +---------------------------------------------------------------+ 302 | FN Header | 303 +---------------------------------------------------------------+ 304 | ... | 305 . . 306 . FN Payload . 307 . . 308 | ... | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | ... | 311 . . 312 . Authentication (optional) . 313 . . 314 | ... | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 1: FN packet format as a UDP datagram 319 The encoding of the FN Header is as follows: 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | FN Length | FN App Type | AuType|unused | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 2: FN Header encoding 329 FN Length (16 bits) 330 The length of the FN message in bytes including the FN Header and 331 the FN Payload. The authentication data optionally appended to 332 the FN packet is not considered part of the FN message: the 333 authentication data is not included in the FN Length field, 334 although it is included in the length field of the packet's IP 335 header. 337 FN App Type (8 bits) 338 Identifies the application which should be the receiver of the 339 notification. A value for each application needs to be assigned 340 by IANA. 342 AuType 343 Identifies the authentication procedure to be used for the packet. 344 Authentication options are discussed in Section 4.2.1 of the 345 specification. 347 4.2.1. Authentication 349 Fast Notification intends to provide a trustable service option, so 350 that receivers of FN packets are able to verify that the packet is 351 sent by an authentic source. Simple password authentication and hash 352 based authentication methods (with MD5 or SHA256) are described in 353 the following subsections. 355 If AuType is set to 0x0, then the FN packet is not carrying an 356 Authentication field at the end of the packet. Note that even in 357 this case the FN application in the payload may still use its own 358 authentication mechanism. 360 If AuType is non null, an Authentication field must be appended after 361 the FN message. The encoding of this field is as described below. 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | AuLength | ... Authentication Data ... | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | ... | 370 Figure 3: Authentication field in FN packets 372 AuLength 373 Describes the length of the entire Authentication field in bytes. 375 The authentication type may be manually pre-configured or may be 376 selected automatically. For automatic selection, the nodes have to 377 know what type of authentication is applicable for the rest of the 378 nodes. This may achieved by extending the IGP to advertise the FN 379 authentication capabilities. The most straightforward way to achieve 380 this is to extend the Router Capability TLVs available both in OSPF 381 [RFC4970] and in IS-IS [RFC4971]. 383 4.2.1.1. Area-scoped and Link-scoped Authentication 385 Since FN is a solution to disseminate an event notification from one 386 source to a whole area of nodes, the simplest approach would be to 387 use per-area authentication, e.g., a common password, a common pre- 388 shared key among all nodes in the area as described in the following 389 sub-sections, or digital signatures. 391 Carriers may, however, prefer per-link authentication. In order not 392 to lose the speed (simple per-hop processing, fast forwarding 393 property) of FN, link-scoped authentication is suggested only if the 394 forwarding plane supports it, i.e. if there is hardware support to 395 verify and re-generate authentication hop-by-hop. In such cases, the 396 operator may need to configure a common pre-shared key only on 397 routers connected by the same link. It is even possible that there 398 is no authentication on some links considered safe. 400 4.2.1.2. Simple Password Authentication 402 Simple password authentication guards against routers inadvertently 403 joining the routing area; each router must first be configured with a 404 password before it can participate in Fast Notification. 406 The password is stored in the Authentication Data field. AuLength is 407 set to the length of the password in bytes plus 1. Two AuType values 408 for simple password authentication need to be allocated by IANA: one 409 for area-scope and another for link-scoped. 411 With per-link authentication mode, the Authentication field must be 412 stripped and regenerated hop-by-hop. 414 Simple password authentication, however, can be easily compromised as 415 anyone with physical access to the network can read the password. 417 4.2.1.3. Cryptographic Authentication for FN 419 Using this authentication type, a secret key is used to generate/ 420 verify a "message digest" that is appended to the end of the FN 421 packet. The message digest is a one-way function of the FN packet 422 and the secret key. This authentication mechanism resembles the 423 cryptographic authentication mechanism of [RFC2328]. 425 4.2.1.3.1. MD5 427 The packet signature is created by an MD5 hash performed on an object 428 which is the concatenation of the FN message, including the FN 429 header, and the pre-shared secret key. The resulting 16 byte MD5 430 message digest is appended to the FN message into the Authentication 431 field as shown below. 433 The AuType in the FN header is set to indicate cryptographic 434 authentication, the specific value is to be assigned by IANA both for 435 area-scoped and for link-scoped versions. 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | AuLength | Key ID | Unused | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Message Digest (bytes 1-4) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Message Digest (bytes 5-8) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Message Digest (bytes 9-12) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Message Digest (bytes 13-16) | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Figure 4: Authentication field in FN packets with MD5 cryptographic 452 authentication. 454 AuLength 455 AuLength is set to 20 bytes. 457 Key ID 458 This field identifies the algorithm and secret key used to create 459 the message digest appended to the FN packet. This field allows 460 that multiple pre-shared keys may exist in parallel. 462 Message Digest 463 The 16 byte long MD5 hash performed on an object which is the 464 concatenation of the FN message, including the FN header, and the 465 pre-shared secret key identified by Key ID. 467 When receiving an FN message, if the FN header indicates MD5 468 authentication, then the last 20 bytes of the FN message are set 469 aside. The recipient forwarding plane element calculates a new MD5 470 digest of the remainder of the FN message to which it appends its own 471 known secret key identified by Key ID. The calculated and received 472 digests are compared. In case of mismatch, the FN message is 473 discarded. 475 In per-link authentication mode, the Authentication field must be 476 regenerated hop-by-hop using the key of the outgoing link. 478 4.2.1.3.2. SHA256 480 Similarly to how MD5 authentication works, it is possible to use 481 Secure Hash 256 hash. Currently this is a more secure hash function 482 than MD5. The Authentication field would look like this: 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | AuLength | Key ID | Unused | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Message Digest (bytes 1-4) | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Message Digest (bytes 5-8) | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | . . . | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Message Digest (bytes 25-28) | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Message Digest (bytes 29-32) | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 Figure 5: Authentication field in FN packets with MD5 cryptographic 501 authentication. 503 AuLength 504 AuLength is set to 36 bytes. 506 Key ID 507 This field identifies the algorithm and secret key used to create 508 the message digest appended to the FN packet. This field allows 509 that multiple pre-shared keys may exist in parallel. 511 Message Digest 512 The 32 bytes long SHA256 value calculated on an object which is 513 the concatenation of the FN message, including the FN header, and 514 the pre-shared secret key identified by Key ID. 516 When receiving an FN message, if the FN header indicates SHA256 517 authentication, then the last 68 bytes of the FN message are set 518 aside. The recipient forwarding plane element calculates a new 519 SHA256 digest of the remainder of the FN message to which it appends 520 its own known secret key identified by Key ID. The calculated and 521 received digests are compared. In case of mismatch, the FN message 522 is discarded. 524 In per-link authentication mode, the Authentication field must be 525 regenerated hop-by-hop using the key of the outgoing link. 527 4.2.1.3.3. Digital Signatures 529 A router may choose to use public key cryptography to digitally sign 530 the notification to provide certification of authenticity. This 531 mechanism can avoid shared secret that is required for other 532 authentication mechanisms described in this document. This 533 authentication mechanism resembles the authentication mechanism of 534 OSPF with digital signatures as defined in [RFC2154]. 536 5. Security Considerations 538 This draft has described basic optional procedures for 539 authentication. The mechanism, however, does not protect against 540 replay attacks. 542 If an application of FN require protection against replay attacks, 543 then these applications should provide their own specific sequence 544 numbering within the FN payload. Recipient applications should 545 accept FN messages only if the included sequence number is valid. 547 Since the message digest of cryptographic authentication also covers 548 the payload, even if an attacker knew how to construct the new 549 sequence number, it would not be able to generate a correct message 550 digest without the pre shared key. This way, a sequence number in 551 the payload combined with FN's cryptographic authentication offers 552 sufficient protection against replay attacks. 554 6. FN Packet Processing Summary 556 When receiving an FN packet, a node has to perform the following 557 steps. 559 It has to identify that the packet is an FN packet. This can be done 560 utilising the destination IP address (MC-FN) or by inspecting the UDP 561 port field. 563 If the flooding like transport logic described in Section 3 is used 564 the node has to perform duplicate check following the teachings in 565 Section 3.1.1. 567 If AuType is non-null, the node has to perform authentication check 568 as discussed in Section 4.2.1. 570 To protect against replay attacks, the node shall perform 571 verification of the sequence number provided by the application. 573 Punt and forward. The notification may need to be multicasted but it 574 also needs to be punted to the local application on the linecard to 575 start processing. 577 Authentication check, sequence number check and punting/forwarding 578 may commence in any order deemed necessary by the operator. If the 579 operator prefers highest level of security, then both checks should 580 be performed before forwarding. If, however, the operator prefers 581 per-hop performance but still wants to ensure that malice packets 582 cannot harm the network, then authentication and sequence number 583 checks may also happen after punting the packet, i.e. before 584 processing the information contained inside the FN payload. In this 585 case, malicious packets may get propagated to every node but they 586 still do not cause any change in the configuration. 588 7. IANA Considerations 590 A UDP port value needs to be assigned by IANA for FN. IANA also 591 needs to maintain values for FN App Type as applications are being 592 proposed. 594 Multicast addresses used for the distribution trees are either 595 allocated by IANA or they can be a configuration parameter within the 596 local domain. 598 8. Acknowledgements 600 The authors owe thanks to Acee Lindem, Joel Halpern and Jakob Heitz 601 for their review and comments. Also thanks to Alia Atlas for 602 constructive feedback. 604 9. References 606 9.1. Normative References 608 [I-D.enyedi-rtgwg-mrt-frr-algorithm] 609 Atlas, A., Envedi, G., Csaszar, A., and A. Gopalan, 610 "Algorithms for computing Maximally Redundant Trees for 611 IP/LDP Fast- Reroute", 612 draft-enyedi-rtgwg-mrt-frr-algorithm-02 (work in 613 progress), October 2012. 615 [I-D.ietf-rtgwg-mrt-frr-architecture] 616 Atlas, A., Kebler, R., Envedi, G., Csaszar, A., 617 Konstantynowicz, M., White, R., and M. Shand, "An 618 Architecture for IP/LDP Fast-Reroute Using Maximally 619 Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-01 620 (work in progress), March 2012. 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, March 1997. 625 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 627 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 628 Shaffer, "Extensions to OSPF for Advertising Optional 629 Router Capabilities", RFC 4970, July 2007. 631 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 632 System to Intermediate System (IS-IS) Extensions for 633 Advertising Router Information", RFC 4971, July 2007. 635 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 636 "Bidirectional Protocol Independent Multicast (BIDIR- 637 PIM)", RFC 5015, October 2007. 639 9.2. Informative References 641 [Eny2009] Enyedi, G., Retvari, G., and A. Csaszar, "On Finding 642 Maximally Redundant Trees in Strictly Linear Time, IEEE 643 Symposium on Computers and Communications (ISCC)", 2009. 645 [I-D.csaszar-ipfrr-fn] 646 Csaszar, A., Envedi, G., Tantsura, J., Kini, S., Sucec, 647 J., and S. Das, "IP Fast Re-Route with Fast Notification", 648 draft-csaszar-ipfrr-fn-03 (work in progress), June 2012. 650 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with 651 Digital Signatures", RFC 2154, June 1997. 653 Appendix A. Further Options for Transport Logic 655 The options described in this appendix represent alternative 656 solutions to the flooding based approach described in Section 657 Section 3. 659 It is left for WG discussion and further evaluation to decide whether 660 any of these options should potentially be preferred instead of 661 redundant trees. 663 A.1. Multicast Tree-based Transport 665 One way of transporting an identical piece of information to several 666 receivers at the same time is to use multicast distribution trees. A 667 tree based transport solution is beneficial since multicast support 668 is already implemented in all forwarding entities, so it is possible 669 to use existing implementations. 671 With multicast or tree based transport, the Fast Notification (FN) 672 packet can be recognized by a pre-configured or well known 673 destination IP address, denoted by MC-FN in the following, which is 674 the group address of the FN service. 676 If the FN service is triggered to send out a notification, the 677 notification will be encapsulated in a new IP packet, where the 678 destination IP address is set to MC-FN. 680 A.1.1. Fault Tolerance of a Single Distribution Tree 682 Several solutions described in this draft use a single tree to 683 disseminate a notification from one given source. 685 The single tree solution is simple, however it is not redundant: a 686 single failure may partition the tree, which will prevent 687 notifications from reaching some nodes in the area. 689 Different applications may have different needs for reliability. For 690 example, when we use fast notification to disseminate network failure 691 information, all nodes surrounding the failure can detect and 692 originate the failure notifications independently. Any one of these 693 notifications (or a subset of them) may be sufficient for the 694 application to make the right decision. This draft provides several 695 different transport options from which an applications can choose. 697 A.1.2. Pair of Redundant Trees 699 If an FN application needs the exact same data to be distributed in 700 the case of any single node or any single link failure, the FN 701 service could opt to run in "redundant tree mode". 703 A pair of "maximally redundant trees" 704 [I-D.enyedi-rtgwg-mrt-frr-algorithm] ensures that at each single node 705 or link failure each node still reaches the common root of the trees 706 through at least one of the trees. A redundant tree pair is a known 707 prior-art graph-theoretical object that is possible to find on any 708 2-node connected network. Even better, it is even possible to find 709 maximally redundant trees in networks where the 2-node connected 710 criterion does not "fully" hold (e.g. there are a few cut vertices) 711 [Eny2009], [I-D.ietf-rtgwg-mrt-frr-architecture]. 713 Note that the referenced algorithm(s) build a pair of trees 714 considering a specific root. The root can be selected in different 715 ways, the only thing that is important that each node makes the same 716 selection, consistently. For instance, the node with the highest or 717 lowest router ID can be used. 719 #1 tree #2 tree 720 +---+ +---+ +---+ +---+ 721 | B |=======| | | B |=======| | 722 +---+ +---+ +---+ +---+ 723 // \\ // \ 724 // \\ // \ 725 +---+ +---+ +---+ +---+ 726 | A |---------------------| R | | A |=====================| R | 727 +---+ +---+ +---+ +---+ 728 \ // \\ / 729 \ // \\ / 730 +---+ +---+ +---+ +---+ 731 | |=======| | | |=======| | 732 +---+ +---+ +---+ +---+ 734 Figure 6: Example: a pair of redundant trees (double lines) of a 735 common root R 737 There is one special constraint in building the redundant trees. A 738 (maximally) redundant tree pair is needed, where in one of the trees 739 the root has only one child in order to protect against the failure 740 of the root itself. Algorithms presented in [Eny2009], 741 [I-D.enyedi-rtgwg-mrt-frr-algorithm] produce such trees. 743 In redundant-tree mode, each node multicasts the requested 744 notification on both trees, if it is possible, but at least along one 745 of the trees. Redundant trees require two multicast group addresses. 746 MC-FN identifies one of the trees, and MC-FN-2 identifies the other 747 tree. 749 Each node multicast forwards the received notification packet (on the 750 same tree). The root node performs as every other node but in 751 addition it also multicast the notification on the other tree! I.e. 752 it forwards a replica of the incoming notification in which it 753 replaces the destination address identifying the other multicast 754 distribution tree. 756 When the network remains connected and the root remains operable 757 after a single failure, the root will be reached on at least one of 758 the trees. Thus, since the root can reach every node along at least 759 one of the trees, all the notifications will reach each node. 760 However, when the root or the link to the root fails, that tree, in 761 which the root has only one child, remains connected (the root is a 762 leaf there), thus, all the nodes can be reached along that tree. 764 For example, let us consider that in Figure 6 FN is used to 765 disseminate failure information. If link A-B fails, the 766 notifications originating from node B (e.g. reporting that the 767 connectivity from B to A is lost) will reach R on tree #1. 768 Notifications originating from A (e.g. reporting that the 769 connectivity from A to B is lost) will reach R on tree #2. From R, 770 each node is reachable through one of the trees, so each node will be 771 notified about both events. 773 A.2. Unicast 775 This method addresses the need in a unique way. It has the following 776 properties: 778 Plain simple, without the need of any forwarding plane change or 779 cooperation; 781 Short turnaround time (i.e. ready for next hit); 783 100% link break coverage (may not work in certain node failure 784 cases); 786 Little change to OSPF (need encapsulation for IS-IS). 788 A.2.1. Method 790 The method is simple in design, easy to implement and quick to 791 deploy. It requires no topology changes or specific configurations. 792 It adds little overhead to the overall system. 794 The method sends the event message to every router in the area in an 795 IP packet. This appears burdensome to the sending router which has 796 to duplicate the packet sending effort many times. Practical 797 experience has shown, however, that the amount of effort is not a big 798 concern in reasonable sized networks. 800 Normal flooding (regular or fast) process requires a router to 801 duplicate the packet to all flooding eligible interfaces. All 802 routers have to be fast-flooding-aware. This implies new code to 803 every router in control plane and/or forwarding plane. 805 The method uses a different approach. It takes advantage of the 806 given routing/forwarding table in each router in the IP domain. The 807 originating router of the flooding information simply sends multiple 808 copies of the packet to each and every router in the domain. These 809 packets are forwarded to the destination routers at forwarding plane 810 speed, 812 just like the way the regular IP data traffic is handled. No special 813 handling in any other routers is needed. 815 This small delay on the sender can be minimized by pre-downloading 816 the link-broken message packets to the forwarding plane. Since the 817 forwarding plane already has the list of all routers which are part 818 of the IGP routing table, the forwarding plane can dispatch the 819 packet directly. 821 In essence, the flooding in this method is tree based, just like a 822 multicast tree. The key is that no special tree is generated for 823 this purpose; the normal routing table which is an SPF tree (SPT) 824 plays a role of the flooding tree. This logic guarantees that the 825 flooding follows the shortest path and no flooding loop is created. 827 A.2.2. Sample Operation 829 Figure 7 depicts a scenario where router A wants to flood its message 830 to all other routers in the domain using the unicast flooding method. 832 Instead of sending one packet to each of its neighbor, and letting 833 the neighbor flood the packet further, router A directly send the 834 same packet to each router in the domain, one at a time. In this 835 sample network, router A sends out 5 packets. 837 A---B---C---D 838 \ 839 --E---F 841 1. Packet(A->B); 842 2. Packet(A->C); 843 3. Packet(A->D); 844 4. Packet(A->E); 845 5. Packet(A->F). 847 Figure 7: Multiple Unicast Packets 849 The unicast flooding procedure is solely controlled by the sending 850 router. No action is needed from other routers other than their 851 normal forwarding functionalities. This method is extremely simple 852 and useful for quick prototyping and deployment. 854 A.3. Gated Multicast through RPF Check 856 This method fulfills the purpose with the following characters: 858 1. No need to build the multicast tree. It is the same as the SPT 859 computed by the IGP routing process; 861 2. Flooding loops are prevented by RPF Check. 863 The method has all the benefits of multicast flooding. It, however, 864 does not require running multicast protocol to setup the multicast 865 tree. The unicast shortest path tree is used as a multicast tree. 867 A.3.1. Loop Prevention - RPF Check 869 In this mechanism, the distribution tree is not explicitly built. 870 Rather, each node will first do a Reverse Path Forwarding (RPF) check 871 before it floods the notification to other links. 873 A special multicast address is defined and is subject to IANA 874 approval. This address is used to qualify the notification packet 875 for fast flooding. When a notification packet arrives, the receiving 876 node will perform an IP unicast routing table lookup for the 877 originator IP address of the notification and find the outgoing 878 interface. Only when the arriving interface of the notification is 879 the same as the outgoing interface leading towards the originator IP 880 address, will the notification be flooded to other interfaces. 882 IP Multicast forwarding with RPF check is available on most of the 883 routing/switching platforms. To support flooding with RPF check, a 884 special IP multicast group must be used. A bi-directional IP 885 multicast forwarding entry is created that consists of all interfaces 886 within the flooding scope, typically an IGP area. 888 A.3.2. Operation 890 The Gated flooding operation is illustrated in Figure 8. 892 All Routers, IGP Process: 893 if (SPT ready) { 894 duplicate the SPT as Bidir_Multicast_tree; 895 download the multicast_tree to forwarding plane; 896 } 897 add FNF_multicast_group_addr; 899 Sender of the FNF notification: 900 if (breakage detected) { 901 pack the notification in a packet; 902 send the packet to the FNF_multicast_group_addr; 903 } 905 Receiver of the FNF notification: 906 if (notification received) { 907 if (RPC_interface == incoming_interface) { 908 multicast the notification to all other interfaces; 909 } 910 forward the notification to IGP for processing; 911 } 913 Figure 8: Gated flooding operation 915 Figure 9 shows a sample operation on a four-router mesh network. The 916 left figure is the topology. The right figure is the shortest path 917 tree rooted at A. 919 Router A initiates the flooding. But the downstream routers B, C, 920 and D will drop all messages except the ones that come from their 921 shortest path parent node. For example, A's message to C via B is 922 dropped by C, because C knows that its reverse path forwarding (RPF) 923 nexthop is A. 925 A A 926 /|\ / \ 927 B---C B C 928 \|/ \ 929 D D 931 Figure 9: Loop Prevention through the RPF check 933 A.4. Further Multicast Tree based Transport Options 935 A.4.1. Source Specific Trees 937 One implementation option is to rely on source specific multicast. 938 This means that even though there is only a single multicast group 939 address (MC-FN) allocated to the FN service, the FIB of each router 940 is configured with forwarding information for as many trees as many 941 FN sources (nodes) there are in the routing area, i.e. to each 942 (S_i,MC-FN) pair. 944 A.4.2. A Single Bidirectional Shared Tree 946 In the previous solution each source specific tree is a spanning 947 tree. It is possible to reduce the complexity of managing and 948 configuring n spanning trees in the area by using bidirectional 949 shared trees. By building a bidirectional shared tree, all nodes on 950 the tree can send and receive traffic using that single tree. Each 951 sent packet from any source is multicasted on the tree to all other 952 receivers. 954 The tree must be consistently computed at all routers. For this, the 955 following rules may be given: 957 The tree can be computed as a shortest path tree rooted at e.g. the 958 highest router-id. When multiple paths are available, the 959 neighbouring node in the graph e.g. with highest router-id can be 960 picked. When multiple paths are available through multiple 961 interfaces to a neighbouring node, e.g. a numbered interface may be 962 preferred over an unnumbered interface. A higher IP address may be 963 preferred among numbered interfaces and a higher ifIndex may be 964 preferred among unnumbered interfaces. 966 Note, however, that the important point is that the rules are 967 consistent among nodes. That is, a router may pick the lower router 968 IDs if it is ensured that ALL routers will do the same to ensure 969 consistency. 971 Multicast forwarding state is installed using such a tree as a bi- 972 directional tree. Each router on the tree can send packets to all 973 other routers on that tree. 975 Note that the multicast spanning tree can be built using [RFC5015] so 976 that each router within an area subscribes to the same multicast 977 group address. Using BIDIR-PIM in such a way will eventually build a 978 multicast spanning tree among all routers within the area. (BIDIR- 979 PIM is normally used to build a shared, bidirectional multicast tree 980 among multiple sources and receivers.) 982 A.5. Layer 2 Networks 984 Layer 2 (e.g. Ethernet) networks offer further options for 985 distributing the notification (e.g. using spanning trees offered by 986 STP). Definition of these is being considered and will be included 987 in a future revision of this draft. 989 Authors' Addresses 991 Wenhu Lu 992 Ericsson 993 300 Holger Way 994 San Jose, California 95134 995 USA 997 Email: Wenhu.Lu@ericsson.com 999 Sriganesh Kini 1000 Ericsson 1001 300 Holger Way 1002 San Jose, California 95134 1003 USA 1005 Email: Sriganesh.Kini@ericsson.com 1007 Andras Csaszar (editor) 1008 Ericsson 1009 Irinyi J utca 4-10 1010 Budapest 1117 1011 Hungary 1013 Email: Andras.Csaszar@ericsson.com 1015 Gabor Sandor Enyedi 1016 Ericsson 1017 Irinyi J utca 4-10 1018 Budapest 1117 1019 Hungary 1021 Email: Gabor.Sandor.Enyedi@ericsson.com 1022 Jeff Tantsura 1023 Ericsson 1024 300 Holger Way 1025 San Jose, California 95134 1026 USA 1028 Email: Jeff.Tantsura@ericsson.com