Hi folks, this is a short summary of the Federated Roaming BBoF yesterday evening. My two Guinness hopefully left enough brain cells intact for this to be a complete report, but in case not: everybody who was there, please complete the pieces that I may have missed. RadSec ------ After an introductory explanation of our deployment scenario in eduroam - aggregation of independent administrative domains (universities) to a central national proxy, and further aggregation of nationals into a continental proxy - we figured that at least in this particular use case, there is a good reason for a reliable transport, but no need for "fancy" Diameter features - especially since eduroam lacks commercial interest, i.e. accounting. In the course of the discussion, it turned out that other people feel the exact contrary need: Diameter over UDP (reported by Avi Lior). Interestingly enough, there were also use cases in the Diameter area that would require proxy hierarchies. It was interesting to see that both of the protocols provoked the same concepts of aggregation hierarchies in certain use cases. There was also an agreement that apparently none of the two protocols is superior to the other in all aspects, and a deployer would need to make his choice. In the end there was a rough agreement of "let all the AAA transports have all the transport profiles they think they need", but the ultimate decision about that would need to be taken in radext on Friday. EAP error reporting ------------------- Basic problem statement: if an EAP session can not be established or is interrupted prematurely, there is no good error reporting mechanism back to the supplicant+user. Avi confirmed that this is not only a concern for eduroam, WiMAX deployments see the same need. It would be good to have a reporting mechanism in EAP preferably (for the WiFi case, having one in 802.1X would also do, but EAP would be the more general solution). Binding layer 2 authenticated entities to layer 3 addresses ----------------------------------------------------------- Lawful interception is one of the drivers for that, current approaches to it are snooping DHCP traffic (as discussed on int-area before the BBoF). Having a clean solution here would be desirable. Stig's approach from the mailing list (distributing keys to supplicant within EAP and DHCP server via some other mechanism to bind the leased IP address to the entity was mentioned. Stig wasn't at the BBoF but later came up with a pretty sonsistent idea. He is going to write an I-D about it. (Note from self, not discussed in meeting: It is unclear though how this works with IPv6. Relying on DHCPv6 would need to disable stateless auto-config, and IPv6 Privacy Extensions wouldn't work any more) EAP fragmentation ----------------- A report on EAP-TLS usage in eduroam came as a surprise to most participants: I had to report that EAP-TLS in the international roaming case does *not* work more often than it does. We have tracked down the likely causes to a) UDP fragmentation [authenticator adds lots of RADIUS attributes to the raw EAP data, and with EAP-TLS the EAP chunks are often = the link-layer MTU already, resulting RADIUS packet is then often > MTU between authenticator and AAA server] When staying local, chunk sizes of EAP can be tweaked to make stuff work, but when roaming to an unknown network with unknown infrastructure, this gets difficult and would have to be done at end-user side, i.e. it exceeds John Doe's capabilities and can not be considered a usable solution. Another possible cause is packet reordering and firewalls that then discard the incoming fragment because there's no observed previous fragment. We think that TCP as a transport (RadSec) could help mitigate that. There are no hard numbers and facts to prove that yet though. In any case, for plain RADIUS deployments, a max-desired-EAP-chunk discovery mechanism would be interesting. That should be pretty much it. May the force be with you, Stefan Winter _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf