My replies to Bernards Comments

[Avi Lior <avi@bridgewatersystems.com>]

Hi Bernard,

Thank you for taking the time to read and review the Bandwidth draft.
Please see our comments inline.

snip

> Section 3
> 
> The Ingress and Egress Bandwidth attributes are defined as 32
> bit values expressing Bytes per second.  Is this really the 
> right way to express bandwidth?  This attribute has been 
> implemented in Metro Ethernet networks where bandwidth of 10+ 
> Gbps is available, and we are seeing an order of magnitude 
> increase every 3 years. I'd suggest that we might want to 
> think of alternative scales such as Kbps, as well as a 64-bit 
> value instead of 32-bits.

We agree.  The bandwidht 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.
 
> 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.
 
> While I'm fairly clear about the usage of the bw attributes
> in Access-Accept, CoA-Request and Accounting-Request packets, 
> I am not as clear about the meaning in an Access-Request.  In 
> that situation "bandwidth available" seems unclear to me.  Is 
> this a measurement of the negotiated rate?  Of the "slot 
> time" available to a station?  Of the available throughput?  
> There are highly transient measurements.  If we are looking 
> for flow data then there are better ways to get it.

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

 
> Similarly, in Accounting-Request packets I can see echoing the bw 
> values from the Access-Accept.  But a dynamic measurement seems 
> redundant since we already support attributes for octets in/out.

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

This is because if the user requests a certain bandwidth and that bandwidth
is allocated then even though the user did not use the bandwidth, the
operator may still want to bill them for the requested bandwidth.  The
operator is billing the user for providing the pipe.

In fact many operators bill the user based solely on the bandwidth
capability and not how much bandwidth they actually use.


>    Note 1 :  If Ingress-Bandwidth appears alone in an Access-Request
>       packet then the NAS is indicating that it only supports
> symmetric
>       bandwidth allocation.  Therefore, Egress bandwidth SHOULD NOT
>       appear in the corresponding Access-Accept packet.
>    Note 2 :  Bandwidth-Profile-Id MUST NOT appear in a RADIUS packet
>       that contains either or both of Ingress-Bandwidth or
>       Egress-Bandwidth attributes.
> 
> The Note 1 seems to imply that putting bw attributes in an
> Access-Request is for capability negotiation.

Yes it is signalling that its only capable of doing symmetric.  We are just
trying to be complete here since there could be a case where a device is
only capable of doing symmetric.

> 
> Section 5
> 
> Why does this document require new vlues for Acct-Terminate-Cause?

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

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

Other SDOs have been including a VSA for that purpose -- for example a MIP
handoff creates Stop Start records. It helps mediation process when this
type of information is included.


> Section 6
> 
> Surely there must be *some* security implications of these
> attributes, no?

It would be nice to get help here.  

Some things that come to mind:

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.

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

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