From rpsec-bounces@ietf.org Mon Nov 14 02:14:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbYXU-0004la-Q7; Mon, 14 Nov 2005 02:14:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbYXJ-0004lI-2f for rpsec@megatron.ietf.org; Mon, 14 Nov 2005 02:14:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00864 for ; Mon, 14 Nov 2005 02:13:21 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbYoG-00010X-Fb for rpsec@ietf.org; Mon, 14 Nov 2005 02:31:26 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAE7Ddg28357 for ; Mon, 14 Nov 2005 09:13:39 +0200 Date: Mon, 14 Nov 2005 09:13:39 +0200 (EET) From: Pekka Savola To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Subject: [RPSEC] comments on draft-ietf-rpsec-bgpsecrec-03 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Hi, I've read the security requirements document, now that it has a bit more detail. There are a couple of high-level omissions which IMHO need to be fixed; there are also some more minor issues in the details. See the comments below. ..... The most serious shortcoming of this doc is that it does not address "economic" realities which is a must for any serious deployment. In particular, you could add for example the following requirements: X. No Heavy Processing on Routers Having specialized hardware to deal with cryptography in order to get acceptable processing speed is unacceptable in general. The solution cannot be deployed if it requires significant financial investment. In particular, the solution must not require that heavy processing is required on all the BGP routers. Even heavy processing on all routers originating a prefix seems very undesirable, as well as requiring such in all eBGP routers. Thus, requiring heavy processing in anything except separate network components or one or two routers would strongly discourage deployment. On the other hand, while "low processing on routers" security model must be supported, it would be acceptable to have extensions for the "basic" support, which could be locally deployed by those parties which find it necessary or economically justifiable. ... Maybe also something a bit more explicit about the amount of configuration? X+1. No Heavy Configuration on Routers It is undesirable to have long or very detailed configuration on the routers, especially it needs to be synchronized on all of them. Long configuration makes operating the device more difficult, and having to do very detailed configuration may hinder the adoption of the security solution; it should be possible to "just start using it" if possible. substantial ----------- o Contents of the UPDATE message SHOULD be authenticated in real- time as the UPDATE message is processed. ... All BGP implementations that implement security MUST utilize at least one of the above methods for validating routing information. Real time verification is preferred in order to prevent transitive failures based on periodic or event-driven scan intervals. ==> you only discuss UPDATEs; you should also mention WITHDRAWs. Regardless of whether it's UPDATE or WITHDRAW, you should also consider the impact of delaying legitimate routing update (e.g., the path went down and the packets will be discarded unless a new path is selected ASAP). (After later reading, some of this is discussed in section 3.4, but an appropriate amount of text and a pointer should be added here as well.) The AS_PATH for specific prefixes may be protected in any proposed security system in four ways: ... All of these checks SHOULD be made available to network operators. Each network operator will decide, on a local basis, which of these checks to enable. ==> this requirement is not spelled out properly. At least the last one (maybe the second-to-last as well) require mechanisms based on the path, i.e., cannot be enabled by local checks. Are you requiring that the transit ASes must implement all of these checks? Transport protection is an important aspect of BGP routing protocol security. The potential to create a linked transport/NLRI/AS_PATH authentication mechanism should not be overlooked and may provide for the accelerated deployment of a BGP security system. Current security mechanisms for BGP transport (e.g. TCP-MD5 [4] and GTSM [6]) are inadequate and require significant operator interaction to maintain a respectable level of security. ... Any proposed security mechanism MUST include provisions for securing both internal BGP and external BGP peering sessions. ==> this is not accurate; TCP-MD5 and GTSM are very well adequate. That is, 1) iBGP sessions are prevented if the AS applies source address spoofing prevention (or alternatively, blocks access to the select parts of the infrastructure components) at its borders; there is no need to use TCP-MD5 or GTSM. 2) eBGP sessions are protected using GTSM when the peer(s) are sufficiently trustable. That leaves only the case when the peering mesh is not point-to-point, i.e., ethernet-based internet exchanges. TCP-MD5 is typically used there to protect from session resets by other members of the exchange. The operational pain of TCP-MD5 comes from having to agree on static keys on a per-peer basis, but the situation may not be much better in terms of config required in any solution. There are still ICMP attacks to consider (draft-gont-tcpm-icmp-attacks-05.txt) but IPsec does not protect from those by better. In any case, the text should be a lot more accurate and realistic, and the 'MUST' requirement seems too strong; this might be something that should be optional to implement, and certainly optional to enable. .... Key maintenance can be especially onerous for operators. The number of keys required and the maintenance of keys (update/withdraw/renew) has had an additive effect as a barrier to deployment. Thus automated means of managing keys, to reduce operational burdens, MUST be available throughout BGP security systems. These security systems MUST be resistant to compromise of session-level or device-level keys, i.e., the security implications of such compromises MUST be limited. ==> what are (update/withdraw/renew) keys? These are not separate keys. Just one key is required. ==> it might be worth separating the discussion of transport protection keys and the route origination (etc.) keys. These are two very different animals with very different security properties. For the former, the MUST requirement is way too strong, as you can only reset one peering session (and even that only if you get on the link) -- hardly a huge problem. semi-editorial -------------- ==> the use of upper-case keywords is not appropriate in a requirements document like this; please make them lower-case. ==> section 1.3 does not mention Withdraws? Update messages are sent between AS peers with the implicit assumption that those messages will be forwarded to others. ==> this leaves out an important detail: only the best path is forwarded (and even then it's only forwarded to those where it's by policy configured to be forwarded). While the AS_PATH information is typically transitive it is, currently, not clearly mandated and many times is removed for various utilitarian reasons. ==> what do you mean with this? This sounds as if some operators would rewrite long AS paths to shorter one which is (I hope) not true... Reword? Specifications state that the AS routing graph MUST be loop free. This indicates that UPDATES received from an external peer which contain the local AS will be rejected. ==> on idr list, maybe about a year ago, this topic came up, and at least some people seemed to think that such routes need not be rejected, but it is sufficient that they are of lower preference than anything else. The "valid" case for these was during certain network partitions. Not that I personally bought it, but that's a separate story.... Prepending a peer AS number on inbound UPDATEs is employed for biasing internal routing and forwarding management while prepending one's own AS number on outbound advertisement is typically used to bias forwarding and routing changes in external networks. The latter practice is explicitly permitted by the BGP specification while the former is not. ==> please add an explicit reference which states how the former is not permitted. Some operators, insert a remote AS number in an UPDATE, in order to cause the UPDATE to be dropped by that AS so that traffic will not traverse a given path. ==> remove the commas; reference (a nanog presentation/posts, a paper, ...) would be useful here. Attributes such as LOCAL_PREF are not transitive and, as such, are protected by BGP session security. ==> local_pref is only passed between iBGP, so if you want to be more generic, I'd use MED as an example. o AS_PATH Feasibility Check: The AS_PATH list MUST correspond to a valid list of autonomous systems according to the first verification category listed in the "Areas to Secure" Section above. o Update Transit Check: Routing information carried through BGP SHOULD include information that can be used to verify the readvertisement or modification by each autonomous system through which the UPDATE has passed. This check is somewhat more rigorous than the "verifiable list of autonomous systems" above. ==> you don't list the "verifiable list of autonomous system"; did you mean the feasibility check or something else? o A BGP speaker and listener have chosen to restrict the number of received prefixes for the listener. The listener has chosen to honor route announcements sent in a summary fashion by the speaker. ==> it's not clear what you're trying to say here, and it's no clear who is the "speaker" and who is the "listener". please reword. 12. References ==> split to informative and normative. editorial --------- ==> you should add ToC as the draft is over 15 pages. ==> you should maybe use ==> slightly trimming the abstract would allow it to be on the cover page:) specification,RFC4271 [7], as a path-vector routing protocol. BGP ==> s/,R/, R/ The session between two BGP speakers can be secured such that the BGP data received by the BGP speakers can by cryptographically verified to have been transmitted by the peer BGP speaker and not a replay of previously transmitted legitimate data. ==> s/by/be/ orignation information is removed (i.e. the more-specific ==> s/orig/origi/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Nov 25 16:09:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efkoa-0002wc-1R; Fri, 25 Nov 2005 16:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfkoY-0002vQ-E6 for rpsec@megatron.ietf.org; Fri, 25 Nov 2005 16:09:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17148 for ; Fri, 25 Nov 2005 16:08:21 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efl7s-0006N5-GG for rpsec@ietf.org; Fri, 25 Nov 2005 16:29:01 -0500 Received: by xproxy.gmail.com with SMTP id t12so511847wxc for ; Fri, 25 Nov 2005 13:09:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=CTckwjcRu2ouJrO7YlcuYgmhz2hZhU+iM6fGlYZe1agFg7rdrGGd3ZGBUuAN64pP+P/oSDT82baRerbV9oxT+GY8h/EG69LdzB0e3NTcgqdFCdN8MPNcNLrQ8BcUatgmDm2hc8jrg1phhI0j2T9bUGEOJmMxNPXEqAFV4hESMvE= Received: by 10.65.230.13 with SMTP id h13mr8665113qbr; Fri, 25 Nov 2005 13:09:00 -0800 (PST) Received: by 10.64.249.11 with HTTP; Fri, 25 Nov 2005 13:09:00 -0800 (PST) Message-ID: <99b9eb8b0511251309v7c56c13vc201ed7fff05f0dc@mail.gmail.com> Date: Sat, 26 Nov 2005 02:39:00 +0530 From: David b To: rpsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [RPSEC] BGP route validation X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0406197301==" Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org --===============0406197301== Content-Type: multipart/alternative; boundary="----=_Part_44603_6720612.1132952940599" ------=_Part_44603_6720612.1132952940599 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi all, I would like to know if we can validate the paths generated by the BGP loca= l decision process by any means ? how much overhead will that incur to converge the BGP routes? ------=_Part_44603_6720612.1132952940599 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hi all,

