From root@core3.amsl.com Tue Jun 1 13:00:03 2010 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6EB133A67FB; Tue, 1 Jun 2010 13:00:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100601200003.6EB133A67FB@core3.amsl.com> Date: Tue, 1 Jun 2010 13:00:03 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D ACTION:draft-ietf-opsec-routing-protocols-crypto-issues-05.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2010 20:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Issues with existing Cryptographic Protection Methods for Routing Protocols Author(s) : J. Jaeggli, S. Hares, M. Bhatia, V. Manral, R. White Filename : draft-ietf-opsec-routing-protocols-crypto-issues-05.txt Pages : 18 Date : 2010-6-1 Routing protocols have over time been extended to use cryptographic mechanisms to validate data being received from a neighboring router to ensure that: o It has not been modified in transit. o Actually originated from an authorized neighboring router. The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet. This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-routing-protocols-crypto-issues-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsec-routing-protocols-crypto-issues-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-6-1125729.I-D@ietf.org> --NextPart-- From Anuja.Sonalker@cobham.com Mon Jun 7 10:19:59 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22153A6DD3 for ; Mon, 7 Jun 2010 10:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_60=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVOvTyXFL3Ya for ; Mon, 7 Jun 2010 10:19:51 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 1FF2A28C1E0 for ; Mon, 7 Jun 2010 08:44:08 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o57Fi8Zx001928 for ; Mon, 7 Jun 2010 10:44:08 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o57Fi8LB005659 for ; Mon, 7 Jun 2010 10:44:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB0658.43D93600" Date: Mon, 7 Jun 2010 11:44:07 -0400 Message-ID: <5ABE30CE099A524CBF95C715D37BCACC03388479@nemo.columbia.ads.sparta.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments/disussion points on draft-ietf-opsec-routing-protocols-crypto-issues-05 Thread-Index: AcsGWEOTnA4IMXOIQ5+JrOcLe/mPjA== From: "Sonalker, Anuja" To: Subject: [OPSEC] Some comments/disussion points on draft-ietf-opsec-routing-protocols-crypto-issues-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 17:19:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0658.43D93600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, =20 First of all, I would like to say what a great initiative this has been to document all cryptographic security issues with routing protocols. This document can become a great source of information for implementers, operators, researchers, engineers, device manufacturers, and others alike. In the interest of making this document finer, I had a few suggestions for the authors to review. Hopefully, they will be of benefit to you. =20 Thanks, Anuja =20 Few comments on the opsec-routing-protocols-crypto-issues-05 IETF draft=20 1) Confidentiality as an issue in the Problem Statement=20 The document aptly notes that digest verification mechanisms are not intended to provide confidentiality, and that one router's routing table information could possibly be exposed to other routers in many different ways. Since confidentiality is not a critical issue for all routing protocols in general, it would be beneficial to highlight and acknowledge the same. For example, while confidentiality is of critical interest to inter autonomous system protocols like BGP, or ones where business relationships may be under threat of exposure, it is of not as much (critical) concern to IGPs like OSPF.=20 2) OSPFv2 Management issues section possible clashing ideas. The first two paragraphs indicate that OSPF uses MD5 and that there neither exists a mechanism to negotiate keys, nor to negotiate the hash algorithms to be used. However, the paragraph immediately following it talks about the proliferation of a number of hash algorithms, as well as the need to continuously upgrade the algorithms with the problems this would face in OSPF. This statement seems more applicable to RFC5709 rather than the OSPF base algorithm itself and should probably accompany a much later paragraph [Section 2.2, Paragraph 5]. A similar issue exists for IS-IS. Both these sections would benefit from a reference to karp, another IETF initiative that deals with solutions for cryptographic authentication and key management for routing protocols. Referencing and acknowledging other active work that is trying to mitigate routing security cryptographic issues would complement this section very well, and provide readers and implementers a more complete picture of the problem and what it would take to solve it.=20 3) DoS attacks as crypto issues, and applicability. While the presence and or use of cryptographic functions at the victim end does allow the attacker to have a greater impact on the victim with lesser effort, DoS attacks can, in reality, be launched on any network even in the absence of cryptographic functions. (e.g., tcp syn flooding, etc). Therefore, in a way, cryptographic performance demands can facilitate DoS attacks. This is noteworthy. However, careful implementation choices lessen the impact of cryptographic performance demands on the recipient end, thereby resulting in wasted effort at the attacker end, making the DoS attack less lucrative to launch. This should probably be indicated. Secondly, this attack is discussed selectively only under a few routing protocols in the document when it is clearly applicable to almost all. =20 4) BGP v4 Management issues. "Most BGP implementations will accept BGP packets with a bad digest up to the hold interval negotiated between BGP peers at peering startup." The authors have highlighted an issue that is specific to certain implementations. Since this is an implementation detail, the motivation behind this choice should be noted in order for the readers to fully understand the compelling reasons behind making such a choice. Secondly, if implementation specific issues are to be considered within scope of this document then, for consistency, the same should be considered of all known and currently in use implementations of all routing protocols that fall within the scope of this initiative. This would result in a long and drawn out process of accumulating such information. Thirdly, as implementations get updated these issues would cease to be relevant issues. Finally, since the karp initiative deals with these kinds of problems it would be very informative to mention the initiative here.=20 5) RIPv2 replay same seq# attack. Since a repeated sequence number is detected as a replay, and discarded, what impact does this attack have on the recipient? What damage results from this attack to the routing? 6) The current abstract only talks about certain cryptographic digests that have been made obsolete due to recent findings while the document deals with other relevant issues as well. Therefore, the abstract should be updated to indicate the full content of document. =20 7) The authors should include, wherever relevant, references to other initiatives like karp that have intersections with the content that the opsec-crypto-issues draft addresses. This will facilitate better interactions across various working groups, and provide implementers, and operators a greater awareness and a more complete picture of routing security and cryptography issues.=20 ------_=_NextPart_001_01CB0658.43D93600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors,

 

First of all, I would like to say what a great = initiative this has been to document all cryptographic security issues with routing protocols. This document can become a great source of information for = implementers, operators, researchers, engineers, device manufacturers, and others = alike. In the interest of making this document finer, I had a few suggestions for = the authors to review. Hopefully, they will be of benefit to = you.

 

Thanks,

Anuja

 

Few comments on the = opsec-routing-protocols-crypto-issues-05 IETF draft

1)      Confidentiality as an issue in the Problem = Statement

The document aptly notes that digest verification mechanisms are not = intended to provide confidentiality, and that one router’s routing table = information could possibly be exposed to other routers in many different ways. Since confidentiality is not a critical issue for all routing protocols in = general, it would be beneficial to highlight and acknowledge the same. For = example, while confidentiality is of critical interest to inter autonomous system protocols like BGP, or ones where business relationships may be under = threat of exposure, it is of not as much (critical) concern to IGPs like OSPF. =

2)      OSPFv2  Management issues section possible clashing ideas. The first two paragraphs indicate that OSPF uses MD5 and = that there neither exists a mechanism to negotiate keys, nor to negotiate the = hash algorithms to be used. However, the paragraph immediately following it = talks about the proliferation of a number of hash algorithms, as well as the = need to continuously upgrade the algorithms with the problems this would face in = OSPF. This statement seems more applicable to RFC5709 rather than the OSPF = base algorithm itself and should probably accompany a much later paragraph = [Section 2.2, Paragraph 5].  A similar issue exists for IS-IS. Both these = sections would benefit from a reference to karp, another IETF initiative that = deals with solutions for cryptographic authentication and key management for = routing protocols. Referencing and acknowledging other active work that is = trying to mitigate routing security cryptographic issues would complement this = section very well, and provide readers and implementers a more complete picture = of the problem and what it would take to solve it.

3)      DoS attacks as crypto issues, and applicability. = While the presence and or use of cryptographic functions at the victim end = does allow the attacker to have a greater impact on the victim with lesser effort, = DoS attacks can, in reality, be launched on any network even in the absence = of cryptographic functions. (e.g., tcp syn flooding, etc). Therefore, in a way, = cryptographic performance demands can facilitate DoS attacks. This is noteworthy. = However, careful implementation choices lessen the impact of cryptographic = performance demands on the recipient end, thereby resulting in wasted effort at the attacker end, making the DoS attack less lucrative to launch. This = should probably be indicated.  Secondly, this attack is discussed = selectively only under a few routing protocols in the document when it is clearly applicable to almost all. 

