idnits 2.17.1 draft-richardson-6tisch-security-architecture-02.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 date (April 28, 2014) is 3644 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '6top' is mentioned on line 323, but not defined == Unused Reference: 'RFC6869' is defined on line 564, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-01 == Outdated reference: A later version (-04) exists of draft-wang-6tisch-6top-sublayer-00 == Outdated reference: A later version (-11) exists of draft-ietf-roll-security-threats-06 == Outdated reference: A later version (-01) exists of draft-pritikin-bootstrapping-keyinfrastructures-00 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-00 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Richardson 3 Internet-Draft SSW 4 Intended status: Informational April 28, 2014 5 Expires: October 30, 2014 7 security architecture for 6top: requirements and structure 8 draft-richardson-6tisch-security-architecture-02 10 Abstract 12 This document details security requirements for 6tisch nodes that use 13 6top in an industrial settings. Layer-2 and a layer-4 authentication 14 and authorization requirements and assumptions are identified. Two 15 approaches to accomplishing these requirements are outlined, with the 16 goal of eventually picking one. This internet-draft is intended for 17 later inclusion into the 6tisch architecture document. 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 http://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 October 30, 2014. 36 Copyright Notice 38 Copyright (c) 2014 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 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction: secure bootstrap requirements . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 1.2. layer-2 join . . . . . . . . . . . . . . . . . . . . . . 4 56 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.4. Use of 802.1AR certificates . . . . . . . . . . . . . . . 5 58 1.4.1. Proxy Discovery . . . . . . . . . . . . . . . . . . . 5 59 1.4.2. Registrar/Authorization server access to certificate 60 chain . . . . . . . . . . . . . . . . . . . . . . . . 6 61 1.4.3. Receiving and accepting the Domain Identity . . . . . 7 62 1.4.4. Enrollment . . . . . . . . . . . . . . . . . . . . . 7 63 1.5. 6top/PCE security requirements . . . . . . . . . . . . . 8 64 1.5.1. no-PCE and 6LR to 6LR 6top authorization . . . . . . 8 65 2. leveraging layer-2 identities for layer-4 security . . . . . 8 66 3. Layer-2 Join . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.1. option 1: The ZigBeeIP/PANA way . . . . . . . . . . . . . 8 68 3.1.1. Network Discovery . . . . . . . . . . . . . . . . . . 8 69 3.1.2. PANA protocol . . . . . . . . . . . . . . . . . . . . 9 70 3.1.3. Authorization . . . . . . . . . . . . . . . . . . . . 9 71 3.1.4. Advantages of the EAP-TLS based methods . . . . . . . 9 72 3.1.5. Bandwidth considerations for joins . . . . . . . . . 9 73 3.1.6. Challenges with this method . . . . . . . . . . . . . 10 74 3.2. option 2: The WirelessHart/ISA100 way . . . . . . . . . . 10 75 3.2.1. Advantages of this method . . . . . . . . . . . . . . 11 76 3.2.2. Challenges with the CoAP method . . . . . . . . . . . 11 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 78 5. Other Related Protocols . . . . . . . . . . . . . . . . . . . 11 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 82 8.1. Normative references . . . . . . . . . . . . . . . . . . 11 83 8.2. Informative references . . . . . . . . . . . . . . . . . 12 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction: secure bootstrap requirements 87 There are five security problems that must be solved in the 6tisch 88 environment in order to permit the nodes to come together and 89 function as a network. They are: 91 layer 2 join: new nodes must be recognized by the network, and 92 provided with layer-2 symmetric credentials 94 zero-touch join: new nodes must recognize the network without 95 explicit provisioning, and attempt to join 97 new nodes must become a part of the RPL DODAG, and make contact 98 with parent and child nodes 100 in networks with a PCE, new nodes must authorize the PCE to 101 update the nodes' schedule using 6top 103 in networks without a PCE, and some situations where a PCE 104 delegates details of a bundle to the nodes, the nodes must be 105 authorized to allocate time slots in their DODAG children 107 This document, presently a stand-alone document, but later to be a 108 section of [I-D.ietf-6tisch-architecture], explains the assumptions 109 of how the node is expected to be provisioned in the factory, and how 110 it will react to networks that it encounters. As is explained in 111 every Internet of Things document, the nodes are constrainted, have 112 no end-user interfaces, and therefore it is desired that they 113 function in a "zero-touch" manner. 114 [I-D.irtf-nmrg-autonomic-network-definitions] introduces the term 115 "autonomic", and it is exactly the properties described there that 116 are desired for 6tisch networks. 118 A 802.1AR [IEEE.802.1AR] certificate provisioned in each node at the 119 factory, combined with a certificate chain provided to the network 120 service provider, permits the node to be recognized by the network, 121 and also for the network to assert it's authority to own and control 122 the node. The authentication part of a security protocol (TLS, DTLS, 123 EAP-TLS, details TBD) will establish identities, and then, said 124 security protocol will be used to provide integrity protection for a 125 control protocol (YANG/6top, as discussed in 126 [I-D.wang-6tisch-6top-sublayer]) to configure the TSCH cells. 128 1.1. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [RFC2119]. 134 1.2. layer-2 join 136 As outlined in [I-D.ietf-roll-security-threats] there are a number of 137 threats in LLNs, and in RPL which are solved if there is layer-2 138 security. The requirement is therefore to provide keying for the 139 layer-2 security features: encryption and integrity protection. 141 In addition to serving to protect the routing traffic against 142 attacks, use of the layer-2 access control serves as adminission 143 control to the network. It is therefore part of the layer-2 join 144 process to authenticate the new node, as well as authorize it to join 145 the network. The admission control SHOULD be controlled by autonomic 146 certificates, as described below. 148 1.3. Terminology 150 Plant Installation: the (6tisch) network installed for control 151 purposes. 153 >Service Provider: the operator of the network. The service 154 provider may a department internal to the plant, or 155 may be an external contractor. It is a role. 157 Authorization server: a centralized entity that makes both layer-2 158 admission control decisions, and acting as a super- 159 user for all nodes, delegates 6top authorization to a 160 PCE, or to parent nodes for PCE-less operation. 162 New Entity: a new 6LN that wishes to join the network. 164 [I-D.pritikin-bootstrapping-keyinfrastructures] explains the 165 architecture for use of 802.1AR certificates in a bootstrap process. 166 In that document a number of terms of introduced, and in this section 167 those terms are mapped to 6tisch entities and processes. Section 2 168 of [I-D.pritikin-bootstrapping-keyinfrastructures] defines: 170 Domain: this refers to the entire 6tisch installation 172 Domain CA: this is a CA operated by the service provider. It is 173 a role: physically, it may be co-located with an 174 Authorization Server and/or with a PCE and have 175 private interfaces with those entities, or may be 176 elsewhere with interfaces to be determined, but out 177 of scope for this document. 179 Orchestrator: the role of the orchestrator is provided by 180 Authorization Server (a term used by both ACE and 181 PANA [RFC5191]), or the EAP Server (see [RFC5247]). 183 Factory: this is the vendor of the mote. It may consist of a 184 supplier chain of value-added resellers. 186 Factory CA: this is the root CA that is placed into the mote. 187 Each device also has an 802.1AR identity issued from 188 that CA. 190 Registrar: the role of registrar is performed by the 191 Authorization Server. 193 MASA Cloud Service: A Manufacturer Authorized Signing Authority. 194 These will typically be co-located in the 195 Authorization Server. 197 1.4. Use of 802.1AR certificates 199 This section explains how the process detailed in 200 [I-D.pritikin-bootstrapping-keyinfrastructures] is to be implemented 201 in the 6tisch case. To recap, the process looks like: 203 (1) Proxy Discovery 205 (2) Receiving and accepting the Domain Identity 207 (3) Enrollment 209 (4) After Enrollment 211 (5) Behavior of a proxy 213 (6) Behavior of the Registrar 215 (7) Authenticating the Device 217 (8) Accepting the Entity 219 (9) Claiming the new entity 221 (10) Behavior of the MASA Cloud Service 223 (11) Issue Authorization Token and Log the event 225 1.4.1. Proxy Discovery 227 The Proxy Discovery step may occur via one of two mechanisms, which 228 are further described in section Section 3. One method involves 229 using an EAP-TLS (or rather, EAP-EST, as imagined by 230 [I-D.pritikin-bootstrapping-keyinfrastructures]), over either 1X or 231 PANA. A nearby node provides a PANA Authentication Agent (PAA) 232 ([RFC5191]), or 802.1X Authenticator. A well-known L2-JOIN key is 233 used during bootstrap. A second method involves using leveraging the 234 ARO ND messages that 6LOWPAN mandates be exchanged. 236 In either case, a (D)TLS channel is created from the New Entity/6LN 237 to the Registrar/Authorization Server 239 1.4.1.1. Certificate Chains 241 In forming the TLS channel, two certificate chains are validated. 242 The Registrar validates a certificate (possibly chain) presented by 243 the New Entity. This certificate chain would be communicated using 244 the TLS Client Certificate message. The Registrar sends a 245 certificate chain in the TLS Server Certificate message which the New 246 Entity must be able to validate. 248 As the Registar will in general perform enrollment for all 6LN on a 249 network, it will have multiple identities, and should send only the 250 certificate chain relevant to each New Entity. 252 The New Entity must also send some TBD extension to the server to 253 indicate who it is. This has to be done before the server sends it's 254 Server Certificate message. This is a variation of the problem the 255 TLS 1.2 SNI extension was designed to solve. 257 1.4.2. Registrar/Authorization server access to certificate chain 259 The certificate chain that the Registrar returns may not exist until 260 the New Entity attempts to join. It may be retrieved/created through 261 a number of different mechanisms which are out of scope of this 262 document, but may include: 264 (1) loaded from a diskette/USB/QR code that was included in the 265 packaging 267 (2) downloaded via some interactive web interface provided by the 268 manufacturer and/or logistics company 270 (3) acquired via an online enrollment protocol, such as EST 271 protocol. This could be secured using a one-time password 272 provided in the packaging. 274 (4) out of band, by having a human talk to another human. 276 An important aspect to note is that it may be some minutes to days 277 between the time the New Entity initiates the join operation, and 278 when the Registrar is able to respond properly: some kind of error 279 code and back-off process may be appropriate. 281 1.4.3. Receiving and accepting the Domain Identity 283 The two certificate chains described in the previous section are 284 critical for permitting the zero-touch operation of the 6LN New 285 Entity. This section describes the contents of the Server 286 Certificate that the 6LN expects to verify. For the purposes of this 287 explanation, assume the 6LN has a deviceID of 3145191, and is 288 manufactured by Example Corp, that it was distributed by Example 289 Logistics, and it is being installed at ACME Widgets. 291 The certificate chain will be rooted with the 6LN's manufacturer 292 certificate: Example Corp. 294 (a) An 802.1AR certificate signed by Example Corp. delegates 295 deviceID 3145191 to Example Logistics. 297 (b) An 802.1AR certificate signed by Example Logistics delegates 298 deviceID 3145191 to ACME Widgets 300 This chain permits the 6LN to verify that ACME Widgets is in fact 301 it's rightful owner. The certificate chain MAY have a validity 302 permit, or MAY be valid indefinitely. Given that it is unlikely that 303 the 6LN will have a reliable real-time clock, or access to a secure 304 network time source, validation of validity permits may be useless. 306 The certificate chain that the New Entity presents to the Registrar 307 would look like: 309 (a) An 802.1AR certificate signed by Example Corp. binds deviceID 310 3145191 to the public key of the New Entity. 312 1While a longer certificate chain could be embedded in the device, it 313 is not advised. Any part of the manufacturing chain that can do such 314 a thing should simply put it's own identity there, and provide a new 315 certificate chain path to the Registrar. 317 1.4.4. Enrollment 318 1.5. 6top/PCE security requirements 320 In addition to authorization a node to join the network, the node 321 agree to provide authorization to a PCE in order for the 6top 322 protocol to run. This protocol, described in section X of 6tisch 323 architecture (this) document and in [6top], permits the PCE to 324 program a timeslot schedule into the node. 326 So, the second part of the 6tisch security requirements is to 327 establish the identities of the the node and the PCE, and to 328 establish an authorization that permits the new node to be programmed 329 by the PCE. 331 1.5.1. no-PCE and 6LR to 6LR 6top authorization 333 2. leveraging layer-2 identities for layer-4 security 335 As explained in [I-D.behringer-autonomic-network-framework] the 336 layer-2 identity of the node will be given by a certificate signed by 337 the vendor of the node. The vendor's certificate authority is loaded 338 into the (PANA) Authorization Server, and permits the AS to 339 authenticate the node. 341 The vendor provides a certificate (chain) to the (PANA) Authorization 342 Server (PAS) attesting to that the PAS is the rightful owner/ 343 controller of the node. This permits the node to validate that the 344 network it is joining is the correct network. This process permits 345 the bootstrap of one of the layer-2 security mechanism(s) describe in 346 sections below. 348 The same set of trust relationships can then permit the PAS to act as 349 an Authorization Server (now, in the context of 350 [I-D.gerdes-core-dcaf-authorize]). The PCE and it's Authorization 351 Manager (AM, again from [I-D.gerdes-core-dcaf-authorize]) can now get 352 a ticket to permit it to write the timeslot schedule. In option 2, 353 below, it also permits updates to the security parameters. 355 3. Layer-2 Join 357 3.1. option 1: The ZigBeeIP/PANA way 359 This is an adaptation of the process described in [ZigBeeIP], section 360 and expounded upon in section 6.3: "Network Discovery", 6.4: "Network 361 Selection", and 6.5, "Node Joining". The process is abridged below. 363 3.1.1. Network Discovery 364 The MAC beacon facility is used. A critical difference in 6tisch 365 from ZigBee IP is that because nodes transmit and receive according 366 to their own schedule, every node is in essence a coordinator. While 367 nodes may sleep a lot, they will not in general be sleep Hosts, from 368 a ZigBee IP point of view, and MLE is not necessary. 370 Each response to the Beacon is a potential network-joining-parent. 372 As an option, it may be desireable for this document to define a well 373 known NetworkID. 375 3.1.2. PANA protocol 377 The PANA payloads MUST be relayed by the chosen network-joining- 378 parent. It is assumed that the PANA Authentication Agent is co- 379 located with the PCE, if there is a PCE. 381 As per section 8.3.4 of [ZigBeeIP], the PANA process runs over UDP 382 using link-layer addressing. The process is first the PANA 383 initialization (PCI, PAR:S, PAN:S), followed by EAP initialization 384 (EAP-Request, EAP-Response), which negotiates the identity, and then 385 EAP-TLS starts, consisting of (TLS(Start), TLS(ClientHello), 386 TLS(ServerHello), TLS(ServerKeyExchange), TLS(ClientKeyExchange), and 387 TLS(ChangeCipherSpec)). 389 When the TLS is done, the EAP derives new network security material, 390 and sends it encrypted using the Encr-Encap AVP described in 391 [RFC6786]. 393 3.1.3. Authorization 395 QUESTION: can we find a way for the authorization protocol, such as 396 described in draft-gerdes-core-dcaf-authorize-01, to run 397 simultaenously with the authentication system if we assume that the 398 dcaf AS is also the PANA Authentication Server/Agent 400 In the context of draft-selander-core-access-control, the new node 401 that is joining is the resource server, and the origin client is the 402 PCE. 404 3.1.4. Advantages of the EAP-TLS based methods 406 3.1.5. Bandwidth considerations for joins 408 Calculations show that with a contention-based medium, using slotted 409 Aloha style, there will be only 1-3 cells available per slotframe, at 410 most 36% of bandwidth. Typical slotframes repeat 10 times/second. 411 Calculations show that it take about 10-15s for each node to join, or 412 about 30 minutes for 10-hop deep, 100-node network. This assumes 300 413 bytes for a certificate. 415 JS: in WHART, all frames sent to centralized manager to set up 416 tyransport session. Primary different is tha the number fo frame is 417 very small (1 frame up, 1 frame down) to get transport session 418 started. 420 JS: limitation is that you cannot cleanly separate joining flows from 421 steady-state flws in the netowkr. You can take device from box, 422 which will disrupt data traffic. In a typical HART network, amount 423 of BW for joining is really low. Limitation, no external validation 424 of the manager's ID, other than it posesses the right key. 426 3.1.6. Challenges with this method 428 number of messages 430 size of certificate exchanges 432 EAP and TLS code not used for anything else 434 ability to support non-PCE case 436 3.2. option 2: The WirelessHart/ISA100 way 438 This is an adaptation of the process described in [HART], section 439 6.6.3. 441 In this process, the new node joins using a well-known layer-2 "JOIN" 442 key. It brings up the layer-3, using 6loWPAN Neighbour Discovery to 443 learn of the 6lowpan contexts, and then uses RPL to join a well-known 444 DODAG as a leaf node. 446 Nodes which have capacity for new joining nodes will respond to the 447 RPL DIS messages. Once connected, the new node uses regular 448 unicasted IP datagrams to contact an Authorization Manager (in the 449 context of [I-D.gerdes-core-dcaf-authorize]). The negotiation with 450 the Authorization Manager (AM) uses the autonomic certificates as 451 described above to establish the trust relationship. 453 Once the relationship is up, the AM needs to signal the PCE that it 454 has a new authorized node, and the PCE can now (acting as a 455 [I-D.gerdes-core-dcaf-authorize] Client), get a Ticket to update the 456 node. 458 The PCE then writes both a new timeslot schedule, and also writes new 459 security parameters that permit the node to fully join the network. 461 Appropriate layer-2 keys are updated, as well as any appropriate 462 layer-3 RPL credentials. MLE may be used to establish pair-wise 463 keying, as appropriate to the timeslot schedule. 465 3.2.1. Advantages of this method 467 3.2.2. Challenges with the CoAP method 469 new protocol to initiate layer-2 471 potentially weaker resistance to layer-2 472 DoS 474 4. Security Considerations 476 5. Other Related Protocols 478 6. IANA Considerations 480 7. Acknowledgements 482 8. References 484 8.1. Normative references 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, March 1997. 489 [ZigBeeIP] 490 ZigBee Public Document 15-002r00, "ZigBee IP 491 Specification", 2013. 493 [RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for 494 Carrying Authentication for Network Access (PANA) 495 Attribute-Value Pairs", RFC 6786, November 2012. 497 [I-D.ietf-6tisch-architecture] 498 Thubert, P., Watteyne, T., and R. Assimiti, "An 499 Architecture for IPv6 over the TSCH mode of IEEE 500 802.15.4e", draft-ietf-6tisch-architecture-01 (work in 501 progress), February 2014. 503 [I-D.wang-6tisch-6top-sublayer] 504 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 505 Operation Sublayer (6top)", draft-wang-6tisch-6top- 506 sublayer-00 (work in progress), February 2014. 508 [I-D.ietf-roll-security-threats] 509 Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., 510 and M. Richardson, "A Security Threat Analysis for Routing 511 Protocol for Low-power and lossy networks (RPL)", draft- 512 ietf-roll-security-threats-06 (work in progress), December 513 2013. 515 [I-D.gerdes-core-dcaf-authorize] 516 Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP 517 Authentication and Authorization Framework (DCAF)", draft- 518 gerdes-core-dcaf-authorize-02 (work in progress), February 519 2014. 521 [I-D.pritikin-bootstrapping-keyinfrastructures] 522 Pritikin, M., Behringer, M., and S. Bjarnason, 523 "Bootstrapping Key Infrastructures", draft-pritikin- 524 bootstrapping-keyinfrastructures-00 (work in progress), 525 January 2014. 527 [I-D.irtf-nmrg-autonomic-network-definitions] 528 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 529 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 530 Networking - Definitions and Design Goals", draft-irtf- 531 nmrg-autonomic-network-definitions-00 (work in progress), 532 December 2013. 534 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, 535 a group of specifications for industrial process and 536 control devices administered by the HART Foundation", . 538 [ISA100.11a] 539 ISA, "ISA100, Wireless Systems for Automation", May 2008, 540 . 543 [IEEE.802.1AR] 544 Institute of Electrical and Electronics Engineers, "Secure 545 Device Identity", IEEE 802.1AR, 2009, 546 . 548 8.2. Informative references 550 [I-D.behringer-autonomic-network-framework] 551 Behringer, M., Pritikin, M., Bjarnason, S., and A. Clemm, 552 "A Framework for Autonomic Networking", draft-behringer- 553 autonomic-network-framework-01 (work in progress), October 554 2013. 556 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 557 Yegin, "Protocol for Carrying Authentication for Network 558 Access (PANA)", RFC 5191, May 2008. 560 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 561 Authentication Protocol (EAP) Key Management Framework", 562 RFC 5247, August 2008. 564 [RFC6869] Salgueiro, G., Clarke, J., and P. Saint-Andre, "vCard 565 KIND:device", RFC 6869, February 2013. 567 Author's Address 569 Michael C. Richardson 570 Sandelman Software Works 571 470 Dawson Avenue 572 Ottawa, ON K1Z 5V7 573 CA 575 Email: mcr+ietf@sandelman.ca 576 URI: http://www.sandelman.ca/