Jim,
>>
>> >1. What is the assumption that EAP uses when being transported over
>> >RADIUS/DIAMETER. Specifically does it make assumption that the
>> >transport is reliable and thus no retries ever need to be made.
>>
>> No; check out section 2.3 of RFC3579: "As noted in [RFC2284], if an EAP
>> packet is lost in transit between the authenticating peer and the NAS
>>(or
>vice
>> versa), the NAS will retransmit."
>>
>> I'm not sufficiently familiar with Diameter to comment, but I hope that
>> someone who is will be able to chip in...
>
>Actually that would make the assumption be true. If it is the job of the
>NAS to do the retransmit then the assumption is that the RADIUS layer is
>going to be a reliable transport.
That's not the conclusion I would draw, but perhaps I'm misunderstanding
you. The fact that the NAS has to consider retransmission is a consequence
of the fact that the underlying transport is not reliable.
>>
>> >2. What are the trade-offs when running the server as an EAP
>> >pass-through service verses as a tunnel. Specifically what are the
>> >security and functionality requirements that are imposed. Two issues
>> >that I can think of are 1) is the EAP data masked from the server and
>> >2) if the host protocol is not reliable, does the pass-through service
>> >need to provide the retry service.
>>
>> I'm not sure what you mean by tunnel in this context; could you clarify
>> please?
>
>Ok - from the response to the above statement, it means that the NAS MUST
>operate according to the rules of being an EAP pass-through service. It
>cannot just blindly pass the EAP packets on to the acceptor w/o ever
>looking
>at them. It needs to filter out known bad packets as well as dealing with
>the rules of retransmission.
Yes; this is laid out in RFC 3748; specifically section 2.3 ('Pass-Through
Behaviour').
>>
>> >3. It would do well to re-state the requirements from GSSAPI in the
>> >document - specifically that it is required the host protocol provide a
>> >reliable service that will deliver items to GSSAP in order. This means
>> >that an underlying protocol that wants to use UDP for some reason will
>> >have additional requirements placed on it that are not there for a TCP
>> >based service.
>>
>> I have no problem with that.
>>
>> >4. Can a host protocol be writing as a pure query/response system or
>> >does it need to support full bi-directional, full duplex functionality.
>> >Specifically are there any requirements from ABFAB itself (say from
>> >EAP) that make it impossible to run as a query/response system.
>>
>> Not that I can think of.
>>
>> > For example, if an EAP server needs to do a re-try and generates a
>> >message to be sent down, can this occur?
>>
>> I'm not sure what you mean by a "re-try"? Do you mean a re-transmission
>> following an assumed packet loss? Or some kind of unsolicited message?
>>
>> > Is this going to be allowed by Radius/Diameter? Is it an issue for
>> >the host protocol to understand.
>>
>> Regretfully I'm not sure what you mean. Do you have a specific use-case
>>or
>> requirement in mind that we can work through?
>
>We can change the questions a bit at this point. Based on your responses
>we
>can make the following assumptions:
>
>1. EAP over Radius is assumed to be running on a reliable transport.
>2. EAP over GSS-API is assumed to be running on a reliable transport. If
>the transport is not reliable then it must be made reliable by the host
>protocol according to the rules of using GSS-API.
These aren't assumptions of the architecture, although I believe it will
end up being true in practice.
>3. The current assumption is that the NAS (using the Radius terminology)
>and the GSS-API acceptor are in the same location thus there is no
>transport
>between them.
Correct. Although bear in mind there could be intermediate RADIUS proxies
between the NAS and the EAP server.
>This removes much of the issue that I was worried about as we can now
>assume
>there is never a reason for an EAP server to retransmit an EAP message.
I think this is, in practice, unlikely but not impossible if unreliable
RADIUS transport is used (ie. RADIUS over TCP).
>The only reason for this not to be true would be if statement 3 was not
>true
>AND there was an unreliable transport between the terminus of the Radius
>system and the service. This means that the GSS-API acceptor is not the
>NAS. The NAS is going to do retransmission of EAP messages. The GSS-API
>would need to potentially need to catch the retransmission and remove
>duplicate messages.
I think I would disagree with this characterisation; the GSS acceptor is
acting very much like a NAS at a protocol level. In terms of
implementation, it could looks quite different, of course. In our GSS EAP
implementation, the acceptor will eventually call out to a completely
separate process (the Identity Selector) which will manage the EAP state
machine.
>Ok - if we make the above assumptions then it might not be necessary to
>have
>a "NAS" that does the retransmission of EAP messages. There would never
>be
>any reason to assume that they are ever going to be lost and thus need to
>get retransmitted as we have defined that there is a reliable transport
>all
>of the way through.
I agree, although not for the reasons you state! It's more likely that
reliable transport will be deployed (ie. RADIUS over TCP, rather than UDP
as is commonly the case today).
>The next question then is does the server need to act as a EAP
>pass-through
>agent, or can it just tunnel the messages from the EAP side to the GSS-API
>side w/o ever looking at the content of the message and following the
>rules
>of an EAP pass-through agent (i.e. drop messages on the floor due to the
>value of the code field and so forth).
It could do that, but it wouldn't conform to the existing architecture.
Why would you want to do this?
Josh.
JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
