Subject: Re: PAA Discovery

From: Jacques Caron <[email-masked]>
Date: Sat, 02 Feb 2002 12:07:33 +0100

Hi all,

First of all, sorry if I'm repeating something that was already discussed 
before, I just discovered the WG, and I have to admit I haven't read the 
whole archive (it's a bit long...).

I'm actually wondering if there's really a need for the client to find the 
PAA. If PANA really is more or less EAP over <pick a protocol>, then the 
initiator is the PAA, not the client. So the only important thing is for 
the PAA to be aware of the new client. Depending on the exact context, 
there might be many ways to get that:
- some SNMP trap or equivalent method from the physical device (AP, 
switch...) that actually sees the connection coming up
- some hook into the DHCP server when it assigns an IP address to the client

I currently use the second method (with a quick extension to ISC DHCP that 
allows me to launch an arbitrary executable when a response is sent to a 
client) to start EAP/UDP authentication in a WLAN context. Works pretty 
much OK...

I haven't read extensively the scenarios draft yet (though you'll probably 
get a bunch of comments over the week-end), but I'm not sure there are any 
situations where neither of the above would work?

Comments welcome.

Thanks,

Jacques.

At 21:53 01/02/2002, Paal Engelstad wrote:
>Hi all,
>
>I recently submitted a draft proposing a mechanism for discovering 
>IP-addresses of PAAs. It is a lightweight and straightforeward solution 
>based on extensions to RAs and/or to DHCP messages.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

---

From: Paal Engelstad <[email-masked]>
Date: Sat, 2 Feb 2002 22:49:31 +0100

Jacques,

> 
> Fra: Jacques Caron <[email-masked]>
> Dato: 2002/02/02 Sat PM 12:07:33 CET
> Til: Paal Engelstad <[email-masked]>
> CC: [email-masked]
> Tema: Re: PAA Discovery
> 
> Hi all,
> 

Don't let that hinder you in joining the discussion!
 
> PAA. 

That's a good question. I can think of some PANA solutions where PAA discovery would not be necessary and others where it will. Since the WG Chairs have stressed that we need a solution soon, I think the sooner we start discussing PAA discovery the better. The feasibility of different discovery methods will also influence which PANA proposal to choose.

>If PANA really is more or less EAP over <pick a protocol>, then the 
> initiator is the PAA, not the client. 

PAA is the initiator when it (re-)authenticates the roaming host. I am not sure if the same goes when the host (re-) authenticates PAA, though...? 

Moreover, I think an authentication process going in one direction could trigger the other authentication process going in the other direction. So it is not evident to me who is going to start the authentication after the discovery phase. 

Furthermore, before they start re-authenticating each other, they MAY establish a session key (possibly supported by a AAA infrastructure). I am not sure if the session key establishment process MUST be initated by PAA, either... ???

I recently re-submitted the EAPoIP-draft (attached), which basically is EAP over UDP. I discuss these scenarios in section 5 and 6. Hope you have time to take a look at it and give your comments.

Paal

EAPoIP-draft (01.txt) attached.