4)      BGP v4 Management issues. “Most BGP implementations will accept BGP packets with a bad digest up to the hold interval negotiated between BGP peers at peering startup.” The = authors have highlighted an issue that is specific to certain implementations. = Since this is an implementation detail, the motivation behind this choice = should be noted in order for the readers to fully understand the compelling = reasons behind making such a choice. Secondly, if implementation specific issues = are to be considered within scope of this document then, for consistency, the = same should be considered of all known and currently in use implementations = of all routing protocols that fall within the scope of this initiative. This = would result in a long and drawn out process of accumulating such information. Thirdly, as implementations get updated these issues would cease to be = relevant issues. Finally, since the karp initiative deals with these kinds of = problems it would be very informative to mention the initiative here. =

5)      RIPv2 replay same seq# attack. Since a repeated sequence number is detected as a replay, and discarded, what impact does = this attack have on the recipient? What damage results from this attack to = the routing?

6)      The current abstract only talks about certain cryptographic digests that have been made obsolete due to recent = findings while the document deals with other relevant issues as well. Therefore, the = abstract should be updated to indicate the full content of document.  =

7)      The authors should include, wherever relevant, references to other initiatives like karp that have intersections with = the content that the opsec-crypto-issues draft addresses. This will = facilitate better interactions across various working groups, and provide = implementers, and operators a greater awareness and a more complete picture of routing security and cryptography issues.

------_=_NextPart_001_01CB0658.43D93600-- From manav.bhatia@alcatel-lucent.com Mon Jun 7 16:39:44 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A054E3A68A4 for ; Mon, 7 Jun 2010 16:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0zVa5TVSReR for ; Mon, 7 Jun 2010 16:39:35 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id D4F143A68AF for ; Mon, 7 Jun 2010 16:39:34 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o57NaSFI008188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Jun 2010 18:36:30 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o57NaQQi031895 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Jun 2010 05:06:27 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Tue, 8 Jun 2010 05:06:26 +0530 From: "Bhatia, Manav (Manav)" To: "Sonalker, Anuja" , "opsec@ietf.org" Date: Tue, 8 Jun 2010 05:06:24 +0530 Thread-Topic: [OPSEC] Some comments/disussion points on draft-ietf-opsec-routing-protocols-crypto-issues-05 Thread-Index: AcsGWEOTnA4IMXOIQ5+JrOcLe/mPjAAQK+4A Message-ID: <7C362EEF9C7896468B36C9B79200D8350CCF8FB5B2@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <5ABE30CE099A524CBF95C715D37BCACC03388479@nemo.columbia.ads.sparta.com> In-Reply-To: <5ABE30CE099A524CBF95C715D37BCACC03388479@nemo.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7C362EEF9C7896468B36C9B79200D8350CCF8FB5B2INBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Subject: Re: [OPSEC] Some comments/disussion points on draft-ietf-opsec-routing-protocols-crypto-issues-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2010 23:39:44 -0000 --_000_7C362EEF9C7896468B36C9B79200D8350CCF8FB5B2INBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Anuja, Thanks for the comments. We will definitely consider them when updating the= document. Regarding your point (5) about RIPv2 . The doc clearly states that the attack is only possible *if* somebody is ab= le to capture a higher cryptographic sequence number (possibly before the s= eq number space rolled over or router rebooted, etc) packet from the source= . That packet can be replayed to disrupt routing as explained in the docume= nt. More inline .. ________________________________ From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of S= onalker, Anuja Sent: Monday, June 07, 2010 9.14 PM To: opsec@ietf.org Subject: [OPSEC] Some comments/disussion points on draft-ietf-opsec-routing= -protocols-crypto-issues-05 Dear Authors, First of all, I would like to say what a great initiative this has been to = document all cryptographic security issues with routing protocols. This doc= ument can become a great source of information for implementers, operators,= researchers, engineers, device manufacturers, and others alike. In the int= erest of making this document finer, I had a few suggestions for the author= s to review. Hopefully, they will be of benefit to you. Thanks, Anuja Few comments on the opsec-routing-protocols-crypto-issues-05 IETF draft 1) Confidentiality as an issue in the Problem Statement The document aptly notes that digest verification mechanisms are not intend= ed to provide confidentiality, and that one router's routing table informat= ion could possibly be exposed to other routers in many different ways. Sinc= e confidentiality is not a critical issue for all routing protocols in gene= ral, it would be beneficial to highlight and acknowledge the same. For exam= ple, while confidentiality is of critical interest to inter autonomous syst= em protocols like BGP, or ones where business relationships may be under th= reat of exposure, it is of not as much (critical) concern to IGPs like OSPF= . 2) OSPFv2 Management issues section possible clashing ideas. The firs= t two paragraphs indicate that OSPF uses MD5 and that there neither exists = a mechanism to negotiate keys, nor to negotiate the hash algorithms to be u= sed. However, the paragraph immediately following it talks about the prolif= eration of a number of hash algorithms, as well as the need to continuously= upgrade the algorithms with the problems this would face in OSPF. This sta= tement seems more applicable to RFC5709 rather than the OSPF base algorithm= itself and should probably accompany a much later I am not sure i understand this. Why is this more applicable for 57= 09? Cheers, Manav paragraph [Section 2.2, Paragraph 5]. A similar issue exists for IS-IS. B= oth these sections would benefit from a reference to karp, another IETF ini= tiative that deals with solutions for cryptographic authentication and key = management for routing protocols. Referencing and acknowledging other activ= e work that is trying to mitigate routing security cryptographic issues wou= ld complement this section very well, and provide readers and implementers = a more complete picture of the problem and what it would take to solve it. 3) DoS attacks as crypto issues, and applicability. While the presence= and or use of cryptographic functions at the victim end does allow the att= acker to have a greater impact on the victim with lesser effort, DoS attack= s can, in reality, be launched on any network even in the absence of crypto= graphic functions. (e.g., tcp syn flooding, etc). Therefore, in a way, cryp= tographic performance demands can facilitate DoS attacks. This is noteworth= y. However, careful implementation choices lessen the impact of cryptograph= ic performance demands on the recipient end, thereby resulting in wasted ef= fort at the attacker end, making the DoS attack less lucrative to launch. T= his should probably be indicated. Secondly, this attack is discussed selec= tively only under a few routing protocols in the document when it is clearl= y applicable to almost all. 4) BGP v4 Management issues. "Most BGP implementations will accept BGP= packets with a bad digest up to the hold interval negotiated between BGP p= eers at peering startup." The authors have highlighted an issue that is spe= cific to certain implementations. Since this is an implementation detail, t= he motivation behind this choice should be noted in order for the readers t= o fully understand the compelling reasons behind making such a choice. Seco= ndly, if implementation specific issues are to be considered within scope o= f this document then, for consistency, the same should be considered of all= known and currently in use implementations of all routing protocols that f= all within the scope of this initiative. This would result in a long and dr= awn out process of accumulating such information. Thirdly, as implementatio= ns get updated these issues would cease to be relevant issues. Finally, sin= ce the karp initiative deals with these kinds of problems it would be very = informative to mention the initiative here. 5) RIPv2 replay same seq# attack. Since a repeated sequence number is = detected as a replay, and discarded, what impact does this attack have on t= he recipient? What damage results from this attack to the routing? 6) The current abstract only talks about certain cryptographic digests= that have been made obsolete due to recent findings while the document dea= ls with other relevant issues as well. Therefore, the abstract should be up= dated to indicate the full content of document. 7) The authors should include, wherever relevant, references to other = initiatives like karp that have intersections with the content that the ops= ec-crypto-issues draft addresses. This will facilitate better interactions = across various working groups, and provide implementers, and operators a gr= eater awareness and a more complete picture of routing security and cryptog= raphy issues. --_000_7C362EEF9C7896468B36C9B79200D8350CCF8FB5B2INBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Anuja,
 
Thanks for the comments. We will definitely cons= ider=20 them when updating the document.
 
Regarding your point (5) about RIPv2=20 .
 
The doc clearly states that the attack is only p= ossible=20 *if* somebody is able to capture a higher cryptographic sequence number=20 (possibly before the seq number space rolled over or router rebooted, etc)= =20 packet from the source. That packet can be replayed to disrupt routing as=20 explained in the document.
 
More inline ..
 
From: opsec-bounces@ietf.org=20 [mailto:opsec-bounces@ietf.org] On Behalf Of Sonalker,=20 Anuja
Sent: Monday, June 07, 2010 9.14 PM
To:=20 opsec@ietf.org
Subject: [OPSEC] Some comments/disussion points on= =20 draft-ietf-opsec-routing-protocols-crypto-issues-05

Dear Authors,

 

First of all, I would like to say what a great initi= ative=20 this has been to document all cryptographic security issues with routing= =20 protocols. This document can become a great source of information for=20 implementers, operators, researchers, engineers, device manufacturers, an= d=20 others alike. In the interest of making this document finer, I had a few= =20 suggestions for the authors to review. Hopefully, they will be of benefit= to=20 you.

 

Thanks,

Anuja

 

Few comments on the=20 opsec-routing-protocols-crypto-issues-05 IETF draft

1)     =20 Confidentiality as an issue in the Problem Statem= ent=20

The document aptly not= es that=20 digest verification mechanisms are not intended to provide confidentialit= y,=20 and that one router’s routing table information could possibly be e= xposed to=20 other routers in many different ways. Since confidentiality is not a crit= ical=20 issue for all routing protocols in general, it would be beneficial to=20 highlight and acknowledge the same. For example, while confidentiality is= of=20 critical interest to inter autonomous system protocols like BGP, or ones = where=20 business relationships may be under threat of exposure, it is of not as m= uch=20 (critical) concern to IGPs like OSPF.

2)     =20 OSPFv2  Management issues section possible=20 clashing ideas. The first two paragraphs indicate that OSPF uses MD5 and = that=20 there neither exists a mechanism to negotiate keys, nor to negotiate the = hash=20 algorithms to be used. However, the paragraph immediately following it ta= lks=20 about the proliferation of a number of hash algorithms, as well as the ne= ed to=20 continuously upgrade the algorithms with the problems this would face in = OSPF.=20 This statement seems more applicable to RFC5709 rather than the OSPF base= =20 algorithm itself and should probably accompany a much later  

 

&l= t;Manav> I=20 am not sure i understand this. Why is this more applicable for=20 5709?

 

Ch= eers,=20 Manav

 

 paragraph [Section 2.2, Paragraph= =20 5].  A similar issue exists for IS-IS. Both these sections would ben= efit=20 from a reference to karp, another IETF initiative that deals with solutio= ns=20 for cryptographic authentication and key management for routing protocols= .=20 Referencing and acknowledging other active work that is trying to mitigat= e=20 routing security cryptographic issues would complement this section very = well,=20 and provide readers and implementers a more complete picture of the probl= em=20 and what it would take to solve it.  

 

3)     =20 DoS attacks as crypto issues, and applicability. = While=20 the presence and or use of cryptographic functions at the victim end does= =20 allow the attacker to have a greater impact on the victim with lesser eff= ort,=20 DoS attacks can, in reality, be launched on any network even in the absen= ce of=20 cryptographic functions. (e.g., tcp syn flooding, etc). Therefore, in a w= ay,=20 cryptographic performance demands can facilitate DoS attacks. This is=20 noteworthy. However, careful implementation choices lessen the impact of= =20 cryptographic performance demands on the recipient end, thereby resulting= in=20 wasted effort at the attacker end, making the DoS attack less lucrative t= o=20 launch. This should probably be indicated.  Secondly, this attack is= =20 discussed selectively only under a few routing protocols in the document = when=20 it is clearly applicable to almost all. 

4)     =20 BGP v4 Management issues. “Most BGP impleme= ntations=20 will accept BGP packets with a bad digest up to the hold interval negotia= ted=20 between BGP peers at peering startup.” The authors have highlighted= an issue=20 that is specific to certain implementations. Since this is an implementat= ion=20 detail, the motivation behind this choice should be noted in order for th= e=20 readers to fully understand the compelling reasons behind making such a=20 choice. Secondly, if implementation specific issues are to be considered= =20 within scope of this document then, for consistency, the same should be=20 considered of all known and currently in use implementations of all routi= ng=20 protocols that fall within the scope of this initiative. This would resul= t in=20 a long and drawn out process of accumulating such information. Thirdly, a= s=20 implementations get updated these issues would cease to be relevant issue= s.=20 Finally, since the karp initiative deals with these kinds of problems it = would=20 be very informative to mention the initiative here.

5)     =20 RIPv2 replay same seq# attack. Since a repeated=20 sequence number is detected as a replay, and discarded, what impact does = this=20 attack have on the recipient? What damage results from this attack to the= =20 routing?

6)     =20 The current abstract only talks about certain=20 cryptographic digests that have been made obsolete due to recent findings= =20 while the document deals with other relevant issues as well. Therefore, t= he=20 abstract should be updated to indicate the full content of document. = ;=20

7)     =20 The authors should include, wherever relevant,=20 references to other initiatives like karp that have intersections with th= e=20 content that the opsec-crypto-issues draft addresses. This will facilitat= e=20 better interactions across various working groups, and provide implemente= rs,=20 and operators a greater awareness and a more complete picture of routing= =20 security and cryptography issues.=20

