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

From: [email-masked]
Date: Wed, 28 May 2003 07:59:26 +0100

Bernard

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

RS> Although I think it is useful feature, I think it should be left up to
the service provider to decide whether CE authentication should be carried
out by RADIUS or not. For example, the RADIUS discovery protocol might be
used across an RFC2547 VPN network, and a particular CE-PE link might be
running OSPF with MD5, in which case the service provider may not feel it
necessary to carry out any further authentication. The PPVPN WG has not
defined a requirement that the actual discovery protocol itself MUST
authenticate CEs, although it is obviously an attractive option.
 
 > 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.

RS> There is a difference between attributes that should be signalled using
a signalling mechanism, and attributes that should be discovered using a
discovery mechanism. The PPVPN group is yet to agree on exactly which
attributes should be signalled and which should be discovered. However, the
PPVPN WG has not identified the need to use the discovery mechanism to
identify the tunnel type or the PSN type, and therefore none of the
discovery mechanisms defined to date include these attributes in the
discovery process. In my opinion the discovery mechanism should discover the
minimum amount of information required to allow signalling to take place,
i.e. a list of PE IP addresses belonging to the same VPN. 

Re-using some of the attributes from RFC2868 such as Tunnel-Client-Endpoint
and Tunnel-Assignment-ID (which looks more appropriate than the
Tunnel-Private-Group-Id you suggested as multiple tunnels may exists between
endpoints) is probably a good idea. However, I don't think one should expect
to be able to make some changes to RFC2868 and use that instead of Juha's
draft. RFC2868 describes attributes for setting up different types of
tunnels across different PSNs, Juha's draft is intended to be a simple
mechanism for discovering VPN endpoints only.

Richard

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 May 2003 04:31:34 -0700 (PDT)

> Although I think it is useful feature, I think it should be left up to

That's fine. A RADIUS "Call Check" assumes that the user is authenticated
by another means (e.g. OSPF MD5), so there are no authentication
attributes in the Access-Request. But it *does* require that the CE be
identified in some way. That typically is via an L2 address, but it
could be something else. I'm just asking what uniquely identifies the CE
in this case. Given that there is no authentication exchange occurring,
it is probably not appropriate for the PE to "forge" an
authentication as through the CE really did authenticate when
in fact it didn't.  Since RADIUS doesn't require authentication (that's
what "Call Check" and "Authorize Only" Service-Type values are for)
there's no need to forge an authentication just to be compliant with the
protocol.

> There is a difference between attributes that should be signalled using

I think that's ok. The Tunnel-Type could just be "PPVPN".

> endpoints) is probably a good idea.

Tunnel-Assignment-ID is used to allow multiple connections to be carried
over the same tunnel. That is not quite the same thing as having multiple
tunnels between two endpoints.

> RFC2868 describes attributes for setting up different types of

I agree that RFC 2868 is a superset of what you're trying to do.  I don't
think that the document necessarily requires the use of all the
capabilities, though.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 28 May 2003 14:26:04 +0200

> tunnels between two endpoints.

I think we are in danger of getting mired in the semantics of what is and is not 
a "tunnel" here.

Juha, (without using the word "tunnel") all you care about here is that multiple 
pseudowires be possible between the same endpoints, correct?

- Mark

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 29 May 2003 18:00:15 +0300

W. Mark Townsley writes:

 > I think we are in danger of getting mired in the semantics of what is
 > and is not a "tunnel" here.
 > 
 > Juha, (without using the word "tunnel") all you care about here is
 > that multiple pseudowires be possible between the same endpoints,
 > correct?

the pe receives from radius a set of ip addresses of other pes.  how it
uses them is up to the vpn protocol that the pes implement.  for
example, in my vpls proposal the pe would create a single l2tp tunnel to
each of the other pes (unless one already exists) and then within each
tunnel create any number of l2tp sessions, one per vpn.

-- juha