>> 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.
Indeed!
>>> 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.
It is, thanks. I propose to slightly change the end of the first bullet then:
o You SHOULD accept from customers only AS(4)-Paths containing ASNs
belonging to (or authorized to transit through) the customer. If
you can not build and generate filtering expressions to implement
this, consider accepting only path lengths relevant to the type of
customer you have (as in, if they are a leaf or have customers of
their own), try to discourage excessive prepending in such paths.
*This loose policy could be combined with filters for specific
AS(4)-Paths that must not be accepted if advertised by the
customer.*
Please tell me if that does the job. Feel free to propose an laternative text
if not.
>>> 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.
Good!
Thanks agin for your suport!
Jerome
>
> 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.
--
Jerome Durand
Consulting Systems Engineer - Routing & Switching
[email protected] - +33 6 35 11 60 50
blogs: http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr
twitter: @JeromeDurand
linkedin: http://fr.linkedin.com/in/jeromedurand
CISCO France
11, rue Camille Desmoulins
92782 Issy les Moulineaux
CEDEX 9
FRANCE
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
