Subject: RE: EAP over ICMP

From: George Tsirtsis <[email-masked]>
Date: Wed, 9 Jan 2002 05:28:30 -0500

Welcome back Alper,

see inline

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Wednesday, January 09, 2002 12:01 AM
To: George Tsirtsis
Cc: 'James Kempf'; 'Carl Williams'; Pana (E-mail)
Subject: Re: EAP over ICMP 

Hi George,

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

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

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.

GT> Well, ok this is exactly my point. If PANA needed ONLY 2 messages that
can ride on RS and RA messages then SNARD would be appealing. But I think,
that flexibility is important here. i.e.: PANA MUST work with multiple
authentication mechanisms. This is vital since we are talking about PANA as
potentially basic element in the Internet which will have to be
extensible...Note that PANA is in some cases needed as an alternative to PPP
which is already extensible in that respect...PANA should be at least as
flexible.

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

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

GT> I have said this twice already, I think it is very clear in the draft
(see Figure 3) and I am going to say it again: EAPoverICMP can run between
the end node and any device you want be it the AR or a server behind it. And
I will ask why not? I am using new message types and ICMP can run end to end
so I do not see why this confuses people.

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

GT> OK, ok :-)

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

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.

GT> No I do not have do that really. One thing I do not like in the IETF
these days is that we tend to confuse protocols with system designs. I wrote
a simple draft on how one can do EAP over ICMP. Address assignment is
irrelevant. Now, one can go and develop a DHCP option that provides the end
system with the address of the Authenticator or create another extension to
RAs that advertises the same address. This has nothing to do with the EAP
over ICMP protocol and yet is clearly feasible and if you twist my arm a bit
more I will add a paragraph in the draft to mention it.

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.

GT> And I fully agree with you and have argued for the AR case since the
BOF. Still there are enough folks out there thinking about the hotel and
other such environments were the back-end Authenticator makes some
sense...and as long as both scenarios can be covered I do not see why we
need to have that argument.

Cheers
George

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

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 9 Jan 2002 08:55:54 -0800

> Welcome back Alper,

Thanks George!

> which is already extensible in that respect...PANA should be at least as

OK, we'll look into this.

> so I do not see why this confuses people.

Sure it should be able to do that. But you need to work out some details
here.
What is the destination address of the PANA packets sent by the client, if
PAA
is more than one hop away? Either the client has to "discover" the address,
or
there must be a pre-configured address (anycast?).

> more I will add a paragraph in the draft to mention it.

George, without that bit, I'd say your "protocol" is incomplete. If you
leave
that part out, your protocol will have a dependency on some other protocol
that doesn't even exist.

A similar example is with Mobile IPv4. The mobile node has to discover the
foreign agent before it registers with this agent. It does so by using
router discovery
messages, which is outlined in the draft. That draft doesn't get away by
saying
"mobile somehow figures out the agent address". I really think you need
something
here.

> need to have that argument.

In the case of SNARD, access routers are the front end, and they consult
AAA server in the visited domain, which is the backend.

Cheers,

alper