I would like to know if we can validate the paths generated by the BGP loca= l decision process by any means ?
how much overhead will that incur to converge the BGP routes?


------=_Part_44603_6720612.1132952940599-- --===============0406197301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0406197301==-- From rpsec-bounces@ietf.org Sat Nov 26 21:42:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgCUi-0006eF-GM; Sat, 26 Nov 2005 21:42:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgCUh-0006eA-KW for rpsec@megatron.ietf.org; Sat, 26 Nov 2005 21:42:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18062 for ; Sat, 26 Nov 2005 21:41:40 -0500 (EST) Received: from rimp2.nist.gov ([129.6.16.227] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgCoH-00077D-5s for rpsec@ietf.org; Sat, 26 Nov 2005 22:02:38 -0500 Received: from [127.0.0.1] ([129.6.220.91]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id jAR2gF4f022364; Sat, 26 Nov 2005 21:42:15 -0500 Message-ID: <43891CFF.80503@nist.gov> Date: Sat, 26 Nov 2005 21:42:07 -0500 From: Doug Montgomery Organization: http://www.antd.nist.gov/ User-Agent: Thunderbird 1.5 (Windows/20051025) MIME-Version: 1.0 To: David b Subject: Re: [RPSEC] BGP route validation References: <99b9eb8b0511251309v7c56c13vc201ed7fff05f0dc@mail.gmail.com> In-Reply-To: <99b9eb8b0511251309v7c56c13vc201ed7fff05f0dc@mail.gmail.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: dougm@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org David b wrote: > hi all, > > I would like to know if we can validate the paths generated by the BGP > local decision process by any means ? > how much overhead will that incur to converge the BGP routes? > What exactly do you mean by "validate the paths generated"? Do you mean given an Adj-RIB-ins and some formal description of the local decision process, validate that the Adj-RIB-outs are feasible? Do you mean to do this at a single node, or for an entire network? Always confused by the notion of validating paths... dougm _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec