Re: call for discussion on draft-heinanen-radius-pe-discovery-03.txt

Bernard Aboba writes:

 > [BA] Preconfiguration may not necessarily be required but there
 > are some pitfalls.  For example, it possible for the RADIUS server to
 > return a Tunnel-Password attribute as indicated in RFC 2868.  However,
 > the security of that mechanism is somewhat suspect, so it would be
 > better if it was not necessary to use it.

there is no need to return a tunnel-password attribute in the pe
discovery application.

 > [BA] The point is that there should not be an expectation that existing
 > RADIUS servers can be implement this specification merely by making
 > changes to the RADIUS Dictionary.  That needs to be stated clearly.

i'll state that in the next version.

 > It's also worth mentioning that most RADIUS Dictionaries only support
 > attributes of types defined in RFC 2865.  That means that Attribute
 > structures are typically only supported within the "String" type, and
 > inherent server support for that is limited.

the pe-list attribute is of type "string".

 > The major problem with stateful application of RADIUS (such as
 > simultaneous usage checks) is the unreliability of RADIUS accounting
 > traffic.

radius accounting packets are acknowledged.  so the pe knows if the
radius server has received the message and, if not, it can keep on
trying.  if connectivity is broken between the pe and radius server for
a long period of time, the keepalive mechanism will cause the sites of
the pe to be flushed from radius database.

 > [BA] This is problematic because RADIUS Accounting retransmission behavior
 > is not specified -- and therefore the loss of an interim packet may not
 > indicate a "failure" at all -- but just ordinary packet loss.  In any
 > case, the proper behavior of a RADIUS client not receiving a Response is
 > to initiate failover.  So the packet may just have been sent to an
 > alternative RADIUS Accounting server and received there.

that is what my draft specifies so i don't see any conflict there.

-- juha