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

Bernard Aboba wrote:
>>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.
> 
> 
> 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.
> 
> 
>> > 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.
>>
>>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.
> 
> 
> I think that's ok. The Tunnel-Type could just be "PPVPN".
> 
> 
>>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.
> 
> 
> 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.

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

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