Subject: Re: one or two protocols: The PANA recipe?

From: Paal Engelstad <[email-masked]>
Date: Fri, 8 Feb 2002 19:59:27 +0100

George,

IP architectural principles are about religion (at least for me). We may argue for ages. I therefore appreciate that you take this pragmatic approach. Let's get the job done.

So religion aside, I think you make some very good points here. It might be more efficient to run it on the IP layer, which might be vital for the part of the PANA group focusing on high performance mobility (3G etc).

However, there is a group of people arguing for an application layer solution. There are tradeoffs, and one is not necessarily better than the other.

Thus, I think your idea of going forward with two PANA carriers modules could good be a good solution to end the application layer vs. IP-layer discussion. PANA (or market demands) may decide later.

Now, if the two PANA carriers, EAPoUDP and EAP-over-ICMP were complicated, two protocols would not be desireable. But both are straightforward proposals, and easy to coordinate.

Moreover, the EAP-methods can obviously be plugged directly into either of them, if we just keep our proposals a little coordinated, and describe the PANA EAP methods in a separate document.

We must also assure that the PAA discovery is an independent module - apart from the carrier, because ICMP would probably prefer RAs while UDP probably would go best with DHCP.

So the PANA recipe will be:
1-2 discovery methods
2 carrier modules (ICMP and UDP)
1-2 Initial Authentication modules (we may need 2 to allow both host- and server-initiated authentication.)
1 Re-Authentication module
1 Disconnect module
Do NOT mix it all together and you will get a tasty cake.

Would this something we could agree on to bury the layering discussion and get on to the actual work?

Do you agree, George?
Alper?

Paal

> 	 <[email-masked]>
> CC: [email-masked]
> Tema: one or two protocols? was:RE: Re: EAPoIP
> 
> Paal,
> 
> You keep ignoring maybe the most important reason we are here and that is
> straight forward network access. You are only thinking about application
> layer and thus EAP over UDP, because you are only thinking hotels/airports
> and such application.
> 
> Still, at least half the people in this group think that PANA is needed for
> authentication for network access potentially performed *prior* to address
> allocation between the end node and the access router.
> 
> Now, if you try a bit and please, please try :-) you will realize that using
> EAPoverUDP to get basic internet access is too inefficient and it does not
> work if you do not already have an address! People want to use this is all
> shorts of scenarios, including wide are wireless and potentially frequently
> due to end node movement. For this kind of fundamental function it is
> prudent to go lower in the networking stack so the solution becomes
> fundamental part of the network layer and is also efficient. ICMP is the
> perfect candidate for that. ICMP is the control plane of IP and some of us
> think that authentication and later authorization is very much control
> plane. 
> 
> It also happens that, despite what you say below, ICMP runs happily end to
> end (e.g: ping, traceroute etc) and thus, one can use it for the control
> plane between any two nodes in the internet and so, can potentially be used
> for the  other class of application that concerns you and others here.
> 
> Still, it is conceivable that the two classes of application that we are
> trying to solve should not be solved with the same protocol. So, unless we
> find a way to accept and work with both applications of this in a reasonable
> way we may have to end up with two protocols which maybe is the right thing
> to do.
> 
> Thoughts?
> 
> George
> 
> 
> 
> -----Original Message-----
> From: Paal Engelstad [mailto:[email-masked]]
> Sent: Friday, February 08, 2002 4:46 AM
> To: Alper Yegin; James Carlson; George Tsirtsis
> Cc: [email-masked]
> Subject: Re: Re: EAPoIP
> 
> 
> Alper, 
> 
> I think you mis-read my message.
> 
> Comments below will clarify.
> 
> > 
> > Fra: "Alper Yegin" <[email-masked]>
> > Dato: 2002/02/08 Fri AM 04:24:28 CET
> > Til: "Paal Engelstad" <[email-masked]>, 
> >    "James Carlson" <[email-masked]>, 
> >    "George Tsirtsis" <[email-masked]>
> > CC: <[email-masked]>
> > Tema: Re: EAPoIP
> > 
> > Paal,
> > 
> > I disagree with your points....
> > 
> > > James,
> > >
> > >
> > > > For the other part, we now have EAP over ICMP and EAP over UDP.  (The
> > > > latter called "EAPoIP" for some reason.)
> > >
> > > It is a good point. EAPoIP is not a good name.
> > >
> > > One reason was that I never expected someone would suggest to run an
> > application layer client/server protocol over ICMP. It really undermined
> the
> > intentions of ICMP from the old days.
> > 
> > PANA is not application layer. It's functionality is part of overall
> network
> > connectivity.
> 
> > > ICMP was intended for error and control messages related to routing. I
> see
> > no reason why PANA should go in the forefront to undermine fundamental
> > principles established in the IP architecture.
> 
> 
> You are arguing for ICMP by "control" and "connectivity". Both these terms
> relates to a butch of protocols including both ICMP and UDP. 
> 
> The big differentiator in my statement is "RELATED TO ROUTING". (Read
> again.) 
> 
> I think ICMP was intended for host-to-router communication and
> router-to-router communication. I do not like to run ICMP host-to-host. PAA
> is a host (of type: server) no matter if it resides on a router or not. PAA
> is not involved with routing! It is providing authentication service. 
> 
> (A mobility agent, on the other hand, is something I can accept as a router
> - it has a configurable "routing table", it forwards messages on behalf of
> the MN, table configured by registrations, etc.)
> 
> > 
> > Well, this is part of "control". 
> 
> Yes, but it is not dealing with routing.
> 
> > Asking for a router on your link and
> > learning routers is
> > control, right? (router discovery).
> 
> This is actually related to routing!
> 
> > Without authentication/authorization,
> > this gives you
> > off-link connectivity. Same goes for PANA. Only after PANA exchange, you
> can
> > get
> > "connected".
> 
> I don't think the main issue of ICMP has to to with connectivity. There are
> a bunch of protocols that accommodates connectivity apart from ICMP at all
> different layers. Let us simply keep connectivity out of the discussion.
> 
> I am really confused that you prefer to run ICMP for client/server
> communication. At least if we anticipate some EAP-based solution, you are
> getting very close to a client/server solution!
> 
> So untill then I stick to my understanding of the IP-architecture the way
> the IETF old-timers envisioned it.
> 
> A statement from Erik on this principal matter would be very clarifying,
> because your statements make me very confused. 
> 
> Perhaps I have to revise my understanding of IP...
> 
> Paal
> 
> 
> > 
> > 
> > alper
> > 
> > 
> > >
> > > I may address your comment about the name in the next version of the
> > draft. Thansk for reminding me.
> > >
> > > Thanks again,
> > > Paal
> > >
> > >
> > >
> > > Both seem to have the
> > > > IP-address-allocated-first problem, unless I'm missing something.
> > > >
> > > > For what it's worth, I think the deployment scenario considered in
> > > > draft-tsirtsis-eap-over-icmp has problems: how do broadcast and
> > > > multicast work in such a situation?  There's clearly no coordination
> > > > of multicast address assignment between the ISPs, nor any obvious way
> > > > to have the End Node do the right thing with received broadcasts.
> > > >
> > > > The IARs in section 1.1 of this draft may know which link-layer
> > > > addresses correspond to which authenticated End Nodes for purposes of
> > > > access filtering, but the End Nodes do not have information about the
> > > > other End Nodes, nor necessarily about the IAR(s) to which they
> > > > *didn't* authenticate.
> > > >
> > > > --
> > > > James Carlson, Solaris Networking
> <[email-masked]>
> > 
> > > > SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442
> 2084
> > > > MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442
> 1677
> > > >
> > > >
> > >
> > >
> > 
> > 
>

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 8 Feb 2002 13:36:45 -0800

> George,
>
> IP architectural principles are about religion (at least for me). We may
argue for ages. I therefore appreciate that you take this pragmatic
approach. Let's get the job done.
>
> So religion aside, I think you make some very good points here. It might
be more efficient to run it on the IP layer, which might be vital for the
part of the PANA group focusing on high performance mobility (3G etc).
>
> However, there is a group of people arguing for an application layer
solution. There are tradeoffs, and one is not necessarily better than the
other.
>
> Thus, I think your idea of going forward with two PANA carriers modules
could good be a good solution to end the application layer vs. IP-layer
discussion. PANA (or market demands) may decide later.
>
> Now, if the two PANA carriers, EAPoUDP and EAP-over-ICMP were complicated,
two protocols would not be desireable. But both are straightforward
proposals, and easy to coordinate.
>
> Moreover, the EAP-methods can obviously be plugged directly into either of
them, if we just keep our proposals a little coordinated, and describe the
PANA EAP methods in a separate document.
>
> We must also assure that the PAA discovery is an independent module -
apart from the carrier, because ICMP would probably prefer RAs while UDP
probably would go best with DHCP.
> Would this something we could agree on to bury the layering discussion and
get on to the actual work?

Paal, I think this discussion is not related to the scope, requirements (,
or
justicification) of the PANA. This cake smells like "solutions" :) I rather
save
this to later... :)

alper