Subject: [eap] Issue: Identifier conflict

From: [email-masked] ([email-masked])
Date: Fri, 4 Apr 2003 12:03:42 +0300

EAP Identifier conflict
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: April 4th, 2003
Reference:=20
Document: RFC 2869bis
Comment type: T
Priority: 1
Section: 2.1 and others?
Rationale/Explanation of issue:

There seems to be a potential issue with EAP packet Identifiers
in 2869bis.

Suppose that the EAP conversations is started by NAS
(e.g. Identity request, possible followed by something else)=20
and then continues as pass-through. When sending its first=20
EAP Request, the RADIUS server must choose an Identifier value=20
different from the previous packet sent by the NAS (otherwise=20
the client will simply retransmit).

If the first Access-Request sent by NAS contains an EAP
Response, the AAA server can look at that packet's identifier
and choose a different one. However, if it only contains
EAP-Start, a conflict can occur (if the NAS already sent
something to the client).

This can happen, e.g. "The NAS also MAY send an Access-Request
packet containing an EAP-Start if, after sending an initial
Request for an authentication Type, the peer responds with a
Nak" (2869bis-11, section 2.1).

I see several possible ways how this could be resolved:

- Specify some way for the NAS to transmit its previous=20
  Identifier value to RADIUS server.
- Allocate Identifier space so that conflicts don't occur (e.g.
  NAS uses only values 0-127, RADIUS server starts with >=3D128).
- Always compare whole packets, not just Identifiers (a big
  change to RFC 2284, so probably not feasible).

There might be other solutions, too. The second one looks
the simplest to me, but is it a reasonable change?

Best regards,
Pasi

---

From: [email-masked] (Jari Arkko)
Date: Fri, 04 Apr 2003 13:04:54 +0300

[email-masked] wrote:
> Reference: 
> (e.g. Identity request, possible followed by something else) 
> and then continues as pass-through. When sending its first 
> EAP Request, the RADIUS server must choose an Identifier value 
> different from the previous packet sent by the NAS (otherwise 

Interesting problem!

> - Specify some way for the NAS to transmit its previous 
>   NAS uses only values 0-127, RADIUS server starts with >=128).

Well, you could also prohibit the use of RADIUS in this situation
(after having got a NAK). I'm actually not sure why we need that
function; it seems like the typical case where the NAS is sending
its own requests is for identity request. But if you don't get an
identity response, you may be in trouble already as the RADIUS
infrastructure may not be able to route the AAA requests to the
right home environment.

Other than that, I'd prefer solution 1.

Jari

---

From: [email-masked] (Jin Tao)
Date: Mon, 07 Apr 2003 10:05:25 +0800

Mr. Jari,
  I am so glad to see you!
  I do agree with you. 
  In eap, we should keep packet's identifier same in whole RADIUS transaction. If the scenario Mr. Eronen mentioned happens, I prefer to prohibit RADIUS function as what you have said. 
  As a developer, I think RADIUS server cannot know where is the client until NAS reports it. Whatever RADIUS server did before NAS reports its client can be omited. In this scenario, NAS starts eap. If RADIUS does know where the client and NAS is , RADIUS starts first, NAS must obey the identifier of RADIUS.

  Best Regards!
        Yours Sincerely,

Tao Jin
System Engineer

NanJing Institute,Huawei Technologies Co.,Ltd.
Floor H,G.E. Plaza Hotel,No.89 Hanzhong Rd.
NanJing, P.R. of China
Zipcode:210029
TEL:(+86) 25-4723480-3009
FAX:(+86) 25-4723063
Email:[email-masked]

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, April 04, 2003 6:04 PM
Subject: Re: [eap] Issue: Identifier conflict

> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap