Re: Review of draft-lior-radius-bandwidth-capability-00.txt

[Bernard Aboba <aboba@internaut.com>]

> think of alternative scales such as Kbps, as well as a 64-bit
> value instead of 32-bits.

We agree.  The bandwidth attribute should be specified as an integer in
units of Kbps. This will give us 2^31 Kbps which is  2^34 bps or 10,000
Gbps.

There is no need to send extra bits.  We can even increase one order of
magnitude by making it an unsigned integer.  If need be we can also
specify Kbytes instead of Kilobits.

[BA] One thing to keep in mind is that bandwidth increases an order of
magnitude every 3 years.  10 terrabits might seem like a lot, but we are
at 10 Gbps now, and increasing by 3 orders of magnitude will only take a
decade.  So my recommendation is to look at a 64-bit attribute.

> Also, the explanations of the attributes in Section 3 are
> minimal. The RADIUS tradition is to explain the usage of the
> attribute here (see RFC 2865) rather than writing a large
> "architecture" section.

Section 2 is not an architecture section. It defines the behavior.
Section 3 describes the attributes.  Having said that, we could trim back
on the behavior and boaster up the attribute description. But please note
that the attributes in by themselves are very simple.  It's the behavior
that is complex in this case.

[BA] I guess I don't understand why the behavior is so complex.  As I
understand it, the goal here is to specify egress & ingress bandwidth
limits for a client.  Now those limits can be changed via RFC 3576, but
this is a static adjustment, rather than a closed loop control system,
correct?

We agree that we need a better description here.  We will take that as an
action item to tighten that part of the protocol.

[BA] My preference would be for the attribute to represent the rate
negotiated with the client.  For example, with 802.11g it might be
anything from 1 Mbps to 54 Mbps.  Or for Ethernet, anything from 10 Mbps
to 10 Gbps.  Note that the rate can change, so that the value in an
Accounting Interim might be different from the value in the Accounting
Start or STOP.

No actually.  We need to provide both the granted bandwidth and the
measured octets in/out.

[BA] So the value in the Access-Accept is merely being echo'd in the
Accounting records?  If so, that makes sense.

Actually we messed up that section somewhat. We only need one value -
either would work.

[BA] OK.

And really that value is a nice to have.  Mid session changes to bandwidth
are allowed (using COA) and MAY cause Acct Stop followed by Acct Start.

[BA] Yes, an RFC 3576 CoA-Request can cause that.

Having a reason in the Terminate Cause to indicate "session continue"
helps the back systems understand that the session is not really going
away. This may help some folks realize that the arrival of the Stop is not
the end of the session.

[BA] Can't Acct-Multi-Session-Id be used for that?  For example, RFC 3580
suggests that this be used to link together sessions created as a result
of a handoff.

MITM lowering the values in the Access-Request potentially cause the
operator to request lower bandwidth for the user.  To protect against that
we need to integrity protect the Access-Request.

[BA] Are you saying that Message-Authenticator is required in an
Access-Request including bandwidth attributes?  Today we require
Message-Authenticator for use with EAP & Digest, but not with legacy
mechanisms (PAP, CHAP).  I guess this draft won't be used along with
legacy mechanisms, so perhaps this would be ok.

MITM uping the request bandwidth causing a user to be billed for bandwidth
that they didn't ask for.  RADIUS already protects against this.


--
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/>