eap Mailing List: RE: comments on draft-adrangi-eap-network-discovery-02.txt

[Bernard Aboba (aboba]

> The figures are done from AAA routing perspective.  Don't you think the
> conversation between the peer and RADIUS server is irrelevent here?

Yes.  That's why I'm not clear what the arrows are trying to say:

     |                   <-- EAP conversation -->                   |

The EAP converation is not the issue, and in any case, EAP is spoken
between the peer and the home RADIUS server so the arrows are in the wrong
place.


> That's correct.  I thought the paragraph after 3.3 diagram explained
> this.

You might say specifically that the RADIUS proxy acts only on the
User-Name attribute and does not have to parse the EAP-Message attribute.
That way it's clear that no change to RADIUS proxy behavior is intended.

> Excellent point!  I thought about mentioning this in the draft, but I
> thought it would be too much implementation-specific details.  So, I
> guess we need to bring it up.

It's not a big deal if Section 3 goes in an Appendix.  Just don't use
normative language.

> > Note that this
> > implies that the
> > RADIUS proxy would not know if the authenticator had sent an
> > identity hint
> > originally,
>
> That's right!

Yes, because there would be no State attribute to tell it that the NAS
already sent a hint.

> But, I don't know why the local AAA proxy should try the identity hint 3
> times before it gives up.

The AAA proxy would only try once, but the NAS would have tried once
before that, and it wouldn't know.  So you'd have two EAP-Identity
exchanges, both with hints.  After that the AAA proxy gives up, and
presumably sends an EAP-Notification or EAP-Failure.