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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf