From mailman-owner@ietf.org Mon Jul 1 06:47:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23613 for ; Mon, 1 Jul 2002 06:47:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA25309 for ; Mon, 1 Jul 2002 06:48:47 -0400 (EDT) Date: Mon, 1 Jul 2002 06:48:47 -0400 (EDT) Message-Id: <200207011048.GAA25309@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: rpsec-web-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, rpsec-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ****************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ****************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for rpsec-web-archive@ietf.org: List Password // URL ---- -------- rpsec@ietf.org lLFY https://www1.ietf.org/mailman/options/rpsec/rpsec-web-archive@ietf.org From rpsec-admin@ietf.org Tue Jul 2 08:32:20 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05891 for ; Tue, 2 Jul 2002 08:32:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07306; Tue, 2 Jul 2002 08:30:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07265 for ; Tue, 2 Jul 2002 08:30:51 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05783 for ; Tue, 2 Jul 2002 08:30:01 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA12622 for ; Tue, 2 Jul 2002 08:30:19 -0400 (EDT) Date: Tue, 2 Jul 2002 08:30:19 -0400 (EDT) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Meeting in Yokohoma.... Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Y'all: RPSEC is meeting in Yokohoma, if anyone has any agenda items. I won't be there, but Bill will be presiding over the meeting, I think. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Sun Jul 7 16:09:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03677 for ; Sun, 7 Jul 2002 16:09:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21743; Sun, 7 Jul 2002 16:08:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA21711 for ; Sun, 7 Jul 2002 16:08:51 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03523 for ; Sun, 7 Jul 2002 16:07:58 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA02153 for ; Sun, 7 Jul 2002 16:08:20 -0400 (EDT) Date: Sun, 7 Jul 2002 16:08:20 -0400 (EDT) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Yokohama Agenda.... Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org So far, we just have Dennis Beard with a 15 minute presentation on the draft he and Sandy are working on. I think Bill will be at the table, since I won't be there. Anything to add? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Mon Jul 8 10:20:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16106 for ; Mon, 8 Jul 2002 10:20:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19343; Mon, 8 Jul 2002 10:19:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA19313 for ; Mon, 8 Jul 2002 10:19:16 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15965 for ; Mon, 8 Jul 2002 10:18:24 -0400 (EDT) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id KAA13450; Mon, 8 Jul 2002 10:18:37 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma013426; Mon, 8 Jul 02 10:17:55 -0400 Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g68EIXI27856; Mon, 8 Jul 2002 10:18:33 -0400 (EDT) Date: Mon, 8 Jul 2002 10:18:33 -0400 (EDT) Message-Id: <200207081418.g68EIXI27856@raven.gw.tislabs.com> To: rpsec@ietf.org Cc: sandy@tislabs.com Subject: [RPSEC] security considerations - case in point: draft-turk-ertb-00.txt Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Perhaps one of the goals of the working group ought to be to provide guidelines and security requirements so that those who write security considerations sections can write something more explicit than the just announced draft-turk-ertb-00.txt, which says: It is very important to practice tight control over BGP peering points before implementing this technique. BGP customers might be able to compromise a particular piece of the network using the Black holing communities. Making sure that a match for locally generated BGP announcement exist helps in limiting the ability to drive a network to a null interface to the local AS. Some other security considerations MUST be looked at based on the status of the AS those techniques are being implemented at. The "MUST" for "some other security considerations" particularly caught my eye. And then there's the requirement for "tight control". It seems that people want to do the right thing, they're just at sea about what that is and how to do it. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Mon Jul 8 11:45:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20508 for ; Mon, 8 Jul 2002 11:45:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25911; Mon, 8 Jul 2002 11:38:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25875 for ; Mon, 8 Jul 2002 11:38:24 -0400 (EDT) Received: from mesa.bbnplanet.com (mesa.bbnplanet.com [199.94.208.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20070 for ; Mon, 8 Jul 2002 11:37:31 -0400 (EDT) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id g68Fb7P25975; Mon, 8 Jul 2002 11:37:11 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Mon, 8 Jul 2002 11:37:07 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: sandy@tislabs.com cc: rpsec@ietf.org Subject: Re: [RPSEC] security considerations - case in point: draft-turk-ertb-00.txt In-Reply-To: <200207081418.g68EIXI27856@raven.gw.tislabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org On Mon, 8 Jul 2002 sandy@tislabs.com wrote: > Perhaps one of the goals of the working group ought to be to provide > guidelines and security requirements so that those who write security > considerations sections can write something more explicit than the I agree completely. Alex posted a decent stab at a framework a couple of months ago: http://www1.ietf.org/mail-archive/working-groups/rpsec/current/msg00065.html and I replied at that time: ++> It seems to me that when thinking about security it's often ++> matter of classifying a given situation and then knowing ++> what kinds of questions to ask about such a situation. ++> ++> This way protocol designers, implementors and users can ++> ask "What about DoS?" "What about authorization?", etc. Might people want to pick that one up and work with it? Personally, I can cogitate on security half-decently, but know not that much about protocol design and what people usually go through with that. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Mon Jul 8 15:46:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05204 for ; Mon, 8 Jul 2002 15:46:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17386; Mon, 8 Jul 2002 15:38:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA17352 for ; Mon, 8 Jul 2002 15:38:09 -0400 (EDT) Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04744 for ; Mon, 8 Jul 2002 15:37:16 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g68JbY501912; Mon, 8 Jul 2002 15:37:34 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g68JbU101905; Mon, 8 Jul 2002 15:37:30 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g68JbUU18943; Mon, 8 Jul 2002 15:37:30 -0400 (EDT) Date: Mon, 8 Jul 2002 15:37:30 -0400 From: Jeffrey Haas To: sandy@tislabs.com Cc: rpsec@ietf.org Subject: Re: [RPSEC] security considerations - case in point: draft-turk-ertb-00.txt Message-ID: <20020708153730.D11658@nexthop.com> References: <200207081418.g68EIXI27856@raven.gw.tislabs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200207081418.g68EIXI27856@raven.gw.tislabs.com>; from sandy@tislabs.com on Mon, Jul 08, 2002 at 10:18:33AM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org On Mon, Jul 08, 2002 at 10:18:33AM -0400, sandy@tislabs.com wrote: > It seems that people want to do the right thing, they're just at sea > about what that is and how to do it. In the case of BGP communities and their extended cousins, there was a nice e-mail from Andrew Partan that summarized a good BCP as to what one should do inside one's AS to help keep the Internet community space clean. Having a standard knob that people can turn to do this would be a nice thing. The mail in whole: : From: Andrew Partan : To: "Martin, Christian" : Cc: ptomaine@shrubbery.net : Subject: Re: BGP TTL : Precedence: bulk : X-NextHop-MailScanner: Found to be clean : X-UIDL: 73b1d38620013b30a92e9b2767474679 : : On Wed, Mar 20, 2002 at 03:25:23PM -0500, Martin, Christian wrote: : > Perhaps communities should become mandatory transitive attributes? : : That is not a good idea. You still need to block communities you use : internally so others can't effect your router. : : Ideal provider config is : - strip all communities you use for internal markers on input : - act on all communities you tell you customers they may use : - strip all your communities on output : - let all other communities thru untouched : : --asp The gotcha here being "your communities". > --Sandy -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Tue Jul 9 16:59:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17286 for ; Tue, 9 Jul 2002 16:59:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06966; Tue, 9 Jul 2002 16:47:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA06919 for ; Tue, 9 Jul 2002 16:47:27 -0400 (EDT) Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16938; Tue, 9 Jul 2002 16:46:31 -0400 (EDT) Received: from 12-234-206-11.client.attbi.com ([12.234.206.11] helo=AGNS3K11) by psg.com with esmtp (Exim 3.36 #1) id 17S1sX-0005RO-00; Tue, 09 Jul 2002 13:46:33 -0700 Date: Tue, 9 Jul 2002 13:46:03 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <10875018761.20020709134603@psg.com> To: rpsec@ietf.org CC: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [RPSEC] Fwd: WG Action: Routing Protocol Security Requirements (rpsec) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Folks, In case someone missed the announcement, RPSEC has been approved as a WG. Regarding the chairmanship--we're still in the process here. Bill kindly agreed to help as the co-chair until we're there. See you in Yokohama. Alex This is a forwarded message From: Steve Coya To: Cc: Date: Tuesday, July 02, 2002, 6:12:10 AM Subject: WG Action: Routing Protocol Security Requirements (rpsec) ===8<==============Original message text=============== A new IETF working group has been established in the Routing Area. Please contact the Area Directors or WG CHairs for additional information. Routing Protocol Security Requirements (rpsec) ---------------------------------------------- Current Status: Active Working Group Chair(s): Bill Fenner Russ White Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: Alex Zinin Mailing Lists: General Discussion:rpsec@ietf.org To Subscribe: rpsec-request@ietf.org In Body: (un)subscribe Archive: http://www1.ietf.org/mail-archive/working-groups/rpsec Description of Working Group: The lack of a common set of security requirements and methods for routing protocols has resulted in a wide variety of security mechanisms for individual routing protocols. Ongoing work on requirements for the next generation routing system and future work on the actual mechanisms for it will require well documented routing security requirements. The products of this working group will be used by routing protocol designers to ensure adequate coverage of security in the future, including well known and possible threats. The scope of work is limited to router-to-router protocols only for both unicast and multicast systems, and does NOT include host-to-router protocol such as IGMP, ICMP, ARP, or ND. It is also a non-goal at this point to produce new or change the current security mechanisms in the existing routing protocols. The RPSEC working group is charged with the following tasks: - Document threat models for routing systems - Document security requirements for routing systems - Provide a common area for discussion between security and routing experts on the topic of securing the routing system Possible Future Work - Evaluate and document existing and proposed routing security mechanisms with respect to established RPSEC requirements - Recommend mechanism(s) Goals and Milestones: JUL 02 Submit initial I-D (or set of I-Ds) which details the threats to routing systems. OCT 02 Submit initial I-D (or set of I-Ds) which outlines security requirements for routing systems. DEC 02 Submit I-Ds documenting threats to routing systems for publication as Informational RFC. MAR 03 Submit the I-D documenting security requirements to routing systems for publication as Informational RFC. MAR 03 Evaluate progress, recharter with new goals (see possible future work above) or shutdown. ===8<===========End of original message text=========== _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Wed Jul 10 15:15:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16258 for ; Wed, 10 Jul 2002 15:15:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00758; Wed, 10 Jul 2002 15:10:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00724 for ; Wed, 10 Jul 2002 15:10:25 -0400 (EDT) Received: from cisco.com (amsterdam.cisco.com [144.254.74.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15942 for ; Wed, 10 Jul 2002 15:09:31 -0400 (EDT) Received: from MBEHRING-W2K1.cisco.com ([10.32.255.101]) by cisco.com (8.8.8+Sun/8.8.8) with SMTP id VAA23282 for ; Wed, 10 Jul 2002 21:09:50 +0200 (MET DST) Message-Id: <4.3.2.7.2.20020710173852.043ed798@madrid.cisco.com> X-Sender: mbehring@madrid.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 10 Jul 2002 21:09:32 +0200 To: rpsec@ietf.org From: "Michael H. Behringer" Subject: RE: [RPSEC] MPLS Security Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Sorry for replying late. If MPLS security is of interest in this WG, you may want to have a look at my draft: http://search.ietf.org/internet-drafts/draft-behringer-mpls-security-02.txt --- Analysis of the Security of the MPLS Architecture Abstract This document analyses the security of the MPLS architecture, especially in comparison with other VPN technologies such as ATM and Frame Relay. The target audience is service providers and VPN users. The document consists of two main parts: First the requirements for security in VPN services are defined, second MPLS is examined with respect to these requirements. The analysis shows that MPLS networks can be equally secured as traditional layer-2 networks such as ATM and Frame Relay. --- I would be happy about any feedback! Michael >I think both would be, from a routing and requirements >perspective (not from an actual mechanism or traffic >perspective). > >:-) > >Russ > >On Fri, 31 May 2002, Marwaha Shivanajay wrote: > >> We may also inlcude ad hoc network routing security. >> >> Regards, >> Shivanajay >> -~-~-~-~-~-~-~-~-~-~-~-~ >> Research Scholar, >> Dept. of Electrical and Comp. Eng. >> National University of Singapore >> Singapore. >> -~-~-~-~-~-~-~-~-~-~-~-~ >> >> -----Original Message----- >> From: David G. Boney [mailto:dboney@gwu.edu] >> Sent: Friday, May 31, 2002 5:57 AM >> To: rpsec@ietf.org >> Subject: [RPSEC] MPLS Security >> >> >> Hi, >> >> Would MPLS security be within the bounds of this group? >> -- >> >> Sincerely, >> David G. Boney >> >> Graduate Research Assistant >> Department of Electrical and Computer Engineering >> The George Washington University >> Phillips Hall, Suite 607 >> 801 22nd Street, N.W. >> Washington, DC 20052 >> >> http://student.seas.gwu.edu/~dboney >> mailto:dboney@gwu.edu >> Department Phone (202) 994-6083 >> Department Fax (202) 994-0227 >> >> "I don't get up until noon, I only work a couple of hours >> a day, and I spend the rest of my time reading. >> I guess my calling in life is to be a professor." >> _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-admin@ietf.org Sun Jul 14 20:17:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22005 for ; Sun, 14 Jul 2002 20:17:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03109; Sun, 14 Jul 2002 20:13:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03079 for ; Sun, 14 Jul 2002 20:13:36 -0400 (EDT) Received: from mail1.netscreen.com ([63.126.135.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21869 for ; Sun, 14 Jul 2002 20:12:39 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca-local [10.100.10.21]) by mail1.netscreen.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6F0B9L09667; Sun, 14 Jul 2002 17:11:09 -0700 (PDT) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Sun, 14 Jul 2002 17:10:26 -0700 Message-ID: <541402FFDC56DA499E7E13329ABFEA87060BDF@SARATOGA> From: Gregory Lebovitz To: "'riw@cisco.com'" , "'sandy@tislabs.com'" , "'fenner@research.att.com'" Cc: "'rpsec@ietf.org'" Date: Sun, 14 Jul 2002 17:07:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [RPSEC] docs for RPsec at 54 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Russ, Bill, Sandy, I checked the web page for the wg and saw no drafts. I thought we were going to try to have out a draft re: threat models for discussion this week at IETF. Should I email someone else or look elsewhere for a copy of such? Also, I did not find an agenda posted at http://www.ietf.org/meetings/wg_agenda_54.html. did I miss it? Is there any informal get together here (54, Yoko) where we can do more face to face brainstorming and discussion? If not, I would be interested in getting one together. Gregory. Staff Architect NetScreen _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Fri Jul 19 11:21:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11622 for ; Fri, 19 Jul 2002 11:21:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08192 for rpsec-archive@odin.ietf.org; Fri, 19 Jul 2002 11:22:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07066; Fri, 19 Jul 2002 11:12:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07020 for ; Fri, 19 Jul 2002 11:11:59 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11170 for ; Fri, 19 Jul 2002 11:10:59 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id LAA02919 for ; Fri, 19 Jul 2002 11:11:28 -0400 (EDT) Date: Fri, 19 Jul 2002 11:11:28 -0400 (EDT) From: Russ White Reply-To: Russ White To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [RPSEC] Draft Status.... Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Y'all: I wasn't in Yokohama (obviously), but I understand there was/is some confusion in where we are/etc. I think we have two immediate objectives/goals to fulfill, threats model(s) and requirements. My general impression is: -- We should allow as many threat model drafts as required/needed/presented. Since each of these essentially represents another way of looking at the problem, there can be, and probably should be, multiple valid drafts in this area. In fact, beyond Susan's draft, I know of at least one other draft in progress on this front (I hope), and the multicast presentation that was made at this IETF would probably represent another valid model that we need to look at. -- We should use these threat models as background towards producing one (or one set of) requirements model(s). On this second point, I think we need some discussion. Should there be one requirements model for interior gateway protocols, another for exterior gateway protocols, and a third for multicast? Or should they be unified in one draft? Or is it better to see what drafts come forward, and see what fits and doesn't fit? I hope to at least have several threat models on the table in Atlanta, and then to adopt as many as appear to be valid in the weeks after Atlanta. From there, we can use these models to build the requirements doc(s) as needed. In the meantime, specific security recommendations for protocols are allowed/encouraged as a cross presentation/discussion with the individual protocol groups. We won't take on specific protocol proposals as wg items, I don't think (since they will generally involve modification of the protocol? but it might have to be case by case), but we can serve as a meeting place for the rp and security folks in this regard, allowing more eyes and brains on such proposals. Perhaps the right term would be "vetting" them (?). Thoughts? Comments? We need to get moving--I know it's a new research area, and it's important to put serious thought into it. But I think we should have adopted threat models just after Atlanta, and then have at least some work done on requirements docs to present in March. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Fri Jul 19 11:47:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12385 for ; Fri, 19 Jul 2002 11:47:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA10892 for rpsec-archive@odin.ietf.org; Fri, 19 Jul 2002 11:48:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10505; Fri, 19 Jul 2002 11:44:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10469 for ; Fri, 19 Jul 2002 11:44:14 -0400 (EDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12282 for ; Fri, 19 Jul 2002 11:43:15 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 19 Jul 2002 11:42:01 -0400 Message-ID: <3D383292.CC83402E@nc.rr.com> Date: Fri, 19 Jul 2002 11:38:58 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Russ White CC: rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Russ, Comments in-line... Russ White wrote: > > Y'all: > > -- We should allow as many threat model drafts as > required/needed/presented. Completely agree. We should be seeing slightly different models based on different variables (e.g. IGP vs. EGP). > -- We should use these threat models as background towards > producing one (or one set of) requirements model(s). > > On this second point, I think we need some discussion. Should > there be one requirements model for interior gateway protocols, > another for exterior gateway protocols, and a third for > multicast? Or should they be unified in one draft? > > Or is it better to see what drafts come forward, and see what > fits and doesn't fit? I would feel better waiting and seeing what comes out. Then, as a group, make the decision on the structure of the requirements models. I did not see the multicast presentation, but I can envision that scenario having very different properties based on the routing protocol being used (e.g. PIM or MOSPF) or any security interaction with the group management protocol. > In the meantime, specific security recommendations for protocols > are allowed/encouraged as a cross presentation/discussion with > the individual protocol groups. We won't take on specific > protocol proposals as wg items, I don't think (since they will > generally involve modification of the protocol? but it might have > to be case by case), but we can serve as a meeting place for the > rp and security folks in this regard, allowing more eyes and > brains on such proposals. Perhaps the right term would be > "vetting" them (?). Sounds reasonable. I would prefer to have the routing protocol groups very involved. Unless we can come up with a security mechanism that is protocol independent. :) Brian _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Fri Jul 19 14:43:22 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15597 for ; Fri, 19 Jul 2002 14:43:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA21785 for rpsec-archive@odin.ietf.org; Fri, 19 Jul 2002 14:44:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21636; Fri, 19 Jul 2002 14:35:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA21608 for ; Fri, 19 Jul 2002 14:35:43 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15438 for ; Fri, 19 Jul 2002 14:34:39 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA13001; Fri, 19 Jul 2002 14:35:06 -0400 (EDT) Date: Fri, 19 Jul 2002 14:35:06 -0400 (EDT) From: Russ White Reply-To: Russ White To: Brian Haberman cc: rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... In-Reply-To: <3D383292.CC83402E@nc.rr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > > -- We should allow as many threat model drafts as > > required/needed/presented. > > Completely agree. We should be seeing slightly different > models based on different variables (e.g. IGP vs. EGP). And on differing analysis within each rp area, I think. > > Or is it better to see what drafts come forward, and see what > > fits and doesn't fit? > > I would feel better waiting and seeing what comes out. > Then, as a group, make the decision on the structure of the > requirements models. > > I did not see the multicast presentation, but I can envision > that scenario having very different properties based on the > routing protocol being used (e.g. PIM or MOSPF) or any > security interaction with the group management protocol. Any other comments from the list? I'd like to get a concensus here, and start seeing drafts come forward, so we can build a full schedule for Atlanta, and have lots to talk about in the mean time. > Sounds reasonable. I would prefer to have the routing > protocol groups very involved. Unless we can come up with a > security mechanism that is protocol independent. :) Agreed... I'm envisioning that the security parts of the draft could/would be discussed here, and then the work would be taken to the protocol wg for actual approval/etc--just so the security folks involved don't have to watch 14 rp mailing lists and working groups, but can focus their efforts in one place, and give us (the rp folks) the best advice possible using as few resources as possible. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Mon Jul 22 10:40:29 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05434 for ; Mon, 22 Jul 2002 10:40:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA21134 for rpsec-archive@odin.ietf.org; Mon, 22 Jul 2002 10:41:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20740; Mon, 22 Jul 2002 10:33:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20709 for ; Mon, 22 Jul 2002 10:33:24 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05256 for ; Mon, 22 Jul 2002 10:32:23 -0400 (EDT) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id KAA27887; Mon, 22 Jul 2002 10:32:50 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma027854; Mon, 22 Jul 02 14:32:23 GMT Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g6MEWub12437; Mon, 22 Jul 2002 10:32:56 -0400 (EDT) Date: Mon, 22 Jul 2002 10:32:56 -0400 (EDT) Message-Id: <200207221432.g6MEWub12437@raven.gw.tislabs.com> To: bkhabs@nc.rr.com, riw@cisco.com Subject: Re: [RPSEC] Draft Status.... Cc: rpsec@ietf.org Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org >Completely agree. We should be seeing slightly different models >based on different variables (e.g. IGP vs. EGP). HM. Having looked at security solutions for both OSPF and BGP, I'm not convinced that the threat model is very different for the two. Certainly the threat actions are not different and the threat sources are not different, though you might give them different names. The threat consequences have different scope but are the same in definition. Also - there are lots of different ways to characterize protocols: - by scope (IGP vs EGP) - by algorithm (link state vs distance vector) - by underlying layer (link layer (well, maybe not), network, transport) - by communication media (ATM (rather not touch that), wired, wireless) - by routed traffic (unicast vs multicast vs ..) I'm not sure that we should try to come up with threat models for each different type in each way of assigning types - too much work. The holy grail would be a general threat model, with perhaps instantiations to various protocol types. Or instantiations to a small set of specific protocols as examples. If the intent of the threat model and security requirements are to advise protocol designers, then making them specific to particular characteristics of the protocol risks a loss of completeness, so that the protocol designer would have no model/requirements that fit the protocol being designed. (OTOH, something terribly general might be difficult to fit to a specific protocol - that's the challenge of writing a general description.) >Sounds reasonable. I would prefer to have the routing protocol >groups very involved. Unless we can come up with a security >mechanism that is protocol independent. :) Mechanism? I thought that our charter specifically discounted any idea that we would come up with a mechanism. It says "it is also a non-goal at this point to produce new or change the current security mechanisms in the existing routing protocols". Evaluation and documentation of mechanisms is listed as "possible future work". --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Mon Jul 22 11:00:51 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06393 for ; Mon, 22 Jul 2002 11:00:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA23016 for rpsec-archive@odin.ietf.org; Mon, 22 Jul 2002 11:01:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22071; Mon, 22 Jul 2002 10:55:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22039 for ; Mon, 22 Jul 2002 10:55:33 -0400 (EDT) Received: from mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06173 for ; Mon, 22 Jul 2002 10:54:32 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 22 Jul 2002 10:53:30 -0400 Message-ID: <3D3C1BC3.E0E22276@nc.rr.com> Date: Mon, 22 Jul 2002 10:50:43 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sandy@tislabs.com CC: riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... References: <200207221432.g6MEWub12437@raven.gw.tislabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Sandy, sandy@tislabs.com wrote: > > >Completely agree. We should be seeing slightly different models > >based on different variables (e.g. IGP vs. EGP). > > HM. Having looked at security solutions for both OSPF and BGP, > I'm not convinced that the threat model is very different for the > two. Certainly the threat actions are not different and the > threat sources are not different, though you might give them > different names. The threat consequences have different scope > but are the same in definition. I see your point. I was trying to point out that there may be different models based on variables and picked IGP/EGP as an example. As you point, it probably wasn't a good example. > > Also - there are lots of different ways to characterize protocols: > - by scope (IGP vs EGP) > - by algorithm (link state vs distance vector) > - by underlying layer (link layer (well, maybe not), network, transport) No, I think we need to stay away from that one. > - by communication media (ATM (rather not touch that), wired, wireless) How much does this differ from the link layer characterization? > - by routed traffic (unicast vs multicast vs ..) Agreed. This could be a key distinction. But since PIM relies on the unicast routing table, we may be talking different problem spaces. Of course DVMRP has its own route exchange which could be protected (not sure if it is worth the effort though). From the MSEC charter it seems that they are not interested in the protection of any routing protocols, rather the group membership. > > I'm not sure that we should try to come up with threat models for > each different type in each way of assigning types - too much work. We just need to look at the different protocols to see if the threat model varies. > > The holy grail would be a general threat model, with perhaps instantiations > to various protocol types. Or instantiations to a small set of specific > protocols as examples. > > If the intent of the threat model and security requirements are to > advise protocol designers, then making them specific to particular > characteristics of the protocol risks a loss of completeness, so that > the protocol designer would have no model/requirements that fit the > protocol being designed. (OTOH, something terribly general might be > difficult to fit to a specific protocol - that's the challenge of writing > a general description.) > > >Sounds reasonable. I would prefer to have the routing protocol > >groups very involved. Unless we can come up with a security > >mechanism that is protocol independent. :) > > Mechanism? I thought that our charter specifically discounted any > idea that we would come up with a mechanism. It says "it is also a > non-goal at this point to produce new or change the current security > mechanisms in the existing routing protocols". Evaluation and > documentation of mechanisms is listed as "possible future work". I wasn't talking about RPSEC specifically with that statement. Brian _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@ns.ietf.org Mon Jul 22 23:11:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10367 for ; Mon, 22 Jul 2002 23:11:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA29826 for rpsec-archive@odin.ietf.org; Mon, 22 Jul 2002 23:12:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA25933; Mon, 22 Jul 2002 23:03:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA25872 for ; Mon, 22 Jul 2002 23:03:18 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09679 for ; Mon, 22 Jul 2002 23:02:16 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17Wpwy-0007aH-00; Mon, 22 Jul 2002 20:03:00 -0700 Date: Mon, 22 Jul 2002 20:01:16 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <2730827788.20020722200116@psg.com> To: Brian Haberman CC: sandy@tislabs.com, riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... In-Reply-To: <3D3C1BC3.E0E22276@nc.rr.com> References: <200207221432.g6MEWub12437@raven.gw.tislabs.com> <3D3C1BC3.E0E22276@nc.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Brian, I agree with Sandy here. Please see some comments below. Monday, July 22, 2002, 7:50:43 AM, Brian Haberman wrote: ... >> Also - there are lots of different ways to characterize protocols: >> - by scope (IGP vs EGP) >> - by algorithm (link state vs distance vector) >> - by underlying layer (link layer (well, maybe not), network, transport) > No, I think we need to stay away from that one. Why? We have IS-IS, OSPF, and BGP that use link layer, IP, and TCP as their transport. Each type of transport has its own set of vulnerabilities. >> - by communication media (ATM (rather not touch that), wired, wireless) > How much does this differ from the link layer characterization? >> - by routed traffic (unicast vs multicast vs ..) > Agreed. This could be a key distinction. But since PIM relies > on the unicast routing table, we may be talking different > problem spaces. Of course DVMRP has its own route exchange > which could be protected (not sure if it is worth the effort > though). I think we should be able to cover both multicast and unicast RPs within the same model if we make sure that the analysis of the DB maintenance and rtg/fwd state establishment components includes the instances used in PIM. >> I'm not sure that we should try to come up with threat models for >> each different type in each way of assigning types - too much work. > We just need to look at the different protocols to see if the threat > model varies. right, as well as make sure that the model we come up with is descriptive enough to cover at least the existing RPs and those under development. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@ns.ietf.org Mon Jul 22 23:47:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12643 for ; Mon, 22 Jul 2002 23:47:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA14080 for rpsec-archive@odin.ietf.org; Mon, 22 Jul 2002 23:48:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA11484; Mon, 22 Jul 2002 23:42:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA06392 for ; Mon, 22 Jul 2002 23:29:55 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11310 for ; Mon, 22 Jul 2002 23:26:21 -0400 (EDT) Subject: RE: [RPSEC] Draft Status.... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 22 Jul 2002 20:26:50 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405E201@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status.... Thread-Index: AcIx9fxE8e5NdyTzRqePJsRHtbTTfAAAFiwQ From: "Michel Py" To: "Alex Zinin" , "Bill Fenner" Cc: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA06478 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit Bill / Russ / Alex, >>> Also - there are lots of different ways to characterize >>> protocols: >>> - by scope (IGP vs EGP) >>> - by algorithm (link state vs distance vector) >>> - by underlying layer (link layer (well, maybe not), >>> network, transport) >> No, I think we need to stay away from that one. > Why? We have IS-IS, OSPF, and BGP that use link layer, IP, > and TCP as their transport. Each type of transport has its > own set of vulnerabilities. I have a very dumb question, as someone that just jumped in: As an example, regarding BGP using TCP, and WRT the rpsec charter: > Document threat models for routing systems. My reading is that it is within scope to describe BGP vulnerabilities induced by the use of TCP. > Document security requirements for routing systems. However, here it is not clear to me if it is in|out of scope to document security requirements for TCP, or if the scope is limited to security requirements for BGP (I can share some insight WRT the same issue we (ipv6mh) are dealing with if you wish). Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@ns.ietf.org Tue Jul 23 00:05:31 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14003 for ; Tue, 23 Jul 2002 00:05:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA23246 for rpsec-archive@odin.ietf.org; Tue, 23 Jul 2002 00:06:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19459; Tue, 23 Jul 2002 00:00:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA19407 for ; Tue, 23 Jul 2002 00:00:15 -0400 (EDT) Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13467 for ; Mon, 22 Jul 2002 23:59:12 -0400 (EDT) Received: from trianon (trianon.shockwave.org [192.111.107.43]) by merlot.juniper.net (8.11.3/8.11.3) with SMTP id g6N3whm96755; Mon, 22 Jul 2002 20:58:43 -0700 (PDT) (envelope-from pst@juniper.net) Message-ID: <001501c231fd$3f6b03a0$2b6b6fc0@shockwave.org> From: "Paul Traina" To: "Michel Py" , "Alex Zinin" , "Bill Fenner" Cc: , References: <2B81403386729140A3A899A8B39B046405E201@server2000.arneill-py.sacramento.ca.us> Subject: Re: [RPSEC] Draft Status.... Date: Mon, 22 Jul 2002 20:58:46 -0700 Organization: Juniper Networks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Fine, but then you should document the practices of BGP/TCP+MD5 checksums and BGP/TCP/IPSEC. ----- Original Message ----- From: "Michel Py" To: "Alex Zinin" ; "Bill Fenner" Cc: ; Sent: Monday, July 22, 2002 8:26 PM Subject: RE: [RPSEC] Draft Status.... > Bill / Russ / Alex, > > >>> Also - there are lots of different ways to characterize > >>> protocols: > >>> - by scope (IGP vs EGP) > >>> - by algorithm (link state vs distance vector) > >>> - by underlying layer (link layer (well, maybe not), > >>> network, transport) > > >> No, I think we need to stay away from that one. > > > Why? We have IS-IS, OSPF, and BGP that use link layer, IP, > > and TCP as their transport. Each type of transport has its > > own set of vulnerabilities. > > > I have a very dumb question, as someone that just jumped in: > As an example, regarding BGP using TCP, and WRT the rpsec charter: > > > Document threat models for routing systems. > > My reading is that it is within scope to describe BGP vulnerabilities > induced by the use of TCP. > > > > Document security requirements for routing systems. > > However, here it is not clear to me if it is in|out of scope to document > security requirements for TCP, or if the scope is limited to security > requirements for BGP (I can share some insight WRT the same issue we > (ipv6mh) are dealing with if you wish). > > > Michel. > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@ns.ietf.org Tue Jul 23 00:09:07 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14270 for ; Tue, 23 Jul 2002 00:09:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA25108 for rpsec-archive@odin.ietf.org; Tue, 23 Jul 2002 00:10:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA21093; Tue, 23 Jul 2002 00:02:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA21026 for ; Tue, 23 Jul 2002 00:02:52 -0400 (EDT) Received: from hotmail.com (f55.pav2.hotmail.com [64.4.37.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13651 for ; Tue, 23 Jul 2002 00:01:50 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 22 Jul 2002 21:02:21 -0700 Received: from 134.193.6.40 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 23 Jul 2002 04:02:20 GMT X-Originating-IP: [134.193.6.40] From: "Senthilkumar Ayyasamy" To: zinin@psg.com, bkhabs@nc.rr.com Cc: sandy@tislabs.com, riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... Date: Mon, 22 Jul 2002 23:02:20 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Jul 2002 04:02:21.0132 (UTC) FILETIME=[BE7068C0:01C231FD] Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org >Why? We have IS-IS, OSPF, and BGP that use link layer, IP, and TCP >as their transport. Each type of transport has its own set of >vulnerabilities. I accept your point that all the above listed protocols have their own list of vulnerabilities. As russ mentioned in one of his previous mails, we can have many documents relating to threat models for different routing protocol/routing types. I think there are some documents already on table( but mostly solution space which is not the goal of this working group but may provide some pointers.) But my concern is requirement document should be generic enough to cover all issues be it mobility, unicast/anycast/multicast, routing algo. It should provide input to respective routing protocol WG for further work. I have some queries: 1. Is there a need for separate security mechanism for routing and forwaring? Are their any tradeoffs ? 2. whether we need to have end to end security mechanism or between peers? -senthil _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@ns.ietf.org Tue Jul 23 00:13:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14658 for ; Tue, 23 Jul 2002 00:13:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA27541 for rpsec-archive@odin.ietf.org; Tue, 23 Jul 2002 00:14:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23464; Tue, 23 Jul 2002 00:06:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA23408 for ; Tue, 23 Jul 2002 00:06:53 -0400 (EDT) Received: from hotmail.com (f150.pav2.hotmail.com [64.4.37.150]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14034 for ; Tue, 23 Jul 2002 00:05:50 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 22 Jul 2002 21:06:21 -0700 Received: from 134.193.6.40 by pv2fd.pav2.hotmail.msn.com with HTTP; Tue, 23 Jul 2002 04:06:21 GMT X-Originating-IP: [134.193.6.40] From: "Senthilkumar Ayyasamy" To: pst@juniper.net, michel@arneill-py.sacramento.ca.us, zinin@psg.com, fenner@research.att.com Cc: riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... Date: Mon, 22 Jul 2002 23:06:21 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Jul 2002 04:06:21.0574 (UTC) FILETIME=[4DC0F260:01C231FE] Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org >you should document the practices of BGP/TCP+MD5 checksums >and BGP/TCP/IPSEC. what you are telling is a solution. But we are here to define the problem space and requirements. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 23 03:45:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02409 for ; Tue, 23 Jul 2002 03:45:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA20298 for rpsec-archive@odin.ietf.org; Tue, 23 Jul 2002 03:46:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20110; Tue, 23 Jul 2002 03:40:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20078 for ; Tue, 23 Jul 2002 03:40:22 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02173 for ; Tue, 23 Jul 2002 03:39:21 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17WuGY-000LE3-00; Tue, 23 Jul 2002 00:39:30 -0700 Date: Tue, 23 Jul 2002 00:38:07 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <3347439143.20020723003807@psg.com> To: "Michel Py" CC: "Bill Fenner" , riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... In-Reply-To: <2B81403386729140A3A899A8B39B046405E201@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E201@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Michel, > I have a very dumb question, as someone that just jumped in: > As an example, regarding BGP using TCP, and WRT the rpsec charter: Not dumb at all, in fact... >> Document threat models for routing systems. > My reading is that it is within scope to describe BGP vulnerabilities > induced by the use of TCP. Since routing protocols inherit vulnerabilities of the transport service they use, we definitely do not want to just say "hey, it's not our problem" (this is in fact what people did when said "just use ipsec" and we're trying to solve this now). On the other hand, we're a RTG area WG, and should not deep into every possible bit here, but should rather be concerned on how transport level vulnerabilities map to the routing protocols, i.e., if I have 5 possible ways to hijack a TCP session and 5 ways to replay a segment, ideally the model would tell me this can happen and refer the reader to a document describing those details. >> Document security requirements for routing systems. > However, here it is not clear to me if it is in|out of scope to document > security requirements for TCP, or if the scope is limited to security > requirements for BGP Security requirements for a routing protocol will eventually map to requirements for securing the transport subsystem, which may mean mechanisms embedded into the protocol itself or into the transport, so while the requirements for TCP as a specific transport instance are a potential outcome of the discussion on securing routing, they are not on the list of deliverables that the WG should explicitly concentrate on. > (I can share some insight WRT the same issue we > (ipv6mh) are dealing with if you wish). Please do. Thanks. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 23 04:03:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02927 for ; Tue, 23 Jul 2002 04:03:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA21941 for rpsec-archive@odin.ietf.org; Tue, 23 Jul 2002 04:04:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20722; Tue, 23 Jul 2002 03:55:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA20688 for ; Tue, 23 Jul 2002 03:55:18 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02709 for ; Tue, 23 Jul 2002 03:54:17 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17WuVe-000LPP-00; Tue, 23 Jul 2002 00:55:06 -0700 Date: Tue, 23 Jul 2002 00:53:45 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9448377092.20020723005345@psg.com> To: "Senthilkumar Ayyasamy" CC: bkhabs@nc.rr.com, sandy@tislabs.com, riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Senthil, >>Why? We have IS-IS, OSPF, and BGP that use link layer, IP, and TCP >>as their transport. Each type of transport has its own set of >>vulnerabilities. > I accept your point that all the above listed protocols have their own > list of vulnerabilities. As russ mentioned in one of his previous mails, we > can have many documents relating to threat models for different routing > protocol/routing types. I guess my point was that even though we have many, they do not have to be in different models, they are just specific instances of the transport subsystem. > I think there are some documents already on table( > but mostly solution space which is not the goal of this working group but > may provide some pointers.) We have the first approximation from Sandy and Dennis. Russ mentioned on the list something else might be coming. > But my concern is requirement document should be generic enough to cover > all issues be it mobility, unicast/anycast/multicast, routing algo. It > should provide input to respective routing protocol WG for further work. I agree, it should be generic. Note however, that even in a generic document you can still have practically useful classification, which is the case with transport, as well as, I believe, any other subsystem. I'm really looking forward to seeing the second document Russ mentioned, to see if I am convinced that we need more than one model ;) > I have some queries: > 1. Is there a need for separate security mechanism for routing and > forwaring? Are their any tradeoffs ? I'm not really sure what you mean by security for forwarding. Could you explain, please? > 2. whether we need to have end to end security mechanism or between peers? Answering questions like this is one of the reasons we have this WG--we need the community to agree on where the line between acceptable complexity and acceptable security should be drawn. The requirements document is supposed to answer these questions. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 23 05:01:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04027 for ; Tue, 23 Jul 2002 05:01:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA25127 for rpsec-archive@odin.ietf.org; Tue, 23 Jul 2002 05:02:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24395; Tue, 23 Jul 2002 04:59:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA24361 for ; Tue, 23 Jul 2002 04:59:51 -0400 (EDT) Received: from orbax.orange.dk (orbax.orange.dk [212.97.216.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03916 for ; Tue, 23 Jul 2002 04:58:49 -0400 (EDT) Received: from msgate-b.intra.mobilix.dk (msgate-b.intra.mobilix.dk [172.16.3.107]) by orbax.orange.dk (8.11.6+Sun/8.11.6) with ESMTP id g6N8xmI10198 for ; Tue, 23 Jul 2002 10:59:48 +0200 (CEST) Received: by msgate-b.intra.mobilix.dk with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 10:59:44 +0200 Message-ID: <76F2DFF76DE8414D95AF660570B0A40B0146A000@exch01.intra.orange.dk> From: Joachim Jensen To: rpsec@ietf.org Date: Tue, 23 Jul 2002 10:59:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [RPSEC] Rpsec update, seen from ISP point of view. Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org I feel like this conversation is about to forget the milestones and goals :) To get the 'Internet Draft' point 1 clear 'which details the threats to routing systems', I think we need to set up some points of action. Draft: Like what kind of protocols do we have to distinguish between? IGP/EGP, DV/LS (as we started out)? What kind of security issues do we have in the respective protocols? How about listing all thinkable protocols, and then figure out which security issues is related to the individual protocol, and which are general for some types.. Like for instance OSPF.. OSPF is an IGP using TCP as communication, working on layer-3.. Okay, What kind of threats do we see here? -Hmmm. OSPF is encapsulated in IP, which makes it subject to spoofing and Denial Of Service attacks. These vulnerabilities is sometimes more theoretical than actually problems, but you could imagine some kind of 'TCP RST' by bruteforcing TCP seq number.. or maybe creating 'fake' OSPF neighbors and sending LSA packets with fake network statements.. On the contrary this is not possible when using IS-IS, because IS-IS does not work on the networklayer (using OSI instead). This makes it more the less impossible for outsiders to destroy your IGP, unless they have physical access to your network and makes some kind of NSAP poisoning.. When we talk about BGP-4, also using TCP, we have more the less the same security issues as in OSPF.. The idea of MD5 hashing (RFC 2385) solves this problem. But as this is mostly used in IBGP, it's not of much use. I have never seen this used between upstreamers or at Internet eXchanges.. Maybe this could be somehow standard in the protocol?? -like some kind of RSA key being exchanged and negotiated during handshake? hmmm.. -seen from an ISP point of view. :-} Joachim Jerberg Jensen Orange Denmark AS_12435 _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 23 09:57:16 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12284 for ; Tue, 23 Jul 2002 09:57:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA11387 for rpsec-archive@odin.ietf.org; Tue, 23 Jul 2002 09:58:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11118; Tue, 23 Jul 2002 09:51:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA11084 for ; Tue, 23 Jul 2002 09:51:53 -0400 (EDT) Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11991 for ; Tue, 23 Jul 2002 09:50:50 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 23 Jul 2002 09:51:34 -0400 Message-ID: <3D3D5EBE.378FAE82@nc.rr.com> Date: Tue, 23 Jul 2002 09:48:46 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: sandy@tislabs.com, riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... References: <200207221432.g6MEWub12437@raven.gw.tislabs.com> <3D3C1BC3.E0E22276@nc.rr.com> <2730827788.20020722200116@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Alex, Alex Zinin wrote: > > Brian, > > I agree with Sandy here. Please see some comments below. > > Monday, July 22, 2002, 7:50:43 AM, Brian Haberman wrote: > ... > >> Also - there are lots of different ways to characterize protocols: > >> - by scope (IGP vs EGP) > >> - by algorithm (link state vs distance vector) > >> - by underlying layer (link layer (well, maybe not), network, transport) > > > No, I think we need to stay away from that one. > > Why? We have IS-IS, OSPF, and BGP that use link layer, IP, and TCP > as their transport. Each type of transport has its own set of > vulnerabilities. I think it becomes an issue of layering. 1. Is RPSEC addressing the threats to the routing protocols? 2. Will it address threats to TCP or UDP or IP? 3. Will it focus on threats to TCP, UDP, and IP that can affect the routing protocols? How much is different between #2 and #3? I don't know. My point was addressed to the link layer aspect. Looking at my comment, I didn't make that very clear. > > >> - by communication media (ATM (rather not touch that), wired, wireless) > > > How much does this differ from the link layer characterization? > > >> - by routed traffic (unicast vs multicast vs ..) > > > Agreed. This could be a key distinction. But since PIM relies > > on the unicast routing table, we may be talking different > > problem spaces. Of course DVMRP has its own route exchange > > which could be protected (not sure if it is worth the effort > > though). > > I think we should be able to cover both multicast and unicast RPs > within the same model if we make sure that the analysis of the > DB maintenance and rtg/fwd state establishment components includes > the instances used in PIM. I guess I am more focused on the protection of routing protocol messages on the wire. That is an area where the reason for sending the message differs greatly between PIM and a unicast routing protocol. PIM messages (such as the join) actually indicate where a receiver is located, there isn't an equivalent in unicast routing. > > >> I'm not sure that we should try to come up with threat models for > >> each different type in each way of assigning types - too much work. > > > We just need to look at the different protocols to see if the threat > > model varies. > > right, as well as make sure that the model we come up with is > descriptive enough to cover at least the existing RPs and those > under development. Agreed. Brian _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 23 10:09:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12828 for ; Tue, 23 Jul 2002 10:09:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12627 for rpsec-archive@odin.ietf.org; Tue, 23 Jul 2002 10:10:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11854; Tue, 23 Jul 2002 10:00:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11812 for ; Tue, 23 Jul 2002 10:00:50 -0400 (EDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12387 for ; Tue, 23 Jul 2002 09:59:47 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Tue, 23 Jul 2002 09:59:26 -0400 Message-ID: <3D3D6096.4B2C9C96@nc.rr.com> Date: Tue, 23 Jul 2002 09:56:38 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: Senthilkumar Ayyasamy , sandy@tislabs.com, riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... References: <9448377092.20020723005345@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Alex, > > 1. Is there a need for separate security mechanism for routing and > > forwaring? Are their any tradeoffs ? > > I'm not really sure what you mean by security for forwarding. > Could you explain, please? I made mention of this in another reply, but I will spell it out here in more detail. With PIM, some of the message exchanges on the wire occur to indicate that there is a host interested in a particular group. The message exchange identifies a receiver and causes the creation of forwarding state in the routers. In unicast, the message exchanges do not identify receivers. So, Senthil's question is whether or not the differences between those types of messages are great enough that there is actually a different threat model for routing and forwarding. Brian _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 23 10:48:10 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14784 for ; Tue, 23 Jul 2002 10:48:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA15080 for rpsec-archive@odin.ietf.org; Tue, 23 Jul 2002 10:49:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14822; Tue, 23 Jul 2002 10:42:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA14788 for ; Tue, 23 Jul 2002 10:42:55 -0400 (EDT) Received: from presque.djinesys.com (dns.nexthop.com [64.211.218.216]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14400 for ; Tue, 23 Jul 2002 10:41:52 -0400 (EDT) Received: (from root@localhost) by presque.djinesys.com (8.11.3/8.11.1) id g6NEgNT72910 for rpsec@ietf.org; Tue, 23 Jul 2002 10:42:23 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: from jhaas.nexthop.com (jhaas.nexthop.com [64.211.218.31]) by presque.djinesys.com (8.11.3/8.11.1) with ESMTP id g6NEgJ172902 for ; Tue, 23 Jul 2002 10:42:19 -0400 (EDT) (envelope-from jhaas@jhaas.nexthop.com) Received: (from jhaas@localhost) by jhaas.nexthop.com (8.11.3nb1/8.11.3) id g6NEgJK01005 for rpsec@ietf.org; Tue, 23 Jul 2002 10:42:19 -0400 (EDT) Date: Tue, 23 Jul 2002 10:42:19 -0400 From: Jeffrey Haas To: rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... Message-ID: <20020723104219.A813@nexthop.com> References: <200207221432.g6MEWub12437@raven.gw.tislabs.com> <3D3C1BC3.E0E22276@nc.rr.com> <2730827788.20020722200116@psg.com> <3D3D5EBE.378FAE82@nc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D3D5EBE.378FAE82@nc.rr.com>; from bkhabs@nc.rr.com on Tue, Jul 23, 2002 at 09:48:46AM -0400 X-Virus-Scanned: by AMaViS perl-11 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org On Tue, Jul 23, 2002 at 09:48:46AM -0400, Brian Haberman wrote: > I think it becomes an issue of layering. > > 1. Is RPSEC addressing the threats to the routing protocols? > 2. Will it address threats to TCP or UDP or IP? > 3. Will it focus on threats to TCP, UDP, and IP that can affect > the routing protocols? As I mentioned at an IDR session (Minneapolis?), what the protocol (in this case BGP) cares about is having a transport layer. Transport layer security is important to the security of the protocol, and a document should be documented to say what protections should be applied to the transport layer to secure the routing information at the transport layer. However, we shouldn't need a "secure transport layer for routing protocol". So, for example, document the vulnerabilities in a given transport protocol and hwo to secure it. Examples of this are IPSec and TCP+MD5. It would then be proper to point out that since a given protocol uses a given tranport, that it should be secured per the vulnerabilities document. If there are special considerations, these should also be pointed out. Hopefully what this means is we end up with a small handful of "securing transport layer " documents. We will then have a document per protocol (and per-extension if necessary) that says "use the following security documents with the following additional considerations". Securing the protocol above the transport layer is a separate issue. -- Jeff Haas NextHop Technologies _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@ns.ietf.org Tue Jul 23 21:13:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09309 for ; Tue, 23 Jul 2002 21:13:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA29257 for rpsec-archive@odin.ietf.org; Tue, 23 Jul 2002 21:14:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29075; Tue, 23 Jul 2002 21:04:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29043 for ; Tue, 23 Jul 2002 21:04:38 -0400 (EDT) Received: from mail1.netscreen.com ([63.126.135.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09170 for ; Tue, 23 Jul 2002 21:03:35 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca-local [10.100.10.21]) by mail1.netscreen.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6O124229410; Tue, 23 Jul 2002 18:02:06 -0700 (PDT) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 18:01:22 -0700 Message-ID: <541402FFDC56DA499E7E13329ABFEA87060C5E@SARATOGA> From: Gregory Lebovitz To: "'Senthilkumar Ayyasamy'" , rpsec@ietf.org Subject: RE: [RPSEC] Draft Status.... Date: Tue, 23 Jul 2002 17:57:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org -----Original Message----- From: Senthilkumar Ayyasamy [mailto:senthil_gct@hotmail.com] Sent: Monday, July 22, 2002 9:02 PM To: zinin@psg.com; bkhabs@nc.rr.com Cc: sandy@tislabs.com; riw@cisco.com; rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... >Why? We have IS-IS, OSPF, and BGP that use link layer, IP, and TCP >as their transport. Each type of transport has its own set of >vulnerabilities. I accept your point that all the above listed protocols have their own list of vulnerabilities. As russ mentioned in one of his previous mails, we can have many documents relating to threat models for different routing protocol/routing types. I think there are some documents already on table( but mostly solution space which is not the goal of this working group but may provide some pointers.) But my concern is requirement document should be generic enough to cover all issues be it mobility, unicast/anycast/multicast, routing algo. It should provide input to respective routing protocol WG for further work. [Gregory] While being generic enough to cover all the issues that may arise from mobility, unicast/anycast/multicast routing algo would be nice, some of us have the sense that this will not be adequate to fulfill the goal of enabling routing protocol designers to design secure routing protocols. As I presented in Yokohama, we will likely need to slice it somehow into sub-focus areas. How to slice it is the big question. I have some queries: 1. Is there a need for separate security mechanism for routing and forwaring? Are their any tradeoffs ? [Gregory] In a pure architectural framework sense, the routing protocols make up part of the "control plane" of a network. If I understand you correctly, the forwarding data is the application data, or the "data plane". The world of large service network designers learned over the past 70 years from SS7 and the PSTN that it makes sense to treat the Control Plane data as separate from Data Plane data. I'm not recommending an actual physical separation, or even a true logical separation between the two planes at this point. But I am encouraging us to see the routing protocols as the Control Plane, and to see the effort of securing that plane as a separate task from securing the Data Plane. We may end up using some similar mechanisms (like IPsec or such) where applicable. 2. whether we need to have end to end security mechanism or between peers? [Gregory] If by "end-to-end" you mean "application-host-to-application-host," then from my thinking above I'd say end-to-end is out of scope in this wg effort, and we ought focus on routing peer to routing peer or within a routing group, in the case of multicast-dependent protocols, like OSPF, RIP, PIM, etc. -senthil _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@ns.ietf.org Tue Jul 23 21:19:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09409 for ; Tue, 23 Jul 2002 21:19:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA29448 for rpsec-archive@odin.ietf.org; Tue, 23 Jul 2002 21:20:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29316; Tue, 23 Jul 2002 21:14:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29280 for ; Tue, 23 Jul 2002 21:14:36 -0400 (EDT) Received: from mail1.netscreen.com ([63.126.135.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09330 for ; Tue, 23 Jul 2002 21:13:35 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca-local [10.100.10.21]) by mail1.netscreen.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6O1C4200558; Tue, 23 Jul 2002 18:12:04 -0700 (PDT) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 18:11:22 -0700 Message-ID: <541402FFDC56DA499E7E13329ABFEA87060C5F@SARATOGA> From: Gregory Lebovitz To: "'Brian Haberman'" Cc: rpsec@ietf.org Subject: RE: [RPSEC] Draft Status.... Date: Tue, 23 Jul 2002 18:07:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org -----Original Message----- From: Brian Haberman [mailto:bkhabs@nc.rr.com] Sent: Tuesday, July 23, 2002 6:49 AM To: Alex Zinin Cc: sandy@tislabs.com; riw@cisco.com; rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... --SNIP-- > > >> - by communication media (ATM (rather not touch that), wired, wireless) > > > How much does this differ from the link layer characterization? > > >> - by routed traffic (unicast vs multicast vs ..) > > > Agreed. This could be a key distinction. But since PIM relies > > on the unicast routing table, we may be talking different > > problem spaces. Of course DVMRP has its own route exchange > > which could be protected (not sure if it is worth the effort > > though). > > I think we should be able to cover both multicast and unicast RPs > within the same model if we make sure that the analysis of the > DB maintenance and rtg/fwd state establishment components includes > the instances used in PIM. I guess I am more focused on the protection of routing protocol messages on the wire. That is an area where the reason for sending the message differs greatly between PIM and a unicast routing protocol. PIM messages (such as the join) actually indicate where a receiver is located, there isn't an equivalent in unicast routing. [Gregory] I agree on this point. I think multicast routing protocols will have some different threats than pure unicast routing protocols, mostly to do with whether or not you care about a certain group or a neighbor asking for that group. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@ns.ietf.org Tue Jul 23 21:27:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09530 for ; Tue, 23 Jul 2002 21:27:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA29655 for rpsec-archive@odin.ietf.org; Tue, 23 Jul 2002 21:28:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29602; Tue, 23 Jul 2002 21:25:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA29568 for ; Tue, 23 Jul 2002 21:25:47 -0400 (EDT) Received: from mail1.netscreen.com ([63.126.135.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09490 for ; Tue, 23 Jul 2002 21:24:46 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca-local [10.100.10.21]) by mail1.netscreen.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6O1NF201782; Tue, 23 Jul 2002 18:23:16 -0700 (PDT) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Jul 2002 18:22:33 -0700 Message-ID: <541402FFDC56DA499E7E13329ABFEA87060C60@SARATOGA> From: Gregory Lebovitz To: "'Alex Zinin'" , rpsec@ietf.org Subject: RE: [RPSEC] Draft Status.... Date: Tue, 23 Jul 2002 18:18:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org >-----Original Message----- >From: Alex Zinin [mailto:zinin@psg.com] >Sent: Monday, July 22, 2002 8:01 PM >To: Brian Haberman >Cc: sandy@tislabs.com; riw@cisco.com; rpsec@ietf.org >Subject: Re: [RPSEC] Draft Status.... > > >--snip-- > >>> I'm not sure that we should try to come up with threat models for >>> each different type in each way of assigning types - too much work. > >> We just need to look at the different protocols to see if the threat >> model varies. > >right, as well as make sure that the model we come up with is >descriptive enough to cover at least the existing RPs and those >under development. [gregory] Maybe we should start with creating the list of RPs that we care to consider. There are many RPs out there, but the deployment and use may not justify the effort of consideration here. An example that comes to mind (hope I'm not stomping anyone's baby here) is DVMPR, which just simply is not widely used or deployed these days. [gregory]Here is a list to start, and is intentionally NOT comprehensive, so please chime in with agreement/disagreement: ==v4== - OSPF - BGP - IS-IS - PIM-SM - RIP ==v6== - RIPng - OSPFv3 - BGP > Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 08:33:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09483 for ; Wed, 24 Jul 2002 08:33:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA20941 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 08:34:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19693; Wed, 24 Jul 2002 08:27:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA19649 for ; Wed, 24 Jul 2002 08:27:36 -0400 (EDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07601 for ; Wed, 24 Jul 2002 08:26:32 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 24 Jul 2002 08:27:17 -0400 Message-ID: <3D3E9C7C.5AB91D92@nc.rr.com> Date: Wed, 24 Jul 2002 08:24:28 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gregory Lebovitz CC: "'Alex Zinin'" , rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... References: <541402FFDC56DA499E7E13329ABFEA87060C60@SARATOGA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Gregory Lebovitz wrote: > > [gregory]Here is a list to start, and is intentionally NOT comprehensive, so > please chime in with agreement/disagreement: > ==v4== > - OSPF > - BGP > - IS-IS > - PIM-SM > - RIP > ==v6== > - RIPng > - OSPFv3 > - BGP PIM-SM supports IPv6 as well. I would not include DVMRP and MOSPF gets carried along with OSPF. Brian _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 11:55:08 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22083 for ; Wed, 24 Jul 2002 11:55:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05143 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 11:56:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04643; Wed, 24 Jul 2002 11:46:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04610 for ; Wed, 24 Jul 2002 11:46:07 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21783 for ; Wed, 24 Jul 2002 11:45:02 -0400 (EDT) Subject: RE: [RPSEC] Draft Status.... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jul 2002 08:45:34 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046406C9AB@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status.... Thread-Index: AcIzDdkUhy3DZgfPRJWDDIDGibJJHwAGx9vg From: "Michel Py" To: "Brian Haberman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA04611 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit Brian, > Brian Haberman wrote: > I would not include DVMRP Could you briefly explain why you would not include DVMRP? Thanks Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 13:05:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24108 for ; Wed, 24 Jul 2002 13:05:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA10875 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 13:06:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10110; Wed, 24 Jul 2002 12:58:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10078 for ; Wed, 24 Jul 2002 12:58:46 -0400 (EDT) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23758 for ; Wed, 24 Jul 2002 12:55:14 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 24 Jul 2002 12:03:29 -0400 Message-ID: <3D3ECF21.D3EC6E68@nc.rr.com> Date: Wed, 24 Jul 2002 12:00:33 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michel Py CC: rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... References: <2B81403386729140A3A899A8B39B046406C9AB@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Michel, Michel Py wrote: > > Brian, > > > Brian Haberman wrote: > > I would not include DVMRP > > Could you briefly explain why you would not include DVMRP? Sure. DVMRP is not going anywhere. It has been superceded by PIM, both SM and DM. There has been little, to no interest ever expressed in trying to "protect" the DVMRP protocol while there has been at least two proposals to secure PIM. There has been at least one mention of making DVMRP historic when/if it ever gets past the IESG. Regards, Brian _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 13:23:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25030 for ; Wed, 24 Jul 2002 13:23:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA11428 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 13:24:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10981; Wed, 24 Jul 2002 13:10:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10949 for ; Wed, 24 Jul 2002 13:10:51 -0400 (EDT) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24569 for ; Wed, 24 Jul 2002 13:09:47 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Wed, 24 Jul 2002 12:05:21 -0400 Message-ID: <3D3ECF8F.EBF53C0F@nc.rr.com> Date: Wed, 24 Jul 2002 12:02:23 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gregory Lebovitz , "'Alex Zinin'" , rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... References: <541402FFDC56DA499E7E13329ABFEA87060C60@SARATOGA> <3D3E9C7C.5AB91D92@nc.rr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Brian Haberman wrote: > > Gregory Lebovitz wrote: > > > > [gregory]Here is a list to start, and is intentionally NOT comprehensive, so > > please chime in with agreement/disagreement: > > ==v4== > > - OSPF > > - BGP > > - IS-IS > > - PIM-SM > > - RIP > > ==v6== > > - RIPng > > - OSPFv3 > > - BGP > > PIM-SM supports IPv6 as well. I would not include DVMRP and MOSPF gets > carried along with OSPF. I just had one more thought. Should MSDP be included in this list? Brian _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 21:01:55 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08227 for ; Wed, 24 Jul 2002 21:01:55 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA09939 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 21:02:57 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07826; Wed, 24 Jul 2002 20:45:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA07792 for ; Wed, 24 Jul 2002 20:44:59 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07618 for ; Wed, 24 Jul 2002 20:43:56 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17XWj5-000BMm-00; Wed, 24 Jul 2002 17:43:31 -0700 Date: Wed, 24 Jul 2002 17:42:09 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <108195280768.20020724174209@psg.com> To: Brian Haberman CC: sandy@tislabs.com, riw@cisco.com, rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... In-Reply-To: <3D3D5EBE.378FAE82@nc.rr.com> References: <200207221432.g6MEWub12437@raven.gw.tislabs.com> <3D3C1BC3.E0E22276@nc.rr.com> <2730827788.20020722200116@psg.com> <3D3D5EBE.378FAE82@nc.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Brian, >> Why? We have IS-IS, OSPF, and BGP that use link layer, IP, and TCP >> as their transport. Each type of transport has its own set of >> vulnerabilities. > I think it becomes an issue of layering. > 1. Is RPSEC addressing the threats to the routing protocols? > 2. Will it address threats to TCP or UDP or IP? > 3. Will it focus on threats to TCP, UDP, and IP that can affect > the routing protocols? > How much is different between #2 and #3? I don't know. My point was > addressed to the link layer aspect. Looking at my comment, I didn't > make that very clear. I hope my other message to the list also clarified this more. >> I think we should be able to cover both multicast and unicast RPs >> within the same model if we make sure that the analysis of the >> DB maintenance and rtg/fwd state establishment components includes >> the instances used in PIM. > I guess I am more focused on the protection of routing protocol > messages on the wire. That is an area where the reason for sending > the message differs greatly between PIM and a unicast routing > protocol. PIM messages (such as the join) actually indicate where > a receiver is located, there isn't an equivalent in unicast routing. So, in your example, the commonalities will be: both protocols have a transport system, both maintain state that is used to calculate some sort of forwarding state, the difference is in exact messages, and exact conditions under which the state is created and removed. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 21:21:18 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08743 for ; Wed, 24 Jul 2002 21:21:18 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA10601 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 21:22:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10307; Wed, 24 Jul 2002 21:11:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10278 for ; Wed, 24 Jul 2002 21:11:35 -0400 (EDT) Received: from sushi.toad.net (sushi.toad.net [162.33.130.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08544 for ; Wed, 24 Jul 2002 21:10:31 -0400 (EDT) Received: from gwu.edu (dboney-01.dslbr.toad.net [162.33.159.86]) by sushi.toad.net (8.11.6/8.11.6) with ESMTP id g6P1BYo03425 for ; Wed, 24 Jul 2002 21:11:34 -0400 Message-ID: <3D3F5045.3050307@gwu.edu> Date: Wed, 24 Jul 2002 21:11:33 -0400 From: "David G. Boney" Organization: The George Washington University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... References: <541402FFDC56DA499E7E13329ABFEA87060C60@SARATOGA> <3D3E9C7C.5AB91D92@nc.rr.com> <3D3ECF8F.EBF53C0F@nc.rr.com> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Brian Haberman wrote:
Brian Haberman wrote:
Gregory Lebovitz wrote:
[gregory]Here is a list to start, and is intentionally NOT comprehensive, so
please chime in with agreement/disagreement:
==v4==
- OSPF
- BGP
- IS-IS
- PIM-SM
- RIP
==v6==
- RIPng
- OSPFv3
- BGP
PIM-SM supports IPv6 as well.  I would not include DVMRP and MOSPF gets
carried along with OSPF.

