Subject: RE: [AAA-WG]: Issue: Maximum size of EAP messages

From: <[email-masked]>
Date: Tue, 24 Jun 2003 14:03:10 +0300

Jari Arkko wrote:

> > The EAP server may need to know the maximum size of EAP payload
> > it can send, in order to produce fragments of correct size.
> > 
> > Proposed change: Add new EAP-MTU AVP, sent in
> > Diameter-EAP-Requests (I think we shouldn't re-use Framed-MTU
> > AVP for this; the "framed MTU" of the link isn't necessarily 
> > the same as the maximum size of EAP message).
> 
> Ok.
> 
> We should have a section that describes how RADIUS EAP
> and DIAMETER EAP map to each other, and explain there
> that RADIUS Framed-MTU maps into both Framed-MTU and
> EAP-MTU AVPs...

I have a sketch of Diameter-RADIUS translation section in
http://www.cs.hut.fi/~peronen/eap/draft-ietf-aaa-eap-02.c.txt.

But is mapping a RADIUS Framed-MTU attribute to both EAP-MTU AVP and
Framed-MTU AVP actually necessary?  RFC2865 says that Framed-MTU may
be used as a hint in Access-Request messages.  But do existing RADIUS
implementations that use EAP actually interprete the same
Framed-MTU value both as MTU for EAP and "link MTU hint"?

My guess would be that if EAP is used, the value is not used as a
"link MTU" hint at all, but then, I'm not an expert on existing 
RADIUS implementations. (RADIUS implementations without EAP may, 
of course, use this value as link MTU hint.)

If this is the case, then we can just map Framed-MTU in RADIUS
Access-Request to EAP-MTU AVP (the Diameter-EAP-Request won't have any
Framed-MTU AVPs), and when mapping Diameter-EAP-Request to RADIUS
Access-Request, just drop all Framed-MTU AVPs present in the
Diameter request.

Best regards,
Pasi

---

From: Jari Arkko <[email-masked]>
Date: Tue, 24 Jun 2003 14:38:39 +0300

> http://www.cs.hut.fi/~peronen/eap/draft-ietf-aaa-eap-02.c.txt.

Yes. I saw it later, comments coming up...

> of course, use this value as link MTU hint.)

Good questions. No, I don't have the answers either...

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Jun 2003 04:49:45 -0700 (PDT)

> > of course, use this value as link MTU hint.)

Perhaps we should post the question to the EAP WG mailing list to see what
implementors do.  I know that some ignore it entirely (with disasterous
results).

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Jun 2003 04:56:11 -0700 (PDT)

> > > of course, use this value as link MTU hint.)

This reminds me. I wonder whether AAA implementations are really prepared
for any legal value of Framed-MTU.  After all, this could be as low as 256
octets -- and there are some methods not supporting fragmentation that
could generate packets larger than this.  It seems like an issue that
needs further clarification in RFC 2284bis -- for example, there are EAP
method specifications that claim that they can never fragment.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 24 Jun 2003 15:38:58 +0300

> method specifications that claim that they can never fragment.

Maybe add a "Fragmentation Behaviour" description for all methods?
State the maximum message size, and whether the method supports
fragmentation or not. Then in the general part of 2284bis, we
can say that methods that do not support fragmentation may not
work in case the MTU value on the given link is too small.

--Jari