Subject: RE: EAP over ICMP

From: George Tsirtsis <[email-masked]>
Date: Tue, 8 Jan 2002 05:14:24 -0500

James,

I understand but then it looks like a hack to me...You use a messages with
specific functions (RS/RA) just because they are their...If the PANA
protocol required messages exactly at the same instance with RS/RAs then
maybe it would have been possible but this is not the case. One EAP session
may require 5-6 messages back and forth...using RS/RAs to carry these
messages maybe be slightly convenient but it also kind of ugly and a bit of
a hack. 

Also, and this is more important, SNARD can not deal with the authenticator
being anything other than the Access Router since a server in the network
can not receive RS or send RAs.

I discussed this with Alper in SLC. I actually liked SNARD initially due to
its simplicity and I was happy to see someone suggesting something concrete
rather than having discussions in the air; Still I quickly identified its
limitations and I think Alper understood although he also reserved the right
to disagree  again later :-) 

I hope you guys see it too and we can move on. EAP over ICMP has the
simplicity and efficiency of SNARD since it is also based on ICMP but it
does not depend on other ICMP messages and can run between the end node and
an authenticator in the AR or behind it.

Regards
George
P.S: BTW, Carl, I actually never advocated ND for PANA in the e-mail you
attached on an earlier message of yours was attempting to argue about where
different work belonged in the IETF (ND work in IPv6 WG, new transport for
authentication in PANA WG). In fact I was supporting the idea of PANA being
implemented with DHCP messages (I presented this in the BURP BOF) until I
realized very similar limitations with that of SNARD...

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: Monday, January 07, 2002 7:27 PM
To: George Tsirtsis; 'Carl Williams'; Pana (E-mail)
Subject: Re: EAP over ICMP 

George,

I believe the idea in SNARD is that a challenge can be issued at any
time by sending out another RA. Sending
an RS can be used by the host to challenge the router.

            jak

----- Original Message -----
From: "George Tsirtsis" <[email-masked]>
To: "'Carl Williams'" <[email-masked]>; "George Tsirtsis"
<[email-masked]>; "Pana (E-mail)" <[email-masked]>
Sent: Monday, January 07, 2002 2:06 AM
Subject: RE: EAP over ICMP

