draft-ietf-rddp-security-01.txt   draft-ietf-rddp-security-02.txt 
Internet Draft James Pinkerton Internet Draft James Pinkerton
draft-ietf-rddp-security-01.txt Microsoft Corporation draft-ietf-rddp-security-02.txt Microsoft Corporation
Expires: September, 2004 Ellen Deleganes Expires: January, 2005 Ellen Deleganes
Intel Corporation Intel Corporation
Allyn Romanow
Cisco Systems
Sara Bitan Sara Bitan
Microsoft Corporation Microsoft Corporation
February 2004 July 2004
DDP/RDMAP Security DDP/RDMAP Security
1 Status of this Memo 1 Status of this Memo
This document is an Internet-Draft and is in full conformance This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line ? skipping to change at page 2, line ?
Memory Access Protocol (RDMAP). It first defines an architectural Memory Access Protocol (RDMAP). It first defines an architectural
model for an RDMA Network Interface Card (RNIC), which can model for an RDMA Network Interface Card (RNIC), which can
implement DDP or RDMAP and DDP. The document reviews various implement DDP or RDMAP and DDP. The document reviews various
attacks against the resources defined in the architectural model attacks against the resources defined in the architectural model
and the countermeasures that can be used to protect the system. and the countermeasures that can be used to protect the system.
Attacks are grouped into spoofing, tampering, information Attacks are grouped into spoofing, tampering, information
disclosure, denial of service, and elevation of privilege. disclosure, denial of service, and elevation of privilege.
Finally, the document concludes with a summary of security Finally, the document concludes with a summary of security
services for RDDP, such as IPSec. services for RDDP, such as IPSec.
J. Pinkerton, et al. Expires September 2004 1 J. Pinkerton, et al. Expires January 2005 1
Table of Contents Table of Contents
1 Status of this Memo.........................................1 1 Status of this Memo.........................................1
2 Abstract....................................................1 2 Abstract....................................................1
2.1 Issues......................................................3 2.1 Issues......................................................3
2.2 Revision History............................................4 2.2 Revision History............................................4
2.2.1 Changes from the -00 to -01 version........................4 2.2.1 Changes from the -01 to the -02 version....................4
2.2.2 Changes from the -00 to -01 version........................4
3 Introduction................................................6 3 Introduction................................................6
4 Architectural Model.........................................8 4 Architectural Model.........................................8
4.1 Components..................................................9 4.1 Components..................................................9
4.2 Resources..................................................11 4.2 Resources..................................................11
4.2.1 Stream Context Memory.....................................11 4.2.1 Stream Context Memory.....................................11
4.2.2 Data Buffers..............................................11 4.2.2 Data Buffers..............................................11
4.2.3 Page Translation Tables...................................11 4.2.3 Page Translation Tables...................................11
4.2.4 STag Namespace............................................12 4.2.4 STag Namespace............................................12
4.2.5 Completion Queues.........................................12 4.2.5 Completion Queues.........................................12
4.2.6 Asynchronous Event Queue..................................12 4.2.6 Asynchronous Event Queue..................................12
skipping to change at page 3, line 15 skipping to change at page 3, line 16
7.5 Denial of Service (DOS)....................................28 7.5 Denial of Service (DOS)....................................28
7.5.1 RNIC Resource Consumption.................................29 7.5.1 RNIC Resource Consumption.................................29
7.5.2 Resource Consumption By Active Applications...............30 7.5.2 Resource Consumption By Active Applications...............30
7.5.2.1 Multiple Streams Sharing Receive Buffers..............30 7.5.2.1 Multiple Streams Sharing Receive Buffers..............30
7.5.2.2 Local Peer Attacking a Shared CQ......................31 7.5.2.2 Local Peer Attacking a Shared CQ......................31
7.5.2.3 Remote Peer Attacking a Shared CQ.....................32 7.5.2.3 Remote Peer Attacking a Shared CQ.....................32
7.5.2.4 RDMA Read Request Queue...............................34 7.5.2.4 RDMA Read Request Queue...............................34
7.5.3 Resource Consumption by Idle Applications.................35 7.5.3 Resource Consumption by Idle Applications.................35
7.5.4 Exercise of non-optimal code paths........................35 7.5.4 Exercise of non-optimal code paths........................35
7.5.5 RI an STag Shared on Multiple Streams.....................36 7.5.5 RI an STag Shared on Multiple Streams.....................36
7.5.6 Remote Peer Consumes Untagged Receive Buffers.............36
7.6 Elevation of Privilege.....................................36 7.6 Elevation of Privilege.....................................36
8 Security Services for RDDP.................................38 8 Security Services for RDDP.................................37
8.1 Introduction to Security Options...........................38 8.1 Introduction to Security Options...........................37
8.1.1 Introduction to IPsec.....................................39 8.1.1 Introduction to IPsec.....................................38
8.1.2 Introduction to SSL Limitations on RDMAP..................40 8.1.2 Introduction to SSL Limitations on RDMAP..................39
8.1.3 Applications Which Provide Security.......................40 8.1.3 Applications Which Provide Security.......................39
8.2 Recommendations for IPsec Encapsulation of RDDP............40 8.2 Recommendations for IPsec Encapsulation of RDDP............39
8.2.1 Transforms................................................41 8.2.1 Transforms................................................40
8.2.2 IPsec modes...............................................41 8.2.2 IPsec modes...............................................40
8.2.3 IKE.......................................................41 8.2.3 IKE.......................................................40
8.2.4 Security Policy Configuration.............................43 8.2.4 Security Policy Configuration.............................42
9 Security considerations....................................45 9 Security considerations....................................44
10 References.................................................46 10 References.................................................45
10.1 Normative References......................................46 10.1 Normative References......................................45
10.2 Informative References....................................47 10.2 Informative References....................................46
11 Appendix A: Implementing Client/Server Protocols...........48 11 Appendix A: Implementing Client/Server Protocols...........47
12 Appendix B: Summary Table of Attacks.......................51 12 Appendix B: Summary Table of Attacks.......................50
12.1 Spoofing..................................................52 12.1 Spoofing..................................................51
12.2 Tampering.................................................52 12.2 Tampering.................................................51
12.3 Information Disclosure....................................52 12.3 Information Disclosure....................................51
12.4 Denial of Service.........................................52 12.4 Denial of Service.........................................51
13 Appendix C: Partial Trust Taxonomy.........................54 13 Appendix C: Partial Trust Taxonomy.........................53
14 AuthorĘs Addresses.........................................56 14 AuthorĘs Addresses.........................................55
15 Acknowledgments............................................57 15 Acknowledgments............................................56
16 Full Copyright Statement...................................58 16 Full Copyright Statement...................................57
Table of Figures Table of Figures
Figure 1 - RDMA Security Model....................................9 Figure 1 - RDMA Security Model....................................9
Figure 2 - Summary Attacks and Trust Model Table.................53 Figure 2 - Summary Attacks and Trust Model Table.................52
2.1 Issues 2.1 Issues
This section is temporary and will go away when all issues have This section is temporary and will go away when all issues have
been resolved. been resolved.
Note: this is far from a complete list of issues; as more are Note: this is far from a complete list of issues; as more are
raised, they will be added to this list until some sort of raised, they will be added to this list until some sort of
consensus is reached. They are in the order found in the consensus is reached. They are in the order found in the
specification. specification.
<TBD ū remove this section: this section was deleted because it Issue: The spec currently took the IPSec requirements for iSCSI
was a duplicate of Section 7.5.2.1 Multiple Streams Sharing and made them a SHOULD recommendation. A different approach would
Receive Buffers on page 30) Thus comments on this section were be to simply outline the issues in this section, but leave IPSec
added to that section.>..........................................36 implementation requirements to be specified by ULP/Application
Issue: The spec currently makes specific IPsec SHOULD requirements. The argument here is that RDDP is a transport, and
recommendations. Should this be relaxed to not be normative, security requirements ū particularly authentication and
since the protocol is just a transport protocol, not an confidentiality requirements, are dictated by application
application protocol?............................................38 concerns, not transport protocol concerns. Which approach should
be taken?........................................................37
Issue: Guidance for application protocols like NFS which Issue: Guidance for application protocols like NFS which
implement security <TBD>.........................................40 implement security <TBD>.........................................39
Issue: I think we should refer to IPS security considerations. Issue: I think we should refer to IPS security considerations.
Most of the issues discussed there are relevant for RDDP/RDMA as Most of the issues discussed there are relevant for RDDP/RDMA as
well (exceptions are the discussion on user certificates).<TBD>..45 well (exceptions are the discussion on user certificates).<TBD>..44
Issue: Finish Summary table of Attacks/Trust Models <TBD>........51 Issue: Finish Summary table of Attacks/Trust Models <TBD>........50
2.2 Revision History 2.2 Revision History
2.2.1 Changes from the -00 to -01 version 2.2.1 Changes from the -01 to the -02 version
Minimal ū some typos, deleted some text previously marked for
deletion.
2.2.2 Changes from the -00 to -01 version
* Added two pages to the architectural model to describe * Added two pages to the architectural model to describe
the Asynchronous Event Queue, and the types of the Asynchronous Event Queue, and the types of
interactions that can occur between the RNIC and the interactions that can occur between the RNIC and the
modules above it. modules above it.
* Addressed Mike Krauses comments submitted on 12/8/2003 * Addressed Mike Krauses comments submitted on 12/8/2003
* Moved "Trust Models" from the body of the document to an * Moved "Trust Models" from the body of the document to an
appendix. Removed references to it throughout the appendix. Removed references to it throughout the
skipping to change at page 17, line 37 skipping to change at page 17, line 37
attacks detailed in this specification. Note that for some attacks detailed in this specification. Note that for some
systems the Privileged Resource Manager may be implemented within systems the Privileged Resource Manager may be implemented within
the Privileged Application. the Privileged Application.
The sharing of resources across Streams should be under the The sharing of resources across Streams should be under the
control of the application, both in terms of the trust model the control of the application, both in terms of the trust model the
application wishes to operate under, as well as the level of application wishes to operate under, as well as the level of
resource sharing the application wishes to give Local Peer resource sharing the application wishes to give Local Peer
processes. For more discussion on types of trust models which processes. For more discussion on types of trust models which
combine partial trust and sharing of resources, see Appendix C: combine partial trust and sharing of resources, see Appendix C:
Partial Trust Taxonomy on page 54. Partial Trust Taxonomy on page 53.
6 Attacker Capabilities 6 Attacker Capabilities
An attackerĘs capabilities delimit the types of attacks that An attackerĘs capabilities delimit the types of attacks that
attacker is able to launch. RDMAP and DDP require that the attacker is able to launch. RDMAP and DDP require that the
initial LLP Stream (and connection) be set up prior to initial LLP Stream (and connection) be set up prior to
transferring RDMAP/DDP Messages. For the attacker to actively transferring RDMAP/DDP Messages. For the attacker to actively
generate an RDMAP/DDP protocol attack, it must have the generate an RDMAP/DDP protocol attack, it must have the
capability to both send and receive messages. Attackers with send capability to both send and receive messages. Attackers with send
only capabilities should be addressed by the LLP, not by only capabilities should be addressed by the LLP, not by
skipping to change at page 22, line 16 skipping to change at page 22, line 16
receive packets. Yet even with this limitation the Stream is receive packets. Yet even with this limitation the Stream is
still exposed to the following spoofing attacks. still exposed to the following spoofing attacks.
7.2.1 Impersonation 7.2.1 Impersonation
A network based attacker can impersonate a legal RDMA/RDDP peer A network based attacker can impersonate a legal RDMA/RDDP peer
(by spoofing a legal IP address), and establish an RDMA/RDDP (by spoofing a legal IP address), and establish an RDMA/RDDP
Stream with the victim. End to end authentication (i.e. IPsec, Stream with the victim. End to end authentication (i.e. IPsec,
SSL or ULP authentication) provides protection against this SSL or ULP authentication) provides protection against this
attack. For additional information see Section 8, Security attack. For additional information see Section 8, Security
Services for RDDP, on page 38. Services for RDDP, on page 37.
7.2.2 Stream Hijacking 7.2.2 Stream Hijacking
Stream Hijacking happens when a network based attacker follows Stream Hijacking happens when a network based attacker follows
the session establishment phase, and waits until the the session establishment phase, and waits until the
authentication phase (if such a phase exists) is completed authentication phase (if such a phase exists) is completed
successfully. He can then spoof the IP address and re-direct the successfully. He can then spoof the IP address and re-direct the
Stream from the victim to its own machine. For example, an Stream from the victim to its own machine. For example, an
attacker can wait until an iSCSI authentication is completed attacker can wait until an iSCSI authentication is completed
successfully, and hijack the iSCSI Stream. successfully, and hijack the iSCSI Stream.
The best protection against this form of attack is end-to-end The best protection against this form of attack is end-to-end
session level integrity protection and authentication, such as session level integrity protection and authentication, such as
IPsec (see Section 8, Security Services for RDDP, on page 38), to IPsec (see Section 8, Security Services for RDDP, on page 37), to
prevent spoofing. Another option is to provide physical security. prevent spoofing. Another option is to provide physical security.
Discussion of physical security is out of scope for this Discussion of physical security is out of scope for this
document. document.
Because the connection and/or Stream itself is established by the Because the connection and/or Stream itself is established by the
LLP, some LLPs are more difficult to hijack than others. Please LLP, some LLPs are more difficult to hijack than others. Please
see the relevant LLP documentation on security issues around see the relevant LLP documentation on security issues around
connection and/or Stream hijacking <TBD: references for SCTP and connection and/or Stream hijacking <TBD: references for SCTP and
TCP on connection hijacking>. TCP on connection hijacking>.
skipping to change at page 23, line 9 skipping to change at page 23, line 9
operation to read the contents of the associated data buffer, operation to read the contents of the associated data buffer,
perform an RDMA Write Operation to modify the contents of the perform an RDMA Write Operation to modify the contents of the
associated data buffer, or invalidate the STag to disable further associated data buffer, or invalidate the STag to disable further
access to the buffer. The only countermeasure for this form of access to the buffer. The only countermeasure for this form of
attack is to either secure the RDMAP/DDP Stream (i.e. integrity attack is to either secure the RDMAP/DDP Stream (i.e. integrity
protect) or attempt to provide physical security to prevent man- protect) or attempt to provide physical security to prevent man-
in-the-middle type attacks. in-the-middle type attacks.
The best protection against this form of attack is end-to-end The best protection against this form of attack is end-to-end
integrity protection and authentication, such as IPsec (see integrity protection and authentication, such as IPsec (see
Section 8 Security Services for RDDP on page 38), to prevent Section 8 Security Services for RDDP on page 37), to prevent
spoofing or tampering. If Stream or session level authentication spoofing or tampering. If Stream or session level authentication
and integrity protection are not used, then a man-in-the-middle and integrity protection are not used, then a man-in-the-middle
attack can occur, enabling spoofing and tampering. attack can occur, enabling spoofing and tampering.
Because the connection/Stream itself is established by the LLP, Because the connection/Stream itself is established by the LLP,
some LLPs are more exposed to man-in-the-middle attack then some LLPs are more exposed to man-in-the-middle attack then
others. Please see the relevant LLP documentation on security others. Please see the relevant LLP documentation on security
issues around connection and/or Stream hijacking <TBD: references issues around connection and/or Stream hijacking <TBD: references
for SCTP and TCP on connection hijacking>. for SCTP and TCP on connection hijacking>.
skipping to change at page 36, line 23 skipping to change at page 36, line 23
If the STag is valid across multiple Streams, then the Remote If the STag is valid across multiple Streams, then the Remote
Peer can prevent other Streams from using that STag by using the Peer can prevent other Streams from using that STag by using the
remote invalidate functionality. remote invalidate functionality.
Thus if RDDP Streams do not share Partial Mutual Trust (i.e. the Thus if RDDP Streams do not share Partial Mutual Trust (i.e. the
Remote Peer may attempt to invalidate the STag prematurely), it Remote Peer may attempt to invalidate the STag prematurely), it
is NOT RECOMMENDED that the application allow an STag to be valid is NOT RECOMMENDED that the application allow an STag to be valid
across multiple Streams. across multiple Streams.
7.5.6 Remote Peer Consumes Untagged Receive Buffers
<TBD ū remove this section: this section was deleted because it
was a duplicate of Section 7.5.2.1 Multiple Streams Sharing
Receive Buffers on page 30) Thus comments on this section were
added to that section.>
7.6 Elevation of Privilege 7.6 Elevation of Privilege
The RDMAP/DDP Security Architecture explicitly differentiates The RDMAP/DDP Security Architecture explicitly differentiates
between three levels of privilege - Non-Privileged, Privileged, between three levels of privilege - Non-Privileged, Privileged,
and the Privileged Resource Manager. If a Non-Privileged and the Privileged Resource Manager. If a Non-Privileged
Application is able to elevate its privilege level to a Application is able to elevate its privilege level to a
Privileged Application, then mapping a physical address list to Privileged Application, then mapping a physical address list to
an STag can provide local and remote access to any physical an STag can provide local and remote access to any physical
address location on the node. If a Privileged Mode Application is address location on the node. If a Privileged Mode Application is
able to promote itself to be a Resource Manager, then it is able to promote itself to be a Resource Manager, then it is
skipping to change at page 36, line 54 skipping to change at page 36, line 47
specific issue and thus outside the scope of this specification. specific issue and thus outside the scope of this specification.
There is one issue worth noting, however. If the RI There is one issue worth noting, however. If the RI
implementation, by some insecure mechanism (or implementation implementation, by some insecure mechanism (or implementation
defect), can enable a Remote Peer or un-trusted Local Peer to defect), can enable a Remote Peer or un-trusted Local Peer to
load firmware into the RNIC Engine, it is possible to use the load firmware into the RNIC Engine, it is possible to use the
RNIC to attack the host. Thus, it is RECOMMENDED that an RNIC to attack the host. Thus, it is RECOMMENDED that an
implementation not enable firmware to be loaded on the RNIC implementation not enable firmware to be loaded on the RNIC
Engine directly from a Remote Peer, unless the Remote Peer is Engine directly from a Remote Peer, unless the Remote Peer is
properly authenticated (by a mechanism outside the scope of this properly authenticated (by a mechanism outside the scope of this
specification), and the update is done via a secure protocol, specification. The mechanism presumably entails authenticating
such as IPsec (See Section 8 Security Services for RDDP on page that the remote application has the right to perform the update),
38). It is RECOMMENDED that an implementation not allow a Non- and the update is done via a secure protocol, such as IPsec (See
Privileged Local Peer to update firmware in the RNIC Engine. Section 8 Security Services for RDDP on page 37). It is
RECOMMENDED that an implementation not allow a Non-Privileged
Local Peer to update firmware in the RNIC Engine.
8 Security Services for RDDP 8 Security Services for RDDP
Issue: The spec currently took the IPSec requirements for iSCSI Issue: The spec currently took the IPSec requirements for iSCSI
and made them a SHOULD recommendation. A different approach would and made them a SHOULD recommendation. A different approach would
be to simply outline the issues in this section, but leave IPSec be to simply outline the issues in this section, but leave IPSec
implementation requirements to be specified by ULP/Application implementation requirements to be specified by ULP/Application
requirements. The argument here is that RDDP is a transport, and requirements. The argument here is that RDDP is a transport, and
security requirements ū particularly authentication and security requirements ū particularly authentication and
confidentiality requirements, are dictated by application confidentiality requirements, are dictated by application
skipping to change at page 53, line 8 skipping to change at page 52, line 8
+--------+---------------------------------------------+-----+--+--+ +--------+---------------------------------------------+-----+--+--+
12.4 Denial of Service 12.4 Denial of Service
+--------+---------------------------------------------+-----+--+--+ +--------+---------------------------------------------+-----+--+--+
| 7.5.1 | RNIC Resource Consumption | | 7.5.1 | RNIC Resource Consumption |
+--------+---------------------------------------------+-----+--+--+ +--------+---------------------------------------------+-----+--+--+
| 7.5.2.1| Multiple Streams Sharing Receive Buffers | | 7.5.2.1| Multiple Streams Sharing Receive Buffers |
+--------+---------------------------------------------+-----+--+--+ +--------+---------------------------------------------+-----+--+--+
| 7.5.2.2| Local Peer Attacking a Shared CQ |Error! | 7.5.2.2| Local Peer Attacking a Shared CQ |
Reference source not found.
+--------+---------------------------------------------+-----+--+--+ +--------+---------------------------------------------+-----+--+--+
| 7.5.2.3| Remote Peer Attacking a Shared CQ | | 7.5.2.3| Remote Peer Attacking a Shared CQ |
+--------+---------------------------------------------+-----+--+--+ +--------+---------------------------------------------+-----+--+--+
| 7.5.2.4| RDMA Read Request Queue | | 7.5.2.4| RDMA Read Request Queue |
+--------+---------------------------------------------+-----+--+--+ +--------+---------------------------------------------+-----+--+--+
| 7.5.3 | Resource Consumption by Idle Applications | | 7.5.3 | Resource Consumption by Idle Applications |
+--------+---------------------------------------------+-----+--+--+ +--------+---------------------------------------------+-----+--+--+
| 7.5.4 | Exercise of non-optimal code paths | | 7.5.4 | Exercise of non-optimal code paths |
+--------+---------------------------------------------+-----+--+--+ +--------+---------------------------------------------+-----+--+--+
| 7.5.5 | RI an STag Shared on Multiple Streams | | 7.5.5 | RI an STag Shared on Multiple Streams |
+--------+---------------------------------------------+-----+--+--+ +--------+---------------------------------------------+-----+--+--+
| 7.5.6 | Remote Peer Consumes Untagged Receive Buffers|
+--------+---------------------------------------------+-----+--+--+
Figure 2 - Summary Attacks and Trust Model Table Figure 2 - Summary Attacks and Trust Model Table
13 Appendix C: Partial Trust Taxonomy 13 Appendix C: Partial Trust Taxonomy
Partial Trust is defined as when one party is willing to assume Partial Trust is defined as when one party is willing to assume
that another party will refrain from a specific attack or set of that another party will refrain from a specific attack or set of
attacks, the parties are said to be in a state of Partial Trust. attacks, the parties are said to be in a state of Partial Trust.
Note that the partially trusted peer may attempt a different set Note that the partially trusted peer may attempt a different set
of attacks. This may be appropriate for many applications where of attacks. This may be appropriate for many applications where
skipping to change at page 55, line 6 skipping to change at page 54, line 6
the safest mode possible. All attack mitigations are in place the safest mode possible. All attack mitigations are in place
to ensure robust operation. to ensure robust operation.
2. NS-RT - Non-Shared Local Resources, no Local Trust, Remote 2. NS-RT - Non-Shared Local Resources, no Local Trust, Remote
Partial Trust - typically a peer-to-peer application, which Partial Trust - typically a peer-to-peer application, which
has, by some method outside of the scope of this has, by some method outside of the scope of this
specification, authenticated the Remote Peer. Note that specification, authenticated the Remote Peer. Note that
unless some form of key based authentication is used on a per unless some form of key based authentication is used on a per
RDMA/DDP session basis, it may not be possible be possible RDMA/DDP session basis, it may not be possible be possible
for man-in-the-middle attacks to occur. See section 8, for man-in-the-middle attacks to occur. See section 8,
Security Services for RDDP on page 38. Security Services for RDDP on page 37.
3. S-NT - Shared Local Resources, no Local Trust, no Remote 3. S-NT - Shared Local Resources, no Local Trust, no Remote
Trust - typically a server application that runs in an Trust - typically a server application that runs in an
untrusted environment where the amount of resources required untrusted environment where the amount of resources required
is either too large or too dynamic to dedicate for each is either too large or too dynamic to dedicate for each
RDMAP/DDP Stream. RDMAP/DDP Stream.
4. S-LT - Shared Local Resources, Local Partial Trust, no Remote 4. S-LT - Shared Local Resources, Local Partial Trust, no Remote
Trust - typically an application, which provides a session Trust - typically an application, which provides a session
layer and uses multiple Streams, to provide additional layer and uses multiple Streams, to provide additional
skipping to change at page 56, line 8 skipping to change at page 55, line 8
advantageous. Model S-T is typically used when resource scaling advantageous. Model S-T is typically used when resource scaling
across a large parallel application makes it infeasible to use across a large parallel application makes it infeasible to use
any other model. Resource scaling issues can either be due to any other model. Resource scaling issues can either be due to
performance around scaling or because there simply are not enough performance around scaling or because there simply are not enough
resources. Model NS-RT is probably the least likely model to be resources. Model NS-RT is probably the least likely model to be
used, but is presented for completeness. used, but is presented for completeness.
14 AuthorĘs Addresses 14 AuthorĘs Addresses
James Pinkerton James Pinkerton
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA. 98052 USA Redmond, WA. 98052 USA
Phone: +1 (425) 705-5442 Phone: +1 (425) 705-5442
Email: jpink@windows.microsoft.com Email: jpink@windows.microsoft.com
Ellen Deleganes Ellen Deleganes
Intel Corporation Intel Corporation
MS JF5-355 MS JF5-355
2111 NE 25th Ave. 2111 NE 25th Ave.
Hillsboro, OR 97124 USA Hillsboro, OR 97124 USA
Phone: +1 (503) 712-4173 Phone: +1 (503) 712-4173
Email: ellen.m.deleganes@intel.com Email: ellen.m.deleganes@intel.com
Sara Bitan
Microsoft Corporation
Email: sarab@microsoft.com
15 Acknowledgments
Allyn Romanow Allyn Romanow
Cisco Systems Cisco Systems
170 W Tasman Drive 170 W Tasman Drive
San Jose, CA 95134 USA San Jose, CA 95134 USA
Phone: +1 408 525 8836 Phone: +1 408 525 8836
Email: allyn@cisco.com Email: allyn@cisco.com
Sara Bitan
Microsoft Corporation
Email: sarab@microsoft.com
15 Acknowledgments
Catherine Meadows Catherine Meadows
Naval Research Laboratory Naval Research Laboratory
Code 5543 Code 5543
Washington, DC 20375 Washington, DC 20375
Email: meadows@itd.nrl.navy.mil Email: meadows@itd.nrl.navy.mil
Patricia Thaler Patricia Thaler
Agilent Technologies, Inc. Agilent Technologies, Inc.
1101 Creekside Ridge Drive, #100 1101 Creekside Ridge Drive, #100
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/