--_000_7C362EEF9C7896468B36C9B79200D8350CCF8FB5B2INBANSXCHMBSA_-- From root@core3.amsl.com Thu Jun 10 13:00:01 2010 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5660B3A6767; Thu, 10 Jun 2010 13:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100610200001.5660B3A6767@core3.amsl.com> Date: Thu, 10 Jun 2010 13:00:01 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D ACTION:draft-ietf-opsec-routing-protocols-crypto-issues-06.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 20:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Issues with existing Cryptographic Protection Methods for Routing Protocols Author(s) : J. Jaeggli, S. Hares, M. Bhatia, V. Manral, R. White Filename : draft-ietf-opsec-routing-protocols-crypto-issues-06.txt Pages : 20 Date : 2010-6-9 Routing protocols have over time been extended to use cryptographic mechanisms to validate data being received from a neighboring router to ensure that: o It has not been modified in transit. o Actually originated from an authorized neighboring router. The cryptographic mechanisms defined to date and described in this document rely on a digest produced with a hash algorithm applied to the payload encapsulated in the routing protocol packet. This document outlines some of the limitations of the current mechanism, problems with manual keying of these cryptographic algorithms, and possible vectors for the exploitation of these limitations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-routing-protocols-crypto-issues-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsec-routing-protocols-crypto-issues-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-6-10125943.I-D@ietf.org> --NextPart-- From Anuja.Sonalker@cobham.com Thu Jun 10 14:47:13 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 616FF3A67CF for ; Thu, 10 Jun 2010 14:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.501 X-Spam-Level: X-Spam-Status: No, score=0.501 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kx1WDHEuOARq for ; Thu, 10 Jun 2010 14:47:00 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 5190A3A63C9 for ; Thu, 10 Jun 2010 14:47:00 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o5ALkxD4021728; Thu, 10 Jun 2010 16:46:59 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o5ALkxBh032714; Thu, 10 Jun 2010 16:46:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB08E6.73E5809D" Date: Thu, 10 Jun 2010 17:46:58 -0400 Message-ID: <5ABE30CE099A524CBF95C715D37BCACC03388AD7@nemo.columbia.ads.sparta.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CCF8FB5B2@INBANSXCHMBSA1.in.alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] Some comments/disussion points ondraft-ietf-opsec-routing-protocols-crypto-issues-05 Thread-Index: AcsGWEOTnA4IMXOIQ5+JrOcLe/mPjAAQK+4AAJAWRBA= References: <5ABE30CE099A524CBF95C715D37BCACC03388479@nemo.columbia.ads.sparta.com> <7C362EEF9C7896468B36C9B79200D8350CCF8FB5B2@INBANSXCHMBSA1.in.alcatel-lucent.com> From: "Sonalker, Anuja" To: "Bhatia, Manav \(Manav\)" , Subject: Re: [OPSEC] Some comments/disussion points ondraft-ietf-opsec-routing-protocols-crypto-issues-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2010 21:47:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB08E6.73E5809D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Manav, =20 Thanks for your response. Sorry for the delay in responding back. Let me try to clarify further.=20 =20 I am not sure i understand this. Why is this more applicable for 5709? Ospfv2 base spec does not have the provision to negotiate any hash algorithms. 5709 adds support for using various other algorithms ( SHA-family, HMAC mode). So the statement about the proliferation of hash algorithms and need for update mechanisms seems more applicable to 5709 as opposed to 2328. =20 =20 Regarding your point (5) about RIPv2 . =20 The doc clearly states that the attack is only possible *if* somebody is able to capture a higher cryptographic sequence number (possibly before the seq number space rolled over or router rebooted, etc) packet from the source. That packet can be replayed to disrupt routing as explained in the document. =20 =20 Sounds like we are talking about different issues. Yes, the attack you describe in Scenario 1 does require a higher sequence number (and is clearly stated.) ...but I was talking about the bulleted paragraph under Section 6.1 (page 12, second bullet) -- "RIPv2 allows multiple packets with the *same* sequence number. This could mean the same packet may be replayed many times before the next legitimate packet is sent. An attacker may resend the same packet repeatedly until the next Hello packet is transmitted and received, which means the hello interval therefore determines the attack window." This sounds like a slightly different attack than the higher sequence number attack you describe in Scenario 1 which executed by replaying any packet from the LAN with a *higher* sequence number, and possibly changing the originator IP information.=20 =20 With a higher sequence number coming from the attacker, R1 is now unable to send legitimate routing updates anymore --as you have stated. This is perfectly true. The question is - if the *same* sequence number packet is replayed by the attacker, what effect would that have on R1? What effect would that have on the network? =20 Hope my question is clearer now.=20 =20 Thanks so much! -Anuja =20 =20 =20 =20 =20 =20 From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]=20 Sent: Monday, June 07, 2010 7:36 PM To: Sonalker, Anuja; opsec@ietf.org Subject: RE: [OPSEC] Some comments/disussion points ondraft-ietf-opsec-routing-protocols-crypto-issues-05 =20 Hi Anuja, =20 Thanks for the comments. We will definitely consider them when updating the document. =20 Regarding your point (5) about RIPv2 . =20 The doc clearly states that the attack is only possible *if* somebody is able to capture a higher cryptographic sequence number (possibly before the seq number space rolled over or router rebooted, etc) packet from the source. That packet can be replayed to disrupt routing as explained in the document. =20 More inline .. =20 ________________________________ From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of Sonalker, Anuja Sent: Monday, June 07, 2010 9.14 PM To: opsec@ietf.org Subject: [OPSEC] Some comments/disussion points on draft-ietf-opsec-routing-protocols-crypto-issues-05 Dear Authors, =20 First of all, I would like to say what a great initiative this has been to document all cryptographic security issues with routing protocols. This document can become a great source of information for implementers, operators, researchers, engineers, device manufacturers, and others alike. In the interest of making this document finer, I had a few suggestions for the authors to review. Hopefully, they will be of benefit to you. =20 Thanks, Anuja =20 Few comments on the opsec-routing-protocols-crypto-issues-05 IETF draft=20 1) Confidentiality as an issue in the Problem Statement=20 The document aptly notes that digest verification mechanisms are not intended to provide confidentiality, and that one router's routing table information could possibly be exposed to other routers in many different ways. Since confidentiality is not a critical issue for all routing protocols in general, it would be beneficial to highlight and acknowledge the same. For example, while confidentiality is of critical interest to inter autonomous system protocols like BGP, or ones where business relationships may be under threat of exposure, it is of not as much (critical) concern to IGPs like OSPF.=20 2) OSPFv2 Management issues section possible clashing ideas. The first two paragraphs indicate that OSPF uses MD5 and that there neither exists a mechanism to negotiate keys, nor to negotiate the hash algorithms to be used. However, the paragraph immediately following it talks about the proliferation of a number of hash algorithms, as well as the need to continuously upgrade the algorithms with the problems this would face in OSPF. This statement seems more applicable to RFC5709 rather than the OSPF base algorithm itself and should probably accompany a much later =20 =20 I am not sure i understand this. Why is this more applicable for 5709? =20 Cheers, Manav =20 paragraph [Section 2.2, Paragraph 5]. A similar issue exists for IS-IS. Both these sections would benefit from a reference to karp, another IETF initiative that deals with solutions for cryptographic authentication and key management for routing protocols. Referencing and acknowledging other active work that is trying to mitigate routing security cryptographic issues would complement this section very well, and provide readers and implementers a more complete picture of the problem and what it would take to solve it. =20 =20 3) DoS attacks as crypto issues, and applicability. While the presence and or use of cryptographic functions at the victim end does allow the attacker to have a greater impact on the victim with lesser effort, DoS attacks can, in reality, be launched on any network even in the absence of cryptographic functions. (e.g., tcp syn flooding, etc). Therefore, in a way, cryptographic performance demands can facilitate DoS attacks. This is noteworthy. However, careful implementation choices lessen the impact of cryptographic performance demands on the recipient end, thereby resulting in wasted effort at the attacker end, making the DoS attack less lucrative to launch. This should probably be indicated. Secondly, this attack is discussed selectively only under a few routing protocols in the document when it is clearly applicable to almost all. =20 4) BGP v4 Management issues. "Most BGP implementations will accept BGP packets with a bad digest up to the hold interval negotiated between BGP peers at peering startup." The authors have highlighted an issue that is specific to certain implementations. Since this is an implementation detail, the motivation behind this choice should be noted in order for the readers to fully understand the compelling reasons behind making such a choice. Secondly, if implementation specific issues are to be considered within scope of this document then, for consistency, the same should be considered of all known and currently in use implementations of all routing protocols that fall within the scope of this initiative. This would result in a long and drawn out process of accumulating such information. Thirdly, as implementations get updated these issues would cease to be relevant issues. Finally, since the karp initiative deals with these kinds of problems it would be very informative to mention the initiative here.=20 5) RIPv2 replay same seq# attack. Since a repeated sequence number is detected as a replay, and discarded, what impact does this attack have on the recipient? What damage results from this attack to the routing? 6) The current abstract only talks about certain cryptographic digests that have been made obsolete due to recent findings while the document deals with other relevant issues as well. Therefore, the abstract should be updated to indicate the full content of document. =20 7) The authors should include, wherever relevant, references to other initiatives like karp that have intersections with the content that the opsec-crypto-issues draft addresses. This will facilitate better interactions across various working groups, and provide implementers, and operators a greater awareness and a more complete picture of routing security and cryptography issues.=20 ------_=_NextPart_001_01CB08E6.73E5809D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Manav,

 

Thanks for your = response. Sorry for the delay in responding back.  Let me try to clarify further. =

 

<Manav> I am not sure i = understand this. Why is this more applicable for 5709?

Ospfv2 base spec does = not have the provision to negotiate any hash algorithms.  5709 adds support = for using various other algorithms ( SHA-family, HMAC mode). So the = statement about the proliferation of hash algorithms and need for update mechanisms = seems more applicable to 5709 as opposed to 2328. = <imho>

 

 

<Manav> Regarding your point (5) about RIPv2 = .

 

The doc clearly states that the attack is only possible *if* somebody is able to capture a higher cryptographic sequence number = (possibly before the seq number space rolled over or router rebooted, etc) packet = from the source. That packet can be replayed to disrupt routing as explained = in the document.

 

 

Sounds like we are = talking about different issues. Yes, the attack you describe in Scenario 1 does = require a higher sequence number (and is clearly stated.) …but I was talking about = the bulleted paragraph under Section 6.1 (page 12, second  bullet) -- =   “RIPv2 allows multiple packets with the *same* sequence number. This could mean = the same packet may be replayed many times before the next legitimate packet = is sent. An attacker may resend the same packet repeatedly until the next = Hello packet is transmitted and received, which means the hello interval = therefore determines the attack window.” This sounds like  a slightly = different attack than the higher sequence number attack you describe in Scenario 1 = which executed by replaying any packet from the LAN with a  *higher* = sequence number, and possibly changing the originator IP information. =

 

With a higher = sequence number coming from the attacker, R1 is now unable to send legitimate routing = updates anymore --as you have stated. This is perfectly true. The question is = – if the *same* sequence number packet is replayed by the attacker, = what effect would that have on R1?  What effect would that have on the = network?

 

Hope my question is = clearer now.

 

Thanks so = much!

-Anuja

 

 

 

 

 

 

From:= Bhatia, = Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com]
Sent: Monday, June 07, 2010 7:36 PM
To: Sonalker, Anuja; opsec@ietf.org
Subject: RE: [OPSEC] Some comments/disussion points ondraft-ietf-opsec-routing-protocols-crypto-issues-05

 

Hi Anuja,

 

Thanks for the comments. We will definitely consider them = when updating the document.

 

Regarding your point (5) about RIPv2 .

 

The doc clearly states that the attack is only possible *if* somebody is able to capture a higher cryptographic sequence number = (possibly before the seq number space rolled over or router rebooted, etc) packet = from the source. That packet can be replayed to disrupt routing as explained = in the document.

 

More inline ..

 

From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of Sonalker, Anuja
Sent: Monday, June 07, 2010 9.14 PM
To: opsec@ietf.org
Subject: [OPSEC] Some comments/disussion points on draft-ietf-opsec-routing-protocols-crypto-issues-05

Dear Authors,

 

