From mjethanandani@gmail.com Tue May 1 08:46:53 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D922821E80EE for ; Tue, 1 May 2012 08:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEFTa51zOHNF for ; Tue, 1 May 2012 08:46:52 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D5A6C21E8064 for ; Tue, 1 May 2012 08:46:52 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so1810795pbc.31 for ; Tue, 01 May 2012 08:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=EmOsTE4bhto+wfxwkD3tH6yMjuTmImGYaSIBluo/ABo=; b=PzZ2OO6mdXwbXASl7I3AYKD+A24VcTg6zFShQn6r1Dbh7gyJuK3lnVmijgzXVY1vg3 4GCixMPc/mfVzavVY9+Cb47Dk701oW6j7YKxqC7snB6wAizH/gLEDNhxjtnz2+rmJj41 pnEtu/ruYpKPyBRa6FHIipYMFEAZocCJ1atAVBtDyLj/xBkzhShbhJ3UEILP4+6mvbxP g3PSzw7d3bZ8E9YPLhJMfeNq9wf4+Rs/BGwoW20jVilVRL3jAJLkvoZ8b9u1T6+3ciyf KhwrTpuz8eKPumHgAy4Oy36Uz/FA2m9gUK581pvz/LzQu5ExnGhkrn0gZsuCkgPDAP5r bVAA== Received: by 10.68.238.201 with SMTP id vm9mr6317441pbc.155.1335887212584; Tue, 01 May 2012 08:46:52 -0700 (PDT) Received: from [192.168.1.123] (c-24-6-173-225.hsd1.ca.comcast.net. [24.6.173.225]) by mx.google.com with ESMTPS id lb10sm4848540pbc.37.2012.05.01.08.46.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 May 2012 08:46:51 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-155--1049761226 From: Mahesh Jethanandani In-Reply-To: <4F71D131.1050704@isi.edu> Date: Tue, 1 May 2012 08:46:47 -0700 Message-Id: <079038F1-324D-4D87-9B12-7EE9FEBB0FC7@gmail.com> References: <20120326161516.27054.71100.idtracker@ietfa.amsl.com> <4F71D131.1050704@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1084) Cc: karp@ietf.org Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 15:46:54 -0000 --Apple-Mail-155--1049761226 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 27, 2012, at 7:39 AM, Joe Touch wrote: > Comments attached below. >=20 > Joe >=20 > On 3/26/2012 9:15 AM, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Keying and Authentication = for Routing Protocols Working Group of the IETF. >>=20 >> Title : Analysis of BGP, LDP, PCEP, and MSDP Security = According to KARP Design Guide >> Author(s) : Mahesh Jethanandani >> Keyur Patel >> Lianshu Zheng >> Filename : draft-ietf-karp-routing-tcp-analysis-01.txt >> Pages : 17 >> Date : 2012-03-26 >>=20 >> This document analyzes BGP, LDP, PCEP and MSDP according to >> guidelines set forth in section 4.2 of Keying and Authentication = for >> Routing Protocols Design Guidelines [RFC6518]. >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-karp-routing-tcp-analysis-0= 1.txt >=20 > ---- >=20 > - the document name and title are misleading If you do not like the title please suggest one. > - the document structure is misleading > in both cases, transport and network vulnerabilities are confused with = routing layer vulnerabilities; the doc should be very clear about what = layers are being analyzed at each step >=20 > - TCP MD5 is cited throughout and noted as weak, even though it is = obsoleted by TCP-AO. > This should be made clear for every routing protocol that still uses = TCP MD5 where that is mentioned, i.e., first that TCP MD5 is obsoleted, = and second that TCP-AO fixes the issues of note with TCP MD5 already. >=20 > - Sec 2.2 mentions reasons for not rekeying secure TCP connections > i.e., that they would generate a reset, but this is not the case for = TCP-AO, nor was it for TCP MD5. When a key is changed in TCP MD5, = segments using the old key would have been discarded (as having the = wrong key). TCP-AO allows for key overlap. If there is evidence of = resets being caused otherwise, a citation is needed. The reason may not be resets and we can take that mention out. However, = there is no well defined rekeying strategy either. Unless you count = sitting on the phone, making calls to all other parties at the same time = to change the keys. Operators will tell you that keys almost never get = changed. If this was not true, it would not be mentioned in the KARP = threats requirement document - section 4 item 7. >=20 > - Sec 2.3.1.2 suggests that TCP MD5 should be updated with SHA1 > This is incorrect; the appropriate recommendation is to shift to = TCP-AO, which includes SHA1 already. Accepted. Will update draft. >=20 > - Sec 4 discusses TCP's vulnerability to attack > This would be an appropriate place to cite RFC 4953 as explaining the = issues and problems. >=20 > The recommendations in RFC5961 are relevant ONLY where IPsec or TCP-AO = protections are not used, and RFC5961 mechanisms do not protect against = replay, spoofing, or other TCP attacks - only some RST attacks. This = section should make it very clear that the use of these techniques does = not replace the need for network or transport protection, nor are any of = its mechanisms needed when such protections are deployed. >=20 > This section also talks about TCP-AO key rollover; the mechanism for = rollover is defined in TCP-AO. What is missing is how the endpoints = decide when to rollover and when to stop using an old key. That remains = a key management issue. >=20 > Regarding connectionless resets, TCP-AO's Section 7.7 does address = this issue in detail, and makes three requirements assertions to address = that case. Storing of keys does not help even if that could be managed securely. = One needs ISN also. >=20 > The discussion of key rollover impact here is inappropriate; TCP-AO = already handles that case without resets - or even packet loss. >=20 > - Security considerations > This section makes recommendations that TCP-AO already covers (e.g., = key rollover without connection loss -- or even congestion window = impact, as well as replay protection). That should be noted. >=20 > ---- >=20 >=20 >=20 > - >=20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail-155--1049761226 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Comments attached below.

Joe

On = 3/26/2012 9:15 AM, internet-drafts@ietf.org = wrote:

A New Internet-Draft is available from the on-line = Internet-Drafts directories. This draft is a work item of the Keying and = Authentication for Routing Protocols Working Group of the = IETF.

Title =           : Analysis = of BGP, LDP, PCEP, and MSDP Security According to KARP Design = Guide
Author(s) =       : Mahesh = Jethanandani
=             &n= bsp;           &nbs= p; Keyur Patel
=             &n= bsp;           &nbs= p; Lianshu Zheng
Filename =        : = draft-ietf-karp-routing-tcp-analysis-01.txt
= Pages =           : = 17
Date =            : = 2012-03-26

=    This document analyzes BGP, LDP, PCEP and MSDP = according to
=    guidelines set forth in section 4.2 of Keying and = Authentication for
=    Routing Protocols Design Guidelines = [RFC6518].

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-karp-routing= -tcp-analysis-01.txt

----

- the document = name and title are misleading

If = you do not like the title please suggest one.

- the document structure is misleading
in both = cases, transport and network vulnerabilities are confused with routing = layer vulnerabilities; the doc should be very clear about what layers = are being analyzed at each step

- TCP MD5 is cited throughout and = noted as weak, even though it is obsoleted by TCP-AO.
This should be = made clear for every routing protocol that still uses TCP MD5 where that = is mentioned, i.e., first that TCP MD5 is obsoleted, and second that = TCP-AO fixes the issues of note with TCP MD5 already.

- Sec 2.2 = mentions reasons for not rekeying secure TCP connections
i.e., that = they would generate a reset, but this is not the case for TCP-AO, nor = was it for TCP MD5. When a key is changed in TCP MD5, segments using the = old key would have been discarded (as having the wrong key). TCP-AO = allows for key overlap. If there is evidence of resets being caused = otherwise, a citation is = needed.

The reason may not be = resets and we can take that mention out. However, there is no well = defined rekeying strategy either. Unless you count sitting on the phone, = making calls to all other parties at the same time to change the keys. = Operators will tell you that keys almost never get changed. If this was = not true, it would not be mentioned in the KARP threats requirement = document - section 4 item 7.


- Sec 2.3.1.2 suggests that TCP MD5 should be = updated with SHA1
This is incorrect; the appropriate recommendation = is to shift to TCP-AO, which includes SHA1 = already.

Accepted. Will update = draft.


- Sec 4 = discusses TCP's vulnerability to attack
This would be an appropriate = place to cite RFC 4953 as explaining the issues and problems.

The = recommendations in RFC5961 are relevant ONLY where IPsec or TCP-AO = protections are not used, and RFC5961 mechanisms do not protect against = replay, spoofing, or other TCP attacks - only some RST attacks. This = section should make it very clear that the use of these techniques does = not replace the need for network or transport protection, nor are any of = its mechanisms needed when such protections are deployed.

This = section also talks about TCP-AO key rollover; the mechanism for rollover = is defined in TCP-AO. What is missing is how the endpoints decide when = to rollover and when to stop using an old key. That remains a key = management issue.

Regarding connectionless resets, TCP-AO's = Section 7.7 does address this issue in detail, and makes three = requirements assertions to address that = case.

Storing of keys does not help even if = that could be managed securely. One needs ISN = also.


The = discussion of key rollover impact here is inappropriate; TCP-AO already = handles that case without resets - or even packet loss.

- = Security considerations
This section makes recommendations that = TCP-AO already covers (e.g., key rollover without connection loss -- or = even congestion window impact, as well as replay protection). That = should be = noted.

----



-

_______________________________= ________________
karp mailing list
karp@ietf.org
https://www.ietf.org/ma= ilman/listinfo/karp

Mahesh = Jethanandani
<= div>


= --Apple-Mail-155--1049761226-- From uma.chunduri@ericsson.com Tue May 1 15:16:41 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F4A11E8076 for ; Tue, 1 May 2012 15:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.357 X-Spam-Level: X-Spam-Status: No, score=-6.357 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQlj0BswOG2r for ; Tue, 1 May 2012 15:16:40 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8516B11E8072 for ; Tue, 1 May 2012 15:16:40 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q41MGc2b001625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 May 2012 17:16:39 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.6]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Tue, 1 May 2012 18:16:38 -0400 From: Uma Chunduri To: Mahesh Jethanandani , Joe Touch Date: Tue, 1 May 2012 18:16:36 -0400 Thread-Topic: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-01.txt Thread-Index: Ac0nsaun1QhFnuz4QPqzDGTWFEc1LwANUWHA Message-ID: References: <20120326161516.27054.71100.idtracker@ietfa.amsl.com> <4F71D131.1050704@isi.edu> <079038F1-324D-4D87-9B12-7EE9FEBB0FC7@gmail.com> In-Reply-To: <079038F1-324D-4D87-9B12-7EE9FEBB0FC7@gmail.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_D1D8138DDF34B34B8BC68A11262D10792242376970EUSAACMS0701e_" MIME-Version: 1.0 Cc: "karp@ietf.org" Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 22:16:41 -0000 --_000_D1D8138DDF34B34B8BC68A11262D10792242376970EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >> - Sec 2.2 mentions reasons for not rekeying secure TCP connections >> i.e., that they would generate a reset, but this is not the case for= TCP-AO, >> nor was it for TCP MD5. When a key is changed in TCP MD5, segments >> using the old key would have been discarded (as having the wrong key= ). TCP-AO >> allows for key overlap. If there is evidence of resets being caused = otherwise, a citation is needed. > The reason may not be resets and we can take that mention out. However,= there is no well defined rekeying strategy either. > Unless you count sitting on the phone, making calls to all other parties= at the same time to change the keys. [Uma]: With KMP support this is any way not the case. For the case you are = talking about, i.e., manual keying, with AO "same time" is not a requireme= nt as overlap is allowed. --_000_D1D8138DDF34B34B8BC68A11262D10792242376970EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
   >>  - Sec 2.2 mentions reasons f= or not=20 rekeying secure TCP connections 
   >>  i.e., that = they=20 would generate a reset, but this is not the case for TCP-AO,  
   >>  nor wa= s it for=20 TCP MD5. When a key is changed in TCP MD5, segments  
   >>  using the o= ld key=20 would have been discarded (as having the wrong key). TCP-AO  
   >>  allows for = key=20 overlap. If there is evidence of resets being caused otherwise, a citation = is=20 needed.

 >  The reason may not be resets an= d we=20 can take that mention out. However, there is no well defined rekeying strat= egy=20 either.  
 > Unless you count sitting on the = phone,=20 making calls to all other parties at the same time to change the=20 keys.  
[Uma]:=20 With KMP support this is any way not the case. For the case you are talking= =20 about, i.e.,  manual keying, with AO "same time" is not= a=20 requirement as overlap is allowed.
 
        =  

 
 
--_000_D1D8138DDF34B34B8BC68A11262D10792242376970EUSAACMS0701e_-- From touch@isi.edu Tue May 1 15:50:21 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FE421E8050 for ; Tue, 1 May 2012 15:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.621 X-Spam-Level: X-Spam-Status: No, score=-103.621 tagged_above=-999 required=5 tests=[AWL=-1.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PToPaclCV+3 for ; Tue, 1 May 2012 15:50:20 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD0E21E8042 for ; Tue, 1 May 2012 15:50:20 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q41MnhwN019380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 May 2012 15:49:43 -0700 (PDT) Message-ID: <4FA06887.3040604@isi.edu> Date: Tue, 01 May 2012 15:49:43 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Mahesh Jethanandani References: <20120326161516.27054.71100.idtracker@ietfa.amsl.com> <4F71D131.1050704@isi.edu> <079038F1-324D-4D87-9B12-7EE9FEBB0FC7@gmail.com> In-Reply-To: <079038F1-324D-4D87-9B12-7EE9FEBB0FC7@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: karp@ietf.org Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 22:50:21 -0000 Hi, Mahesh, On 5/1/2012 8:46 AM, Mahesh Jethanandani wrote: > > On Mar 27, 2012, at 7:39 AM, Joe Touch wrote: > >> Comments attached below. >> >> Joe >> >> On 3/26/2012 9:15 AM, internet-drafts@ietf.org >> wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Keying and >>> Authentication for Routing Protocols Working Group of the IETF. >>> >>> Title : Analysis of BGP, LDP, PCEP, and MSDP Security According to >>> KARP Design Guide >>> Author(s) : Mahesh Jethanandani >>> Keyur Patel >>> Lianshu Zheng >>> Filename : draft-ietf-karp-routing-tcp-analysis-01.txt >>> Pages : 17 >>> Date : 2012-03-26 >>> >>> This document analyzes BGP, LDP, PCEP and MSDP according to >>> guidelines set forth in section 4.2 of Keying and Authentication for >>> Routing Protocols Design Guidelines [RFC6518]. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-karp-routing-tcp-analysis-01.txt >> >> ---- >> >> - the document name and title are misleading > > If you do not like the title please suggest one. The document name isn't a big issue, and not worth the trouble to change. For the title, it is currently: Analysis of BGP, LDP, PCEP, and MSDP Security According to KARP Design Guide IMO, it should be something closer to: Analysis of Routing Protocol Communication Security Issues according to the KARP Design Guide or Analysis of Routing Transport Protocol Security Issues According to the KARP Design Guide (I think the second one is the most accurate, based on the document contents) ... >> - Sec 2.2 mentions reasons for not rekeying secure TCP connections >> i.e., that they would generate a reset, but this is not the case for >> TCP-AO, nor was it for TCP MD5. When a key is changed in TCP MD5, >> segments using the old key would have been discarded (as having the >> wrong key). TCP-AO allows for key overlap. If there is evidence of >> resets being caused otherwise, a citation is needed. > > The reason may not be resets and we can take that mention out. However, > there is no well defined rekeying strategy either. Unless you count > sitting on the phone, making calls to all other parties at the same time > to change the keys. That sort of tight synchronization isn't required for TCP-AO. You can simply add the new keys to each side as convenient, and as soon as they're both available they'll be used. The rekeying strategy isn't part of TCP-AO as a result. > Operators will tell you that keys almost never get > changed. There are two reasons: 1) the difficulty in deploying new keys, because of coordination required (which TCP-AO avoids) 2) the work of actually deploying the keys For TCP MD5, this assumed manual key exchange which is cumbersome. TCP-AO was designed to make it easier to support automated key exchange, but that key exchange protocol is not specific to TCP-AO. One is under development in KARP, though. I.e., the whole point of TCP-AO was to avoid TCP MD5's disincentives for rekeying. > If this was not true, it would not be mentioned in the KARP > threats requirement document - section 4 item 7. It is currently true, based on the current use of TCP MD5, but it might be useful to not discount TCP-AO on TCP MD5's grounds. ... >> - Sec 4 discusses TCP's vulnerability to attack >> This would be an appropriate place to cite RFC 4953 as explaining the >> issues and problems. >> >> The recommendations in RFC5961 are relevant ONLY where IPsec or TCP-AO >> protections are not used, and RFC5961 mechanisms do not protect >> against replay, spoofing, or other TCP attacks - only some RST >> attacks. This section should make it very clear that the use of these >> techniques does not replace the need for network or transport >> protection, nor are any of its mechanisms needed when such protections >> are deployed. >> >> This section also talks about TCP-AO key rollover; the mechanism for >> rollover is defined in TCP-AO. What is missing is how the endpoints >> decide when to rollover and when to stop using an old key. That >> remains a key management issue. >> >> Regarding connectionless resets, TCP-AO's Section 7.7 does address >> this issue in detail, and makes three requirements assertions to >> address that case. > > Storing of keys does not help even if that could be managed securely. > One needs ISN also. The traffic key already incorporates the ISN information, as per Figs 7 and 8 of TCP-AO. Joe From hartmans@mit.edu Tue May 8 11:17:36 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BBE21F8581 for ; Tue, 8 May 2012 11:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_00=-2.599, FUZZY_VLIUM=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1hsdhDZ8RTo for ; Tue, 8 May 2012 11:17:35 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6175B21F8569 for ; Tue, 8 May 2012 11:17:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6559D2023F; Tue, 8 May 2012 14:13:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 91D874769; Tue, 8 May 2012 14:17:29 -0400 (EDT) From: Sam Hartman To: Uma Chunduri References: Date: Tue, 08 May 2012 14:17:29 -0400 In-Reply-To: (Uma Chunduri's message of "Wed, 25 Apr 2012 13:08:54 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "karp@ietf.org" Subject: Re: [karp] Q's on karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 18:17:36 -0000 >>>>> "Uma" == Uma Chunduri writes: Uma> On Apr 24, 2012, at 5:26 PM, Uma Chunduri wrote: Dear All, Uma> I understand the spirit of the Uma> http://datatracker.ietf.org/doc/ Uma> draft-ietf-karp-crypto-key-table/?include_text=1 WG document. Uma> I saw the presentation on the same at IETF83, but still have Uma> the following specific questions and comments. Uma> Questions/Comments: --------------------------------- Uma> 1. Text in Abstract and Section-1 assumes this conceptual Uma> database if for security protocols such as TCP-AO with a Uma> following exception in Section-1 Uma> "In other instances, security protocols will Uma> directly use the long-lived key from the database." AFAICT, Uma> KARP is interested in security protocol TCP-AO to protect all Uma> TCP based pair wise routing protocols (BGP, LDP, MSDP, PCEP). Uma> I am interested to know what other security protocols relevant Uma> to KARP use long-lived keys. Almost all the group routing protocols use long-lived keys. OSPF, IS-IS, etc. I believe every routing protocol mentioned in our charter can take advantage of the key tables. Uma> 2. From the fields in conceptual Uma> database and the description it's very clear that this is a Uma> common table not only for security protocols like TCP-AO but Uma> also for routing protocols which use group keys (notably OSPF, Uma> ISIS etc..). But, a. For one set of routing protocols which Uma> use security protocols like TCP-AO, for E.g., 'interfaces' Uma> field is not relevant as key selection is not done per I could imagine a TCP-AO implementation that permitted interface to be considered in key selection, but I agree that this would be highly unusual. The next version will make it clear that the interfaces field may not be mandatory to support for all protocols. I'd expect that descriptions for binding the key tables to BGP/TCP-AO/etc would make it clear that interfaces will not typically be supported. Uma> Uma> interface level. Similarly for group keying routing protocols Uma> KDF, KDF inputs are not relevant. It's true that today's routing protocols do not use KDF. There's nothing inherent about that though. If I were designing authentication for a new protocol I would support a KDF. The KDF inputs field is going away. Uma> b. For lifetime there are 4 Uma> fields defined, which seems more relevant to OSPF. But this can Uma> be specified in seconds as well as number of bytes secured with Uma> that key. I don't see any requirement for routing protocols to Uma> specify key lifetime in terms of number of bytes secured and Uma> also don't see all routing protocols as well as security Uma> protocols use the same lifetime format either. This is something we discussed in the presentation. The hope here is to normalize things to something that is operationally easy. Like Joe, I don't think number of bytes is needed here. Uma> How else would one determine it is time for a key rollover? Uma> [Uma]: Just by one config option with lifetime in "secs". For Uma> all TCP based pair wise routing protocols which is IKEv2 this Uma> can be the best option. Key rollover decision made locally at Uma> either end with out necessarily having co-ordinated out of band Uma> config agreement for this. IKEv2 doesn't negotiate Uma> lifetimes. AO is capable of co-oridinated key changes with out Uma> impacting single TCP segment. By having the 4 fields in the Uma> keytable and enforcing in all types (sets) of routing protocols Uma> we may not utilizing the full potential of what security Uma> protocol and KMP we use for some RPs. I agree this needs to be considered. Uma> I am not worried about few extra fields which are Uma> relevant to one set of protocols and not at all relevant to Uma> other set. But, I am not sure why we have to club routing Uma> protocols which use group keying, use different transports (L2, Uma> L3, L4) and do security by themselves need to be clubbed with a Uma> security protocol like TCP-AO which is specifically designed to Uma> protect TCP based pair wise routing protocols (BGP, LDP etc..). The rationale is operators want to secure routing protocols. Conceptually an OSPF virtual link looks to an operator a lot like BGP in terms of security. so, the intent is to have one conceptual model for all the above. We're cleaning up many of the issues you describe and by the next version I don't think that it will feel forced. Uma> Section-3 specifies Key Selection and as mentioned earlier this Uma> is not applicable to security protocols like TCP-AO as key Uma> selection happens by consulting it's internal tables. How ever, Uma> a routing protocol which secures it's routing packet by itself Uma> can consult this table. This will be dealt with. Uma> In summary- IMO, as we have various types of routing Uma> protocols it's better to define conceptual key table specific Uma> to that set. Set1: BGP, LDP, PCEP, and MSDP (Pair wise TCP Uma> based which use security protocol like TCP-AO) Set 2: OSPF, Uma> IS-IS, RIP (group keying, different transports and security is Uma> provided by themselves) - OSPFv3 ( Originally defined with Uma> IPSec based on the new draft/RFC it?s similar to OSPFv2) - Uma> RSVP-TE (I would say still come under group key category) Set3: Uma> Multicast routing protocols like PIM -- Uma C. I strongly believe that a single conceptual table will serve us well in terms of making a set of specifications that are easy to deploy and use in the real world. From hartmans@mit.edu Tue May 8 11:35:00 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9BA21F8573 for ; Tue, 8 May 2012 11:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.887 X-Spam-Level: X-Spam-Status: No, score=-102.887 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNUumqsC-G5y for ; Tue, 8 May 2012 11:35:00 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 02EF821F8532 for ; Tue, 8 May 2012 11:34:59 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5E6D42023F; Tue, 8 May 2012 14:30:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5ECBA4769; Tue, 8 May 2012 14:34:54 -0400 (EDT) From: Sam Hartman To: Joe Touch References: <20120326161516.27054.71100.idtracker@ietfa.amsl.com> <4F71D131.1050704@isi.edu> <079038F1-324D-4D87-9B12-7EE9FEBB0FC7@gmail.com> <4FA06887.3040604@isi.edu> Date: Tue, 08 May 2012 14:34:54 -0400 In-Reply-To: <4FA06887.3040604@isi.edu> (Joe Touch's message of "Tue, 01 May 2012 15:49:43 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: karp@ietf.org Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 18:35:00 -0000 I strongly prefer that the title include the names of the protocols being analyzed. I'm not sure I agree with Joe that it is desirable to separate out transport/network layer issues from routing protocol issues. It's the system as a whole that we want to analyze and secure, so I'd prefer the document set out to do that and succeed. From touch@isi.edu Tue May 8 12:14:08 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCD021F85E6 for ; Tue, 8 May 2012 12:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.497 X-Spam-Level: X-Spam-Status: No, score=-103.497 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je9uvFj6Ljhe for ; Tue, 8 May 2012 12:14:08 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5DA21F85CE for ; Tue, 8 May 2012 12:14:08 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q48JDRNC011292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 May 2012 12:13:28 -0700 (PDT) Message-ID: <4FA97057.1050306@isi.edu> Date: Tue, 08 May 2012 12:13:27 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sam Hartman References: <20120326161516.27054.71100.idtracker@ietfa.amsl.com> <4F71D131.1050704@isi.edu> <079038F1-324D-4D87-9B12-7EE9FEBB0FC7@gmail.com> <4FA06887.3040604@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: karp@ietf.org Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 19:14:09 -0000 On 5/8/2012 11:34 AM, Sam Hartman wrote: > I strongly prefer that the title include the names of the protocols > being analyzed. I'm not sure I agree with Joe that it is desirable to > separate out transport/network layer issues from routing protocol > issues. It's the system as a whole that we want to analyze and secure, > so I'd prefer the document set out to do that and succeed. That's fine, but that's not what the document currently represents. Joe From hartmans@mit.edu Tue May 8 12:27:13 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C3621F8483 for ; Tue, 8 May 2012 12:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.868 X-Spam-Level: X-Spam-Status: No, score=-102.868 tagged_above=-999 required=5 tests=[AWL=-0.603, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO2K71bLESwg for ; Tue, 8 May 2012 12:27:13 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB0021F846F for ; Tue, 8 May 2012 12:27:13 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A8FF4201CB; Tue, 8 May 2012 15:23:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 595964769; Tue, 8 May 2012 15:27:07 -0400 (EDT) From: Sam Hartman To: Joe Touch References: <20120326161516.27054.71100.idtracker@ietfa.amsl.com> <4F71D131.1050704@isi.edu> <079038F1-324D-4D87-9B12-7EE9FEBB0FC7@gmail.com> <4FA06887.3040604@isi.edu> <4FA97057.1050306@isi.edu> Date: Tue, 08 May 2012 15:27:07 -0400 In-Reply-To: <4FA97057.1050306@isi.edu> (Joe Touch's message of "Tue, 08 May 2012 12:13:27 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 19:27:13 -0000 >>>>> "Joe" == Joe Touch writes: Joe> On 5/8/2012 11:34 AM, Sam Hartman wrote: >> I strongly prefer that the title include the names of the >> protocols being analyzed. I'm not sure I agree with Joe that it >> is desirable to separate out transport/network layer issues from >> routing protocol issues. It's the system as a whole that we want >> to analyze and secure, so I'd prefer the document set out to do >> that and succeed. Joe> That's fine, but that's not what the document currently Joe> represents. Understood. I tended to agree with your other comments and believe the document needs some work. I'd just like to get all the way to the sort of analysis the design guide contemplates for routing protocols rather than stopping at the transport issues. From touch@isi.edu Tue May 8 12:31:02 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1E421F84EA for ; Tue, 8 May 2012 12:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.475 X-Spam-Level: X-Spam-Status: No, score=-103.475 tagged_above=-999 required=5 tests=[AWL=-0.876, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efcxVh10yJFb for ; Tue, 8 May 2012 12:31:01 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id C692721F84E4 for ; Tue, 8 May 2012 12:31:01 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q48JUUjx016934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 May 2012 12:30:30 -0700 (PDT) Message-ID: <4FA97456.2080902@isi.edu> Date: Tue, 08 May 2012 12:30:30 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sam Hartman References: <20120326161516.27054.71100.idtracker@ietfa.amsl.com> <4F71D131.1050704@isi.edu> <079038F1-324D-4D87-9B12-7EE9FEBB0FC7@gmail.com> <4FA06887.3040604@isi.edu> <4FA97057.1050306@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: karp@ietf.org Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 19:31:02 -0000 On 5/8/2012 12:27 PM, Sam Hartman wrote: >>>>>> "Joe" == Joe Touch writes: > > Joe> On 5/8/2012 11:34 AM, Sam Hartman wrote: > >> I strongly prefer that the title include the names of the > >> protocols being analyzed. I'm not sure I agree with Joe that it > >> is desirable to separate out transport/network layer issues from > >> routing protocol issues. It's the system as a whole that we want > >> to analyze and secure, so I'd prefer the document set out to do > >> that and succeed. > > Joe> That's fine, but that's not what the document currently > Joe> represents. > > Understood. I tended to agree with your other comments and believe the > document needs some work. I'd just like to get all the way to the sort > of analysis the design guide contemplates for routing protocols rather > than stopping at the transport issues. Sure - should that be in the same doc, though? I thought this doc was specific to securing the message exchanges, not the messages themselves. Joe From hartmans@mit.edu Tue May 8 12:58:58 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288E421F8453 for ; Tue, 8 May 2012 12:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=-0.885, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDGWjt7Ofatm for ; Tue, 8 May 2012 12:58:57 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id B605A21F844F for ; Tue, 8 May 2012 12:58:57 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 13FF22023F; Tue, 8 May 2012 15:54:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E88E64769; Tue, 8 May 2012 15:58:51 -0400 (EDT) From: Sam Hartman To: Joe Touch References: <20120326161516.27054.71100.idtracker@ietfa.amsl.com> <4F71D131.1050704@isi.edu> <079038F1-324D-4D87-9B12-7EE9FEBB0FC7@gmail.com> <4FA06887.3040604@isi.edu> <4FA97057.1050306@isi.edu> <4FA97456.2080902@isi.edu> Date: Tue, 08 May 2012 15:58:51 -0400 In-Reply-To: <4FA97456.2080902@isi.edu> (Joe Touch's message of "Tue, 08 May 2012 12:30:30 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 19:58:58 -0000 >>>>> "Joe" == Joe Touch writes: >> >> Understood. I tended to agree with your other comments and >> believe the document needs some work. I'd just like to get all >> the way to the sort of analysis the design guide contemplates for >> routing protocols rather than stopping at the transport issues. Joe> Sure - should that be in the same doc, though? I thought this Joe> doc was specific to securing the message exchanges, not the Joe> messages themselves. Ok, my assumption here is that there's fairly little to do beyond securing the transport for these protocols. I do think the analysis needs to be comprehensive enough to understand the protocol level issues. As an example, if TCP-AO didn't protect against resets, the analysis would need to cover how a higher laye.r session resume feature was used to avoid serious DOS issues or something like that. However my assumption is that for the protocols in question that there will be few such issues. If that turns out not to be the case, then we should consider splitting documents. From touch@isi.edu Tue May 8 13:05:13 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B439E800A for ; Tue, 8 May 2012 13:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.155 X-Spam-Level: X-Spam-Status: No, score=-105.155 tagged_above=-999 required=5 tests=[AWL=0.844, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l8KMfWwTsEvT for ; Tue, 8 May 2012 13:05:13 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id E35429E8009 for ; Tue, 8 May 2012 13:05:12 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q48K4YRt010986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 May 2012 13:04:34 -0700 (PDT) Message-ID: <4FA97C51.7020908@isi.edu> Date: Tue, 08 May 2012 13:04:33 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sam Hartman References: <20120326161516.27054.71100.idtracker@ietfa.amsl.com> <4F71D131.1050704@isi.edu> <079038F1-324D-4D87-9B12-7EE9FEBB0FC7@gmail.com> <4FA06887.3040604@isi.edu> <4FA97057.1050306@isi.edu> <4FA97456.2080902@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: karp@ietf.org Subject: Re: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-01.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:05:13 -0000 On 5/8/2012 12:58 PM, Sam Hartman wrote: >>>>>> "Joe" == Joe Touch writes: > > >> > >> Understood. I tended to agree with your other comments and > >> believe the document needs some work. I'd just like to get all > >> the way to the sort of analysis the design guide contemplates for > >> routing protocols rather than stopping at the transport issues. > > Joe> Sure - should that be in the same doc, though? I thought this > Joe> doc was specific to securing the message exchanges, not the > Joe> messages themselves. > > Ok, my assumption here is that there's fairly little to do beyond > securing the transport for these protocols. Sure, but the devil - and most of this doc, AFAICT - is in the details of how to do that. > I do think the analysis > needs to be comprehensive enough to understand the protocol level > issues. As an example, if TCP-AO didn't protect against resets, the > analysis would need to cover how a higher laye.r session resume feature > was used to avoid serious DOS issues or something like that. > However my assumption is that for the protocols in question that there > will be few such issues. The current doc suggests there's more than enough for one doc on just those issues - which protocols to use, how to use them, etc. > If that turns out not to be the case, then we should consider splitting > documents. See above; I'm not sure there's much other than this in the current doc, IMO. That's the reason I wanted the title to reflect the contents. Joe From touch@isi.edu Tue May 8 13:07:59 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D689E8008 for ; Tue, 8 May 2012 13:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.474 X-Spam-Level: X-Spam-Status: No, score=-105.474 tagged_above=-999 required=5 tests=[AWL=1.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW3xo5NkQLjv for ; Tue, 8 May 2012 13:07:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 785DC9E8004 for ; Tue, 8 May 2012 13:07:58 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q48K7QZn011355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 May 2012 13:07:26 -0700 (PDT) Message-ID: <4FA97CFD.7060204@isi.edu> Date: Tue, 08 May 2012 13:07:25 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "karp@ietf.org" Subject: Re: [karp] Q's on karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:07:59 -0000 Hi, Sam (et al.), Cutting down to the interfaces point, one comment below. On 5/8/2012 11:17 AM, Sam Hartman wrote: >>>>>> "Uma" == Uma Chunduri writes: > > Uma> On Apr 24, 2012, at 5:26 PM, Uma Chunduri wrote: .. > > Uma> 2. From the fields in conceptual > Uma> database and the description it's very clear that this is a > Uma> common table not only for security protocols like TCP-AO but > Uma> also for routing protocols which use group keys (notably OSPF, > Uma> ISIS etc..). But, a. For one set of routing protocols which > Uma> use security protocols like TCP-AO, for E.g., 'interfaces' > Uma> field is not relevant as key selection is not done per > > I could imagine a TCP-AO implementation that permitted interface to be > considered in key selection, but I agree that this would be highly > unusual. TCP-AO uses the IP address in determining which key to use. That address could belong to multiple interfaces, and if it does I would assume the same key would be used. FWIW. Joe From hartmans@mit.edu Tue May 8 13:21:28 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6E521F8463 for ; Tue, 8 May 2012 13:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.825 X-Spam-Level: X-Spam-Status: No, score=-102.825 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNkHuEviLDii for ; Tue, 8 May 2012 13:21:27 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id ECFBF21F846E for ; Tue, 8 May 2012 13:21:25 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 44ED12023F; Tue, 8 May 2012 16:17:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1BADB4769; Tue, 8 May 2012 16:21:20 -0400 (EDT) From: Sam Hartman To: Joe Touch References: <4FA97CFD.7060204@isi.edu> Date: Tue, 08 May 2012 16:21:20 -0400 In-Reply-To: <4FA97CFD.7060204@isi.edu> (Joe Touch's message of "Tue, 08 May 2012 13:07:25 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] Q's on karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:21:28 -0000 >>>>> "Joe" == Joe Touch writes: Or that the routing protocol would choose a specific interface when setting up a socket (several platforms support this), etc. I think it's safe to say that we should not standardize interface restrictions for TCP-AO. From touch@isi.edu Tue May 8 13:25:35 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1FE9E8007 for ; Tue, 8 May 2012 13:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.499 X-Spam-Level: X-Spam-Status: No, score=-105.499 tagged_above=-999 required=5 tests=[AWL=1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk7C5uvZkVry for ; Tue, 8 May 2012 13:25:35 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFB19E8006 for ; Tue, 8 May 2012 13:25:35 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q48KPEnJ013884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 May 2012 13:25:14 -0700 (PDT) Message-ID: <4FA9812A.7080707@isi.edu> Date: Tue, 08 May 2012 13:25:14 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sam Hartman References: <4FA97CFD.7060204@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "karp@ietf.org" Subject: Re: [karp] Q's on karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:25:35 -0000 On 5/8/2012 1:21 PM, Sam Hartman wrote: >>>>>> "Joe" == Joe Touch writes: > > Or that the routing protocol would choose a specific interface when > setting up a socket (several platforms support this), etc. > I think it's safe to say that we should not standardize interface > restrictions for TCP-AO. There's no restriction, but TCP-AO doesn't understand using a key specific to an interface unless it's specific to an IP address - and an IP address isn't *necessarily* limited to a single interface. Joe From hartmans@mit.edu Tue May 8 13:36:37 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34279E800C for ; Tue, 8 May 2012 13:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.809 X-Spam-Level: X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=-0.544, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wILbTXdqeZQJ for ; Tue, 8 May 2012 13:36:37 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6874B9E800B for ; Tue, 8 May 2012 13:36:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id ABB772023F for ; Tue, 8 May 2012 16:32:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 936FB4769; Tue, 8 May 2012 16:36:31 -0400 (EDT) From: Sam Hartman To: karp@ietf.org Date: Tue, 08 May 2012 16:36:31 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [karp] Only two lifetimes? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:36:37 -0000 So, at the last KARP meeting we talked about whether to simplify management models or wether to implement everything that could be used by a protocol. Between version 01 and 02 of the key tables draft, the NotBefore and NotAfter fields were expanded to {Send|Receive}Not{Before|After}. Yes, some routing protocols have this flexibility. however it doesn't seem necessary. Why is a key that is inappropriate for verifying packets in the key table at all? Why not go back to the 01 model and have only two times? We can also provide a way to mark a key disabled by setting its direction to disabled rather than in/out/both. I believe this will provide the flexibility people actually use while simplifying configuration somewhat. --Sam From uma.chunduri@ericsson.com Tue May 8 13:50:00 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB211F0C65 for ; Tue, 8 May 2012 13:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.097 X-Spam-Level: X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, FUZZY_VLIUM=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2v+qMdllYhWd for ; Tue, 8 May 2012 13:50:00 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id E7CE71F0C62 for ; Tue, 8 May 2012 13:49:59 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q48Knl9Y022666; Tue, 8 May 2012 15:49:58 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.6]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 8 May 2012 16:49:43 -0400 From: Uma Chunduri To: Sam Hartman Date: Tue, 8 May 2012 16:49:42 -0400 Thread-Topic: [karp] Q's on karp-crypto-tables Thread-Index: Ac0tRtxP9uPUP1IISvyMcJgJ7CGoIwADoWvw Message-ID: References: In-Reply-To: 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 Cc: "karp@ietf.org" Subject: Re: [karp] Q's on karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:50:00 -0000 In-line [Uma]=20 --=20 Uma C.=20 =20 Uma> "In other instances, security protocols will Uma> directly use the long-lived key from the database." AFAICT, Uma> KARP is interested in security protocol TCP-AO to protect all Uma> TCP based pair wise routing protocols (BGP, LDP, MSDP, PCEP). Uma> I am interested to know what other security protocols relevant Uma> to KARP use long-lived keys. =20 Almost all the group routing protocols use long-lived keys. OSPF, IS-IS, etc. I believe every routing protocol mentioned in our charter can take advantag= e of the key tables. [Uma]: Actually that is the problem I have. You didn't answer my question.= =20 My Q was specifically on security protocols not routing protocols as= section 1 says. If you read the introduction you get the feeling this is mostly designed for RPs which use TCP-AO= but as we know this is not true. Make distinction between RPs seeking security through security proto= cols and RPs doing security by themselves. --- Uma> Uma> interface level. Similarly for group keying routing prot= ocols Uma> KDF, KDF inputs are not relevant. =20 It's true that today's routing protocols do not use KDF. There's nothing inherent about that though. If I were designing authentication for a new protocol I would support a KDF= . The KDF inputs field is going away. [Uma]: I am not sure this justification warrants KDF to be in the table and= to be (not) applicable to all existing=20 group keying protocols. Uma> b. For lifetime there are 4 Uma> fields defined, which seems more relevant to OSPF. But this can Uma> be specified in seconds as well as number of bytes secured with Uma> that key. I don't see any requirement for routing protocols to Uma> specify key lifetime in terms of number of bytes secured and Uma> also don't see all routing protocols as well as security Uma> protocols use the same lifetime format either. This is something we discussed in the presentation. The hope here is to normalize things to something that is operationally eas= y. Like Joe, I don't think number of bytes is needed here. [Uma]: I didn't say it's needed either. Uma> How else would one determine it is time for a key rollover? Uma> [Uma]: Just by one config option with lifetime in "secs". For Uma> all TCP based pair wise routing protocols which is IKEv2 this Uma> can be the best option. Key rollover decision made locally at Uma> either end with out necessarily having co-ordinated out of band Uma> config agreement for this. IKEv2 doesn't negotiate Uma> lifetimes. AO is capable of co-oridinated key changes with out Uma> impacting single TCP segment. By having the 4 fields in the Uma> keytable and enforcing in all types (sets) of routing protocols Uma> we may not utilizing the full potential of what security Uma> protocol and KMP we use for some RPs. I agree this needs to be considered. [Uma]: This is one good example where separate tables can really help assoc= iating the=20 tables fields for what RP is doing/not doing. =20 Uma> I am not worried about few extra fields which are Uma> relevant to one set of protocols and not at all relevant to Uma> other set. But, I am not sure why we have to club routing Uma> protocols which use group keying, use different transports (L2, Uma> L3, L4) and do security by themselves need to be clubbed with a Uma> security protocol like TCP-AO which is specifically designed to Uma> protect TCP based pair wise routing protocols (BGP, LDP etc..). The rationale is operators want to secure routing protocols. Conceptually an OSPF virtual link looks to an operator a lot like BGP in te= rms of security. so, the intent is to have one conceptual model for all the above. We're cleaning up many of the issues you describe and by the next version I= don't think that it will feel forced. [Uma]: OSPF virtual link case justifies a bigger group for group keying cas= e. But I don't see any parallels to BGP in terms of=20 security requirements. I am not convinced this is the reason to have= single table for all RPs. =20 Uma> In summary- IMO, as we have various types of routing Uma> protocols it's better to define conceptual key table specific Uma> to that set. Set1: BGP, LDP, PCEP, and MSDP (Pair wise TCP Uma> based which use security protocol like TCP-AO) Set 2: OSPF, Uma> IS-IS, RIP (group keying, different transports and security is Uma> provided by themselves) - OSPFv3 ( Originally defined with Uma> IPSec based on the new draft/RFC it?s similar to OSPFv2) - Uma> RSVP-TE (I would say still come under group key category) Set3: Uma> Multicast routing protocols like PIM -- Uma C. I strongly believe that a single conceptual table will serve us well in ter= ms of making a set of specifications that are easy to deploy and use in the= real world. [Uma]: I won't insist on this separation one more time, if authors still fe= el it's better to have one table only. I specified reasons (how one relates and adopts key table much easie= r) and why it is better to separate=20 the tables but I yet to hear convincing answers on why it has to be = in the same table. As an example,=20 you can see the questions asked on crypto tables earlier from IGP si= de and how some fields which are=20 not relevant to IGPs created more confusion overall.=20 To summarize again why separate tables are better for RP set: 1. to refer key tables or not while securing the packets/PDUs 2. to differentiate RPs using security protocols and RPs use various tran= sports and doing security by themselves 3. to differentiate pair-wise and group keying RPs (the requirement would= be completely different) 4. to relate and adopt key tables easily by RP But overall, I see agreement on couple of key points and would like to se= e the new version of this document. From housley@vigilsec.com Tue May 8 13:53:03 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80A921F84D6 for ; Tue, 8 May 2012 13:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAerLx96JOXX for ; Tue, 8 May 2012 13:53:03 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE3D21F84D3 for ; Tue, 8 May 2012 13:53:03 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 19A099A4738; Tue, 8 May 2012 16:53:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id P1p5wjcoJ-JO; Tue, 8 May 2012 16:52:55 -0400 (EDT) Received: from [172.16.41.237] (unknown [38.100.136.98]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 429809A4728; Tue, 8 May 2012 16:53:13 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Russ Housley In-Reply-To: Date: Tue, 8 May 2012 16:52:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: karp@ietf.org Subject: Re: [karp] Only two lifetimes? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:53:03 -0000 We got a request for this structure because (as you point out) some = routing protocols have this flexibility. The person making the request = wanted to support this flexibility. Russ On May 8, 2012, at 4:36 PM, Sam Hartman wrote: > So, at the last KARP meeting we talked about whether to simplify > management models or wether to implement everything that could be used > by a protocol. >=20 > Between version 01 and 02 of the key tables draft, the NotBefore and > NotAfter fields were expanded to {Send|Receive}Not{Before|After}.=20 >=20 > Yes, some routing protocols have this flexibility. >=20 > however it doesn't seem necessary. > Why is a key that is inappropriate for verifying packets in the key > table at all? Why not go back to the 01 model and have only two times? > We can also provide a way to mark a key disabled by setting its > direction to disabled rather than in/out/both. >=20 > I believe this will provide the flexibility people actually use while > simplifying configuration somewhat. >=20 > --Sam From hartmans@mit.edu Tue May 8 13:54:00 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FBE21F84D6 for ; Tue, 8 May 2012 13:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.795 X-Spam-Level: X-Spam-Status: No, score=-102.795 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23PVPAvFJrG4 for ; Tue, 8 May 2012 13:53:59 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id B246D21F84D3 for ; Tue, 8 May 2012 13:53:59 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 13E2D2023F; Tue, 8 May 2012 16:49:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D6C0B4769; Tue, 8 May 2012 16:53:53 -0400 (EDT) From: Sam Hartman To: Joe Touch References: <4FA97CFD.7060204@isi.edu> <4FA9812A.7080707@isi.edu> Date: Tue, 08 May 2012 16:53:53 -0400 In-Reply-To: <4FA9812A.7080707@isi.edu> (Joe Touch's message of "Tue, 08 May 2012 13:25:14 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , "karp@ietf.org" Subject: Re: [karp] Q's on karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:54:00 -0000 >>>>> "Joe" == Joe Touch writes: Joe> On 5/8/2012 1:21 PM, Sam Hartman wrote: >>>>>>> "Joe" == Joe Touch writes: >> >> Or that the routing protocol would choose a specific interface >> when setting up a socket (several platforms support this), etc. >> I think it's safe to say that we should not standardize interface >> restrictions for TCP-AO. Joe> There's no restriction, but TCP-AO doesn't understand using a Joe> key specific to an interface unless it's specific to an IP Joe> address - and an IP address isn't *necessarily* limited to a Joe> single interface. There is a restriction: the interface column in the key table is a restriction on the scope of a key. I'm arguing that we should not require that routing protocols on top of TCP-AO support that restriction, nor worry about the specific semantics if an implementation should go ahead and implement that restriction for an AO-secured routing protocol. I can think of implementation strategies if you really wanted to implement that interface restriction, but my preferred strategy is to suggest that for AO, you restrict the scope of keys using peer identifiers (IP addresses). My goal is to align the next version of the key tables draft with this. From touch@isi.edu Tue May 8 13:59:54 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78C221F84D1 for ; Tue, 8 May 2012 13:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.523 X-Spam-Level: X-Spam-Status: No, score=-103.523 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZyPRxsD2S7j for ; Tue, 8 May 2012 13:59:54 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4B75A21F8473 for ; Tue, 8 May 2012 13:59:54 -0700 (PDT) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q48KxCsA000500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 May 2012 13:59:12 -0700 (PDT) Message-ID: <4FA9891F.1000403@isi.edu> Date: Tue, 08 May 2012 13:59:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sam Hartman References: <4FA97CFD.7060204@isi.edu> <4FA9812A.7080707@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "karp@ietf.org" Subject: Re: [karp] Q's on karp-crypto-tables X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:59:54 -0000 On 5/8/2012 1:53 PM, Sam Hartman wrote: >>>>>> "Joe" == Joe Touch writes: > > Joe> On 5/8/2012 1:21 PM, Sam Hartman wrote: > >>>>>>> "Joe" == Joe Touch writes: > >> > >> Or that the routing protocol would choose a specific interface > >> when setting up a socket (several platforms support this), etc. > >> I think it's safe to say that we should not standardize interface > >> restrictions for TCP-AO. > > Joe> There's no restriction, but TCP-AO doesn't understand using a > Joe> key specific to an interface unless it's specific to an IP > Joe> address - and an IP address isn't *necessarily* limited to a > Joe> single interface. > > There is a restriction: the interface column in the key table is a > restriction on the scope of a key. I'm arguing that we should not > require that routing protocols on top of TCP-AO support that > restriction, nor worry about the specific semantics if an implementation > should go ahead and implement that restriction for an AO-secured routing > protocol. I can think of implementation strategies if you really wanted > to implement that interface restriction, but my preferred strategy is to > suggest that for AO, you restrict the scope of keys using peer > identifiers (IP addresses). My goal is to align the next version of the > key tables draft with this. AOK. That makes sense. Joe From hartmans@mit.edu Tue May 8 14:41:52 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7636611E8074 for ; Tue, 8 May 2012 14:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=-0.516, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MkY24S8ESiu for ; Tue, 8 May 2012 14:41:52 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0F32B11E8072 for ; Tue, 8 May 2012 14:41:51 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0021F201CB; Tue, 8 May 2012 17:37:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 367CA4769; Tue, 8 May 2012 17:41:45 -0400 (EDT) From: Sam Hartman To: Russ Housley References: Date: Tue, 08 May 2012 17:41:45 -0400 In-Reply-To: (Russ Housley's message of "Tue, 8 May 2012 16:52:56 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] Only two lifetimes? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 21:41:52 -0000 >>>>> "Russ" == Russ Housley writes: Russ> We got a request for this structure because (as you point out) Russ> some routing protocols have this flexibility. The person Russ> making the request wanted to support this flexibility. Russ Right. I'm asking the WG to push back on that request and/or for the person making the request to come forward with a more complete justification than existing protocols support this. From gregory.ietf@gmail.com Thu May 10 08:02:57 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D2C21F862A for ; Thu, 10 May 2012 08:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QrdACrrKi3F for ; Thu, 10 May 2012 08:02:52 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB5FF21F85BB for ; Thu, 10 May 2012 08:02:52 -0700 (PDT) Received: by dacx6 with SMTP id x6so1936142dac.31 for ; Thu, 10 May 2012 08:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=72BiyMoo0o/lMsLaYwGvLhd9RnjbDelhTZlYzNf82+I=; b=Ig0gquDPOmxXsIvf5YxzlRn7MiXhbQTLdyfLcSmGUCKqFVHYucffeoK6lLaeFnEJ6n mOHzVYVshjnvCiDkS2w5h3DObNgp+oJWh0fCPcJ7x9+Ye2bxqMsxNtENaVC2OMeELkPv ZdW3M6SKOckWnnVA6t+cEgq5dWOgFtMrGiH0sHjB33bXlNspcwBXeIhv/dfJGLBQQxUq 6y/PV8iPBbwbDbqBc2CdZaw+pN/98XsSj/W7EOOgJBzmkswPJ05bHKeuZzDCID6qaxjm 0dhlD3EtXqk8w4fR+qLXpVAkRX93kZeG2s27CylKn3hotzl4g7IIlo+rH6TnVH/BkzVt OGHA== MIME-Version: 1.0 Received: by 10.68.221.39 with SMTP id qb7mr21016595pbc.120.1336662169575; Thu, 10 May 2012 08:02:49 -0700 (PDT) Received: by 10.143.67.2 with HTTP; Thu, 10 May 2012 08:02:49 -0700 (PDT) In-Reply-To: <66F1DE8F-0B63-4832-8B4C-FECC066A0BE3@cisco.com> References: <66F1DE8F-0B63-4832-8B4C-FECC066A0BE3@cisco.com> Date: Thu, 10 May 2012 08:02:49 -0700 Message-ID: From: Gregory Lebovitz To: Brian Weis Content-Type: multipart/alternative; boundary=e89a8ff25688cd5fd904bfafe943 Cc: karp@ietf.org Subject: Re: [karp] Requirement 22 of draft-ietf-karp-threats-reqs-04 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 15:02:57 -0000 --e89a8ff25688cd5fd904bfafe943 Content-Type: text/plain; charset=ISO-8859-1 The resolution for Brian's comment below is to replace the 2nd paragraph with the following: *If authentication and security mechanisms rely on systems* * external to the routing system, then there MUST be one or more options available to avoid circular dependencies. It is not acceptable to have a routing protocol (e.g., unicast routing) depend upon correct operation of a security protocol that, in turn, depends upon correct operation of the same instance of that routing protocol (i.e., the unicast routing). However, it is okay to have operation of a routing protocol (e.g., multicast routing) depend upon operation of a security protocol, which depends upon an independent routing protocol (e.g., unicast routing). Similarly it would be okay to have the operation of a routing protocol depend upon a security protocol, which in turn uses an out of band network to exchange information with remote systems.* * * *This will be placed into the soon to be issued -05.* * * *Gregory (and Manav & Brian)* On Fri, Apr 6, 2012 at 3:58 PM, Brian Weis wrote: > (Speaking as a WG member.) > > A second paragraph was added in this version to Requirement 22. While it's > a valiant effort to try to give examples where a circular dependency does > and does not exist, both examples are convoluted. Understanding the nuances > of the examples, and whether or not in all cases of each example that the > bad one is bad and the good one is good, is laborious. Also it's also not > clear to me that the added MUST is necessary. Wouldn't it be sufficient to > add this as one reason for the dire warnings already communicated in the > previous paragraph? > > I would suggest removing this paragraph completely, and adding something > like the following sentence before the last sentence in the previous > paragraph: "Relying on external systems may result in a circular dependency > between routing and the security mechanisms such that routing cannot be > started." > > Brian > > -- > Brian Weis > Security Standards and Technology, SRTG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > > > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > -- ---- IETF related email from Gregory M. Lebovitz --e89a8ff25688cd5fd904bfafe943 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The resolution for Brian's comment below is to replace the 2nd paragrap= h with the following:

=A0 =A0 =A0 =A0=A0If authenticat= ion and security mechanisms rely on systems
= =A0=A0=A0=A0=A0=A0=A0external to the routing system, then there MUST be one= or more
=A0=A0= =A0=A0=A0=A0=A0options available to avoid circular dependencies. =A0=A0= =A0=A0=A0=A0=A0It is not acceptable to have a routing protocol (e.g., unica= st routing) depend upon correct
=A0=A0= =A0=A0=A0=A0=A0operation of a security protocol that, in turn, depends upon=
=A0=A0= =A0=A0=A0=A0=A0correct operation of the same instance of that routing proto= col (i.e., the unicast
=A0=A0= =A0=A0=A0=A0=A0routing). =A0However, it is okay to
=A0=A0= =A0=A0=A0=A0=A0have operation of a routing protocol (e.g., multicast routin= g) depend upon
=A0=A0= =A0=A0=A0=A0=A0operation of a security protocol, which depends upon an inde= pendent
=A0=A0= =A0=A0=A0=A0=A0routing protocol (e.g., unicast routing).
=A0=A0= =A0=A0=A0=A0=A0Similarly it would be okay to have the operation of a routin= g protocol depend
=A0=A0= =A0=A0=A0=A0=A0upon a security protocol, which in turn uses an out of band<= /span>
=A0=A0= =A0=A0=A0=A0=A0network to exchange information with remote systems.<= /b>

This will be pl= aced into the soon to be issued -05.

Gregory (and Ma= nav & Brian)

On Fri, Apr 6, 2012 at 3:58 PM, Brian Weis <= span dir=3D"ltr"><bew= @cisco.com> wrote:
(Speaking as a WG member.)

A second paragraph was added in this version to Requirement 22. While it= 9;s a valiant effort to try to give examples where a circular dependency do= es and does not exist, both examples are convoluted. Understanding the nuan= ces of the examples, and whether or not in all cases of each example that t= he bad one is bad and the good one is good, is laborious. =A0Also it's = also not clear to me that the added MUST is necessary. Wouldn't it be s= ufficient to add this as one reason for the dire warnings already communica= ted in the previous paragraph?

I would suggest removing this paragraph completely, and adding something li= ke the following sentence before the last sentence in the previous paragrap= h: "Relying on external systems may result in a circular dependency be= tween routing and the security mechanisms such that routing cannot be start= ed."

Brian

--
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: += 1 408 526 4796
Email: bew@cisco.com





_______________________________________________
karp mailing list
karp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/karp



--
----
IETF= related email from
Gregory M. Lebovitz

--e89a8ff25688cd5fd904bfafe943-- From gregory.ietf@gmail.com Thu May 10 08:20:45 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD6121F866A for ; Thu, 10 May 2012 08:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHN93Cn9Rn+g for ; Thu, 10 May 2012 08:20:44 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 62F4621F862A for ; Thu, 10 May 2012 08:20:44 -0700 (PDT) Received: by dacx6 with SMTP id x6so1955863dac.31 for ; Thu, 10 May 2012 08:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HXYuHItfUzbK82D8sWYEHE2btB4EqMNlxS7CpK4/XLw=; b=PsoX/4tyk+ZOKrlWTj+sV0UvxppohEFXe+U8Xb5aw262GtRQe8BIEpuIz6CdQpswVp uyT2MlnAj7Dss7gOTDq8+nqAxWWiB9TVArFXNo3plNG3e8+2WblWzK0xwaNLCL7+mU1X n2zvNZl71NkVfjdq16RIffkGhvuhFpLebg+UzvZI4jnkp/bj84jEMZGXkm5VfTmyvbez /MdswVeULM+QrJ14mJBblnEEA2gOYM3BRqcosusXfZbvnGxG3OJL+y+K3/QC4YSQI5Xc CEQv8i06S+WmZtj6K4PwutHcP05D4ssNoQxzp4UM/VafbJPNNi7aGmJl8EVG/fh/Qyxd gT7Q== MIME-Version: 1.0 Received: by 10.68.238.65 with SMTP id vi1mr959413pbc.28.1336663243819; Thu, 10 May 2012 08:20:43 -0700 (PDT) Received: by 10.143.67.2 with HTTP; Thu, 10 May 2012 08:20:43 -0700 (PDT) In-Reply-To: <6A3737B2-5B3C-421A-A61C-64AFB74B2F30@cisco.com> References: <6A3737B2-5B3C-421A-A61C-64AFB74B2F30@cisco.com> Date: Thu, 10 May 2012 08:20:43 -0700 Message-ID: From: Gregory Lebovitz To: Brian Weis Content-Type: multipart/alternative; boundary=047d7b33c7aed50a7b04bfb029a0 Cc: karp@ietf.org Subject: Re: [karp] Security Considerations text added to draft-ietf-karp-threats-reqs-04 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 15:20:45 -0000 --047d7b33c7aed50a7b04bfb029a0 Content-Type: text/plain; charset=ISO-8859-1 Agreed. Change coming in v05. On Fri, Apr 6, 2012 at 4:02 PM, Brian Weis wrote: > (Speaking as a WG member.) > > The text added to the Security Considerations document describes issues > inherent in using a group key, and then adds a requirement that design > teams need to make choices about stopping a BYZANTINE actor. The general > guidance is good, but because Section 3.3 clearly states that threats from > a BYZANTINE actor are out of scope it seems wrong to require design teams > to defend against them. I suggest that the last sentence in this paragraph > be removed. > > Brian > > -- > Brian Weis > Security Standards and Technology, SRTG, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > > > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > -- ---- IETF related email from Gregory M. Lebovitz --047d7b33c7aed50a7b04bfb029a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agreed. Change coming in v05.

On Fri, Apr= 6, 2012 at 4:02 PM, Brian Weis <bew@cisco.com> wrote:
(Speaking as a WG member.)

The text added to the Security Considerations document describes issues inh= erent in using a group key, and then adds a requirement that design teams n= eed to make choices about stopping a BYZANTINE actor. The general guidance = is good, but because Section 3.3 clearly states that threats from a BYZANTI= NE actor are out of scope it seems wrong to require design teams to defend = against them. I suggest that the last sentence in this paragraph be removed= .

Brian

--
Brian Weis
Security Standards and Technology, SRTG, Cisco Systems
Telephone: += 1 408 526 4796
Email: bew@cisco.com





_______________________________________________
karp mailing list
karp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/karp



--
----
IETF= related email from
Gregory M. Lebovitz

--047d7b33c7aed50a7b04bfb029a0-- From internet-drafts@ietf.org Thu May 10 10:53:15 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE9111E809A; Thu, 10 May 2012 10:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfv91qOH6ofF; Thu, 10 May 2012 10:53:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C138121F8637; Thu, 10 May 2012 10:53:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120510175313.23420.15177.idtracker@ietfa.amsl.com> Date: Thu, 10 May 2012 10:53:13 -0700 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 17:53:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing= Protocols Working Group of the IETF. Title : Keying and Authentication for Routing Protocols (KARP) O= verview, Threats, and Requirements Author(s) : Gregory Lebovitz Manav Bhatia Filename : draft-ietf-karp-threats-reqs-05.txt Pages : 32 Date : 2012-05-10 Different routing protocols exist and each employs its own mechanism for securing the protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed and a set of requirements for KARP design teams to follow. RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" is a companion to this document; KARP design teams will use them together to review and overhaul routing protocols. These two documents reflect the input of both the IETF's Security Area and Routing Area in order to form a mutually agreeable work plan. This document has three main parts. The first part provides an overview of the KARP effort. The second part lists the threats from RFC 4593, Generic Threats To Routing Protocols, that are in scope for attacks against routing protocols' transport systems, including any mechanisms built into the routing protocols themselves, which accomplish packet authentication. The third part enumerates the requirements that routing protocol specifications must meet when addressing those threats for RFC 6518's "Work Phase 1", the update to a routing protocol's existing transport security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ From gregory.ietf@gmail.com Thu May 10 11:04:14 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9D921F86D5 for ; Thu, 10 May 2012 11:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCtu2r5OIGYi for ; Thu, 10 May 2012 11:04:13 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7202E21F86C6 for ; Thu, 10 May 2012 11:04:13 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2321441pbc.31 for ; Thu, 10 May 2012 11:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RCiuFtVx/5Zlw89+y2iwyTxTFAfTxSfo1ilOXZ4S/yM=; b=qrqWqnZhNqAM8ZTGJ0Z+nQqO/yVpm+yRQmR+6+9JmKicHlEBrC4pE9n4FIooUKYCrL MDsh0p2yMRlv9bh+JfVxRZ9z8Aa+PRcPe+OLVSUxXK1QMB8xqkhru6gJffANDbiuZ2l/ xWkspTheAwRYFN8tyN/quzAifDhER1UDTGZmCnQniC0OUBv3tXhiAzTF9rWagSWk7nXF lFwDDIV/cQpwA88W+Wg3tZxkcNxAOuKfF3SyINvWZyiF3SLI7I9pA2UqHe+DaFEOy7QP uOkUl7JOD53aHb2eW7t7JOCXWj/S4fYAakXMzZh28ey/0vHkB1pQXNM4x8rwandTJHCR LZZQ== MIME-Version: 1.0 Received: by 10.68.221.39 with SMTP id qb7mr22577745pbc.120.1336673052615; Thu, 10 May 2012 11:04:12 -0700 (PDT) Received: by 10.143.67.2 with HTTP; Thu, 10 May 2012 11:04:12 -0700 (PDT) In-Reply-To: <20120510175313.23420.15177.idtracker@ietfa.amsl.com> References: <20120510175313.23420.15177.idtracker@ietfa.amsl.com> Date: Thu, 10 May 2012 11:04:12 -0700 Message-ID: From: Gregory Lebovitz To: karp@ietf.org, Brian Weis , "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=e89a8ff256887b650304bfb272bd Subject: Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 18:04:14 -0000 --e89a8ff256887b650304bfb272bd Content-Type: text/plain; charset=ISO-8859-1 Hey all, This version -05 addressed all the known content issues (a total of 6) that were brought to our attention during the 2nd WG LC. Brian - I think we are ready to go back for IESG approval. FYI, we started a simple GoogleDoc tracker for this last version. It is located here: https://docs.google.com/document/d/10lSS99Rq3wCDKgyrNuv-9dxbbInOIIVDb_BWaPxrm9Q/edit Hope it helps, Gregory On Thu, May 10, 2012 at 10:53 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Keying and Authentication for > Routing Protocols Working Group of the IETF. > > Title : Keying and Authentication for Routing Protocols > (KARP) Overview, Threats, and Requirements > Author(s) : Gregory Lebovitz > Manav Bhatia > Filename : draft-ietf-karp-threats-reqs-05.txt > Pages : 32 > Date : 2012-05-10 > > Different routing protocols exist and each employs its own mechanism > for securing the protocol packets on the wire. While most already > have some method for accomplishing cryptographic message > authentication, in many cases the existing methods are dated, > vulnerable to attack, and employ cryptographic algorithms that have > been deprecated. The "Keying and Authentication for Routing > Protocols" (KARP) effort aims to overhaul and improve these > mechanisms. > > This document does not contain protocol specifications. Instead, it > defines the areas where protocol specification work is needed and a > set of requirements for KARP design teams to follow. RFC 6518, > "Keying and Authentication for Routing Protocols (KARP) Design > Guidelines" is a companion to this document; KARP design teams will > use them together to review and overhaul routing protocols. These > two documents reflect the input of both the IETF's Security Area and > Routing Area in order to form a mutually agreeable work plan. > > This document has three main parts. The first part provides an > overview of the KARP effort. The second part lists the threats from > RFC 4593, Generic Threats To Routing Protocols, that are in scope for > attacks against routing protocols' transport systems, including any > mechanisms built into the routing protocols themselves, which > accomplish packet authentication. The third part enumerates the > requirements that routing protocol specifications must meet when > addressing those threats for RFC 6518's "Work Phase 1", the update to > a routing protocol's existing transport security. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > -- ---- IETF related email from Gregory M. Lebovitz --e89a8ff256887b650304bfb272bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey all,
This version -05 addressed all the known content issues (a tot= al of 6) that were brought to our attention during the 2nd WG LC.

Brian - I think we are ready to go back for IESG approval.<= /div>

FYI, we started a simple GoogleDoc tracker for this las= t version. It is located here:=A0


Hope it helps,
Gregory

On Thu, May 10, 2012 at 10:53 AM, <= ;internet-dra= fts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing= Protocols Working Group of the IETF.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Keying and Authentication for R= outing Protocols (KARP) Overview, Threats, and Requirements
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Gregory Lebovitz
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Manav Bhatia
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-karp-threats-reqs-05.t= xt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 32
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-05-10

=A0 Different routing protocols exist and each employs its own mechanism =A0 for securing the protocol packets on the wire. =A0While most already =A0 have some method for accomplishing cryptographic message
=A0 authentication, in many cases the existing methods are dated,
=A0 vulnerable to attack, and employ cryptographic algorithms that have =A0 been deprecated. =A0The "Keying and Authentication for Routing =A0 Protocols" (KARP) effort aims to overhaul and improve these
=A0 mechanisms.

=A0 This document does not contain protocol specifications. =A0Instead, it=
=A0 defines the areas where protocol specification work is needed and a =A0 set of requirements for KARP design teams to follow. =A0RFC 6518,
=A0 "Keying and Authentication for Routing Protocols (KARP) Design =A0 Guidelines" is a companion to this document; KARP design teams wi= ll
=A0 use them together to review and overhaul routing protocols. =A0These =A0 two documents reflect the input of both the IETF's Security Area a= nd
=A0 Routing Area in order to form a mutually agreeable work plan.

=A0 This document has three main parts. =A0The first part provides an
=A0 overview of the KARP effort. =A0The second part lists the threats from=
=A0 RFC 4593, Generic Threats To Routing Protocols, that are in scope for<= br> =A0 attacks against routing protocols' transport systems, including an= y
=A0 mechanisms built into the routing protocols themselves, which
=A0 accomplish packet authentication. =A0The third part enumerates the
=A0 requirements that routing protocol specifications must meet when
=A0 addressing those threats for RFC 6518's "Work Phase 1", = the update to
=A0 a routing protocol's existing transport security.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-k= arp-threats-reqs-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-kar= p-threats-reqs-05.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-karp-threats-= reqs/

_______________________________________________
karp mailing list
karp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/karp



--
----
IETF= related email from
Gregory M. Lebovitz

--e89a8ff256887b650304bfb272bd-- From rja.lists@gmail.com Mon May 14 12:42:37 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEA221F8875 for ; Mon, 14 May 2012 12:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGEkr0ejfTjj for ; Mon, 14 May 2012 12:42:37 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id F20F821F884E for ; Mon, 14 May 2012 12:42:36 -0700 (PDT) Received: by qcsq13 with SMTP id q13so4440491qcs.31 for ; Mon, 14 May 2012 12:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=Sg1mV+x2VwLuoHWEJXxcPJHaDpbrulJnTxsPcXJ9FGc=; b=b9wkIqdxCd7E3iColy9LFEThzHBATVkv6Uw/a/YD6OV2s/zrN916y+eNQNNLuK/iXS 2SC3Ekn/Ecaiztn7ZbTr2SSXqW7ihiOwmdRF3gmsIAbju1rrMvkAShnDCQTmxq+SBFE3 r06vNZgyCZteZbOkioOwj7VamgjbCWyuzs+so870ntMM1PDu8JvAflv8ZfTnnvQUf32I YSgbyD7+0GbzjvHFMXSm2izobbLRwWLWrq8MmciQyEhNmsN1SvOC387fk1EERpQdys6o 31n5tW/cZMae6RXUBFHIvaQjf3BBeOFYaFiEKOexI8px4jbIRvMTLlukhkcqF/pBwFz7 KIOQ== Received: by 10.224.181.17 with SMTP id bw17mr14878676qab.24.1337024554870; Mon, 14 May 2012 12:42:34 -0700 (PDT) Received: from [10.30.20.11] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id cp17sm41238283qab.5.2012.05.14.12.42.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 14 May 2012 12:42:31 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 14 May 2012 15:42:30 -0400 Message-Id: To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: Re: [karp] Only two lifetimes ? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 19:42:37 -0000 Reducing the applicable lifetimes from the 4 defined in the Key Table draft (and in standards-track IETF RFCs) at present=20 to 2 creates multiple issues -- and solves no technical problems. 1) It breaks existing deployments of OSPFv2 Authentication, which use those lifetimes. By itself, this is more than sufficient reason to retain the current approach. 2) It means that the Key Table cannot comply with the OSPFv2 specification (e.g. RFC-2328, Appendix D.3, page 230). This also, by itself, is more than sufficient reason to retain the current approach. OSPFv2 is widely implemented with these 4 lifetimes. It even managed to get all the way through to full IETF Standard, which is pretty amazing, and also indicative of maturity of specification. 3) It is not obvious that 2 times are sufficient to enable smooth key rollover, for several different reasons. A) Clocks on routers might or might not be tightly synchronised in practice. Even if intended to be tightly synchronised, for example via NTP, relying on milli-second accuracy would create a new (D)DOS attack vector (e.g. on NTP running=20 inside the routers). In many deployments that I'm aware of, adjacent routers commonly have clocks a few minutes apart. B) Transit time between adjacent routers is not necessarily a few milliseconds. Consider, for example, two routers inside=20 a single administrative domain connected via an MPLS L2 VPN. =20 Those easily could be a continent apart. I know of such deployments that cross oceans today (e.g. for VM migration = reasons). =20 L2 WAN VPNs are NOT uncommon in the deployed world, especially for distributed enterprises that use a commercial ISP for inter-site connectivity. A common reason to deploy one's network this way is to enable VM migration between multiple geographically diverse data centres, but this is not the=20 only reason one might deploy one's enterprise network that way. C) Operationally, we know that the 4 lifetime approach in RFC-2328 works well because multiple sites have deployed that today (e.g. using NetConf or Tcl/Expect/SSH to update the SAs inside=20 the routers). By contrast, it has not been shown here that=20 a 2 lifetime approach is even sufficient, even with tightly=20 synchronised clocks. Consider an OSPF packet that is sent just=20 before the end lifetime of a start-lifetime/stop-lifetime system. =20= That packet will arrive at the adjacent router AFTER the = stop-lifetime=20 and so will be discarded as non-authentic -- potentially causing=20= routing issues and certainly delaying (re)convergence. By contrast, keeping a 4 lifetime system is NOT an operational burden, evidence that some sites have deployed this for OSPFv2. Also, the additional code required in a router or provisioning system to support the 4 lifetime scheme is neither complex nor sophisticated, nor does it have a large code footprint. So there is no reason to reduce from 4 lifetimes to 2 lifetimes. In fact, there is some operational evidence that other IGPs would=20 benefit from having the same 4 lifetimes specified as part of their Security Associations. That would be a more promising fix. Just to be clear, the burden of proof here is on folks advocating 2 = lifetimes, since both operational experience and existing standards-track RFCs (e.g. RFC-2328) specify 4 lifetimes. =20 Yours, Ran From gregory.ietf@gmail.com Wed May 16 09:42:20 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA3B21F84D5 for ; Wed, 16 May 2012 09:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.387, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_45=1, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IKBhwD8IX-M for ; Wed, 16 May 2012 09:42:19 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 77E3A21F8442 for ; Wed, 16 May 2012 09:42:19 -0700 (PDT) Received: by dacx6 with SMTP id x6so1249109dac.31 for ; Wed, 16 May 2012 09:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=7Y/XrIOibY7szpNbtddd67ZVZ+sn3jbtRL3pi45VPw8=; b=dUT3ZgVWWXTHMPvNQWGlbFpkRn+U1e+ZY+sP/z2wefXK4TVlqLhOeJfX6wtBjg5iL6 yB8EyykMZ2VwLQuO6etBdAaHdrcwXABSMYjxRLkh9llQHhskOKQOSfbd+s4xy0JNCZbw lmTkbYBcPz9JJcJQhTESQ0RSBgVmSfLtWOmPDKKSYIZetBaVnH8pxdjHn/wk9InnjNXj mT+Eh/luYmyhzZIo90jAfz/DxmnR69cIKnJtefMZbLA89Chw8xT6nnQl8GB4UPgXq3Kw SbrQhyvAnEyDjeihtw15jpJAh3NNipdu9nbn5qCq2fUiECqPz8xMKbm9leVEsYkQTl/a cMkQ== MIME-Version: 1.0 Received: by 10.68.194.227 with SMTP id hz3mr11032624pbc.23.1337186539008; Wed, 16 May 2012 09:42:19 -0700 (PDT) Received: by 10.143.67.2 with HTTP; Wed, 16 May 2012 09:42:18 -0700 (PDT) Date: Wed, 16 May 2012 09:42:18 -0700 Message-ID: From: Gregory Lebovitz To: Brian Weis , Joel Halpern Content-Type: multipart/alternative; boundary=047d7b10cb51a7f30904c02a0050 Cc: karp@ietf.org Subject: [karp] Charter updates X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 16:42:20 -0000 --047d7b10cb51a7f30904c02a0050 Content-Type: text/plain; charset=ISO-8859-1 Hey all, I was looking for something today and happened to review the charter page. A few things are out of date there, besides the (obvious) dates: - refers to "draft-lebovitz-karp-roadmap" which has LONG since become RFC 6518 and draft-ietf-karp-threats-reqs - has a link to RFC 4393which, when clicked, actually takes one to "MIME Type Registrations for 3GPP2 Multimedia files" which I'm pretty sure is incorrect. - key tables draft has expired and does not appear on the list of active drafts or related drafts Hope it helps, -- ---- IETF related email from Gregory M. Lebovitz --047d7b10cb51a7f30904c02a0050 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey all,
I was looking for something today and happened to review the c= harter page. A few things are out of date there, besides the (obvious) date= s:
=A0- refers to "draft-lebovitz-karp-roadmap" which has LONG since become RFC 6518 = and draft-ietf-karp-threats-reqs
=A0- has a link to= =A0<= /span>RFC 4393 which, when clicked, actually takes one to &quo= t;MIME Type Registrations for 3GPP2 Multimedia files" which I'm pr= etty sure is incorrect.
=A0- key tables draft has= expired and does not appear on the list of active drafts or related drafts=

Hope it helps,

--
----
= IETF related email from
Gregory M. Lebovitz
--047d7b10cb51a7f30904c02a0050-- From bew@cisco.com Fri May 18 12:24:30 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7666921F8653 for ; Fri, 18 May 2012 12:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108 X-Spam-Level: X-Spam-Status: No, score=-108 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csJfRP-0Gre4 for ; Fri, 18 May 2012 12:24:30 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 13A9321F864E for ; Fri, 18 May 2012 12:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=556; q=dns/txt; s=iport; t=1337369070; x=1338578670; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=D2PxJsx1dqhp+DaCDlUIRfeyH5xJXELu11T9ZDS+/pQ=; b=DKTds2MfM9sX3qksENbK0oFJhvwQsZejEEB+4IYRCajXnniZi5vgIpRu ns1tqZfHZPaMBQ8FiZFL9Nx8G6/xNRcVoVZ3ysDCScayHVqFz0MU6od66 6GYWOxasmZYx17HdXx3SaaFwnJnOqf6SFd6SwCEzzBNjmPpbMm6NThLjk g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFAAihtk+rRDoJ/2dsb2JhbABFgx2wbIEHgi4BJ4Iyh2sMmySBKJ99in+CKII8YgOIQIxggQ+EQ4g/gWSDCQ X-IronPort-AV: E=Sophos;i="4.75,618,1330905600"; d="scan'208";a="45371740" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 18 May 2012 19:24:29 +0000 Received: from [10.34.209.205] ([10.34.209.205]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4IJOTkK021927 for ; Fri, 18 May 2012 19:24:29 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 18 May 2012 12:24:28 -0700 Message-Id: <02717414-847B-4E3C-9F47-7AE30947F052@cisco.com> To: karp@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [karp] WGLC of draft-ietf-karp-ospf-analysis-03 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 19:24:30 -0000 Folks, The KARP Analysis of OSPF document has been stable for some time, and = the authors believe it is in accordance with both the KARP Design Guide = (RFC 6518) and the Threats-Reqs draft (draft-ietf-karp-threats-reqs-05). = The chairs are therefore asking for a WG last call, with the view of = sending this to our AD for publication as an Informational RFC. Please = send any remaining comments you have on this document to the list by = June 1, 2012. Thanks, Brian & Joel From uma.chunduri@ericsson.com Fri May 18 16:56:58 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC0221F8603 for ; Fri, 18 May 2012 16:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32ozDCqgfApX for ; Fri, 18 May 2012 16:56:58 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id E385E21F858A for ; Fri, 18 May 2012 16:56:54 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q4INurk5020565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 May 2012 18:56:54 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.6]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 18 May 2012 19:56:53 -0400 From: Uma Chunduri To: Sam Hartman , "karp@ietf.org" Date: Fri, 18 May 2012 19:56:51 -0400 Thread-Topic: [karp] Only two lifetimes? Thread-Index: Ac0tWkblIDm82EK4SrqNZj0lQo7hpgH9TVbg Message-ID: References: In-Reply-To: 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 Subject: Re: [karp] Only two lifetimes? X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 23:56:58 -0000 For TCP based RPs these two lifetimes are any ways not negotiable through K= MP.=20 A locally configured Master key life-time is good enough to roll over the s= ame using KMP and roll over time need not be synchronized explicitly with the peer. So, o= ne re-key=20 configuration value specified in "secs" is sufficient.=20 I am just wondering how these 2 operator entered lifetimes work with KMP?=20 --=20 Uma C.=20 -----Original Message----- From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Sam= Hartman Sent: Tuesday, May 08, 2012 1:37 PM To: karp@ietf.org Subject: [karp] Only two lifetimes? So, at the last KARP meeting we talked about whether to simplify managemen= t models or wether to implement everything that could be used by a protocol= . Between version 01 and 02 of the key tables draft, the NotBefore and NotAft= er fields were expanded to {Send|Receive}Not{Before|After}.=20 Yes, some routing protocols have this flexibility. however it doesn't seem necessary. Why is a key that is inappropriate for verifying packets in the key table a= t all? Why not go back to the 01 model and have only two times? We can also provide a way to mark a key disabled by setting its direction t= o disabled rather than in/out/both. I believe this will provide the flexibility people actually use while simpl= ifying configuration somewhat. --Sam _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp From uma.chunduri@ericsson.com Fri May 18 17:00:28 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A7321F8620 for ; Fri, 18 May 2012 17:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTP2-flL+3MT for ; Fri, 18 May 2012 17:00:27 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 41C3F21F852D for ; Fri, 18 May 2012 17:00:27 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q4J00NW0026000; Fri, 18 May 2012 19:00:24 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.6]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Fri, 18 May 2012 20:00:19 -0400 From: Uma Chunduri To: Gregory Lebovitz , "karp@ietf.org" , Brian Weis , "Bhatia, Manav (Manav)" Date: Fri, 18 May 2012 20:00:17 -0400 Thread-Topic: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt Thread-Index: Ac0u11IfKn1NmyxwSgGf8NWh766mCAGeJgcQ Message-ID: References: <20120510175313.23420.15177.idtracker@ietfa.amsl.com> In-Reply-To: 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_D1D8138DDF34B34B8BC68A11262D107922425D5F0CEUSAACMS0701e_" MIME-Version: 1.0 Subject: Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 00:00:28 -0000 --_000_D1D8138DDF34B34B8BC68A11262D107922425D5F0CEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, I read this version and the document is in good shape. If, it's not too late, I have few comments on the 05 version. 1.a) Page 4: Section 1. Introduction Third Bullet: " o Create specifications for cryptographic validation of routing message content." "The third bullet is being addressed in the SIDR working group." Though we can understand what SIDR is doing - "routing message content"= just doesn't imply BGP message? I can understand what you are trying to say, but IMO, what is said is no= t representative. b) 7. Sec 2.4: "Message content validity (routing database validity). This work is being addressed in other IETF efforts, like SIDR." I am not sure "routing database" above is synonymous to BGP. Be explicit= calling out, as this can wrong impression on SIDR scope. 2. Section 1, Last paragraph, unnecessary ending quote. 3. Section 1.1, Page 6: "If session or traffic keys are being used, KMP is responsible for generating them and determining when they should be renewed." This is not necessarily the only way as it sounds. KMP can also be used = for only master key generation and traffic keys are generated from the same by the master key consumer. And= also determining when the keys should be renewed may not be KMP function. So I am not quite you define KMP thi= s way. 4. Sec 2.2: "However,in the spirit of incremental deployment, we first addressed issues like cryptographic algorithm agility, replay attacks, and TCP session resetting in the base TCP-AO protocol, and then later began work to layer key management on top of it." Though authors might have worked on AO, but the above can be better represented how TCP-AO is planned to be evolved. 5. Sec 2.3, Page 13, Point 7. " For example, designers should aim to re-use the key management protocol that will be defined for BGP's TCP-AO key establishment for as many other routing protocols as possible." Why this should be BGP's TCP-AO ?? I presume, TCP-AO is a generic pr= otocol and any TCP-based pair wise RP or client/server can use this. It's b= etter to say "other routing protocols with similar [characteristics/propertie= s] as possible" 6. Section-4 Page 20 >>document(s)." Extra ending quote. 7." 21. Given the number of routers that would require the new authentication mechanisms in a typical ISP deployment, solutions can increase their appeal by minimizing the burden imposed on all routers in favor of confining significant work loads to a relatively small number of devices. Optional features or increased assurance that engenders more pervasive processing loads MAY be made available for deployments where the additional resources are economically justifiable." What is the requirement? -- Uma C. ________________________________ From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] On Behalf Of Gre= gory Lebovitz Sent: Thursday, May 10, 2012 11:04 AM To: karp@ietf.org; Brian Weis; Bhatia, Manav (Manav) Subject: Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt Hey all, This version -05 addressed all the known content issues (a total of 6) that= were brought to our attention during the 2nd WG LC. Brian - I think we are ready to go back for IESG approval. FYI, we started a simple GoogleDoc tracker for this last version. It is loc= ated here: https://docs.google.com/document/d/10lSS99Rq3wCDKgyrNuv-9dxbbInOIIVDb_B= WaPxrm9Q/edit Hope it helps, Gregory On Thu, May 10, 2012 at 10:53 AM, > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing= Protocols Working Group of the IETF. Title : Keying and Authentication for Routing Protocols (K= ARP) Overview, Threats, and Requirements Author(s) : Gregory Lebovitz Manav Bhatia Filename : draft-ietf-karp-threats-reqs-05.txt Pages : 32 Date : 2012-05-10 Different routing protocols exist and each employs its own mechanism for securing the protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed and a set of requirements for KARP design teams to follow. RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" is a companion to this document; KARP design teams will use them together to review and overhaul routing protocols. These two documents reflect the input of both the IETF's Security Area and Routing Area in order to form a mutually agreeable work plan. This document has three main parts. The first part provides an overview of the KARP effort. The second part lists the threats from RFC 4593, Generic Threats To Routing Protocols, that are in scope for attacks against routing protocols' transport systems, including any mechanisms built into the routing protocols themselves, which accomplish packet authentication. The third part enumerates the requirements that routing protocol specifications must meet when addressing those threats for RFC 6518's "Work Phase 1", the update to a routing protocol's existing transport security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp -- ---- IETF related email from Gregory M. Lebovitz --_000_D1D8138DDF34B34B8BC68A11262D107922425D5F0CEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors,
 
I read this version and the document is in good=20 shape.
 <= /DIV>
If, it's not too late, I have few comments on th= e 05=20 version.
 
 
1.a) Page 4: Section 1.&nb= sp;=20 Introduction
    Third Bullet:
   =20 "   o  Create specifications for cryptographic validation of= =20 routing
      message=20 content."
    "The third bullet is being addressed in the= =20 SIDR
   working group."
   Though we can understa= nd=20 what SIDR is doing -  "routing message content" just doesn't=20 imply BGP message?
 &= nbsp; I=20 can understand what you are tr= ying to=20 say, but IMO, what is said is not representative.
 
  b) 7. Sec 2.4:
&= nbsp; =20 "Message content validity (routing database validity).  This=20 work
      is being addressed in other IETF eff= orts,=20 like SIDR."
 
   I am not sure= "routing=20 database" above is synonymous to BGP. Be explicit calling out, as this can = wrong=20 impression on SIDR scope.
 

2. Section 1, Last par= agraph,=20 unnecessary ending quote.
 
3. Section 1.1, Page=20 6:
   "If session or traffic
     = keys=20 are being used, KMP is responsible for generating them=20 and
      determining when they should be=20 renewed."
 
   This is not n= ecessarily=20 the only way as it sounds. KMP can also be used for only master key generat= ion=20 and
   traffic keys are generated from the same by the master= key=20 consumer. And also determining when the keys should
   be ren= ewed=20 may not be KMP function. So I am not quite you define KMP this way.<= /DIV>
 

