On 4/10/14, 3:20 AM, "Jerome Durand (jerduran)" <[email protected]> wrote:
>Doc has already been presented RIPE and NANOG meeting as you know. Should >we simply send an email recalling this is last call? Couldn’t hurt. >For section 4.1 I propose the following text for 2nd paragraph you're >referring to: > > TCP sessions used by BGP can be secured with a variety of mechanisms. > MD5 protection of TCP session header [14] was the first existing >mechanism. > It is now deprececated by TCP Authentication Option (TCP-AO, [10]) >which > offers stronger protection. IPsec can also be used for this purpose. > While MD5 is still the most used mechanism due to its availability in > vendor's equipment, TCP-AO and MD5 SHOULD be preferred when >implemented. Looks fine, although I think you meant to say “TCP-AO SHOULD be preferred” not “TCP-AO and MD5 SHOULD” in the last sentence. > >>Section 3- may want to mention rate-limiting accepted traffic in >>addition to strict filtering of unacceptable traffic > >Maybe a note on that. We probably don't want to start discussing the >right thresholds here. Agree >> 5.2.1 (or possibly section 8) - Filtering peer ASes inbound from >>customers? (in this case “peer” meaning a non-transit interconnect, not >>just someone you are connected to via BGP) I.e. If I know that I should >>only receive routes with 701 in the path from 701 because I do not use >>any other ASN as transit to reach 701, I should filter routes inbound >>from other sources to ensure that they don’t announce routes with that >>path. This is somewhere between the strict IRR based filters and the >>loose filters, and depends on the topology of the network and my >>business relationships, but I think it’s a useful point to make to add >>some additional safety filtering to prevent “my idiot customer is trying >>to re-announce the internet to me” along with max-prefix, which you >>already cover. > >I think that first bullet of section 8 is saying this. We are saying we >need to make sure we receive only identified ASes from customer, we >probably don't need to add we have to filter the ones we don't want. Tell >me if I didn't understand your point. Feel free to propose some modified >text. You’re right, it’s mostly saying that. I think the model you’re advocating is a filter that explicitly permits certain ASNs, generated uniquely for each customer, meaning each has an implicit deny of anything that isn’t explicitly permitted. That’s certainly the better model. My suggestion was more for the second case “if you cannot build filters…”, where building a short list of explicitly denied ASNs that you should never see from *any* downstream customer (i.e. The ASNs of your peers and/or upstream transit providers) to a non-customer-specific filter that can be globally applied on all customer BGP sessions provides a useful safety mechanism beyond AS-path-length limits, and protects if the customer-specific filter is inadvertently not applied (since that never happens :-) ). Hope that’s clearer. > >> This may be something that the RFC editor will fix, but it would be >>preferable to use the actual draft name or RFC number as the reference >>tag instead of numeric tags, so that the reader knows what you are >>referencing without having to jump to footnotes each time. > >If RFC editor can fix it I buy the idea. Otherwise you need to explain to >me how to do it easily :) I just looked briefly at your XML compared with one of my drafts, and I can’t see how it’s different, so I’m actually not sure how to fix, so I guess let’s don’t worry about it. Wes George This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
