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

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 May 2003 12:57:46 -0700 (PDT)

>this was already fixed in 04 that i announced to the list a few weeks
>ago.   the terms conflicting 2486 are gone.

[BA] Good. If there is a need to update 2486 for some reason, this can be
accomplished within the RFC 2486bis effort.

>my draft doesn't use radius for service discovery.  the service type in
>the radius request that the pe makes is VPN-Login.  so the pe already
>knows what service to ask for.

[BA] My error, sorry.

Use of RADIUS for discovering VPN endpoints is OK, and is described
in RFC 2868.  It is not even necessary to know what type of VPN is
desired, since this is returned in the Access-Accept.

>what comes to the security issue, it is not at all unreasonable to
>assume that there exists a security relationship between pes of a
>provider and the radius servers of the same provider.  it is in the same
>category than assuming that there is a security association between pes
>and their snmp management system.

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

>it is very common that radius requests have side effects.  any
>reasonable radius server on the market supports configuration of pre and
>post authentication hooks.  otherwise routine things like checking of
>simultaneous use would not be possible.

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

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 major problem with stateful application of RADIUS (such as
simultaneous usage checks) is the unreliability of RADIUS accounting traffic.  That
implies that the state on the RADIUS server can easily get out of sync,
and a mechanism needs to be provided to resynchronize.  In the case of
simultaneous usage checks, the accounting info is typically supplemented
by telnet-based access or a proprietary SNMP MIB.  The end result is that
stateful uses typically have implementation-dependent components,
and therefore don't interoperate well.

This could be addressed either by specifying the required transport
behavior or by providing an interoperable resynchronization mechanism.

>i don't see the use of Interim Accounting for failure detection a big
>protocol abuse.  that request is normally used to keep accounting
>information as accurate as possible in case the nas fails and is not
>able to send stop accounting request.  its use here is close to that
>purpose.

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

>thanks for the "joke".

[BA] RADIUS security problems are not a joke.  The security of RADIUS was
marginal at the time it was proposed, but by now it has become quite easy
to crack if the implementation or deployment configuration has even the
slightest weakness.  This includes known plaintext attacks similar to
those which can be carried out on WEP, dictionary attacks on the RADIUS
shared secret, and even brute force attacks on the (sub-standard) ciphers
used to hide attributes.

My advice is to consider the security weaknesses present in RFC 2868 and
include potential mitigating measures in the Security Considerations
section.  An example of such a section is available here:

http://www.drizzle.com/~aboba/EAP/draft-aboba-radius-rfc2869bis-22.txt

>that would include some "concerns" regarding the draft, because the one
>i now replied to was empty of them.

[BA] Overall, I think that the draft has value and its purpose is
within the precedent established in RFC 2867-2868.  Given that RADIUS
already supports configuration of VPNs and VLANs, it is not much of a
stretch to see it being used for PPVPN configuration.

However, there are things that RADIUS implementations cannot be guaranteed
to do well, primarily because of the lack of a transport and failover
specification, and limitations in the original security design.

The question is whether potential implementors will be ok with the changes
that might be necessary to address these issues.  An example would be use
of IPsec to protect the RADIUS exchanges,  or the specification of
required retransmission behavior.

These changes will inevitably make the implementations more complex and
expensive -- but will also make them more reliable and secure.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 20 May 2003 13:14:51 -0700 (PDT)

>I'm no radius expert, but I think  what Bernard Aboba is objecting to is
>the proposed procedure by  which PEs seem to register  and unregister
>themselves dynamically in RADIUS  as supporters of a particular  VPN
>instance.  This is what he means by "service discovery", I think.

>"Service discovery"  doesn't mean figuring out  what service to  ask for,
>it means finding, from  a dynamically changing list of  servers, the
>servers to connect to at some given time.

>I think that using RADIUS to get  a preconfigured list of PEs attaching
>to a given  VPN is  probably  unproblematic, but  trying  to use  it to
>maintain dynamically learned PE/VPN associations  is probably
>overextending it, as  it is something that RADIUS is not typically used
>for.

I think this is a reasonable statement of my concern.  RFC 2868 allows a
PE to obtain a preconfigured list of potential VPN endpoints
and associated configuration. However, the PE then needs to
choose between those potential endpoints, and can only bring them up and
down within the context of a session.

Now it is possible to do dynamic authorization and disconnection, as
specified in draft-chiba-radius-dynamic-authorization-20.txt. But this is
under the control of the RADIUS server, not the PE or CE.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 May 2003 10:57:00 -0700 (PDT)

>Bernard is one of the main contributors to the RADIUS development, from
>his point of view this is not limited, it is applying a tool when RADIUS
>is proposed to be used in a new context, which I would think is highly
>appropriate.

Given what has already been done in RFC 2867-2868, use of RADIUS for VPN
configuration and setup isn't new. Such an application is well
established.  So I don't really see anything intrinsically wrong with
using RADIUS to authenticate and configure (PP)VPNs.

I'm just trying to understand what changes to the RADIUS protocol are
required to meet *all* the requirements for this application, not just
configuration and authentication of (PP)VPNs. If configuration and
authentication of (PP)VPNs were all we are talking about then this might
be supported by just allocating some new values of the attributes defined
in RFC 2868 (e.g. new Tunnel-Type, etc.), without adding any new protocol
messages or even attributes. That's all we had to do in order to support
RADIUS-configured VLANs.

So by nature this discussion is going to focus on the "fringe" areas of
the proposal -- since the core of it is well within established uses of
RADIUS. The goal is to see if *all* the requirements can easily be
accomodated within existing facilities or not -- and if not, how far we
have to go in order to accomodate the needs.

To that end, it would be helpful for people to take a look at some of the
latest RADIUS drafts, in particular:

http://www.ietf.org/internet-drafts/draft-chiba-radius-dynamic-authorization-20.txt
http://www.ietf.org/internet-drafts/draft-congdon-radius-8021x-29.txt
http://www.ietf.org/internet-drafts/draft-aboba-radius-iana-07.txt

In draft-chiba, dynamic authorization facilities are added that allow the
RADIUS server to reprovision a session. This is a bit tricky in that the
user may not necessarily know that their session has been reprovisioned --
if the VLAN or VPN were changed in mid-stream, for example.  So there
needs to be some user-NAS signalling in some cases and that may be media
dependent.

In draft-congdon, RADIUS is used to provision VLANs. This can be used to
provide layer 2 mobility, or perhaps just to allow centralized
MAC-address, user or port-based VLAN administration.

The RADIUS IANA considerations draft outlines the procedures necessary for
allocation of RADIUS packet types, attributes and values.  This has been
tightened up somewhat compared to what was in RFC 2865.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 May 2003 11:10:30 -0700 (PDT)

> I wonder what the results would be if the other discovery and signalling
> drafts defined by PPVPN so far were evaluated using a "Protocol Abuse
> Rating Scale (PARSE)"? I suspect that most of them (if not all) would
> also receive 2's and 3's.

Please note that I do not consider use of RADIUS to authenticate and
configure (PP)VPNs to constitute protocol abuse.  RFC 2868 describes the
use of RADIUS to configure and authenticate VPNs.  So such a use is well
established.  My issues were with other parts of the proposal, such as
modifying RFC 2486, using Interim Accounting as a failure detection
mechanism, and attempting to do dynamic re-authorization in a manner not
supported within draft-chiba-radius-dynamic-authorization-20.txt.  I'd
hope that discussion in this forum will focus on figuring out how to
meet the requirements given existing facilities (RFC 2865-2869 + 3162,
2869bis, draft-congdon and draft-chiba).

>I hope this is not true, but if you think it is it would be helpful to
>do that evaluation, cause we would need it.

