>>>>> "Josh" == Josh Howlett <[email protected]> writes:
Josh> 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.
Josh> That's not the conclusion I would draw, but perhaps I'm
Josh> misunderstanding you. The fact that the NAS has to consider
Josh> retransmission is a consequence of the fact that the
Josh> underlying transport is not reliable.
What Jim is saying is that RADIUS provides a reliable service to
EAP. That is, RADIUS is responsible for making sure that messages
reliably get from the NAS to the EAP server and back.
I believe he's approximately right and that the differences are not
things we need to worry abuot.
>>>
>>> >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.
Josh> These aren't assumptions of the architecture, although I
Josh> believe it will end up being true in practice.
I actually believe these are carefully crafted aspects of the
architecture. Making sure both the above could be assumed was something
I have been very careful to try and achieve since the issues were
discussed in the feasibility analysis.
>> 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.
Josh> Correct. Although bear in mind there could be intermediate
Josh> 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.
Josh> I think this is, in practice, unlikely but not impossible if
Josh> unreliable RADIUS transport is used (ie. RADIUS over TCP).
There is never a case where an EAP retransmission is visible at the GSS
layer. I think that's enough to get the properties Jim is interested
in. Arguing about whether a duplicate EAP request is a RADIUS
retransmission or an EAP server retransmission is implementation
pedantry; I think 3748 resolves it as a RADIUS issue, but it doesn't
much matter.
>> 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.
Josh> I think I would disagree with this characterisation; the GSS
Josh> acceptor is acting very much like a NAS at a protocol
Josh> level. In terms of implementation, it could looks quite
Josh> different, of course. In our GSS EAP implementation, the
Josh> acceptor will eventually call out to a completely separate
Josh> process (the Identity Selector) which will manage the EAP
Josh> 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.
Josh> I agree, although not for the reasons you state! It's more
Josh> likely that reliable transport will be deployed (ie. RADIUS
Josh> 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).
Josh> It could do that, but it wouldn't conform to the existing
Josh> architecture. Why would you want to do this?
Josh> Josh.
Josh> JANET(UK) is a trading name of The JNT Association, a company
Josh> limited by guarantee which is registered in England under
Josh> No. 2881024 and whose Registered Office is at Lumen House,
Josh> Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG
Josh> _______________________________________________ abfab mailing
Josh> list [email protected]
Josh> https://www.ietf.org/mailman/listinfo/abfab
_______________________________________________
abfab mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/abfab