First of all, I would like to say what a great = initiative this has been to document all cryptographic security issues with routing protocols. This document can become a great source of information for implementers, operators, researchers, engineers, device manufacturers, = and others alike. In the interest of making this document finer, I had a few suggestions for the authors to review. Hopefully, they will be of = benefit to you.

 

Thanks,

Anuja

 

Few comments on the opsec-routing-protocols-crypto-issues-05 IETF draft

1)      = Confidentiality as an issue in the Problem Statement

The document aptly notes that digest verification mechanisms are not = intended to provide confidentiality, and that one router’s routing table = information could possibly be exposed to other routers in many different ways. Since confidentiality is not a critical issue for all routing protocols in = general, it would be beneficial to highlight and acknowledge the same. For = example, while confidentiality is of critical interest to inter autonomous system protocols like BGP, or ones where business relationships may be under = threat of exposure, it is of not as much (critical) concern to IGPs like OSPF. =

2)      = OSPFv2  Management issues section possible clashing ideas. The first two = paragraphs indicate that OSPF uses MD5 and that there neither exists a mechanism to negotiate keys, nor to negotiate the hash algorithms to be used. = However, the paragraph immediately following it talks about the proliferation of a = number of hash algorithms, as well as the need to continuously upgrade the = algorithms with the problems this would face in OSPF. This statement seems more = applicable to RFC5709 rather than the OSPF base algorithm itself and should = probably accompany a much later  

=

 

<Manav> I am not sure i = understand this. Why is this more applicable for 5709?

 

Cheers, Manav

 

 paragraph [Section 2.2, Paragraph 5].  A = similar issue exists for IS-IS. Both these sections would benefit from a = reference to karp, another IETF initiative that deals with solutions for = cryptographic authentication and key management for routing protocols. Referencing and = acknowledging other active work that is trying to mitigate routing security = cryptographic issues would complement this section very well, and provide readers and implementers a more complete picture of the problem and what it would = take to solve it.  

 

3)      DoS = attacks as crypto issues, and applicability. While the presence and or use of cryptographic functions at the victim end does allow the attacker to = have a greater impact on the victim with lesser effort, DoS attacks can, in = reality, be launched on any network even in the absence of cryptographic = functions. (e.g., tcp syn flooding, etc). Therefore, in a way, cryptographic = performance demands can facilitate DoS attacks. This is noteworthy. However, careful implementation choices lessen the impact of cryptographic performance = demands on the recipient end, thereby resulting in wasted effort at the attacker = end, making the DoS attack less lucrative to launch. This should probably be indicated.  Secondly, this attack is discussed selectively only = under a few routing protocols in the document when it is clearly applicable to = almost all. 

4)      BGP v4 Management issues. “Most BGP implementations will accept BGP = packets with a bad digest up to the hold interval negotiated between BGP peers at = peering startup.” The authors have highlighted an issue that is specific = to certain implementations. Since this is an implementation detail, the = motivation behind this choice should be noted in order for the readers to fully = understand the compelling reasons behind making such a choice. Secondly, if = implementation specific issues are to be considered within scope of this document then, = for consistency, the same should be considered of all known and currently in = use implementations of all routing protocols that fall within the scope of = this initiative. This would result in a long and drawn out process of = accumulating such information. Thirdly, as implementations get updated these issues = would cease to be relevant issues. Finally, since the karp initiative deals = with these kinds of problems it would be very informative to mention the = initiative here.

5)      RIPv2 = replay same seq# attack. Since a repeated sequence number is detected as a = replay, and discarded, what impact does this attack have on the recipient? What = damage results from this attack to the routing?

6)      The = current abstract only talks about certain cryptographic digests that have been = made obsolete due to recent findings while the document deals with other = relevant issues as well. Therefore, the abstract should be updated to indicate the full = content of document. 

7)      The = authors should include, wherever relevant, references to other initiatives like = karp that have intersections with the content that the opsec-crypto-issues = draft addresses. This will facilitate better interactions across various = working groups, and provide implementers, and operators a greater awareness and = a more complete picture of routing security and cryptography issues. =

------_=_NextPart_001_01CB08E6.73E5809D-- From joelja@bogus.com Sat Jun 12 15:05:09 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1CB23A6405 for ; Sat, 12 Jun 2010 15:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtFYhyJXrt8w for ; Sat, 12 Jun 2010 15:05:08 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 1896C3A63CB for ; Sat, 12 Jun 2010 15:05:07 -0700 (PDT) Received: from [192.168.1.151] (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.3) with ESMTP id o5CM58DU043102 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sat, 12 Jun 2010 22:05:09 GMT (envelope-from joelja@bogus.com) Message-ID: <4C140493.90600@bogus.com> Date: Sat, 12 Jun 2010 15:05:07 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "opsec@ietf.org" X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sat, 12 Jun 2010 22:05:09 +0000 (UTC) Subject: [OPSEC] Agenda items X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 22:05:10 -0000 Initial schedule isn't available yet but it's time to start collecting agenda items for Maastricht... joel From manav.bhatia@alcatel-lucent.com Tue Jun 15 01:04:06 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0EF53A67E3 for ; Tue, 15 Jun 2010 01:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.059 X-Spam-Level: X-Spam-Status: No, score=-0.059 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bZcILJG+Fhq for ; Tue, 15 Jun 2010 01:04:05 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 8BBB93A6971 for ; Tue, 15 Jun 2010 01:04:04 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id o5F843Ig008063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 15 Jun 2010 03:04:05 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o5F841aE025287 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Jun 2010 13:34:02 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.50]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 15 Jun 2010 13:34:01 +0530 From: "Bhatia, Manav (Manav)" To: "Sonalker, Anuja" , "opsec@ietf.org" Date: Tue, 15 Jun 2010 13:33:59 +0530 Thread-Topic: [OPSEC] Some comments/disussion points ondraft-ietf-opsec-routing-protocols-crypto-issues-05 Thread-Index: AcsGWEOTnA4IMXOIQ5+JrOcLe/mPjAAQK+4AAJAWRBAA4ExfAA== Message-ID: <7C362EEF9C7896468B36C9B79200D8350CCFBB6078@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <5ABE30CE099A524CBF95C715D37BCACC03388479@nemo.columbia.ads.sparta.com> <7C362EEF9C7896468B36C9B79200D8350CCF8FB5B2@INBANSXCHMBSA1.in.alcatel-lucent.com> <5ABE30CE099A524CBF95C715D37BCACC03388AD7@nemo.columbia.ads.sparta.com> In-Reply-To: <5ABE30CE099A524CBF95C715D37BCACC03388AD7@nemo.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 Subject: Re: [OPSEC] Some comments/disussion points ondraft-ietf-opsec-routing-protocols-crypto-issues-05 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 08:04:06 -0000 Hi Anuja, =20 > Ospfv2 base spec does not have the provision to negotiate=20 > any hash algorithms. 5709 adds support for using various=20 > other algorithms ( SHA-family, HMAC mode). So the statement > about the proliferation of hash algorithms and need for=20 > update mechanisms seems more applicable to 5709 as opposed to 2328. =20 I am still unclear about this. If you look at the original text it says the following: "OSPF does not specify a mechanism to negotiate keys, nor does it=20 specify any mechanism to negotiate the hash algorithms to be used." This remains true even with 5709. 5709 really adds nothing new to the base = spec in terms of negotiating keys, exchanging the hash algo information, et= c. The only thing it does is to explain the semantics of how the HMAC-SHA-X= computation must be done. [clipped] =20 > Sounds like we are talking about different issues. Yes, the=20 > attack you describe in Scenario 1 does require a higher=20 > sequence number (and is clearly stated.) ...but I was talking > about the bulleted paragraph under Section 6.1 (page 12, second=20 > bullet) -- "RIPv2 allows multiple packets with the *same*=20 > sequence number. This could mean the same packet may be replayed > many times before the next legitimate packet is sent. An attacker=20 > may resend the same packet repeatedly until the next Hello packet > is transmitted and received, which means the hello interval > therefore determines the attack window." This sounds like a > slightly different attack than the higher sequence number attack=20 > you describe in Scenario 1 which executed by replaying any packet=20 > from the LAN with a *higher* sequence number, and possibly=20 > changing the originator IP information.=20 > With a higher sequence number coming from the attacker,=20 > R1 is now unable to send legitimate routing updates anymore=20 > --as you have stated. This is perfectly true. The question is -=20 > if the *same* sequence number packet is replayed by the attacker, > what effect would that have on R1? What effect would that have on the ne= twork? It can disrupt the routing. If you replay a packet with the same sequence n= umber from an earlier session then this would be accepted, as RIP would acc= ept packets with the same seq number.=20 Hope this helps. Cheers,= From joelja@bogus.com Mon Jun 21 21:49:54 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044FB3A6942 for ; Mon, 21 Jun 2010 21:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nTOXm49F85i for ; Mon, 21 Jun 2010 21:49:52 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 965BA3A68BB for ; Mon, 21 Jun 2010 21:49:51 -0700 (PDT) Received: from [192.168.2.103] (m4a0536d0.tmodns.net [208.54.5.74]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o5M4nqRo099094 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 22 Jun 2010 04:49:55 GMT (envelope-from joelja@bogus.com) Message-ID: <4C2040EB.2040202@bogus.com> Date: Mon, 21 Jun 2010 21:49:47 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: raszuk@cisco.com, "'opsec@ietf.org'" X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 22 Jun 2010 04:49:56 +0000 (UTC) Subject: [OPSEC] widely adopted communities presentation at nanog 49 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 04:49:54 -0000 While I have some personal ambivialence to the idea of specifiying well-known communities, I noted this presentation with some interest at nanog and since the subject has been discussed here before I would drop a pointer to the presentation. http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Raszuk-Wide_BGP_Communities_00_2.pdf From christopher.morrow@gmail.com Mon Jun 21 22:33:35 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 690C83A6950 for ; Mon, 21 Jun 2010 22:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrFmdI5k+k5m for ; Mon, 21 Jun 2010 22:33:16 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8396D3A690B for ; Mon, 21 Jun 2010 22:33:14 -0700 (PDT) Received: by iwn9 with SMTP id 9so1322817iwn.31 for ; Mon, 21 Jun 2010 22:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=qgk873k9T2JEIM6cBe5ZTTphozZB8ZJCyaryp9KTbyo=; b=vszHEchoZZGwit7JL2aEIaEm8DGwTe5+zdqukfIY0kfvaghbuAuh2LdkNdWYiL2xfK 1cOjnZbWpgzjNprWAL1ykjG23Coktr3eAgiu+zioEJvCP5kuar+7mVVIgHsLceW2IVFa ygyFv3pKW2jn4Lug1CUWtGgJtROh9cybcn6Xo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Dx+Aml8yilC5L3mQRJBxB+9yjG866nAIaX5LHAImhC76LFLur3Sl0h2CShjR90OUW3 K69IMl4D/lnM65a/LLbfXRplgYgK3m4QrcN4tydPsKCa3q7WUldKrpWOOCT5Wieq37Oh uJnbh5bn9kWawxRSTJB/N7G10UPkWEBBxLGVs= MIME-Version: 1.0 Received: by 10.231.176.74 with SMTP id bd10mr6062810ibb.38.1277184799157; Mon, 21 Jun 2010 22:33:19 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.231.156.134 with HTTP; Mon, 21 Jun 2010 22:33:19 -0700 (PDT) In-Reply-To: <4C2040EB.2040202@bogus.com> References: <4C2040EB.2040202@bogus.com> Date: Tue, 22 Jun 2010 01:33:19 -0400 X-Google-Sender-Auth: hCxVquvvnrPmbIqkRAo-xdmdPQM Message-ID: From: Christopher Morrow To: Joel Jaeggli Content-Type: text/plain; charset=ISO-8859-1 Cc: raszuk@cisco.com, "opsec@ietf.org" Subject: Re: [OPSEC] widely adopted communities presentation at nanog 49 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 05:33:35 -0000 On Tue, Jun 22, 2010 at 12:49 AM, Joel Jaeggli wrote: > While I have some personal ambivialence to the idea of specifiying > well-known communities, I noted this presentation with some interest at > nanog and since the subject has been discussed here before I would drop > a pointer to the presentation. > > http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Raszuk-Wide_BGP_Communities_00_2.pdf i vote, again, no 'well known communities' ... the guarantee that they exist and will be used as intended isn't currently working with no-export (as you stated at the mic I think). Having a contractually obligated set of communities (even if it's different per provider) with proscribed behaviours should be the target (which each customer should pursue). just one guy's opinion (I think). -chris From warren@kumari.net Tue Jun 22 01:10:56 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E7E28C0E0 for ; Tue, 22 Jun 2010 01:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yk7lqLfabjZT for ; Tue, 22 Jun 2010 01:10:51 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 7ACF93A698F for ; Tue, 22 Jun 2010 01:10:51 -0700 (PDT) Received: from [130.129.17.237] (unknown [130.129.17.237]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 093842284033; Tue, 22 Jun 2010 04:06:54 -0400 (EDT) Message-Id: <49BFF6BC-2B09-451F-AA11-45C1AEE48178@kumari.net> From: Warren Kumari To: Christopher Morrow In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 22 Jun 2010 10:10:52 +0200 References: <4C2040EB.2040202@bogus.com> X-Mailer: Apple Mail (2.936) Cc: raszuk@cisco.com, "opsec@ietf.org" Subject: Re: [OPSEC] widely adopted communities presentation at nanog 49 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 08:10:56 -0000 On Jun 22, 2010, at 7:33 AM, Christopher Morrow wrote: > On Tue, Jun 22, 2010 at 12:49 AM, Joel Jaeggli > wrote: >> While I have some personal ambivialence to the idea of specifiying >> well-known communities, I noted this presentation with some >> interest at >> nanog and since the subject has been discussed here before I would >> drop >> a pointer to the presentation. >> >> http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Raszuk-Wide_BGP_Communities_00_2.pdf > > i vote, again, no 'well known communities' ... the guarantee that they > exist and will be used as intended isn't currently working with > no-export (as you stated at the mic I think). Having a contractually > obligated set of communities (even if it's different per provider) > with proscribed behaviours should be the target (which each customer > should pursue). > Keep in mind that I did not see the presentation, but I think that having 'well-known' communities in the sense that the communities are well known would be very useful, but 'well-known' with its current meaning is not... It would be really useful if: A: providers published their communities somewhere easily findable (and didn't require NDAs and such for them...) B: providers converged towards using the same communities -- If would be great if I could only have to store 3-5 different numbers in my head for what denotes a customer and not one per peer. I think that this could / should be achieved by market pressure and not though the IETF. Just my feelings on this, W > just one guy's opinion (I think). > -chris > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From raszuk@cisco.com Tue Jun 22 01:32:44 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FAD53A67B7 for ; Tue, 22 Jun 2010 01:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.2 X-Spam-Level: X-Spam-Status: No, score=-10.2 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F32kJWf6zTIY for ; Tue, 22 Jun 2010 01:32:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B78A83A6987 for ; Tue, 22 Jun 2010 01:32:36 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAN4RIEyrRN+K/2dsb2JhbACDHZt1caYOgXgLAYcgkTqBJYMGcAQ X-IronPort-AV: E=Sophos;i="4.53,459,1272844800"; d="scan'208";a="548211070" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 22 Jun 2010 08:21:58 +0000 Received: from [192.168.1.61] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o5M8LvRb003642 for ; Tue, 22 Jun 2010 08:21:58 GMT Message-ID: <4C2072A7.50905@cisco.com> Date: Tue, 22 Jun 2010 10:21:59 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "'opsec@ietf.org'" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [OPSEC] Fwd: Re: widely adopted communities presentation at nanog 49 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 08:32:45 -0000 Subject: Re: widely adopted communities presentation at nanog 49 Date: Tue, 22 Jun 2010 09:17:21 +0200 From: Robert Raszuk Reply-To: raszuk@cisco.com To: Joel Jaeggli , morrowc.lists@gmail.com CC: 'opsec@ietf.org' Hi Joel/Chris, Many thx for forwarding the pointer to opsec WG. I guess I need to subscribe now :) The up to date version can be found here: ftp://ftpeng.cisco.com/raszuk/bgp_wide_comms/ Based on the input received after Nanog to avoid any misinterpretations I have changed the semantics of the pre-defined communities from "well-known" to simply "registered". The point of defining them is not to enforce global support both by operators or by vendors, but simply to make it easier to apply commonly used policies intra and inter-domians. It is just to serve as an informational collection of community templates which could be used if fits in the contractual agreements. Another point is that subset of defined communities are AS specific - today communities are of common execution type. That means that AS specific communities would be executed only on the boundary to or by target AS specified in the community therefor passing those could be much less troublesome as compared with today's standard BGP communities. Feedback is welcome ! Many thx, R. > While I have some personal ambivialence to the idea of specifiying > well-known communities, I noted this presentation with some interest at > nanog and since the subject has been discussed here before I would drop > a pointer to the presentation. > > http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Raszuk-Wide_BGP_Communities_00_2.pdf > From joelja@bogus.com Tue Jun 22 07:08:23 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20BC03A68AC for ; Tue, 22 Jun 2010 07:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwQ-bPQN0Nua for ; Tue, 22 Jun 2010 07:08:21 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id F3AB53A677D for ; Tue, 22 Jun 2010 07:08:19 -0700 (PDT) Received: from [192.168.1.228] (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o5ME8OCQ030390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 22 Jun 2010 14:08:25 GMT (envelope-from joelja@bogus.com) Message-Id: From: Joel Jaeggli To: "opsec@ietf.org" Content-Type: multipart/alternative; boundary=Apple-Mail-1-408289443 Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (7B367) Mime-Version: 1.0 (iPad Mail 7B367) Date: Tue, 22 Jun 2010 07:08:35 -0700 References: X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 22 Jun 2010 14:08:25 +0000 (UTC) Subject: [OPSEC] Fwd: Nomcom 2010-2011: Second Call for Volunteers X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 14:08:23 -0000 --Apple-Mail-1-408289443 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Begin forwarded message: > From: "Romascanu, Dan (Dan)" > Date: June 22, 2010 12:30:14 AM PDT > To: > Subject: FW: Nomcom 2010-2011: Second Call for Volunteers > > OPS Area Chairs, > > Please forward this message to your WG mail lists. Participation in the > Nomcom process is an opportunity for any IETF participant to support the > IETF and influence its future by selecting the next generation of IETF > leaders and by receiving and processing the inputs of the community > about the IETF work and processes. > > Regards, > > Dan > > > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair > Sent: Tuesday, June 22, 2010 12:49 AM > To: IETF Announcement list > Subject: Nomcom 2010-2011: Second Call for Volunteers > > Hi all, > > This is the Second call for Volunteers for the 2010-11 nomcom. We are > just about halfway through the volunteer period so if you are > considering volunteering please do so very soon. > > I am pleased to report that we have 29 volunteers thus far whose > qualifications have been confirmed by the secretariat. I have notified > each of these volunteers by email. > > If you volunteered before 08:00 PDT (15:00 UTC) on June 21 to serve as a > voting member and have not received a confirmation email from me, please > re-submit and bring to my attention right away! > > However, we need many more volunteers. You have until 17:00 PDT (24:00 > UTC) on July 8, 2010 to volunteer for nomcom but it is much better if > you volunteer as early as possible. The more volunteers, the better > chance we have of choosing a random yet representative cross section of > the IETF > pouplation. > > As a reminder, volunteers must have attended 3 of the past 5 IETF > meetings - per RFC 3777, which means 3 of the following meetings: > IETF-73, IETF-74, IETF-75, IETF-76 and IETF-77. If you qualify, and are > willing to forgo appointment to any of the positions for which the > nominating committee is responsible, please volunteer. > > The 10 nominating committee members are selected randomly from a pool of > volunteers. The details of the operation of nomcom may be found in RFC > 3777. The process on how to volunteer for nomcom is in the initial > announcement: https://datatracker.ietf.org/ann/nomcom/2330/ > > The lists of open positions and people whose terms end in March 2011 and > thus the positions for which the nominating committee is responsible are > summarized in the initial announcement: > https://datatracker.ietf.org/ann/nomcom/2330/ > > The 29 volunteers who have thus far been qualified by the secretariat > are: > > Fred Baker, Cisco Systems > > Stephan Wenger, Vidyo, Inc. > > Marc Blanchet, Viagenie > > Lixia Zhang, UCLA > > John Drake, Juniper Networks > > Ole Troan, Cisco > > Jiankang Yao, CNNIC > > Wassim Haddad, Ericsson > > Yi Zhao, Huawei USA > > Teemu Savolainen, Nokia > > Jouni Korhonen, Nokia Siemens Networks > > Mehmet Ersue, Nokia Siemens Networks > > Christian Schmidt, Nokia Siemens Networks > > Stephen Hanna, Juniper Networks > > Suresh Krishnan, Ericsson > > Eric Gray, Ericsson > > David Sinicrope, Ericsson > > Jan Melen, Ericsson > > Richard Barnes, BBN Technologies > > Hugo Salgado Hernandez, NIC Chile > > Ning Zong, Huawei Technologies > > Qin Wu, Huawei Technologies > > Karen Seo, BBN Technologies > > Haibin Song, Huawei Technologies > > Susan Hares, Huawei Technologies > > Tony Hansen. AT&T Labs > > Fuqing Huang, Huawei Technologies Co., Ltd. > > Huub van Helvoort, Huawei Technologies > > Miya Kohno, Juniper Networks > > The primary activity for this nomcom will begin just prior to IETF-78 in > Maastricht and should be completed in early January 2011. The nomcom > will be collecting requirements from the community, as well as talking > to candidates and to community members about candidates. There will be > weekly conference calls to ensure progress. Thus, being a nomcom member > does require some time commitment. > > While, there is no requirement in RFC 3777 that a participant attend > IETF meetings while serving on nomcom, please consider that during the > IETF meetings, people that do not attend would be expected to remotely > participate during the day in the time zones of the meeting locations - > Maastricht at the end of July and Beijing in November. > > If you are not yet sure you would like to volunteer, please consider > that nomcom members play a very important role in shaping the leadership > of the IETF. Ensuring the leadership of the IETF is fair and balanced > and comprised of those who can lead the IETF in the right direction is > an important responsibility that rests on the IETF participants at > large. > Volunteering for the nomcom is a good way of contributing in that > direction. > > Please volunteer by sending an email before: > 17:00 PDT (24:00 UTC) July 8, 2010 as follows: > > To: nomcom-chair@ietf.org > Subject: Nomcom 2010-11 Volunteer > > Please include the following information in the body: > > // As you enter in the IETF Registration Form, > // First/Given name followed by Last/Family Name > > > // typically what goes in the Company field > // in the IETF Registration Form > > [] > // > > // For confirmation if selected > > Please expect an email response from me within 3 days stating whether or > not you are qualified. If you don't receive a response, please re-send > your email with the tag "Duplicate:" added to the subject line. > > Thank you and I hope to hear from you, > > Thomas Walsh > Chair, Nomcom 2010-11 > Email: nomcom-chair@ietf.org > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --Apple-Mail-1-408289443 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Begin forwarded = message:

