Hosnieh Rafiee <ietf@xxxxxxxxxxx> wrote:
> The name of this group is: SDNAuth
> This group focuses on the following scope:
> - Authentication and authorization of application to the network
> control - SDNAuth only provides the place where a network control can find
> policy but applying policy is out of the scope of SDN auth
> - Authentication and authorization of two controllers (exchanging
> policy is out of the scope)
> - Optimization of authentication and authorization of network elements
> + user at the same time
All of this seems very much internal-to-Autonomous-System. There are a bunch
of solutions which exist already, many of which are aimed at tty/CLI-style
logins. (Radius, tacacs and kerberos come to mind). Some many inappropriate
for the m2m-type communication you envision; or may require some profiling to
make work.
> - Authentication and authorization of an app to a security function
> service such as a firewall (applying any rules on the firewall is out of
> scope but authentication and showing the place of policies are in scope) :
> SDN/NFV authentication
I don't know what the scope of "app" here is, but I think that perhaps it
means that my mobile phone can ask some firewall that is (perhaps) not within
my enterprise for access. Such as when I'm roaming at your office.
But, even if it turns out that I'm at my office, the firewall is not *my*
firewall (I'm not the admin), it's my enterprises' firewall.
As such, this relates to such things as the "authenticated-firewall-traversal
(AFT)" problem (and WG) of 2 decades ago
<http://datatracker.ietf.org/wg/aft/charter/>, and also to much more modern
things like PCP, RSVP, uPNP and the like. It would be wonderful if we could
solve the problems of being able to scalably authenticate to network elements
for the purpose of either reserving bandwith (in a positive, I care about
this traffic way), and also for deflecting traffic (in a negative, please
filter this DDoS traffic out further away from my constrainted pipe).
On this, you seem to have a totally different set of requirements different
From the SDN space, and I don't see how it matters that SDN is involved at
all.
I think that you should remove this item from your SDNauth scope; we've been
through this dicussion multiple times now. It's not that it isn't important;
its really really really important, but it has a very different set of
constraints.
> You can find more information about this group on the info page.
> If you are interested on the scope of this group, please feel free to join
> clicking on the following address:
> < https://mail.rozanak.com/mailman/listinfo/sdnauth >
> ---------------------------------------------------------------
> We had some discussions on "secauth" at IETF and would like to continue the
> discussion with interested folks in an external group. The goal is to
> prepare the final draft of charter for possible BoF.
> This group also plans to have an implementation by using Openstack as a
> based. Later, I will update the info page of the group with the link to a
> project repository.
> Thanks,
> Best,
> Hosnieh
> P.S. Please note that the group is public including its archive.
--
Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
-= IPv6 IoT consulting =-
Attachment:
signature.asc
Description: PGP signature