RE: Pls check: draft-carroll-dynmobileip-cdma-04.txt

[Bernard Aboba <aboba@internaut.com>]

> I disagree with the current policies on individual submissions that have
> the effect of violating normative requirements of Standards Track
> protocols.  I believe that such RFCs should never be published, even as
> Informational with suitable "disclaimer" notes.  The effect of allowing
> this practice is to allow (even encourage) disparate "dialects" of
> Standards Track protocols. We're not here to build a Tower of Babel.

Authentication, Authorization and Accounting protocols are built on a very
fundamental idea:  that AAA servers can unambigously allow or deny access
to the network.

RFC 2865 is very clear on this.  For example, Section 2 states:

"If desired, the server MAY include a text message in the Access-Reject
which MAY be displayed by the client to the user.  No other
Attributes (except Proxy-State) are permitted in an Access-Reject."

Table 5.44 of RFC 2865, makes it clear that inclusion of a vendor-specific
attribute in an Access-Reject is a MUST NOT:

   Request   Accept   Reject   Challenge   #    Attribute
   0+        0+       0        0+          26   Vendor-Specific

Given that RFC 2865 typically uses SHOULD or SHOULD NOT language,
the use of a MUST NOT is a sign that this practice was considered
fundamentally unacceptable.

There is a simple reason for this: an Access-Reject denies access to the
user, and that action must be understood non-ambigously by any NAS device.

Since an Access-Reject results in denied access, there is no service that
can be provided to the user, other than perhaps routing the
Reject message to the right NAS or explaining to the user why
they have been denied access.

Allowing an Access-Reject to provision a service is like redefining a
"Deny" filter to allow packets to pass through.  This is not just a garden
variety "bad idea" -- it's a fundamental re-definition of the concept of
access control.