Subject: [Int-area] Results from the Federated Roaming BBoF

From: [email-masked]
Date: Thu, 13 Mar 2008 22:31:50 +0100

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

_______________________________________________
Int-area mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/int-area