Re: [Idr] draft-ymbk-l3vpn-origination-00.txt

[Robert Raszuk <[e-mail]>]

Hello Randy,

On Tue, Oct 16, 2012 at 5:41 AM, Randy Bush <[e-mail]> wrote:
> thanks for review!

You are very welcome !

>>    This document describes how the originating PE, West, may sign the
>>    announcement so that the destination PE, East, may authenticate the
>>    NLRI and the Route Distinguisher (RD), , see RFC 4364 [RFC4364]
>>
>> Let me point out that West PE is not the originator of the route
>> advertisement .. neither East PE is the destination. Originator and
>> destination are corresponding CEs on both sides.
>
> good catch!

I was not that much fishing here ... just trying to understand if you
are validating CE-CE or PE-PE. If the latter I unfortunately think
there is much less of the value.

When we originally started to roll out 2547 there was very clear
consensus that real protection must happen on the CE-CE boundary.
Trusting SP where anyone who logs into PE can do anything for any VPN
there was never taken serious.

Note that the draft could also allow both, but this needs to be
clearly stated in the text.

>> With this in mind let me also point out that RFC4364 VPN sites very
>> often use private addresses which are never part of any public RPKI
>> for one simple reason that public RPKI has no notion of RDs to make
>> such prefixes unique.
>
> if they want to use the rpki, then, just as other rpki publishers using
> 1918 space, they would have local trust anchors and certify the private
> space.  see draft-ietf-sidr-ltamgmt.

And what happens in the event of PE-PE validation where only one SP of
L3VPN subscribes to RPKI business ?

>> Last let me point out also that RFC4364 defines CSC interconnect model
>> which this draft also does not comment on.
>
> more specific cite, please?  thanks.

http://tools.ietf.org/html/rfc4364#section-9

Summary ... PEs are not involved in distribution of customer routes
between customer sites.

R.


> randy