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

All,

I agree with the remarks of Richard Spencer on this thread which
(paraphrased) stated that a test of protocol abuse should be applied to all
candidates being proposed for this purpose.  But why is this 'abuse' test
suddenly being applied here and in a restricted sense?  I can see far more
serious layered network architecture abuse happening, but I'll refrain from
going into this on this thread.

If we want to address the VPN problem properly (so I am including layered
architecture considerations here) I believe we have to do the following
things:

1	Recognise that IP and MPLS are independent layer networks that
provide different networking modes and hence different behaviours....IP is
cnls and MPLS is co pkt-sw (else why bother with MPLS?).

2	A corollary of 1 is that MPLS requires consistent/independent
addressing of access points.  It does indeed get these today.  However, this
is done unconsciously(?) and they are determined by the specific signalling
protocol used as a combination of a v4 address + some further 'tunnel IDs'.
These addresses *do not* belong in the same space as the IP v4 addresses,
and (sadly) they are different for each instance of signalling
protocol.....the correct requirement here is that the addresses should be
consistent and independent of the signalling protocol (inc case of none) as
they belong to the *data-plane*, ie they identify the access points of the
MPLS network.

3	We now need to break the VPN problem up into 2 distinct parts:
(i)	the discovery/signalling aspects that belong to the *server* layer
technology (either IP or MPLS say, but it could be *any* technology);
(ii)	the (most usual) requirement to distribute *client* layer
reachability information, ie which client layer network addresses lie where
wrt to the access points that delimit the server layer topology.

4	(i) above is *common* to all VPN types and should be independent of
the client.  So we need a method of associating a set of server layer access
point addresses with a VPN ID and creating topological mesh of trails
between these access points.  Now this would provide the most basic server
layer VPN service.  The analogy today would be a FR or ATM VPN.  There is no
reason why this could also not be applied to MPLS, and in fact a SP offering
a transit MPLS bearer service would be an example of such a basic VPN.  It
should also be obvious that this observation can also be extended to
(creating basic VPNs in) co cct-sw mode technologies like SDH and OTNs.

5	So I see Juha's draft being a *common* discovery functional solution
that can apply to *any* VPN type.  It also allows one to choose/use an
appropriate signalling protocol that is independent of the discovery
function and appropriate to the data-plane technology/mode being
considered.....which IMO is a very good thing.

6	(ii) above is something else entirely.  It sits above the common
discovery/signalling topology creation of the server layer and strictly
belongs in the client layer network.  In fact, in a basic server layer VPN
this is exactly what happens, ie the client layer network is responsible for
the distribution of its own reachability information.  Indeed, this option
should be allowed because its the essence of a basic managed BW VPN service,
and no doubt some customers will still want this.  Currently we seem to have
completely overlooked this potential service opportunity.

7	The alternative of course is for the SP to take on this 'client
layer reachability/distribution' function as some 'value-add' proposition.
This is what rfc2547 is all about in the case of an IP client.  Here, the SP
uses his own BGP protocol to provide this function. This seems natural as
BGP was indeed developed for an IP layer network.  But this does not have to
be a restricted case.  All network modes (be they cnls, co pkt-sw or co
cct-sw) can use a distributed routing protocol......in fact addressing and
routing are the 2 most fundamental functional components that *any* layer
network must have to scale/work.  And herein lies the problem for an
ethernet client....its does not have either of these components as one would
understand them in the context of a properly specified WAN technology.

8	So, looking for a SP value-add role in client layer reachability
distribution, we seem to have 2 options:
-	migrate to a generic solution for the distribution of *any* client
layer's reachability information.......this was my point above that BGP does
not have to be restricted to an IP client only (and I have seen at least one
person (Muneyoshi I believe) sort-of saying this);
-	or use (in some way by the SP) the intrinsic client layer
reachability distribution.....in the case of ethernet this is simply
data-plane learning, though it brings the downside of loop prevention (which
IMO is a problem that can never be properly/fully sorted by appeal to the
server layer proxying for this....as indeed the many threads on this have
already discussed).


So in summary:
-	I support the direction being advocated by Juha's draft, ie
identifying the server layer discovery/signalling function as an independent
and common issue requiring its own solution that can be recursively applied
to *any* of the technologies falling 3 networking modes of cnls, co pkt-sw
and co cct-sw;
-	the signalling protocol that can be used is completely independent
of the above;
-	for 'proper' layer networks that have well defined addressing and
routing functions, there seems no reason why a common client layer
reachability solution could not be defined as a SP value-add proposition, eg
BGP may be a good solution here;
-	for an ethernet client.....well I am not sure.  Ultimately it can't
really scale/work as it is functionally deficient.  All I will say is this:
There is a massive difference between recognising that ethernet is an
important CPE interface and then (somehow) wrongly interpreting that
observation to mean we must build WAN solutions based on ethernet
technology....these are quite different points.