4. Sec 2.2:
 &= nbsp;=20 "However,in the spirit of incremental
   deployment, we first= =20 addressed issues like cryptographic algorithm
   agility, repl= ay=20 attacks, and TCP session resetting in the base TCP-AO
   proto= col,=20 and then later began work to layer key management on top of
  = =20 it."
   Though authors might have worked on AO, but the above = can=20 be better
   represented how TCP-AO is planned to be evolved.
 
5. Sec 2.3, Page 13, Point= =20 7.
   " For example, designers should aim to re-use the key=20 management
       protocol that will be de= fined=20 for BGP's TCP-AO key establishment
       = for=20 as many other routing protocols as possible."
    
       Why = this should be=20 BGP's TCP-AO ?? I presume,=20 TCP-AO is a generic protocol
      = and=20 any TCP-based pair wise RP or client/server can use this. It's better to=20
       say "other routing protocols with= =20 similar [characteristics/properties] as possible"
 

6. Section-4 Page=20 20
   >>document(s)."
   Extra ending=20 quote.
 
7."   21.  = Given the=20 number of routers that would require the=20 new
        authentication mechanisms= in a=20 typical ISP deployment, solutions
      &n= bsp;=20 can increase their appeal by minimizing the burden imposed=20 on
        all routers in favor of=20 confining significant work loads to=20 a
        relatively small number of= =20 devices.  Optional features=20 or
        increased assurance that=20 engenders more pervasive=20 processing
        loads MAY be made= =20 available for deployments where the=20 additional
        resources are=20 economically justifiable."
     What is the=20 requirement?
 
--
Uma C.
 

From: karp-bounces@ietf.org=20 [mailto:karp-bounces@ietf.org] On Behalf Of Gregory=20 Lebovitz
Sent: Thursday, May 10, 2012 11:04 AM
To:=20 karp@ietf.org; Brian Weis; Bhatia, Manav (Manav)
Subject: Re: [ka= rp]=20 I-D Action: draft-ietf-karp-threats-reqs-05.txt

Hey all,
This version -05 addressed all the known content issues (a total of 6)= that=20 were brought to our attention during the 2nd WG LC.

Brian - I think we are ready to go back for IESG approval.

FYI, we started a simple GoogleDoc tracker for this last version. It i= s=20 located here: 

    https://docs.google.com/document/d/10lSS99Rq3wCDKgyrNuv-= 9dxbbInOIIVDb_BWaPxrm9Q/edit

Hope it helps,
Gregory

On Thu, May 10, 2012 at 10:53 AM, = <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line= =20 Internet-Drafts directories. This draft is a work item of the Keying and= =20 Authentication for Routing Protocols Working Group of the IETF.

&n= bsp;=20      Title           : Keying and= =20 Authentication for Routing Protocols (KARP) Overview, Threats, and=20 Requirements
       Author(s)      = :=20 Gregory Lebovitz
              &nbs= p;=20          Manav Bhatia
     =20  Filename        :=20 draft-ietf-karp-threats-reqs-05.txt
       Pages &= nbsp;=20         : 32
       Date  = ;=20          : 2012-05-10

  Different ro= uting=20 protocols exist and each employs its own mechanism
  for securing= the=20 protocol packets on the wire.  While most already
  have som= e=20 method for accomplishing cryptographic message
  authentication, = in=20 many cases the existing methods are dated,
  vulnerable to attack= , and=20 employ cryptographic algorithms that have
  been deprecated. &nbs= p;The=20 "Keying and Authentication for Routing
  Protocols" (KARP) effort= aims=20 to overhaul and improve these
  mechanisms.

  This=20 document does not contain protocol specifications.  Instead, it
&= nbsp;=20 defines the areas where protocol specification work is needed and a
&n= bsp;=20 set of requirements for KARP design teams to follow.  RFC 6518,
&= nbsp;=20 "Keying and Authentication for Routing Protocols (KARP) Design
 = =20 Guidelines" is a companion to this document; KARP design teams will
&n= bsp;=20 use them together to review and overhaul routing protocols.=20  These
  two documents reflect the input of both the IETF's= =20 Security Area and
  Routing Area in order to form a mutually agre= eable=20 work plan.

  This document has three main parts.  The fi= rst=20 part provides an
  overview of the KARP effort.  The second = part=20 lists the threats from
  RFC 4593, Generic Threats To Routing=20 Protocols, that are in scope for
  attacks against routing protoc= ols'=20 transport systems, including any
  mechanisms built into the rout= ing=20 protocols themselves, which
  accomplish packet authentication.=20  The third part enumerates the
  requirements that routing=20 protocol specifications must meet when
  addressing those threats= for=20 RFC 6518's "Work Phase 1", the update to
  a routing protocol's=20 existing transport security.


A URL for this Internet-Draft=20 is:
http://www.ietf.org/internet-drafts/draft-ietf-karp-threa= ts-reqs-05.txt

Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This=20 Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-threat= s-reqs-05.txt

The=20 IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-karp-threats-= reqs/

_______________________________________________
karp=20 mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp


--
----
IETF related email from
Gregory M.=20 Lebovitz