> Hi Carl,
>
> First of all I thought SNARD also used ICMP (Router adverts and
> solicitations)! The only difference is that I do not like the idea of
> piggybacking the PANA protocol on RS/RAs. The reason is that an
> authentication challenge should be possible to be sent at any time
from any
> of the parties involved and as many time as the specific
authentication
> protocol requires...
>
> Note that SNARD has not demonstrated that EAP can be carried over it,
and
> EAP seems to be gaining support in this area.
>
> On the other hand I do not like the idea of running PANA over UDP/TCP
either
> due to the overhead involved. Straight forward ICMP seems to me to be
> ideal...
>
> George
>
> -----Original Message-----
> From: Carl Williams [mailto:[email-masked]]
> Sent: Saturday, January 05, 2002 1:08 AM
> To: George Tsirtsis; Pana (E-mail)
> Subject: Re: EAP over ICMP
>
>
>
> Hi George,
>
>      I have take a quick look at your draft.
>
>     You don't explain why ICMP was choose as the
>     carrier (vs other methods such as the one SNARD uses).
>
>     I consider ICMP for control - allowing one to troubleshoot
>     networks and other related uses.
>
>    You might provide that with your design choice analysis.
>
>
>    Carl
>
> ----- Original Message -----
> From: "George Tsirtsis" <[email-masked]>
> To: "Pana (E-mail)" <[email-masked]>
> Sent: Friday, January 04, 2002 4:49 PM
> Subject: EAP over ICMP
>
>
> > Hi all,
> >
> > Here is a draft that reflects some of the discussion in SLK meeting
and
> > proposes a solution to the PANA problem. This will also appear on
the IETF
> > directory as normal in a few days...
> >
> > Let me know what you think
> >
> > Thanks
> > George
> >
>
> ----------------------------------------------------------------------
-
> > Personal                                                    G.
Tsirtsis
> >                                                    Flarion
Technologies
> > Internet Draft
> > Title:draft-ietf-tsirtsis-eap-over-icmp-00.txt
> > Category: Informational                                    January
2002
> > Expires : June 2002
> >
> >
> >                                 EAP over ICMP
> >                   <draft-ietf-tsirtsis-eap-over-icmp-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.
> >
> >    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.
> >
> >
> > Copyright Notice
> >
> >    Copyright (C) The Internet Society (2001).  All Rights Reserved.
> >
> >
> >
> > Abstract
> >
> >    This specification describes a way to carry the Extensible
> >    Authentication Protocol (EAP) over the Internet Control Message
> >    Protocol (ICMP). This provides a generic mechanism for
user/device
> >    authentication to access routers or other designated nodes.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Tsirtsis
1
> > Internet Draft              EAP over ICMP                January
2002
> >    INDEX
> >    1. Introduction
3
> >
> >       1.1. Why don't we just use 802.1X?
> >
> >       1.2. Solution overview and scope
> >
> >    2. EAP over ICMP Message definition
4
> >
> >    3. Guidelines to implementation
5
> >
> >       3.1 IP addresses
> >
> >       3.2 Usage and guidelines
> >
> >       3.3. Broadcast-unicast
> >
> >    4. Security Considerations
6
> >    5. IANA Considerations
6
> >    6. Acknowledgements
7
> >    7. References
7
> > Tsirtsis
2
> > Internet Draft              EAP over ICMP                January
2002
> >
> >
> >
> > 1. Introduction
> >
> >    End nodes are connected to the Internet either in an
unauthenticated
> >    or in an authenticated way. Typically, authenticated nodes
connect
> >    to the Internet via PPP, which includes a number of
authentication
> >    mechanisms and more recently EAP. With wireless and other
always-on
> >    services now available, PPP is not always the default way of
> >    providing connectivity to end nodes and other alternatives for
> >    authentication are being developed.
> >
> >
> > 1.1. Why don't we just use 802.1X?
> >
> >    Some link layers (e.g.: 802 family) now provide their own
> >    authentication mechanisms implemented with EAP (e.g.: 802.1X).
This
> >    is becoming increasingly popular but is not adequate in a number
of
> >    deployment scenarios. For illustration take the case of an 802.11
> >    based network connected to Internet Access Routers (IAR) via an
> >    Ethernet infrastructure. One may want to allow end nodes to gain
> >    connectivity via such infrastructure without the use of PPP and
yet
> >    end node authentication may still be required. The use of
something
> >    like 802.1X in this case is not adequate since this will only
> >    authenticate the end node/user to the 802.11 Access Points to
which
> >    it associates, which may be multiple link layer hops away from
the
> >    first Internet Access Router. Even worse, consider this same link
> >    layer infrastructure providing access to multiple Internet
Service
> >    Providers (Figure 1). Link Layer authentication in this case is
> >    clearly inadequate when it comes to gaining access to one ISP
over
> >    the other.
> >
> >       End <===EAPwith802.1x==>
> >       Node  ------------------X---X---X---X---IAR---ISP1
> >                        Multi-hop L2   |
> >                                       +---X---IAR---ISP2
> >
> >    IAR = Internet Access Router
> >    ISP = Internet Service Provider
> >    X   = Link Layer device (e.g.: access point, switch)
> >
> >        Figure 1: Link Layer authentication example
> >
> >
> >
> > 1.2. Solution overview and scope
> >
> >
> >
> >    It is clear that an IP based mechanism (Figure 2) is required to
> >    allow the end node to authenticate itself to the Internet Access
> >    Router of its choice, irrespective of the underlying link layer
> >    infrastructure which may or may not require its own
authentication.
> > Tsirtsis
3
> > Internet Draft              EAP over ICMP                January
2002
> >
> >
> >
> >       End <==========EAPoverICMP============>
> >       Node  -----------------X---X---X---X---IAR---ISP1
> >                       Multi-hop L2   |
> >                                      +---X---IAR---ISP2
> >
> >        Figure 2: Network Layer authentication example
> >
> >    Furthermore, another type of authentication is also required that
> >    takes place between the end node and a designated node beyond the
> >    Internet Access Router but very likely before a firewall (Figure
3).
> >    This is typically useful in the context of access to the Internet
> >    via a Hotel or other such service.
> >
> >
> >
> >           <=====EAPoverICMP========>
> >       End -------------------IAR----AuthServer---Firewall--Internet
> >       Node
> >
> >        Figure 3: Authentication beyond the IAR example
> >
> >    - EAP allows the authenticator to use a back end system to assist
> >    with the authentication. The details of such a mechanism are out
of
> >    scope for this document.
> >
> >    - Some interaction between the IAR or the Auth. Server and a
> >    firewall function is likely required for the policing of the
> >    authentication. The details of such a mechanism are also out of
> >    scope for this document.
> >
> >    - EAP can perform authentication of users as well as devices, no
> >    restrictions are imposed to that effect by this specification.
> >
> >    - EAP can be used to implement a number of different
authentication,
> >    and key exchange mechanisms. The details of such mechanisms are
> >    outside the scope of this document.
> >
> >
> >
> > 2. EAP over ICMP Message definition
> >
> >
> >    ICMPv4/v6 EAP Message
> >
> >    ICMPv4 and ICMPv6 protocols employ the same message structure and
> >    thus the message definition below is applicable to both
protocols.
> > Tsirtsis
4
> > Internet Draft              EAP over ICMP                January
2002
> >
> >
> >
> >        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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |     Type      |     Code      |           Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       |           EAP Header        ~
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> >    IP Fields:
> >
> >    Source Address
> >
> >       The address of the node that composes the ICMP message
> >
> >    Destination Address
> >
> >       The address of the node to which this message should be sent
> >
> >    ICMP Fields:
> >
> >    Type
> >
> >       TBA
> >
> >    Code
> >
> >       0
> >
> >    Checksum
> >
> >       The checksum is the 16-bit ones's complement of the one's
> >       complement sum of the ICMP message starting with the ICMP
Type.
> >       For computing the checksum, the checksum field should be zero.
> >       This checksum may be replaced in the future.
> >
> >
> >     EAP Header
> >
> >       As defined in [RFC2284bis]
> >
> >
> > 3. Guidelines to implementation
> >
> > 3.1 IP addresses
> >
> >    Depending on the deployment model, the end node involved in the
> >    authentication may or may not have a valid global IP address
during
> >    the time this protocol is used. In this case a zero or a valid
link
> >    local address may be used as source address in which case only
> >    authentication with the IAR is possible.
> >
> >
> > Tsirtsis
5
> > Internet Draft              EAP over ICMP                January
2002
> >
> >
> >    Authentication with an Authentication Server can only take place
> >    after the end node has a network address that is routable from
that
> >    server. This could be a global address or a site local address if
> >    appropriate. Details on how this address may be acquired are
outside
> >    the scope of this document and are IP version specific.
> >
> > 3.2 Usage and guidelines
> >
> >    End nodes should quote unique identifiers that can be
authenticated
> >    against. The Network Address Identifier (NAI) is ideal for this
> >    purpose since it provides maximum flexibility for the location of
> >    the node's authentication records in a multi-provider roaming
> >    environment. Still other identifiers may also be used according
to
> >    the application in question (IMSIs, user names, phone numbers,
etc).
> >    A number of draft proposals are already describing various
> >    authentication mechanisms implemented with EAP; such proposals
also
> >    include details of the type of identifier to be used.
> >
> >
> > 3.3. Broadcast-unicast
> >
> >    If the end node does not know the address of the Access Router
with
> >    which it should authenticate, an ICMP-EAP message may be sent to
the
> >    subnet broadcast address or the all routers multicast address
> >    according to IPv4 and IPv6 rules.
> >
> >    If the Authenticator does not know the IP address of the end node
> >    but knows its link layer address, an ICMP-EAP message may be sent
to
> >    the all nodes on link network address while the IP packet can be
> >    encapsulated in a link layer frame with the unicast link layer
> >    address of that node as destination address.
> >
> >
> >
> > 4. Security Considerations
> >
> >    This specification describes a way of carrying EAP over ICMP
> >    messages. All the EAP related security considerations described
in
> >    RFC2284bis are also applicable here.
> >
> >    QUESTION: Are there any more security issues relevant the
specific
> >    environment we are looking at here?
> >
> >
> > 5. IANA Considerations
> >
> >    A Type value for both ICMPv4 and ICMPv6 is required to be
assigned
> >    for EAP.
> > Tsirtsis
6
> > Internet Draft              EAP over ICMP                January
2002
> >
> >
> >
> > 6. Acknowledgements
> >
> >    The subject of this draft has been discussed at length with my
> >    colleagues Alan O'Neill, Scott Corson, Vincent Park and Matt
Impett
> >    from Flarion Technologies.
> >
> > 7. References
> >
> >    [RFC2284bis], L. Blunk et.al, Extensible Authentication Protocol
> >    (EAP), <draft-ietf-pppext-rfc2284bis-01.txt> November 2001, Work
in
> >    Progress.
> >
> >    [ICMPv6], A. Conta, S. Deering, Internet Control Message Protocol
> >    (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification,
> >    draft-ietf-ipngwg-icmp-v3-02.txt, November 2001, Work in progress
> >
> >    [ICMPv4], J. Postel, Internet Control Message Protocol, RFC792,
> >    September 1991
> >
> >
> >
> >
> > Author's Address
> >
> >       George Tsirtsis
> >       Flarion Technologies
> >       +44 (0)20 88260073
> >       [email-masked]
> >       [email-masked]
> >
> >
> > Copyright Notice
> >
> >    Full Copyright Statement
> >
> >    Copyright (C) The Internet Society (2001).  All Rights Reserved.
> >    This document and translations of it may be copied and furnished
to
> >    others, and derivative works that comment on or otherwise explain
it
> >    or assist in its implementation may be prepared, copied,
published
> >    and distributed, in whole or in part, without restriction of any
> >    kind, provided that the above copyright notice and this paragraph
> >    are included on all such copies and derivative works.  However,
this
> >    document itself may not be modified in any way, such as by
removing
> >    the copyright notice or references to the Internet Society or
other
> >    Internet organizations, except as needed for the purpose of
> >    developing Internet standards in which case the procedures for
> >    copyrights defined in the Internet Standards process must be
> >    followed, or as required to translate it into languages other tha
n
> >    English.  The limited permissions granted above are perpetual and
> >    will not be revoked by the Internet Society or its successors or
> >    assigns.  This document and the information contained herein is
> >
> >
> > Tsirtsis
7
> > Internet Draft              EAP over ICMP                January
2002
> >
> >
> >    provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
> >    INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS
OR
> >    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
OF
> >    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED
> >    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE."
> > Tsirtsis
8

---

From: "James Kempf" <[email-masked]>
Date: Tue, 8 Jan 2002 08:55:03 -0800

George,

Re. reusing RA/RS, one could look at it as a hack, or as a way to save
bandwidth on the radio connection by reusing
an existing message.

I agree with your comment about requiring
5-6 messages, this must be accommodated.
But does broadening out the container
to an as yet undefined ICMP message
help here? It seems you still need to define
how that transaction will occur, and I don't
believe you are proposing that it be done
over ICMP are you?

With respect to having an arbitrary server
do the authentication, I actually think this
is less important than your point about
making sure the EAP transaction can be
accommodated. The router can backend
into a server, and I would expect that
it would do that with something like
a Radius server anyway. Is anybody
on the list familiar enough with current
practice to comment whether current
NAS products typically combine router function
and Radius, or are they typically separated?

        jak

----- Original Message -----
From: "George Tsirtsis" <[email-masked]>
To: "'James Kempf'" <[email-masked]>; "George Tsirtsis"
<[email-masked]>; "'Carl Williams'" <[email-masked]>;
"Pana (E-mail)" <[email-masked]>
Sent: Tuesday, January 08, 2002 2:14 AM
Subject: RE: EAP over ICMP

> > >        0                   1                   2
3

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 8 Jan 2002 09:37:56 -0800 (PST)

> and Radius, or are they typically separated?

A NAS usually has very limited router funcionality
compared to a "real router" and does not implement
Radius Server funcionalities (it usually has a Radius
Client/Proxy).

As a real-world comment (I already said this on the
meeting), ICMP router discovery comes disabled by
default on every single router/NAS that I know of.
Some knew router vendors actually do not even
implement it. It is considered a security leak. All
router "discovery" on backbones are done trough manual
configuration. 

Actually some protocols like OSPF have their own
"discovery" based on well-known multicast addresses.

Moreover, windows (desktop) does not implement ICMP
router discovery. If we are trying to "investigate
protocols already established or that we might think
are going to be ubiquitous", ICMP RA is not the way to
go.

my 2 cents.

thanks,

Reinaldo

> > I understand but then it looks like a hack to
> me...You use a messages
> with
> > protocol required messages exactly at the same
> instance with RS/RAs
> then
> > maybe it would have been possible but this is not
> the case. One EAP
> session
> > messages maybe be slightly convenient but it also
> kind of ugly and a
> bit of
> > a hack.
> >
> > Also, and this is more important, SNARD can not
> deal with the
> authenticator
> > being anything other than the Access Router since
> a server in the
> network
> > I discussed this with Alper in SLC. I actually
> liked SNARD initially
> due to
> > its simplicity and I was happy to see someone
> suggesting something
> concrete
> > rather than having discussions in the air; Still I
> quickly identified
> its
> > limitations and I think Alper understood although
> he also reserved the
> right
> > simplicity and efficiency of SNARD since it is
> also based on ICMP but
> it
> > does not depend on other ICMP messages and can run
> between the end
> node and
> > P.S: BTW, Carl, I actually never advocated ND for
> PANA in the e-mail
> you
> > attached on an earlier message of yours was
> attempting to argue about
> where
> > different work belonged in the IETF (ND work in
> IPv6 WG, new transport
> for
> > authentication in PANA WG). In fact I was
> supporting the idea of PANA
> being
> > implemented with DHCP messages (I presented this
> in the BURP BOF)
> until I
> > > solicitations)! The only difference is that I do
> not like the idea
> of
> > > Note that SNARD has not demonstrated that EAP
> can be carried over
> it,
> > and
> > > On the other hand I do not like the idea of
> running PANA over
> UDP/TCP
> > either
> > > due to the overhead involved. Straight forward
> ICMP seems to me to
> be
> > > ideal...
> > >
> > > George
> > >
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