From: = "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Date:<= /b> June 22, 2010 12:30:14 AM PDT
To: <ops-chairs@ietf.org>
Subj= ect: FW: Nomcom 2010-2011: Second Call for Volunteers =

OPS Area = Chairs,

Please forward this message to = your WG mail lists. Participation in the
Nomcom process = is an opportunity for any IETF participant to support = the
IETF and influence its future by selecting the next = generation of IETF
leaders and by receiving and = processing the inputs of the community
about the IETF = work and processes. =

Regards,

Dan


-----Original = Message-----
From: ietf-announce-bounces@ietf.= org
[mailto:ietf-announce-bounces@ietf.org] On = Behalf Of NomCom Chair
Sent: Tuesday, June 22, 2010 = 12:49 AM
To: IETF Announcement = list
Subject: Nomcom 2010-2011: Second Call for = Volunteers

Hi all, =

This is the Second call for Volunteers = for the 2010-11 nomcom.  We are
just about halfway = through the volunteer period so if you are
considering = volunteering please do so very soon.

I = am pleased to report that we have 29 volunteers thus far = whose
qualifications have been confirmed by the = secretariat. I have notified
each of these volunteers by = email.  

If you volunteered before = 08:00 PDT (15:00 UTC) on June 21 to serve as a
voting = member and have not received a confirmation email from me, = please
re-submit and bring to my attention right = away!

However, we need many more = volunteers.  You have until 17:00 PDT (24:00
UTC) = on July 8, 2010 to volunteer for nomcom but it is much better = if
you volunteer as early as possible.  The more = volunteers, the better
chance we have of choosing a = random yet representative cross section of
the = IETF
pouplation. =   

As a reminder, volunteers = must have attended 3 of the past 5 IETF
meetings - per = RFC 3777, which means 3 of the following = meetings:
IETF-73, IETF-74, IETF-75, IETF-76 and = IETF-77.  If you qualify, and are
willing to forgo = appointment to any of the positions for which = the
nominating committee is responsible, please = volunteer.  

The 10 nominating = committee members are selected randomly from a pool = of
volunteers.  The details of the operation of = nomcom may be found in RFC
3777.  The process on = how to volunteer for nomcom is in the = initial
announcement:  https://datatracker= .ietf.org/ann/nomcom/2330/