If you really think that completed specifications in this WG are unlikely
to work reliably or securely in practice (that's a "2") or could be done
better using an alternative mechanism (that's a "3") then I'd certainly
hope that the problems will be identified and fixed *prior* to sending
them off to the IESG.  Otherwise, you shouldn't be surprised to receiving
the predictable response -- "fix it".

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 23 May 2003 09:36:16 +0300

Bernard Aboba writes:

 > My issues were with other parts of the proposal, such as
 > supported within draft-chiba-radius-dynamic-authorization-20.txt.  

i'm not proposing any modifications to the protocols described in RFC
2486 and RFC 2866.  all packets and procedures remain as it.  i'm simply
describing how those protocols are used in a pe discovery application.
neither is this application requiring any dynamic changes to user
sessions as covered by draft-chiba-radius-dynamic-authorization-20.txt.
in particular, the pe discovery application described in my draft does
not require or need the radius server to send any unsolicited messages
for any purpose to the pes.

 > 2869bis, draft-congdon and draft-chiba).

i don't see any conflict with my draft and rfc 2486 and rfc 2866.  if
you do, please describe what that are.  in particular, those rfcs do
allow the ras to send re-authentication and interim accounting requests
at any time.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 23 May 2003 09:49:13 +0300

> messages or even attributes. That's all we had to do in order to support

as i said in my previous message, the pe discovery application does not
require any changes to radius protocols nor do i propose any changes.
of course radius protocols could be improved in various ways, but those
improvements are not mandatory in order to make pe discovery work.

 > have to go in order to accomodate the needs.

i have tried to meet all requirements using existing facilities.  since
radius protocol does not include any keepalive mechanism between the nas
and the server, the pe discovery application uses interim accounting
requests for that purpose.  that is, however, just a particular
application of the radius accounting protocol that doesn't change the
protocol itself.  if you have a better means to achieve the same goal,
i'm more than happy to change the draft accordingly.

 > RADIUS server to reprovision a session. 

there is no such need in the pe discovery application that i have
described.

 > tightened up somewhat compared to what was in RFC 2865.

the latest version of my draft
ftp://lohi.eng.song.fi/tmp/draft-heinanen-radius-pe-discovery-04.txt
which details the protocol, defines one new service type (VPN-Login) and
one new attribute (PE-List) that of course need to get assigned code
points according to the iana procedures.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 23 May 2003 10:17:28 +0300

> better if it was not necessary to use it.

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

 > changes to the RADIUS Dictionary.  That needs to be stated clearly.

i'll state that in the next version.

 > inherent server support for that is limited.

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

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

 > alternative RADIUS Accounting server and received there.

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

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 23 May 2003 11:06:23 +0300

if using radius accounting messages as pe keepalive messages is
something that people don't like in the draft then we can easily get rid
of the whole pe keepalive business by requiring that each pe must
re-authenticate each of its vpn sites every N hours.  if i remember
correctly, this is how it was in the first version of the draft, but
then introduced the pe keepalive concept in order to improve
scalability.

if a provider has 3,600 vpn sites in its network and N=1, radius server
would get on the average one authentication message per second from the
pes.  that may still be acceptable.  but if the number of vpn sites
grows to, say, 36,000, then most likely N would need to be made bigger,
e.g., 10 or 24.

to me even N=24 would be acceptable, since in vpn application getting
rid of a pe that no longer contains any sites of a vpn is not usually
that urgent matter.  if it in some case is an urgent matter, then the
network management application could be used to trigger valid pes to
immediately re-authenticate the sites of a vpn and thus learn the
currently valid pe list.

if this sounds better to people, i can edit the draft accordingly.

-- juha

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 23 May 2003 04:58:30 -0700 (PDT)

> re-authenticate each of its vpn sites every N hours.

Re-authentication can be accomplished by sending a Session-Time attribute
with Termination-Action=1.  However, there is also work underway (for
prepaid) to support re-authorization via the "Authorize Only" Service-Type
supported in draft-chiba.

> if i remember

Not sure why using Interim Accounting would improve scalability as
compared with re-authorization.

> grows to, say, 36,000, then most likely N would need to be made bigger,

With this many sites you will definitely need to require some improvements
in RADIUS client retransmission behavior.  I've seen situations
with 3K+ RADIUS clients where the network could not come up again after a
power failure, due to overload on the RADIUS server.  Exponential backoff
+ jittering would have helped, and we'll be putting together a document to
provide guidelines on how RADIUS client should behave.

> immediately re-authenticate the sites of a vpn and thus learn the

You can use draft-chiba to send a CoA-Request with Service-Type="Authorize
Only" in order to make this happen.

---

From: Juha Heinanen <[email-masked]>
Date: Fri, 23 May 2003 15:37:18 +0300

> supported in draft-chiba.

yes, that way the pe would know when it needs to re-authenticate its
sites.

 > compared with re-authorization.

as it is currently written, the pe is not required to authenticate all
its sites, but just to send any message to the radius server at least
every N minutes.  i proposed to use an accounting message for that
purpose, but it could as well be re-authentication message.

 > provide guidelines on how RADIUS client should behave.

the text mentions that pes should use exponential backoff. i guess that
it is standard practice in any protocol.

 > Only" in order to make this happen.

yes, perhaps so.  however, i would not like to make mandatory anything
that is beyond current standards.  optional recommendations based on
drafts are ok.

so where are we now?  are people happy if i make another version of the
draft, where the pes always re-authenticate all their sites every N
minutes and accounting keepalives are not used?  if so i can do it and
publish the new version as wg document.

-- juha

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 23 May 2003 06:01:50 -0700 (PDT)

> purpose, but it could as well be re-authentication message.

Or re-authorization (no authentication required) as in pre-paid.

> it is standard practice in any protocol.

Yes, but unfortunately not in RADIUS. We'll be producing a separate
document to provide details on how that is done.

> that is beyond current standards.  optional recommendations based on

draft-chiba is going to RFC soon. Support can be optional.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 23 May 2003 16:46:21 +0200

> document to provide details on how that is done.

In any case, I would suspect that for some period of time the number of typical 
PPVPN nodes will lag behind the state of the art in number of access nodes 
hitting a radius server. If not, then PPVPN will simply become an additional 
driver for making these improvements (improvements that of course need to be 
done anyway).

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 May 2003 06:12:53 -0700 (PDT)

> for any purpose to the pes.

My question is how dynamic changes to user sessions are being handled.

The draft states that:

   In addition to the above manually configured information, Radius
   keeps dynamically track of the PEs of the VPN as described below
   (Protocol Operation)."

Typically, once the attributes described in RFC 2868 are sent, the RADIUS
server does not monitor the resulting tunnels. So I'm not clear
exactly what the RADIUS server is expected to do to "dynamically track".

I'm also still unclear about whether the CEs also use RADIUS.

For example, the draft states "It is envisioned that a similar Radius
based mechanism can be used by CEs of a CE-based VPN to discover the other
CEs of the VPN."

The problem is that RADIUS is not a protocol in which users (CEs)
participate directly to discover other users.

With respect to the following paragraph:

"  When a CE is to be connected to a VPN at a PE, the PE issues a Radius
   Access-Request using the user name and password of the CE.  The PE
   has either learned this information from the CE via an authentication
   protocol, for example, 802.1x/EAP, or it has been configured in the
   PE."

RADIUS either assumes that the user (CE) performs authentication, or
that a Service-Type="Call Check" is being performed where the user (CE) is
authorized based on attributes such as Called-Station-Id and
Calling-Station-Id (e.g. telephone number or MAC address identification).
Is the "configured in the PE" case equivalent to a Call Check, and if so,
how is the CE identified?

In the following paragraph:

   If a PE wants for some reason to get from Radius an up-to-date list
   of PEs in a particular VPN, it can at any time issue a new Access-
   Request for any one of its CEs that belongs to the VPN.

This seems like it is describing a re-authorization request. Is the intent
for the CE to re-authenticate as part of this Access-Request?

In terms of the attributes necessary to implement this draft, I'd suggest
reuse of the RFC 2868 Tunnel Attributes, if possible.  Of the top of my
head, I'd recommend the following:

a. Definition of new Tunnel-Type values as appropriate.
b. Reuse of existing Tunnel-Medium-Type values.
c. Transmission of the VPNID in the Tunnel-Private-Group-Id Attribute.

The question with RFC 2868 attributes is if they can be extended to
allow for multiple tunnels to be set up.

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 27 May 2003 20:05:12 +0300

> exactly what the RADIUS server is expected to do to "dynamically track".

by keeping dynamically track i mean that radius server keeps state based
on access requests and stop accounting requests about which pes
currently have members in which vpns.  radius server does not and should
not know anything about the resuiting tunnels.  the procedure on how
this keeping track takes place has been defined in the draft.

 > I'm also still unclear about whether the CEs also use RADIUS.

in the protocol described in the draft the ces have nothing to do with
radius. 

 > based mechanism can be used by CEs of a CE-based VPN to discover the other

that is a referral to a possible other schenario which is not covered
nor is within the scope of the draft.  i agree that it is confusing and
will remove the sentence from the next version.

 > how is the CE identified?

no, it is not equivalent to call check.  the pe simply performs the
authentication of the ce on behalf of the ce if the ce itself doesn't
support an authentication protocol like 802.1x, i.e., the username and
password are in that case configured in the pe instead of the ce.

 > for the CE to re-authenticate as part of this Access-Request?

yes.

 > allow for multiple tunnels to be set up.

the pe needs from radius a list of ip addresses of other pes.  if there
is an existing attribute that can return that, it is fine with me to use
it.

i have been oin vacation a few days and will issue a new version of the
draft during the coming weekend.  i do not claim that the new draft
would be ready to be published as an rfc but it should be ready enough
to be published as working groupo document.  then detailed work on it
can beging.

-- juha

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 May 2003 09:42:52 -0700 (PDT)

> for the CE to re-authenticate as part of this Access-Request?

I should also mention that RADIUS clients do not initiate
re-authentication or re-authorization requests "at any time". They only do
so under direction of the server.  For example, re-authentication can
occur after expiry of the time indicated in Session-Time, assuming that
Termination-Action=1 (RADIUS).  Alternatively, a server-initiated message
(CoA-Request) can result in the RADIUS client (PE) sending an
Access-Request.  So I'm curious as to whether these existing mechanisms
can be reused or whether something different is needed.

> reuse of the RFC 2868 Tunnel Attributes, if possible.

There is an RFC 2868bis effort underway, so it might make sense to contact
the authors and see if the needs described in the draft can be met:

http://www.watersprings.org/pub/id/draft-zorn-rfc2868bis-01.txt

For example, Section 5 of this draft says:

"If the RADIUS server returns attributes describing multiple tunnels then
the tunnels SHOULD be interpreted by the tunnel initiator as
alternatives and the server SHOULD include an instance of the Tunnel-
Preference Attribute in the set of Attributes pertaining to each
alternative tunnel.  Similarly, if the RADIUS client includes multiple
sets of tunnel Attributes in an Access-Request packet, all the
Attributes pertaining to a given tunnel SHOULD contain the same value in
their respective Tag fields and each set SHOULD include an appropriately
valued instance of the Tunnel-Preference Attribute."

So one question in my mind is under what conditions multiple tunnels will
not be interpreted by the tunnel initiator as alternatives, but rather as
distinct VPNs, which is what you want.

> Off the top of my

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 27 May 2003 20:11:42 +0300

> can be reused or whether something different is needed.

the intention is to use these existing mechanisms.  next version of the
draft will include session-time/termination-action stuff.

-- juha

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 May 2003 10:05:41 -0700 (PDT)

> password are in that case configured in the pe instead of the ce.

Having the PE fabricate a User-Name and Password exchange where in fact
no such exchange is occurring is not a good idea.

Clearly the PE must be identifying the CE in some manner so that it is
confident it is the correct CE, no?  Since there is no username and
password exchange, is there is some means for identifying the CE (a
MAC address? a port number?) Otherwise you really have no idea who the CE
is, or even who should be billed for the service.  The Call-Check Service is
designed for these kind of situations, where the CE is identified in some
way (e.g. by MAC address) but no authentication is done.

>  > for the CE to re-authenticate as part of this Access-Request?

OK. You might go ahead and say that explicitly.

> is an existing attribute that can return that, it is fine with me to use

Yes, there is. There is Tunnel-Client-Endpoint and Tunnel-Server Endpoint.
If used with a Tunnel-Medium-Type of 1 (IPv4) or 2 (IPv6) these Attributes
can contain IP addresses. Have a look at RFC 2868.

> can begin.

You might also want to chat with the authors of RFC 2868bis to see if they
can accomodate your need for multiple tunnels. That seems like the major
extension that is required to enable what you want to do.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 29 May 2003 17:41:52 +0300

> no such exchange is occurring is not a good idea.

this is how most vpn implementations work today, i.e., the vpn site
information is only configured in the pe.

 > confident it is the correct CE, no?  

as i said in above, in most vpn implementations today, the ces doen't 
identify them selfes at all.  in that respect my proposal in a big
improvement, because if the ce is 802.1x capable, it can identify
itself.

 > can contain IP addresses. Have a look at RFC 2868.

i'll take a look at it.  which attribute to use is a minor issue can be
decided later.

-- juha

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 29 May 2003 10:06:17 -0700 (PDT)

> identify them selves at all.  in that respect my proposal in a big

In RADIUS "Call Check" or "Authorize Only" exchanges, the PE need not have
an identification exchange with the CE.  However, the PE still needs to
identify the CE somehow in the RADIUS Access-Request.  So even if there is
no identity exchange, you still need to put something into the User-Name
attribute.  In a "Call Check" service that could be an L2 address (phone
# or MAC address) or it could be a user name.  Ideally it's the identity
that you determine somehow by the alternative auth mechanism (e.g. OSPF
MD5).