Subject: [eap] preserving packet order in EAP?

From: [email-masked] ([email-masked])
Date: Thu, 23 Jan 2003 15:26:28 +0200

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.

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

---

From: [email-masked] (James Carlson)
Date: Thu, 23 Jan 2003 08:50:44 -0500

[email-masked] writes:
> 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.

That's basically what I was suggesting -- if you're going to make it
incompatible, then it's not EAP anymore and isn't suitable for the EAP
RFC update, but it might work for some particular domain.

It seems to me that there are other issues that need to be solved, and
might as well be solved while the patient is on the table.  For
instance, EAP assumes a peer-to-peer link.  PANA and 802.11 [1] have a
common problem -- the use of multiaccess media.  (Note that both PPP
and 802.1X are just point-to-point.)  It's not the wireless aspect
that's really a special problem; it's the multiaccess nature that
causes all the additional security headache.  Why not define something
that's specific to use on multiaccess networks and that can handle
bootstrapping the security association required?

That new protocol (MEAP?) can certainly carry EAP-formatted messages
if it wants -- after all, AAA protocols aren't EAP, but do carry EAP-
formatted messages, so it's not a new concept -- but it needn't be
compatible with EAP in any other way, so it doesn't need the same
retransmission mechanism.

I think that'd be a happier result than contorting EAP to fit into a
non-EAP-shaped hole.

[1] Minor digression: I leave DSL out of that list quite
    intentionally.  DSL is most certainly a point-to-point technology,
    and it's made to appear to be multiaccess only by error.  If you
    could yank out the Ethernet-over-ATM baggage and run plain PPP
    over HDLC on the raw bit pipe between CPE and CO, then all of the
    current problems -- including PPPoE and PANA -- disappear (and
    overhead is reduced as well).  Bridged Ethernet with DHCP or
    routed point-to-point link: pick *one*.

    (It also doesn't actually require the authentication in the plain
    point-to-point case, since you know where the wires go physically,
    but it doesn't hurt.)

-- 
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: [email-masked] (John Vollbrecht)
Date: Thu, 23 Jan 2003 08:51:24 -0500

I think it is an interesting idea to consider a way to use EAP Methods 
independently of EAP itself.    Seems to me it could be an interesting 
approach for PANA to consider.

--On Thursday, January 23, 2003 3:26 PM +0200 [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.
>
> - Dan
>
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] (Yoshihiro Ohba)
Date: Thu, 23 Jan 2003 09:25:59 -0500

I agree with James, and the following is just a clarification.

PIC and PoTLS are aiming to serve for carrying EAP-formatted messges
over multiaccess (and any other type of) link, by logically
establishing a secure, order-preserved, logical point-to-point
communication channel before starting EAP conversation, based on
anonymous key exchange.  This is a different approach from which
802.11i is taking.

Yoshihiro Ohba

---

From: [email-masked] (Alper Yegin)
Date: Thu, 23 Jan 2003 11:32:59 -0800

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.

alper