> So the only important thing is for 

     Internet Draft                                       P. Engelstad 
                                                           Telenor R&D 
     Expires July 2002                                    January 2002 

            Extensible Authentication Protocol over IP (EAPoIP) 
         
                <draft-engelstad-pana-eap-over-ip-01.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]. 

     Abstract 
         
        This document specifies the Extensible Authentication Protocol over 
        IP (EAPoIP) to be used as a carrier for network access 
        authentication. An access domain is represented by one or many PANA 
        Authentication Agents (PAAs). Before a host is granted access to the 
        domain, a PAA can use EAPoIP to authenticate the host. The host can 
        also use EAPoIP to authenticate the PAA. EAPoIP is essentially a 
        variation of the Extensible Authentication Protocol (PPP EAP) [2] 
        and runs over IP - either IPv4 or IPv6. Unlike PPP EAP, EAPoIP 
        allows hosts and PAAs to authenticate over any link layer 
        technology, and they do not need to be on the same link. Since 
        EAPoIP is basically a client/server protocol, and since the PANA WG 
        is opting for a lightweight solution, UDP is proposed as the 
        transport protocol for EAPoIP.   

     P. Engelstad              Expires July 2002                  [Page 1] 
                                  EAP over IP                February 2002 

     Table of Contents 
         
        1 Introduction.....................................................2 
        2 Terminology......................................................3 
        3 UDP as a transport protocol for EAPoIP...........................3 
        4 EAPoIP re-uses PPP EAP message formats...........................3 
        5 A simplified model of a "host-initiated" EAPoIP scheme...........4 
        6 A simplified model of a "network-initiated" EAPoIP scheme........6 
        7 Identity hiding..................................................6 
        8 Additional Security Requirements.................................7 
        9 Retransmission and timeout mechanisms............................7 
        10 Security Considerations.........................................7 
        IANA Considerations................................................7 
        Acknowledgements...................................................7 
        References.........................................................7 
        Authors' Addresses.................................................8 

     1 Introduction 
         
        This document specifies the Extensible Authentication Protocol over 
        IP (EAPoIP) to be used as a carrier for network access 
        authentication.  
         
        An access domain is represented by one or many PANA Authentication 
        Agents (PAAs). Before a host is granted access to the domain, a PAA 
        MAY use EAPoIP to authenticate the host. The host MAY also use 
        EAPoIP to authenticate the PAA.  
         
        EAPoIP MAY initially be used to establish a local security 
        association (e.g. in terms of a session key) between a host and a 
        PAA. A PAA MAY subsequently use EAPoIP to (re-) authenticate a host, 
        and a host MAY also use EAPoIP to (re-) authenticate a PAA. 
         
        EAPoIP is essentially a variation of the Extensible Authentication 
        Protocol (PPP EAP) [2]. Unlike PPP EAP, EAPoIP runs over IP - either 
        IPv4 or IPv6. Thus, it allows hosts and PAAs to authenticate over 
        any link layer technology, and they do not need to be on the same 
        link.  
         
        EAPoIP need to use a transport protocol. Since EAPoIP is basically a 
        client/server protocol, and since the PANA WG is opting for a 
        lightweight solution, UDP is proposed. EAPoIP, as outlined in this 
        document, MAY readily be modified to use TCP or SCTP as transport 
        protocols. ICMP, on the other hand, seems inappropriate, since PAA 
        is not concerned with routing.  
         
        EAPoIP assumes that the host has configured a valid IPv4 or IPv6 
        address for itself. It MAY also have discovered IP-addresses of PAAs 
        in the access domain. A PAA Discovery mechanism is proposed in [1].  

     P. Engelstad              Expires July 2002                  [Page 2] 
                                  EAP over IP                February 2002 
      
        Where to locate PAAs (e.g. with a PAA located on each access router 
        or with a pool of PAAs located further "back" in the access domain) 
        represents an architectural tradeoff. The PANA WG may leave up to 
        the implementers and operators which architecture would best fit 
        their needs. Alternatively, the PANA WG may mandate that PAAs are 
        located on access routers. The scheme presented in this document 
        does not mandate any particular architecture; it should accommodate 
        all possible PAA configurations. 

     2 Terminology  
         
        This document uses the following terms: 
         
           Authenticator: A node requiring the authentication, like a PPP 
           EAP authenticator ([2], [3]).  
            
           Peer: A node that is being authenticated by an authenticator, 
           like a PPP EAP peer ([2], [3]).  
         
           PANA Authentication Agent (PAA): The authentication server 
           function. It acts as an EAP Authenticator that authenticates a 
           host, or as an EAP Peer that is authenticated by a host. 

     3 UDP as a transport protocol for EAPoIP 
         
        This document suggests that EAPoIP uses UDP as a transport protocol.  
         
        Considering PANA WG's preference for a lightweight solution UDP and 
        ICMP are both attractive alternatives. Since EAPoIP is basically a 
        stateful client/server protocol, UDP is thus proposed. 
         
        (The intention of ICMP in the original IP architecture was to allow 
        routers to send error and control messages to other routers and 
        hosts. Since the PAA function is not concerned with routing of any 
        sort, ICMP is ruled out as an alternative.) 
         
        The EAPoIP protocol, as described in this document, can readily be 
        modified to use more heavyweight transport protocols, such as TCP or 
        SCTP. 
         
        EAPoIP SHOULD use IANA-assigned port numbers (TBD).  

     4 EAPoIP re-uses PPP EAP message formats 
          
        EAPoIP messages re-uses PPP EAP packet formats ([2], [3]).  
         
        Thus, EAPoIP MUST support the four message types "Request", 
        "Response", "Success" and "Failure" with the corresponding code 
        values 1, 2, 3, and 4, respectively. 

     P. Engelstad              Expires July 2002                  [Page 3] 
                                  EAP over IP                February 2002 
      
        Furthermore, EAPoIP MUST also support the initial EAPoIP 
        Request/Response Types that MUST be supported by PPP EAP. These 
        include the Request/Response Types "Identity", "Notification", "NAK" 
        and "MD5-Challenge" - with the corresponding code values 1, 2, 3, 
        and 4, respectively. 

     5 A simplified model of a "host-initiated" EAPoIP scheme 
         
        The following diagram shows a simplified model of the message 
        exchanges of an EAPoIP scheme where the host takes the initiative: 

           Roaming host       Access Router/DHCP server         PAA 
               |                         |                       | 
               |                         |                       | 
               |   1) PAA Discovery      |                       | 
               |<----------------------- |                       | 
               |                         |                       | 
           ....|.................................................|....... 
               |                                                 | 
               |          2a) Session Key Request                | 
               |------------------------------------------------>| 
               |                                                 | 
               |                                                 |  AAA 
               |                                                 |<----->TTP 
               |                                                 | 
               |          2b) Session Key Response               | 
               |<------------------------------------------------| 
               |                                                 | 
           ....|.................................................|....... 
               |                                                 | 
               |        3a) (Re-)authentication Challenge        | 
               |<------------------------------------------------| 
               |                                                 | 
               |        3b) (Re-)authentication Response         | 
               |------------------------------------------------>| 
               |                                                 | 
           ....|.................................................|....... 
               |                                                 | 
               |        4a) (Re-)authentication Challenge        | 
               |------------------------------------------------>| 
               |                                                 | 
               |        4b) (Re-)authentication Response         | 
               |<------------------------------------------------| 
               |                                                 | 
           ....|.................................................|....... 
            
        The PAA may be co-located with the Access Router or DHCP server.  
         
        The messages are described as follows:  
         
        1) PAA discovery:  
      
     P. Engelstad              Expires July 2002                  [Page 4] 
                                  EAP over IP                February 2002 

           A roaming host discovers the IP-address (and identity) of a PAA 
           in an extension to a Router Advertisement or by means of DHCP. A 
           PAA Discovery mechanism is proposed in [1]. It allows the host to 
           discover the IP-address and identity of the PAA, as well as the 
           session key establishment method to be used in the subsequent 
           message exchange. 
            
        This scheme assumes that it is the host that sends the first message 
        after having discovered a PAA. 
         
        2) Session Key Distribution: 
         
        Assuming, for simplicity, that a session key establishment algorithm 
        uses only 2 local passes between host and PAA:  
            
           2a) The host initiates the Session Key Establishment phase (as an 
           EAP Authenticator) by sending an EAP Session Key Request to the 
           PAA.  
            
           2b) PAA acts as an EAP peer and sends an EAP Session Key 
           Response. PAA MAY use a back-end AAA infrastructure, a 
           Certificate Authority or another kind of Trusted Third Party 
           (TTP) to intercept and validate the Session Key Request and/or to 
           formulate the Session Key Response. 
            
        The Session Key Establishment phase may naturally use more message 
        passes.  
         
        If the host did not discover PAA's identity during the PAA Discovery 
        phase, it may initially send an Identity Request. (This Request may 
        alternatively trigger the PAA to initiate the Session Key 
        Establishment process going in the opposite direction, i.e. with PAA 
        acting as the EAP Authenticator.)  
         
        A PAA or host MAY re-authenticate the other party at any time, using 
        message exchange 3 or 4 (respectively) in the figure above.  
         
        It should be noted that some session key establishment algorithms do 
        not incorporate proof of freshness/liveliness of one or both 
        parties. If this is the case, the session key establishment 
        algorithm SHOULD be followed up by (re-) authentication. 
         
        3) PAA (re-) authenticates host  
         
           3a) PAA acts as an EAP authenticator and sends a challenge to the 
           host.  
            
           3b) The host responds to the challenge (e.g. by computing a MD-5 
           hash over the challenge), using the session key that was 
           established during the Session Key message exchange (above). 
         
        4) Host (re-) authenticates PAA  
      
     P. Engelstad              Expires July 2002                  [Page 5] 
                                  EAP over IP                February 2002 

           As in 3 above, but the roles of host and PAA are reversed. 
            
        EAPoIP Success and Failure messages have been omitted for 
        simplicity. 

     6 A simplified model of a "network-initiated" EAPoIP scheme 
         
        The following diagram shows a simplified model of the message 
        exchanges of an EAPoIP scheme where the network takes the 
        initiative: 

           Roaming host       Access Router/DHCP server         PAA 
               |                         |                       | 
               |                         |                       | 
               |                         |  1)Some trigger       | 
               |                         |---------------------->| 
               |                         |                       | 
           ....|.................................................|....... 
               |                                                 | 
               |          2a) Identity Request                   | 
               |<------------------------------------------------| 
               |          2b) Identity Response                  | 
               |------------------------------------------------>| 
               |                                                 | 
               |          2c) Session Key Establishment          |  AAA 
               |<----------------------------------------------->|<----->TTP 
               |                                                 | 
           ....|.................................................|....... 
            
        The PAA may be co-located with the Access Router or DHCP server.  
         
        This scheme assumes that the PAA receives some triggers indicating 
        arrival of a new host. PAA MAY for example be triggered by stateful 
        address configuration, e.g. the DHCP server signals to PAA that 
        there is a new host at the IP-address it has just handed out. 
         
        PAA will first reveal the identity of a host, by sending an EAPoIP 
        Identity Request, before continuing with the Session Key 
        Establishment. 

     7 Identity hiding 
         
        Some Session Key Establishment algorithms MAY help conceal the 
        host's identity. Identity hiding MAY alternatively be addressed by 
        other protocols, e.g. a host MAY use temporary user names and/or 
        temporary IP-addresses. The use of temporary IPv6 addresses is 
        specified in [5].  

     P. Engelstad              Expires July 2002                  [Page 6] 
                                  EAP over IP                February 2002 
      
     8 Additional Security Requirements 
          
        Since PPP EAP makes assumptions about the characteristics of the 
        underlying point-to-point link, a PPP EAP method cannot blindly be 
        substituted with its EAPoIP counterpart without taking security 
        threats into account.  
         
        EAP methods that are vulnerable to attacks likely on multi-access 
        links (including eavesdropping, address spoofing, replay attacks and 
        man-in-the-middle attacks) MUST NOT be used with EAPoIP. EAPoIP may 
        instead pose additional requirements to existing EAP methods. 
        Furthermore, EAPoIP-specific methods that are designed for multi-
        access environments MAY also be developed. 
         
        These issues should be addressed in follow-on documents. 

     9 Retransmission and timeout mechanisms 
         
        The EAPoIP protocol may require specific retransmission and timeout 
        mechanisms based the possibility of multi-access wireless subnets.  
         
        These mechanisms also depend on whether a user is expected to type 
        in a password with long latency and possibility of typos, or whether 
        a software or hardware module is expected to handle this part on 
        behalf of the user (i.e. user authentication versus device 
        authentication). 

     10 Security Considerations 
         
        An important issue is how to secure the EAPoIP protocol. 
         
        Authenticators and peers MAY validate their lower-layer identifiers, 
        such as IP- and MAC- addresses, in addition to their NAIs, during 
        either the initial session key establishment or during subsequent 
        (re-) authentication.  
         
        EAPoIP will then be better secured against address spoofing and man-
        in-the-middle attacks. It also facilitates use of address filtering 
        as one (of possibly many) means to enforce network access control.  

     IANA Considerations 
         
        IANA-assigned port numbers need be assigned to EAPoIP.  
         
     Acknowledgements 
         
        ... 
         
     References 

     P. Engelstad              Expires July 2002                  [Page 7] 
                                  EAP over IP                February 2002 
      
     [1]  Engelstad, P., "Discovery Mechanism for PANA Authentication 
           Agents (PAA-discovery)", <draft-engelstad-pana-paa-discovery-
           00.txt>, January 2002, Work in Progress.  
         
     [2]  Blunk, L. and Vollbrecht, J., "PPP Extensible Authentication 
           Protocol", RFC 2284, March 1998. 
         
     [3]  Blunk, L., Vollbrecht, J., and Aboba, B., "Extensible 
           Authentication Protocol (EAP)", <draft-ietf-pppext-rfc2284bis-
           01.txt> (RFC2284bis), November 2001, Work in Progress.  
         
     [4]  Aboba, B., Beadles, M. "The Network Access Identifier", RFC 2486, 
           January 1999. 
         
     [5]  Narten, T., and Draves, R., "Privacy Extensions for Stateless 
           Address Autoconfiguration in IPv6", RFC 3041, January 2001. 

     Authors' Addresses 
         
        Paal E. Engelstad 
        Telenor R&D (California) 
        399 Sherman Ave. Suite #12 
        Palo Alto, CA 94306, USA 
         
        Tel.: + 1-650- 714 7537 
        e-mail: [email-masked] 
      
     P. Engelstad              Expires July 2002                  [Page 8]

---

From: Jacques Caron <[email-masked]>
Date: Sun, 03 Feb 2002 00:06:25 +0100

Hi Paal,

At 22:49 02/02/2002, Paal Engelstad wrote:
>That's a good question. I can think of some PANA solutions where PAA 
>discovery would not be necessary and others where it will. Since the WG 
>Chairs have stressed that we need a solution soon, I think the sooner we 
>start discussing PAA discovery the better. The feasibility of different 
>discovery methods will also influence which PANA proposal to choose.

Can you give me a hint of a scenario that would require PAA discovery?

To be honest, the only scenario I really have completely in mind is public 
WLAN roaming, so you might find my comments a bit biased. I should try to 
re-read the scenarios draft, my first attempt did not make it through to my 
permanent storage :-(

>PAA is the initiator when it (re-)authenticates the roaming host. I am not 
>sure if the same goes when the host (re-) authenticates PAA, though...?

What's the purpose of a host authenticating the PAA? I think an 
authentication protocol that allows for mutual authentication (e.g. EAP 
SRP) should be enough, if it's to make sure you don't leave your data in 
the wrong hands (which shouldn't happen anyway: the auth protocol should 
not be susceptible to eavesdropping or man-in-the-middle attacks, and any 
further data that needs to be protected... should be protected using 
regular encryption methods (IPsec, SSH, TLS, whatever).

>Moreover, I think an authentication process going in one direction could 
>trigger the other authentication process going in the other direction. So 
>it is not evident to me who is going to start the authentication after the 
>discovery phase.
>
>Furthermore, before they start re-authenticating each other, they MAY 
>establish a session key (possibly supported by a AAA infrastructure). I am 
>not sure if the session key establishment process MUST be initated by PAA, 
>either... ???

I would tend to think that:
- the session key is the result of an EAP authentication anyway (like EAP SRP)
- you shouldn't need a key to protect the auth itself (see above)

So I'm not really confident there is a need for the session key request 
before the auth?

>I recently re-submitted the EAPoIP-draft (attached), which basically is 
>EAP over UDP. I discuss these scenarios in section 5 and 6. Hope you have 
>time to take a look at it and give your comments.

Looks very close to what I had in mind (EAP over UDP), though I would make 
it a lot simpler: EAPoIP would be initiated by the PAA (Request/Identity), 
upon detection of the presence of a new host, most probably triggered by 
the DHCP server, and that's about it.

My reasoning for wanting EAP over UDP was just as an interim measure until 
802.1x is widely implemented and supported: 802.1x often requires low-level 
integration (in drivers, firmware or OS, on both the infrastructure and 
client sides), whereas an EAP over UDP implementation would be (actually, 
is) very easy to port to any platform.

Personally, I still believe that the "good" way of doing authentication is 
to do it during the "bring up" phase of any protocol (as is the case with 
PPP, 802.1x, and probably over HTTP, though I haven't read the draft on the 
subject yet), rather than afterwards. Doing it "later on" has some security 
and generalization issues, so I really believe it should be considered as 
interim, but I'll go re-read the scenarios draft to see if there's a good 
reason to make that "permanent".

One essential reason for picking UDP over TCP is that EAP dictates 
retransmission requirements, and thus TCP may not be appropriate. IP and 
ICMP are not suitable because they often require the same low-level 
integration as 802.1x would (not as difficult, but raw IP handling is a lot 
less portable than UDP).

Jacques.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 7 Feb 2002 13:29:04 +0100

Paal, 

Thanks for your efforts, this is a good start of 
the analysis.
I'm not sure about b) though. I think that 
if you were to use anycast, it would need to be 
a separate message unless there is some sync
of states between PAA servers. 
Also for more on the concerns of using anycast
see Itojun's draft on the IPv6 page. 
Sorry I don't have it handy. 

Hesham

  > -----Original Message-----
  > From: Paal Engelstad [mailto:[email-masked]]
  > Sent: Wednesday, February 06, 2002 8:02 AM
  > To: Hesham Soliman "ERA"; James Kempf; George Tsirtsis;
  > [email-masked]
  > Subject: RE: Re: PAA Discovery
  > 
  > 
  > Hesham, James.
  > 
  > That is a good idea, Hesham. 
  > 
  > To push our discussion on this thread forward I have tried 
  > to make a brief summary of that draft. 
  > 
  > According to that draft, we have the following discovery mechanisms:
  > 
  > 1)Transport Mechanisms
  > 
  > a)Anycast discovery of PAAs
  > b)Anycasted authentication request
  > c)Multicasting, using local-/link- scope etc.
  > 
  > 2)Extensions to existing protocols
  > 
  > a)DHCP
  > b)RA
  > c)SLP
  > d)DNS
  > 
  > James did not only say we should not use extensions to RA. 
  > If I understood his comment correctly we should also 
  > refrain from developping protocol-specific mechanisms.  I 
  > expect this warning includes most of the transport 
  > mechansms. Did I understand you correctly, James?  
  > - Perhaps with exception of Anicasted Authentication request?
  > 
  > I am still concerned with the security aspects of the 
  > remaining alternatives; SLP, DNS, and DHCP. I assume that 
  > security aspects will be especially important criteria for PANA.
  > 
  > I think the assumptions that you referred to, Hesham, is 
  > the evaluation criterias. Right? In the PANA environment, I 
  > expect these to include:
  > 
  > - Security
  > - Time to deploy
  > - Standardization required
  > - Response times (and overhead)
  > - Scenarios (localization of PAA, interworking with 
  > mobility mechanisms, address filtering, etc.)
  > - Convergence times after failure
  > - Fate sharing
  > 
  > Are there more?
  > 
  > I assume most of the pros and cons in the DNS draft also 
  > applies to PANA.
  > 
  > Could this be a starting point for the discussion?
  > Comments?
  > 
  > Paal
  > 
  > > 
  > > Fra: "Hesham Soliman (ERA)" <[email-masked]>
  > > Dato: 2002/02/05 Tue AM 11:14:58 CET
  > > Til: Paal Engelstad <[email-masked]>, 
  > >    James Kempf
  > > 	 <[email-masked]>, 
  > >    George Tsirtsis <[email-masked]>,  
  > [email-masked]
  > > Tema: RE: Re: PAA Discovery
  > > 
  > > Folks, 
  > > 
  > > There is an analysis of several possible ways 
  > > of discovering the DNS and the pros and cons
  > > of each mechanism. You can find a WG draft on 
  > > the IPv6 WG web page.
  > > I suggest we read this at least and draft 
  > > some assumptions so we can discuss which 
  > > way is better. Arguing about solutions 
  > > without stating assumptions is pointless. 
  > > 
  > > BTW SLP was not the highest preference because
  > > it required multicast routing. The team was
  > > not sure whether this will be widely available
  > > given the IPv4 situation. 
  > > 
  > > Hesham
  > > 
  > >   > -----Original Message-----
  > >   > From: Paal Engelstad [mailto:[email-masked]]
  > >   > Sent: Saturday, February 02, 2002 9:08 PM
  > >   > To: James Kempf; George Tsirtsis; [email-masked]
  > >   > Subject: Re: Re: PAA Discovery
  > >   > 
  > >   > 
  > >   > James,
  > >   > 
  > >   > I appreciate your concern, and I agree with you. In 
  > my opinion:
  > >   > 
  > >   > 1) SLP: This is generally a sound and preferable protocol 
  > >   > for service discovery. The PANA protocol accommodates 
  > >   > authentication service, which should be discovered as such.
  > >   > 
  > >   > 2) DHCP: This is a good nr. 2. We should probably avoid 
  > >   > getting in a situation where all services are discovered by 
  > >   > DHCP. However, the Authentication Service IS special in 
  > >   > that it is one of the few services that unauthenticated 
  > >   > host will be granted access to.  The wide deployment of 
  > >   > DHCP may also be beneficial, considering that we are aiming 
  > >   > to have a solution ready shortly. 
  > >   > 
  > >   > 3) AR: We need good arguments to deviate from the 
  > >   > fundamental principle that ICMP is intended for error and 
  > >   > control messages related to routing. However, it turns out 
  > >   > that people are arguing for strong coupling between ICMP 
  > >   > and the PANA authentication service. Thus, I do not think 
  > >   > we should rule this option out before we have discussed 
  > >   > those proposals.
  > >   > 
  > >   > BUT:
  > >   > 
  > >   > 4) The PANA protocol should work well in both roaming and 
  > >   > fixed environments. In a fixed environment, I think SLP 
  > >   > might not be a bad choice, but I am not sure with respect 
  > >   > to a roaming environment:
  > >   > 
  > >   > a) Overhead and delay:
  > >   > 
  > >   > - First of all, SLP WILL require more messaging, bandwidth 
  > >   > and - most importantly - yield more delay, than for 
  > example DHCP.
  > >   > 
  > >   > b) Confidentiality of Network and Services:
  > >   > 
  > >   > - Un-authenticated hosts should not be able to discover 
  > >   > services on the network, apart from perhaps the PANA 
  > >   > authentication service. If SLP is to be used, it MUST be 
  > >   > able to securely distinguish between authenticated and 
  > >   > un-authenticated hosts. Do you think it would be a good 
  > >   > solution to require PAAs being co-located with SAs/DAs?Are 
  > >   > there other ways to solve this problem?
  > >   > 
  > >   > c) Denial-of-Service and other security attacks:
  > >   > 
  > >   > - Un-authenticated hosts should get as little access to the 
  > >   > network as possible to prevent them from consuming network 
  > >   > resources and launching DoS attacks. The more the access 
  > >   > network is opened, the more it will be exposed. Since there 
  > >   > is no way to secure SLP as far as UAs of roaming hosts are 
  > >   > concerned, would not SLP be easily exposed to DoS attacks? 
  > >   > I expect flooding attacks, malicious nodes posing as DAs, 
  > >   > and so forth, would be hard to prevent? (Moreover, allowing 
  > >   > un-authenticated hosts to multicast may also be ruled out 
  > >   > by the same argument...?)
  > >   > 
  > >   > Due to 1), I would like to add SLP into the draft, but I 
  > >   > have not yet had time to look into the problems in 4). 
  > >   > 
  > >   > Some directions - "directly from the horse's mouth" - on 
  > >   > how you see SLP being used in the PANA environment would be 
  > >   > more than welcome!!!
  > >   > 
  > >   > Paal
  > >   > 
  > >   > 
  > >   > > 
  > >   > > Fra: "James Kempf" <[email-masked]>
  > >   > > Dato: 2002/02/02 Sat AM 12:29:55 CET
  > >   > > Til: "George Tsirtsis" <[email-masked]>,  
  > >   > <[email-masked]>
  > >   > > Tema: Re: PAA Discovery
  > >   > > 
  > >   > > George,
  > >   > > 
  > >   > > There are 4 suggested mechanisms, two use DHCP, two 
  > use router
  > >   > > advertisements. It's the latter two
  > >   > > I am complaining about. Router advertisements are not the 
  > >   > place to put
  > >   > > service discovery information.
  > >   > > 
  > >   > >             jak
  > >   > > 
  > >   > > 
  > >   > > ----- Original Message -----
  > >   > > From: "George Tsirtsis" <[email-masked]>
  > >   > > To: "'James Kempf'" <[email-masked]>;
  > >   > > <[email-masked]>
  > >   > > Sent: Friday, February 01, 2002 2:53 PM
  > >   > > Subject: RE: PAA Discovery
  > >   > > 
  > >   > > 
  > >   > > > James,
  > >   > > >
  > >   > > > Did you look at Paal's draft at all? He is 
  > actually discussing a
  > >   > > couple of
  > >   > > > ways including one based on DHCP....but as he says he 
  > >   > is missing SLP
  > >   > > which
  > >   > > > may also be considered.
  > >   > > >
  > >   > > > I think you are correct about the fact that there is no 
  > >   > need for yet
  > >   > > another
  > >   > > > protocol ...an extension of something that already 
  > >   > exists should do
  > >   > > the
  > >   > > > trick, I also think Paal will agree with this statement 
  > >   > since his
  > >   > > draft does
  > >   > > > not discuss any "new" approaches...just extensions.
  > >   > > >
  > >   > > > George
  > >   > > > -----Original Message-----
  > >   > > > From: James Kempf [mailto:[email-masked]]
  > >   > > > Sent: Friday, February 01, 2002 10:12 PM
  > >   > > > To: Paal Engelstad; [email-masked]
  > >   > > > Subject: Re: PAA Discovery
  > >   > > >
  > >   > > >
  > >   > > > IP-addresses of PAAs. It is a lightweight and 
  > straightforeward
  > >   > > solution
  > >   > > > > There are naturally other alternatives:
  > >   > > > > More heavyweight discovery: SLP
  > >   > > >
  > >   > > > I'll dispute this assertion. The SLP implementers group 
  > >   > is currently
  > >   > > > working to take SLP to draft standard and has 
  > >   > eliminated a number of
  > >   > > > mechanisms that were either not implemented or were 
  > >   > deemed to be too
  > >   > > > heavyweight.
  > >   > > > Check draft-guttman-rfc2608bis-01.txt.
  > >   > > >
  > >   > > > Furthermore, I would like to argue strongly against a 
  > >   > "roll your own"
  > >   > > > discovery technique approach. If you
  > >   > > > don't like SLP try:
  > >   > > >
  > >   > > > 1) DHCP
  > >   > > >
  > >   > > > 2) DNS/mDNS
  > >   > > >
  > >   > > > 3) LDAP
  > >   > > >
  > >   > > > Unless you are talking about something like 
  > routing, there is
  > >   > > absolutely
  > >   > > > no reason to come up with
  > >   > > > a new discovery technique. I've spent the last two 
  > >   > years going around
  > >   > > to
  > >   > > > working groups who
  > >   > > > argue that their protocol is so "different" and 
  > >   > "unique" that they
  > >   > > must
  > >   > > > invent a new discovery protocol.
  > >   > > > The problem with this is that it is another special, 
  > >   > one off discovery
  > >   > > > protocol that must be administered
  > >   > > > Not only that, but somebody has to implement the tools 
  > >   > to administer
  > >   > > the
  > >   > > > discovery protocol. Imagine what it would be like if 
  > >   > every WG decided
  > >   > > > they wanted to implement their own transport protocol, 
  > >   > or name service
  > >   > > > protocol, or <pick a currently used protocol for 
  > a standard
  > >   > > architecural
  > >   > > > element>. Unfortunately, the IAB/IESG hasn't yet seen
  > >   > > > fit to try to enforce architectural consistency on 
  > >   > service discovery,
  > >   > > > since it is in some sense, not
  > >   > > > perceived as a serious enough problem. But for the 
  > >   > people who have to
  > >   > > > implement the tools and
  > >   > > > administer it, it sure enough is.
  > >   > > >
  > >   > > > We don't need a special purpose discovery protocol for 
  > >   > PANA, let's
  > >   > > just
  > >   > > > figure out what the right existing protocol is and how 
  > >   > to use that.
  > >   > > >
  > >   > > >                 jak
  > >   > > >
  > >   > > >
  > >   > > >
  > >   > > 
  > >   > > 
  > >   > 
  > > 
  > > 
  >

---

From: Paal Engelstad <[email-masked]>
Date: Thu, 7 Feb 2002 20:32:48 +0100

I know of the Itojun-draft. Actually I refer to its content in the PAA Discovery draft and argue that that approach have some problems.

Another problem with anycast is it provides only an IP address of PAA. It would be desireable also to provide the higher layer identifier (NAI, FQDN).

If the PaC knows also the PAA FQDN, the PANA protocol in total will probably perform better performance.

Thanks,
Paal

> Dato: 2002/02/07 Thu PM 01:29:04 CET
>    "Hesham Soliman \"ERA\""
> 	 <[email-masked]>, 
>    James Kempf <[email-masked]>, 
>    George Tsirtsis <[email-masked]>,  [email-masked]

---

From: Paal Engelstad <[email-masked]>
Date: Wed, 13 Feb 2002 23:35:39 +0100

Corrections, James,

Replace "site-scoped" with "link-scoped" in some of the sentences below. (See comments.)

Paal

> 
> Fra: Paal Engelstad <[email-masked]>
> Dato: 2002/02/13 Wed PM 11:12:22 CET
> Til: "James Kempf" <[email-masked]>, 
>    "Hesham Soliman \"ERA\"" <[email-masked]>, 
>    "George Tsirtsis" <[email-masked]>,  <[email-masked]>
> Tema: Re: Re: PAA Discovery
> 
> > 
> > Sorry, what I meant was, that I agreed it was too
> > early to say.
> > 
> > Perhaps we need to have a discussion about the
> > benefits and drawbacks of various mechanisms.
> 
> Definitely. However, I hope we do not need to form an PAA discovery design team (like for DNS discovery).
> 
> Rather, I hope we are able to temporarily dismiss some proposals early in the process and focus on a few alternatives.
> 
> Just from the top of my head, it could be simple statements like this:
> 
> - Anycast request seems superior to anycast discovery - let's focus on anycast request first.
> - Site-scoped multicast seems like a bad choice. It opens the access network, and there might be a tradeoff between message overhead and latency. Let's focus on site-scoped multicast first.

=> Of, course I meant "link-scoped" in the last sentence above, and in the sentences below.

> - Site-scoped multicast with router-assist seems inferior to site-scoped multicast with router-only replies in the PANA case. Let's focus on the latter first.
> - Router Advertisement seems like a good alternative wrt security. Un-authenticated PaCs does not get more information than required. Tuning the system wrt solicitations and periodic advertisements seems like a good way to deal with DoS. If we also gets an ICMP based solution with PAA located on AR, this could be an interesting option. Let's take a closer look at it.
> - SLP, DNS and DHCP all opens the network to un-authenticated hosts - perhaps too much. However, some will use DHCP anyway to allocate addresses to un-authenticated nodes. Let's take a closer look at DHCP. (Let's alternatively take a look at SLP later.)
> 
> If we can do such a rudimentary analysis first, we could end up studying only the alternatives that seems most interesting.
> 
> With my example above, we would end up with analysing only:
> - DHCP (IPv4 and IPv6)
> - Router Adverisement (IPv4 and IPv6)
> - Anycasted request (IPv6)
> 
> (which actually reflects the status of our PAA discussions so far.)
> 
> Then we could add new protocols to the analysis later.
> 
> My intention is not having to go through a too tedious process. Hopefully we will end up with a PANA protocol that gives some flexibility wrt discovery.
> 
> Comments?
> Paal
> 
> 
> 
>  
> >             jak
> > 
> > From: "Paal Engelstad" <[email-masked]>
> > To: "James Kempf" <[email-masked]>; "Hesham Soliman "ERA""
> > <[email-masked]>; "Paal Engelstad"
> > <[email-masked]>; "George Tsirtsis" <[email-masked]>;
> > Sent: Wednesday, February 13, 2002 11:32 AM
> > > Hesham, James,
> > > I disagree, and think you might be jumping to conclusions.
> > >
> > > Comments below.
> > >
> > > Paal
> > >
> > > >
> > > > Dato: 2002/02/13 Wed PM 05:52:52 CET
> > > > Til: "Hesham Soliman \(ERA\)" <[email-masked]>,
> > > >    "Paal Engelstad" <[email-masked]>,
> > > >    "George Tsirtsis" <[email-masked]>,
> > > > Tema: Re: Re: PAA Discovery
> > > >
> > > >
> > > > >   > Are you proposing anycasting the PANA message itself or the
> > > > >   > discovery
> > > > >   > request? If the former, I have no
> > > > >   > objections, in fact, it looks like an interesting use of
> > anycast.
> > > > >
> > > > > => It's too early to tell. We have to first
> > > > > look at the final solution, see what security
> > > > > assumptions it makes about the request, what
> > > > > transport layer is being used ...etc
> > > > > When we have that we can see whether anycast
> > > > > fits in or not.
> > > > >
> > > > > Th idea of anycasting the request is nice for
> > > > > something like a DNS request, but when state
> > > > > is kept, this is a different issue.
> > > > >
> > > >
> > > > Agree!
> > > >
> > >
> > > I think you might be jumping to conclusions, - it's way too early to
> > dismiss anycast as a discovery mechanism!
> > >
> > > Your argument is based on the general opinion that anycast does not go
> > well together with stateless communication. (I agree to that.)
> > >
> > > That is fine, but concider for example an EAP-based PANA protocol: In
> > the anycast case, (and in the PaC initated version) it would probably
> > start with a PaC anycasting an Identity Request. The PAA returns an
> > Idenity Response containing the NAI of the PAA. The PaC reads the
> > IP-address from the IP-header (or we allow it to be incorporated into
> > the Identity Response payload to avoid/reduce layering violation).
> > >
> > > At this point of time, it does not need to be any state established by
> > the PAA. (I would expect rather the opposite: we would try to avoid it
> > due to the DoS threat.)
> > >
> > > The client would then continue with the stateful authentication method
> > towards the PAA.
> > >
> > > Hesham and James, please explain to me why this is a bad discovery
> > mechanism that we should dismiss right away. My problem is, I cannot see
> > where your "stateful communcation" argument fits into the scenario I
> > discribed above.
> > >
> > > Paal
> > >
> > >
> > > >             jak
> > > >
> > > >
> > >
> > >
> > 
> > 
> 
>

---

From: Paal Engelstad <[email-masked]>
Date: Thu, 14 Feb 2002 0:09:46 +0100

George, James,

>  As I have previously said, I don't think Router Advertisements are the
> right place for this.

Fine with me. I would like to hear George's opinion on this first, however.

Paal

> 
> For the rest,  I think they should be examined.
> 
>         jak
> 
> <[email-masked]>; "George Tsirtsis"
> <[email-masked]>; <[email-masked]>
> Sent: Wednesday, February 13, 2002 2:12 PM
> > Rather, I hope we are able to temporarily dismiss some proposals early
> in the process and focus on a few alternatives.
> >
> > - Site-scoped multicast seems like a bad choice. It opens the access
> network, and there might be a tradeoff between message overhead and
> latency. Let's focus on site-scoped multicast first.
> > - Site-scoped multicast with router-assist seems inferior to
> site-scoped multicast with router-only replies in the PANA case. Let's
> focus on the latter first.
> > - Router Advertisement seems like a good alternative wrt security.
> Un-authenticated PaCs does not get more information than required.
> Tuning the system wrt solicitations and periodic advertisements seems
> like a good way to deal with DoS. If we also gets an ICMP based solution
> with PAA located on AR, this could be an interesting option. Let's take
> a closer look at it.
> > - SLP, DNS and DHCP all opens the network to un-authenticated hosts -
> perhaps too much. However, some will use DHCP anyway to allocate
> addresses to un-authenticated nodes. Let's take a closer look at DHCP.
> (Let's alternatively take a look at SLP later.)
> >
> > If we can do such a rudimentary analysis first, we could end up
> studying only the alternatives that seems most interesting.
> >
> > My intention is not having to go through a too tedious process.
> Hopefully we will end up with a PANA protocol that gives some
> flexibility wrt discovery.
> >
> > Comments?
> > Paal
> >
> >
> >
> >
> > >             jak
> > >