My key objective in going through the above is to try and get us all to
think a little bit more architecturally about the problem.  I hope there are
some reading this who can recognise that there are benefits from doing this.

regards, Neil


> -----Original Message-----
> From: Rick Wilder [mailto:[email protected]]
> Sent: 20 May 2003 05:47
> To: [email protected]
> Subject: call for discussion on
> draft-heinanen-radius-pe-discovery-03.txt
> 
> 
> 
> 
> Below is feedback which raises some concerns about
> draft-heinanen-radius-pe-discovery-03.txt.
> 
> I invite your participation in a two-week email discussion of this
> feedback, after which a decision will be taken on whether the draft
> should become a working group document.
> 
> Rick
> 
> 
> 
> Bernard Aboba <[email protected]> writes:
> 
> > Overall, I believe that there are things that this draft 
> does that are
> 
> > genuinely useful and that are within the scope of legitimate AAA 
> > activity. Fundamentally, I think that this draft is about 
> > authenticating and providing configuration of (PP)VPN 
> connections -- 
> > which fits reasonably well with previous work in authentication and 
> > configuration of VPNs -- RFC 2867 and 2868.
> 
> > That said, there is also a lot of material in this draft which is 
> > inappropriate and in some cases dangerous, and so if it is 
> allowed to 
> > proceed it must be with the understanding that it will have 
> to change 
> > significantly in order to become acceptable.
> 
> > Since the same thing could be said of many other 
> AAA-related Internet 
> > Drafts, it is worthwhile to try to provide some perspective. Below 
> > find a proposal for a Protocol Abuse Rating ScalE (PARSE):
> 
> > 1 = An idea so bad that it will not work at all, and anyone 
> who tries
> it
> >     will likely to be weeded out by Darwinian Selection.  
> Mike O'Dell
> has
> >     suggested that we not choose to fix things in this 
> category so as
> >     to allow evolution to continue to work, since ideas in this
> >     category are so toxic that the host dies quickly.  An example of
> >     this would be attempting to use AAA as an inter-domain routing
> >     protocol.
> > 2 = A bad idea that will work well enough to get significant
> deployment,
> >     but will show intermittent failures and poor 
> interoperability and
> >     therefore can cause significant damage which the IETF 
> will have to
> >     clean up later. For things in this category, darwinism 
> may not be
> a
> >     satisfactory solution, since the host may not know they are sick
> >     until they have spread the problem to a significant population.
> >     In general, I think we need to be more strongly discouraging
> >     such things rather than hoping they will go away.  An example of
> >     this would be attempting to use an unreliable AAA accounting
> >     protocol for usage-based billing.
> > 3 = Garden variety abuse -- there are better ways to do this,
> >     but one could conceive of it working. This category is like a
> >     chronic condition in that in the long term these kind of
> >     mediocre ideas can degrade the quality of the Internet 
> experience,
> >     and lead to shortened lifespan for adopters, so that education
> >     and discouragement is appropriate.
> > 4 = An appropriate use with lots of potential security
> >     vulnerabilties. Things in this category can be fixed, but
> >     implementers will undoubtedly take the easy way out. 
> The original
> >     RADIUS RFCs [RFC2865]-[RFC2869] fall into this category. 5 = An 
> > appropriate use of where there is some evidence of
> >     real thought about security. In AAA, I unfortunately
> >     cannot think of an example that fits in this category :)
> 
> > In terms of this draft, portions appear to be a 2 
> (Discovery) and some
> 
> > parts would be a 4 (authentication and configuration). Note that 
> > Section 2 attempts to update RFC 2486, which is not good. There is 
> > currently an effort to do an RFC 2486bis (talk to 
> > [email protected]) so I'd recommend piggybacking on that 
> instead. 
> > Use of RADIUS for service discovery is a bad idea for many reasons, 
> > not the least of which is that RADIUS security presumes a 
> pre-existing
> 
> > security association between the RADIUS client and server.
> 
> > Use of RADIUS for authentication and configuration of (PP)VPNs is 
> > within the scope of things envisaged in RFC 2867-68. Similar things 
> > were done in draft-congdon with respect to dynamic configuration of 
> > VLANs as well so there is some precedent.
> 
> > Section 5.1 puts constraints on the implementation of the RADIUS 
> > backend database, and appears to require that RADIUS servers be 
> > stateful (which most current implementations are not).  So 
> this rates 
> > a 2.
> 
> > In Section 5.4 Interim Accounting is misused for failure detection. 
> > This is level 2 protocol abuse.
> 
> > Section 7 is a largely empty security considerations section so it 
> > contains no bad ideas and therefore rates a 4 :)
> 
> 
>