Re: Fwd: [Nea] Re: use of a design team to develop requirements

["Mike Fratto" <mfratto at gmail.com>]

> Why in the world should IETF standardize a protocol that enables
> networks to impose whatever policies they wish on hosts, given that we
> already understand how this could be harmful to the Internet and
> counter to IETF's organizational goals?

I think I can safely say that the purpose of NAC is NOT to impose
anything on a host. The purpose of NAC is to allow a network owner to
control access to it's resources, which is well within the network
owner's right. Nothing more and nothing less. If a host is not upto
snuff and the network owner requires certain actions to take place,
the host can *choose* not to participate in the network. There is no
forcing anything. There is no other social, racial, national, or
political agenda. And no, I don't agree with your claim that NAC is
harmful to anyone

I can't speak for the IETF at large, but off the top of my noggin here
are some other examples of potentially draconian standards,

1) RADIUS is an IETF standard that past muster and is used to control
user access. RADIUS imposes the rule that if you can't authenticate,
you don't get access. If a user can't authenticate to a RADIUS server
for any reason, including not supporting any required authentication
mechanisms, then they are denied access. Heck, if you do authenticate
and are part of a group, the network can segment you.

2) PKIX is a whole suite of standards. It too can be used to grant or
deny access to a number of resource via the presence or absense of
attributes or heck, knowledge, or lack of knowlege, of the signing
certificate.

3) PPP.  Is that also the tool of oppression? Ya know, if a host
doesn't accept an offered IP address or other configuration option,
they don't attach the network. To think a network owner might want to
enforce that!

4) IKE V1 maybe the worst offender of all. If the peers don't find
agreement on proposals in the first round of offers, communications
stops. Period. There is no negotiation.

By your reasoning, none of them should have been in the IETF either.

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea