Subject: RE: [eap] preserving packet order in EAP?

From: <[email-masked]>
Date: Wed, 5 Feb 2003 14:15:06 +0200

> -----Original Message-----
> From: ext Alper Yegin [mailto:[email-masked]]
> Sent: 23 January, 2003 21:33
> To: Forsberg Dan (NRC/Helsinki); [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [eap] preserving packet order in EAP?
> 
> 
> On 1/23/03 5:26 AM, "[email-masked]" 
> <[email-masked]> wrote:
> 
> > Thank you for your comments. Just a quick question. What if 
> PANA would specify
> > a "EAPv2" that wasn't backwards compatible with EAP but 
> better suitable for
> > UDP/ICMP or TCP/SCTP? This new version could carry EAP 
> methods specified in
> > the current EAP wg. For my understanding this wasn't the 
> intention of PANA wg,
> > but it would make things simpler/easier for PANA(?). Just an idea.
> 
> First we really need to understand what problems arise from 
> carrying EAP
> above IP. Re-ordering was brought up, but that can be handled by
> including an identifier field in a PANA header. So I don't
> see this as a requirement for a new version of EAP. Is there 
> anything else?
> Let's think...
> 
> Also let's note that if modifications to EAP are needed, PANA is not
> the right WG to take over this. We need to bring it up to the EAP WG.

It's not possible to make changes to EAP, because it MUST be backwards compatible with RFC2284. That is what I've understood. So, the playground is around the EAP methods and requirements set to them (classification).

- Dan

> alper
> 
> 
> 
> > 
> > - Dan
> > 
> > 
> >> -----Original Message-----
> >> From: ext James Carlson [mailto:[email-masked]]
> >> Sent: 23 January, 2003 15:09
> >> To: Forsberg Dan (NRC/Helsinki)
> >> Cc: [email-masked]; [email-masked];
> >> [email-masked]
> >> Subject: RE: [eap] preserving packet order in EAP?
> >> 
> >> 
> >> [email-masked] writes:
> >>> One possible solution for this problem is to require the
> >>> Authenticatee to remember the ID numbers inside the EAP method
> >>> (message id's between the initial request and  Success/Failure
> >>> msgs). This would imply that no EAP method should produce 
> more than
> >>> 256 requests per authentication.
> >> 
> >> That doesn't work because of rechallenge.  (Well, unless you're
> >> willing to drop the link when you run out of ID space for 
> rechallenges
> >> ...)
> >> 
> >>> Anyway, I think this should be fixed in the EAP protocol simply
> >>> because it is standardized here in the IETF. A new issue perhaps?
> >>> EAP already provides retransmission and "duplicate"
> >>> detection. Making the duplicate detection work within 
> this example,
> >>> would make EAP suitable for carriers such as UDP, ICMP, 
> and IP. This
> >>> would increase the possibilities for EAP in the Internet.
> >> 
> >> EAP has no problem with retransmission or duplicates (or other bad
> >> packets, for that matter).  It does have a problem with reordering,
> >> and that can't actually be fixed without making the "new" version
> >> incompatible with the old.  If you're going to make it 
> incompatible,
> >> I'd suggest starting with a blank slate.
> >> 
> >> EAP just wasn't designed to be used as you suggest.  It needs an
> >> order-preserving peer-to-peer link.
> >> 
> >> -- 
> >> 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
> >> 
> > _______________________________________________
> > eap mailing list
> > [email-masked]
> > http://mail.frascone.com/mailman/listinfo/eap
> > 
> 
>

---

From: James Carlson <[email-masked]>
Date: Wed, 5 Feb 2003 07:28:17 -0500

[email-masked] writes:
> It's not possible to make changes to EAP, because it MUST be
> backwards compatible with RFC2284. That is what I've understood. So,
> the playground is around the EAP methods and requirements set to
> them (classification).

I find that assertion hard to follow.  Yes, it's true that redefining
the way EAP works when it runs over PPP or 802.1X would be somewhere
between 'hard' and 'impossible,' but I don't see how that's
necessarily true for PANA, which, as best I can tell, has no fielded
implementations.

If you had a different transport mechanism for non-point-to-point
links, you could still carry encapsulated EAP messages and be
compatible with the existing AAA infrastructure and with the defined
EAP methods.  The one thing you'd lose is compatibility with EAP's
existing retransmission framework, and thus 2284, but since the draft
authors are going to great pains to separate "method" definitions from
the "EAP base," I don't see how that's a terrible loss.

(None of that should be read as endorsing such a plan, since I don't
agree that PANA is necessary or desirable in the face of L2
authentication technologies, but it doesn't seem right to me to say
that it's not possible.)

-- 
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: Wed, 05 Feb 2003 17:42:03 -0800

> authentication technologies, but it doesn't seem right to me to say

Not all networks are running IEEE 802 links, and not all (if any) other
link technologies are supporting EAP. And inserting PPP in the stack
just for the sake of carrying EAP is not the best idea obviously.  Or
developing other ad-hoc solutions. PANA usage scenarios draft is where this
is covered, and its updated version will be available soon.

alper