The = lists of open positions and people whose terms end in March 2011 = and
thus the positions for which the nominating = committee is responsible are
summarized in the initial = announcement:
https://datatracker= .ietf.org/ann/nomcom/2330/

The 29 = volunteers who have thus far been qualified by the = secretariat
are:

Fred = Baker, Cisco Systems

Stephan Wenger, = Vidyo, Inc.

Marc Blanchet, = Viagenie

Lixia Zhang, UCLA =

John Drake, Juniper = Networks

Ole Troan, = Cisco

Jiankang Yao, = CNNIC

Wassim Haddad, = Ericsson

Yi Zhao, Huawei = USA

Teemu Savolainen, = Nokia

Jouni Korhonen, Nokia Siemens = Networks

Mehmet Ersue, Nokia Siemens = Networks

Christian Schmidt, Nokia = Siemens Networks

Stephen Hanna, = Juniper Networks

Suresh Krishnan, = Ericsson

Eric Gray, = Ericsson

David Sinicrope, = Ericsson

Jan Melen, = Ericsson

Richard Barnes, BBN = Technologies

Hugo Salgado Hernandez, = NIC Chile

Ning Zong, Huawei = Technologies

Qin Wu, Huawei = Technologies

Karen Seo, BBN = Technologies

Haibin Song, Huawei = Technologies

Susan Hares, Huawei = Technologies

Tony Hansen. AT&T = Labs

Fuqing Huang, Huawei Technologies = Co., Ltd.

Huub van Helvoort, Huawei = Technologies

Miya Kohno, Juniper = Networks

The primary activity for this = nomcom will begin just prior to IETF-78 in
Maastricht = and should be completed in early January 2011.  The = nomcom
will be collecting requirements from the = community, as well as talking
to candidates and to = community members about candidates. There will be
weekly = conference calls to ensure progress. Thus, being a nomcom = member
does require some time commitment. =  

While, there is no requirement = in RFC 3777 that a participant attend
IETF meetings = while serving on nomcom, please consider that during = the
IETF meetings, people that do not attend would be = expected to remotely
participate during the day in the = time zones of the meeting locations -
Maastricht at the = end of July and Beijing in November. =

If you are not yet sure you would like = to volunteer, please consider
that nomcom members play a = very important role in shaping the leadership
of the = IETF.  Ensuring the leadership of the IETF is fair and = balanced
and comprised of those who can lead the IETF in = the right direction is
an important responsibility that = rests on the IETF participants = at
large.
Volunteering for the nomcom is = a good way of contributing in = that
direction.

Please = volunteer by sending an email before:
17:00 PDT (24:00 = UTC) July 8, 2010 as follows:

To: nomcom-chair@ietf.org=
Subject: Nomcom 2010-11 = Volunteer

Please include the following = information in the body:

<Your Full = Name>  // As you enter in the IETF Registration = Form,
=             &n= bsp;    // First/Given name followed by Last/Family = Name

<Current Primary = Affiliation>
=             &n= bsp;    // typically what goes in the Company = field
=             &n= bsp;    // in the IETF Registration Form =

[<all email addresses used to = Register for the past 5 IETF meetings>]
<Preferred = email address> =  //

<Telephone number> =         // For confirmation if = selected

Please expect an email = response from me within 3 days stating whether or
not = you are qualified.  If you don't receive a response, please = re-send
your email with the tag "Duplicate:" added to = the subject line.

Thank you and I hope = to hear from you,

Thomas = Walsh
Chair, Nomcom 2010-11
Email: nomcom-chair@ietf.org=


______________________________= _________________
IETF-Announce mailing = list
IETF-Announce@ietf.orghttps://www.i= etf.org/mailman/listinfo/ietf-announce

= --Apple-Mail-1-408289443-- From raszuk@cisco.com Tue Jun 22 00:21:03 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A042D3A6452 for ; Tue, 22 Jun 2010 00:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpymjMMI59on for ; Tue, 22 Jun 2010 00:20:38 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9A22B3A67C0 for ; Tue, 22 Jun 2010 00:20:38 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMIAIEyrR7Ht/2dsb2JhbACDHZtvcaVigXgLAYcgkTKBJYMGcAQ X-IronPort-AV: E=Sophos;i="4.53,459,1272844800"; d="scan'208";a="263188683" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 22 Jun 2010 07:17:24 +0000 Received: from [192.168.1.61] (sjc-raszuk-87113.cisco.com [10.20.147.254]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5M7HMM0001974; Tue, 22 Jun 2010 07:17:23 GMT Message-ID: <4C206381.9060703@cisco.com> Date: Tue, 22 Jun 2010 09:17:21 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Joel Jaeggli , morrowc.lists@gmail.com References: <4C2040EB.2040202@bogus.com> In-Reply-To: <4C2040EB.2040202@bogus.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 23 Jun 2010 08:51:17 -0700 Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] widely adopted communities presentation at nanog 49 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: raszuk@cisco.com List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 07:21:03 -0000 Hi Joel/Chris, Many thx for forwarding the pointer to opsec WG. I guess I need to subscribe now :) The up to date version can be found here: ftp://ftpeng.cisco.com/raszuk/bgp_wide_comms/ Based on the input received after Nanog to avoid any misinterpretations I have changed the semantics of the pre-defined communities from "well-known" to simply "registered". The point of defining them is not to enforce global support both by operators or by vendors, but simply to make it easier to apply commonly used policies intra and inter-domians. It is just to serve as an informational collection of community templates which could be used if fits in the contractual agreements. Another point is that subset of defined communities are AS specific - today communities are of common execution type. That means that AS specific communities would be executed only on the boundary to or by target AS specified in the community therefor passing those could be much less troublesome as compared with today's standard BGP communities. Feedback is welcome ! Many thx, R. > While I have some personal ambivialence to the idea of specifiying > well-known communities, I noted this presentation with some interest at > nanog and since the subject has been discussed here before I would drop > a pointer to the presentation. > > http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Raszuk-Wide_BGP_Communities_00_2.pdf > From joelja@bogus.com Mon Jun 28 22:04:09 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3F513A6887 for ; Mon, 28 Jun 2010 22:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psZGqxLJ9z1B for ; Mon, 28 Jun 2010 22:04:07 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 734203A687C for ; Mon, 28 Jun 2010 22:04:07 -0700 (PDT) Received: from [172.16.192.154] (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o5T54Cbf054435 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 29 Jun 2010 05:04:13 GMT (envelope-from joelja@bogus.com) Message-ID: <4C297ECB.5040402@bogus.com> Date: Mon, 28 Jun 2010 22:04:11 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Warren Kumari References: <4C2040EB.2040202@bogus.com> <49BFF6BC-2B09-451F-AA11-45C1AEE48178@kumari.net> In-Reply-To: <49BFF6BC-2B09-451F-AA11-45C1AEE48178@kumari.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Tue, 29 Jun 2010 05:04:14 +0000 (UTC) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] widely adopted communities presentation at nanog 49 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2010 05:04:09 -0000 On 2010-06-22 01:10, Warren Kumari wrote: > > On Jun 22, 2010, at 7:33 AM, Christopher Morrow wrote: > >> On Tue, Jun 22, 2010 at 12:49 AM, Joel Jaeggli wrote: >>> While I have some personal ambivialence to the idea of specifiying >>> well-known communities, I noted this presentation with some interest at >>> nanog and since the subject has been discussed here before I would drop >>> a pointer to the presentation. >>> >>> http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Raszuk-Wide_BGP_Communities_00_2.pdf >>> >> >> i vote, again, no 'well known communities' ... the guarantee that they >> exist and will be used as intended isn't currently working with >> no-export (as you stated at the mic I think). Having a contractually >> obligated set of communities (even if it's different per provider) >> with proscribed behaviours should be the target (which each customer >> should pursue). >> > > Keep in mind that I did not see the presentation, but I think that > having 'well-known' communities in the sense that the communities are > well known would be very useful, but 'well-known' with its current > meaning is not... > > It would be really useful if: > A: providers published their communities somewhere easily findable (and > didn't require NDAs and such for them...) > B: providers converged towards using the same communities -- If would be > great if I could only have to store 3-5 different numbers in my head for > what denotes a customer and not one per peer. I think there is a case to be made that what you end up with is a taxony of what communities are useful and which as a customer you expect to find without defining what actual community values are. > I think that this could / should be achieved by market pressure and not > though the IETF. > > Just my feelings on this, > > W > >> just one guy's opinion (I think). >> -chris >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >