Subject: Re: Re: Another draft: EAP over IP

From: Paal Engelstad <[email-masked]>
Date: Sat, 5 Jan 2002 6:28:32 +0100

Carl,

> Paal,
> 
>    Have you reviewed over the SNAARD draft.

Nope. I tried to locate it, but could not find it. 

>    SNAARD (via RAs) can be used as a carrier for
>    EAP as well.....

Sounds interesting! Generally I think that the actual carrier is not the main issue at this point in time:

To save energy we should first focus on how existing protocols (e.g. EAP, IKE, IPSec, DIAMETER, DHCP and DHCP-relays, ND, X.509, MIDCOM-in-some-years-to-come, etc..) may interact together for both IPv4 and IPv6 - taking both firewalls and NATs into consideration - to meet (the still vague concept of) our most important requirements. 

Most of these protocols will naturally be out of scope as work items for this WG, but we may take advantage of their existing functionalities.

I think the actual carrier (TCP, UDP, SCTP, ICMP, higher layer protocols, etc...) will come out as a result of more principal design choices.

Paal

> 
>  Carl
> 
> 
> ----- Original Message -----
> From: "Paal Engelstad" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Friday, January 04, 2002 7:38 PM
> Subject: Another draft: EAP over IP
> 
> 
> > > Hi all,
> >
> > Hi George - and others,
> >
> > FYI: I also did some analyses that resulted in a draft that I submitted
> after the SLC meeting. The I-D administrator has returned to office and
> promised to announce it January 4th, but I have not seen it. Since I hope
> for some comment before I soon leave for a weeks vacation, I allow myself to
> attach my draft in this e-mail.  Others not interested: Please excuse me for
> filling your mail-boxes.
> >
> > George: I had a little difficulty with reading your draft in the format I
> got it, but I will soon return with some comments based on what I understood
> of it.
> >
> > I do not intend to push the discussion on the list too much into
> solution-space. On the contrary, I hope my draft may trigger some
> discussions regarding basic principles that might be useful for the
> requirements-team.
> >
> > Please take a look at the attached EAP-over-IP draft. Comments are
> welcome. Thanks.
> >
> > Paal
> >
> >
> 
> 
> ----------------------------------------------------------------------------
> ----
> 
> 
> >
> >
> > Internet Draft                                       P. Engelstad
> >                                                       Telenor R&D
> > Expires: June 2002                                  December 2001
> >
> >           Extensible Authentication Protocol over IP (EAPoIP)
> >
> >                <draft-engelstad-pana-eap-over-ip-00.txt>
> >
> >
> > Status of this Memo
> >
> >    This document is an Internet-Draft and is in full conformance with
> >    all provisions of Section 10 of RFC2026.
> >
> >    This document is an Internet-Draft. Internet-Drafts are working
> >    documents of the Internet Engineering Task Force (IETF), its areas,
> >    and its working groups. Note that other groups may also distribute
> >    working documents as Internet-Drafts.
> >
> >    Internet-Drafts are draft documents valid for a maximum of six
> >    months and may be updated, replaced, or obsoleted by other documents
> >    at any time. It is inappropriate to use Internet- Drafts as
> >    reference material or to cite them other than as "work in progress."
> >
> >    The list of current Internet-Drafts can be accessed at
> >    http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
> >    Draft Shadow Directories can be accessed at
> >    http://www.ietf.org/shadow.html.
> >
> >    This document is an individual submission for the PANA Working Group
> >    of the Internet Engineering Task Force (IETF). Comments should be
> >    submitted to the mailing list [email-masked].
> >
> > Copyright Notice
> >
> >    Copyright (C) The Internet Society.  All Rights Reserved.
> >
> > Abstract
> >
> >    This document defines the Extensible Authentication Protocol over IP
> >    (EAPoIP), which basically is a variation of the Extensible
> >    Authentication Protocol (EAP). Unlike EAP, it runs over IP. EAPoIP
> >    is intended primarily for authentication of hosts in an access
> >    domain. EAPoIP assumes that the host has established a link-layer
> >    connection to an access router and has configured a valid IPv4 or
> >    IPv6 address for itself on the subnet by DHCP, by address auto-
> >    configuration, or by other means. Dynamically configurable firewalls
> >    may be used to shield unauthenticated and unauthorized hosts on the
> >    access subnets from resources in the inner parts of the access
> >    domain. A PANA Authentication Agent (PAA), which is an
> >    Authentication Server located somewhere in the access domain,
> >    authenticates the host. The host may also authenticate the PAA.
> >
> >
> > P. Engelstad              Expires June 2002                  [Page 1]
> >                              EAP over IP                December 2001
> > Table of Contents
> >
> >    1. Introduction.................................................  2
> >       1.1 Specification of Requirements
> >       1.2 Terminology
> >    2. EAPoIP Overview .............................................  4
> >    3. Extensions for EAPoIP Service Discovery .....................  5
> >       3.1 ICMPv4 Router Advertisement Extension
> >       3.2 DHCPv4 Extension
> >       3.3 ICMPv6 Router Advertisement Option
> >       3.4 DHCPv6 Option
> >       3.5 Sub-options for EAPoIP Service Discovery
> >            3.5.1 PAA IPv4 Address Sub-option
> >            3.5.2 PAA IPv6 Address Sub-option
> >            3.5.3 PAA Identity Sub-option
> >            3.5.4 Other Sub-options
> >    4. EAPoIP Packet and Message Formats (Post-IKE) ................  9
> >       4.1 EAPoIP Transport Protocols
> >       4.2 EAPoIP uses IKE and IPSec
> >       4.3 EAPoIP message format
> >    5. Initial EAPoIP Request/Response Types ....................... 12
> >       5.1 Supported EAP-Types
> >    6. Post-IKE EAPoIP Message Formats and Contents ................ 13
> >    Security Considerations ........................................ 13
> >    IANA Considerations ............................................ 13
> >    References ..................................................... 13
> >    Authors' Addresses ............................................. 14
> >    Appendix A ..................................................... 15
> >       A.1 Mandatory message codes and formats
> >       A.2 Request and Response
> >       A.3 Success and Failure
> >    Appendix B ..................................................... 17
> >       B.1 Mandatory Initial Request/Response EAP-types (Post-IKE)
> >       B.2 Identity
> >       B.3 Notification
> >       B.4 NAK
> >       B.5 MD5-Challenge
> >
> > 1. Introduction
> >
> >    This document defines the Extensible Authentication Protocol over IP
> >    (EAPoIP).
> >
> >    EAPoIP is intended primarily for authentication of hosts that want
> >    to be authorized access to resources in the access domain. EAPoIP
> >    assumes that the host has established a link-layer connection to an
> >    access router and has configured a valid IPv4 or IPv6 address for
> >    itself on the subnet by DHCP, by address auto-configuration, or by
> >    other means.
> >
> >    Dynamically configurable firewalls may be used to shield
> >    unauthenticated and unauthorized hosts on the access subnets from
> >    resources in the inner parts of the access domain. If the firewall
> >    and PAA are not co-located, PAA MAY use a MIDCOM protocol to
> >
> > P. Engelstad              Expires June 2002                  [Page 2]
> >                              EAP over IP                December 2001
> >    dynamically configure the firewall and allow domain access to
> >    authenticated and authorized hosts. A MIDCOM protocol is currently
> >    under development in IETF. The MIDCOM Working Group of IETF has
> >    determined the requirements of the protocol.
> >
> >    A PANA Authentication Agent (PAA), which is an Authentication Server
> >    located somewhere in the access domain, authenticates the host. The
> >    host may also want to authenticate the PAA. EAPoIP runs over IP and
> >    is link-layer agnostic; hosts may connect over either point-to-point
> >    or multi-access links. The authentication part of EAPoIP runs over
> >    UDP (or TCP or SCTP), which is also IP-agnostic; it may run over
> >    either IPv4 or IPv6.
> >
> >    The EAPoIP protocol consists of four main elements:
> >
> >    1) PAA Discovery: Mobile nodes and other hosts discover IP-addresses
> >    and identities of PAAs located in the access domain.
> >
> >    2) "Pre-IKE" EAPoIP: Hosts and PAAs prepares for IKE (below) [17],
> >    e.g. they set up a trust relationship by using some back-end AAA
> >    Infrastructure (e.g. Radius or Diameter). Pre-IKE EAPoIP uses an
> >    IANA-assigned port number. It must be designed with security in
> >    mind, since there may not exist an initial trust relationship
> >    between PAA and the host.
> >
> >    3) Internet Key Exchange (IKE): The host initiates an IKE session
> >    with PAA over UDP port 500, to set up IPSec Security Associations in
> >    both directions.
> >
> >    4) "Post-IKE" EAPoIP: All applications and protocols may
> >    authenticate the peer using the same authentication methods that are
> >    defined for EAP. All messages use a IANA-assigned port number, and
> >    MUST be protected by IPSec AH and ESP.
> >
> >    Post-IKE EAPoIP is basically a variation of the Extensible
> >    Authentication Protocol (EAP), although it runs over IP. Thus,
> >    significant parts of this document are VERBATIM cut-and-paste from
> >    RFC 2284 [7]. It reuses the extension formats for request-,
> >    response-, success-, and failure-messages defined for EAP, as well
> >    as the initial EAP request/response types. Unlike EAP, EAPoIP does
> >    not provide ways to negotiate non-EAPoIP authentication mechanisms.
> >    Pre-IKE EAPoIP is a request/response scheme that re-uses the Post-
> >    IKE message formats.
> >
> >    EAPoIP is built around IPSec and IKE. Ideally IPSec and IKE could
> >    replace both Pre-IKE and Post-IKE EAPoIP:
> >
> >       - Instead of using Pre-IKE EAPoIP, PAA may alternatively use the
> >       back-end AAA infrastructure between IKE message 5 and IKE message
> >       6 of phase 1 - assuming Main Mode. With skillful use of IKE, e.g.
> >       by using signature keys or by revealing the FQDN of the host, one
> >       may argue that pre-IKE EAPoIP may not be required in any
> >       circumstances. This document, however, assumes that IKE alone
> >
> > P. Engelstad              Expires June 2002                  [Page 3]
> >                              EAP over IP                December 2001
> >       will not be able to fulfill all requirements of all PANA
> >       scenarios.
> >
> >       - The existence of valid IPSec Security Associations implies that
> >       the peer is already authenticated, and one may argue that Post-
> >       IKE EAPoIP authentication is redundant. On the other hand, Post-
> >       IKE EAPoIP allows any protocol or application to freely
> >       authenticate and re-authenticate the peer (i.e. an authenticated
> >       ping) at any time. Post-IKE EAPoIP will not be allowed unless
> >       appropriate IPSec Security Associations are in place.
> >
> > 1.1 Specification of Requirements
> >
> >    In this document, several words are used to signify the requirements
> >    of the specification. These words are often capitalized. The key
> >    words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> >    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
> >    this document are to be interpreted as described in RFC 2119 [6].
> >
> > 1.2 Terminology
> >
> >    This document uses the same terms as [7], except for:
> >
> >       Peer: A node that is being authenticated by an authenticator.
> >
> >       Authenticator: The node requiring the authentication.
> >
> >    The following additional terms are used in this document:
> >
> >       PANA Authentication Agent (PAA): The EAPoIP Authentication
> >       Server. It is also the authenticator that authenticates the host.
> >
> >       Common Authentication Authority (CAA): An authority that has a
> >       trust relationships with both the peer and the authenticator.
> >       Both peer and authenticator can communicate with CAA using strong
> >       security mechanism. AAA protocols, such as Diameter or Radius,
> >       may be utilized to carry such communication. A mobile node that
> >       roams to a foreign access network may not share a secret with the
> >       PAA or there may not be an appropriate Public Key Infrastructure
> >       in place. The authenticator and peer may use the CAA to
> >       authenticate each other in a secure way.
> >
> > 2. EAPoIP Overview
> >
> >    The Extensible Authentication Protocol over IP (EAPoIP) is a general
> >    protocol for IP-based authentication, which supports multiple
> >    authentication mechanisms. It is a uni-directional protocol that
> >    allows the authenticator to authenticate the peer.
> >
> >    The uni-directional (Post-IKE) authentication process proceeds as
> >    follows:
> >
> >       1. The authenticator sends one or more Requests to authenticate
> >       the peer. The Request has a type field to indicate what is being
> >
> > P. Engelstad              Expires June 2002                  [Page 4]
> >                              EAP over IP                December 2001
> >       requested. Examples of Request types include Identity, MD5-
> >       challenge, One-Time Passwords, Generic Token Card, etc. The MD5-
> >       challenge type corresponds closely to the CHAP authentication
> >       protocol [3]. Typically, the authenticator will send an initial
> >       Identity Request followed by one or more Requests for
> >       authentication information. However, an initial Identity Request
> >       is not required, and MAY be bypassed in cases where the identity
> >       is presumed.
> >
> >       2. The peer sends a Response message in reply to each Request. As
> >       with the Request message, the Response message contains a type
> >       field, which corresponds to the type field of the Request.
> >
> >       3. The authenticator ends the authentication phase with a Success
> >       or Failure message.
> >
> >    The authenticator MAY authenticate the peer using a sequence of
> >    methods. Thus, the authentication process can loop through steps 1
> >    and 2 a number of times until the authenticator finally moves to
> >    step 3. The authentication process may also fail because the
> >    authenticator or peer times out, possibly after a number of
> >    retransmission attempts.
> >
> >    In most cases for which EAPoIP is intended bi-directional
> >    authentication is required. Two uni-directional authentication
> >    processes going in opposite directions comprise the bi-directional
> >    authentication. In one direction the host takes the role as the
> >    authenticator and authenticates the PAA as a peer. In the other
> >    direction the PAA takes the role as the authenticator and
> >    authenticates the host as a peer.
> >
> >    In some cases for which EAPoIP is intended the host will be the
> >    first to start authenticating the other party by sending a Request
> >    to the PAA (e.g. when the host roams to a new access network an
> >    discovers the PAA or when an authentication time-out event occurs by
> >    the host).
> >
> >    In other cases, the PAA will be the first to start authenticating
> >    the host (e.g. when the host acquires an IP address or attempts to
> >    access another resource or when an authentication time-out event
> >    occurs by the PAA.)
> >
> >    An authentication request message from one party may trigger the
> >    other party to start authenticating the other way. An authenticator
> >    MAY even assume the identity of the peer from the Request message,
> >    or from previous communication, and use this information to skip the
> >    Identity Request phase.
> >
> > 3. Extensions for EAPoIP Service Discovery
> >
> >    Router Advertisement Extensions and DHCP Extensions (or "options")
> >    are defined for both IPv4 and IPv6. These will inform a host that
> >    acquires an IPv4 or IPv6 address on how to get started with the
> >    authentication process in order to get access to the interior access
> >
> > P. Engelstad              Expires June 2002                  [Page 5]
> >                              EAP over IP                December 2001
> >    domain. The extensions are expected to simplify PAA discovery, but
> >    they are not mandatory.
> >
> >    Each extension conveys information about one particular PAA. If
> >    there are many PAAs in the access domain, the Router Advertisements
> >    or DHCP reply messages MAY include one extension for each PAA in the
> >    domain.
> >
> > 3.1 ICMPv4 Router Advertisement Extension for EAPoIP Service Discovery
> >
> >    This document suggests that the following extension MAY be used with
> >    ICMPv4 [10]:
> >
> >     0                   1                   2
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |     Type      |    Length     |   Sub-options...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Type
> >
> >       EAPoIP-RAv4-EXTENSION (TBD)
> >
> >    Length
> >
> >       This value equals the number of octets of the extension,
> >       excluding the Type and Length fields, i.e. it only includes the
> >       length of the sub-option field.
> >
> >    Sub-options
> >
> >       Sub-options are specified in section 3.5.
> >
> > 3.2 DHCPv4 Extension for EAPoIP Service Discovery
> >
> >    This document suggests that the following extension MAY be used with
> >    DHCPv4 [11]:
> >
> >    0                   1                   2
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |     Code      |     Len       |   Sub-options...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Code
> >
> >       EAPoIP-DHCPv6-EXTENSION (TBD)
> >
> >    Len
> >
> >       This value equals the number of octets of the extension,
> >       excluding the Code and Len fields, i.e. it only includes the
> >       length of the sub-option field.
> >
> >
> > P. Engelstad              Expires June 2002                  [Page 6]
> >                              EAP over IP                December 2001
> >    Sub-options
> >
> >       Sub-options are specified in section 3.5.
> >
> > 3.3 ICMPv6 Router Advertisement Option for EAPoIP Service Discovery
> >
> >    This document suggests that the following option MAY be used with
> >    ICMPv6 [12]:
> >
> >     0                   1                   2
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |     Type      |    Length     |   Sub-options...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Type
> >
> >       EAPoIP-RAv6-OPTION (TBD)
> >
> >    Length
> >
> >       This value equals the number of octets of the option, excluding
> >       the Type and Length fields, i.e. it only includes the length of
> >       the sub-option field.
> >
> >    Sub-options
> >
> >       Sub-options are specified in section 3.5.
> >
> > 3.4 DHCPv6 Option for EAPoIP Service Discovery
> >
> >    This document suggests that the following option MAY be used with
> >    DHCPv6 [13]:
> >
> >    0                   1                   2                   3
> >    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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |       option code           |          option-length          |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |   Sub-Option ...
> >    +-+-+-+-+-+-+-+
> >
> >    option code
> >
> >       EAPoIP-DHCPv6-OPTION (TBD)
> >
> >    option length
> >
> >       This value equals the number of octets of the extension,
> >       excluding the option code and option-length fields, i.e. it only
> >       includes the length of the sub-option field.
> >
> >
> >    Sub-options
> >
> > P. Engelstad              Expires June 2002                  [Page 7]
> >                              EAP over IP                December 2001
> >
> >       Sub-options are specified in section 3.5.
> >
> > 3.5 Sub-options for EAPoIP Service Discovery
> >
> > 3.5.1 PAA IPv4 Address Sub-option
> >
> >    This optional sub-option allows the host to discover the IPv4
> >    address of a PAA present in the access domain. It is typically
> >    included in DHCPv4 Extensions and IPv4 Router Advertisement
> >    Extensions for EAPoIP Service Discovery.
> >
> >     0                   1                   2
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Sub-opt. Type |    Length     | IPv4 Address (4 octets)...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Sub-Option Type
> >
> >       TBD
> >
> >    Length
> >
> >       4
> >
> >    IPv4 Address
> >
> >       An IPv4 address of the PAA referred to in this extension.
> >
> > 3.5.2 PAA IPv6 Address Sub-option
> >
> >    This optional sub-option allows the host to discover the IPv6
> >    address of a PAA present in the access domain. It is typically
> >    included in DHCPv6 Extensions and IPv6 Router Advertisement
> >    Extensions for EAPoIP Service Discovery.
> >
> >    0                   1                   2
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Sub-opt. Type |    Length     | IPv6 Address (16 octets)...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Sub-option Type
> >
> >       TBD
> >
> >    Length
> >
> >       16
> >
> >    IPv6 Address
> >
> >       An IPv6 address of the PAA referred to in this extension.
> >
> > P. Engelstad              Expires June 2002                  [Page 8]
> >                              EAP over IP                December 2001
> >
> >    Since EAPoIP is a stateful protocol, the IPv6 Address SHOULD NOT be
> >    an anycast addresses before the problems regarding anycast for
> >    stateful communication as described in RFC 1546 [8], have been
> >    solved for IPv6.
> >
> >    One may in the future pre-assign to EAPoIP site-scoped IPv6
> >    addresses that can be hard coded into the host. (E.g. the five site-
> >    scoped addresses fec0:0:0:ffff::4 - fec0:0:0:ffff::8 from the
> >    address space with SLA values of 'ffff' could be assigned to EAPoIP,
> >    similar to what is proposed for stateless IPv6 DNS discovery in
> >    [9]). This may facilitate the authentication process, reduce the
> >    fate sharing, and save the additional bandwidth of conveying the PAA
> >    addresses to the host.
> >
> > 3.5.3 PAA Identity Sub-option
> >
> >    This optional sub-option allows the host to discover the identity of
> >    the PAA that the extension concerns. It allows the host to
> >    authenticate the PAA directly without sending an initial EAPoIP
> >    Identity request first.
> >
> >    0                   1                   2
> >     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Sub-opt. Type |    Length     | PAA Identity ...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Sub-option Type
> >
> >       TBD
> >
> >    Length
> >
> >       Length of the PAA Identity field.
> >
> >    PAA Identity
> >
> >       The identity of the PAA.
> >
> > 3.5.4 Other Sub-options
> >
> >    Other sub-options may be specified at a later stage.
> >
> > 4. EAPoIP Packet and Message Formats
> >
> > 4.1 EAPoIP Transport Protocols
> >
> >    This document suggests EAPoIP runs over UDP. (The alternative of
> >    running EAPoIP over TCP or SCTP is for further study. Experience
> >    from implementations may determine the best transport protocol for
> >    EAPoIP.)
> >
> >    EAPoIP SHOULD run with IANA-assigned port numbers (TBD).
> >
> > P. Engelstad              Expires June 2002                  [Page 9]
> >                              EAP over IP                December 2001
> >
> > 4.2 EAPoIP uses IKE and IPSec
> >
> >    Since the authentication session may be sent over shared medias,
> >    EAPoIP is more vulnerable to snooping and packet modification
> >    attacks than EAP is over a PPP links. This document proposes
> >    therefore that every EAPoIP packet (including IP header fields) MUST
> >    be protected by IPSec AH strong authentication, unless otherwise
> >    explicitly specified in this document. Furthermore, every EAPoIP
> >    payload MUST be protected by IPSec ESP strong encryption, unless
> >    otherwise explicitly specified in this document. IPSec is specified
> >    in [14] - [17].
> >
> >    Packet authentication is a security mechanism that comes in addition
> >    to the EAP-like authentication of the peer. As shown later in this
> >    document, applications and protocols may run EAP authentication
> >    methods over EAPoIP, using the given UDP-port number, and the same
> >    message-codes and type-values that the EAP method would use (because
> >    the message formats are the same).
> >
> >    Such EAP-like authentication messages MUST NOT be sent or accepted
> >    without being strongly protected by IPSec AH and IPSec ESP. With
> >    this rule in mind, a protocol or application can safely substitute a
> >    PPP EAP authentication method with its EAPoIP counterpart, with
> >    assurance that this transition will not compromise the security of
> >    the authentication.
> >
> >    When a host wants to use EAPoIP to gain access to a protected access
> >    domain, it may be in one of the following situations:
> >
> >    1) The host has not a trust relationship to any CAA that the PAA has
> >    a trust relationship to. In this case the host will not get access
> >    to the domain.
> >
> >    2) The host has a trust relationship to a CAA that the PAA also has
> >    a trust relationship to. In this case the host MAY get access to the
> >    domain in the following way:
> >
> >       a) "Pre-IKE" EAPoIP: Some "pre-IKE" EAPoIP messaging between the
> >       host and the PAA may be a prerequisite to accommodate a
> >       subsequent session of The Internet Key Exchange (IKE) [17]. The
> >       PAA and host may use the CAA to exchange and verify public keys,
> >       to exchange certificates signed by the CAA, or to exchange pre-
> >       shared secrets. In the latter case, a roaming host may need to
> >       pass a binding between its IP-address and a temporary or
> >       encrypted identity, since the existing IKE specification requires
> >       such an address-identity binding. Pre-IKE EAPoIP messages between
> >       hosts and PAAs cannot be protected by IPSec, because there is no
> >       IPSec Security Association yet established between the host and
> >       the PAA. This calls for an exception to the IPSec-based security
> >       rule above, and such messages MUST utilize specific strong
> >       security mechanisms. Communication between PAAs and CAAs MUST be
> >       protected by strong authentication and encryption. Pre-IKE
> >
> > P. Engelstad              Expires June 2002                 [Page 10]
> >                              EAP over IP                December 2001
> >       communication MAY result in maximum one round-trip-time worth of
> >       messaging between PAA and CAA.
> >
> >       b) Internet Key Exchange (IKE): The host initiates an IKE-session
> >       with PAA on UDP port 500. If the Pre-IKE EAPoIP above was not
> >       necessary, the PAA MAY consult the CAA between message 5 and 6
> >       (assuming that Main Mode is being used in phase 1, and that the
> >       host passes its identity to PAA in the 5th message). On the other
> >       hand, if the Pre-IKE EAPoIP resulted in one round-trip-time worth
> >       of messaging between PAA and CAA, PAA may not need to consult CAA
> >       during the IKE-session. After IKE phase 1, the host and PAA
> >       establishes the IPSec Security Associations in phase 2.
> >
> >       c) Post-IKE EAPoIP: The peer and the host MAY authenticate and
> >       re-authenticate each other, using EAP-like authentication
> >       mechanisms that is protected by the IPSec security associations
> >       established by IKE.
> >
> >    3) If the host has a trust relationship to the PAA (or the CAA is
> >    co-located with the PAA), but the IPSec Security Associations are
> >    not yet established, the host uses IKE to establish the Security
> >    Associations which are used to protect subsequent post-IKE EAPoIP
> >    communication.
> >
> >    4) If the host and PAA already have established the required IPSec
> >    Security Associations they MAY start with post-IKE EAPoIP
> >    communication directly.
> >
> > 4.3 EAPoIP message format (Post-IKE)
> >
> >    The EAPoIP message in the UDP packet uses the same format as the EAP
> >    packet.
> >
> >    A summary of the EAPoIP message format is shown below. The fields
> >    are transmitted from left to right.
> >
> >     0                   1                   2                   3
> >     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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |     Code      |   Identifier  |             Length            |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    | Data ...
> >    +-+-+-+-+
> >
> >    Code
> >
> >       The Code field is one octet and identifies the type of EAPoIP
> >       message. EAPoIP Codes are the same as the EAP Codes, and are
> >       assigned as follows:
> >
> >       1 Request
> >       2 Response
> >       3 Success
> >       4 Failure
> >
> > P. Engelstad              Expires June 2002                 [Page 11]
> >                              EAP over IP                December 2001
> >
> >    Identifier
> >
> >       The Identifier field is one octet and aids in matching responses
> >       with requests.
> >
> >    Length
> >
> >       The Length field is two octets and indicates the length (in
> >       octets) of the EAPoIP message including the Code, Identifier,
> >       Length and Data fields.
> >
> >    Data
> >
> >       The Data field is zero or more octets. The Code field determines
> >       the format of the Data field.
> >
> >    All EAPoIP implementations MUST support the same message codes and
> >    message formats that EAP supports, and EAPoIP MUST support message
> >    codes 1-4. The message codes and formats are described in Appendix
> >    A, with only minor modifications from the original text in RFC 2284
> >    [7].
> >
> > 5. Initial EAPoIP Request/Response Types
> >
> >    This section defines the initial set of EAPoIP Types used in
> >    Request/Response exchanges.
> >
> >    A summary of the Request and Response message format is shown below.
> >    The fields are transmitted from left to right.
> >
> >     0                   1                   2                   3
> >     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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |     Code      |  Identifier   |            Length             |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |     Type      |  Type-Data ...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> >
> >    The Code-field is 1 for Request and 2 for Response. Refer to
> >    Appendix A for more details.
> >
> >    The Type field is one octet and identifies the structure of an
> >    EAPoIP Request or Response message. Different request/response types
> >    are described below.
> >
> > 5.1 Supported EAP-Types
> >
> >    The initial EAPoIP Request/Response Types include (a subset of) the
> >    initial EAP Request/Response Types, using the same Type values as
> >    EAP does [7]. These include the type values:
> >
> >    1 Identity
> >    2 Notification
> >
> > P. Engelstad              Expires June 2002                 [Page 12]
> >                              EAP over IP                December 2001
> >    3 NAK (Response only)
> >    4 MD5-Challenge
> >
> >    Every (Post-IKE) EAPoIP message that uses an EAP Type value MUST be
> >    strongly protected by IPSec AH and ESP: Authenticators or peers MUST
> >    NOT send such messages without IPSec AH and ESP, and they MUST be
> >    silently discarded upon reception. With this rule in mind, a
> >    protocol or application can safely substitute a PPP EAP
> >    authentication method with its EAPoIP counterpart, without
> >    compromising the security of the authentication.
> >
> >    All EAPoIP implementations MUST support the same EAP-Types that EAP
> >    MUST support, and EAPoIP MUST support EAP-Types 1-4. These types are
> >    described in Appendix B, with only minor modifications from the
> >    original text in RFC 2284 [7]. Additional Types may be defined in
> >    follow-on documents.
> >
> > 6. Pre-IKE EAPoIP Message formats
> >
> >    This document suggests that Pre-IKE EAPoIP messages use the same
> >    messaging format as the post-IKE (i.e. EAP-like) EAPoIP message
> >    format described above.
> >
> >    However, since Pre-IKE EAPoIP messages require special security
> >    mechanisms, they should be clearly and easily distinguished from
> >    Post-IKE messages. One may for example use different ranges of
> >    Initial request/response types, or different message codes, or even
> >    different IANA-assigned UDP port numbers.
> >
> >    One may define a set of generic Attribute-Length-Value (ALV) pairs
> >    that can be used in Pre-IKE messages.
> >
> >    The formats of Pre-IKE EAPoIP messages and their contents are for
> >    further study.
> >
> > Security Considerations
> >
> >    Security issues are the primary topic of this document...
> >
> > IANA Considerations
> >
> >    TBD...
> >
> > Acknowledgements
> >
> >    ...
> >
> > References
> >
> >    [1]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
> >    1661, July 1994.
> >
> >    [2]  Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
> >    1700, October 1994.
> >
> > P. Engelstad              Expires June 2002                 [Page 13]
> >                              EAP over IP                December 2001
> >
> >    [3]  Simpson, W., "PPP Challenge Handshake Authentication Protocol
> >    (CHAP)", RFC 1994, August 1996.
> >
> >    [4]  Haller, N. and C. Metz, "A One-Time Password System", RFC 1938,
> >    May 1996.
> >
> >    [5]  Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
> >    10646", RFC 2044, October 1996.
> >
> >    [6]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
> >    Levels", RFC 2119, March 1997.
> >
> >    [7]  Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication
> >    Protocol", RFC 2284, March 1998.
> >
> >    [8]  Partridge, C., Mendez, T. and Milliken, W., "Host Anycasting
> >    Service", RFC 1546, November 1993.
> >
> >    [9]  Thaler, D., Hagino, J.I., "IPv6 Stateless DNS Discovery", Work
> >    in progress, November 2001.
> >
> >    [10]  Deering, S. "ICMP Router Discovery Messages", RFC 1256,
> >    September 1991.
> >
> >    [11]  Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,
> >    March 1997.
> >
> >    [12]  Narten, T., Nordmark, E., Simpson, W. "Neighbor Discovery for
> >    IP Version 6", RFC 2461, December 1998.
> >
> >    [13]  Droms, R. (ed.), "Dynamic Host Configuration Protocol for IPv6
> >    (DHCPv6)", Work in progress, November 2001.
> >
> >    [14]  Kent, S., Atkinson, R. "Security Architecture for the Internet
> >    Protocol", RFC 2401, November 1998.
> >
> >    [15]  Kent, S., Atkinson, R. "IP Authentication Header", RFC 2402,
> >    November 1998.
> >
> >    [16]  Atkinson, R., Kent, S. "IP Encapsulating Security Payload
> >    (ESP)", RFC 2406, November 1998.
> >
> >    [17]  Harkins, D., Carrel, D. "The Internet Key Exchange (IKE)", RFC
> >    2409, November 1998.
> >
> >    [18]  IEEE Standard for Local and Metropolitan Networks: Port bases
> >    Network Access Control, IEEE Std 802.1X-2001, June 2001.
> >
> > Authors' Addresses
> >
> >    Paal E. Engelstad
> >    Telenor R&D (California)
> >    399 Sherman Ave. Suite #12
> >
> > P. Engelstad              Expires June 2002                 [Page 14]
> >                              EAP over IP                December 2001
> >    Palo Alto, CA 94306, USA
> >
> >    Tel.: + 1-650- 714 7537
> >    e-mail: [email-masked]
> >
> > Appendix A
> >
> > A.1 Mandatory message codes and formats
> >
> >    All EAPoIP implementations MUST support the same message codes and
> >    message formats that EAP supports, and EAPoIP MUST support message
> >    codes 1-4. The message codes and formats are described in the
> >    following two sub-sections, with only minor modifications from the
> >    original text in RFC 2284 [7].
> >
> > A.2 Request and Response
> >
> >    Description
> >
> >    The authenticator sends a Request message to the peer. Each Request
> >    has a type field which serves to indicate what is being requested.
> >    The authenticator MUST transmit an EAPoIP message with the Code
> >    field set to 1 (Request). Additional Request messages MUST be sent
> >    until a valid Response message is received, or an optional retry
> >    counter expires. Retransmitted Requests MUST be sent with the same
> >    Identifier value in order to distinguish them from new Requests. The
> >    contents of the data field is dependent on the
> >    Request type. The peer MUST send a Response message in reply to a
> >    Request message. Responses MUST only be sent in reply to a received
> >    Request and never retransmitted on a timer. The Identifier field of
> >    the Response MUST match that of the Request.
> >
> >       Implementation Note: The authentication process will in some
> >       cases involve user input. In other cases, on the other hand, it
> >       will not require user input, but run over an unreliable medium
> >       (e.g. wireless) and have strict timing constrains. Hence, some
> >       care must be taken when deciding upon retransmission strategies
> >       and authentication timeouts.
> >
> >    One solution might be to set the retry counter to zero by default,
> >    which is also done for EAP over 802.1x [18]. In this case,
> >    retransmissions will never occur. Instead the peer times out and
> >    authentication is restarted. The identity value will be renewed,
> >    which makes the MD5-challenge authentication type more similar to
> >    CHAP [3]. However, this issue is for further study. Experience from
> >    implementations may determine the best retransmission strategy for
> >    EAPoIP.)
> >
> >    A summary of the Request and Response message format is shown below.
> >    The fields are transmitted from left to right.
> >
> >     0                   1                   2                   3
> >     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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > P. Engelstad              Expires June 2002                 [Page 15]
> >                              EAP over IP                December 2001
> >    |     Code      |  Identifier   |            Length             |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |     Type      |  Type-Data ...
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> >
> >    Code
> >
> >       1 for Request;
> >       2 for Response.
> >
> >    Identifier
> >
> >       The Identifier field is one octet. The Identifier field MUST be
> >       the same if a Request message is retransmitted due to a timeout
> >       while waiting for a Response. Any new (non-retransmission)
> >       Requests MUST modify the Identifier field. If a peer receives a
> >       duplicate Request for which it has already sent a Response, it
> >       MUST resend its Response. If a peer receives a duplicate Request
> >       before it has sent a Response to the initial Request (i.e. it's
> >       waiting for user input), it MUST silently discard the duplicate
> >       Request.
> >
> >    Length
> >
> >       The Length field is two octets and indicates the length of the
> >       EAPoIP message including the Code, Identifier, Length, Type, and
> >       Type-Data fields.
> >
> >    Type
> >
> >       The Type field is one octet. This field indicates the Type of
> >       Request or Response. Only one Type MUST be specified per EAPoIP
> >       Request or Response. Normally, the Type field of the Response
> >       will be the same as the Type of the Request. However, there is
> >       also a NAK Response Type for indicating that a Request type is
> >       unacceptable to the peer. When sending a NAK in response to a
> >       Request, the peer MAY indicate an alternative desired
> >       authentication Type that it supports. An initial specification of
> >       Types follows in a later section of this document.
> >
> >    Type-Data
> >
> >       The Type-Data field varies with the Type of Request and the
> >       associated Response.
> >
> > A.3 Success and Failure
> >
> >    Description
> >
> >       The Success message is sent by the authenticator to the peer to
> >       acknowledge successful authentication. The authenticator MUST
> >       transmit an EAPoIP message with the Code field set to 3
> >       (Success).
> >
> >
> > P. Engelstad              Expires June 2002                 [Page 16]
> >                              EAP over IP                December 2001
> >       If the authenticator cannot authenticate the peer (unacceptable
> >       Responses to one or more Requests) then the implementation MUST
> >       transmit an EAPoIP message with the Code field set to 4
> >       (Failure). An authenticator MAY wish to issue multiple Requests
> >       before sending a Failure response in order to allow for human
> >       typing mistakes.
> >
> >       Implementation Note: Because the Success and Failure messages are
> >       not acknowledged, they may be potentially lost. A peer MUST allow
> >       for this circumstance. By setting the retry counter to zero, as
> >       this document proposes as a default configuration, loss of a
> >       Success or Failure message will result in peer timeout, and
> >       restarting of the authentication process.
> >
> >    A summary of the Success and Failure message format is shown below.
> >    The fields are transmitted from left to right.
> >
> >     0                   1                   2                   3
> >     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
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >    |     Code      |  Identifier   |           Length              |
> >    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >    Code
> >
> >       3 for Success;
> >       4 for Failure.
> >
> >    Identifier
> >
> >       The Identifier field is one octet and aids in matching replies to
> >       Responses. The Identifier field MUST match the Identifier field
> >       of the Response message that it is sent in response to.
> >
> >    Length
> >
> >       4
> >
> >
> > Appendix B
> >
> > B.1 Mandatory Initial Request/Response EAP-Types (Post-IKE)
> >
> >    All EAPoIP implementations MUST support the same initial
> >    request/response EAP-Types that EAP MUST support, and EAPoIP MUST
> >    support EAP-Types 1-4. These types are described in the following
> >    four sub-sections, with only minor modifications from the original
> >    text in RFC 2284 [7].
> >
> > A.2 Identity
> >
> >    Description
> >
> >
> > P. Engelstad              Expires June 2002                 [Page 17]
> >                              EAP over IP                December 2001
> >       The Identity Type is used to query the identity of the peer.
> >       Generally, the authenticator will issue this as the initial
> >       Request. An optional displayable message MAY be included to
> >       prompt the peer in the case where there expectation of
> >       interaction with a user. A Response MUST be sent to his Request
> >       with a Type of 1 (Identity).
> >
> >       Implementation Note: The peer MAY obtain the Identity via user
> >       input. It is suggested that the authenticator retry the Identity
> >       Request in the case of an invalid Identity or authentication
> >       failure to allow for potential typos on the part of the user. It
> >       is suggested that the Identity Request be retried a minimum of 3
> >       times before terminating the authentication phase with a Failure
> >       reply. The Notification Request MAY be used to indicate an
> >       invalid authentication attempt prior to transmitting a new
> >       Identity Request (optionally, the failure MAY be indicated within
> >       the message of the new Identity Request itself).
> >
> >    Type
> >
> >       1
> >
> >    Type-Data
> >
> >       This field MAY contain a displayable message in the Request. The
> >       Response uses this field to return the Identity. If the Identity
> >       is unknown, this field should be zero bytes in length. The field
> >       MUST NOT be null terminated. The length of this field is derived
> >       from the Length field of the Request/Response message and hence a
> >       null is not required.
> >
> > B.3 Notification
> >
> >    Description
> >
> >       The Notification Type is optionally used to convey a displayable
> >       message from the authenticator to the peer. The peer SHOULD
> >       display this message to the user or log it if it cannot be
> >       displayed. It is intended to provide an acknowledged notification
> >       of some imperative nature. Examples include authentication
> >       failure warnings, and warnings that a password with an expiration
> >       time is about to expire. In most circumstances, notification
> >       should not be required.
> >
> >    Type
> >
> >       2
> >
> >    Type-Data
> >
> >       The Type-Data field in the Request contains a displayable message
> >       greater than zero octets in length. Length field of the Request
> >       message determines the length of the message. The message MUST
> >       not be null terminated. A Response MUST be sent in reply to the
> >
> > P. Engelstad              Expires June 2002                 [Page 18]
> >                              EAP over IP                December 2001
> >       Request with a Type field of 2 (Notification). The Type-Data
> >       field of the Response is zero octets in length. The Response
> >       should be sent immediately (independent of how the message is
> >       displayed or logged).
> >
> > B.4 NAK
> >
> >    Description
> >
> >       The NAK Type is valid only in Response messages. It is sent in
> >       reply to a Request where the desired authentication Type is
> >       unacceptable. Authentication Types are numbered 4 and above. The
> >       Response contains the authentication Type desired by the peer.
> >
> >    Type
> >
> >       3
> >
> >    Type-Data
> >
> >       This field MUST contain a single octet indicating the desired
> >       authentication type.
> >
> > B.5 MD5-Challenge
> >
> >    Description
> >
> >       The MD5-Challenge Type is analogous to the PPP CHAP protocol [3]
> >       (with MD5 as the specified algorithm). The PPP Challenge
> >       Handshake Authentication Protocol RFC [3] should be referred to
> >       for further implementation specifics. The Request contains a
> >       "challenge" message to the peer. A Response MUST be sent in reply
> >       to the Request. The Response MAY be either of Type 4 (MD5-
> >       Challenge) or Type 3 (NAK). The NAK reply indicates the peer's
> >       desired authentication mechanism Type. All EAPoIP implementations
> >       MUST support the MD5-Challenge mechanism.
> >
> >    Type
> >
> >       4
> >
> >    Type-Data
> >
> >       The content of the Type-Data field is summarized below. For
> >       reference on the use of this fields see the PPP Challenge
> >       Handshake Authentication Protocol [3].
> >
> >        0                   1                   2                   3
> >        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
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |  Value-Size   |  Value ...
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |  Name ...
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > P. Engelstad              Expires June 2002                 [Page 19]
> >                              EAP over IP                December 2001
> >
> >
> >
> > P. Engelstad              Expires June 2002                 [Page 20]
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 7 Jan 2002 10:47:51 -0800

Paal,

> Sounds interesting! Generally I think that the actual carrier is not
the main issue at this point in time:

Actually, I think the carrier is exactly the point. Especially if we
decide to use EAP as the actual PANA protocol

> To save energy we should first focus on how existing protocols (e.g.
EAP, IKE, IPSec, DIAMETER, DHCP and DHCP-relays, ND, X.509,
MIDCOM-in-some-years-to-come, etc..) may interact together for both IPv4
and IPv6 - taking both firewalls and NATs into consideration - to meet
(the still vague concept of) our most important requirements.

Not clear what you have in mind. Why should firewalls and NATs be an
issue on the last hop link?

            jak

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 8 Jan 2002 16:55:27 -0800

Hi Paal,

> Nope. I tried to locate it, but could not find it.

http://ietf.org/internet-drafts/draft-yegin-unap-snard-00.txt

> Sounds interesting! Generally I think that the actual carrier is not the
main issue at this point in time:

Well, actually it *is* the main point. Determining what the carrier is and
how it's
used is the subject of PANA.

alper

>
> To save energy we should first focus on how existing protocols (e.g. EAP,
IKE, IPSec, DIAMETER, DHCP and DHCP-relays, ND, X.509,
MIDCOM-in-some-years-to-come, etc..) may interact together for both IPv4 and
IPv6 - taking both firewalls and NATs into consideration - to meet (the
still vague concept of) our most important requirements.
>
> Most of these protocols will naturally be out of scope as work items for
this WG, but we may take advantage of their existing functionalities.
>
> I think the actual carrier (TCP, UDP, SCTP, ICMP, higher layer protocols,
etc...) will come out as a result of more principal design choices.