idnits 2.17.1 draft-hildebrand-spud-prototype-03.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 == Line 142 has weird spacing: '...unknown no in...' == Line 145 has weird spacing: '...opening the i...' == Line 148 has weird spacing: '...running the t...' == Line 150 has weird spacing: '...esuming an ou...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 09, 2015) is 3307 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3168' is defined on line 615, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hildebrand 3 Internet-Draft Cisco Systems 4 Intended status: Informational B. Trammell 5 Expires: September 10, 2015 ETH Zurich 6 March 09, 2015 8 Substrate Protocol for User Datagrams (SPUD) Prototype 9 draft-hildebrand-spud-prototype-03 11 Abstract 13 SPUD is a prototype for grouping UDP packets together in a "tube", 14 also allowing network devices on the path between endpoints to 15 participate explicitly in the tube outside the end-to-end context. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 10, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 1. Introduction 51 The goal of SPUD (Substrate Protocol for User Datagrams) is to 52 provide a mechanism for grouping UDP packets together into a "tube" 53 with a defined beginning and end in time. Devices on the network 54 path between the endpoints speaking SPUD may communicate explicitly 55 with the endpoints outside the context of the end-to-end 56 conversation. 58 The SPUD protocol is a prototype, intended to promote further 59 discussion of potential use cases within the framework of a concrete 60 approach. To move forward, ideas explored in this protocol might be 61 implemented inside another protocol such as DTLS. 63 1.1. Terminology 65 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 66 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 67 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 68 [RFC2119]. 70 2. Requirements, Assumptions and Rationale 72 The prototype described in this document is designed to provide an 73 encapsulation for transport protocols which allows minimal and 74 selective exposure of transport semantics, and other transport- and 75 higher-layer information; and explicit discovery of selected 76 information about devices along the path by the transport and higher 77 layers. 79 The encryption of transport- and higher-layer content encapsulated 80 within SPUD is not mandatory; however, the eventual intention is that 81 explicit communication between endpoints and the path can largely 82 replace the implicit endpoint-to-path communication presently derived 83 by middleboxes through deep packet inspection (DPI). 85 SPUD is not a transport protocol; rather, we envision it as the 86 lowest layer of a "transport construction kit". Using SPUD as a 87 common encapsulation, such that new transports have a common 88 appearance to middleboxes, applications, platforms, and operating 89 systems can provide a variety of transport protocols or transport 90 protocol modules. This construction kit is out of scope for this 91 prototype, and left to future work, though we note it could be an 92 alternate implementation of an eventual TAPS interface. 94 The design is based on the following requirements and assumptions: 96 o SPUD must enable multiple new transport semantics without 97 requiring updates to SPUD implementations in middleboxes. 99 o Transport semantics and many properties of communication that 100 endpoints may want to expose to middleboxes are bound to flows or 101 groups of flows. SPUD must therefore provide a basic facility for 102 associating packets together (into what we call a "tube" for lack 103 of a better term). 105 o SPUD and transports above SPUD must be implementable without 106 requiring kernel replacements or modules on the endpoints, and 107 without having special privilege (root or "jailbreak") on the 108 endpoints. Eventually, we envision that SPUD will be implemented 109 in operating system kernels as part of the IP stack. However, we 110 also assume that there will be a (very) long transition to this 111 state, and SPUD must be useful and deployable during this 112 transition. In addition, userspace implementations of SPUD can be 113 used for rapid deployment of SPUD itself and new transport 114 protocols over SPUD, e.g. in web browsers. 116 o SPUD must operate in the present Internet. In order to ensure 117 deployment, it must also be useful as an encapsulation between 118 endpoints even before the deployment of middleboxes that 119 understand it. 121 o SPUD must be low-overhead, specifically requiring very little 122 effort to recognize that a packet is a SPUD packet and to 123 determine the tube it is associated with. 125 o SPUD must impose minimal restrictions on the transport protocols 126 it encapsulates. SPUD must work in multipath, multicast, and 127 mobile environments. 129 o SPUD must provide incentives for development and deployment by 130 multiple communities. These communities and incentives will be 131 defined through the prototyping process. 133 3. Lifetime of a tube 135 A tube is a grouping of packets between two endpoints on the network. 136 Tubes are started by the "initiator" expressing an interest in 137 comminicating with the "responder". A tube may be closed by either 138 endpoint. 140 A tube may be in one of the following states: 142 unknown no information is currently known about the tube. All tubes 143 implicitly start in the unknown state. 145 opening the initiator has requested a tube that the responder has 146 not yet acknowledged. 148 running the tube is set up and will allow data to flow 150 resuming an out-of-sequence SPUD packet has been received for this 151 tube. Policy will need to be developed describing how (or if) 152 this state can be exploited for quicker tube resumption by higher- 153 level protocols. 155 This leads to the following state transitions (see Section 4.3 for 156 details on the commands that cause transitions): 158 +---------------------+ +-----+ 159 | | |close| 160 | v | v 161 | +---sopen--- +-------+ <--close----+ 162 | | |unknown| | 163 | | +-----> +-------+ -ack,--+ | 164 | | | \ data | | 165 | | close open | | 166 | v | \ v | 167 | +-------+ ------data-------> +--------+ 168 | +-----|opening| ) |resuming|----+ 169 | | +-------+ <-----open-------- +--------+ | 170 | | ^ | / | ^ | 171 | | | | v | | | 172 | +-sopen-+ +-ack-> +-------+ <-ack,-+ +-data-+ 173 | |running| open 174 +---------close------ +-------+ 175 ^ | 176 | | open,ack,data 177 +----+ 179 Figure 1: State transitions 181 All of the state transitions happen when a command is received, 182 except for the "sopen" transition which occurs when an open command 183 is sent. 185 4. Packet layout 187 SPUD packets are sent inside UDP packets, with the SPUD header 188 directly after the UDP header. 190 0 1 2 3 191 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 2 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | magic = 0xd80000d8 | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | tube ID | 196 + + 197 | | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |cmd|a|p| resv | CBOR map... | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 2: SPUD packets 204 The fields in the packet are: 206 o 32-bit constant magic number (see Section 4.1) 208 o 64 bits defining the id of this tube 210 o 2 bits of command (see Section 4.3) 212 o 1 bit marking this packet as an application declaration (adec) 214 o 1 bit marking this packet as a path declaration (pdec) 216 o 4 reserved bits that MUST be set to 0 for this version of the 217 protocol 219 o If more bytes are present, they contain a CBOR map 221 4.1. Detecting usage 223 The first 32 bits of every SPUD packet is the constant bit pattern 224 d80000d8 (hex), or 1101 1000 0000 0000 1101 1000 (binary). This 225 pattern was selected to be invalid UTF-8, UTF-16 (both big- and 226 little-endian), and UTF-32 (both big- and little-endian). The intent 227 is to ensure that text-based non-SPUD protocols would not use this 228 pattern by mistake. A survey of other protocols will be done to see 229 if this pattern occurs often in existing traffic. 231 The intent of this magic number is not to provide conclusive evidence 232 that SPUD is being used in this packet, but instead to allow a very 233 fast (i.e., trivially implementable in hardware) way to decide that 234 SPUD is not in use on packets that do not include the magic number. 236 4.2. TUBE ID 238 The 64-bit tube ID uniquely identifies a given tube. All commands 239 (see Section 4.3) are scoped to a single tube. 241 [EDITOR'S NOTE: Does a Tube ID have to be bound to a single source 242 address or not? This would be for mobility, not multipath.] 244 4.3. Commands 246 The next 2 bits of a SPUD packet encode a command: 248 Data (00) Normal data in a running tube 250 Open (01) A request to begin a tube 252 Close (10) A request to end a tube 254 Ack (11) An acknowledgement to an open request 256 4.4. Declaration bits 258 The adec bit is set when the application is making a declaration to 259 the path. The pdec bit is set when the path is making a declaration 260 to the application. 262 4.5. Reserved bits 264 The final required four bits of SPUD packet MUST all be set to zero 265 in this version of the protocol. Implementors of this version of the 266 protocol MUST ignore these bits. 268 The reseved bits could be used for extensions in future versions. 270 4.6. Additional information 272 The information after the SPUD header (if it exists) is a CBOR 273 [RFC7049] map (major type 5). Each key in the map may be an integer 274 (major type 0 or 1) or a text string (major type 3). Integer keys 275 are reserved for standardized protocols, with a registry defining 276 their meaning. This convention can save several bytes per packet, 277 since small integers only take a single byte in the CBOR encoding, 278 and a single-character string takes at least two bytes (more when 279 useful-length strings are used). 281 The only integer keys reserved by this version of the document are: 283 0 (anything) Application Data. Any CBOR data type, used as 284 application-specific data. Often this will be a byte string 285 (major type 2), particularly for protocols that encrypt data. 287 The 0 key MUST NOT be used when the adec or pdec bit is set. Path 288 elements MUST NOT inspect or modify the contents of the 0 key. 290 The overhead for always using CBOR is therefore effectively three or 291 more bytes: 0xA1 (map with one element), 0x00 (integer 0 as the key), 292 and 0x41 (byte string containing one byte). [EDITOR'S NOTE: It may 293 be that the simplicity and extensibility of this approach is worth 294 the three bytes of overhead.] 296 5. Initiating a tube 298 To begin a tube, the initiator sends a SPUD packet with the "open" 299 command (bits 01). 301 Future versions of this specification may contain CBOR in the open 302 packet. One example might be requesting proof of implementation from 303 the receiving endpoint, 305 6. Acknowledging tube creation 307 To acknowledge the creation of a tube, the responder sends a SPUD 308 packet with the "ack" command (bits 11). The current thought is that 309 the security provided by the TCP three-way handshake would be left to 310 transport protocols inside of SPUD. Further exploration of this 311 prototype will help decide how much of this handshake needs to be 312 made visible to path elements that _only_ process SPUD. 314 Future versions of this specification may contain CBOR in the ack 315 packet. One example might be answering an implementation proof 316 request from the initiator. 318 7. Closing a tube 320 To close a tube, either side sends a packet with the "close" command 321 (bits 10). Whenever a path element sees a close packet for a tube, 322 it MAY drop all stored state for that tube. Further exploration of 323 this prototype will determine when close packets are sent, what CBOR 324 they contain, and how they interact with transport protocols inside 325 of SPUD. 327 What is likely at this time is that SPUD close packets MAY contain 328 error information in the following CBOR keys (and associated values): 330 "error" (map, major type 5) a map from text string (major type 3) to 331 text string. The keys are [RFC5646] language tags, and the values 332 are strings that can be presented to a user that understands that 333 language. The key "*" can be used as the default. 335 "url" (text string, major type 3) a URL identifying some information 336 about the path or its relationship with the tube. The URL 337 represents some path condition, and retrieval of content at the 338 URL should include a human-readable description. 340 8. Path declarations 342 SPUD can be used for path declarations: information delivered to the 343 endpoints from devices along the path. Path declarations can be 344 thought of as enhanced ICMP for transports using SPUD, allowing 345 information about the condition or state of the path or the tube to 346 be communicated directly to a sender. 348 Path declarations may be sent in either direction (toward the 349 initiator or responder) at any time. The scope of a path declaration 350 is the tube (identified by tube ID) to which it is associated. 351 Devices along the path cannot make declarations to endpoints without 352 a tube to associate them with. Path declarations are sent to one 353 endpoint in a SPUD conversation by the path device sending SPUD 354 packets with the source IP address and UDP port from the other 355 endpoint in the conversation. These "spoofed" packets are required 356 to allow existing network elements that pass traffic for a given 357 5-tuple to continue to work. To ensure that the context for these 358 declarations is correct, path declaration packets MUST have the pdec 359 bit set. Path declarations MUST use the "data" command (bits 00). 361 Path declarations do not imply specific required actions on the part 362 of receivers. Any path declaration MAY be ignored by a receiving 363 application. When using a path declaration as input to an algorithm, 364 the application will make decisions about the trustworthiness of the 365 declaration before using the data in the declaration. 367 The data associated with a path declaration may always have the 368 following keys (and associated values), regardless of what other 369 information is included: 371 "ipaddr" (byte string, major type 2) the IPv4 address or IPv6 372 address of the sender, as a string of 4 or 16 bytes in network 373 order. This is necessary as the source IP address of the packet 374 is spoofed 376 "token" (byte string, major type 2) data that identifies the sending 377 path element unambiguously 379 "url" (text string, major type 3) a URL identifying some information 380 about the path or its relationship with the tube. The URL 381 represents some path condition, and retrieval of content at the 382 URL should include a human-readable description. 384 "warning" (map, major type 5) a map from text string (major type 3) 385 to text string. The keys are [RFC5646] language tags, and the 386 values are strings that can be presented to a user that 387 understands that language. The key "*" can be used as the 388 default. 390 The SPUD mechanism is defined to be completely extensible in terms of 391 the types of path declarations that can be made. However, in order 392 for this mechanism to be of use, endpoints and devices along the path 393 must share a relatively limited vocabulary of path declarations. The 394 following subsections briefly explore declarations we believe may be 395 useful, and which will be further developed on the background of 396 concrete use cases to be defined as part of the SPUD effort. 398 Terms in this vocabulary considered universally useful may be added 399 to the SPUD path declaration map keys, which in this case would then 400 be defined as an IANA registry. 402 8.1. ICMP 404 ICMP [RFC4443] (e.g.) messages are sometimes blocked by path elements 405 attempting to provide security. Even when they are delivered to the 406 host, many ICMP messages are not made available to applications 407 through portable socket interfaces. As such, a path element might 408 decide to copy the ICMP message into a path declaration, using the 409 following key/value pairs: 411 "icmp" (byte string, major type 2) the full ICMP payload. This is 412 intended to allow ICMP messages (which may be blocked by the path, 413 or not made available to the receiving application) to be bound to 414 a tube. Note that sending a path declaration ICMP message is not 415 a substitute for sending a required ICMP or ICMPv6 message. 417 "icmp-type" (unsigned, major type 0) the ICMP type 419 "icmp-code" (unsigned, major type 0) the ICMP code 421 Other information from particular ICMP codes may be parsed out into 422 key/value pairs. 424 8.2. Address translation 426 SPUD-aware path elements that perform Network Address Translation 427 MUST send a path declaration describing the translation that was 428 done, only to the endpoint whose address was translated (the 429 "internal" side in a typical NAT deployment). It uses the following 430 key/value pairs: 432 "translated-external-address" (byte string, major type 2) The 433 translated external IPv4 address or IPv6 address for this 434 endpoint, as a string of 4 or 16 bytes in network order 436 "translated-external-port" (unsigned, major type 0) The translated 437 external UDP port number for this endpoint 439 "internal-address" (byte string, major type 2) The pre-translation 440 (internal) IPv4 address or IPv6 address for this endpoint, as a 441 string of 4 or 16 bytes in network order 443 "internal-port" (unsigned, major type 0) The pre-translation 444 (internal) UDP port number for this endpoint 446 The internal addresses are useful when multiple address translations 447 take place on the same path. 449 8.3. Tube lifetime 451 SPUD-aware path elements that are maintaining state MAY drop state 452 using inactivity timers, however if they use a timer they MUST send a 453 path declaration in both directions with the length of that timer, 454 using the following key/value pairs: 456 "inactivity-timer" (unsigned, major type 0) The length of the 457 inactivity timer (in microseconds). A value of 0 means no timeout 458 is being enforced by this path element, which might be useful if 459 the timeout changes over the lifetime of a tube. 461 8.4. Path element identity 463 Path elements can describe themselves using the following key/value 464 pairs: 466 "description" (text string, major type 3) the name of the software, 467 hardware, product, etc. that generated the declaration 469 "version" (text string, major type 3) the version of the software, 470 hardware, product, etc. that generated the declaration 472 "caps" (byte string, major type 2) a hash of the capabilities of the 473 software, hardware, product, etc. that generated the declaration 474 [TO BE DESCRIBED] 476 "ttl" (unisigned integer, major type 0) IP time to live / IPv6 Hop 477 Limit of associated device [EDITOR'S NOTE: more detail is required 478 on how this is calculated] 480 8.5. Maximum Datagram Size 482 A path element may tell the endpoint the maximum size of a datagram 483 it is willing or able to forward for a tube, to augment various path 484 MTU discovery mechanisms. This declaration uses the following key/ 485 value pairs: 487 "mtu" (unsigned, major type 0) the maximum transmission unit (in 488 bytes) 490 8.6. Rate Limit 492 A path element may tell the endpoint the maximum data rate (in octets 493 or packets) that it is willing or able to forward for a tube. As all 494 path declarations are advisory, the device along the path must not 495 rely on the endpoint to set its sending rate at or below the declared 496 rate limit, and reduction of rate is not a guarantee to the endpoint 497 of zero queueing delay. This mechanism is intended for "gross" rate 498 limitation, i.e. to declare that the output interface is connected to 499 a limited or congested link, not as a substitute for loss-based or 500 explicit congestion notification on the RTT timescale. This 501 declaration uses the following key/value pairs: 503 "max-byte-rate" (unsigned, major type 0) the maximum bandwidth (in 504 bytes per second) 506 "max-packet-rate" (unsigned, major type 0) the maximum bandwidth (in 507 packets per second) 509 8.7. Latency Advisory 511 A path element may tell the endpoint the latency attributable to 512 traversing that path element. This mechanism is intended for "gross" 513 latency advisories, for instance to declare the output interface is 514 connected to a satellite or [RFC1149] link. This declaration uses 515 the following key/value pairs: 517 "latency" (unsigned, major type 0) the latency (in microseconds) 519 8.8. Prohibition Report 521 A path element which refuses to forward a packet may declare why the 522 packet was not forwarded, similar to the various Destination 523 Unreachable codes of ICMP. 525 [EDITOR'S NOTE: Further thought will be given to how these reports 526 interact with the ICMP support from Section 8.1.] 528 9. Declaration reflection 530 In some cases, a device along the path may wish to send a path 531 declaration but may not be able to send packets ont he reverse path. 532 It may ask the endpoint in the forward direction to reflect a SPUD 533 packet back along the reverse path in this case. 535 [EDITOR'S NOTE: Bob Briscoe raised this issue during the SEMI 536 workshop, which has largely to do with tunnels. It is not clear to 537 the authors yet how a point along the path would know that it must 538 reflect a declaration, but this approach is included for 539 completeness.] 541 A reflected declaration is a SPUD packet with both the pdec and adec 542 flags set, and contains the same content as a path declaration would. 543 However the packet has the same source address and port and 544 destination address and port as the SPUD packet which triggered it. 546 When a SPUD endpoint receives a declaration reflection, it SHOULD 547 reflect it: swapping the source and destination addresses IP 548 addresses and ports. The reflecting endpoint MUST unset the adec 549 bit, sending the packet it as if it were a path declaration. 551 [EDITOR's NOTE: this facility will need careful security analysis 552 before it makes it into any final specification.] 554 10. Application declarations 556 Applications may also use the SPUD mechanism to describe the traffic 557 in the tube to the application on the other side, and/or to any point 558 along the path. As with path declarations, the scope of an 559 application declaration is the tube (identified by tube ID) to which 560 it is associated. 562 An application declaration is a SPUD packet with the adec flag set, 563 and contains an application declaration formatted in CBOR in its 564 payload. As with path declarations, an application declaration is a 565 CBOR map, which may always have the following keys: 567 o "token" (byte string, major type 2): an identifier for this 568 application declaration, used to address a particular path element 570 Unless the token matches one sent by the path element for this tube, 571 every device along the path MUST forward application declarations on 572 towards the destination endpoint. 574 The definition of an application declaration vocabulary is left as 575 future work; we note only at this point that the mechanism supports 576 such declarations. 578 11. CBOR Profile 580 Moving forward, we will likely specify a subset of CBOR that can be 581 used in SPUD, including the avoidance of floating point numbers, 582 indefinite-length arrays, and indefinite-length maps. This will 583 allow a significantly less complicated CBOR implementation to be 584 used, which would be particularly nice on constrained devices. 586 12. Security Considerations 588 This gives endpoints the ability to expose information about 589 conversations to elements on path. As such, there are going to be 590 very strict security requirements about what can be exposed, how it 591 can be exposed, etc. This prototype DOES NOT tackle these issues 592 yet. 594 The goal is to ensure that this layer is better than TCP from a 595 security perspective. The prototype is clearly not yet to that 596 point. 598 13. IANA Considerations 600 If this protocol progresses beyond prototype in some way, a registry 601 will be needed for well-known CBOR map keys. 603 14. Acknowledgements 605 Thanks to Ted Hardie for suggesting the change from "Session" to 606 "Substrate" in the title, and to Joel Halpern for suggesting the 607 change from "session" to "tube" in the protocol description. 609 15. References 610 15.1. Normative References 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, March 1997. 615 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 616 of Explicit Congestion Notification (ECN) to IP", RFC 617 3168, September 2001. 619 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 620 Message Protocol (ICMPv6) for the Internet Protocol 621 Version 6 (IPv6) Specification", RFC 4443, March 2006. 623 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 624 Languages", BCP 47, RFC 5646, September 2009. 626 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 627 Representation (CBOR)", RFC 7049, October 2013. 629 15.2. Informative References 631 [RFC1149] Waitzman, D., "Standard for the transmission of IP 632 datagrams on avian carriers", RFC 1149, April 1990. 634 Authors' Addresses 636 Joe Hildebrand 637 Cisco Systems 639 Email: jhildebr@cisco.com 641 Brian Trammell 642 ETH Zurich 644 Email: ietf@trammell.ch