--_000_D1D8138DDF34B34B8BC68A11262D107922425D5F0CEUSAACMS0701e_-- From bew@cisco.com Fri May 18 18:06:53 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DBE21F8634 for ; Fri, 18 May 2012 18:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.371 X-Spam-Level: X-Spam-Status: No, score=-110.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0c6utY5-dK8f for ; Fri, 18 May 2012 18:06:52 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 00A2221F8631 for ; Fri, 18 May 2012 18:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=12334; q=dns/txt; s=iport; t=1337389611; x=1338599211; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=oem9IJNCKO5pnom3AZTybdpkVYEWlZ9Cu2upphhKJI0=; b=Fwm4td3smKC7aw/7J58MH9llTiAVA430V4clnPyF4L1TCqp87f/JcOa3 FsbEG67nYneCpaTJgYNaAEYjC4QfCCE5WdGXGXudYSzeMGFMSra0vCbbG L1a1+RITLlf5EmkThM6YlpKWbebtdBy18U5EyBJ9ELvK4+V2Xjlgc4SEX E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAGTxtk+rRDoH/2dsb2JhbABCA4JFiGqoXYEHghUBAQEDAQEBAQ8BWwsFCwsYLicwBhMJGYdnBAELnEiffop/giyCQWIDiD2MWY4MgWSDCYE/ X-IronPort-AV: E=Sophos;i="4.75,620,1330905600"; d="scan'208,217";a="42296520" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 19 May 2012 01:06:51 +0000 Received: from dhcp-128-107-151-76.cisco.com (dhcp-128-107-151-76.cisco.com [128.107.151.76]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4J15wBs018020; Sat, 19 May 2012 01:06:51 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_D9B5744F-8B81-46AB-8A7A-4461D06B9B9A" From: Brian Weis In-Reply-To: Date: Fri, 18 May 2012 18:06:50 -0700 Message-Id: <2826EC25-B42F-4406-A7B3-C88C3282D562@cisco.com> References: <20120510175313.23420.15177.idtracker@ietfa.amsl.com> To: Gregory Lebovitz X-Mailer: Apple Mail (2.1257) Cc: karp@ietf.org Subject: Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 01:06:53 -0000 --Apple-Mail=_D9B5744F-8B81-46AB-8A7A-4461D06B9B9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Gregory, On May 10, 2012, at 11:04 AM, Gregory Lebovitz wrote: > Hey all, > This version -05 addressed all the known content issues (a total of 6) = that were brought to our attention during the 2nd WG LC. >=20 > Brian - I think we are ready to go back for IESG approval. Stewart will be reviewing -05 and decide whether it's ready to forward = to the IETG. Thanks! Brian >=20 > FYI, we started a simple GoogleDoc tracker for this last version. It = is located here:=20 >=20 > = https://docs.google.com/document/d/10lSS99Rq3wCDKgyrNuv-9dxbbInOIIVDb_BWaP= xrm9Q/edit >=20 > Hope it helps, > Gregory >=20 > On Thu, May 10, 2012 at 10:53 AM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Keying and Authentication = for Routing Protocols Working Group of the IETF. >=20 > Title : Keying and Authentication for Routing = Protocols (KARP) Overview, Threats, and Requirements > Author(s) : Gregory Lebovitz > Manav Bhatia > Filename : draft-ietf-karp-threats-reqs-05.txt > Pages : 32 > Date : 2012-05-10 >=20 > Different routing protocols exist and each employs its own mechanism > for securing the protocol packets on the wire. While most already > have some method for accomplishing cryptographic message > authentication, in many cases the existing methods are dated, > vulnerable to attack, and employ cryptographic algorithms that have > been deprecated. The "Keying and Authentication for Routing > Protocols" (KARP) effort aims to overhaul and improve these > mechanisms. >=20 > This document does not contain protocol specifications. Instead, it > defines the areas where protocol specification work is needed and a > set of requirements for KARP design teams to follow. RFC 6518, > "Keying and Authentication for Routing Protocols (KARP) Design > Guidelines" is a companion to this document; KARP design teams will > use them together to review and overhaul routing protocols. These > two documents reflect the input of both the IETF's Security Area and > Routing Area in order to form a mutually agreeable work plan. >=20 > This document has three main parts. The first part provides an > overview of the KARP effort. The second part lists the threats from > RFC 4593, Generic Threats To Routing Protocols, that are in scope = for > attacks against routing protocols' transport systems, including any > mechanisms built into the routing protocols themselves, which > accomplish packet authentication. The third part enumerates the > requirements that routing protocol specifications must meet when > addressing those threats for RFC 6518's "Work Phase 1", the update = to > a routing protocol's existing transport security. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ >=20 > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp >=20 >=20 >=20 > --=20 > ---- > IETF related email from > Gregory M. Lebovitz >=20 --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com --Apple-Mail=_D9B5744F-8B81-46AB-8A7A-4461D06B9B9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Gregory,

On May 10, 2012, at 11:04 AM, = Gregory Lebovitz wrote:

Hey = all,
This version -05 addressed all the known content issues (a = total of 6) that were brought to our attention during the 2nd WG = LC.

Brian - I think we are ready to go back for = IESG approval.

Stewart will be = reviewing -05 and decide whether it's ready to forward to the = IETG.

Thanks!
Brian


FYI, we started a simple GoogleDoc tracker for this = last version. It is located here: 


Hope it helps,
Gregory

On Thu, May 10, 2012 at 10:53 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Keying and Authentication = for Routing Protocols Working Group of the IETF.

       Title           : = Keying and Authentication for Routing Protocols (KARP) Overview, = Threats, and Requirements
       Author(s)       : Gregory = Lebovitz
                    =      Manav Bhatia
       Filename        : = draft-ietf-karp-threats-reqs-05.txt
       Pages           : = 32
       Date           =  : 2012-05-10

  Different routing protocols exist and each employs its own = mechanism
  for securing the protocol packets on the wire.  While most = already
  have some method for accomplishing cryptographic message
  authentication, in many cases the existing methods are = dated,
  vulnerable to attack, and employ cryptographic algorithms that = have
  been deprecated.  The "Keying and Authentication for = Routing
  Protocols" (KARP) effort aims to overhaul and improve these
  mechanisms.

  This document does not contain protocol specifications. =  Instead, it
  defines the areas where protocol specification work is needed = and a
  set of requirements for KARP design teams to follow.  RFC = 6518,
  "Keying and Authentication for Routing Protocols (KARP) = Design
  Guidelines" is a companion to this document; KARP design teams = will
  use them together to review and overhaul routing protocols. =  These
  two documents reflect the input of both the IETF's Security Area = and
  Routing Area in order to form a mutually agreeable work = plan.

  This document has three main parts.  The first part = provides an
  overview of the KARP effort.  The second part lists the = threats from
  RFC 4593, Generic Threats To Routing Protocols, that are in = scope for
  attacks against routing protocols' transport systems, including = any
  mechanisms built into the routing protocols themselves, = which
  accomplish packet authentication.  The third part = enumerates the
  requirements that routing protocol specifications must meet = when
  addressing those threats for RFC 6518's "Work Phase 1", the = update to
  a routing protocol's existing transport security.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-karp-thre= ats-reqs-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-threa= ts-reqs-05.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-karp-threats= -reqs/

_______________________________________________
karp mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp



-- =
----
IETF related email from
Gregory M. Lebovitz


bew@cisco.com





= --Apple-Mail=_D9B5744F-8B81-46AB-8A7A-4461D06B9B9A-- From turners@ieca.com Sat May 19 12:55:50 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 036DC21F8636 for ; Sat, 19 May 2012 12:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.698 X-Spam-Level: X-Spam-Status: No, score=-101.698 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5e3Y4wKYQJXu for ; Sat, 19 May 2012 12:55:49 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.216.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFA921F8610 for ; Sat, 19 May 2012 12:55:49 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id A693769EF8611; Sat, 19 May 2012 14:55:48 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 9C67769EF85F1 for ; Sat, 19 May 2012 14:55:48 -0500 (CDT) Received: from [96.231.128.111] (port=43302 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SVpki-0001ur-97 for karp@ietf.org; Sat, 19 May 2012 14:55:48 -0500 Message-ID: <4FB7FAC3.70701@ieca.com> Date: Sat, 19 May 2012 15:55:47 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: karp@ietf.org References: <02717414-847B-4E3C-9F47-7AE30947F052@cisco.com> In-Reply-To: <02717414-847B-4E3C-9F47-7AE30947F052@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-128-111.washdc.east.verizon.net (thunderfish.local) [96.231.128.111]:43302 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: Re: [karp] WGLC of draft-ietf-karp-ospf-analysis-03 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 19:55:50 -0000 Quick question: Should the OSPFv3 section discuss RFC 6506: Supporting Authentication Trailer for OSPFv3? spt On 5/18/12 3:24 PM, Brian Weis wrote: > Folks, > > The KARP Analysis of OSPF document has been stable for some time, and the authors believe it is in accordance with both the KARP Design Guide (RFC 6518) and the Threats-Reqs draft (draft-ietf-karp-threats-reqs-05). The chairs are therefore asking for a WG last call, with the view of sending this to our AD for publication as an Informational RFC. Please send any remaining comments you have on this document to the list by June 1, 2012. > > > Thanks, > Brian& Joel > > > > _______________________________________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/listinfo/karp > From hartmans@mit.edu Mon May 28 04:26:16 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1573321F84B6 for ; Mon, 28 May 2012 04:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.987 X-Spam-Level: X-Spam-Status: No, score=-102.987 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzUAv+V04NVk for ; Mon, 28 May 2012 04:26:15 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A125221F84A1 for ; Mon, 28 May 2012 04:26:15 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4194920424; Mon, 28 May 2012 07:26:13 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 762704151; Mon, 28 May 2012 07:26:03 -0400 (EDT) From: Sam Hartman To: Sean Turner References: <02717414-847B-4E3C-9F47-7AE30947F052@cisco.com> <4FB7FAC3.70701@ieca.com> Date: Mon, 28 May 2012 07:26:03 -0400 In-Reply-To: <4FB7FAC3.70701@ieca.com> (Sean Turner's message of "Sat, 19 May 2012 15:55:47 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: karp@ietf.org Subject: Re: [karp] WGLC of draft-ietf-karp-ospf-analysis-03 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 11:26:16 -0000 >>>>> "Sean" == Sean Turner writes: Sean> Quick question: Should the OSPFv3 section discuss RFC 6506: Sean> Supporting Authentication Trailer for OSPFv3? I guess we can update to add a reference if you like. I kind of view this as work that lead to that RFC though. From turners@ieca.com Mon May 28 11:06:23 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EAC21F8672 for ; Mon, 28 May 2012 11:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.105 X-Spam-Level: X-Spam-Status: No, score=-102.105 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6N9vIxhT6FPy for ; Mon, 28 May 2012 11:06:23 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [67.18.82.4]) by ietfa.amsl.com (Postfix) with ESMTP id EC60D21F866D for ; Mon, 28 May 2012 11:06:22 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 9338971E292DE; Mon, 28 May 2012 13:06:22 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 85A7971E292A3 for ; Mon, 28 May 2012 13:06:22 -0500 (CDT) Received: from [71.191.15.83] (port=41263 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZ4Kk-00079k-6w; Mon, 28 May 2012 13:06:22 -0500 Message-ID: <4FC3BE9D.7080506@ieca.com> Date: Mon, 28 May 2012 14:06:21 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Sam Hartman References: <02717414-847B-4E3C-9F47-7AE30947F052@cisco.com> <4FB7FAC3.70701@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [71.191.15.83]:41263 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: karp@ietf.org Subject: Re: [karp] WGLC of draft-ietf-karp-ospf-analysis-03 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 18:06:23 -0000 On 5/28/12 7:26 AM, Sam Hartman wrote: >>>>>> "Sean" == Sean Turner writes: > > Sean> Quick question: Should the OSPFv3 section discuss RFC 6506: > Sean> Supporting Authentication Trailer for OSPFv3? > > I guess we can update to add a reference if you like. I kind of view > this as work that lead to that RFC though. I think it's worth pointing out that one of the follow-on documents that this analysis was going to produce is completed. Also should this sentence be changed: OLD: A security solution will be developed for OSPFv2 and OSPFv3 based on the OSPFv2 cryptographic authentication option. NEW: A security solution will be developed for OSPFv3 based on the OSPFv2 cryptographic authentication option. Shouldn't this draft also discuss the Only talking about OPSFv3? It seems odd to develop a security solution for OSPv2 based on the already defined OSPFv3 option. Isn't [I-D.ietf-ospf-security-extension-manual-keying] also a solution output that should be discussed in s5? some nits from nitchecker: Need an IANA considerations section. r/I-D.ietf-opsec-routing-protocols-crypto-issues/RFC6309 r/draft-ietf-opsec-routing-protocols-crypto-issues/RFC6309 r/draft-ietf-karp-threats-reqs-04/draft-ietf-karp-threats-reqs-05 r/draft-ietf-ospf-security-extension-manual-keying-01/draft-ietf-ospf-security-extension-manual-keying-02 spt From hartmans@mit.edu Mon May 28 12:59:04 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139D621F86A4 for ; Mon, 28 May 2012 12:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.807 X-Spam-Level: X-Spam-Status: No, score=-102.807 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsCCLLeyKeTA for ; Mon, 28 May 2012 12:59:03 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA8821F86A3 for ; Mon, 28 May 2012 12:59:03 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 01AF520424; Mon, 28 May 2012 15:59:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 95FB14151; Mon, 28 May 2012 15:58:51 -0400 (EDT) From: Sam Hartman To: Sean Turner References: <02717414-847B-4E3C-9F47-7AE30947F052@cisco.com> <4FB7FAC3.70701@ieca.com> <4FC3BE9D.7080506@ieca.com> Date: Mon, 28 May 2012 15:58:51 -0400 In-Reply-To: <4FC3BE9D.7080506@ieca.com> (Sean Turner's message of "Mon, 28 May 2012 14:06:21 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , karp@ietf.org Subject: Re: [karp] WGLC of draft-ietf-karp-ospf-analysis-03 X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 19:59:04 -0000 Yes. The intent is to move towards OSPF v2-like options not v3-like options. From gregory.ietf@gmail.com Thu May 31 07:57:58 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E387C21F86E2 for ; Thu, 31 May 2012 07:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jE01BB5P7xmZ for ; Thu, 31 May 2012 07:57:57 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 07ABD21F86DB for ; Thu, 31 May 2012 07:57:56 -0700 (PDT) Received: by dacx6 with SMTP id x6so1401527dac.31 for ; Thu, 31 May 2012 07:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cngovwdFdtnbMnVIwVAMi+cL3CbkGD2mdbHRKNhaWhY=; b=VTEq0Q4Brldtx6+SPHd/Byq7l8r4iZXVx6gDcKA0mxWq72vuRnfi91muh8wb5AD2r6 m6Nh3RNDDxtcXm+bbN2TKiQjlJk3t2gNR3xyIXWmlieyxoMPIY2V74HkAkFkAgX+2fIP 6fNtBEVp4JKeru/rcdH2di8Lrb+BrtXY3f71KgWtGiFvHSp0s0EKq7eEnpdXboaxzMxe kN2VfQ8t+v0sG8tgWdeFwBE7ZXpUCKAs3FlX7iP/gb9SK4bh6oyqGbYLtAtzNghyusjy Trib30X5M8spkTGsyaDuJOwumIYpRul9tRSduKJVQBnZBnrXH6r/tb5levdBS8D23Gmc R6yQ== MIME-Version: 1.0 Received: by 10.68.203.66 with SMTP id ko2mr563350pbc.84.1338476276291; Thu, 31 May 2012 07:57:56 -0700 (PDT) Received: by 10.143.67.2 with HTTP; Thu, 31 May 2012 07:57:56 -0700 (PDT) In-Reply-To: References: <20120510175313.23420.15177.idtracker@ietfa.amsl.com> Date: Thu, 31 May 2012 07:57:56 -0700 Message-ID: From: Gregory Lebovitz To: Uma Chunduri , "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=047d7b10cfb7fd18cb04c1564a2d Cc: "karp@ietf.org" Subject: Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:57:59 -0000 --047d7b10cfb7fd18cb04c1564a2d Content-Type: text/plain; charset=ISO-8859-1 Hello, Uma. Thanks for your input. No, I don't believe it's too late. It looks like these are all fairly minor clarification issues, and no major content debates, which gives me great hope that we are very near completed!! Please find comments inline below. Let me know if the proposed resolution text for each point is ok. Once agreed, I'll issue draft-06. Manav, could you please address the last issue ASAP? Note to community: I have updated the karp-threats-reqs issue tracker (google doc, public access) with ID's for the noted items below. Thanks again for the review, Gregory On Fri, May 18, 2012 at 5:00 PM, Uma Chunduri wrote: > ** > Dear Authors, > > I read this version and the document is in good shape. > > If, it's not too late, I have few comments on the 05 version. > > > 1.a) Page 4: Section 1. Introduction > Third Bullet: > " o Create specifications for cryptographic validation of routing > message content." > "The third bullet is being addressed in the SIDR > working group." > Though we can understand what SIDR is doing - "routing message > content" just doesn't imply BGP message? > I can understand what you are trying to say, but IMO, what is said is > not representative. > > How about this: NEW: The third bullet is being addressed in other efforts within the IETF. *For example, BGP message content validity is being addressed in the SIDR working group.* * * *(Tracker ID 08)* > b) 7. Sec 2.4: > "Message content validity (routing database validity). This work > is being addressed in other IETF efforts, like SIDR." > > I am not sure "routing database" above is synonymous to BGP. Be > explicit calling out, as this can wrong impression on SIDR scope. > How about this: NEW: This work is being addressed in other efforts within the IETF. *For example, BGP message content validity is being addressed in the SIDR working group.* * * *(Tracker ID 08)* > > > 2. Section 1, Last paragraph, unnecessary ending quote. > Got it. Tracker ID 09. > > 3. Section 1.1, Page 6: > "If session or traffic > keys are being used, KMP is responsible for generating them and > determining when they should be renewed." > > This is not necessarily the only way as it sounds. KMP can also be used > for only master key generation and > traffic keys are generated from the same by the master key consumer. > And also determining when the keys should > be renewed may not be KMP function. So I am not quite you define KMP > this way. > Understood. How about this: NEW: In some routing protocols traffic keys are derived by the routing protocol from session / master keys. In this case, KMP is responsible for the session / master key generation. In other cases, there are only traffic keys (and no session / master keys), and KMP is responsible for the traffic key generation. tracker ID 10. > > > 4. Sec 2.2: > "However,in the spirit of incremental > deployment, we first addressed issues like cryptographic algorithm > agility, replay attacks, and TCP session resetting in the base TCP-AO > protocol, and then later began work to layer key management on top of > it." > Though authors might have worked on AO, but the above can be better > represented how TCP-AO is planned to be evolved. > TCP-AO's published RFC contains "cryptographic algorithm agility, replay attacks, and TCP session resetting". And it is true that after AO's RFC published, the community began work on the key management for it. So I think the sentence is ok. No change. > > 5. Sec 2.3, Page 13, Point 7. > " For example, designers should aim to re-use the key management > protocol that will be defined for BGP's TCP-AO key establishment > for as many other routing protocols as possible." > > Why this should be BGP's TCP-AO ?? I presume, TCP-AO is a generic > protocol > and any TCP-based pair wise RP or client/server can use this. It's > better to > say "other routing protocols with similar > [characteristics/properties] as possible" > Understood. How about this: NEW: For example, designers should aim to re-use the key management protocol that will be defined for BGP, which will establish keys for TCP-AO, for as many other routing protocols with similar characteristics and properties as possible. tracker ID 11 > > > 6. Section-4 Page 20 > >>document(s)." > Extra ending quote. > Got it. ID 09 > 7." 21. Given the number of routers that would require the new > authentication mechanisms in a typical ISP deployment, solutions > can increase their appeal by minimizing the burden imposed on > all routers in favor of confining significant work loads to a > relatively small number of devices. Optional features or > increased assurance that engenders more pervasive processing > loads MAY be made available for deployments where the additional > resources are economically justifiable." > What is the requirement? > We've been back and forth on this requirement since its original insertion, i.e. you are not the only one with this question. I'm going to let my co-author, Manav, handle this question. I've entered it on the tracker as ID 12. Manav, could address this ASAP? Thanks again, Uma, for the detailed review, Gregory > > -- > Uma C. > > > ------------------------------ > *From:* karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] *On Behalf > Of *Gregory Lebovitz > *Sent:* Thursday, May 10, 2012 11:04 AM > *To:* karp@ietf.org; Brian Weis; Bhatia, Manav (Manav) > *Subject:* Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt > > Hey all, > This version -05 addressed all the known content issues (a total of 6) > that were brought to our attention during the 2nd WG LC. > > Brian - I think we are ready to go back for IESG approval. > > FYI, we started a simple GoogleDoc tracker for this last version. It is > located here: > > > https://docs.google.com/document/d/10lSS99Rq3wCDKgyrNuv-9dxbbInOIIVDb_BWaPxrm9Q/edit > > Hope it helps, > Gregory > > On Thu, May 10, 2012 at 10:53 AM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Keying and Authentication for >> Routing Protocols Working Group of the IETF. >> >> Title : Keying and Authentication for Routing Protocols >> (KARP) Overview, Threats, and Requirements >> Author(s) : Gregory Lebovitz >> Manav Bhatia >> Filename : draft-ietf-karp-threats-reqs-05.txt >> Pages : 32 >> Date : 2012-05-10 >> >> Different routing protocols exist and each employs its own mechanism >> for securing the protocol packets on the wire. While most already >> have some method for accomplishing cryptographic message >> authentication, in many cases the existing methods are dated, >> vulnerable to attack, and employ cryptographic algorithms that have >> been deprecated. The "Keying and Authentication for Routing >> Protocols" (KARP) effort aims to overhaul and improve these >> mechanisms. >> >> This document does not contain protocol specifications. Instead, it >> defines the areas where protocol specification work is needed and a >> set of requirements for KARP design teams to follow. RFC 6518, >> "Keying and Authentication for Routing Protocols (KARP) Design >> Guidelines" is a companion to this document; KARP design teams will >> use them together to review and overhaul routing protocols. These >> two documents reflect the input of both the IETF's Security Area and >> Routing Area in order to form a mutually agreeable work plan. >> >> This document has three main parts. The first part provides an >> overview of the KARP effort. The second part lists the threats from >> RFC 4593, Generic Threats To Routing Protocols, that are in scope for >> attacks against routing protocols' transport systems, including any >> mechanisms built into the routing protocols themselves, which >> accomplish packet authentication. The third part enumerates the >> requirements that routing protocol specifications must meet when >> addressing those threats for RFC 6518's "Work Phase 1", the update to >> a routing protocol's existing transport security. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ >> >> _______________________________________________ >> karp mailing list >> karp@ietf.org >> https://www.ietf.org/mailman/listinfo/karp >> > > > > -- > ---- > IETF related email from > Gregory M. Lebovitz > > -- ---- IETF related email from Gregory M. Lebovitz --047d7b10cfb7fd18cb04c1564a2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, Uma. Thanks for your input.=A0

No, I don't believe = it's too late. It looks like these are all fairly minor clarification i= ssues, and no major content debates, which gives me great hope that we are = very near completed!!=A0

Please find comments inline below. Let me know if the p= roposed resolution text for each point is ok. Once agreed, I'll issue d= raft-06.=A0

Manav, could you please address the la= st issue ASAP?

Note to community: =A0I have updated the karp-threats-r= eqs issue tracker (google doc, public access) with ID's for the noted i= tems below.

Thanks again for the review,
Gregory


On Fri, May 18, 2012 a= t 5:00 PM, Uma Chunduri <uma.chunduri@ericsson.com> = wrote:
Dear Authors,
=A0
I read this version and the document is in good=20 shape.
=A0
If, it's not too late, I have few comments=A0on the 05=20 version.
=A0
=A0
1.a) Page 4: Section 1.=A0=20 Introduction
=A0=A0=A0 Third Bullet:
=A0=A0=A0=20 "=A0=A0 o=A0 Create specifications for cryptographic validation of=20 routing
=A0=A0=A0=A0=A0 message=20 content."
=A0=A0=A0 "The third bullet is being addressed in th= e=20 SIDR
=A0=A0 working group."
=A0=A0 Though we can understand=20 what SIDR is doing -=A0 "routing message content" just doesn'= t=20 imply=A0BGP message?
=A0=A0 I=20 can=A0understand what you are trying to=20 say, but IMO, what is said is not representative.
=A0

How about this:
<= div>NEW: The third bullet is being addressed in other efforts within the IE= TF.=A0For example, BGP message= content validity is being addressed in the SIDR working group.<= /span>

(= Tracker ID 08)
=A0
=A0 b) 7. Sec 2.4:
=A0=A0=20 "Message content validity (routing database validity).=A0 This=20 work
=A0=A0=A0=A0=A0 is being addressed in other IETF efforts,=20 like SIDR."
=A0
=A0=A0 I am not sure "rout= ing=20 database" above is synonymous to BGP. Be explicit calling out, as this= can wrong=20 impression on SIDR scope.

How about this:
NEW: This work is being addressed in other= efforts within the IETF.=A0Fo= r example, BGP message content validity is being addressed in the SIDR work= ing group.

(= Tracker ID 08)
=A0
=A0

2. Section 1, Last paragrap= h,=20 unnecessary ending quote.

Got it. Tracker ID 09.
=A0
=
=A0
3. Section 1.1, Page=20 6:
=A0=A0 "If session or traffic
=A0=A0=A0=A0=A0 keys=20 are being used, KMP is responsible for generating them=20 and
=A0=A0=A0=A0=A0 determining when they should be=20 renewed."
=A0
=A0=A0 This is not necessarily= =20 the only way as it sounds. KMP can also be used for only master key generat= ion=20 and
=A0=A0 traffic keys are generated from the same by the master key= =20 consumer. And also determining when the keys should
=A0=A0 be renewed= =20 may not be KMP function. So I am not quite you define KMP this way.<= /div>

Understood. How about this:

NEW: =A0 In some routing protocols traffic keys are d= erived by the routing protocol from session / master keys. In this case, KM= P=A0is responsible for the session / master key generation.=A0In other case= s, there are only traffic keys (and no session / master keys), and KMP is r= esponsible for the traffic key generation.

tracker ID 10.
=A0
=A0

4. Sec 2.2:
=A0=A0=20 "However,in the spirit of incremental
=A0=A0 deployment, we first= =20 addressed issues like cryptographic algorithm
=A0=A0 agility, replay=20 attacks, and TCP session resetting in the base TCP-AO
=A0=A0 protocol,= =20 and then later began work to layer key management on top of
=A0=A0=20 it."
=A0=A0 Though authors might have worked on AO, but the above c= an=20 be better
=A0=A0 represented how TCP-AO is planned to=A0be evolved.

TCP-AO's p= ublished RFC contains "cryptographic algorithm
=A0=A0 agility= , replay attacks, and TCP session resetting". And it is true that afte= r AO's RFC published, the community began work on the key management fo= r it. So I think the sentence is ok. No change.
=A0
=A0
5. Sec 2.3, Page 13, Point=20 7.
=A0=A0 " For example, designers should aim to re-use the key=20 management
=A0=A0=A0=A0=A0=A0 protocol that will be defined=20 for BGP's TCP-AO key establishment
=A0=A0=A0=A0=A0=A0 for=20 as many other routing protocols as possible."
=A0=A0=A0=A0
= =A0=A0=A0=A0=A0=A0 Why this should=A0be=20 BGP's TCP-AO ??=A0I presume,=20 TCP-AO is a generic protocol
=A0=A0=A0=A0=A0=A0 and=20 any TCP-based pair wise RP or client/server can use this. It&#= 39;s better to=20
=A0=A0=A0=A0=A0=A0 say "other routing protocols with=20 similar [characteristics/properties] as possible"=

Understood. How about this:
NEW: =A0For example, designers should aim to re-use the key managem= ent protocol that will be defined for BGP, which will establish keys for TC= P-AO, for as many other routing protocols with similar characteristics and = properties as possible.=A0

tracker ID 11
=A0

= =A0
=A0

6. Section-4 Page=20 20
=A0=A0 >>document(s)."
=A0=A0 Extra ending=20 quote.=A0
<= /blockquote>

Got it. ID 09
=A0
7."=A0=A0 21.=A0 Given the= =20 number of routers that would require the=20 new
=A0=A0=A0=A0=A0=A0=A0 authentication mechanisms in a=20 typical ISP deployment, solutions
=A0=A0=A0=A0=A0=A0=A0=20 can increase their appeal by minimizing the burden imposed=20 on
=A0=A0=A0=A0=A0=A0=A0 all routers in favor of=20 confining significant work loads to=20 a
=A0=A0=A0=A0=A0=A0=A0 relatively small number of=20 devices.=A0 Optional features=20 or
=A0=A0=A0=A0=A0=A0=A0 increased assurance that=20 engenders more pervasive=20 processing
=A0=A0=A0=A0=A0=A0=A0 loads MAY be made=20 available for deployments where the=20 additional
=A0=A0=A0=A0=A0=A0=A0 resources are=20 economically justifiable."
=A0=A0=A0=A0 What is the=20 requirement?

We've b= een back and forth on this requirement since its original insertion, i.e. y= ou are not the only one with this question. I'm going to let my co-auth= or, Manav, handle this question. I've entered it on the tracker as ID 1= 2. Manav, could address this ASAP?

Thanks again, Uma, for the detailed review,
G= regory

=A0=A0
=
=A0
--
Uma C.
=A0

From: karp-bounces@ietf.org=20 [mailto:karp-bou= nces@ietf.org] On Behalf Of Gregory=20 Lebovitz
Sent: Thursday, May 10, 2012 11:04 AM
To:=20 karp@ietf.org; Brian= Weis; Bhatia, Manav (Manav)
Subject: Re: [karp]=20 I-D Action: draft-ietf-karp-threats-reqs-05.txt

=
Hey all,
This version -05 addressed all the known content issues (a total of 6)= that=20 were brought to our attention during the 2nd WG LC.

Brian - I think we are ready to go back for IESG approval.

FYI, we started a simple GoogleDoc tracker for this last version. It i= s=20 located here:=A0


Hope it helps,
Gregory

On Thu, May 10, 2012 at 10:53 AM, <inter= net-drafts@ietf.org> wrote:

A New Internet-Draft is available= from the on-line=20 Internet-Drafts directories. This draft is a work item of the Keying and= =20 Authentication for Routing Protocols Working Group of the IETF.

= =A0=20 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Keying and=20 Authentication for Routing Protocols (KARP) Overview, Threats, and=20 Requirements
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 :=20 Gregory Lebovitz
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0Manav Bhatia
=A0 =A0 =A0=20 =A0Filename =A0 =A0 =A0 =A0:=20 draft-ietf-karp-threats-reqs-05.txt
=A0 =A0 =A0 =A0Pages =A0=20 =A0 =A0 =A0 =A0 : 32
=A0 =A0 =A0 =A0Date =A0=20 =A0 =A0 =A0 =A0 =A0: 2012-05-10

=A0 Different routing=20 protocols exist and each employs its own mechanism
=A0 for securing th= e=20 protocol packets on the wire. =A0While most already
=A0 have some=20 method for accomplishing cryptographic message
=A0 authentication, in= =20 many cases the existing methods are dated,
=A0 vulnerable to attack, a= nd=20 employ cryptographic algorithms that have
=A0 been deprecated. =A0The= =20 "Keying and Authentication for Routing
=A0 Protocols" (KARP)= effort aims=20 to overhaul and improve these
=A0 mechanisms.

=A0 This=20 document does not contain protocol specifications. =A0Instead, it
=A0= =20 defines the areas where protocol specification work is needed and a
= =A0=20 set of requirements for KARP design teams to follow. =A0RFC 6518,
=A0= =20 "Keying and Authentication for Routing Protocols (KARP) Design
= =A0=20 Guidelines" is a companion to this document; KARP design teams will<= br>=A0=20 use them together to review and overhaul routing protocols.=20 =A0These
=A0 two documents reflect the input of both the IETF's=20 Security Area and
=A0 Routing Area in order to form a mutually agreeab= le=20 work plan.

=A0 This document has three main parts. =A0The first=20 part provides an
=A0 overview of the KARP effort. =A0The second part= =20 lists the threats from
=A0 RFC 4593, Generic Threats To Routing=20 Protocols, that are in scope for
=A0 attacks against routing protocols= '=20 transport systems, including any
=A0 mechanisms built into the routing= =20 protocols themselves, which
=A0 accomplish packet authentication.=20 =A0The third part enumerates the
=A0 requirements that routing=20 protocol specifications must meet when
=A0 addressing those threats fo= r=20 RFC 6518's "Work Phase 1", the update to
=A0 a routing p= rotocol's=20 existing transport security.


A URL for this Internet-Draft=20 is:
http://www.ietf.org/internet-drafts/dra= ft-ietf-karp-threats-reqs-05.txt

Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/=

This=20 Internet-Draft can be retrieved at:
ftp://ft= p.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt

The=20 IETF datatracker page for this Internet-Draft is:
ht= tps://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/

___= ____________________________________________
karp=20 mailing list
karp@i= etf.org
https://www.ietf.org/mailman/listinfo/karp



--
----
IETF related email from
Gregory M.=20 Lebovitz




--
----
IETF= related email from
Gregory M. Lebovitz

--047d7b10cfb7fd18cb04c1564a2d-- From gregory.ietf@gmail.com Thu May 31 08:03:40 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF7421F875B for ; Thu, 31 May 2012 08:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMbvRv34TyRh for ; Thu, 31 May 2012 08:03:39 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29C7A21F8757 for ; Thu, 31 May 2012 08:03:39 -0700 (PDT) Received: by dacx6 with SMTP id x6so1407927dac.31 for ; Thu, 31 May 2012 08:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=1b8SFoD6ngUycE/CH6jEL5XFWyAvkXW5KYgLxd+1cmE=; b=fjRvA2H7BLg7a9udQCZoGJLCGxjEL3tLMjI9hybrybrrCImyTYI9m+TDPswDka8aa8 kUcqr36x/w0TwjJMlw1+/FODEbOzl8bGJlvzmZY+8JPDi4tKnton2FnfcmuQLib4+0YQ zIxKSziP8ssALK2ew58mmFhXUj+LamEvVCnQO0YieyP9g+vErYh3YgrvYJA5TedRg2t9 AYWc+AW5gl4tvqsM9JwEgGa1gQVDseoov25QnW/GnPKtZhHHogpU5MsaoH1UGGoqahIC W62etK65qwSbVg91vwSnDHtn6TBjUdaFM2XG+ROshjdRKSmsZIgLS2Tl0MvRy2jY+WVB Hb/g== MIME-Version: 1.0 Received: by 10.68.203.66 with SMTP id ko2mr601097pbc.84.1338476618659; Thu, 31 May 2012 08:03:38 -0700 (PDT) Received: by 10.143.67.2 with HTTP; Thu, 31 May 2012 08:03:38 -0700 (PDT) Date: Thu, 31 May 2012 08:03:38 -0700 Message-ID: From: Gregory Lebovitz To: "Bhatia, Manav (Manav)" , Brian Weis Content-Type: multipart/alternative; boundary=047d7b10cfb765384704c1565f62 Cc: "karp@ietf.org" Subject: [karp] Progressing draft-ietf-karp-threats-reqs-05.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 15:03:40 -0000 --047d7b10cfb765384704c1565f62 Content-Type: text/plain; charset=ISO-8859-1 Note to Chairs and AD: The issues noted below are minor text clarifications, and NOT so substantive -- and not at all contentious -- that an AD or IETF review should wait for them. Please proceed with the review process, and we'll roll these minor clarifications into a draft with any final AD / IETF review comments. Thanks, Gregory On Thu, May 31, 2012 at 7:57 AM, Gregory Lebovitz wrote: > Hello, Uma. Thanks for your input. > > No, I don't believe it's too late. It looks like these are all fairly > minor clarification issues, and no major content debates, which gives me > great hope that we are very near completed!! > > Please find comments inline below. Let me know if the proposed resolution > text for each point is ok. Once agreed, I'll issue draft-06. > > Manav, could you please address the last issue ASAP? > > Note to community: I have updated the karp-threats-reqs issue tracker > (google doc, public access) with ID's for the noted items below. > > Thanks again for the review, > Gregory > > > On Fri, May 18, 2012 at 5:00 PM, Uma Chunduri wrote: > >> ** >> Dear Authors, >> >> I read this version and the document is in good shape. >> >> If, it's not too late, I have few comments on the 05 version. >> >> >> 1.a) Page 4: Section 1. Introduction >> Third Bullet: >> " o Create specifications for cryptographic validation of routing >> message content." >> "The third bullet is being addressed in the SIDR >> working group." >> Though we can understand what SIDR is doing - "routing message >> content" just doesn't imply BGP message? >> I can understand what you are trying to say, but IMO, what is said is >> not representative. >> >> > > How about this: > NEW: The third bullet is being addressed in other efforts within the IETF. > *For example, BGP message content validity is being addressed in the SIDR > working group.* > * > * > *(Tracker ID 08)* > > >> b) 7. Sec 2.4: >> "Message content validity (routing database validity). This work >> is being addressed in other IETF efforts, like SIDR." >> >> I am not sure "routing database" above is synonymous to BGP. Be >> explicit calling out, as this can wrong impression on SIDR scope. >> > > How about this: > NEW: This work is being addressed in other efforts within the IETF. *For > example, BGP message content validity is being addressed in the SIDR > working group.* > * > * > *(Tracker ID 08)* > > >> >> >> 2. Section 1, Last paragraph, unnecessary ending quote. >> > > Got it. Tracker ID 09. > > >> >> 3. Section 1.1, Page 6: >> "If session or traffic >> keys are being used, KMP is responsible for generating them and >> determining when they should be renewed." >> >> This is not necessarily the only way as it sounds. KMP can also be >> used for only master key generation and >> traffic keys are generated from the same by the master key consumer. >> And also determining when the keys should >> be renewed may not be KMP function. So I am not quite you define KMP >> this way. >> > > Understood. How about this: > > NEW: In some routing protocols traffic keys are derived by the routing > protocol from session / master keys. In this case, KMP is responsible for > the session / master key generation. In other cases, there are only traffic > keys (and no session / master keys), and KMP is responsible for the traffic > key generation. > > tracker ID 10. > > >> >> >> 4. Sec 2.2: >> "However,in the spirit of incremental >> deployment, we first addressed issues like cryptographic algorithm >> agility, replay attacks, and TCP session resetting in the base TCP-AO >> protocol, and then later began work to layer key management on top of >> it." >> Though authors might have worked on AO, but the above can be better >> represented how TCP-AO is planned to be evolved. >> > > TCP-AO's published RFC contains "cryptographic algorithm > agility, replay attacks, and TCP session resetting". And it is true > that after AO's RFC published, the community began work on the key > management for it. So I think the sentence is ok. No change. > > >> >> 5. Sec 2.3, Page 13, Point 7. >> " For example, designers should aim to re-use the key management >> protocol that will be defined for BGP's TCP-AO key establishment >> for as many other routing protocols as possible." >> >> Why this should be BGP's TCP-AO ?? I presume, TCP-AO is a generic >> protocol >> and any TCP-based pair wise RP or client/server can use this. >> It's better to >> say "other routing protocols with similar >> [characteristics/properties] as possible" >> > > Understood. How about this: > NEW: For example, designers should aim to re-use the key management > protocol that will be defined for BGP, which will establish keys for > TCP-AO, for as many other routing protocols with similar characteristics > and properties as possible. > > tracker ID 11 > > > > >> >> >> 6. Section-4 Page 20 >> >>document(s)." >> Extra ending quote. >> > > Got it. ID 09 > > >> 7." 21. Given the number of routers that would require the new >> authentication mechanisms in a typical ISP deployment, solutions >> can increase their appeal by minimizing the burden imposed on >> all routers in favor of confining significant work loads to a >> relatively small number of devices. Optional features or >> increased assurance that engenders more pervasive processing >> loads MAY be made available for deployments where the additional >> resources are economically justifiable." >> What is the requirement? >> > > We've been back and forth on this requirement since its original > insertion, i.e. you are not the only one with this question. I'm going to > let my co-author, Manav, handle this question. I've entered it on the > tracker as ID 12. Manav, could address this ASAP? > > Thanks again, Uma, for the detailed review, > Gregory > > > >> >> -- >> Uma C. >> >> >> ------------------------------ >> *From:* karp-bounces@ietf.org [mailto:karp-bounces@ietf.org] *On Behalf >> Of *Gregory Lebovitz >> *Sent:* Thursday, May 10, 2012 11:04 AM >> *To:* karp@ietf.org; Brian Weis; Bhatia, Manav (Manav) >> *Subject:* Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt >> >> Hey all, >> This version -05 addressed all the known content issues (a total of 6) >> that were brought to our attention during the 2nd WG LC. >> >> Brian - I think we are ready to go back for IESG approval. >> >> FYI, we started a simple GoogleDoc tracker for this last version. It is >> located here: >> >> >> https://docs.google.com/document/d/10lSS99Rq3wCDKgyrNuv-9dxbbInOIIVDb_BWaPxrm9Q/edit >> >> Hope it helps, >> Gregory >> >> On Thu, May 10, 2012 at 10:53 AM, wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. This draft is a work item of the Keying and Authentication for >>> Routing Protocols Working Group of the IETF. >>> >>> Title : Keying and Authentication for Routing Protocols >>> (KARP) Overview, Threats, and Requirements >>> Author(s) : Gregory Lebovitz >>> Manav Bhatia >>> Filename : draft-ietf-karp-threats-reqs-05.txt >>> Pages : 32 >>> Date : 2012-05-10 >>> >>> Different routing protocols exist and each employs its own mechanism >>> for securing the protocol packets on the wire. While most already >>> have some method for accomplishing cryptographic message >>> authentication, in many cases the existing methods are dated, >>> vulnerable to attack, and employ cryptographic algorithms that have >>> been deprecated. The "Keying and Authentication for Routing >>> Protocols" (KARP) effort aims to overhaul and improve these >>> mechanisms. >>> >>> This document does not contain protocol specifications. Instead, it >>> defines the areas where protocol specification work is needed and a >>> set of requirements for KARP design teams to follow. RFC 6518, >>> "Keying and Authentication for Routing Protocols (KARP) Design >>> Guidelines" is a companion to this document; KARP design teams will >>> use them together to review and overhaul routing protocols. These >>> two documents reflect the input of both the IETF's Security Area and >>> Routing Area in order to form a mutually agreeable work plan. >>> >>> This document has three main parts. The first part provides an >>> overview of the KARP effort. The second part lists the threats from >>> RFC 4593, Generic Threats To Routing Protocols, that are in scope for >>> attacks against routing protocols' transport systems, including any >>> mechanisms built into the routing protocols themselves, which >>> accomplish packet authentication. The third part enumerates the >>> requirements that routing protocol specifications must meet when >>> addressing those threats for RFC 6518's "Work Phase 1", the update to >>> a routing protocol's existing transport security. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt >>> >>> The IETF datatracker page for this Internet-Draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ >>> >>> _______________________________________________ >>> karp mailing list >>> karp@ietf.org >>> https://www.ietf.org/mailman/listinfo/karp >>> >> >> >> >> -- >> ---- >> IETF related email from >> Gregory M. Lebovitz >> >> > > > -- > ---- > IETF related email from > Gregory M. Lebovitz > > -- ---- IETF related email from Gregory M. Lebovitz --047d7b10cfb765384704c1565f62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Note to Chairs and AD:
=A0The issues noted below are minor text clarifi= cations, and NOT so substantive -- and not at all contentious -- that an AD= or IETF review should wait for them. Please proceed with the review proces= s, and we'll roll these minor clarifications into a draft with any fina= l AD / IETF review comments.

Thanks,
Gregory

On Thu, May 31, 2012 at 7:57 AM, Gregory Lebovitz &l= t;gregory.ietf@= gmail.com> wrote:
Hello, Uma. Thanks for your input.=A0
No, I don't believe it's too late. It looks like these are a= ll fairly minor clarification issues, and no major content debates, which g= ives me great hope that we are very near completed!!=A0

Please find comments inline below. Let me know if the p= roposed resolution text for each point is ok. Once agreed, I'll issue d= raft-06.=A0

Manav, could you please address the la= st issue ASAP?

Note to community: =A0I have updated the karp-threats-r= eqs issue tracker (google doc, public access) with ID's for the noted i= tems below.

Thanks again for the review,
Gregory


On F= ri, May 18, 2012 at 5:00 PM, Uma Chunduri <uma.chunduri@ericsson.c= om> wrote:
Dear Authors,
=A0
I read this version and the document is in good=20 shape.
=A0
If, it's not too late, I have few comments=A0on the 05=20 version.
=A0
=A0
1.a) Page 4: Section 1.=A0=20 Introduction
=A0=A0=A0 Third Bullet:
=A0=A0=A0=20 "=A0=A0 o=A0 Create specifications for cryptographic validation of=20 routing
=A0=A0=A0=A0=A0 message=20 content."
=A0=A0=A0 "The third bullet is being addressed in th= e=20 SIDR
=A0=A0 working group."
=A0=A0 Though we can understand=20 what SIDR is doing -=A0 "routing message content" just doesn'= t=20 imply=A0BGP message?
=A0=A0 I=20 can=A0understand what you are trying to=20 say, but IMO, what is said is not representative.
=A0

How about this:<= /div>
NEW: The third bullet is being addressed in other efforts within = the IETF.=A0For example, BGP message content val= idity is being addressed in the SIDR working group.

(Tracker ID 08)
=A0
=A0 b) 7. Sec 2.4:
=A0=A0=20 "Message content validity (routing database validity).=A0 This=20 work
=A0=A0=A0=A0=A0 is being addressed in other IETF efforts,=20 like SIDR."
=A0
=A0=A0 I am not sure "rout= ing=20 database" above is synonymous to BGP. Be explicit calling out, as this= can wrong=20 impression on SIDR scope.

How about this:
NEW: This work is being addressed in= other efforts within the IETF.=A0For example, B= GP message content validity is being addressed in the SIDR working group.

(Tracker ID 08)
=A0
=A0

2. Section 1, Last paragrap= h,=20 unnecessary ending quote.

Got it. Tracker ID 09.
=A0
=A0
3. Section 1.1, Page=20 6:
=A0=A0 "If session or traffic
=A0=A0=A0=A0=A0 keys=20 are being used, KMP is responsible for generating them=20 and
=A0=A0=A0=A0=A0 determining when they should be=20 renewed."
=A0
=A0=A0 This is not necessarily= =20 the only way as it sounds. KMP can also be used for only master key generat= ion=20 and
=A0=A0 traffic keys are generated from the same by the master key= =20 consumer. And also determining when the keys should
=A0=A0 be renewed= =20 may not be KMP function. So I am not quite you define KMP this way.<= /div>

Understood. How about thi= s:

NEW: =A0 In some routing protocols traffic keys= are derived by the routing protocol from session / master keys. In this ca= se, KMP=A0is responsible for the session / master key generation.=A0In othe= r cases, there are only traffic keys (and no session / master keys), and KM= P is responsible for the traffic key generation.

tracker ID 10.
=A0
=A0

4. Sec 2.2:
=A0=A0=20 "However,in the spirit of incremental
=A0=A0 deployment, we first= =20 addressed issues like cryptographic algorithm
=A0=A0 agility, replay=20 attacks, and TCP session resetting in the base TCP-AO
=A0=A0 protocol,= =20 and then later began work to layer key management on top of
=A0=A0=20 it."
=A0=A0 Though authors might have worked on AO, but the above c= an=20 be better
=A0=A0 represented how TCP-AO is planned to=A0be evolved.

TCP-AO&#= 39;s published RFC contains "cryptog= raphic algorithm
=A0=A0 agility, replay attacks, and TCP s= ession resetting". And it is true that after AO's RFC published, t= he community began work on the key management for it. So I think the senten= ce is ok. No change.
=A0
=A0
5. Sec 2.3, Page 13, Point=20 7.
=A0=A0 " For example, designers should aim to re-use the key=20 management
=A0=A0=A0=A0=A0=A0 protocol that will be defined=20 for BGP's TCP-AO key establishment
=A0=A0=A0=A0=A0=A0 for=20 as many other routing protocols as possible."
=A0=A0=A0=A0
= =A0=A0=A0=A0=A0=A0 Why this should=A0be=20 BGP's TCP-AO ??=A0I presume,=20 TCP-AO is a generic protocol
=A0=A0=A0=A0=A0=A0 and=20 any TCP-based pair wise RP or client/server can use this. It&#= 39;s better to=20
=A0=A0=A0=A0=A0=A0 say "other routing protocols with=20 similar [characteristics/properties] as possible"=

Understood. How about th= is:
NEW: =A0For example, designers should aim to re-use the key m= anagement protocol that will be defined for BGP, which will establish keys = for TCP-AO, for as many other routing protocols with similar characteristic= s and properties as possible.=A0

tracker ID 11
=A0

=A0
=A0

6. Section-4 Page=20 20
=A0=A0 >>document(s)."
=A0=A0 Extra ending=20 quote.=A0
<= /blockquote>

Got it. ID 09
=
=A0
7."=A0=A0 21.=A0 Given the= =20 number of routers that would require the=20 new
=A0=A0=A0=A0=A0=A0=A0 authentication mechanisms in a=20 typical ISP deployment, solutions
=A0=A0=A0=A0=A0=A0=A0=20 can increase their appeal by minimizing the burden imposed=20 on
=A0=A0=A0=A0=A0=A0=A0 all routers in favor of=20 confining significant work loads to=20 a
=A0=A0=A0=A0=A0=A0=A0 relatively small number of=20 devices.=A0 Optional features=20 or
=A0=A0=A0=A0=A0=A0=A0 increased assurance that=20 engenders more pervasive=20 processing
=A0=A0=A0=A0=A0=A0=A0 loads MAY be made=20 available for deployments where the=20 additional
=A0=A0=A0=A0=A0=A0=A0 resources are=20 economically justifiable."
=A0=A0=A0=A0 What is the=20 requirement?

We= 9;ve been back and forth on this requirement since its original insertion, = i.e. you are not the only one with this question. I'm going to let my c= o-author, Manav, handle this question. I've entered it on the tracker a= s ID 12. Manav, could address this ASAP?

Thanks again, Uma, for the detailed review,
G= regory

=A0=A0
=A0
--
Uma C.
=A0

From: karp-bounces@ietf.org=20 [mailto:karp-bou= nces@ietf.org] On Behalf Of Gregory=20 Lebovitz
Sent: Thursday, May 10, 2012 11:04 AM
To:=20 karp@ietf.org; Brian= Weis; Bhatia, Manav (Manav)
Subject: Re: [karp]=20 I-D Action: draft-ietf-karp-threats-reqs-05.txt

=
Hey all,
This version -05 addressed all the known content issues (a total of 6)= that=20 were brought to our attention during the 2nd WG LC.

Brian - I think we are ready to go back for IESG approval.

FYI, we started a simple GoogleDoc tracker for this last version. It i= s=20 located here:=A0


Hope it helps,
Gregory

On Thu, May 10, 2012 at 10:53 AM, <inter= net-drafts@ietf.org> wrote:

A New Internet-Draft is available= from the on-line=20 Internet-Drafts directories. This draft is a work item of the Keying and= =20 Authentication for Routing Protocols Working Group of the IETF.

= =A0=20 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Keying and=20 Authentication for Routing Protocols (KARP) Overview, Threats, and=20 Requirements
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 :=20 Gregory Lebovitz
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0 =A0 =A0Manav Bhatia
=A0 =A0 =A0=20 =A0Filename =A0 =A0 =A0 =A0:=20 draft-ietf-karp-threats-reqs-05.txt
=A0 =A0 =A0 =A0Pages =A0=20 =A0 =A0 =A0 =A0 : 32
=A0 =A0 =A0 =A0Date =A0=20 =A0 =A0 =A0 =A0 =A0: 2012-05-10

=A0 Different routing=20 protocols exist and each employs its own mechanism
=A0 for securing th= e=20 protocol packets on the wire. =A0While most already
=A0 have some=20 method for accomplishing cryptographic message
=A0 authentication, in= =20 many cases the existing methods are dated,
=A0 vulnerable to attack, a= nd=20 employ cryptographic algorithms that have
=A0 been deprecated. =A0The= =20 "Keying and Authentication for Routing
=A0 Protocols" (KARP)= effort aims=20 to overhaul and improve these
=A0 mechanisms.

=A0 This=20 document does not contain protocol specifications. =A0Instead, it
=A0= =20 defines the areas where protocol specification work is needed and a
= =A0=20 set of requirements for KARP design teams to follow. =A0RFC 6518,
=A0= =20 "Keying and Authentication for Routing Protocols (KARP) Design
= =A0=20 Guidelines" is a companion to this document; KARP design teams will<= br>=A0=20 use them together to review and overhaul routing protocols.=20 =A0These
=A0 two documents reflect the input of both the IETF's=20 Security Area and
=A0 Routing Area in order to form a mutually agreeab= le=20 work plan.

=A0 This document has three main parts. =A0The first=20 part provides an
=A0 overview of the KARP effort. =A0The second part= =20 lists the threats from
=A0 RFC 4593, Generic Threats To Routing=20 Protocols, that are in scope for
=A0 attacks against routing protocols= '=20 transport systems, including any
=A0 mechanisms built into the routing= =20 protocols themselves, which
=A0 accomplish packet authentication.=20 =A0The third part enumerates the
=A0 requirements that routing=20 protocol specifications must meet when
=A0 addressing those threats fo= r=20 RFC 6518's "Work Phase 1", the update to
=A0 a routing p= rotocol's=20 existing transport security.


A URL for this Internet-Draft=20 is:
http://www.ietf.org/internet-drafts/dra= ft-ietf-karp-threats-reqs-05.txt

Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/=

This=20 Internet-Draft can be retrieved at:
ftp://ft= p.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt

The=20 IETF datatracker page for this Internet-Draft is:
ht= tps://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/

___= ____________________________________________
karp=20 mailing list
karp@i= etf.org
https://www.ietf.org/mailman/listinfo/karp



--
----
IETF related email from
Gregory M.=20 Lebovitz




--
----
IETF related email from
Gregory M. Lebovi= tz




--
----
IETF= related email from
Gregory M. Lebovitz

--047d7b10cfb765384704c1565f62-- From uma.chunduri@ericsson.com Thu May 31 11:33:30 2012 Return-Path: X-Original-To: karp@ietfa.amsl.com Delivered-To: karp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C4121F85A2 for ; Thu, 31 May 2012 11:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, HTML_FONT_LOW_CONTRAST=0.124, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTP8SXrPZ8Xf for ; Thu, 31 May 2012 11:33:29 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3A94B21F8559 for ; Thu, 31 May 2012 11:33:29 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q4VIWxih012317; Thu, 31 May 2012 13:33:25 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.31]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 31 May 2012 14:33:22 -0400 From: Uma Chunduri To: Gregory Lebovitz , "Bhatia, Manav (Manav)" Date: Thu, 31 May 2012 14:33:20 -0400 Thread-Topic: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt Thread-Index: Ac0/PcYZATqpQRenQS6O6PrVLeOJ2QAGmnPw Message-ID: References: <20120510175313.23420.15177.idtracker@ietfa.amsl.com> In-Reply-To: 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_D1D8138DDF34B34B8BC68A11262D10792243A9D555EUSAACMS0701e_" MIME-Version: 1.0 Cc: "karp@ietf.org" Subject: Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt X-BeenThere: karp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for key management for routing and transport protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 18:33:31 -0000 --_000_D1D8138DDF34B34B8BC68A11262D10792243A9D555EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gregory, Changes look fine to me. See my comments in-line..[Uma] -- Uma C. ________________________________ From: Gregory Lebovitz [mailto:gregory.ietf@gmail.com] Sent: Thursday, May 31, 2012 7:58 AM To: Uma Chunduri; Bhatia, Manav (Manav) Cc: karp@ietf.org; Brian Weis Subject: Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt Hello, Uma. Thanks for your input. No, I don't believe it's too late. It looks like these are all fairly minor= clarification issues, and no major content debates, which gives me great h= ope that we are very near completed!! Please find comments inline below. Let me know if the proposed resolution t= ext for each point is ok. Once agreed, I'll issue draft-06. Manav, could you please address the last issue ASAP? Note to community: I have updated the karp-threats-reqs issue tracker (goo= gle doc, public access) with ID's for the noted items below. Thanks again for the review, Gregory On Fri, May 18, 2012 at 5:00 PM, Uma Chunduri > wrote: Dear Authors, I read this version and the document is in good shape. If, it's not too late, I have few comments on the 05 version. 1.a) Page 4: Section 1. Introduction Third Bullet: " o Create specifications for cryptographic validation of routing message content." "The third bullet is being addressed in the SIDR working group." Though we can understand what SIDR is doing - "routing message content"= just doesn't imply BGP message? I can understand what you are trying to say, but IMO, what is said is no= t representative. How about this: NEW: The third bullet is being addressed in other efforts within the IETF. = For example, BGP message content validity is being addressed in the SIDR wo= rking group. [Uma]: Sure. (Tracker ID 08) b) 7. Sec 2.4: "Message content validity (routing database validity). This work is being addressed in other IETF efforts, like SIDR." I am not sure "routing database" above is synonymous to BGP. Be explicit= calling out, as this can wrong impression on SIDR scope. How about this: NEW: This work is being addressed in other efforts within the IETF. For exa= mple, BGP message content validity is being addressed in the SIDR working g= roup. [Uma]: Sure. (Tracker ID 08) 2. Section 1, Last paragraph, unnecessary ending quote. Got it. Tracker ID 09. 3. Section 1.1, Page 6: "If session or traffic keys are being used, KMP is responsible for generating them and determining when they should be renewed." This is not necessarily the only way as it sounds. KMP can also be used = for only master key generation and traffic keys are generated from the same by the master key consumer. And= also determining when the keys should be renewed may not be KMP function. So I am not quite you define KMP thi= s way. Understood. How about this: NEW: In some routing protocols traffic keys are derived by the routing pr= otocol from session / master keys. In this case, KMP is responsible for the= session / master key generation. In other cases, there are only traffic ke= ys (and no session / master keys), and KMP is responsible for the traffic k= ey generation. [Uma]: Perhaps you can drop "session/" in the above, as that sounds more sy= nonymous to traffic keys rather than master key (both places). tracker ID 10. 4. Sec 2.2: "However,in the spirit of incremental deployment, we first addressed issues like cryptographic algorithm agility, replay attacks, and TCP session resetting in the base TCP-AO protocol, and then later began work to layer key management on top of it." Though authors might have worked on AO, but the above can be better represented how TCP-AO is planned to be evolved. TCP-AO's published RFC contains "cryptographic algorithm agility, replay attacks, and TCP session resetting". And it is true that= after AO's RFC published, the community began work on the key management f= or it. So I think the sentence is ok. No change. [Uma]: Ok. 5. Sec 2.3, Page 13, Point 7. " For example, designers should aim to re-use the key management protocol that will be defined for BGP's TCP-AO key establishment for as many other routing protocols as possible." Why this should be BGP's TCP-AO ?? I presume, TCP-AO is a generic pr= otocol and any TCP-based pair wise RP or client/server can use this. It's b= etter to say "other routing protocols with similar [characteristics/propertie= s] as possible" Understood. How about this: NEW: For example, designers should aim to re-use the key management protoc= ol that will be defined for BGP, which will establish keys for TCP-AO, for = as many other routing protocols with similar characteristics and properties= as possible. [ Uma]: Sure. tracker ID 11 6. Section-4 Page 20 >>document(s)." Extra ending quote. Got it. ID 09 7." 21. Given the number of routers that would require the new authentication mechanisms in a typical ISP deployment, solutions can increase their appeal by minimizing the burden imposed on all routers in favor of confining significant work loads to a relatively small number of devices. Optional features or increased assurance that engenders more pervasive processing loads MAY be made available for deployments where the additional resources are economically justifiable." What is the requirement? We've been back and forth on this requirement since its original insertion,= i.e. you are not the only one with this question. I'm going to let my co-a= uthor, Manav, handle this question. I've entered it on the tracker as ID 12= . Manav, could address this ASAP? Thanks again, Uma, for the detailed review, Gregory -- Uma C. ________________________________ From: karp-bounces@ietf.org [mailto:karp-boun= ces@ietf.org] On Behalf Of Gregory Lebovitz Sent: Thursday, May 10, 2012 11:04 AM To: karp@ietf.org; Brian Weis; Bhatia, Manav (Manav) Subject: Re: [karp] I-D Action: draft-ietf-karp-threats-reqs-05.txt Hey all, This version -05 addressed all the known content issues (a total of 6) that= were brought to our attention during the 2nd WG LC. Brian - I think we are ready to go back for IESG approval. FYI, we started a simple GoogleDoc tracker for this last version. It is loc= ated here: https://docs.google.com/document/d/10lSS99Rq3wCDKgyrNuv-9dxbbInOIIVDb_B= WaPxrm9Q/edit Hope it helps, Gregory On Thu, May 10, 2012 at 10:53 AM, > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Keying and Authentication for Routing= Protocols Working Group of the IETF. Title : Keying and Authentication for Routing Protocols (K= ARP) Overview, Threats, and Requirements Author(s) : Gregory Lebovitz Manav Bhatia Filename : draft-ietf-karp-threats-reqs-05.txt Pages : 32 Date : 2012-05-10 Different routing protocols exist and each employs its own mechanism for securing the protocol packets on the wire. While most already have some method for accomplishing cryptographic message authentication, in many cases the existing methods are dated, vulnerable to attack, and employ cryptographic algorithms that have been deprecated. The "Keying and Authentication for Routing Protocols" (KARP) effort aims to overhaul and improve these mechanisms. This document does not contain protocol specifications. Instead, it defines the areas where protocol specification work is needed and a set of requirements for KARP design teams to follow. RFC 6518, "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" is a companion to this document; KARP design teams will use them together to review and overhaul routing protocols. These two documents reflect the input of both the IETF's Security Area and Routing Area in order to form a mutually agreeable work plan. This document has three main parts. The first part provides an overview of the KARP effort. The second part lists the threats from RFC 4593, Generic Threats To Routing Protocols, that are in scope for attacks against routing protocols' transport systems, including any mechanisms built into the routing protocols themselves, which accomplish packet authentication. The third part enumerates the requirements that routing protocol specifications must meet when addressing those threats for RFC 6518's "Work Phase 1", the update to a routing protocol's existing transport security. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-threats-reqs-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp -- ---- IETF related email from Gregory M. Lebovitz -- ---- IETF related email from Gregory M. Lebovitz --_000_D1D8138DDF34B34B8BC68A11262D10792243A9D555EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Gregory,
 
Changes look fine to me. See my comments=20 in-line..[Uma]
--
Uma C.
 

From: Gregory Lebovitz=20 [mailto:gregory.ietf@gmail.com]
Sent: Thursday, May 31, 2012 7:5= 8=20 AM
To: Uma Chunduri; Bhatia, Manav (Manav)
Cc:=20 karp@ietf.org; Brian Weis
Subject: Re: [karp] I-D Action:=20 draft-ietf-karp-threats-reqs-05.txt

Hello, Uma. Thanks for your input. 

No, I don't believe it's too late. It looks like these are all fairly = minor=20 clarification issues, and no major content debates, which gives me great ho= pe=20 that we are very near completed!! 

Please find comments inline below. Let me know if the proposed resolut= ion=20 text for each point is ok. Once agreed, I'll issue draft-06. 

Manav, could you please address the last issue ASAP?

Note to community:  I have updated the karp-threats-reqs issue tr= acker=20 (google doc, public access) with ID's for the noted items below.

Thanks again for the review,
Gregory


On Fri, May 18, 2012 at 5:00 PM, Uma Chunduri <uma.chunduri@ericsson.com> wrote:
Dear= =20 Authors,
 
I re= ad this=20 version and the document is in good shape.
 
If, = it's not too=20 late, I have few comments on the 05 version.
 
 
1.a) Page 4: Section 1. =20 Introduction
    Third Bullet:
   =20 "   o  Create specifications for cryptographic validation = of=20 routing
      message=20 content."
    "The third bullet is being addressed in t= he=20 SIDR
   working group."
   Though we can unders= tand=20 what SIDR is doing -  "routing message content" just doesn't=20 imply BGP message?
   I=20 can understand what you are trying to say, but IMO, wha= t is=20 said is not representative.
 

How about this:
NEW: The third bullet is being addressed in other = efforts=20 within the IETF. For=20 example, BGP message content validity is being addressed in the SIDR workin= g=20 group. 
 
[Uma]:=20 Sure. 

=
(Tracker=20 ID 08)
 
  b) 7. Sec 2.4:
 &n= bsp;=20 "Message content validity (routing database validity).  This=20 work
      is being addressed in other IETF=20 efforts, like SIDR."
 
   I am not sure "routi= ng=20 database" above is synonymous to BGP. Be explicit calling out, as this ca= n=20 wrong impression on SIDR scope.

How about this:
NEW: This work is being addressed in other efforts within the=20 IETF. For=20 example, BGP message content validity is being addressed in the SIDR workin= g=20 group. 
[Uma]: Sure.=20 =
=
(Tracker=20 ID 08) 
 
 

2. Section 1, Last paragraph, unnecessary ending=20 quote.

Got it. Tracker ID 09.
 
 
3. Section 1.1, Page 6:
 =  =20 "If session or traffic
      keys are being u= sed,=20 KMP is responsible for generating them and
    &nb= sp;=20 determining when they should be renewed."
 
   This is not necessar= ily the=20 only way as it sounds. KMP can also be used for only master key generatio= n and=20
   traffic keys are generated from the same by the master k= ey=20 consumer. And also determining when the keys should
   be=20 renewed may not be KMP function. So I am not quite you define KMP this=20 way.

Understood. How about this:

NEW:   In some routing protocols traffic keys= are=20 derived by the routing protocol from session / master keys. In this case,=20 KMP is responsible for the session / master key generation. In ot= her=20 cases, there are only traffic keys (and no session / master keys), and KMP = is=20 responsible for the traffic key generation. 
 
[Uma]: Perhaps&nb= sp;you=20 can drop "session/" in the above, as that sounds more synonymous = to=20 traffic keys rather than master key (both=20 places).
&nbs= p;

tracker ID 10.
 
 

4. Sec 2.2:
   "However,in the spirit of=20 incremental
   deployment, we first addressed issues like=20 cryptographic algorithm
   agility, replay attacks, and TCP= =20 session resetting in the base TCP-AO
   protocol, and then l= ater=20 began work to layer key management on top of
  =20 it."
   Though authors might have worked on AO, but the abov= e can=20 be better
   represented how TCP-AO is planned to be=20 evolved.

TCP-AO's published RFC contains "cryptographic=20 algorithm
   agility, replay attacks, and TCP sess= ion=20 resetting". And it is true that after AO's RFC published, the community beg= an=20 work on the key management for it. So I think the sentence is ok. No=20 change. 
&nb= sp;
[Uma]: Ok. 
 
 
5. Sec 2.3, Page 13, Point=20 7.
   " For example, designers should aim to re-use the key= =20 management
       protocol that will be= =20 defined for BGP's TCP-AO key=20 establishment
       for as many other=20 routing protocols as possible."
    =20
       Why th<= SPAN>is=20 should be BGP's TCP-AO ?? I presume,= =20 TCP-AO is a generic protocol
     &nbs= p;=20 and any TCP-based pair wise RP or client/server can use this= .=20 It's better to
       say "other routin= g=20 protocols with similar [characteristics/properties] as=20 possible"

Understood. How about this:
NEW:  For example, designers should aim to re= -use=20 the key management protocol that will be defined for BGP, which will establ= ish=20 keys for TCP-AO, for as many other routing protocols with similar=20 characteristics and properties as possible. 
[ Uma]:=20 Sure. 
tracker ID 11
 

 
 

6. Section-4 Page 20
  =20 >>document(s)."
   Extra ending quote. 

Got it. ID 09
 
7."   21.  Given t= he number=20 of routers that would require the=20 new
        authentication mechanis= ms in=20 a typical ISP deployment,=20 solutions
        can increase thei= r=20 appeal by minimizing the burden imposed=20 on
        all routers in favor of= =20 confining significant work loads to=20 a
        relatively small number o= f=20 devices.  Optional features=20 or
        increased assurance that= =20 engenders more pervasive=20 processing
        loads MAY be mad= e=20 available for deployments where the=20 additional
        resources are=20 economically justifiable."
     What is the=20 requirement?

We've been back and forth on this requirement sinc= e its=20 original insertion, i.e. you are not the only one with this question. I'm g= oing=20 to let my co-author, Manav, handle this question. I've entered it on the tr= acker=20 as ID 12. Manav, could address this ASAP?

Thanks again, Uma, for the detailed review,
Gregory

  
 
--=
Uma C.
 

From: karp-bounces@ietf.org [mailto:karp-bounces@ietf.o= rg]=20 On Behalf Of Gregory Lebovitz
Sent: Thursday, May 10, 20= 12=20 11:04 AM
To: karp@ietf.org; Brian Weis; Bhatia, Manav=20 (Manav)
Subject: Re: [karp] I-D Action:=20 draft-ietf-karp-threats-reqs-05.txt
Hey all,=20
This version -05 addressed all the known content issues (a total of = 6)=20 that were brought to our attention during the 2nd WG LC.

Brian - I think we are ready to go back for IESG approval.

FYI, we started a simple GoogleDoc tracker for this last version. It= is=20 located here: 

    https://docs.google.com/document/d/10lSS99Rq3wCDKgyrNuv-9= dxbbInOIIVDb_BWaPxrm9Q/edit

Hope it helps,
Gregory

On Thu, May 10, 2012 at 10:53 AM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-lin= e=20 Internet-Drafts directories. This draft is a work item of the Keying an= d=20 Authentication for Routing Protocols Working Group of the=20 IETF.

       Title       &nbs= p;=20   : Keying and Authentication for Routing Protocols (KARP) Overvie= w,=20 Threats, and Requirements
       Author(s)  = ;=20     : Gregory Lebovitz
         = =20                Manav=20 Bhatia
       Filename       &nbs= p;:=20 draft-ietf-karp-threats-reqs-05.txt
       Pages= =20           : 32
       D= ate=20            : 2012-05-10

 =20 Different routing protocols exist and each employs its own=20 mechanism
  for securing the protocol packets on the wire.=20  While most already
  have some method for accomplishing=20 cryptographic message
  authentication, in many cases the exist= ing=20 methods are dated,
  vulnerable to attack, and employ cryptogra= phic=20 algorithms that have
  been deprecated.  The "Keying and=20 Authentication for Routing
  Protocols" (KARP) effort aims to=20 overhaul and improve these
  mechanisms.

  This doc= ument=20 does not contain protocol specifications.  Instead, it
 =20 defines the areas where protocol specification work is needed and=20 a
  set of requirements for KARP design teams to follow.  = RFC=20 6518,
  "Keying and Authentication for Routing Protocols (KARP)= =20 Design
  Guidelines" is a companion to this document; KARP desi= gn=20 teams will
  use them together to review and overhaul routing=20 protocols.  These
  two documents reflect the input of bot= h the=20 IETF's Security Area and
  Routing Area in order to form a mutu= ally=20 agreeable work plan.

  This document has three main parts.= =20  The first part provides an
  overview of the KARP effort.= =20  The second part lists the threats from
  RFC 4593, Generi= c=20 Threats To Routing Protocols, that are in scope for
  attacks=20 against routing protocols' transport systems, including any
 =20 mechanisms built into the routing protocols themselves, which
 = =20 accomplish packet authentication.  The third part enumerates=20 the
  requirements that routing protocol specifications must me= et=20 when
  addressing those threats for RFC 6518's "Work Phase 1", = the=20 update to
  a routing protocol's existing transport=20 security.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-karp-thr= eats-reqs-05.txt

Internet-Drafts=20 are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This=20 Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-karp-thre= ats-reqs-05.txt

The=20 IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-karp-threat= s-reqs/

_______________________________________________
karp= =20 mailing list
karp@ietf.org
https://www.ietf.org/mailman/listinfo/karp


--
----
IETF related email from
Gregory M.=20 Lebovitz




--
----
IETF related email from
Gregory M.=20 Lebovitz

--_000_D1D8138DDF34B34B8BC68A11262D10792243A9D555EUSAACMS0701e_--