Subject: Re: Re: EAPoIP

From: Paal Engelstad <[email-masked]>
Date: Fri, 8 Feb 2002 5:45:30 +0100

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:52:49 -0500 (EST)

Paal Engelstad writes:
> 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.

Huh?  ICMP Port Unreachable?  ICMP Echo?

Since when is what you describe an issue at all?

> 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. 

That doesn't appear to be true.  The PAA makes a decision that affects
whether IP packets from a given node are forwarded through the rest of
the network.  Is that somehow not a routing function?

Other folks on this list have very vigorously defended the notion that
the PAA *MUST* be the Access Router.  Are you saying that this must
not be the case?

> 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!

Is ICMP Echo a client/server model?  How about ICMP Address Mask
Request?