Josh, Good to hear from you.
> -----Original Message----- > From: Josh Howlett [mailto:[email protected]] > Sent: Friday, July 22, 2011 3:26 PM > To: Jim Schaad; [email protected] > Subject: Re: [abfab] Architecture Document Issue > > 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. > > >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. > > >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. 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. 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. 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. 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. 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). Jim > > 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
