idnits 2.17.00 (12 Aug 2021) /tmp/idnits60934/draft-jjmb-dhc-eap-auth-analysis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (February 4, 2010) is 4482 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-pruss-dhcp-auth-dsl-06 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc J. Brzozowski 3 Internet-Draft Comcast Cable Communications 4 Intended status: Informational T. Lemon 5 Expires: August 8, 2010 Nominum 6 G. Hollan 7 Telus 8 February 4, 2010 10 DHCP Authentication Analysis 11 draft-jjmb-dhc-eap-auth-analysis-02 13 Abstract 15 This document analyzes and technically evaluates a proposal by Ric 16 Pruss, et al., to implement end-user EAP-based authentication as a 17 part of a DHCP protocol transaction in DSL networks. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 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 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 8, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Message and Option Definition . . . . . . . . . . . . . . . . 3 63 3.1. Message Type Overloading . . . . . . . . . . . . . . . . . 3 64 3.2. Differences in Message and Option Names . . . . . . . . . 4 65 3.3. Message and Option Sizing . . . . . . . . . . . . . . . . 4 66 3.4. RADIUS Message Requirements . . . . . . . . . . . . . . . 4 67 4. Protocol behavior . . . . . . . . . . . . . . . . . . . . . . 4 68 4.1. DHCP Clients . . . . . . . . . . . . . . . . . . . . . . . 4 69 4.1.1. Packet Size . . . . . . . . . . . . . . . . . . . . . 4 70 4.1.2. Standalone Client Behavior . . . . . . . . . . . . . . 5 71 4.1.3. Handling of non-EAP responses . . . . . . . . . . . . 5 72 4.1.4. Protocol State Machine is Only in Client . . . . . . . 5 73 4.1.5. Transaction IDs . . . . . . . . . . . . . . . . . . . 6 74 4.1.6. EAP Protocol Direction . . . . . . . . . . . . . . . . 6 75 4.1.7. Reliable Delivery of EAP messages . . . . . . . . . . 7 76 4.1.8. Re-Authentication . . . . . . . . . . . . . . . . . . 7 77 4.1.9. Authorization lifetime versus lease time . . . . . . . 7 78 4.2. DHCP Servers . . . . . . . . . . . . . . . . . . . . . . . 7 79 4.3. DHCP Relay Agents . . . . . . . . . . . . . . . . . . . . 8 80 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 8 81 6. Dual-Stack issues . . . . . . . . . . . . . . . . . . . . . . 9 82 7. Appropriateness . . . . . . . . . . . . . . . . . . . . . . . 9 83 7.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 9 84 7.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 10 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 89 11.1. Normative References . . . . . . . . . . . . . . . . . . . 11 90 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 93 1. Introduction 95 This document provides an independent analysis of the proposal to 96 support end-user authentication using extension to DHCP. While the 97 current proposal largley focuses on Broadband Digital Subscriber Line 98 scenarions the adhoc team that has been assembled will evaulate the 99 proposal generally from a DHCP point of view. This analysis will 100 also cite architectural and best practice considerations for the 101 authors to consider as part of this work. 103 1.1. Requirements Language 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 2. Terminology 111 The following terms and acronyms are used in this document: 113 o DHCPv4 - "Dynamic Host Configuration Protocol" [RFC2131][RFC2132] 115 o DHCPv6 - "Dynamic Host Configuration Protocol for IPv6" [RFC3315] 117 o DHCP - DHCPv4 and/or DHCPv6 119 3. Message and Option Definition 121 In this section considerations pertaining to how the DHCPEAP messages 122 have been defined in [I-D.pruss-dhcp-auth-dsl] are discussed. 123 Recommendations as to how messages may be defined are also documented 124 in this section. 126 3.1. Message Type Overloading 128 [I-D.pruss-dhcp-auth-dsl] defines a DHCP single EAP message to 129 support end-user DHCP-based authentication. However, the DHC working 130 group has found that using the same DHCP message type for more than 131 one leg of a packet exchange creates confusion, and we recommend 132 instead that a different message type be used for each leg of the 133 transaction. In this case a four message model may better satisfy 134 the requirements, similar, for example, to the DISCOVER/OFFER/ 135 REQUEST/ACK cycle in the standard DHCPv4 bootstrapping exchange. 137 3.2. Differences in Message and Option Names 139 [I-D.pruss-dhcp-auth-dsl] mingles DHCPv4 and DHCPv6 message types. 140 This is not valid. DHCPv4 messages and options must be clearly 141 defined and referenced to for IPv4. DHCPv6 messages and options must 142 be defined and referenced for IPv6. 144 3.3. Message and Option Sizing 146 [I-D.pruss-dhcp-auth-dsl] introduces a DHCP Capability Vendor- 147 specific Suboption for DHCPv4 and DHCPv6 which is specified to carry 148 authentication information. This information is required to support 149 the desired protocol behavior. However, including this data in a 150 DHCP greatly increases the size of the DHCP option payload. While 151 [I-D.pruss-dhcp-auth-dsl] specifies how large options are to be 152 handled, this large option payload still has the potential to create 153 problems; there is the potential for this option to squeeze out other 154 DHCP options required for correct DHCP configuration 156 Additionally, the authors of [I-D.pruss-dhcp-auth-dsl] should mention 157 that in practice the Maximum Message Size option is rarely used by 158 DHCP clients and as such we have no real operational experience that 159 tells us what percentage of relay agents will fail in the face of 160 DHCP packets larger than 576 bytes. 162 3.4. RADIUS Message Requirements 164 Section 5.1 and 5.2 of [I-D.pruss-dhcp-auth-dsl] mention RADIUS 165 attributes required to support this behavior. These are not included 166 as part of [RFC4014]. These messages still need to be specified. 168 4. Protocol behavior 170 [I-D.pruss-dhcp-auth-dsl] requires that end-user DHCP-based 171 authentication must be handled independently in the case where both 172 IPv4 and IPv6 service are present. [I-D.pruss-dhcp-auth-dsl] is not 173 clear as to how clients and servers handle conflicts where both IPv4 174 and IPv6 are used simultaneously and further how conflicts are 175 resolved when such scenarios arise. See the beginning of section 5 176 of [I-D.pruss-dhcp-auth-dsl]. 178 4.1. DHCP Clients 180 4.1.1. Packet Size 182 Packet size for DHCP clients that support end-user DHCP-based 183 authentication remains a concern. DHCP clients MUST advertise their 184 ability to support larger packet sizes, however, this alone will not 185 ensure that intermediate elements like DHCP relay agents will support 186 the same or adversely impact exchanges between DHCP clients and 187 servers. DHCP clients in this case include but are not limited to 188 those include with operating systems and home networking equipment. 190 4.1.2. Standalone Client Behavior 192 The behavior for home gateway (HG) as defined in 193 [I-D.pruss-dhcp-auth-dsl] has been specified, however, specification 194 of standalone client behavior remains absent. In order for this 195 proposal to be complete it must be specified how standalone client 196 are to behave to support end-user authentication using DHCP. 198 4.1.3. Handling of non-EAP responses 200 Section 5 of [I-D.pruss-dhcp-auth-dsl] also indicates that a client 201 may receive one or more DHCP OFFER/ADVERTISE messages some of which 202 may or may not support DHCP EAP authentication. It is unclear and 203 unspecified how or if the client is to wait for DHCPEAP messages if 204 it has already received a DHCPOFFER or DHCP Advertise message. An 205 EAP-capable client could accept a DHCPOFFER or DHCP Advertise message 206 and consequently miss a subsequent DHCPEAP message, which would 207 prevent it from authenticating. 209 This is further complicated in the case where the DHCP client is not 210 a home gateway, and may in fact be a portable device such as a laptop 211 computer. When the DHCP/EAP capable client is connected to a 212 provider network supporting DHCP/EAP, the client may wait for a 213 DHCPEAP message from the server. When the client is connected to 214 some other network, where DHCP/EAP is not supported, it may still 215 wait for such a message. This would create a delay in the 216 availability of the network for the end user when not connecting to 217 the provider network. 219 4.1.4. Protocol State Machine is Only in Client 221 [I-D.pruss-dhcp-auth-dsl] proposes that if the relay agent or server 222 decides to do DHCP/EAP, the original DHCPDISCOVER message from the 223 DHCP client will be cached. Once the EAP authentication has 224 succeeded, the DHCPDISCOVER will be forwarded to the server or, in 225 the case where the server does the EAP authentication, the server 226 will take the cached DHCPDISCOVER and send a DHCPOFFER in response to 227 it. 229 However, this proposal ignores the fact that the DHCP client, not the 230 DHCP server, drives the DHCP protocol. The DHCP client determines 231 when to send the DHCPDISCOVER, and the DHCP server responds. The 232 DHCP client determines when to send the DHCPREQUEST, and the DHCP 233 server responds. The DHCP client determines when to renew, and so 234 on. 236 Hence, we strongly recommend that the proposed protocol be changed so 237 that, after a successful DHCP/EAP exchange, the DHCP client restarts 238 its state machine at the INIT state and sends a new DHCPDISCOVER, 239 with a new transaction ID. This eliminates three problems: 241 - the need for the DHCP server or relay to cache the DHCPDISCOVER 243 - the problem of how to retransmit if the DHCP server doesn't send 244 a response to the DHCPDISCOVER cached and eventually forwarded by 245 the relay agent 247 - the problem that the DHCP client state machine would have to 248 remember the xid in the original DHCPDISCOVER packet, even though 249 it's gone through several state transitions since the DHCPDISCOVER 250 was sent. 252 Needless to say, the same suggestion applies for the DHCPv6 protocol, 253 although the names of the packets are different and DHCPv6 doesn't 254 name the client's states. 256 4.1.5. Transaction IDs 258 The proposed protocol extension does not document the handling of the 259 DHCP client's transaction IDs during the processing of EAP-specific 260 messages. We recommend that each EAP message sourced by the client 261 have a new transaction ID, which should then be returned in the 262 response from the server. 264 4.1.6. EAP Protocol Direction 266 The proposed protocol extension attempts to replace PPPoE/EAP with a 267 new protocol based on DHCP. However, the DHCP protocol is client- 268 initiated, whereas EAP is server-initiated. For example, consider 269 PPP Extensible Authentication Protocol [RFC3748]. In this document, 270 the authenticator initiates the packet exchange after the layer two 271 (PPPoE) connection is established. 273 The proposal does not explain how this incompatibility is resolved. 274 Either the proposal needs to turn the DHCP client state machine on 275 its head, or it needs to turn the EAP state machine on its head. The 276 document proposes neither solution, so we can't evaluate the impact 277 the solution to this problem would have on the DHCP protocol. 279 4.1.7. Reliable Delivery of EAP messages 281 The proposal doesn't talk about retransmission for DHCPEAP messages. 282 This is a particularly important omission because of the reversal of 283 roles implicit in doing DHCP over EAP, as discussed in the previous 284 section, "EAP Protocol Direction." Since DHCP is a UDP-based 285 protocol with no guaranteed delivery, retransmission is not optional, 286 and the way in which the DHCP client or EAP authenticator does 287 retransmission must be specified explicitly, or this proposal does 288 not in any way guarantee interoperability. 290 4.1.8. Re-Authentication 292 The proposal doesn't cover re-authentication. Although section 2, 293 "Problem Statement," mentions user authentication and connection 294 liveness probing, the actual protocol document never proposes a 295 method whereby this requirement is satisfied. 297 We theorize that it might be possible to somehow accomplish this 298 using DHCPFORCERENEW in DHCPv4 and DHCP Reconfigure in DHCPv6, but 299 nowhere in the document is this solution discussed. So again, there 300 is no way to evaluate how the solution to this problem would interact 301 with DHCP. 303 4.1.9. Authorization lifetime versus lease time 305 The underlying authentication protocol may assign a lifetime to the 306 authorization, after which time the authorization must be renewed. 307 DHCP clients also have a lease interval, which might be different 308 than the authorization interval. The proposal should specify that 309 the lease must expire before the authorization expires, in cases 310 where the authorization expires. The proposal should also cover re- 311 authentication, so that a new authorization with a new expiration is 312 acquired each time the lease is renewed. 314 4.2. DHCP Servers 316 In the DHCP protocol, the state machine is in the client, not the 317 server. The server retains information about the client's IP address 318 allocation, but from the perspective of the protocol, the DHCP server 319 only sends messages in response to messages sent by the DHCP client. 320 So [I-D.pruss-dhcp-auth-dsl] places a new requirement on DHCP servers 321 that they retain DHCPDISCOVER messages sent by clients during the EAP 322 authentication process. This problem would be solved by following 323 the related recommendations in the earlier section on DHCP clients. 325 4.3. DHCP Relay Agents 327 [I-D.pruss-dhcp-auth-dsl] does not say whether or not the relay agent 328 should append a relay agent information option to EAP-specific 329 messages. We think that a non-EAP-aware relay agent would have to do 330 so, but the draft should talk about this issue. 332 [I-D.pruss-dhcp-auth-dsl] proposes a mode in which the DHCP relay 333 agent implements the EAP protocol itself, rather than relying on the 334 DHCP server to do so. In order to do this, the relay agent, which in 335 the normal DHCP protocol is completely stateless, must now retain 336 state regarding the progress of the DHCP protocol. There are two 337 different ways in which this protocol extension adds state to the 338 relay agent: 340 - The relay agent must retain the initial DHCPDISCOVER packet sent 341 by the client. 343 - Once the EAP authentication has succeeded, the relay agent must 344 remember that the authentication has succeeded, so that if the 345 DHCP client must retransmit its DHCPDISCOVER, the relay agent does 346 not attempt to redo the entire EAP authentication process. This 347 state must be retained for the entire duration of the DHCP 348 protocol from that point on, so that the initial four-way 349 handshake can complete, and so that any subsequent renewals, 350 rebinds, and INIT-REBOOT renewals can complete. In order to avoid 351 caching this state forever, the relay agent would have to retain 352 lease timing information so that it could time out cached 353 information as the leases associated with that information expire. 355 For this reason, we strongly recommend that the authors abandon the 356 idea of implementing this protocol extension in the relay agent. 357 Also, please note that this is true for the DHCPv6 exchange as well 358 as the DHCPv4 exchange; we only document the DHCPv4 exchange for 359 brevity. 361 5. Compatibility 363 The compatibility of clients, servers, and relay agents that 364 implement this behavior with legacy clients, servers, and relay 365 agents MUST be explicitly documented. The behavior of the remaining 366 elements that do not support this behavior while others do MUST be 367 considered, specifically, how will legacy element handle the presence 368 of the corresponding DHCP options when present. Consider the 369 following scenarios for example: 371 1. DHCP client support for authentication 373 2. DHCP relay agent support for authentication 375 3. DHCP server support for authentication 377 4. DHCP client, server, and relay agent support for authentication 379 6. Dual-Stack issues 381 The proposed DHCP extension performs authentication in a way that is 382 linked with the DHCP transaction. The legacy authentication protocol 383 may only support a single authentication per connection. In a dual- 384 stack environment, both the DHCPv4 and DHCPv6 clients might attempt 385 to authenticate. The underlying authentication protocol might then 386 succeed for DHCPv4 and fail for DHCPv6, or vice versa. 388 The proposal should account for this issue, either specifying that in 389 a dual-stack situation, one or the other DHCP clients should do the 390 authentication, or specifying that this protocol does not work in a 391 dual-stack environment, or specifying how the underlying EAP 392 authentication works in the presence of parallel authentications. 394 7. Appropriateness 396 The proposed DHCP extension embeds the network authentication process 397 into the network configuration process, which, it could be argued, 398 goes against the recommendation inPrinciples of Internet Host 399 Configuration [RFC5505], which states: 401 Network access authentication and authorization is a distinct 402 problem from Internet host configuration. Therefore, network 403 access authentication and authorization is best handled 404 independently of the Internet and higher-layer configuration 405 mechanisms. 407 There are two aspects to this objection. The first is that of course 408 there are reasons why strict adherence to this provision of RFC5505 409 was not followed. Second, does this provision actually apply? 411 7.1. Motivation 413 To address the first point, the motivation stated by the authors for 414 embedding an authentication protocol into a configuration protocol is 415 essentially economic: it allows ISPs implementing the protocol to 416 continue using network infrastructure they have already deployed and 417 paid for, while providing a substantial benefit by allowing them to 418 move away from using PPPoE as, essentially, a gatekeeper protocol and 419 toward running native (non-tunneled) IP. 421 A second motivation is that existing protocols for authenticating at 422 layer two aren't applicable to the DSL environment - 802.1x, for 423 instance, can't work, because the device doing the authentication has 424 no connectivity to the node being authenticated until layer three 425 (IP) configuration has occurred. And yet authentication is required 426 before decisions can be made as to how to configure the client. The 427 DHCPv4 and DHCPv6 protocols provide a mechanism for doing the 428 authentication despite the lack of a layer three configuration. 430 7.2. Applicability 432 As to the question of applicability of the statement in question, it 433 is not really the case that configuration and authentication are 434 being done by the same protocol. Configuration is being done by 435 DHCP. Authentication is being done by EAP. True, DHCP is being used 436 as a transport for the EAP protocol, but it is not the case that DHCP 437 itself is being used for authentication and authorization. 439 In addition, existing network access authentication protocols that 440 work over layer three do use DHCP to configure the node prior to 441 authentication in cases, such as this, where the authentication agent 442 is not available on the local link. 444 Once the node is configured, in order to get new DHCP configuration 445 information based on the authentication and authorization results, a 446 second DHCP transaction must be done. In order for this to work, 447 essentially the same mechanisms being proposed in Authentication 448 Extensions for the Dynamic Host Configuration Protocol 449 [I-D.pruss-dhcp-auth-dsl] are needed - the DHCP server or DHCP relay 450 agent must have access to the results of the authentication. And the 451 DHCP protocol itself provides no mechanism for reconfiguring 452 subsequent to a successful layer three authentication. Hence the 453 difference between such a protocol and the one being proposed is 454 minor, and largely serves to make the configuration/authentication 455 process slower and more awkward. 457 8. Acknowledgements 459 Thanks to Alper Yegin, Ric Pruss, Glen Zorn, Alan DeKok, Yoshihiro 460 Ohba, Miles David, Alan Kavanaugh, Steinar Haug and Alfred Hoenes for 461 the review and feedback. 463 9. IANA Considerations 465 This memo includes no request to IANA. 467 10. Security Considerations 469 The current version of [I-D.pruss-dhcp-auth-dsl] indicates that 470 [RFC3118] likely cannot be seamlessly integrated with existing 471 RADIUS-based AAA infrastructure used in Broadband DSL environments. 472 [I-D.pruss-dhcp-auth-dsl] must elaborate on how DHCP EAP can be 473 secured if not by leveraging [RFC3118]. While the use cases for that 474 extension are hard to evaluate, so it seems that this draft is 475 neutral toward other DHCP security mechanisms, with one small caveat: 476 since it increases the DHCP message size, it is competing for space 477 in the DHCP packet with other authentication options. However, 478 existing [RFC3118] authentication schemes use relatively short 479 signatures and keys, so in practice this is probably not a serious 480 concern. 482 11. References 484 11.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 11.2. Informative References 491 [I-D.pruss-dhcp-auth-dsl] 492 Pruss, R. and G. Zorn, "EAP Authentication Extensions for 493 the Dynamic Host Configuration Protocol for Broadband", 494 draft-pruss-dhcp-auth-dsl-06 (work in progress), 495 June 2009. 497 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 498 RFC 2131, March 1997. 500 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 501 Extensions", RFC 2132, March 1997. 503 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 504 Messages", RFC 3118, June 2001. 506 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 507 and M. Carney, "Dynamic Host Configuration Protocol for 508 IPv6 (DHCPv6)", RFC 3315, July 2003. 510 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 511 Levkowetz, "Extensible Authentication Protocol (EAP)", 512 RFC 3748, June 2004. 514 [RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication 515 Dial-In User Service (RADIUS) Attributes Suboption for the 516 Dynamic Host Configuration Protocol (DHCP) Relay Agent 517 Information Option", RFC 4014, February 2005. 519 [RFC5505] Aboba, B., Thaler, D., Andersson, L., and S. Cheshire, 520 "Principles of Internet Host Configuration", RFC 5505, 521 May 2009. 523 Authors' Addresses 525 John Jason Brzozowski 526 Comcast Cable Communications 527 1360 Goshen Parkway 528 West Chester, PA 19473 529 USA 531 Phone: +1-609-377-6594 532 Email: john_brzozowski@cable.comcast.com 534 Ted Lemon 535 Nominum 536 USA 538 Phone: 539 Email: mellon@nominum.com 541 Geoffrey Holan 542 Telus 543 Canada 545 Phone: 546 Email: geoffrey.holan@telus.com