![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Andy Bierman wrote:Well, first of all I don't see why this is any different than a radiusI don't agree that this is low-hanging fruit. The server component of this system seems like a wonderful new target for DDoS and masquerade attacks.
server. In fact it could be that the access box forwards information in
a very similar way. But let's say that it doesn't work that way just
for yucks. Another approach is that the clients themselves must have a
server on them and the queries go the other way. In this case the
server need only check either a source address or a transaction ID. Furthermore, there is no reason for clients outside of that AS to have
access to that server, so it's a good candidate for an ACL. Of course
this creates a risk of attack on the clients themselves, which brings me
to one of my greater concerns:
In many of the mechanisms that communicate between client and network we are not finding good ways to prove the legitimacy of the service to the client. This is an area that perhaps it would be good to get the IRTF to work on.
My comment was on Harald's characterization of this work effort as 'low hanging fruit'. IMO, that term is reserved for huge gains for very little effort. I don't think that is the case here.
Eliot
Andy
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.