---

From: "James Kempf" <[email-masked]>
Date: Tue, 8 Jan 2002 10:14:22 -0800

Reinaldo,

Thanks for your comments.

> router "discovery" on backbones are done trough manual

One of the difficulties here is that there are security problems with
multi-link ARP and IPv6 neighbor discovery
that have not been dealt with (see 
draft-kempf-ipng-netaccess-threats-00.txt
for a list so far for IPv6). Unless these
threats are dealt with, I don't see people using
IPv6 neighbor discovery and thus router
discovery on multi-access links for public
access networks. Thus, I think most public
access networks, even those with multi-access
links like 802.11, are likely to configure
the link as a point to point link. While this
does not necessarily mean PPP will always
be used, as a practical matter, it probably
will be, despite the ugliness of running
PPP over Ethernet. 

> are going to be ubiquitous", ICMP RA is not the way to

Well, this brings up a pretty basic philosophical question
(this is meant to be somewhat provocative).
If security problems are going to require that people
configure their public last hop links as point to point links
regardless of whether they have multi-access capability
or not, what is the point of:

    - PANA
    - spending lots of time in the MIP group trying to
    accommodate stateful and stateless address 
    autoconfiguration for IPv6

We should just figure out a way to do PPP context
transfer for MIP handover and rely on EAP over
PPP for authentication.

            jak

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 8 Jan 2002 14:21:43 -0500

> are going to be ubiquitous", ICMP RA is not the way to

Are you sure?  

I am not advocating ICMP router discovery, but I found some statement
that Windows 2000 supports ICMP router discovery.  (see
http://www.softheap.com/internet/icmp-router-discovery.html)

Yoshihiro Ohba

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 8 Jan 2002 16:09:43 -0800 (PST)

You are right. I should not be so general. Windows
2000 server supports ICMP router discovery.

regards,

Reinaldo

> > > > specific functions (RS/RA) just because they
> are
> > > their...If the PANA
> > > > may require 5-6 messages back and
> forth...using
> > > RS/RAs to carry these
> > > > I hope you guys see it too and we can move on.
> EAP
> > > over ICMP has the
> > > > I believe the idea in SNARD is that a
> challenge
> > > can be issued at any
> > > > To: "'Carl Williams'"
> <[email-masked]>;
> > > "George Tsirtsis"
> > > > > piggybacking the PANA protocol on RS/RAs.
> The
> > > reason is that an
> > > > > authentication challenge should be possible
> to
> > > be sent at any time
> > > > from any
> > > > > of the parties involved and as many time as
> the
> > > specific
> > > > authentication
> > > > > protocol requires...
>

---

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

Hi Reinaldo,

> "discovery" based on well-known multicast addresses.

The router discovery (RS/RA) as specified in rfc2461, rfc1256
deals with "hosts" discovering "routers" on the same link. It sounds
like you are talking about "routers" discovering other "routers"?

> are going to be ubiquitous", ICMP RA is not the way to

This sounds really scary. This is a show-stopper for 
a number of mobility related protocols. For example
Mobile IPv4 relies on agent advertisements which are
carried by router advertisements. If RD is not used, we need
another discovery protocol (dhcp??) as we cannot pre-configure
default routers when the client is mobile. Also the dynamic
address autoconf of IPv6 does down the drain as well...

> Reinaldo

Regards,

alper

---

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

Hi George,

> specific functions (RS/RA) just because they are their...

Of course not :) ... Please see the section 4 of the draft. Router discovery
(RD) is a semantically fit choice, as for a PANA protocol, we are interested
in clients gaining IP connectivity. Client needs inbound and outbound IP
forwarding.
This is done by client knowing its onlink routers, and routers providing
this
service. And one way to do this is RD. We are authenticating this RD
exchange,
which is currently used unauthenticated. It seemed so natural for us to use
it as a carrier. We have more reasons listed in that section.

> If the PANA

The WG hasn't really decided that PANA will carry EAP, and EAP only. We have
also worked out the authentication (the payload of ) PANA (which is not
in the version 00 of SNARD), and all it requires is one round-trip between
the client and the PANA agent. Of course if a single authentication requires
several back-and-forth messaging between two entities, then RD doesn't look
as attractive.

> can not receive RS or send RAs.

Yes, but is this a problem? I don't think the current form of EAPoverICMP
does that either. The destination of EAPoverICMP packets needs to be
worked out for this..

> to disagree  again later :-)

I think I'll use my rights now :) I thought you only had issues with
re-authentication,
and was suggesting using a new message for that. Even for that I wasn't
really convinced to invent a new format, as you remember.

> an authenticator in the AR or behind it.

George, I think first you need to define how EAPoverICMP can deal with an
authenticator behind the ARs. What would be the destination address of the
request packets, and a discovery protocol might be needed for that.

Also, although it sounds like maybe a good flexibility to have the
authenticator
anywhere, to me having it on the AR is the right choice.

Thanks George,

alper