Dear authors, I have one doubt regarding this proposal ...
Abstract says: "This document describes how the sender of the VPN/Prefix binding may sign it so that recipient of the binding may authenticate it." I highly agree that this would be useful to address. However just going to introduction section we find: 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. 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. Last let me point out also that RFC4364 defines CSC interconnect model which this draft also does not comment on. With this in mind I find the document quite incomplete at it's current form to progress it further. Also I think l3vpn WG should be cc-ed on this thread. Best regards, R. On Mon, Oct 15, 2012 at 8:08 PM, Randy Bush <[email protected]> wrote: > Filename: draft-ymbk-l3vpn-origination > Revision: 00 > Title: Authenticating L3VPN Origination Signaling > Creation date: 2012-10-15 > WG ID: Individual Submission > Number of pages: 6 > URL: > http://www.ietf.org/internet-drafts/draft-ymbk-l3vpn-origination-00.txt > Status: http://datatracker.ietf.org/doc/draft-ymbk-l3vpn-origination > Htmlized: http://tools.ietf.org/html/draft-ymbk-l3vpn-origination-00 > > > Abstract: > A BGP-signaled Layer-3 VPN's prefix bindings sent over BGP are > subject to unintentional errors, both by the legitimate originator > and by non-legitimate origins. This is of special concern if the VPN > traverses untrusted networks. This document describes how the sender > of the VPN/Prefix binding may sign it so that recipient of the > binding may authenticate it. > _______________________________________________ > Idr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/idr
