Subject: one or two protocols? was:RE: Re: EAPoIP

From: George Tsirtsis <[email-masked]>
Date: Fri, 8 Feb 2002 06:18:23 -0500

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: James Carlson <[email-masked]>
Date: Fri, 8 Feb 2002 08:17:11 -0500 (EST)

> allocation between the end node and the access router.

Right.

> work if you do not already have an address!

Well, that's not quite right.  Assuming you have reliable L2
addressing, you can use IP source address 0 and L2 tricks to do this
-- just like DHCP.  As anyone who has worked on this knows, it's a bit
messy when it comes to implementation, so it'd be really nice if the
number of applications that perform this sort of hackery were limited.

> People want to use this is all

Um.  ICMP requires IP addresses no more or less than UDP does.
Switching from UDP to ICMP doesn't actually address that issue, but it
creates a new issue: ICMP types are usually harder to filter (for
firewalls) and proxy (for NATs) than are UDP ports.

So, moving the protocol from UDP to ICMP means that it will have
additional deployment problems with firewalls and NATs, and will still
have the same cart-before-the-horse IP address problem.

That doesn't sound like a necessary change to me.

-- 
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: Jacques Caron <[email-masked]>
Date: Fri, 08 Feb 2002 14:42:19 +0100

At 12:18 08/02/2002, George Tsirtsis wrote:
>prudent to go lower in the networking stack

I think you just made the case for L2 integration rather than L3 :-)

>  so the solution becomes

How does ICMP solve the issue of the absence of IP address?

Jacques.

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