I just had one more thought.  Should MSDP be included in this list?

Brian

_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec

I would suggest that MPLS/GMPLS be included in this list. There is a high degree of overlap in the functions of switching and routing. I think security of the control plane is the issue.
--

Sincerely,
David G. Boney

Graduate Research Assistant
Department of Electrical and Computer Engineering
The George Washington University
Phillips Hall, Suite 607
801 22nd Street, N.W.
Washington, DC 20052

http://student.seas.gwu.edu/~dboney
mailto:dboney@gwu.edu
Department Phone (202) 994-6083
Department Fax (202) 994-0227


_______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 21:33:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09098 for ; Wed, 24 Jul 2002 21:33:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA11542 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 21:34:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10799; Wed, 24 Jul 2002 21:29:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10765 for ; Wed, 24 Jul 2002 21:29:07 -0400 (EDT) Received: from mail1.netscreen.com ([63.126.135.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08924 for ; Wed, 24 Jul 2002 21:28:04 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca-local [10.100.10.21]) by mail1.netscreen.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6P1QO210003; Wed, 24 Jul 2002 18:26:25 -0700 (PDT) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Jul 2002 18:25:42 -0700 Message-ID: <541402FFDC56DA499E7E13329ABFEA87060C6C@SARATOGA> From: Gregory Lebovitz To: "'Brian Haberman'" , rpsec@ietf.org Subject: RE: [RPSEC] Draft Status.... Date: Wed, 24 Jul 2002 18:22:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Though not an authority on this topic at all, I did sit in on the MBONED WG last week, and heard pretty clearly that MSDP, currently at draft 13, was going to be pushed forward at the draft 6 version. It sounded like draft 6 really doesn't address a lot of the features/requirements people hoped for out of MSDP. I took from the discussion that maybe MSDP was not going to be used much in the wild. If I understood this clearly, I would not include it on the list. Can anyone with closer ties to MSDP, and its future, comment more authoritatively? -----Original Message----- From: Brian Haberman [mailto:bkhabs@nc.rr.com] Sent: Wednesday, July 24, 2002 9:02 AM To: Gregory Lebovitz; 'Alex Zinin'; rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... Brian Haberman wrote: > > Gregory Lebovitz wrote: > > > > [gregory]Here is a list to start, and is intentionally NOT comprehensive, so > > please chime in with agreement/disagreement: > > ==v4== > > - OSPF > > - BGP > > - IS-IS > > - PIM-SM > > - RIP > > ==v6== > > - RIPng > > - OSPFv3 > > - BGP > > PIM-SM supports IPv6 as well. I would not include DVMRP and MOSPF gets > carried along with OSPF. I just had one more thought. Should MSDP be included in this list? Brian _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 21:34:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09126 for ; Wed, 24 Jul 2002 21:34:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA11593 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 21:35:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10840; Wed, 24 Jul 2002 21:29:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA10808 for ; Wed, 24 Jul 2002 21:29:12 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08940 for ; Wed, 24 Jul 2002 21:28:08 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17XXP8-000GLu-00; Wed, 24 Jul 2002 18:26:58 -0700 Date: Wed, 24 Jul 2002 18:25:35 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <182197887096.20020724182535@psg.com> To: Brian Haberman CC: Senthilkumar Ayyasamy , sandy@tislabs.com, riw@cisco.com, Subject: Re: [RPSEC] Draft Status.... In-Reply-To: <3D3D6096.4B2C9C96@nc.rr.com> References: <9448377092.20020723005345@psg.com> <3D3D6096.4B2C9C96@nc.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Brian, Quite interesting interpretation, I would say... Let me give you my perspective on this. First, routing vs forwarding. Let's not re-invent the wheel and stick with the currently accepted definitions, i.e., in an overly simplified way, "routing" calculates the state that routers need for data packet forwarding, while "forwarding" is the actual process of relaying packets from one interface to another using the state calculated by routing. Regarding multicast state creation--it can be triggered either by the mechanisms within the multicast _routing_ protocols (employing router-to-router communication), such as PIM, or by the mechanisms within the _network_ protocols (employing host-to- router communication), such as IGMP. Network protocols are explicitly excluded from the charter of this WG, while routing protocols are explicitly included. The reason for this is that indeed the trust and security models for network protocols are quite different from those in the routing ones. For those who're interested in this topic, please tune in to SEND. Hope this helps. -- Alex Tuesday, July 23, 2002, 6:56:38 AM, Brian Haberman wrote: > Alex, >> > 1. Is there a need for separate security mechanism for routing and >> > forwaring? Are their any tradeoffs ? >> >> I'm not really sure what you mean by security for forwarding. >> Could you explain, please? > I made mention of this in another reply, but I will spell it out here > in more detail. With PIM, some of the message exchanges on the wire > occur to indicate that there is a host interested in a particular > group. The message exchange identifies a receiver and causes > the creation of forwarding state in the routers. In unicast, the > message exchanges do not identify receivers. So, Senthil's question > is whether or not the differences between those types of messages > are great enough that there is actually a different threat model > for routing and forwarding. > Brian _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 21:35:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09181 for ; Wed, 24 Jul 2002 21:35:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA11671 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 21:36:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11521; Wed, 24 Jul 2002 21:33:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11488 for ; Wed, 24 Jul 2002 21:33:38 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09079 for ; Wed, 24 Jul 2002 21:32:34 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17XXUL-000GzA-00; Wed, 24 Jul 2002 18:32:22 -0700 Date: Wed, 24 Jul 2002 18:30:59 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <77198211042.20020724183059@psg.com> To: Gregory Lebovitz CC: rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87060C60@SARATOGA> References: <541402FFDC56DA499E7E13329ABFEA87060C60@SARATOGA> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Tuesday, July 23, 2002, 6:18:53 PM, Gregory Lebovitz wrote: > [gregory] Maybe we should start with creating the list of RPs that we care > to consider. ... Might be a good idea. Note, however, that we should not use this list to have different models for each, but rather to make sure that the model we produce includes classifications that cover at least the existing protocols. The way one could do this is by identifying the subsystems within each protocol and classifying them. This will let us collect multiple examples of each class of subsystem. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 21:40:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09341 for ; Wed, 24 Jul 2002 21:40:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA11811 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 21:41:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11765; Wed, 24 Jul 2002 21:39:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11734 for ; Wed, 24 Jul 2002 21:39:41 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09298 for ; Wed, 24 Jul 2002 21:38:37 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17XXb3-000HmN-00; Wed, 24 Jul 2002 18:39:17 -0700 Date: Wed, 24 Jul 2002 18:37:55 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <63198626499.20020724183755@psg.com> To: Gregory Lebovitz CC: "'Brian Haberman'" , rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87060C5F@SARATOGA> References: <541402FFDC56DA499E7E13329ABFEA87060C5F@SARATOGA> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Gregory, Tuesday, July 23, 2002, 6:07:47 PM, Gregory Lebovitz wrote: > I guess I am more focused on the protection of routing protocol > messages on the wire. That is an area where the reason for sending > the message differs greatly between PIM and a unicast routing > protocol. PIM messages (such as the join) actually indicate where > a receiver is located, there isn't an equivalent in unicast routing. > [Gregory] I agree on this point. I think multicast routing protocols will > have some different threats than pure unicast routing protocols, mostly to > do with whether or not you care about a certain group or a neighbor asking > for that group. I agree they will be different, but I still think they are classifiable to be in the same model. It is still state, the difference is how you manage it. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 21:41:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09382 for ; Wed, 24 Jul 2002 21:41:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA11828 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 21:42:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11646; Wed, 24 Jul 2002 21:36:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA11612 for ; Wed, 24 Jul 2002 21:36:01 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09144 for ; Wed, 24 Jul 2002 21:34:57 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17XXXn-000HNU-00; Wed, 24 Jul 2002 18:35:56 -0700 Date: Wed, 24 Jul 2002 18:34:33 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <99198425110.20020724183433@psg.com> To: Brian Haberman CC: Gregory Lebovitz , rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... In-Reply-To: <3D3E9C7C.5AB91D92@nc.rr.com> References: <541402FFDC56DA499E7E13329ABFEA87060C60@SARATOGA> <3D3E9C7C.5AB91D92@nc.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Brian, > PIM-SM supports IPv6 as well. What about DM? > I would not include DVMRP Doesn't hurt looking at it from the classification perspective. > and MOSPF gets > carried along with OSPF. Hmmm... yes and no. Some subsystems do, some don't. E.g., transport, neighbors, adjacencies, DB maintenance are shared, but routing and forwarding state creation are different from OSPF. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 21:50:36 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09925 for ; Wed, 24 Jul 2002 21:50:36 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA12132 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 21:51:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA12096; Wed, 24 Jul 2002 21:49:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA12057 for ; Wed, 24 Jul 2002 21:49:19 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09795 for ; Wed, 24 Jul 2002 21:48:16 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17XXkk-000InM-00; Wed, 24 Jul 2002 18:49:18 -0700 Date: Wed, 24 Jul 2002 18:47:55 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <94199227213.20020724184755@psg.com> To: "David G. Boney" CC: rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... In-Reply-To: <3D3F5045.3050307@gwu.edu> References: <541402FFDC56DA499E7E13329ABFEA87060C60@SARATOGA> <3D3E9C7C.5AB91D92@nc.rr.com> <3D3ECF8F.EBF53C0F@nc.rr.com> <3D3F5045.3050307@gwu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit David, Please disable HTML, we have people with non-html clients > I would suggest that MPLS/GMPLS be included in this list. There is a high > degree of overlap in the functions of switching and routing. I think security > of the control plane is the issue. You have to be more specific, which part of MPLS you mean. If IGP extensions for TE, then we're essentially talking about extended topology info in IGPs and I have no problem with this, if signalling or VPNs, then no--let's walk first. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 22:04:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10231 for ; Wed, 24 Jul 2002 22:04:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA12888 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 22:05:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12604; Wed, 24 Jul 2002 22:00:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12572 for ; Wed, 24 Jul 2002 22:00:36 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10098 for ; Wed, 24 Jul 2002 21:59:32 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17XXvf-000K08-00; Wed, 24 Jul 2002 19:00:35 -0700 Date: Wed, 24 Jul 2002 18:59:12 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <14199904267.20020724185912@psg.com> To: Gregory Lebovitz CC: "'Senthilkumar Ayyasamy'" , rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87060C5E@SARATOGA> References: <541402FFDC56DA499E7E13329ABFEA87060C5E@SARATOGA> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Gregory, > But my concern is requirement document should be generic enough to cover > all issues be it mobility, unicast/anycast/multicast, routing algo. It > should provide input to respective routing protocol WG for further work. > [Gregory] While being generic enough to cover all the issues that may arise > from mobility, unicast/anycast/multicast routing algo would be nice, some of > us have the sense that this will not be adequate to fulfill the goal of > enabling routing protocol designers to design secure routing protocols. As I > presented in Yokohama, we will likely need to slice it somehow into > sub-focus areas. How to slice it is the big question. Agree. Even though the model should be generic in a sense of not being specific for a given protocol, it should still have enough details for each class of a particular subsystem. > I have some queries: > 1. Is there a need for separate security mechanism for routing and > forwaring? Are their any tradeoffs ? ... >... But I am encouraging us to see the routing protocols as the Control > Plane, and to see the effort of securing that plane as a separate task from > securing the Data Plane. Definitely. > 2. whether we need to have end to end security mechanism or between peers? > [Gregory] If by "end-to-end" you mean > "application-host-to-application-host," then from my thinking above I'd say > end-to-end is out of scope in this wg effort, and we ought focus on routing > peer to routing peer or within a routing group, in the case of > multicast-dependent protocols, like OSPF, RIP, PIM, etc. My reading of this question was a little bit different, i.e, whether we want to work on such issues as authenticity of reachability announcements or their withdrawals vs just securing the transport. My opinion is securing the transport connection is not enough, and though particular protocol designers may choose to limit their security mechanisms to transport integrity and authentication, this WG should look further. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 22:11:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10330 for ; Wed, 24 Jul 2002 22:11:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA13119 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 22:12:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12972; Wed, 24 Jul 2002 22:07:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12938 for ; Wed, 24 Jul 2002 22:07:30 -0400 (EDT) Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10294 for ; Wed, 24 Jul 2002 22:06:26 -0400 (EDT) Received: from [10.0.1.4] (SSH.BBN.COM [192.1.50.70]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05886 for ; Wed, 24 Jul 2002 22:08:06 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <2B81403386729140A3A899A8B39B046405E201@server2000.arneill-py.sacramento.c a.us> References: <2B81403386729140A3A899A8B39B046405E201@server2000.arneill-py.sacramento.c a.us> Date: Tue, 23 Jul 2002 21:14:44 -0400 To: From: Stephen Kent Subject: RE: [RPSEC] Draft Status.... Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Folks, Although it is certainly possible to discuss routing protocol vulnerabilities based on the specific transport protocols that are employed, I'd like to suggest a slightly different tact. Over time I think the IETF has evolved to adopt a threat model that assumes man-in-the-middle attacks. We have some protocols that were designed with a more limited threat model, one that did not admit such attacks, and this has proven to be a mistake. If we assume that man-in-the-middle attacks are a valid concern, then the details of the underlying transport protocol probably do not matter much, since we will require a crypto-security mechanism to protect the traffic. It also is appropriate to document the ways in which a routing protocol relies on the underlying transport protocol. I don't think that documenting vulnerabilities of otherwise unprotected transport protocols is the best strategy for our work. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Wed Jul 24 23:40:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12382 for ; Wed, 24 Jul 2002 23:40:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA16836 for rpsec-archive@odin.ietf.org; Wed, 24 Jul 2002 23:41:13 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA16603; Wed, 24 Jul 2002 23:33:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA16568 for ; Wed, 24 Jul 2002 23:33:57 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12247 for ; Wed, 24 Jul 2002 23:32:52 -0400 (EDT) Subject: RE: [RPSEC] Draft Status.... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jul 2002 20:33:25 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405E208@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status.... Thread-Index: AcIzMqHL5m2cuC57ToeCL0FC+dWEQgAWKLIA From: "Michel Py" To: "Brian Haberman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id XAA16569 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit >>> Brian Haberman wrote: >>> I would not include DVMRP >> Michel Py wrote: >> Could you briefly explain why you would not include DVMRP? > Brian Haberman wrote: > Sure. DVMRP is not going anywhere. It has been superceded by > PIM, both SM and DM. There has been little, to no interest ever > expressed in trying to "protect" the DVMRP protocol while there > has been at least two proposals to secure PIM. > There has been at least one mention of making DVMRP historic > when/if it ever gets past the IESG. Fair enough. > With PIM, some of the message exchanges on the wire occur to > indicate that there is a host interested in a particular group. > The message exchange identifies a receiver and causes the creation > of forwarding state in the routers. In unicast, the message > exchanges do not identify receivers. So, Senthil's question is > whether or not the differences between those types of messages are > great enough that there is actually a different threat model for > routing and forwarding. Without debating the topic itself, please do not associate it with unicast and/or multicast. The protocol I am developing (MHAP) is a unicast protocol but does use rendezvous points; parts of it are somehow similar to PIM. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Thu Jul 25 01:04:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13981 for ; Thu, 25 Jul 2002 01:04:13 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA20806 for rpsec-archive@odin.ietf.org; Thu, 25 Jul 2002 01:05:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20469; Thu, 25 Jul 2002 01:02:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20437 for ; Thu, 25 Jul 2002 01:02:51 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13962 for ; Thu, 25 Jul 2002 01:01:45 -0400 (EDT) Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 Jul 2002 22:02:19 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405E20A@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status, from a protocol developer's angle. Thread-Index: AcIzgYGSggJbXmYPQPCCznfBX8UIFQADwFcw From: "Michel Py" To: "Stephen Kent" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA20438 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit Rpsec folk, > Alex Zinin wrote: > My opinion is securing the transport connection is not > enough, and though particular protocol designers may choose > to limit their security mechanisms to transport integrity > and authentication, this WG should look further. That would definitely suit my own needs as a protocol developer (I came here for help). To place things in context, let me make a few statements that apply to my own views about protocol development, but might be applicable to others: - I am by no means a security expert (specifically, I do not know jack about crypto). In my experience, developing a routing protocol requires some expertise and experience with routing, and not that much with security. - Developing a routing protocol is all about one thing: compromises or trade-offs. In that bigger picture, security is one out of 10 topics that all have conflicting interests. A good routing protocol is not the most secure, but the one that has a good balance between (non-exhaustive list, in no specific order): - Simplicity. - Cost. - Performance. - Hardware/bandwidth requirements. - Stability. - Flexibility. - Security. - Ease of implementation. - Optimality. Etc.. WRT Alex's posting above, the choice that I would make about using transport integrity and authentication (or not using it) is dictated by many factors, that sometimes have very little to do with security. WRT Steve's posting below, let me say very clearly that stating things such as "if you have a problem with man-in-the-middle things, just use IPSEC" or "let's not waste time documenting vulnerabilities issued from unprotected transport mechanisms" are of no use to me. I don't know IPSec, but I know enough about it to understand that the consequences on the global balance of the routing protocol I am trying to design are so bad that I can't use it. In other words: my protocol (like many others) has a man-in-the-middle vulnerability, and the reason I don't use IPSEC to solve it is because I can't. > Stephen Kent wrote: > Over time I think the IETF has evolved to adopt a threat > model that assumes man-in-the-middle attacks. We have some > protocols that were designed with a more limited threat > model, one that did not admit such attacks, and this has > proven to be a mistake. Allow me to say mostly the same thing, viewed from another angle. When designing a routing protocol today, I have the general understanding of the security issue that is the current state of it. In other words, I am going to include in my protocol security mechanisms to dodge as many attacks as possible. Nevertheless, the bottom line still is: I'm doing my best, but it might not be enough. > If we assume that man-in-the-middle attacks are a > valid concern, I think we should. > then the details of the underlying transport protocol > probably do not matter much, since we will require a > crypto-security mechanism to protect the traffic. > It also is appropriate to document the ways in which a > routing protocol relies on the underlying transport > protocol. I don't think that documenting vulnerabilities > of otherwise unprotected transport protocols is the best > strategy for our work. My problem is that the crypto-security mechanism that I could use to protect the traffic does not exist. Until it is invented, I think that it is appropriate to document the vulnerability, as correct operational practices could reduce its scope; I do think that operational practices recommendations or BCPs are definitely within the scope of this WG. Michel. http://arneill-py.sacramento.ca.us/ipv6mh/ http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Thu Jul 25 03:50:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25521 for ; Thu, 25 Jul 2002 03:50:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA07190 for rpsec-archive@odin.ietf.org; Thu, 25 Jul 2002 03:51:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07095; Thu, 25 Jul 2002 03:49:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA07065 for ; Thu, 25 Jul 2002 03:49:26 -0400 (EDT) Received: from hotmail.com (f100.pav2.hotmail.com [64.4.37.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25485 for ; Thu, 25 Jul 2002 03:48:23 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 25 Jul 2002 00:48:56 -0700 Received: from 134.193.6.40 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 25 Jul 2002 07:48:55 GMT X-Originating-IP: [134.193.6.40] From: "Senthilkumar Ayyasamy" To: rpsec@ietf.org Date: Thu, 25 Jul 2002 02:48:55 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jul 2002 07:48:56.0241 (UTC) FILETIME=[BA94EA10:01C233AF] Subject: [RPSEC] threat models Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org As someone mentioned in some previous mails, studying threat models based on protocols, algorithms and its implementation sounds reasonable. Some of the present day security breaches in routing are due to *implementation* mistakes. Code red and nimada perplexed the BGP stability and had major effect across the internet. Many of BGP misconfigurations lead to security breaches. Hence studies on security vulnerabilities due to RP implementation is also essential. Remember,I am talking about high-level security requirements& threat(sr&t) and not robust coding (which is not an IETF topic as such.) We are currently discussing only the privacy mechanisms side of RP. But discussion should also consider various other vulnerabilities like: DDoS attacks on routing protols, breaches due to misconfigurations errors, and spoofing across routing systems. My opinion is lot have been done in protecting privacy& routing session by means of various encryption schemes in RP. Hence focussing on major threats like DDoS is important. I presume that vulnerabilities are more in inter-domain than in intra-domain. A complex situation comes with respect to idr where trust& security policy of peering domains vary. Hence particular attention to idr sr&t is essential. Let me make my previous question on e2e more clear: Whether we assume that a particular router trusts its neighbour alone or we advocating e2e authendication like ipsec. Possibly the answer will be the former one. But, It is also necessary that we should not disturbe *application host to host* secured communication by security mechanisms like IPSEC. - senthil. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Thu Jul 25 04:57:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26669 for ; Thu, 25 Jul 2002 04:57:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA11887 for rpsec-archive@odin.ietf.org; Thu, 25 Jul 2002 04:58:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11771; Thu, 25 Jul 2002 04:52:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA11737 for ; Thu, 25 Jul 2002 04:52:53 -0400 (EDT) Received: from hotmail.com (f3.pav2.hotmail.com [64.4.37.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26625 for ; Thu, 25 Jul 2002 04:51:49 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 25 Jul 2002 01:52:23 -0700 Received: from 134.193.6.40 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 25 Jul 2002 08:52:22 GMT X-Originating-IP: [134.193.6.40] From: "Senthilkumar Ayyasamy" To: zinin@psg.com, dboney@gwu.edu Cc: rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... Date: Thu, 25 Jul 2002 03:52:22 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jul 2002 08:52:23.0218 (UTC) FILETIME=[97B78120:01C233B8] Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > which part of MPLS you mean. > If IGP extensions for TE, then we're essentially talking about > extended topology info in IGPs and I have no problem with this, > if signalling or VPNs, then no--let's walk first. Some of relevant issues of st&r relevant to MPLS are: - Security issues wrt routing of traffic between two independent VPN . I remember reading a draft which talking about this situation. - label spoofing issues when BGP carries label information. - When considering IGP extensions for TE, security issues relevant to OSPF will hold. But control traffic generated in TE extensions will be more. I dont know whether there will be major security issues here. Some mpls experts out here can enlighten us. - senthil _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Thu Jul 25 05:26:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27054 for ; Thu, 25 Jul 2002 05:26:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA13456 for rpsec-archive@odin.ietf.org; Thu, 25 Jul 2002 05:27:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13340; Thu, 25 Jul 2002 05:21:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA13306 for ; Thu, 25 Jul 2002 05:21:47 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27027 for ; Thu, 25 Jul 2002 05:20:42 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17Xeob-000AlV-00; Thu, 25 Jul 2002 02:21:45 -0700 Date: Thu, 25 Jul 2002 02:20:22 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <115226374148.20020725022022@psg.com> To: "Senthilkumar Ayyasamy" CC: dboney@gwu.edu, rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Senthil > Some of relevant issues of st&r relevant to MPLS are: > - Security issues wrt routing of traffic between > two independent VPN . I remember reading a draft which > talking about this situation. outside the scope > - label spoofing issues when BGP carries label information. ditto > - When considering IGP extensions for TE, security issues > relevant to OSPF will hold. right > But control traffic generated in > TE extensions will be more. I dont know whether there will > be major security issues here. Some mpls experts out here > can enlighten us. TE signaling is outside the scope as well. Focusing the efforts is essential for making progress, especially at this stage. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Thu Jul 25 05:36:38 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27191 for ; Thu, 25 Jul 2002 05:36:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA14308 for rpsec-archive@odin.ietf.org; Thu, 25 Jul 2002 05:37:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14197; Thu, 25 Jul 2002 05:34:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA14129 for ; Thu, 25 Jul 2002 05:34:31 -0400 (EDT) Received: from hotmail.com (f117.pav2.hotmail.com [64.4.37.117]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27158 for ; Thu, 25 Jul 2002 05:33:26 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 25 Jul 2002 02:34:00 -0700 Received: from 134.193.6.40 by pv2fd.pav2.hotmail.msn.com with HTTP; Thu, 25 Jul 2002 09:34:00 GMT X-Originating-IP: [134.193.6.40] From: "Senthilkumar Ayyasamy" To: zinin@psg.com Cc: dboney@gwu.edu, rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... Date: Thu, 25 Jul 2002 04:34:00 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jul 2002 09:34:00.0759 (UTC) FILETIME=[685E0470:01C233BE] Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org I must accept your views at this point. The whole process of routing in MPLS architecture depends on traditional IGP schemes. I am not a MPLS expert but i see some people in the list have interest in security in MPlS. But security wrt to MPLS arch is itself in infant stage. Hence, they should see if any new st&r are introduced in mpls environment other than normal IGP st&r. >Focusing the efforts is essential for making progress, >especially at this stage. So,It is better to keep MPLS out of scope at this stage. _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Thu Jul 25 08:33:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01032 for ; Thu, 25 Jul 2002 08:33:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA23445 for rpsec-archive@odin.ietf.org; Thu, 25 Jul 2002 08:34:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22538; Thu, 25 Jul 2002 08:25:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22507 for ; Thu, 25 Jul 2002 08:25:02 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00682 for ; Thu, 25 Jul 2002 08:23:58 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA18740; Thu, 25 Jul 2002 08:20:44 -0400 (EDT) Date: Thu, 25 Jul 2002 08:20:43 -0400 (EDT) From: Russ White Reply-To: Russ White To: Alex Zinin cc: Gregory Lebovitz , "'Senthilkumar Ayyasamy'" , rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... In-Reply-To: <14199904267.20020724185912@psg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > > But my concern is requirement document should be generic enough to cover > > all issues be it mobility, unicast/anycast/multicast, routing algo. It > > should provide input to respective routing protocol WG for further work. > > > [Gregory] While being generic enough to cover all the issues that may arise > > from mobility, unicast/anycast/multicast routing algo would be nice, some of > > us have the sense that this will not be adequate to fulfill the goal of > > enabling routing protocol designers to design secure routing protocols. As I > > presented in Yokohama, we will likely need to slice it somehow into > > sub-focus areas. How to slice it is the big question. > > Agree. Even though the model should be generic in a sense of > not being specific for a given protocol, it should still have > enough details for each class of a particular subsystem. I think the difference in opinion here is in the way we are looking at the threat models.... As a (simple, an probably absurd) model, let's say we were to look at the "threat model of an onion." Now, we could say that there are many types of onions, and each one has a different threat model, or we could argue that onions are all similar enough to have enough characteristics in common so they can all share the same threat model. This is where we are at the moment, and I can see valid concerns on both sides. This is one reason why I think multiple threat models can be valid and useful. Beyond the obvious issue of what types of onions there are, though, there are multiple other ways of looking at this problem: -- What is the threat if an onion is used as a projectile? Then the threat model becomes an issue of looking at things like onion hardness, density, and maximum achievable velocity under various conditions, and the effective range given the ballistic coefiicient of an onion. -- What if the threat model is approaching the onion as a poison carrier? Then you must be concerned about the chemical composition of the beast, and the ability of the onion taste to cover the taste of particular classes of poisons. -- What if the threat model is approaching the onion as a device to make people cry? Then you would have an entirely different set of problems and issues to address. To me, each of these "threat models" is valid. Beyond the simple concept of a threat model for each type of protocol, or a threat model for other things, I see several threat models approaching the problem from other viewpoints that are all valid, useful, and would help in building a requirements doc. And I hope my example is not too absurd to blow your thinking cap off. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Thu Jul 25 08:59:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01955 for ; Thu, 25 Jul 2002 08:59:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25511 for rpsec-archive@odin.ietf.org; Thu, 25 Jul 2002 09:00:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24988; Thu, 25 Jul 2002 08:54:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA24955 for ; Thu, 25 Jul 2002 08:54:42 -0400 (EDT) Received: from smtp2.southeast.rr.com (smtp2.southeast.rr.com [24.93.67.83]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01765 for ; Thu, 25 Jul 2002 08:53:39 -0400 (EDT) Received: from mail6.nc.rr.com (fe6 [24.93.67.53]) by smtp2.southeast.rr.com (8.12.5/8.12.2) with ESMTP id g6PCtnAY011852; Thu, 25 Jul 2002 08:55:49 -0400 (EDT) Received: from nc.rr.com ([24.162.252.183]) by mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 25 Jul 2002 08:54:42 -0400 Message-ID: <3D3FF46A.D304C502@nc.rr.com> Date: Thu, 25 Jul 2002 08:51:54 -0400 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: Gregory Lebovitz , rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... References: <541402FFDC56DA499E7E13329ABFEA87060C60@SARATOGA> <3D3E9C7C.5AB91D92@nc.rr.com> <99198425110.20020724183433@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Alex, Alex Zinin wrote: > > Brian, > > > PIM-SM supports IPv6 as well. > > What about DM? draft-ietf-pim-dm-new-v2-01.txt was revised to include IPv6 as well. > > > I would not include DVMRP > > Doesn't hurt looking at it from the classification > perspective. I suppose not. My feeling though is that it may be wasted effort. > > > and MOSPF gets > > carried along with OSPF. > > Hmmm... yes and no. Some subsystems do, some don't. > E.g., transport, neighbors, adjacencies, DB maintenance > are shared, but routing and forwarding state creation > are different from OSPF. Do you envision type 6 LSAs being protected differently than other LSAs? Brian _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Thu Jul 25 09:26:27 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02906 for ; Thu, 25 Jul 2002 09:26:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA27227 for rpsec-archive@odin.ietf.org; Thu, 25 Jul 2002 09:27:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26957; Thu, 25 Jul 2002 09:21:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26908 for ; Thu, 25 Jul 2002 09:21:35 -0400 (EDT) Received: from wolfe.bbn.com (wolfe.bbn.com [128.89.80.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02715 for ; Thu, 25 Jul 2002 09:20:32 -0400 (EDT) Received: by wolfe.bbn.com (Postfix, from userid 13538) id 7576416484; Thu, 25 Jul 2002 09:21:03 -0400 (EDT) From: Charles Lynn To: "Michel Py" Cc: , CLynn@bbn.com Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. In-Reply-To: <2B81403386729140A3A899A8B39B046405E20A@server2000.arneill-py.sacramento.ca.us> Message-Id: <20020725132103.7576416484@wolfe.bbn.com> Date: Thu, 25 Jul 2002 09:21:03 -0400 (EDT) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Hi Michel, > I don't know IPSec, but I know enough about it to understand that the > consequences on the global balance of the routing protocol I am trying > to design are so bad that I can't use it. [FWIW, the IPsec WG is revising RFC 2401 ...] Can you explain why the current IPsec protocols are not able to satisfy your needs, or why their use would make the protocol you are designing not work well? E.g., "needs too much bandwidth for the low bit rate radio links", or "the protocol operates at the link-layer and IPsec is in the IP layer". Charlie _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@ns.ietf.org Thu Jul 25 20:30:17 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25492 for ; Thu, 25 Jul 2002 20:30:16 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA07420 for rpsec-archive@odin.ietf.org; Thu, 25 Jul 2002 20:31:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06505; Thu, 25 Jul 2002 20:19:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA06471 for ; Thu, 25 Jul 2002 20:19:46 -0400 (EDT) Received: from hotmail.com (f24.pav2.hotmail.com [64.4.37.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25316 for ; Thu, 25 Jul 2002 20:18:40 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 25 Jul 2002 17:19:16 -0700 Received: from 134.193.6.40 by pv2fd.pav2.hotmail.msn.com with HTTP; Fri, 26 Jul 2002 00:19:15 GMT X-Originating-IP: [134.193.6.40] From: "Senthilkumar Ayyasamy" To: senthil_gct@hotmail.com, rpsec@ietf.org Subject: Re: [RPSEC] threat models Date: Thu, 25 Jul 2002 19:19:15 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 26 Jul 2002 00:19:16.0050 (UTC) FILETIME=[138C3B20:01C2343A] Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Sandy, http://www.potaroo.net/ietf/ids/draft-murphy-bgp-vuln-00.txt talks about most of the threat issues related to BGP. But the document could cover some other vulnerabities too. >From: "Senthilkumar Ayyasamy" >To: rpsec@ietf.org >Subject: [RPSEC] threat models >Date: Thu, 25 Jul 2002 02:48:55 -0500 > >As someone mentioned in some previous mails, studying >threat models based on protocols, algorithms and its >implementation sounds reasonable. Some of the present >day security breaches in routing are due to >*implementation* mistakes. Code red and nimada perplexed >the BGP stability and had major effect across the internet. >Many of BGP misconfigurations lead to security breaches. >Hence studies on security vulnerabilities due to >RP implementation is also essential. Remember,I am talking >about high-level security requirements& threat(sr&t) and not >robust coding (which is not an IETF topic as such.) > >We are currently discussing only the privacy mechanisms side >of RP. But discussion should also consider various other >vulnerabilities like: DDoS attacks on routing protols, breaches >due to misconfigurations errors, and spoofing across routing >systems. My opinion is lot have been done in protecting >privacy& routing session by means of various encryption >schemes in RP. Hence focussing on major threats like DDoS >is important. > >I presume that vulnerabilities are more in inter-domain than in >intra-domain. A complex situation comes with respect to idr where >trust& security policy of peering domains vary. Hence particular >attention to idr sr&t is essential. > >Let me make my previous question on e2e more clear: >Whether we assume that a particular router trusts its neighbour >alone or we advocating e2e authendication like ipsec. Possibly the answer >will be the former one. But, It is also necessary that we >should not disturbe *application host to host* secured communication >by security mechanisms like IPSEC. > >- senthil. > > > > > > >_________________________________________________________________ >Join the world’s largest e-mail service with MSN Hotmail. >http://www.hotmail.com > > >_______________________________________________ >RPSEC mailing list >RPSEC@ietf.org >https://www1.ietf.org/mailman/listinfo/rpsec ------------------------------------------------ Ayysamy SenthilKumar M.S(computer networking) UMKC,MO-64112 ------------------------------------------------ Never will a man penetrate deeper into error than when he is continuing on a road that has led him to a great sucess -- Friederich von hayek ------------------------------------------------ _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@ns.ietf.org Fri Jul 26 01:21:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29996 for ; Fri, 26 Jul 2002 01:21:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28878 for rpsec-archive@odin.ietf.org; Fri, 26 Jul 2002 01:22:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28729; Fri, 26 Jul 2002 01:17:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA28697 for ; Fri, 26 Jul 2002 01:17:15 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29934 for ; Fri, 26 Jul 2002 01:16:09 -0400 (EDT) Subject: RE: [RPSEC] Draft Status.... MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Jul 2002 22:16:43 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046406C9B8@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status.... Thread-Index: AcIz2IP9+6XH/1uiSaKhRgr12mxPvQAivqxQ From: "Michel Py" To: "Russ White" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA28698 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit > Russ white wrote: > [the onion thing] > And I hope my example is not too absurd to blow your > thinking cap off. IMHO, a very good parabole. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@ns.ietf.org Fri Jul 26 01:58:28 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00485 for ; Fri, 26 Jul 2002 01:58:27 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA00294 for rpsec-archive@odin.ietf.org; Fri, 26 Jul 2002 01:59:33 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00198; Fri, 26 Jul 2002 01:53:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA00150 for ; Fri, 26 Jul 2002 01:53:31 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00398 for ; Fri, 26 Jul 2002 01:52:24 -0400 (EDT) Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 Jul 2002 22:52:59 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405E210@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status, from a protocol developer's angle. Thread-Index: AcIz3mTpST6Gfy7URZi6xuddsHPilwAhZo7Q From: "Michel Py" To: "Charles Lynn" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id BAA00151 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit Charlie, > Charles Lynn wrote: > Hi Michel, > Can you explain why the current IPsec protocols are not able to > satisfy your needs, or why their use would make the protocol you > are designing not work well? > E.g., "needs too much bandwidth for the low bit rate radio links", > or "the protocol operates at the link-layer and IPsec is in the IP > layer". It's a matter of extra latency. Long story made short, the concerned part of MHAP is a three-way (client, rendezvous point, endpoint), connectionless, UDP based animal. Note that authentication / signing (vs. data encryption) is what I am looking for, and it does require some crypto magic. My feeble understanding is that IPSEC, as I know it, and specifically the establishment of the SA, will require several back-and-forth packets that will introduce an unacceptable latency (I'm happy to provide any detail you wish about it, but I think they would be o/t for here). Also, there have been extensive concerns on the ipv6mh mailing list about "crypto DoS", which is that it is easier to DoS a router that uses crypto by feeding it encrypted packets full of foo (the rationale being that most routers can't handle decrypting packets at line speed), vs. a brute-force bandwidth based DoS. To push it to the extreme, what I need is a one-way, connectionless IPSEC ;-) Hopes this makes sense; if it does not please state it. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Fri Jul 26 13:28:57 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01109 for ; Fri, 26 Jul 2002 13:28:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA09768 for rpsec-archive@odin.ietf.org; Fri, 26 Jul 2002 13:30:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09564; Fri, 26 Jul 2002 13:24:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09528 for ; Fri, 26 Jul 2002 13:24:13 -0400 (EDT) Received: from mail1.netscreen.com ([63.126.135.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00914 for ; Fri, 26 Jul 2002 13:23:07 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca-local [10.100.10.21]) by mail1.netscreen.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g6QHKW229324; Fri, 26 Jul 2002 10:20:34 -0700 (PDT) Received: by NS-CA with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Jul 2002 10:19:50 -0700 Message-ID: <541402FFDC56DA499E7E13329ABFEA87060C86@SARATOGA> From: Gregory Lebovitz To: "'Michel Py'" , "'rpsec@ietf.org'" Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. Date: Fri, 26 Jul 2002 10:16:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org -----Original Message----- From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] Sent: Thursday, July 25, 2002 10:53 PM To: Charles Lynn Cc: rpsec@ietf.org Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. --snip-- My feeble understanding is that IPSEC, as I know it, and specifically the establishment of the SA, will require several back-and-forth packets that will introduce an unacceptable latency (I'm happy to provide any detail you wish about it, but I think they would be o/t for here). [Gregory] The back-and-forth packets are not actually from the IPsec, but from the IKE, the negotiation of the IPsec SA/keyes. Today, that negotiation is 6 packets, three in each direction. And yes, we have seen that in the wild it can take up to 4 seconds using Pre-Shared Secrets, and quite a bit longer, up to 10 seconds or more, if using Certificates are used (especially long when a Revocation List must be retrieved to check peer's certificate status is not revoked) to complete the full IKE/IPsec negotiation. [Gregory] IPsec itself actually requires no in-band negotiation. The sa and keys can be manually entered on both sides. But we have found this completely unscalable and difficult to manage. In addition, it ultimately leads to poorer security, because operators set the SA parameters and keys once and then forget about them; key freshness becomes an issue. [Gregory] I don't believe this info is o/t. I provide this info for others (sounds like you already know it) for this reason: if RPsec is going to sooner or later require some crypto mechanism for auth/privacy/data integrity/non-repudiation/anti-replay, then we are going to need to consider the key negotiation overhead of the system, and how that will affect adjacency establishment, timeouts, etc. Also, there have been extensive concerns on the ipv6mh mailing list about "crypto DoS", which is that it is easier to DoS a router that uses crypto by feeding it encrypted packets full of foo (the rationale being that most routers can't handle decrypting packets at line speed), vs. a brute-force bandwidth based DoS. [Gregory] In the case of IPsec (if I understand that stuff correctly), this type of DoS attack would necessitate the packets be spoofed in two ways - (1) the SPI would have to match an existing SA, and (2) the correct source address for that SPI would have to be injected. If those two look correct, the receiver would first do a authentication check on the HMAC signed portion of the packet for that SA. Assuming the attacker did not crack the auth key, that would fail, no further decrypt would be done. So the question is whether the router would keel over on the auth checks, assuming (1) and (2) were learned and done successfully. To push it to the extreme, what I need is a one-way, connectionless IPSEC ;-) Hopes this makes sense; if it does not please state it. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Fri Jul 26 16:12:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06989 for ; Fri, 26 Jul 2002 16:12:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA19861 for rpsec-archive@odin.ietf.org; Fri, 26 Jul 2002 16:13:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19667; Fri, 26 Jul 2002 16:09:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19638 for ; Fri, 26 Jul 2002 16:09:57 -0400 (EDT) Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06871 for ; Fri, 26 Jul 2002 16:08:51 -0400 (EDT) Received: from [128.89.89.100] (dhcp089-100.bbn.com [128.89.89.100]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06430; Fri, 26 Jul 2002 16:09:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <2B81403386729140A3A899A8B39B046405E20A@server2000.arneill-py.sacramento.c a.us> References: <2B81403386729140A3A899A8B39B046405E20A@server2000.arneill-py.sacramento.c a.us> Date: Fri, 26 Jul 2002 15:41:05 -0400 To: "Michel Py" From: Stephen Kent Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Michel, This is a WG to develop security requirements. The IESG has made it clear that security is a manor consideration for all protocol standards being developed. To that end, security needs to receive greater attention in the protocols you design, or they likely will not become IETF standards, if that is of any interest to you. >WRT Steve's posting below, let me say very clearly that stating things >such as "if you have a problem with man-in-the-middle things, just use >IPSEC" or "let's not waste time documenting vulnerabilities issued from >unprotected transport mechanisms" are of no use to me. I don't know >IPSec, but I know enough about it to understand that the consequences on >the global balance of the routing protocol I am trying to design are so >bad that I can't use it. Your second comment is intriguing. Do you plan on elaborating how you have come to dismiss IPsec, despite an avowed ignorance of the protocol? >In other words: my protocol (like many others) has a man-in-the-middle >vulnerability, and the reason I don't use IPSEC to solve it is because I >can't. To paraphrase your comment above, that statement tells me nothing. > >> Stephen Kent wrote: >> Over time I think the IETF has evolved to adopt a threat >> model that assumes man-in-the-middle attacks. We have some >> protocols that were designed with a more limited threat >> model, one that did not admit such attacks, and this has >> proven to be a mistake. > >Allow me to say mostly the same thing, viewed from another angle. When >designing a routing protocol today, I have the general understanding of >the security issue that is the current state of it. In other words, I am >going to include in my protocol security mechanisms to dodge as many >attacks as possible. > >Nevertheless, the bottom line still is: I'm doing my best, but it might >not be enough. Any maybe it's not good enough to become an IETF standard. > > If we assume that man-in-the-middle attacks are a >> valid concern, > >I think we should. > >> then the details of the underlying transport protocol >> probably do not matter much, since we will require a >> crypto-security mechanism to protect the traffic. >> It also is appropriate to document the ways in which a >> routing protocol relies on the underlying transport >> protocol. I don't think that documenting vulnerabilities >> of otherwise unprotected transport protocols is the best >> strategy for our work. > >My problem is that the crypto-security mechanism that I could use to >protect the traffic does not exist. Until it is invented, I think that >it is appropriate to document the vulnerability, as correct operational >practices could reduce its scope; I do think that operational practices >recommendations or BCPs are definitely within the scope of this WG. So, to summarize, you admit to knowing nothing about crypto and little or nothing about the IETF standard protocol for IP layer security, but you are confident that nothing exists that can address MITM problems for your routing protocol. Is that about it? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Fri Jul 26 16:27:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07389 for ; Fri, 26 Jul 2002 16:27:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20233 for rpsec-archive@odin.ietf.org; Fri, 26 Jul 2002 16:28:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20143; Fri, 26 Jul 2002 16:26:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA20107 for ; Fri, 26 Jul 2002 16:26:00 -0400 (EDT) Received: from david.io.com (root@david.io.com [199.170.88.28]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07302 for ; Fri, 26 Jul 2002 16:24:55 -0400 (EDT) From: mdfranz@io.com Received: from eris.io.com (IDENT:root@eris.io.com [199.170.88.11]) by david.io.com (8.11.6/8.11.2) with ESMTP id g6QKPxJ17557; Fri, 26 Jul 2002 15:25:59 -0500 Received: from localhost (mdfranz@localhost) by eris.io.com (8.11.6/8.11.6) with ESMTP id g6QKPxs22879; Fri, 26 Jul 2002 15:25:59 -0500 X-Authentication-Warning: eris.io.com: mdfranz owned process doing -bs Date: Fri, 26 Jul 2002 15:25:59 -0500 (CDT) To: Gregory Lebovitz cc: "'Michel Py'" , "'rpsec@ietf.org'" Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87060C86@SARATOGA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > [Gregory] IPsec itself actually requires no in-band negotiation. The sa and > keys can be manually entered on both sides. But we have found this > completely unscalable and difficult to manage. In addition, it ultimately > leads to poorer security, because operators set the SA parameters and keys > once and then forget about them; key freshness becomes an issue. Correct. IKE is where the extensive negotiation occurs and the potential latency as well as the most obvious and easy to exploit DoS issues. See below. > Also, there have been extensive concerns on the ipv6mh mailing list > about "crypto DoS", which is that it is easier to DoS a router that uses > crypto by feeding it encrypted packets full of foo (the rationale being > that most routers can't handle decrypting packets at line speed), vs. a > brute-force bandwidth based DoS. > > [Gregory] In the case of IPsec (if I understand that stuff correctly), this > type of DoS attack would necessitate the packets be spoofed in two ways - > (1) the SPI would have to match an existing SA, and (2) the correct source > address for that SPI would have to be injected. If those two look correct, > the receiver would first do a authentication check on the HMAC signed > portion of the packet for that SA. Assuming the attacker did not crack the > auth key, that would fail, no further decrypt would be done. So the question > is whether the router would keel over on the auth checks, assuming (1) and > (2) were learned and done successfully. > While this might be possible depending on the AH/ESP implementation, the real DoS problem with IPSEC is with IKE. Because it relies on UDP, many implementations are vulnerable to complete CPU exhaustion (even remote blind) usng only a small number of Message 1's (a fraction for non-crypto based DoS's) because they start doing the RSA stuff immediately. This is even the case with hardware accelaration. However, I believe there are various proposals in the works (such as JFK) to fix the DoS problem. The following link provides a good discussion and source code (although the attack is possible with 2-3 lines of Python/Perl code). http://alternic.net/drafts/drafts-s-t/draft-simpson-danger-isakmp-01.html - mdf _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Fri Jul 26 17:19:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09341 for ; Fri, 26 Jul 2002 17:19:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA23893 for rpsec-archive@odin.ietf.org; Fri, 26 Jul 2002 17:20:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23826; Fri, 26 Jul 2002 17:18:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA23793 for ; Fri, 26 Jul 2002 17:18:36 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09241 for ; Fri, 26 Jul 2002 17:17:30 -0400 (EDT) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id RAA25939; Fri, 26 Jul 2002 17:18:02 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma025926; Fri, 26 Jul 02 21:17:02 GMT Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g6QLHYs25348; Fri, 26 Jul 2002 17:17:34 -0400 (EDT) Date: Fri, 26 Jul 2002 17:17:34 -0400 (EDT) Message-Id: <200207262117.g6QLHYs25348@raven.gw.tislabs.com> To: rpsec@ietf.org Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. Cc: sandy@tislabs.com Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org >In other words, I am >going to include in my protocol security mechanisms to dodge as many >attacks as possible. The sticky problem comes when there exist several attacks: Attack 1 can make the Internet routing fall over in a heap Attack 2 can make the Internet routing fall over in a heap Attack 3 can make the Internet routing fall over in a heap Now, if Attack 1 and 2 can be countered quite easily without adversely affecting your protocol, but Attack 3 takes a lot of work, then what? Countering Attacks 1 and 2 would definitely be a good thing, but you're left with the uncomfortable result that the Internet is still subject to falling over in a heap. The classic answer to problems like this are (a) buy bigger hardware (hey, the windowing systems on our workstations are definitely a drain on the workstation's ability to devote cycles to sheer computation - it's just that nobody cares) and (b) use some sort of operational controls to counter the attacks. Like licensing to avoid the clueless, inspections to spot the careless, incarcerations to punish the malicious, etc. WRT your comments about IPSEC msg round trips - in some cases, that should not be a problem because the IPSEC connection establishment does not happen that often - BGP peering sessions or OSPF adjacencies get established and should not change that often. Perhaps your protocol is different. Lord knows the ad-hoc protocols have a problem in frequent topology changes, maybe yours is also quite dynamic. In that case, maybe a group protection would be suitable (there are groups working on that as well). Not all solutions work with all protocols, but they all have a common goal: to preserve the data source authenticity of the messages a router receives. We can state that goal as a security requirement. Maybe we can also give examples of solutions that will meet that requirement (tho' I think the charter says we're not looking at mechanisms at the moment), maybe related to a characterizaton of how the protocol works. But we can't possibly list all possible solutions to all possible existing protocols much less to all possible future protocol designs. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Fri Jul 26 19:31:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12072 for ; Fri, 26 Jul 2002 19:31:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA29870 for rpsec-archive@odin.ietf.org; Fri, 26 Jul 2002 19:32:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29232; Fri, 26 Jul 2002 19:28:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29198 for ; Fri, 26 Jul 2002 19:28:03 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11996 for ; Fri, 26 Jul 2002 19:26:55 -0400 (EDT) Received: from sandelman.ottawa.on.ca (virthost47.sandelman.ottawa.on.ca [192.139.46.47] (may be forged)) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g6QNRlW19367 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Fri, 26 Jul 2002 19:27:58 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g6QNRP8j006528 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Fri, 26 Jul 2002 19:27:47 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g6QMC5tj005160 for ; Fri, 26 Jul 2002 18:13:05 -0400 Message-Id: <200207262213.g6QMC5tj005160@marajade.sandelman.ottawa.on.ca> To: "'rpsec@ietf.org'" In-reply-to: Your message of "Fri, 26 Jul 2002 10:16:02 PDT." <541402FFDC56DA499E7E13329ABFEA87060C86@SARATOGA> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 26 Jul 2002 18:12:04 -0400 From: Michael Richardson Subject: [RPSEC] IPsec for protection of routing traffic Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org -----BEGIN PGP SIGNED MESSAGE----- {Gregory, your quoting style renders your posts nearly unparseable. Usenet style quoting is decade plus technology, and evolved for a good reason. Use it.} >>>>> "Gregory" == Gregory Lebovitz writes: Gregory> [Gregory] In the case of IPsec (if I understand that stuff correctly), this Gregory> type of DoS attack would necessitate the packets be spoofed in two ways - Gregory> (1) the SPI would have to match an existing SA, and (2) the correct source Gregory> address for that SPI would have to be injected. If those two look correct, The replay counter is checked even before the HMAC is checked. It has to be within a window, usually 64 packets, or the packet is discarded without any crypto or hashing being done. That means that the attack has to observe actual traffic in real time, and be able to inject DoS traffic in a timely manner. Operators have pointed out that is it trivial for an employee of an ISP to have all the required access as part of their regular job. On the other hand, such an employee likely also has access to the router configurations and could simply redirect all packets to another location. For regular BGP-type routing, I do not believe that there is any threat that crypto can prevent - there are more trivial and more effective ways for rogue employees (or crackers with enable access to core equipment) to mount a denial of service attack. IMHO, The major need to authenticate who may speak for which networks is more of a protection against mis-configuraiton than against maliciousness. MHAP, on the other hand, is a potential route signaling protocol between border routers of end-user networks to accomplish multihoming. The intermediary ISPs are not necessarily friendly here, but I do not believe we can do better than IPsec anyway. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPUHJMoqHRg3pndX9AQGDEAQA6TXmMJ8eKPScjBnYzfvgVPePD9dcRxvA 81Tm6fue7I1sfYQB7cu7J7ODBCMGdB4b2DZrRYltn3/EaYxyTPJDTW32e1WVfGjw jFfApNG15vXg+7f+riK4JXvioDlSUNWHrypeoaXPSLum9M4DBGcJQYcCQkg/dC3C ovmK3DPwB5M= =n7DD -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Fri Jul 26 19:31:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12085 for ; Fri, 26 Jul 2002 19:31:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA29881 for rpsec-archive@odin.ietf.org; Fri, 26 Jul 2002 19:33:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29279; Fri, 26 Jul 2002 19:28:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA29243 for ; Fri, 26 Jul 2002 19:28:29 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12019 for ; Fri, 26 Jul 2002 19:27:21 -0400 (EDT) Received: from sandelman.ottawa.on.ca (virthost47.sandelman.ottawa.on.ca [192.139.46.47] (may be forged)) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g6QNS9W19375 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 26 Jul 2002 19:28:23 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g6QNRP8n006528 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 26 Jul 2002 19:28:09 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g6QLuGW2005093; Fri, 26 Jul 2002 17:57:16 -0400 Message-Id: <200207262157.g6QLuGW2005093@marajade.sandelman.ottawa.on.ca> To: rpsec@ietf.org cc: "Michel Py" Subject: Re: [RPSEC] Draft Status, from a protocol developer's angle. In-reply-to: Your message of "Thu, 25 Jul 2002 22:52:59 PDT." <2B81403386729140A3A899A8B39B046405E210@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 26 Jul 2002 17:56:15 -0400 From: Michael Richardson Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Michel" == Michel Py writes: Michel> It's a matter of extra latency. Long story made short, the concerned Michel> part of MHAP is a three-way (client, rendezvous point, endpoint), Michel> connectionless, UDP based animal. Note that authentication / signing Michel> (vs. data encryption) is what I am looking for, and it does require some Michel> crypto magic. Sorry, Michel, you are asking for faerie dust. Stop dreaming. The fastest that you can get key agreement is with 1 1/2 round trips. IKEv1, proposed IKEv2 and JFK do it no faster than 2 round trips, sometimes 3 round trips. They also provide protection against passive eavesdropping of identities, protection against passive DoS, and some flexibility in negotiation of protocols. You can do a bit better than them, but in my opinion, not enough to justify any additional lines of code in a border router. As I have said several times on the ipv6mh list. The bits-on-the-wire problem is SOLVED. The key agreement problem is also solved. The problem is the trust model. Securing routing means that at some level every network needs to have a statement about what are acceptable routes to reach it. That means signed statements. That means a delegation of trust along the same paths that the allocations of address spaces flows. Michel> To push it to the extreme, what I need is a one-way, Michel> connectionless IPSEC ;-) See HIP. But it likely is DOS'able, you just may have to pay for public key cryptography rather than symmetric cryptography. It still requires that the trust problem be solved. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPUHFe4qHRg3pndX9AQFvVQP+JfzXDJtyqiHf200aWI8fBhTLK6faPERk TNsoFgLQK0lzihszPsnbpLMHmSwSsb56oYaWTjlodTUgdYNYDcQciE4CQzN7VDLw tzHr8M0v4yPNbGkmTBTRTjZY8ypqkuttxiRF0FHSomA6SKuwvoFT+p+1FjG5O/et TecUpdD1TzI= =OhXC -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Fri Jul 26 21:07:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13676 for ; Fri, 26 Jul 2002 21:07:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA04090 for rpsec-archive@odin.ietf.org; Fri, 26 Jul 2002 21:08:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03351; Fri, 26 Jul 2002 20:55:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03317 for ; Fri, 26 Jul 2002 20:55:34 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13537 for ; Fri, 26 Jul 2002 20:54:28 -0400 (EDT) Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 Jul 2002 17:55:03 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046406C9BE@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status, from a protocol developer's angle. Thread-Index: AcI04HZSe7dKwIDYQZeuTndrdQ1VxAAJ1uDg From: "Michel Py" To: "Stephen Kent" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id UAA03318 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit > Stephen Kent > So, to summarize, you admit to knowing nothing about crypto > and little or nothing about the IETF standard protocol for IP > layer security, but you are confident that nothing exists that > can address MITM problems for your routing protocol. Is that > about it? I'm not confident that it does not exist, I just haven't found. Can you point me to something? Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Fri Jul 26 21:33:35 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14245 for ; Fri, 26 Jul 2002 21:33:35 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA05088 for rpsec-archive@odin.ietf.org; Fri, 26 Jul 2002 21:34:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04495; Fri, 26 Jul 2002 21:30:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA04452 for ; Fri, 26 Jul 2002 21:29:58 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13981 for ; Fri, 26 Jul 2002 21:28:53 -0400 (EDT) Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 Jul 2002 18:29:26 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405E213@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status, from a protocol developer's angle. Thread-Index: AcI0yU+MYaEa5y0uQY++W02hZjLWmwAI96pA From: "Michel Py" To: "Gregory Lebovitz" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA04453 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit Gregory, > Gregory Lebovitz wrote: > [Gregory] can you explain why you don't want privacy (data > encryption) of the control plane messages, i.e. the routing > protocol messages themselves? If we assume either a man-in- > he-middle or an eaves-dropper threat, then one of the > protections we would want is concealing the contents of > the rp itself, no? The routing protocol messages themselves contain nothing confidential. The attacker would be able to obtain them easily by sending regular requests from his own endpoint; no need to encrypt that part. The threat that has been identified is that the attacker could feed an endpoint with forged routing protocol messages, that would fool the endpoint and make it send the traffic to a blackhole, or to the attacker. I other words, I just need to make sure that a routing update _really_ comes from the router it says it does. > [Gregory] The back-and-forth packets are not actually from the > IPsec, but from the IKE, the negotiation of the IPsec SA/keyes. > Today, that negotiation is 6 packets, three in each direction. > And yes, we have seen that in the wild it can take up to 4 > seconds using Pre-Shared Secrets, and quite a bit longer, up > to 10 seconds or more, if using Certificates are used (especially > long when a Revocation List must be retrieved to check peer's > certificate status is not revoked) to complete the full > IKE/IPsec negotiation. Anything longer than 200 ms is a show stopper for me (and I expect screams asking for a lot less). > [Gregory] IPsec itself actually requires no in-band negotiation. > The sa and keys can be manually entered on both sides. But we have > found this completely unscalable and difficult to manage. In > addition, it ultimately leads to poorer security, because operators > set the SA parameters and keys once and then forget about them; > key freshness becomes an issue. The scalability requirement I have is any prefix to any prefix, out of 2.5 Billion possible ones. No manual configuration is possible here. It might be interesting for you to have a quick look at the tentative addressing plan, as we are talking about the protocol to support it. http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt > [Gregory] I don't believe this info is o/t. I provide this info > for others (sounds like you already know it) for this reason: if > RPsec is going to sooner or later require some crypto mechanism > for auth/privacy/data integrity/non-repudiation/anti-replay, Likely, IMHO. > then we are going to need to consider the key negotiation overhead > of the system, and how that will affect adjacency establishment, > timeouts, etc. I completely agree. Allow me to re-phrase: The reason I am not using IPSEC is not because of IPSEC itself but because I do not know about any key/certificate distribution mechanism that IPSEC could use and that could suit my needs. The point I was trying to make is this: I have heard too many times "MITM is a no-brainer, use IPSEC and your MITM issue is solved". It just is not that simple. >> Also, there have been extensive concerns on the ipv6mh mailing >> list about "crypto DoS", which is that it is easier to DoS a >> router that uses crypto by feeding it encrypted packets full of >> foo (the rationale being that most routers can't handle decrypting >> packets at line speed), vs. a brute-force bandwidth based DoS. > mdfranz wrote: > While this might be possible depending on the AH/ESP implementation, > the real DoS problem with IPSEC is with IKE. Because it relies on UDP, > many implementations are vulnerable to complete CPU exhaustion (even > remote blind) usng only a small number of Message 1's (a fraction for > non-crypto based DoS's) because they start doing the RSA stuff > immediately. This is even the case with hardware accelaration. > However, I believe there are various proposals in the works (such as > JFK) to fix the DoS problem. I another post replying to Sandy, I will address this issue. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Fri Jul 26 21:38:59 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14317 for ; Fri, 26 Jul 2002 21:38:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA05190 for rpsec-archive@odin.ietf.org; Fri, 26 Jul 2002 21:40:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05132; Fri, 26 Jul 2002 21:35:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05100 for ; Fri, 26 Jul 2002 21:35:00 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14263 for ; Fri, 26 Jul 2002 21:33:55 -0400 (EDT) Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 Jul 2002 18:34:29 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405E214@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status, from a protocol developer's angle. Thread-Index: AcI064Xvty2EzHFKTDS4S2qEdVRKuwAHY5Og From: "Michel Py" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA05101 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit Sandy, >> Michel Py wrote: >> In other words, I am going to include in my protocol security >> mechanisms to dodge as many attacks as possible. > Sandy wrote: > The sticky problem comes when there exist several attacks: > Attack 1 can make the Internet routing fall over in a heap > Attack 2 can make the Internet routing fall over in a heap > Attack 3 can make the Internet routing fall over in a heap > Now, if Attack 1 and 2 can be countered quite easily without > adversely affecting your protocol, but Attack 3 takes a lot of > work, then what? Countering Attacks 1 and 2 would definitely be > a good thing, but you're left with the uncomfortable result that > the Internet is still subject to falling over in a heap. Correct. However there is some threat assessment to be done, as well as some pros/cons analysis. Threat assessment: In my case, attack 3 requires sniffing the traffic inside the telco. Two solutions: 1 - Do nothing, live with the attack 3 vulnerability. 2 - Use IPSEC / IKE Pros: - solves the MITM vulnerability. Cons: - creates a new vulnerability: crypto-DoS. - complexity / cost. Let's forget about the complexity / cost issue for the moment. What do you prefer? - a) A man in the middle attack that requires telco class sniffing. - b) A DoS that can potentially be launched by a script kiddie. > WRT your comments about IPSEC msg round trips - in some cases, > that should not be a problem because the IPSEC connection > establishment does not happen that often - BGP peering sessions > or OSPF adjacencies get established and should not change that > often. Perhaps your protocol is different. It is. A large part relies on BGP, and the scope of the problem we are discussing is _not_ securing the BGP peering sessions, as a 5-second delay to establish them once in a while is insignificant. > Lord knows the ad-hoc protocols have a problem in frequent > topology changes, maybe yours is also quite dynamic. It's more than dynamic, it's on-demand, any-to-any. > Not all solutions work with all protocols, but they all have > a common goal: to preserve the data source authenticity of > the messages a router receives. We can state that goal as > a security requirement. Exactly what I need, but not at the cost of a 5-second latency. > But we can't possibly list all possible solutions to all > possible existing protocols much less to all possible future > protocol designs. Of course we can't. But that does not mean that we could rely on generic mechanisms to solve generic problems either. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Fri Jul 26 21:56:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14873 for ; Fri, 26 Jul 2002 21:56:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA05449 for rpsec-archive@odin.ietf.org; Fri, 26 Jul 2002 21:58:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05304; Fri, 26 Jul 2002 21:48:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA05276 for ; Fri, 26 Jul 2002 21:48:31 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14608 for ; Fri, 26 Jul 2002 21:47:26 -0400 (EDT) Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 Jul 2002 18:48:00 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405E215@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status, from a protocol developer's angle. Thread-Index: AcI0/FyNTFb3HJGUT7i+PAUIDEvPSAAECc3w From: "Michel Py" To: "Michael Richardson" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA05277 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit Michael, Michel> It's a matter of extra latency. Long story made short, Michel> the concerned part of MHAP is a three-way (client, Michel> rendezvouspoint, endpoint), connectionless, UDP based Michel> animal. Note that authentication / signing (vs. data Michel> encryption) is what I am looking for, and it does Michel> require some crypto magic. > Michael Richardson wrote: > Sorry, Michel, you are asking for faerie dust. Stop dreaming. I'm not dreaming, just thinking loudly that there might be some gains by leveraging the RVP infrastructure. As you know, I did not make this a mailing list project, just trying to find people to look at the issue. > As I have said several times on the ipv6mh list. > The bits-on-the-wire problem is SOLVED. The key agreement problem is > also solved. The problem is the trust model. I agree with you and I have stated it publicly before. > See HIP. I'm looking at it, I have to corner Francis in Atlanta. > But it likely is DOS'able, you just may have to pay for > public key cryptography rather than symmetric cryptography. It > still requires that the trust problem be solved. Agree. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 01:25:24 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18054 for ; Sat, 27 Jul 2002 01:25:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA21217 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 01:26:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21162; Sat, 27 Jul 2002 01:21:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21089 for ; Sat, 27 Jul 2002 01:21:13 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17994 for ; Sat, 27 Jul 2002 01:20:07 -0400 (EDT) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17YK0t-000D47-00; Fri, 26 Jul 2002 22:21:11 -0700 Date: Fri, 26 Jul 2002 22:19:47 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9012504220.20020726221947@psg.com> To: Brian Haberman CC: Gregory Lebovitz , rpsec@ietf.org Subject: Re: [RPSEC] Draft Status.... In-Reply-To: <3D3FF46A.D304C502@nc.rr.com> References: <541402FFDC56DA499E7E13329ABFEA87060C60@SARATOGA> <3D3E9C7C.5AB91D92@nc.rr.com> <99198425110.20020724183433@psg.com> <3D3FF46A.D304C502@nc.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Brian, >> > I would not include DVMRP >> >> Doesn't hurt looking at it from the classification >> perspective. > I suppose not. My feeling though is that it may be wasted effort. Don't get too deep into it, just look if there's anything sufficiently different from other protocols in it that would be interesting for security analysis--you never know what you'll see tomorrow. >> > and MOSPF gets >> > carried along with OSPF. >> >> Hmmm... yes and no. Some subsystems do, some don't. >> E.g., transport, neighbors, adjacencies, DB maintenance >> are shared, but routing and forwarding state creation >> are different from OSPF. > Do you envision type 6 LSAs being protected differently than other > LSAs? No, but I do envision the difference between the amount of state and CPU calculation performed by OSPF and MOSPF (their state calculation models are different) depending on the number of new groups per sec that MOSPF has to deal with. Since exhaustion of CPU and memory is a threat, I would think there's a sufficient difference here. Note that I'm not saying the protocols are completely different, but that there are differences in their vulnerabilities. Thanks. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 01:25:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18068 for ; Sat, 27 Jul 2002 01:25:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA21234 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 01:26:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20937; Sat, 27 Jul 2002 01:16:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA20900 for ; Sat, 27 Jul 2002 01:16:16 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17944 for ; Sat, 27 Jul 2002 01:15:10 -0400 (EDT) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17YJur-000CkS-00; Fri, 26 Jul 2002 22:14:57 -0700 Date: Fri, 26 Jul 2002 22:13:33 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1212129971.20020726221333@psg.com> To: Russ White CC: Gregory Lebovitz , "'Senthilkumar Ayyasamy'" , Subject: Re: [RPSEC] Draft Status.... In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Russ, > And I hope my example is not too absurd to blow your thinking cap > off. Hey, liked the analogy a lot! :) I guess we should indeed wait to see what the other model will give us... Not trying to start an analogy argument, but it seems to me that in your example, the difference between models is in the set of characteristics that are considered in each, and, potentially, one could have one model, with classification of threats based of the onion's physical characteristics, chemical substances, internal structure, etc. etc. Anyways, we should probably really stop it here and wait till we see the other doc :) Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 01:39:13 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18283 for ; Sat, 27 Jul 2002 01:39:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA21919 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 01:40:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21876; Sat, 27 Jul 2002 01:37:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA21842 for ; Sat, 27 Jul 2002 01:37:24 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18259 for ; Sat, 27 Jul 2002 01:36:17 -0400 (EDT) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17YKFc-000DgK-00; Fri, 26 Jul 2002 22:36:25 -0700 Date: Fri, 26 Jul 2002 22:35:01 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <8613417703.20020726223501@psg.com> To: "Michel Py" CC: "Stephen Kent" , rpsec@ietf.org Subject: Re: [RPSEC] Draft Status, from a protocol developer's angle. In-Reply-To: <2B81403386729140A3A899A8B39B046405E20A@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E20A@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Wednesday, July 24, 2002, 10:02:19 PM, Michel Py wrote: ... > - Developing a routing protocol is all about one thing: compromises or > trade-offs. In that bigger picture, security is one out of 10 topics > that all have conflicting interests. A good routing protocol is not the > most secure, but the one that has a good balance between (non-exhaustive > list, in no specific order): > - Simplicity. > - Cost. > - Performance. > - Hardware/bandwidth requirements. > - Stability. > - Flexibility. > - Security. > - Ease of implementation. > - Optimality. > Etc.. Very very true. And if this WG manages to reach a consensus on what exactly this balance should be wrt security, we can say we accomplished our goals. BTW, the way I see the outcome from this WG as far as the requirements (2nd step) are concerned is a document listing a bunch of : - MUSTs (things you gotta secure in your protocol), - SHOULDs (things you better have secured, but if you have a very good reason not to, beware of dragons), - MAYs (might be a good idea to look into this) - and probably SHOULD NOTs (things like bootstrap problems) Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 01:45:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18341 for ; Sat, 27 Jul 2002 01:45:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA22090 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 01:46:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22074; Sat, 27 Jul 2002 01:45:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA22037 for ; Sat, 27 Jul 2002 01:45:04 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18335 for ; Sat, 27 Jul 2002 01:43:56 -0400 (EDT) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17YKN6-000E6t-00; Fri, 26 Jul 2002 22:44:09 -0700 Date: Fri, 26 Jul 2002 22:42:41 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <1713878105.20020726224241@psg.com> To: Gregory Lebovitz CC: "'Michel Py'" , "'rpsec@ietf.org'" Subject: Re: [RPSEC] Draft Status, from a protocol developer's angle. In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87060C86@SARATOGA> References: <541402FFDC56DA499E7E13329ABFEA87060C86@SARATOGA> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Friday, July 26, 2002, 10:16:02 AM, Gregory Lebovitz wrote: ... > [Gregory] I don't believe this info is o/t. Correct. Discussing applicability of existing security mechanisms to RPs definitely belongs here... provided, of course, that we don't spend till Atlanta discussing this instead of vulnerabilities :) > Also, there have been extensive concerns on the ipv6mh mailing list > about "crypto DoS", which is that it is easier to DoS a router that uses > crypto by feeding it encrypted packets full of foo (the rationale being > that most routers can't handle decrypting packets at line speed), vs. a > brute-force bandwidth based DoS. > [Gregory] In the case of IPsec (if I understand that stuff correctly), this > type of DoS attack would necessitate the packets be spoofed in two ways - > (1) the SPI would have to match an existing SA, and (2) the correct source > address for that SPI would have to be injected. If those two look correct, > the receiver would first do a authentication check on the HMAC signed > portion of the packet for that SA. Assuming the attacker did not crack the > auth key, that would fail, no further decrypt would be done. So the question > is whether the router would keel over on the auth checks, assuming (1) and > (2) were learned and done successfully. Besides, I've heard what people do is rate limit some stuff that goes up to the control plane to make sure the CPU does not go crazy even if an attack is mounted :) Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 07:38:04 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00534 for ; Sat, 27 Jul 2002 07:38:04 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA03155 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 07:39:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03114; Sat, 27 Jul 2002 07:35:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA03082 for ; Sat, 27 Jul 2002 07:35:04 -0400 (EDT) Received: from hotmail.com (f168.pav2.hotmail.com [64.4.37.168]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00513 for ; Sat, 27 Jul 2002 07:33:56 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 27 Jul 2002 04:34:32 -0700 Received: from 134.193.24.36 by pv2fd.pav2.hotmail.msn.com with HTTP; Sat, 27 Jul 2002 11:34:31 GMT X-Originating-IP: [134.193.24.36] From: "Senthilkumar Ayyasamy" To: zinin@psg.com, michel@arneill-py.sacramento.ca.us Cc: kent@bbn.com, rpsec@ietf.org Subject: Re: [RPSEC] Draft Status, from a protocol developer's angle. Date: Sat, 27 Jul 2002 06:34:31 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Jul 2002 11:34:32.0218 (UTC) FILETIME=[937A97A0:01C23561] Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org >BTW, the way I see the outcome from this WG as far as the requirements >(2nd step) are concerned is a document listing a bunch of : > > - MUSTs (things you gotta secure in your protocol), > - SHOULDs (things you better have secured, but if you have a very > good reason not to, beware of dragons), > - MAYs (might be a good idea to look into this) > - and probably SHOULD NOTs (things like bootstrap problems) A quick question!!! I am often confused with the terms *robustness* and *security*. The possible causes for lack of robustness is more than just security breaches. It also includes routing misconfigurations or many other reasons ( e.g MOAS conflicts in BGP.) So, Is *robustness of a network* a SHOULD requirement? As a side note, do you assume the routers to be functioning correct when defining threats and requirements? IPSEC or any type of encryption based authendication helps to prevent attackers from hijacking protocol communication. But any of the common security mechanisms works on a basic assumption that every node in a network works functionally correct. But imagine a situation when some of the routers are malfunctioning or acting as a DDoS agent. Does current security mechansims provide an answer in such scenarios? perlman's byzantine robustness provides a solution by means of consensus approach. But i dont know how much the consensus based algorithms are practical. - senthil. But my point is: the threat models SHOULD consider cases of networks with malicious routers. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 13:12:58 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04895 for ; Sat, 27 Jul 2002 13:12:58 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA15097 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 13:14:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14839; Sat, 27 Jul 2002 13:08:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14805 for ; Sat, 27 Jul 2002 13:08:46 -0400 (EDT) Received: from wolfe.bbn.com (wolfe.bbn.com [128.89.80.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04816 for ; Sat, 27 Jul 2002 13:07:40 -0400 (EDT) Received: by wolfe.bbn.com (Postfix, from userid 13538) id 5DF3516484; Sat, 27 Jul 2002 13:08:11 -0400 (EDT) From: Charles Lynn To: rpsec@ietf.org Cc: zinin@psg.com, Gregory@netscreen.com, CLynn@bbn.com Subject: Re: [RPSEC] Draft Status, from a protocol developer's angle. In-Reply-To: <1713878105.20020726224241@psg.com> Message-Id: <20020727170811.5DF3516484@wolfe.bbn.com> Date: Sat, 27 Jul 2002 13:08:11 -0400 (EDT) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > > [Gregory] In the case of IPsec (if I understand that stuff > > correctly), this type of DoS attack would necessitate the packets > > be spoofed in two ways - > > (1) the SPI would have to match an existing SA, and > > (2) the correct source address for that SPI would have to be > > injected. In a router, might not other packet characteristics, e.g., TTL and incoming interface, be added to the list of pre-crypto checks that must be satisfied? > > If those two look correct, the receiver would first do a > > authentication check on the HMAC signed portion of the packet for > > that SA. Assuming the attacker did not crack the auth key, that > > would fail, no further decrypt would be done. Correct. > > So the question is whether the router would keel over on the auth > > checks, assuming (1) and (2) were learned and done successfully. Yes. > [Alex] Besides, I've heard what people do is rate limit some stuff > that goes up to the control plane to make sure the CPU does not go > crazy even if an attack is mounted :) This can be broken into two parts: the functions that need CPU cycles and the functions handled by the crypto hardware that the box would likely have, at least if it was labeled "high performance". Based on what I've heard about modern crypto chips and the pre-crypto checks, I do not think that this type of DoS is a particularly hard to solve problem, at least if the router design criteria includes routing protocol DoS prevention. Charlie _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 15:12:23 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06471 for ; Sat, 27 Jul 2002 15:12:23 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19201 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 15:13:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19160; Sat, 27 Jul 2002 15:11:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19126 for ; Sat, 27 Jul 2002 15:11:20 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06441 for ; Sat, 27 Jul 2002 15:10:12 -0400 (EDT) Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 27 Jul 2002 12:10:47 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405E218@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status, from a protocol developer's angle. Thread-Index: AcI04HZSe7dKwIDYQZeuTndrdQ1VxAAvrCQA From: "Michel Py" To: "Stephen Kent" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA19127 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit Steve, >> Nevertheless, the bottom line still is: I'm doing my best, >> but it might not be enough. > Stephen Kent wrote: > Any maybe it's not good enough to become an IETF standard. This is not my primary goal. Let me give you a few examples about "standards": [precision: I do *not* work for Cisco] - EIGRP. I use it all the time, and there is no IETF equivalent. - HSRP. I use it all the time, and switching to VRPP is not high on my priority list. - ISL: I am phasing it out in favor of 802.1q. Have any idea where 802.1q comes from? The IETF is not the only place where standards are developed. If this workgroup produces unrealistic requirements that protocol developers can't meet, protocol developers will either ignore the requirements (which is possible, as it is very well understood that a routing protocol can't please everyone), or take their work outside the IETF (which is what I have done already, AAMOF). If this WG doesn't mind some advice, try not to get into the same schism as multi6, which is deadlocked in non-consensual, impossible to meet requirements. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 15:33:30 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06652 for ; Sat, 27 Jul 2002 15:33:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA19996 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 15:34:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19422; Sat, 27 Jul 2002 15:30:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA19378 for ; Sat, 27 Jul 2002 15:30:03 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06611 for ; Sat, 27 Jul 2002 15:28:55 -0400 (EDT) Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 27 Jul 2002 12:29:31 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405E219@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status, from a protocol developer's angle. Thread-Index: AcI1YcnPsoSYMf1YQXeGMiJQbmmRgwAP8PeA From: "Michel Py" To: "Senthilkumar Ayyasamy" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA19379 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit > Senthilkumar Ayyasamy wrote: > So, Is *robustness of a network* a SHOULD requirement? It's a MUST, but the definition of robustness can be discussed. To that regard, the exact same applies to security. It appears to me that it might not clear to everyone on this list what the job of a protocol developer is: my job is to put a bunch of pieces together to create a protocol. These pieces are other protocols, mostly already existing. I have a great deal of control in the way I assemble the pieces together, but I don't have the time to re-design each piece I am given to work with. That is where the compromise and balance comes into play. If you give me requirements such as: Security: 100% Optimality: 100% ... Robustness: 100% Stability: 100% I will gladly refer you to someone that is in the business of doing miracles. I'm not, I'm in the business of designing protocols, which is more something like deciding between: Security: 85% Robustness: 80% vs. Security: 80% Robustness: 85% Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 17:58:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07944 for ; Sat, 27 Jul 2002 17:58:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA24663 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 17:59:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24614; Sat, 27 Jul 2002 17:53:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA24580 for ; Sat, 27 Jul 2002 17:53:08 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07915 for ; Sat, 27 Jul 2002 17:52:01 -0400 (EDT) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17YZTr-000LNw-00; Sat, 27 Jul 2002 14:52:07 -0700 Date: Sat, 27 Jul 2002 14:50:44 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <10571960814.20020727145044@psg.com> To: "Senthilkumar Ayyasamy" CC: michel@arneill-py.sacramento.ca.us, kent@bbn.com, rpsec@ietf.org Subject: Re: [RPSEC] Draft Status, from a protocol developer's angle. In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Senthil, I believe that MUSTs and SHOULDs need to be used with very quantifiable definitions of the requirements, so that later it is possible to tell if that MUST or SHOULD has been satisfied. The term "robustness" or the adjective "robust" are too generic and usually used to characterize protocols and their implementations that are able to work well under unusual and stress conditions, such as too much state to announce or too many messages to process, or neighbors behaving incorrectly, or being under an attack. So, I would say that robustness is a more generic, collective, and pretty vague characteristic that will be hard to formally evaluate. The term "Byzantine robustness" is more specific. I think we need to look into the area of attacks when some of the trusted routers are compromised. There can be a range of solutions here that need to be evaluated keeping the engineering trade-offs in mind. In some cases attack prevention might be required, in others attack detection and elimination may be sufficient. -- Alex Saturday, July 27, 2002, 4:34:31 AM, Senthilkumar Ayyasamy wrote: >>BTW, the way I see the outcome from this WG as far as the requirements >>(2nd step) are concerned is a document listing a bunch of : >> >> - MUSTs (things you gotta secure in your protocol), >> - SHOULDs (things you better have secured, but if you have a very >> good reason not to, beware of dragons), >> - MAYs (might be a good idea to look into this) >> - and probably SHOULD NOTs (things like bootstrap problems) > A quick question!!! > I am often confused with the terms *robustness* and > *security*. The possible causes for lack of robustness is more > than just security breaches. It also includes routing > misconfigurations or many other reasons ( e.g MOAS conflicts > in BGP.) So, Is *robustness of a network* a SHOULD requirement? > As a side note, do you assume the routers to be > functioning correct when defining threats and requirements? > IPSEC or any type of encryption based authendication helps > to prevent attackers from hijacking protocol communication. > But any of the common security mechanisms works on a basic > assumption that every node in a network works functionally > correct. But imagine a situation when some of the routers > are malfunctioning or acting as a DDoS agent. > Does current security mechansims provide an answer in such > scenarios? > perlman's byzantine robustness provides a solution by means > of consensus approach. But i dont know how much the consensus > based algorithms are practical. > - senthil. > But my point is: the threat models SHOULD consider cases of > networks with malicious routers. > _________________________________________________________________ > MSN Photos is the easiest way to share and print your photos: > http://photos.msn.com/support/worldwide.aspx > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 18:19:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08113 for ; Sat, 27 Jul 2002 18:19:15 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA25454 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 18:20:21 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25369; Sat, 27 Jul 2002 18:16:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25334 for ; Sat, 27 Jul 2002 18:16:14 -0400 (EDT) Received: from hotmail.com (f108.pav2.hotmail.com [64.4.37.108]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08097 for ; Sat, 27 Jul 2002 18:15:07 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 27 Jul 2002 15:15:43 -0700 Received: from 134.193.24.32 by pv2fd.pav2.hotmail.msn.com with HTTP; Sat, 27 Jul 2002 22:15:42 GMT X-Originating-IP: [134.193.24.32] From: "Senthilkumar Ayyasamy" To: rpsec@ietf.org Subject: Fwd: Re: [RPSEC] Draft Status, from a protocol developer's angle. Date: Sat, 27 Jul 2002 17:15:42 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 27 Jul 2002 22:15:43.0166 (UTC) FILETIME=[25F365E0:01C235BB] Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org >From: Charles Lynn >To: "Senthilkumar Ayyasamy" >CC: CLynn@BBN.Com >Subject: Re: [RPSEC] Draft Status, from a protocol developer's angle. >Date: Sat, 27 Jul 2002 13:27:48 -0400 (EDT) > >Senthil, > > > A quick question!!! > > I am often confused with the terms *robustness* and *security*. The > > possible causes for lack of robustness is more than just security > > breaches. It also includes routing misconfigurations or many other > > reasons ( e.g MOAS conflicts in BGP.) > > So, Is *robustness of a network* a SHOULD requirement? > >I think it should be. > > > As a side note, do you assume the routers to be functioning correct > > when defining threats and requirements? > >The presence of one or more compromised routers should definitely be >considered when defining threats and requirements, as should be the >possibility of the router being "misconfigured". > > > IPSEC or any type of encryption based authentication helps to > > prevent attackers from hijacking protocol communication. But any of > > the common security mechanisms works on a basic assumption that > > every node in a network works functionally correct. > >I think that is too strong. > > > But imagine a situation when some of the routers are malfunctioning > > or acting as a DDoS agent. Does current security mechanisms > >I suspect that the mechanisms applicable to malfunctioning routers >are not identical to those for prevention of acting as a DDoS agent. >E.g., DDoS agent prevention may include data-plane mechanisms. > > > provide an answer in such scenarios? perlman's byzantine robustness > > provides a solution by means of consensus approach. But i dont know > > how much the consensus based algorithms are practical. > >While practicality considerations will influence what we can implement, >or maybe the MUST vs SHOULD in the recommendations that we produce, >I do not think that we should let them be the basis for excluding our >consideration of the treats. If we identify the problems, someone or >some vendor may be motivated to find better solutions than we currently >have in our tool boxes. > > > But my point is: the threat models SHOULD consider cases of networks > > with malicious routers. > >I agree, especially where "misconfigured" is part of "malicious". > >Charlie _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 18:24:37 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08158 for ; Sat, 27 Jul 2002 18:24:37 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA25570 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 18:25:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25509; Sat, 27 Jul 2002 18:21:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA25474 for ; Sat, 27 Jul 2002 18:21:12 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08133 for ; Sat, 27 Jul 2002 18:20:05 -0400 (EDT) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17YZv3-000MXO-00; Sat, 27 Jul 2002 15:20:13 -0700 Date: Sat, 27 Jul 2002 15:18:49 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <9773646588.20020727151849@psg.com> To: "Michel Py" CC: "Stephen Kent" , rpsec@ietf.org Subject: Re: [RPSEC] Draft Status, from a protocol developer's angle. In-Reply-To: <2B81403386729140A3A899A8B39B046405E218@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405E218@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Saturday, July 27, 2002, 12:10:47 PM, Michel Py wrote: > Steve, >>> Nevertheless, the bottom line still is: I'm doing my best, >>> but it might not be enough. >> Stephen Kent wrote: >> Any maybe it's not good enough to become an IETF standard. > This is not my primary goal. Let me give you a few examples about > "standards": > [precision: I do *not* work for Cisco] > - EIGRP. I use it all the time, and there is no IETF equivalent. > - HSRP. I use it all the time, and switching to VRPP is not high on my > priority list. > - ISL: I am phasing it out in favor of 802.1q. Have any idea where > 802.1q comes from? > The IETF is not the only place where standards are developed. Michel, Steve, this an off-topic for this list, please keep it focused. > If this > workgroup produces unrealistic requirements that protocol developers > can't meet, protocol developers will either ignore the requirements > (which is possible, as it is very well understood that a routing > protocol can't please everyone), or take their work outside the IETF > (which is what I have done already, AAMOF). > If this WG doesn't mind some advice, try not to get into the same schism > as multi6, which is deadlocked in non-consensual, impossible to meet > requirements. The only way to make sure right things happen somewhere in the IETF is to be part of the process. If you consider yourself a member of this WG and are really concerned with the quality of its products, I'm sure we'll soon see a lot of constructive suggestions and useful contributions to its work. Thanks. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 19:59:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08950 for ; Sat, 27 Jul 2002 19:59:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA28416 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 20:00:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28222; Sat, 27 Jul 2002 19:57:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28188 for ; Sat, 27 Jul 2002 19:57:52 -0400 (EDT) Received: from web12906.mail.yahoo.com (web12906.mail.yahoo.com [216.136.174.73]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08940 for ; Sat, 27 Jul 2002 19:56:43 -0400 (EDT) Message-ID: <20020727235724.83171.qmail@web12906.mail.yahoo.com> Received: from [131.123.177.104] by web12906.mail.yahoo.com via HTTP; Sat, 27 Jul 2002 16:57:24 PDT Date: Sat, 27 Jul 2002 16:57:24 -0700 (PDT) From: Hasan Gobjuka To: rpsec@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1143810048-1027814244=:79601" Subject: [RPSEC] IBGP seesions between clients in BGP cluster Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org --0-1143810048-1027814244=:79601 Content-Type: text/plain; charset=us-ascii Hello all, I'm trying to understand the forwarding loop (or Persistent Loops) problem between clusters in ASes; the problem that has been expalined in section 4 at http://members.tripod.com/~rohit_dube/papers/draft-dube-route-reflection-harmful-00.txt . My question is: is it acceptable to configure an IBGP session between two clients in the same cluster? Thanks alot, Hassan --------------------------------- Do You Yahoo!? Yahoo! Health - Feel better, live better --0-1143810048-1027814244=:79601 Content-Type: text/html; charset=us-ascii

Hello all,

 

 

I'm trying to understand the forwarding loop (or Persistent Loops) problem between clusters in ASes; the problem that has been expalined in section 4 at http://members.tripod.com/~rohit_dube/papers/draft-dube-route-reflection-harmful-00.txt .

 

My question is: is it acceptable to configure an IBGP session between two clients in the same cluster?

 

 

Thanks alot,

Hassan


Do You Yahoo!?
Yahoo! Health - Feel better, live better --0-1143810048-1027814244=:79601-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 21:09:39 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09665 for ; Sat, 27 Jul 2002 21:09:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA00670 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 21:10:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00552; Sat, 27 Jul 2002 21:03:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA00518 for ; Sat, 27 Jul 2002 21:03:36 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09614 for ; Sat, 27 Jul 2002 21:02:29 -0400 (EDT) Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 27 Jul 2002 18:03:02 -0700 content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046406C9CF@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status, from a protocol developer's angle. Thread-Index: AcI1MNQxVIiiH41GS8Cz65YSTFae4wAj+eLQ From: "Michel Py" To: "Alex Zinin" , "Gregory Lebovitz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id VAA00519 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit > Gregory Lebovitz wrote: > So the question is whether the router would keel over on the auth > checks, assuming (1) and > (2) were learned and done successfully. Yes. > Alex Zinin wrote: > Besides, I've heard what people do is rate limit some > stuff that goes up to the control plane to make sure the > CPU does not go crazy even if an attack is mounted :) Definitely something to do, but it has its limitations. Let's say a router with 10 gbit of aggregated bandwidth routinely processes 1 gbit of auth checks and begins to choke at 2 gbit of auth checks. You rate-limit auth checks to 2 gbit. If an attacker flows you with 3 gbit of useless packets that require an auth check, it effectively denies half of the traffic that uses auth checks, as the flow of auth checks would be 4 gbit (1 legit and 3 attacker); out of these 4, half of it would be dropped by the 2 gbit rate-limit, which includes half of the legit 1 gbit. On the side, I would say that to me it definitely is in the scope of this WG to make recommendations such as: "If you use authentication, and if your router can't handle it a line speed, you MUST rate-limit the auth traffic to what you router is able to handle." However, it might be too early for this. Back to the task at hand, let's try to transform onions into routers. The combination of the fact that auth checks are required AND that the router can't process them at line speed has created a situation that allows the attacker to take 50% of traffic off with 3 gbit of bandwidth, where it would have needed 10 gbit of bandwidth without auth checks. In this specific situation, I see three different things: - A MITM vulnerability has been identified. 1. This vulnerability {MUST NOT | MAY | MUST} be countered by some form of authentication. 2. If 1. == MUST, routers {MAY | MUST} be able to handle authentication at line speed. 3. If 2. == MAY, you MUST rate-limit the authentication traffic to the router's capabilities. One of the challenges in making these choices would be: - If MUST is chosen for 1., this tips the scale over the MUST side for 2., which likely includes hardware upgrade or replacements, and I see router vendors with a smile up to their ears. Is this group ready to make a recommendation that basically mandates authentication hardware in each router? Making these choices require a clear answer on: - Is the cure better or worse than the vulnerability? - If it is better, does the gain balance the consequences on the protocol, which include but are not limited to reduced performance and greater complexity? I will finish by the remark that nothing in this post is specific to my protocol (MHAP); I expect the issues to be the same with any protocol that has to deal with the same scalability issues I have to. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sat Jul 27 22:42:33 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11229 for ; Sat, 27 Jul 2002 22:42:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA03310 for rpsec-archive@odin.ietf.org; Sat, 27 Jul 2002 22:43:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03287; Sat, 27 Jul 2002 22:41:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA03253 for ; Sat, 27 Jul 2002 22:41:05 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11199 for ; Sat, 27 Jul 2002 22:39:59 -0400 (EDT) Received: from sandelman.ottawa.on.ca (virthost47.sandelman.ottawa.on.ca [192.139.46.47] (may be forged)) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g6S2duW21653 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sat, 27 Jul 2002 22:40:05 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g6S2ds8j015843 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 27 Jul 2002 22:39:55 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g6S2dqvW015838; Sat, 27 Jul 2002 22:39:53 -0400 Message-Id: <200207280239.g6S2dqvW015838@marajade.sandelman.ottawa.on.ca> To: "Michel Py" cc: rpsec@ietf.org Subject: Re: [RPSEC] Draft Status, from a protocol developer's angle. In-reply-to: Your message of "Sat, 27 Jul 2002 18:03:02 PDT." <2B81403386729140A3A899A8B39B046406C9CF@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 27 Jul 2002 22:39:52 -0400 From: Michael Richardson Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Michel" == Michel Py writes: Michel> Definitely something to do, but it has its limitations. Michel> Let's say a router with 10 gbit of aggregated bandwidth routinely Michel> processes 1 gbit of auth checks and begins to choke at 2 gbit of auth Michel> checks. You rate-limit auth checks to 2 gbit. Michel> If an attacker flows you with 3 gbit of useless packets that require an Michel> auth check, it effectively denies half of the traffic that uses auth Michel> checks, as the flow of auth checks would be 4 gbit (1 legit and 3 Michel> attacker); out of these 4, half of it would be dropped by the 2 gbit Michel> rate-limit, which includes half of the legit 1 gbit. Unfortunately, your analysis, while correct, is far too simple if you assume IPsec with symmetric keys. 1) you have to get SPI#+destination address correct first. 2) IPsec replay checks occur without any crypto to have occured. 3) integrity checks (HMAC-MD5) occur next, and may have more bandwidth than decryption. 4) finally, some crypto occurs. This means that for a DoS to occur, you have to have a box that can snoop on the traffic enroute, and within 64-packets (which is a typical window size for the replay counter), generate the junk that is needed to spam. Not impossible, certainly, but not doable without specialized equipment. A DDoS attack is certainly possible, but there is going to be almost as much traffic flowing from the tap point to the DDoS machines as there is going to be originating from the DDoS boxes. Can you do a DDoS without bothering to get the SPI#/destination address correct? Maybe. The question is, can a border router keep up with discarding packets which the wrong SPI#? SPI# is a 32-bit unstructured quantity. So, a bit harder to lookup than a route entry. Let's say that in a programmable part it requires twice the cycles compared to a destination address router lookup. A hash table implementation is more likely than a patricia tree implementation. (nothing to stop one from using a tree though) Hash tables are heurisically better than O(n), but typical case are only constant better. Pathological case is linear. (n=# of SPIs, meaning that it is the number of active unique sites that one is communicating with). If you have hardware assistance (not as likely), it is likely a CAM (binary CAM only required), so it will be O(1), just like the destination address lookup will be. Michel> Making these choices require a clear answer on: Michel> - Is the cure better or worse than the vulnerability? If the trust problem can be solved, then use the crypto. If the trust problem can not be solved, do not deploy, the system is too easily hijacked. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPUNZc4qHRg3pndX9AQGSoAQAwQZYxDtfX4ZPBgGS2Mklcakp5nr2ioNI GpMZ15t+yelhntrWFy3z4r4Ub3Nvny1RJ9jyGGTYM4Qf42FU+kqpNs2kDYoLZKSW n14zMk3bz4UZDUmwNYTexzl/7zbAYRob/hP5xuHTur1N3GWkQHcANmwuvafcNTly 1tgULEVOKKY= =WM7n -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sun Jul 28 10:58:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27328 for ; Sun, 28 Jul 2002 10:58:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04327 for rpsec-archive@odin.ietf.org; Sun, 28 Jul 2002 10:59:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04221; Sun, 28 Jul 2002 10:53:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04187 for ; Sun, 28 Jul 2002 10:53:26 -0400 (EDT) Received: from wolfe.bbn.com (wolfe.bbn.com [128.89.80.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27284 for ; Sun, 28 Jul 2002 10:52:06 -0400 (EDT) Received: by wolfe.bbn.com (Postfix, from userid 13538) id 8955416484; Sun, 28 Jul 2002 10:52:36 -0400 (EDT) From: Charles Lynn To: Michael Richardson Cc: rpsec@ietf.org, CLynn@bbn.com Subject: Re: [RPSEC] Draft Status, from a protocol developer's angle. In-Reply-To: <200207280239.g6S2dqvW015838@marajade.sandelman.ottawa.on.ca> Message-Id: <20020728145236.8955416484@wolfe.bbn.com> Date: Sun, 28 Jul 2002 10:52:36 -0400 (EDT) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > This means that for a DoS to occur, you have to have a box that > can snoop on the traffic enroute, and within 64-packets (which is a > typical window size for the replay counter), generate the junk that > is needed to spam. ... > A DDoS attack is certainly possible, but there is going to be > almost as much traffic flowing from the tap point to the DDoS > machines as there is going to be originating from the DDoS boxes. Wouldn't one only need to get a subset of the sampled packets? > Not impossible, certainly, but not doable without specialized equipment. The specialized hardware could time stamp the sequence number sample to allow the attacker to "guess" the right sequence number, then use the special equipment to provide feedback to refine the guess. Then, one might also have to get the TTL "right". The attack is probably a lot harder in the wired internet than in wireless nets. > Can you do a DDoS without bothering to get the SPI#/destination > address correct? Maybe. The question is, can a border router keep up > with discarding packets which the wrong SPI#? SPI# is a 32-bit > unstructured quantity. So, a bit harder to lookup than a route entry. I do not think so. The typical selectors are src/dst addresses & ports, and protocol = 104 bits, in the hardware. For IPsec, one has src/dst addresses, SPI, and ESP = 104 bits. ESP even put the SPI bits at the same packet offset as are the TCP/UPD port numbers. Thus the needed hardware is already there, except possibly for a "not" operator. Charlie _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sun Jul 28 16:23:15 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02491 for ; Sun, 28 Jul 2002 16:23:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA15971 for rpsec-archive@odin.ietf.org; Sun, 28 Jul 2002 16:24:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15849; Sun, 28 Jul 2002 16:17:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15817 for ; Sun, 28 Jul 2002 16:17:35 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02410 for ; Sun, 28 Jul 2002 16:16:29 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g6SKHGW23203 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Sun, 28 Jul 2002 16:17:22 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g6SKHEYr003190 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 28 Jul 2002 16:17:15 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g6SKH97P003185; Sun, 28 Jul 2002 16:17:12 -0400 Message-Id: <200207282017.g6SKH97P003185@marajade.sandelman.ottawa.on.ca> To: Charles Lynn cc: rpsec@ietf.org Subject: Re: [RPSEC] Draft Status, from a protocol developer's angle. In-reply-to: Your message of "Sun, 28 Jul 2002 10:52:36 EDT." <20020728145236.8955416484@wolfe.bbn.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 28 Jul 2002 16:17:08 -0400 From: Michael Richardson Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Charles" == Charles Lynn writes: >> A DDoS attack is certainly possible, but there is going to be >> almost as much traffic flowing from the tap point to the DDoS >> machines as there is going to be originating from the DDoS boxes. Charles> Wouldn't one only need to get a subset of the sampled packets? Yes, I'm saying "almost" - 1/20th is significant to me. The control load on the coordinating machine will be high. Specifically, one needs to get the SPI#s, replay counters, and valid source addresses. The DDoS clients need to make sure that they go at the same speed. That's going to take at least a control packet every 20 or 30 packets. Otherwise one will get ahead, and the window will close on the other senders, rendering their attacks easy to fend off. Charles> The attack is probably a lot harder in the wired internet than in Charles> wireless nets. >> Can you do a DDoS without bothering to get the SPI#/destination >> address correct? Maybe. The question is, can a border router keep up >> with discarding packets which the wrong SPI#? SPI# is a 32-bit >> unstructured quantity. So, a bit harder to lookup than a route entry. Charles> I do not think so. The typical selectors are src/dst addresses & ports, Charles> and protocol = 104 bits, in the hardware. For IPsec, one has src/dst Those are the selectors for entry into the tunnel/SA. We are attacking the decryption end of the tunnel, from the outside. If RFC2401bis makes the SPI# independant of all other fields for unicast senders, and many implementations already keep the SPI# space unique per machine, so why mention the other bits? Charles> addresses, SPI, and ESP = 104 bits. ESP even put the SPI bits at the Charles> same packet offset as are the TCP/UPD port numbers. Thus the needed Charles> hardware is already there, except possibly for a "not" operator. Yup. The hardware is probably already there. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPURRJ4qHRg3pndX9AQH1IgP9FY+Q+FbahRSkXflEeD9NPcNqDHZF5Wua OmkI1Vzeqf4kcQDCgrJO18cLNugF1dPGHVFO0LwNx4T9DdzBUPZtCziYyDXrsJVS rOyWiQOlu7o5Elb2jfrOG9L01HJckIXjxM+cC8O3Uklo3+u/HwC9XceH/1X7jEci jCEWub6j5X4= =iq62 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sun Jul 28 16:40:40 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02765 for ; Sun, 28 Jul 2002 16:40:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA16754 for rpsec-archive@odin.ietf.org; Sun, 28 Jul 2002 16:41:46 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16715; Sun, 28 Jul 2002 16:36:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16681 for ; Sun, 28 Jul 2002 16:36:46 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02734 for ; Sun, 28 Jul 2002 16:35:39 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Jul 2002 13:36:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405E21D@server2000.arneill-py.sacramento.ca.us> Thread-Topic: [RPSEC] Draft Status, from a protocol developer's angle. Thread-Index: AcI14EKeelo1saNySteHOOgMEU/9fgAlEAoA From: "Michel Py" To: "Michael Richardson" , "Charles Lynn" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA16682 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit Michael / Charlie >> Michel Py wrote: >> If an attacker flows you with 3 gbit of useless packets that >> require an auth check, it effectively denies half of the >> traffic that uses auth checks, as the flow of auth checks >> would be 4 gbit (1 legit and 3 attacker); out of these 4, >> half of it would be dropped by the 2 gbit rate-limit, which >> includes half of the legit 1 gbit. > Michael Richardson wrote: > Unfortunately, your analysis, while correct, is far too simple > if you assume IPsec with symmetric keys. You are the one making the assumption; I meant to stay generic and only mentioned "auth checks". Michael and Charlie, I think the discussion you are having about the crypto-DoS issue is premature, because it is too focused or too specific, see below. Michael, I agree that this problem, in order to be solved, needs to solve the trust model first. However, you are making two assumptions that I don't. 1. You assume that a suitable trust model will be found, which remains to be seen. 2. You assume that the trust model that will be found will allow the use of symmetric keys, which is even more hypothetical. In other words, it might end up that the trust model will call for public/private keys, we just don't know this yet, and I am uncomfortable being the one that brought the issue on the table because I think this level of detail about a protocol under development is not of interest for the WG as a whole. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sun Jul 28 17:35:50 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03298 for ; Sun, 28 Jul 2002 17:35:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA19280 for rpsec-archive@odin.ietf.org; Sun, 28 Jul 2002 17:36:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18728; Sun, 28 Jul 2002 17:30:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA18687 for ; Sun, 28 Jul 2002 17:30:09 -0400 (EDT) Received: from noxmail.sandelman.ottawa.on.ca (cyphermail.sandelman.ottawa.on.ca [192.139.46.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03123 for ; Sun, 28 Jul 2002 17:29:01 -0400 (EDT) Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [192.139.46.20]) by noxmail.sandelman.ottawa.on.ca (8.11.6/8.11.6) with ESMTP id g6SLU1W23309 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Sun, 28 Jul 2002 17:30:07 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g6SLTxYr003807 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Sun, 28 Jul 2002 17:30:00 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by marajade.sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian -4) with ESMTP id g6SLTwOx003802 for ; Sun, 28 Jul 2002 17:29:58 -0400 Message-Id: <200207282129.g6SLTwOx003802@marajade.sandelman.ottawa.on.ca> To: rpsec@ietf.org Subject: Re: [RPSEC] Draft Status, from a protocol developer's angle. In-reply-to: Your message of "Sun, 28 Jul 2002 13:36:13 PDT." <2B81403386729140A3A899A8B39B046405E21D@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 28 Jul 2002 17:29:58 -0400 From: Michael Richardson Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Michel" == Michel Py writes: Michel> You are the one making the assumption; I meant to stay generic and only Michel> mentioned "auth checks". Michel> Michael and Charlie, I think the discussion you are having about the Michel> crypto-DoS issue is premature, because it is too focused or too Michel> specific, see below. Michel> Michael, I agree that this problem, in order to be solved, needs to Michel> solve the trust model first. Michel> However, you are making two assumptions that I don't. Michel> 1. You assume that a suitable trust model will be found, which remains Michel> to be seen. Michel> 2. You assume that the trust model that will be found will allow the use Michel> of symmetric keys, which is even more hypothetical. Back to rpsec. Re-reading the charter. There are two kinds of threats: - transport threats "make sure it gets there okay" - content threats "make sure we aren't talking to a crazy" I believe that transport threats are well understood, and well addressed by IPsec. The biggest problem is that pre-shared secrets for authenticating IKE do not scale, yet are the only "easy" method. PK authentication is not available on most routers without the *I*, which is overkill. === I believe that we need to strongly look at authenticating who may speak for what network blocks. The threats here -- particularly due to misconfiguration rather than malice -- are very real. ] Internet Security. Have encryption, will travel |1 Fish/2 Fish [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |Red F./Blow F [ ]mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto [ ] At the far end of some dark fiber - wait that's dirt! |for everyone [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPURiVIqHRg3pndX9AQFbGQQAmf2/mzjwJFrWFDuGwwyLNAXIMxzlnkX1 yIS8uABbpj7JYYorwg910SJ8kA37y8v+XbQ6LaUcD6bshh3Scd//3m3UfhslMyAs qR7K8il+jirv8660dDTQocalaoOM+GAPcNpBEp7c9eRMoBi7E8XlD1QZC6qox0Ro 1lsoqvTkZ/o= =x7/0 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Sun Jul 28 22:34:49 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06778 for ; Sun, 28 Jul 2002 22:34:49 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA29128 for rpsec-archive@odin.ietf.org; Sun, 28 Jul 2002 22:35:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA28623; Sun, 28 Jul 2002 22:30:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA28568 for ; Sun, 28 Jul 2002 22:30:18 -0400 (EDT) Received: from wolfe.bbn.com (wolfe.bbn.com [128.89.80.22]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06446 for ; Sun, 28 Jul 2002 22:29:12 -0400 (EDT) Received: by wolfe.bbn.com (Postfix, from userid 13538) id 3971516484; Sun, 28 Jul 2002 22:29:41 -0400 (EDT) From: Charles Lynn To: Michael Richardson Cc: rpsec@ietf.org, CLynn@bbn.com Subject: Re: Re: [RPSEC] Draft Status, from a protocol developer's angle. In-Reply-To: <200207282129.g6SLTwOx003802@marajade.sandelman.ottawa.on.ca> <2B81403386729140A3A899A8B39B046405E21D@server2000.arneill-py.sacramento.ca.us> Message-Id: <20020729022941.3971516484@wolfe.bbn.com> Date: Sun, 28 Jul 2002 22:29:41 -0400 (EDT) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org > I believe that we need to strongly look at authenticating who may > speak for what network blocks. The threats here -- particularly due > to misconfiguration rather than malice -- are very real. Yes, we must do that. Charlie _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Mon Jul 29 13:46:11 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08848 for ; Mon, 29 Jul 2002 13:46:10 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA19318 for rpsec-archive@odin.ietf.org; Mon, 29 Jul 2002 13:47:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19103; Mon, 29 Jul 2002 13:39:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA19069 for ; Mon, 29 Jul 2002 13:39:14 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08708 for ; Mon, 29 Jul 2002 13:38:06 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g6THcgM2008957; Mon, 29 Jul 2002 10:38:42 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g6THcgkj014619; Mon, 29 Jul 2002 10:38:42 -0700 (PDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA16181; Mon, 29 Jul 2002 10:38:35 -0700 (PDT) Date: Mon, 29 Jul 2002 13:38:35 -0400 (EDT) From: Russ White Reply-To: Russ White To: Hasan Gobjuka cc: rpsec@ietf.org Subject: Re: [RPSEC] IBGP seesions between clients in BGP cluster In-Reply-To: <20020727235724.83171.qmail@web12906.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Probably the idr mailing list would be better. :-) Russ On Sat, 27 Jul 2002, Hasan Gobjuka wrote: > Hello all, > > I'm trying to understand the forwarding loop (or Persistent > Loops) problem between clusters in ASes; the problem that has > been expalined in section 4 at > http://members.tripod.com/~rohit_dube/papers/draft-dube-route-reflection-harmful-00.txt > . > > My question is: is it acceptable to configure an IBGP session > between two clients in the same cluster? > > > > > > Thanks alot, > > Hassan > > > > --------------------------------- > Do You Yahoo!? > Yahoo! Health - Feel better, live better __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Mon Jul 29 18:04:42 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16505 for ; Mon, 29 Jul 2002 18:04:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA03539 for rpsec-archive@odin.ietf.org; Mon, 29 Jul 2002 18:05:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03463; Mon, 29 Jul 2002 18:01:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA03429 for ; Mon, 29 Jul 2002 18:01:47 -0400 (EDT) Received: from mesa.bbnplanet.com (mesa.bbnplanet.com [199.94.208.140]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16479 for ; Mon, 29 Jul 2002 18:00:40 -0400 (EDT) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id g6TLrqm18229; Mon, 29 Jul 2002 17:53:52 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Mon, 29 Jul 2002 17:53:52 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Alex Zinin cc: Russ White , Gregory Lebovitz , "'Senthilkumar Ayyasamy'" , Subject: Re: [RPSEC] Draft Status.... In-Reply-To: <1212129971.20020726221333@psg.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org On Fri, 26 Jul 2002, Alex Zinin wrote: > Russ, > > > And I hope my example is not too absurd to blow your > > thinking cap off. > > Hey, liked the analogy a lot! :) I liked it also. > Not trying to start an analogy argument, but it seems to me > that in your example, the difference between models is in > the set of characteristics that are considered in each, and, > potentially, one could have one model, with classification > of threats based of the onion's physical characteristics, > chemical substances, internal structure, etc. etc. One thing that occurred to me a little while ago is that there's the system-level memory threats which can be realized by expanding an attribute that's not (I think) of contstrained length like communities or AS path in BGP or by de-aggregating explosively and causing memory exhaustion as a result. Limiting the length of all the attributes could help such a vulnerability, but the scaling for raw number of routes and balancing that with other demands in your embedded system seems sorta outside the scope of a protocol spec. I should say that I don't have experience actually coding any of these protocols so I'm not sure how big a problem these things might be. > Anyways, we should probably really stop it here and wait > till we see the other doc :) Which other model? I wasn't in Yokahama. Is this reference related to the meeting? (I might be dense - just back from vacation and catching up on 1500 emails.) Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 30 02:43:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06532 for ; Tue, 30 Jul 2002 02:43:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA02620 for rpsec-archive@odin.ietf.org; Tue, 30 Jul 2002 02:44:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02230; Tue, 30 Jul 2002 02:36:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02198 for ; Tue, 30 Jul 2002 02:36:45 -0400 (EDT) Received: from psg.com (smmsp@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06362 for ; Tue, 30 Jul 2002 02:35:38 -0400 (EDT) Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 17ZQa6-000E4F-00; Mon, 29 Jul 2002 23:34:06 -0700 Date: Mon, 29 Jul 2002 23:32:33 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.51) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <96276069707.20020729233233@psg.com> To: Tony Tauber CC: Russ White , Gregory Lebovitz , "'Senthilkumar Ayyasamy'" , Subject: Re: [RPSEC] Draft Status.... In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 7bit Tony, > One thing that occurred to me a little while ago is that there's the > system-level memory threats which can be realized by expanding an > attribute that's not (I think) of contstrained length like communities > or AS path in BGP or by de-aggregating explosively and causing memory > exhaustion as a result. > Limiting the length of all the attributes could help such a > vulnerability, but the scaling for raw number of routes and balancing > that with other demands in your embedded system seems sorta outside > the scope of a protocol spec. > I should say that I don't have experience actually coding any of these > protocols so I'm not sure how big a problem these things might be. Hmmm... On the one hand, this falls into the "robustness" category (how many neighbors and routes can an implementation support, etc.), on the other hand all implementations will have finite amount of resources and such an attack can be mounted by compromising a trusted router or by using some protocol vulnerabilities. Essentially, what we're seeing here is a very generic dilemma (improvising): 1) I have to maintain state created/requested by "others" in order ensure correct operation of the protocol (example: I have to have all LSPs from all routers in an area to properly calc the SPT and route correctly), assuming that everyone in the distributed system is cooperating But: 2) Some "other" may not be cooperating (compromised) and inject too much state or there may be too many "others", so I just can't keep up. Going back to my favorite list of subsystems :), this is the type of threats specific to the DB maintenance subsystem, i.e., a router may pass the transport-level authentication checks perfectly well, but may still be dangerous. So, yes, this is a threat. As far as addressing it--we're yet to get to that point--the threat analysis is the first step. >> Anyways, we should probably really stop it here and wait >> till we see the other doc :) > Which other model? I wasn't in Yokahama. Is this reference related > to the meeting? (I might be dense - just back from vacation and > catching up on 1500 emails.) In the first message in this thread Russ mentioned he knows at least one other draft that might provide a different view at the threat model. Alex _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 30 13:01:21 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28878 for ; Tue, 30 Jul 2002 13:01:20 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA10611 for rpsec-archive@odin.ietf.org; Tue, 30 Jul 2002 13:02:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09889; Tue, 30 Jul 2002 12:59:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09861 for ; Tue, 30 Jul 2002 12:59:41 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28700 for ; Tue, 30 Jul 2002 12:58:33 -0400 (EDT) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id MAA19496; Tue, 30 Jul 2002 12:58:58 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma019448; Tue, 30 Jul 02 16:58:39 GMT Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g6UGx9R27146; Tue, 30 Jul 2002 12:59:09 -0400 (EDT) Date: Tue, 30 Jul 2002 12:59:09 -0400 (EDT) Message-Id: <200207301659.g6UGx9R27146@raven.gw.tislabs.com> To: rpsec@ietf.org Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. Cc: sandy@tislabs.com Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org One thing I'm unclear of is whether you are talking about authentication of the routing protocol packets or authentication of the data traffic. >The combination of the fact that auth checks are required AND that the >router can't process them at line speed has created a situation that >allows the attacker to take 50% of traffic off with 3 gbit of bandwidth, >where it would have needed 10 gbit of bandwidth without auth checks. First: wowzers! Do router routinely have to handle gbit of routing packets? (Hence my wondering if you're talking about data traffic or routing protocol traffic.) I don't know the answer here. A quick check of the potaroo site says that the FIB can be 100K-ish and the RIB 300K-ish. But those are entries, not bytes. Second: if the attacker can overwhelm your router with 3gbit of authenticated routing protocol traffic and it takes him/her/it 10gbit of unauthenticated routing protocol traffic but with .5M of unauthenticated routing protocol traffic he/she/it can make your router do goofy and harmful things to routing everywhere in the Internet - do you win by making the routing protocols unauthenticated? >Making these choices require a clear answer on: >- Is the cure better or worse than the vulnerability? Depends on whether you are worried about your router being overwhelmed or your Internet being overwhelmed. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 30 13:48:19 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01788 for ; Tue, 30 Jul 2002 13:48:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA13898 for rpsec-archive@odin.ietf.org; Tue, 30 Jul 2002 13:49:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13508; Tue, 30 Jul 2002 13:43:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13475 for ; Tue, 30 Jul 2002 13:43:07 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01584 for ; Tue, 30 Jul 2002 13:41:58 -0400 (EDT) Subject: RE: [RPSEC] Draft Status.... MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 30 Jul 2002 10:42:35 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E223@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [RPSEC] Draft Status.... Thread-Index: AcI3lQ3HjERDopNCRgyW8iOzDQ/aygAR2CMA From: "Michel Py" To: "Alex Zinin" , "Tony Tauber" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA13476 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit Tony, > Tony Tauber wrote: > Limiting the length of all the attributes could help > such a vulnerability, but the scaling for raw number of > routes and balancing that with other demands in your > embedded system seems sorta outside the scope of a > protocol spec. I do not think so. The lowest figure that I have for IPv6 multihoming is one Billion routes (below is considered not enough to work on it). As of today, nobody has the slightest clue about how BGP would behave with a billion prefixes (if CPU/memory/bandwidth were not issues, that is). So, although I agree that between 100,000 routes and 200,000 routes (and possibly up to a million) there is not much difference, when talking about 1 billion routes there is one. I am not saying that we will not see a routing protocol with a billion routes, but the protocol I am working on has a completely different mechanism of transmitting routes, and is a distributed system precisely to avoid having a billion entries routing table. How does this relate to rpsec: In my protocol, I managed to keep the size of the routing table no more than 64k routes. It is obvious that a router designed to handle 64k routes will not handle a billion routes. Therefore, if some form of attack manages to fill that router with a billion prefixes, it will collapse. So I'm not misunderstood: I'm not calling for rpsec to address this, just trying to make the point that the raw number of routes does matter. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 30 14:02:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02263 for ; Tue, 30 Jul 2002 14:02:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA15280 for rpsec-archive@odin.ietf.org; Tue, 30 Jul 2002 14:03:53 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14264; Tue, 30 Jul 2002 13:53:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA14232 for ; Tue, 30 Jul 2002 13:53:30 -0400 (EDT) Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01949 for ; Tue, 30 Jul 2002 13:52:22 -0400 (EDT) Received: from ruwhite-u10.cisco.com (ruwhite-u10.cisco.com [64.102.48.251]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA15355; Tue, 30 Jul 2002 13:52:07 -0400 (EDT) Date: Tue, 30 Jul 2002 13:52:07 -0400 (EDT) From: Russ White Reply-To: Russ White To: Michel Py cc: Alex Zinin , Tony Tauber , rpsec@ietf.org Subject: RE: [RPSEC] Draft Status.... In-Reply-To: <2B81403386729140A3A899A8B39B046405E223@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Let's say this: I'm not quite certain where you come up with 1 billion (could you articulate it?), but I do agree that larger numbers are in the coming in the future, and we have no idea how the current routing protocols will react to them. The ipv6 folks tell me that the routing table sizes should not change that radically, because we will be summarizing in a radical way. I always ponder that there are 4.2 billion addresses in a /32, which is what I understand the registries are currently handing out, and I'm hoping that summarization truly is radical. :-) Russ On Tue, 30 Jul 2002, Michel Py wrote: > Tony, > > > Tony Tauber wrote: > > Limiting the length of all the attributes could help > > such a vulnerability, but the scaling for raw number of > > routes and balancing that with other demands in your > > embedded system seems sorta outside the scope of a > > protocol spec. > > I do not think so. The lowest figure that I have for IPv6 multihoming is > one Billion routes (below is considered not enough to work on it). > > As of today, nobody has the slightest clue about how BGP would behave > with a billion prefixes (if CPU/memory/bandwidth were not issues, that > is). > > So, although I agree that between 100,000 routes and 200,000 routes (and > possibly up to a million) there is not much difference, when talking > about 1 billion routes there is one. > > I am not saying that we will not see a routing protocol with a billion > routes, but the protocol I am working on has a completely different > mechanism of transmitting routes, and is a distributed system precisely > to avoid having a billion entries routing table. > > > How does this relate to rpsec: > In my protocol, I managed to keep the size of the routing table no more > than 64k routes. It is obvious that a router designed to handle 64k > routes will not handle a billion routes. Therefore, if some form of > attack manages to fill that router with a billion prefixes, it will > collapse. > > So I'm not misunderstood: I'm not calling for rpsec to address this, > just trying to make the point that the raw number of routes does matter. > > Michel. > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 30 14:37:41 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03894 for ; Tue, 30 Jul 2002 14:37:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA17718 for rpsec-archive@odin.ietf.org; Tue, 30 Jul 2002 14:38:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17294; Tue, 30 Jul 2002 14:32:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA17254 for ; Tue, 30 Jul 2002 14:32:39 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03648 for ; Tue, 30 Jul 2002 14:31:31 -0400 (EDT) Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 30 Jul 2002 11:32:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B046405E224@server2000.arneill-py.sacramento.ca.us> content-class: urn:content-classes:message Thread-Topic: [RPSEC] Draft Status, from a protocol developer's angle. Thread-Index: AcI37A4gjVoe2JJITB+7yhNwvo6VDAABH/Dg From: "Michel Py" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA17255 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit Sandy, > Sandy wrote: > One thing I'm unclear of is whether you are talking about > authentication of the routing protocol packets or > authentication of the data traffic. Authentication of the routing protocol packets. >> The combination of the fact that auth checks are required >> AND that the router can't process them at line speed has >> created a situation that allows the attacker to take 50% >> of traffic off with 3 gbit of bandwidth, where it would have >> needed 10 gbit of bandwidth without auth checks. > First: wowzers! Do router routinely have to handle gbit > of routing packets? (Hence my wondering if you're talking > about data traffic or routing protocol traffic.) I see your point. Back in the original context of this issue: we are talking about a Billion or more prefixes here. I will address this size matter replying to a post from Russ I just saw. > Second: if the attacker can overwhelm your router with 3gbit > of authenticated routing protocol traffic and it takes > him/her/it 10gbit of unauthenticated routing protocol traffic > but with .5M of unauthenticated routing protocol traffic > he/she/it can make your router do goofy and harmful things to > routing everywhere in the Internet - do you win by making the > routing protocols unauthenticated? Sometimes you do, and sometimes you don't. It depends on who the attacker is. If the attacker is a script kiddie with no more than some IRC bots, you actually win by making the routing protocol unauthenticated. Since the script kiddie can't sniff the cookie in the protocol, he/she can't make your router do goofy things with small bandwidth and must go for the full bandwidth attack. And yes, if the attacker can sniff your traffic in the middle of telco cloud, you are screwed without authentication. It all comes to the assessment of the threat: the world-class hacker that happens to have an OC-192 sniffer is more dangerous, but there are not too many of them. The script kiddie is less dangerous, but there are lots of them. Nothing's either completely black or completely white. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 30 15:32:52 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06067 for ; Tue, 30 Jul 2002 15:32:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA20840 for rpsec-archive@odin.ietf.org; Tue, 30 Jul 2002 15:34:00 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20060; Tue, 30 Jul 2002 15:22:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA20027 for ; Tue, 30 Jul 2002 15:22:29 -0400 (EDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05702 for ; Tue, 30 Jul 2002 15:21:20 -0400 (EDT) From: sandy@tislabs.com Received: by sentry.gw.tislabs.com; id PAA25937; Tue, 30 Jul 2002 15:21:57 -0400 (EDT) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma025877; Tue, 30 Jul 02 19:21:00 GMT Received: (from sandy@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g6UJLVZ10344; Tue, 30 Jul 2002 15:21:31 -0400 (EDT) Date: Tue, 30 Jul 2002 15:21:31 -0400 (EDT) Message-Id: <200207301921.g6UJLVZ10344@raven.gw.tislabs.com> To: michel@arneill-py.sacramento.ca.us, rpsec@ietf.org, sandy@tislabs.com Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. Cc: sandy@tislabs.com Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org >Since the script kiddie can't sniff the cookie in the >protocol, he/she can't make your router do goofy things with small >bandwidth and must go for the full bandwidth attack. Hm. So do we just need to make sure IPSEC has a cookie? I know it has replay protection, but I don't know if that is nonce or timestamp or big sequence number. (Charlie Lynn or someone else at BBN :-) probably knows IPSEC down to its socks and can answer the question with alacrity.) I know that ISAKMP/IKE at one point had cookies to prevent clogging attacks you're talking about. I don't think that BGP/OSPF/RIP, etc. in their MD5 protections have cookies, much less full replay protection. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 30 15:52:53 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06729 for ; Tue, 30 Jul 2002 15:52:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA21971 for rpsec-archive@odin.ietf.org; Tue, 30 Jul 2002 15:54:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21674; Tue, 30 Jul 2002 15:47:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA21636 for ; Tue, 30 Jul 2002 15:47:00 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06530 for ; Tue, 30 Jul 2002 15:45:50 -0400 (EDT) Subject: RE: [RPSEC] Draft Status.... MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 30 Jul 2002 12:46:26 -0700 Message-ID: <2B81403386729140A3A899A8B39B046405E226@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [RPSEC] Draft Status.... Thread-Index: AcI38glZGUgmSFhpRXOYJaAQKnsDaQABXYWA From: "Michel Py" To: "Russ White" Cc: "Alex Zinin" , "Tony Tauber" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA21637 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit Russ, > Russ White wrote: > Let's say this: I'm not quite certain where you come up > with 1 billion (could you articulate it?), It's the consensual number for the ipv6mh design target. More specifically, the consensus is that 1 Billion independent multihomed /48 prefixes are the smallest number that has not been challenged as being too small. Trying to stay brief, MHAP deals with two kinds of prefixes: (Prefixes are /48s for end-sites) - Centralized. - Geographically aggregatable. We were actually able to fit 2.5 billion geo prefixes (instead of the 1 billion target) in a /16 because of a higher than expected HD ratio, which takes us roughly to the point where every 4-person household has their /48 prefix. Interestingly, I also put a cap of 1 million centralized prefixes (which are targeted to large, multinational, multihomed organizations) and I was told that it was not enough by many people. Given the fact that they are ~15k multihomers today, I hope that gives you an idea of what kind of magnitude changes we have to deal with when designing IPv6 routing protocols. > but I do agree that larger numbers are in the coming in the > future, and we have no idea how the current routing protocols > will react to them. There is a more generic issue: even if you can manufacture a router that has enough CPU and memory to handle a billion routes, do we want to go that way? What a pain in the kazoo it would be to maintain / troubleshoot with BGP as we know it today. > The ipv6 folks tell me that the routing table sizes should > not change that radically, because we will be summarizing > in a radical way. It depends on which ipv6 folks you are talking to. There are a number of people that think that we can follow Moore's law and keep building more powerful hardware. > I always ponder that there are 4.2 billion addresses in a > /32, which is what I understand the registries are currently > handing out, and I'm hoping that summarization truly is radical. Note that I don't drill down that deep. To me, a /32 is 64K /48 prefixes, not 4B /64 subnets. The 2.5 billion (which is 4 billion less overhead) I am dealing with are 4 billion of /48s. The SLA bits (bits 48 to 63, which are the subnets specific to each site) are negotiated between sites only and not on the global routing table. That would be 256 trillion prefixes, too much. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From daemon@optimus.ietf.org Tue Jul 30 22:08:01 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16450 for ; Tue, 30 Jul 2002 22:08:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA12549 for rpsec-archive@odin.ietf.org; Tue, 30 Jul 2002 22:09:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12317; Tue, 30 Jul 2002 22:04:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12283 for ; Tue, 30 Jul 2002 22:04:08 -0400 (EDT) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16383 for ; Tue, 30 Jul 2002 22:02:59 -0400 (EDT) Subject: RE: [RPSEC] Draft Status, from a protocol developer's angle. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 30 Jul 2002 19:03:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <2B81403386729140A3A899A8B39B046405E228@server2000.arneill-py.sacramento.ca.us> content-class: urn:content-classes:message Thread-Topic: [RPSEC] Draft Status, from a protocol developer's angle. Thread-Index: AcI3/qcl1G02lrlqStCKlY6pLRb6TwAA1DBA From: "Michel Py" To: , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA12284 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Routing Protocol Security Requirements X-BeenThere: rpsec@ietf.org Content-Transfer-Encoding: 8bit > Since the script kiddie can't sniff the cookie in the > protocol, he/she can't make your router do goofy things > with small bandwidth and must go for the full bandwidth > attack. > sandy wrote: > Hm. So do we just need to make sure IPSEC has a cookie? I included an unencrypted 64-bit cookie in MHAP (it's a random number). Although it was not the original purpose, we have discovered discussing security that checking that unencrypted cookie _before_ performing auth checks greatly reduced the risks of crypto-DoS, as the attacker has to sniff the cookie prior to any attack involving the router performing crypto checks. Michel. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec