David, On the IXP LAN prefix front, there's nothing in the draft saying you shouldn't propagate it (maybe even in deaggregated form) in your IGP. What it says is (or maybe I'm just reading it wrong):
* You MUST NOT accept more specific prefixes (for obvious reasons); * If you do accept it, take care that the EBGP route doesn't become better than an IGP route (leading to recursive routing problems) or use next-hop-self; * It MUST only be accepted from ASes authorized to announce it (OK, this one MAY use a rewording). * Exact IXP LAN prefix (accepted from proper AS) SHOULD be propagated to downstreams for uRPF checks on pMTUd ICMP replies. On the next-hop filtering (section 9), I agree we MUST mention use of EBGP next hops for RTBH, including a reference to RFC 6666. Thanks again for the comments, Ivan > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Gert Doering > Sent: Thursday, September 27, 2012 2:56 PM > To: David Freedman > Cc: [email protected] > Subject: Re: [OPSEC] Comments on draft-jdurand-bgp-security-02 > > Hi, > > On Thu, Sep 27, 2012 at 12:29:21PM +0000, David Freedman wrote: > > I'm not aware of any implementations which can achieve this in a > > scalable way, are the authors? at present I would have to statically > > configure a next hop for each peer, not fun. > > Both Cisco and Juniper can do > > route-map foo permit 10 > set ip(v6) next-hop peer-address > > (dunno the exact Juniper syntax, but have been told it can be done) > > DFN(680) stated on the DECIX list that the have been doing this on Cisco > "since ever" and it works. > > > Also, are you aware that some networks inject the IXP LAN into their > > IGP for the purposes of TE? (I.e leaving the IXP LAN next hop present > > in their iBGP and then doing MPLS TE on this LAN as opposed to > > next-hop-self on the border where all peering networks are collapsed > > into a single loopback) > > Yeah, I did. At some point. > > Maybe we need to add a bit more language to the point of "if you need to > deviate from these recommendations, understand why you are doing this, and > then feel free to do so" (= "SHOULD" normative language). > > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > _______________________________________________ > OPSEC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
