RE: REMINDER: RADEXT WG Last Call on Design Guidelines Document

[Bernard Aboba <aboba@internaut.com>]

> >   e.g. I just ran into devices with multiple interfaces that send
> > Accounting-Requests from IP (1) for Start/Stop, and from IP (2) for
> > Interim-Updates.
> > 
> >   Since this isn't forbidden by the specs, they have no interest in
> > fixing it.  It's everyone *else* that has to butcher their systems in
> > order to deal with such nonsense.

Ugh.  I wonder how the RADSEC proxy would function when receiving packets 
from an implementation like that.

RFC 5080 does suggest that NAS-Identifier be used to avoid 
multi-homing confusion, at least within the RADIUS packet itself.  
Using different source addresses does seem "novel" - and quite 
likely to confuse.  One can imagine quite bizarre scenarios for an interop 
torture test - like having a NAS sending RADIUS/EAP packets within the 
same session from different IP addresses.  The RFC 5080 algorithm in 
Section 2.1.2 references "source IP", so it would be confused by this, 
wouldn't it? 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>