From internet-drafts@ietf.org Thu Dec 6 09:32: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 61AFC21F86DC; Thu, 6 Dec 2012 09:32:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMmcawtuNOGq; Thu, 6 Dec 2012 09:32:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D3721F86E2; Thu, 6 Dec 2012 09:32:44 -0800 (PST) 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.36 Message-ID: <20121206173244.8205.7822.idtracker@ietfa.amsl.com> Date: Thu, 06 Dec 2012 09:32:44 -0800 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-routing-tcp-analysis-06.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, 06 Dec 2012 17:32:45 -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 Pro= tocols Working Group of the IETF. Title : Analysis of BGP, LDP, PCEP and MSDP Issues According to = KARP Design Guide Author(s) : Mahesh Jethanandani Keyur Patel Lianshu Zheng Filename : draft-ietf-karp-routing-tcp-analysis-06.txt Pages : 20 Date : 2012-12-06 Abstract: This document analyzes TCP based routing protocols, Border Gateway Protocol (BGP) [RFC4271], Label Distribution Protocol (LDP) [RFC5036], Path Computation Element Protocol (PCEP) [RFC5440], and Multicast Source Distribution Protocol (MSDP) [RFC3618] according to guidelines set forth in section 4.2 of Keying and Authentication for Routing Protocols Design Guidelines [RFC6518]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-routing-tcp-analysis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-karp-routing-tcp-analysis-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-routing-tcp-analysis-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Fri Dec 14 11:18:56 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 0C88D21F8B57; Fri, 14 Dec 2012 11:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3YatyBJ4Jlp; Fri, 14 Dec 2012 11:18:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17D121F8B5A; Fri, 14 Dec 2012 11:18:54 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121214191854.1809.43759.idtracker@ietfa.amsl.com> Date: Fri, 14 Dec 2012 11:18:54 -0800 Cc: karp mailing list , karp chair , RFC Editor Subject: [karp] Document Action: 'Analysis of OSPF Security According to KARP Design Guide' to Informational RFC (draft-ietf-karp-ospf-analysis-06.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: Fri, 14 Dec 2012 19:18:56 -0000 The IESG has approved the following document: - 'Analysis of OSPF Security According to KARP Design Guide' (draft-ietf-karp-ospf-analysis-06.txt) as Informational RFC This document is the product of the Keying and Authentication for Routing Protocols Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-karp-ospf-analysis/ Technical Summary This document analyzes the security mechanisms for OSPFv2 and OSPFv3, according to the guidelines set forth in RFC 6518. In analyzes the current state of each protocol, describes gaps, and discusses work that needs to be done to close those gaps. Working Group Summary This document is the first of a series of documents analyzing routing protocol security, which is the initial mission of the working group. There was little controversy of note. Members and chairs of the OSPF WG were active in its development and review. Document Quality The document meets the criteria for the phase 1 analysis as defined in RFC 6518. Recommendations of methods of closing security gaps have already been included in I-Ds accepted as OSPF WG documents. Personnel Brian Weis is the document shepherd. Stewart Bryant is the responsible AD. RFC Editor Note OLD A security solution will be developed for OSPFv2 and OSPFv3 based on the OSPFv2 cryptographic authentication option. This solution will have NEW It is recommended that the OSPF Working Group develop a solution for OSPFv2 and OSPFv3 based on the OSPFv2 cryptographic authentication option. This solution would have ... END From jmh@joelhalpern.com Tue Dec 18 14:26: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 0783B21E8054; Tue, 18 Dec 2012 14:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.888 X-Spam-Level: X-Spam-Status: No, score=-101.888 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_73=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TxxUC06rYG9; Tue, 18 Dec 2012 14:26:19 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1F93C21E8039; Tue, 18 Dec 2012 14:26:19 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 26666A397E; Tue, 18 Dec 2012 14:26:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 56E021C0524; Tue, 18 Dec 2012 14:26:17 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-81.clppva.east.verizon.net [70.106.135.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id ECC1D1C005A; Tue, 18 Dec 2012 14:26:15 -0800 (PST) Message-ID: <50D0ED83.3090700@joelhalpern.com> Date: Tue, 18 Dec 2012 17:26:11 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Nick Hilliard References: <50D0EA56.3050308@inex.ie> In-Reply-To: <50D0EA56.3050308@inex.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-karp-routing-tcp-analysis.all@tools.ietf.org" , "ietf@ietf.org List" , "karp@ietf.org" Subject: Re: [karp] Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06 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, 18 Dec 2012 22:26:20 -0000 Nick, I appreciate that you have read this document and commented. Two general questions: 1) Can you be more specific about where you see unclear language usage? It is hard to fix a general coment. 2) A number of your comments seem to be about general router security. Many of them would see far more appicable to RFC 6518. This document is just about changes to protect TCP sessions (yes, what we are concerned about are the TCP sessions used by routers.) Can you take a look at your comments, and tell us which ones are applicable to this document, and which ones should be held for when the community is ready to revise RFC 6518? Thank you, Joel On 12/18/2012 5:12 PM, Nick Hilliard wrote: > On 18/12/2012 20:14, Ben Campbell wrote: >> ** Nits/editorial comments: >> >> -- The 2119 paragraph was removed, but there's still an orphaned 2119 entry in the informational reference section. > > I'm not sure that this was a good idea. There are a lot of "has to"s in > this text, and it's not clear to me whether they are phrased like that as a > way of getting around 2119, or what's going on. Whatever the reason, "has > to" sounds very informal and probably not suitable for a document like > this. Could we have some clarification as to why "has to" doesn't mean > "MUST" (or even "SHOULD"). > > -- > > - protocol stack from CPU-utilization based attacks.TCP Robustness > + protocol stack from CPU-utilization based attacks. TCP Robustness > > -- > > I have a general issue with the statement "TCP MD5 [RFC2385] has been > obsoleted by TCP-AO [RFC5925]." At this time, I'm not aware of any live > TCP-AO implementations. So while I understand that md5 is effectively > obsolete from the specification point of view, from the point of view of > operational reality it's still the only show in town (no-one uses ipsec for > this). > > Secondly, as a general comment about the TCP MD5 option, no-one that I know > uses it as a serious security mechanism, but instead as a means of putting > the equivalent of a padlock on the barn door. This does two things: 1. it > stops bgp sessions from being accidentally re-used (e.g. at IXPs or on > commercial providers who are re-using access ports), and 2. it simply > raises the bar in terms of difficulty. If your barnyard door has a > padlock, and the one beside doesn't, the average lazy human being will > attempt to poke at the one which doesn't. > >>From an operational view, i would generally see the difference between > tcp/md5 and tcp/sha1 (via tcp-ao) as being similar to the difference > between a 5 pin and a 7 pin barrel lock. Both look like a lock on the > outside, and the thief is probably going to smash a window to get in > anyway, or look for the key which the owners left under the mat. > > -- > > There is a second operational issue which may merit mention here, namely > the issue of ensuring that whatever session layer authentication is > implemented on an actual network device, that it doesn't create more > problems than it solves. Specifically, if session layer authentication is > pushed too far down the protocol stack, cryptographic authentication can > occur before other basic checks which might be a whole pile less CPU > intensive. There was a scare about this several years ago when it turned > out that a well-known vendor had implemented tcp md5 checksumming before > more basic tcp session checks (e.g. seq numbers, ttl, etc). In the event, > this turned out to be a red herring because md5 is sufficiently gentle on > the CPU that it didn't make much difference in reality. > > However, there is cryptographic value in using more computationally > intensive hashing algorithms, and if routers (which often have relatively > slow general CPUs or route-processor CPUs) were to get trashed with a large > flood of packets which were signed with a cpu-intensive hashing algorithm, > and if the checksum were to be implemented in the wrong place in the TCP > stack, then this could become an actual problem. > > I don't know whether these things should be noted in the draft. > > -- > > It may be useful to consider whether to acknowledge the existence of rfc > 6192 in the context of providing a link to what other steps might be useful > to secure routers. > > -- > >> pairs of routers when using TCP MD5. It is well known that the >> longer the same key is used, the greater the chance that it can be >> guessed or exposed > > I'm split between {{cn}} and [[Wikipedia:OBVIOUS]]. Hmmm, life's little > decisions. > > -- > >> Routers lack comprehensive key management and keys derived from it >> that they can use to authenticate data. > > clumsy wording (and grammatically incorrect). > > -- > >> Authentication, tamper protection, and encryption all require the use > > should that second comma be dropped? Not sure what the ietf style dictates. > > -- > >> Authentication, tamper protection, and encryption all require the use >> of keys by sender and receiver. An automated KMP therefore has to >> include a way to distribute MKT between two end points with little or >> no administration overhead. It has to cover automatic key rollover. > > "has to" has to become "MUST", shouldn't it? > > Also, the third sentence is a semantic repeat of the second - and much > easier to understand, too. > > -- > > - that, where PCEs are discovered and not configured, the PCC cannot > + that where PCEs are discovered and not configured, the PCC cannot > > -- > > - [draft-zheng-mpls-ldp-hello-crypto-auth-04] suggest a new > + [draft-zheng-mpls-ldp-hello-crypto-auth-04] suggests a new > > -- > >> An LSR can reduce the threat of spoofed Extended Hellos by >> filtering them and accepting Hellos from sources permitted by an >> access lists. > > "permitted by an access list". > > -- > >> However, performing the filtering using access lists >> requires LSR resource, and the LSR is still vulnerable to the IP >> source address spoofing. > > This is a little clumsy. Maybe rephrase as: "However, filtering with > access lists requires LSR resources, and the LSR may still be vulnerable to > IP source address spoofing." > > "may" rather than is. This will depend on the iACL policy of the network. > > -- > >> Spoofed Hello messages are observed and reported as real >> problem in production networks. > > s/problem/problems/ > > {{cn}} > > -- > >> The Message Authentication Codes (MACs) used by TCP MD5 option, is >> considered too weak > > oops, grammar. > > -- > >> Cryptographic research suggests that both these >> MAC algorithms defined are fairly secure. > > Today's "fairly secure" algorithms are tomorrow's swiss cheese: > >> http://www.eetimes.com/electronics-news/4051745/Chinese-researchers-compromise-SHA-1-hashing-algorithm > > I would explicitly avoid the use of ".* secure", and if the authors feel > the need to make any statement about them, that it should be prefixed by > woolly, hand-wavey, get-out-of-jail-free phrases, e.g. "at the time of > authorship, there are no publicly known attacks on this algorithm which > reduce the strength to complexity of less than 1 in X", or however > crypto-heads like to phrase that sort of thing. Right now, that phrase is > headed towards algorithmic oblivion. > > -- > >> LDP [RFC5036] does not provide any security >> mechanisms for use with Hello messages except for some configuration >> which may help protect against bogus discovery events. These >> configurations include directly connected links and interfaces. > > suggest rewording: > > LDP [RFC5036] does not provide any security mechanisms for use with Hello > messages, although operational workarounds may be implemented such as > using directly interfaces. > > -- > > There are possibly more nits in there - I haven't exhaustively gone through > all the text, but it needs a good shake-down by a style editor. > > Otherwise I like this draft and think it has merit as a general > informational overview. > > Nick > > From ananth@nttmcl.com Tue Dec 18 15:15:44 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 5632A21E805A for ; Tue, 18 Dec 2012 15:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eUDYc+6xZJR for ; Tue, 18 Dec 2012 15:15:42 -0800 (PST) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7F40C21F86CA for ; Tue, 18 Dec 2012 15:15:42 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id fr13so1591829vbb.23 for ; Tue, 18 Dec 2012 15:15:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=DddHo5pyWh4QpU43phRHSG4mES1vXpZ5dgbk81NsXGo=; b=bLuaKkW7rmL0DXhsbnVH2QpBmIhLA5r1tpDQBCKI9bh1GeF6vE0Vc1uH9usAnhxn1j LZ1M45gtheNR70qhCpNYkG9WxhaxVnxk60GdCWnhxaeZVWsAr/m6WdPRSbDXu5+ggluX K85eYJLgOcAWySt+ftpzLH48odVfrCjQh+sF18VTfFLTE2rdvktDTNzS0OIY7XLv7rUy OhQVvCV75mQE6ifVPTNAq5MMbsewcLJ8x98Wnbz0xtECLoPqPEtV27sAJfHSalEtuu36 hiQtXTGy36bhIW40UcEHEFCwb+H6ue+nP2rStOVIpc34SUNiixlR9F8kIB6h1XP3p8si 7K4A== MIME-Version: 1.0 Received: by 10.220.141.6 with SMTP id k6mr5839992vcu.24.1355872541485; Tue, 18 Dec 2012 15:15:41 -0800 (PST) Received: by 10.220.3.229 with HTTP; Tue, 18 Dec 2012 15:15:41 -0800 (PST) In-Reply-To: <50D0ED83.3090700@joelhalpern.com> References: <50D0EA56.3050308@inex.ie> <50D0ED83.3090700@joelhalpern.com> Date: Tue, 18 Dec 2012 15:15:41 -0800 Message-ID: From: Anantha Ramaiah To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=f46d04389221322a6504d128ad8e X-Gm-Message-State: ALoCoQmetyob4Hs5LBFC+UjXQngZJ/um7ro8rEFD3T5Pg7tLzXXxRhI9JXd/P/Xuc/A8lwn/UPOI Cc: "draft-ietf-karp-routing-tcp-analysis.all@tools.ietf.org" , Nick Hilliard , "ietf@ietf.org List" , "karp@ietf.org" Subject: Re: [karp] Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06 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, 18 Dec 2012 23:15:44 -0000 --f46d04389221322a6504d128ad8e Content-Type: text/plain; charset=ISO-8859-1 FWIW, I have to agree with Nick's observations w.r.t TCP MD5. Especially the following :- - TCP MD5 is not universally turned on to protect LDP sessions. It is case by case. TCP MD5 is better than no security at all. Also TCP MD5 with periodic key rollover can make the life harder for TCP MD5 based collision attacks. It is better than TCP-MD5 with no key rollover. (so, you see the degree of protection varies and the Nick's example of 5 pin versus 7 pin barrel lock, which I like :-) - I also agree that there are no live TCP-AO implementations to date. TCP-MD5 on the other hand has been there and still there in many vendors TCP stacks. I think it is a good idea to note some the points (esp the CPU utilization depending on the crypto algorithm of choice etc.,) into the draft. Makes sense to me. thanks, -Anantha On Tue, Dec 18, 2012 at 2:26 PM, Joel M. Halpern wrote: > Nick, I appreciate that you have read this document and commented. > > Two general questions: > 1) Can you be more specific about where you see unclear language usage? > It is hard to fix a general coment. > > 2) A number of your comments seem to be about general router security. > Many of them would see far more appicable to RFC 6518. This document is > just about changes to protect TCP sessions (yes, what we are concerned > about are the TCP sessions used by routers.) Can you take a look at your > comments, and tell us which ones are applicable to this document, and which > ones should be held for when the community is ready to revise RFC 6518? > > Thank you, > Joel > > On 12/18/2012 5:12 PM, Nick Hilliard wrote: > >> On 18/12/2012 20:14, Ben Campbell wrote: >> >>> ** Nits/editorial comments: >>> >>> -- The 2119 paragraph was removed, but there's still an orphaned 2119 >>> entry in the informational reference section. >>> >> >> I'm not sure that this was a good idea. There are a lot of "has to"s in >> this text, and it's not clear to me whether they are phrased like that as >> a >> way of getting around 2119, or what's going on. Whatever the reason, "has >> to" sounds very informal and probably not suitable for a document like >> this. Could we have some clarification as to why "has to" doesn't mean >> "MUST" (or even "SHOULD"). >> >> -- >> >> - protocol stack from CPU-utilization based attacks.TCP Robustness >> + protocol stack from CPU-utilization based attacks. TCP Robustness >> >> -- >> >> I have a general issue with the statement "TCP MD5 [RFC2385] has been >> obsoleted by TCP-AO [RFC5925]." At this time, I'm not aware of any live >> TCP-AO implementations. So while I understand that md5 is effectively >> obsolete from the specification point of view, from the point of view of >> operational reality it's still the only show in town (no-one uses ipsec >> for >> this). >> >> Secondly, as a general comment about the TCP MD5 option, no-one that I >> know >> uses it as a serious security mechanism, but instead as a means of putting >> the equivalent of a padlock on the barn door. This does two things: 1. it >> stops bgp sessions from being accidentally re-used (e.g. at IXPs or on >> commercial providers who are re-using access ports), and 2. it simply >> raises the bar in terms of difficulty. If your barnyard door has a >> padlock, and the one beside doesn't, the average lazy human being will >> attempt to poke at the one which doesn't. >> >> From an operational view, i would generally see the difference between >>> >> tcp/md5 and tcp/sha1 (via tcp-ao) as being similar to the difference >> between a 5 pin and a 7 pin barrel lock. Both look like a lock on the >> outside, and the thief is probably going to smash a window to get in >> anyway, or look for the key which the owners left under the mat. >> >> -- >> >> There is a second operational issue which may merit mention here, namely >> the issue of ensuring that whatever session layer authentication is >> implemented on an actual network device, that it doesn't create more >> problems than it solves. Specifically, if session layer authentication is >> pushed too far down the protocol stack, cryptographic authentication can >> occur before other basic checks which might be a whole pile less CPU >> intensive. There was a scare about this several years ago when it turned >> out that a well-known vendor had implemented tcp md5 checksumming before >> more basic tcp session checks (e.g. seq numbers, ttl, etc). In the event, >> this turned out to be a red herring because md5 is sufficiently gentle on >> the CPU that it didn't make much difference in reality. >> >> However, there is cryptographic value in using more computationally >> intensive hashing algorithms, and if routers (which often have relatively >> slow general CPUs or route-processor CPUs) were to get trashed with a >> large >> flood of packets which were signed with a cpu-intensive hashing algorithm, >> and if the checksum were to be implemented in the wrong place in the TCP >> stack, then this could become an actual problem. >> >> I don't know whether these things should be noted in the draft. >> >> -- >> >> It may be useful to consider whether to acknowledge the existence of rfc >> 6192 in the context of providing a link to what other steps might be >> useful >> to secure routers. >> >> -- >> >> pairs of routers when using TCP MD5. It is well known that the >>> longer the same key is used, the greater the chance that it can be >>> guessed or exposed >>> >> >> I'm split between {{cn}} and [[Wikipedia:OBVIOUS]]. Hmmm, life's little >> decisions. >> >> -- >> >> Routers lack comprehensive key management and keys derived from it >>> that they can use to authenticate data. >>> >> >> clumsy wording (and grammatically incorrect). >> >> -- >> >> Authentication, tamper protection, and encryption all require the use >>> >> >> should that second comma be dropped? Not sure what the ietf style >> dictates. >> >> -- >> >> Authentication, tamper protection, and encryption all require the use >>> of keys by sender and receiver. An automated KMP therefore has to >>> include a way to distribute MKT between two end points with little or >>> no administration overhead. It has to cover automatic key rollover. >>> >> >> "has to" has to become "MUST", shouldn't it? >> >> Also, the third sentence is a semantic repeat of the second - and much >> easier to understand, too. >> >> -- >> >> - that, where PCEs are discovered and not configured, the PCC cannot >> + that where PCEs are discovered and not configured, the PCC cannot >> >> -- >> >> - [draft-zheng-mpls-ldp-hello-**crypto-auth-04] suggest a new >> + [draft-zheng-mpls-ldp-hello-**crypto-auth-04] suggests a new >> >> -- >> >> An LSR can reduce the threat of spoofed Extended Hellos by >>> filtering them and accepting Hellos from sources permitted by an >>> access lists. >>> >> >> "permitted by an access list". >> >> -- >> >> However, performing the filtering using access lists >>> requires LSR resource, and the LSR is still vulnerable to the IP >>> source address spoofing. >>> >> >> This is a little clumsy. Maybe rephrase as: "However, filtering with >> access lists requires LSR resources, and the LSR may still be vulnerable >> to >> IP source address spoofing." >> >> "may" rather than is. This will depend on the iACL policy of the network. >> >> -- >> >> Spoofed Hello messages are observed and reported as real >>> problem in production networks. >>> >> >> s/problem/problems/ >> >> {{cn}} >> >> -- >> >> The Message Authentication Codes (MACs) used by TCP MD5 option, is >>> considered too weak >>> >> >> oops, grammar. >> >> -- >> >> Cryptographic research suggests that both these >>> MAC algorithms defined are fairly secure. >>> >> >> Today's "fairly secure" algorithms are tomorrow's swiss cheese: >> >> http://www.eetimes.com/**electronics-news/4051745/**Chinese-researchers- >>> **compromise-SHA-1-hashing-**algorithm >>> >> >> I would explicitly avoid the use of ".* secure", and if the authors feel >> the need to make any statement about them, that it should be prefixed by >> woolly, hand-wavey, get-out-of-jail-free phrases, e.g. "at the time of >> authorship, there are no publicly known attacks on this algorithm which >> reduce the strength to complexity of less than 1 in X", or however >> crypto-heads like to phrase that sort of thing. Right now, that phrase is >> headed towards algorithmic oblivion. >> >> -- >> >> LDP [RFC5036] does not provide any security >>> mechanisms for use with Hello messages except for some configuration >>> which may help protect against bogus discovery events. These >>> configurations include directly connected links and interfaces. >>> >> >> suggest rewording: >> >> LDP [RFC5036] does not provide any security mechanisms for use with Hello >> messages, although operational workarounds may be implemented such as >> using directly interfaces. >> >> -- >> >> There are possibly more nits in there - I haven't exhaustively gone >> through >> all the text, but it needs a good shake-down by a style editor. >> >> Otherwise I like this draft and think it has merit as a general >> informational overview. >> >> Nick >> >> >> ______________________________**_________________ > karp mailing list > karp@ietf.org > https://www.ietf.org/mailman/**listinfo/karp > --f46d04389221322a6504d128ad8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

FWIW,
=A0 =A0 =A0 I have to agree with Nick's observ= ations w.r.t TCP MD5. Especially the following :-

= - TCP MD5 is not universally turned on to protect LDP sessions. It is case = by case. TCP MD5 is better than no security at all. Also TCP MD5 with perio= dic key rollover can make the life harder for TCP MD5 based collision attac= ks. It is better than TCP-MD5 with no key rollover.

(so, you see the degree of protection varies and the Ni= ck's example of 5 pin versus 7 pin barrel lock, which I like :-)
<= div>
- I also agree that there are no live TCP-AO implementat= ions to date. TCP-MD5 on the other hand has been there and still there in m= any vendors TCP stacks.

I think it is a good idea to note some the points (esp = the CPU utilization depending on the crypto algorithm of choice etc.,) into= the draft. Makes sense to me.

thanks,
-Anantha


On Tue, Dec 18, 2012 = at 2:26 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
Nick, I appreciate that you have read this document and commented.

Two general questions:
1) Can you be more specific about where you see unclear language usage? =A0= It is hard to fix a general coment.

2) A number of your comments seem to be about general router security. Many= of them would see far more appicable to RFC 6518. =A0This document is just= about changes to protect TCP sessions (yes, what we are concerned about ar= e the TCP sessions used by routers.) =A0Can you take a look at your comment= s, and tell us which ones are applicable to this document, and which ones s= hould be held for when the community is ready to revise RFC 6518?

Thank you,
Joel

On 12/18/2012 5:12 PM, Nick Hilliard wrote:
On 18/12/2012 20:14, Ben Campbell wrote:
** Nits/editorial comments:

-- The 2119 paragraph was removed, but there's still an orphaned 2119 e= ntry in the informational reference section.

I'm not sure that this was a good idea. =A0There are a lot of "has= to"s in
this text, and it's not clear to me whether they are phrased like that = as a
way of getting around 2119, or what's going on. =A0Whatever the reason,= "has
to" sounds very informal and probably not suitable for a document like=
this. =A0Could we have some clarification as to why "has to" does= n't mean
"MUST" (or even "SHOULD").

--

- =A0 protocol stack from CPU-utilization based attacks.TCP Robustness
+ =A0 protocol stack from CPU-utilization based attacks. TCP Robustness

--

I have a general issue with the statement "TCP MD5 [RFC2385] has been<= br> obsoleted by TCP-AO [RFC5925]." =A0At this time, I'm not aware of = any live
TCP-AO implementations. =A0So while I understand that md5 is effectively obsolete from the specification point of view, from the point of view of operational reality it's still the only show in town (no-one uses ipsec= for
this).

Secondly, as a general comment about the TCP MD5 option, no-one that I know=
uses it as a serious security mechanism, but instead as a means of putting<= br> the equivalent of a padlock on the barn door. =A0This does two things: 1. i= t
stops bgp sessions from being accidentally re-used (e.g. at IXPs or on
commercial providers who are re-using access ports), and 2. it simply
raises the bar in terms of difficulty. =A0If your barnyard door has a
padlock, and the one beside doesn't, the average lazy human being will<= br> attempt to poke at the one which doesn't.

>From an operational view, i would generally see the difference between
tcp/md5 and tcp/sha1 (via tcp-ao) as being similar to the difference
between a 5 pin and a 7 pin barrel lock. =A0Both look like a lock on the outside, and the thief is probably going to smash a window to get in
anyway, or look for the key which the owners left under the mat.

--

There is a second operational issue which may merit mention here, namely the issue of ensuring that whatever session layer authentication is
implemented on an actual network device, that it doesn't create more problems than it solves. =A0Specifically, if session layer authentication i= s
pushed too far down the protocol stack, cryptographic authentication can occur before other basic checks which might be a whole pile less CPU
intensive. =A0There was a scare about this several years ago when it turned=
out that a well-known vendor had implemented tcp md5 checksumming before more basic tcp session checks (e.g. seq numbers, ttl, etc). =A0In the event= ,
this turned out to be a red herring because md5 is sufficiently gentle on the CPU that it didn't make much difference in reality.

However, there is cryptographic value in using more computationally
intensive hashing algorithms, and if routers (which often have relatively slow general CPUs or route-processor CPUs) were to get trashed with a large=
flood of packets which were signed with a cpu-intensive hashing algorithm,<= br> and if the checksum were to be implemented in the wrong place in the TCP stack, then this could become an actual problem.

I don't know whether these things should be noted in the draft.

--

It may be useful to consider whether to acknowledge the existence of rfc 6192 in the context of providing a link to what other steps might be useful=
to secure routers.

--

=A0 =A0 pairs of routers when using TCP MD5. =A0It is well known that the =A0 =A0 longer the same key is used, the greater the chance that it can be<= br> =A0 =A0 guessed or exposed

I'm split between {{cn}} and [[Wikipedia:OBVIOUS]]. =A0Hmmm, life's= little
decisions.

--

=A0 =A0 Routers lack comprehensive key management and keys derived from it<= br> =A0 =A0 that they can use to authenticate data.

clumsy wording (and grammatically incorrect).

--

=A0 =A0 Authentication, tamper protection, and encryption all require the u= se

should that second comma be dropped? =A0Not sure what the ietf style dictat= es.

--

=A0 =A0 Authentication, tamper protection, and encryption all require the u= se
=A0 =A0 of keys by sender and receiver. =A0An automated KMP therefore has t= o
=A0 =A0 include a way to distribute MKT between two end points with little = or
=A0 =A0 no administration overhead. =A0It has to cover automatic key rollov= er.

"has to" has to become "MUST", shouldn't it?

Also, the third sentence is a semantic repeat of the second - and much
easier to understand, too.

--

- =A0 =A0that, where PCEs are discovered and not configured, the PCC cannot=
+ =A0 =A0that where PCEs are discovered and not configured, the PCC cannot<= br>
--

- =A0 [draft-zheng-mpls-ldp-hello-crypto-auth-04] suggest a new
+ =A0 [draft-zheng-mpls-ldp-hello-crypto-auth-04] suggests a new

--

=A0 =A0 =A0 =A0 =A0 =A0 =A0An LSR can reduce the threat of spoofed Extended= Hellos by
=A0 =A0 filtering them and accepting Hellos from sources permitted by an =A0 =A0 access lists.

"permitted by an access list".

--

=A0 However, performing the filtering using access lists
=A0 =A0 requires LSR resource, and the LSR is still vulnerable to the IP =A0 =A0 source address spoofing.

This is a little clumsy. =A0Maybe rephrase as: "However, filtering wit= h
access lists requires LSR resources, and the LSR may still be vulnerable to=
IP source address spoofing."

"may" rather than is. =A0This will depend on the iACL policy of t= he network.

--

Spoofed Hello messages are observed and reported as real
=A0 =A0 problem in production networks.

s/problem/problems/

{{cn}}

--

=A0 =A0 The Message Authentication Codes (MACs) used by TCP MD5 option, is<= br> =A0 =A0 considered too weak

oops, grammar.

--

Cryptographic research suggests that both these
=A0 =A0 MAC algorithms defined are fairly secure.

Today's "fairly secure" algorithms are tomorrow's swiss c= heese:

http://www.eetime= s.com/electronics-news/4051745/Chinese-researchers-com= promise-SHA-1-hashing-algorithm

I would explicitly avoid the use of ".* secure", and if the autho= rs feel
the need to make any statement about them, that it should be prefixed by woolly, hand-wavey, get-out-of-jail-free phrases, e.g. "at the time of=
authorship, there are no publicly known attacks on this algorithm which
reduce the strength to complexity of less than 1 in X", or however
crypto-heads like to phrase that sort of thing. =A0Right now, that phrase i= s
headed towards algorithmic oblivion.

--

LDP [RFC5036] does not provide any security
=A0 =A0 mechanisms for use with Hello messages except for some configuratio= n
=A0 =A0 which may help protect against bogus discovery events. =A0These
=A0 =A0 configurations include directly connected links and interfaces.

suggest rewording:

LDP [RFC5036] does not provide any security mechanisms for use with Hello messages, although operational workarounds may be implemented such as
using directly interfaces.

--

There are possibly more nits in there - I haven't exhaustively gone thr= ough
all the text, but it needs a good shake-down by a style editor.

Otherwise I like this draft and think it has merit as a general
informational overview.

Nick


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

--f46d04389221322a6504d128ad8e-- From nick@inex.ie Wed Dec 19 15:14:25 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 E85AA21F892A; Wed, 19 Dec 2012 15:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4laReO8tpOI; Wed, 19 Dec 2012 15:14:25 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id A16C721F88F1; Wed, 19 Dec 2012 15:14:23 -0800 (PST) X-Envelope-To: ietf@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:41e8:aae1:8461:f339]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBJNCVHM040156 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 19 Dec 2012 23:12:37 GMT (envelope-from nick@inex.ie) Message-ID: <50D24A43.6050608@inex.ie> Date: Wed, 19 Dec 2012 23:14:11 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Joel M. Halpern" References: <50D0EA56.3050308@inex.ie> <50D0ED83.3090700@joelhalpern.com> In-Reply-To: <50D0ED83.3090700@joelhalpern.com> X-Enigmail-Version: 1.4.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 19 Dec 2012 19:41:11 -0800 Cc: "draft-ietf-karp-routing-tcp-analysis.all@tools.ietf.org" , "ietf@ietf.org List" , "karp@ietf.org" Subject: Re: [karp] Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06 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, 19 Dec 2012 23:14:26 -0000 On 18/12/2012 22:26, Joel M. Halpern wrote: > Nick, I appreciate that you have read this document and commented. > > Two general questions: > 1) Can you be more specific about where you see unclear language usage? It > is hard to fix a general coment. I was referring to the use of "has to", but the phrase only appears three times so maybe it's not going to be a large amount of work to eradicate it. This might work: s/has to/needs to/g I overestimated to myself the number of times it appeared by flicking back and forwards through the document when looking at it last night. > 2) A number of your comments seem to be about general router security. Many > of them would see far more appicable to RFC 6518. This document is just > about changes to protect TCP sessions (yes, what we are concerned about are > the TCP sessions used by routers.) Can you take a look at your comments, > and tell us which ones are applicable to this document, and which ones > should be held for when the community is ready to revise RFC 6518? 6518 looks like a roadmap to me. I don't see any of these comments as being especially relevant to that document. There are 3 general suggestions and the rest of the issues are either style or syntax editing issues, and I think they are all relevant to this document. These suggestions are: 1: >> I have a general issue with the statement "TCP MD5 [RFC2385] has been >> obsoleted by TCP-AO [RFC5925]." At this time, I'm not aware of any live >> TCP-AO implementations. So while I understand that md5 is effectively >> obsolete from the specification point of view, from the point of view of >> operational reality it's still the only show in town (no-one uses ipsec for >> this). We don't have running code for the new protocol, but we have very wide deployment for the older protocol. So I question how appropriate it is to make a statement on whether the new protocol has obsoleted the old one. I'm not familiar enough with ietf nous to know whether this is relevant to a document like this. Wearing my operator hat, it looks a little odd, that's all. 2: >> There is a second operational issue which may merit mention here, namely >> the issue of ensuring that whatever session layer authentication is >> implemented on an actual network device, that it doesn't create more >> problems than it solves. Specifically, if session layer authentication is >> pushed too far down the protocol stack, cryptographic authentication can >> occur before other basic checks which might be a whole pile less CPU >> intensive. There was a scare about this several years ago when it turned >> out that a well-known vendor had implemented tcp md5 checksumming before >> more basic tcp session checks (e.g. seq numbers, ttl, etc). In the event, >> this turned out to be a red herring because md5 is sufficiently gentle on >> the CPU that it didn't make much difference in reality. >> >> However, there is cryptographic value in using more computationally >> intensive hashing algorithms, and if routers (which often have relatively >> slow general CPUs or route-processor CPUs) were to get trashed with a large >> flood of packets which were signed with a cpu-intensive hashing algorithm, >> and if the checksum were to be implemented in the wrong place in the TCP >> stack, then this could become an actual problem. Whatever a router manufacturer does in terms of implementation, they need to be careful when writing code to ensure that they don't accidentally open up other attack vectors by implementing transport layer security badly. It almost happened once before, and this could have caused damage at the time if we had had been using a computationally expensive algorithm like openbsd bcrypt instead of md5. 3: >> It may be useful to consider whether to acknowledge the existence of rfc >> 6192 in the context of providing a link to what other steps might be useful >> to secure routers. What I'm suggesting here is a single sentence around the first paragraph in section 2.1 to say that while it's outside the context of transport security, there's more to protecting routers than cryptography - and then provide a link to 6192 as an informative reference to someone who might be interested in the more general area router security. General router security is a large subject which is not particularly pertinent to keying and authentication, but a random operator who happens to read this ID when it's published might appreciate the pointer. Nick From nick@inex.ie Wed Dec 19 15:21: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 72CA721F892A; Wed, 19 Dec 2012 15:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynRRuOmsL7dI; Wed, 19 Dec 2012 15:20:58 -0800 (PST) Received: from mail.acquirer.com (mail.netability.ie [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id 38D9221F8899; Wed, 19 Dec 2012 15:20:55 -0800 (PST) X-Envelope-To: karp@ietf.org Received: from cupcake.foobar.org ([IPv6:2001:4d68:2002:100:41e8:aae1:8461:f339]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id qBJNJ9VM040188 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 19 Dec 2012 23:19:15 GMT (envelope-from nick@inex.ie) Message-ID: <50D24BD1.4070801@inex.ie> Date: Wed, 19 Dec 2012 23:20:49 +0000 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Anantha Ramaiah References: <50D0EA56.3050308@inex.ie> <50D0ED83.3090700@joelhalpern.com> In-Reply-To: X-Enigmail-Version: 1.4.6 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 19 Dec 2012 19:41:11 -0800 Cc: "draft-ietf-karp-routing-tcp-analysis.all@tools.ietf.org" , "ietf@ietf.org List" , "karp@ietf.org" Subject: Re: [karp] Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06 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, 19 Dec 2012 23:21:04 -0000 On 18/12/2012 23:15, Anantha Ramaiah wrote: > Also TCP MD5 with periodic key rollover can make the life harder for TCP > MD5 based collision attacks. there is no facility in rfc 2385 for automatic key rollover, which means that any key changes must be done manually. I've come across gratuitous key rollover happening exactly once in my career: namely where (as far as I understand) a particular company had used the same MD5 key for all ebgp peering sessions worldwide. They eventually decided that this wasn't such a good idea and subsequently changed keys whenever they changed routers / bgp sessions / did port upgrades / etc. Other than that, I've never come across a case of someone wanting to proactively change a session key because it seemed to be a good idea. Just sayin'. Nick From mjethanandani@gmail.com Wed Dec 19 20:52: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 4428521F884C for ; Wed, 19 Dec 2012 20:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hF7f52kdi3CG for ; Wed, 19 Dec 2012 20:52:19 -0800 (PST) Received: from mail-da0-f49.google.com (mail-da0-f49.google.com [209.85.210.49]) by ietfa.amsl.com (Postfix) with ESMTP id A70B121F8899 for ; Wed, 19 Dec 2012 20:52:19 -0800 (PST) Received: by mail-da0-f49.google.com with SMTP id v40so1298923dad.36 for ; Wed, 19 Dec 2012 20:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:subject:date:references:to:message-id :mime-version:x-mailer; bh=VqxsoAN56zHwHH+mOL/YOZ1JhpRVGnBfaGsrfRW6Rvk=; b=ZVCH2y1UM2PGwlqB2bRz8m3337qFfJvuOCji5So93NnWMu+0ygk7MI+igOv4r2ff0h 1+3DzBjCVM8wnfWk482WOoI+Hgynqd2azMqDfO35uYEXu0heCY7tEqn78m9dqP60jUb3 SeaDHcFPIXn0T7zeqiXXsKTN89WhhHciffBpzHA0rxCz6pFBUQVGHjfYE4Bhjv6U9BE3 8Fwudb5BVYQHgZQl+UpnJfw8nnAOQnD5qq/ow21k5ZhyR3K1pqb0iAjBVhfPO1nNkPOX PCnYokoJ8F4eyIaAn1eKEODvLJmv0DTclw1iTrqI7U9rvPxOfvhsVgnahtB+r7+ASGgM R3Dg== X-Received: by 10.69.16.100 with SMTP id fv4mr25578939pbd.135.1355979138231; Wed, 19 Dec 2012 20:52:18 -0800 (PST) Received: from [192.168.1.123] (c-24-6-180-144.hsd1.ca.comcast.net. [24.6.180.144]) by mx.google.com with ESMTPS id w5sm4672357pax.28.2012.12.19.20.52.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 20:52:17 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary=Apple-Mail-13--285186206 Date: Wed, 19 Dec 2012 20:52:15 -0800 References: To: "karp@ietf.org karp@ietf.org" Message-Id: Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Subject: [karp] New Version Notification for draft-mahesh-karp-rsvp-te-analysis-00.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, 20 Dec 2012 04:52:20 -0000 --Apple-Mail-13--285186206 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > A new version of I-D, draft-mahesh-karp-rsvp-te-analysis-00.txt > has been successfully submitted by Mahesh Jethanandani and posted to = the > IETF repository. >=20 > Filename: draft-mahesh-karp-rsvp-te-analysis > Revision: 00 > Title: Analysis of RSVP-TE Security According to KARP Design = Guide > Creation date: 2012-12-16 > WG ID: Individual Submission > Number of pages: 12 > URL: = http://www.ietf.org/internet-drafts/draft-mahesh-karp-rsvp-te-analysis-00.= txt > Status: = http://datatracker.ietf.org/doc/draft-mahesh-karp-rsvp-te-analysis > Htmlized: = http://tools.ietf.org/html/draft-mahesh-karp-rsvp-te-analysis-00 >=20 >=20 > Abstract: > This document analyzes RSVP-TE according to guidelines set forth in > section 4.2 of KARP Design Guidelines [RFC6518]. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail-13--285186206 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

A new version of I-D, = draft-mahesh-karp-rsvp-te-analysis-00.txt
has been = successfully submitted by Mahesh Jethanandani and posted to = the
IETF repository.

Filename: =     draft-mahesh-karp-rsvp-te-analysis
R= evision:     00
Title: =         Analysis of RSVP-TE = Security According to KARP Design Guide
Creation date: =     2012-12-16
WG ID: =         Individual = Submission
Number of pages: 12
URL: =             http://www.ietf.org/internet-drafts/draft-mahesh-karp-rsvp-te= -analysis-00.txt
Htmlized:        = http://tools.ietf.org/html/draft-mahesh-karp-rsvp-te-analysis-00


Abstract:
This document analyzes RSVP-TE = according to guidelines set forth in
section 4.2 of KARP = Design Guidelines [RFC6518].




The IETF = Secretariat



Mahesh = Jethanandani
<= div>


= --Apple-Mail-13--285186206-- From gregory.ietf@gmail.com Wed Dec 19 22:01:09 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 78D4A21F875D for ; Wed, 19 Dec 2012 22:01:09 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ebJs5K2P8V2 for ; Wed, 19 Dec 2012 22:01:07 -0800 (PST) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1956B21F86A3 for ; Wed, 19 Dec 2012 22:01:07 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id h1so3006368oag.34 for ; Wed, 19 Dec 2012 22:01:04 -0800 (PST) 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=g9c8mk8inrsTQPi7OvXTWGa74jOGH2rmyIqe/MNW06Y=; b=bejiEvXAVjug0FkAneAo5D5EUdEDBmcf+6MEbAYr+CXooVZ0p/ph1eCdLZIAflMLB1 V+qrLcLH5yaTwKCeAsx2zpJQK//QgJvGY8Y2IaLR/hEROiPS0D/4CULHKlZCVukU/vVQ MCMD4HfNg3pjBEMqLBbHuBejGrG5vM8eKkPCPEk0ua8vVr8yaaSBUXHaG1qp6AFb9K/I MlyA7PhsQKVnpp8yjixQ0/O9PTlRwzi1pewINLAFzRMi/Sxvld21K40cl5ZrqKKGUag+ 8L1g7IlTS5//oiDuSJVWb89eDzEBSInXEe8v5jnfTdf8944p0V/Lip2RAT/1AHHd21F1 xurA== MIME-Version: 1.0 Received: by 10.182.8.10 with SMTP id n10mr7085639oba.19.1355983263907; Wed, 19 Dec 2012 22:01:03 -0800 (PST) Received: by 10.76.130.83 with HTTP; Wed, 19 Dec 2012 22:01:03 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D0994298D@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <508EC76E.3070101@ieca.com> <594EF5AE-F349-46C1-ACA9-920EDC9D1284@cisco.com> <50A2CDB8.3000508@ieca.com> <471CDB24-45B3-410A-A892-27828475348C@cisco.com> <7C362EEF9C7896468B36C9B79200D8350D0994298D@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 19 Dec 2012 22:01:03 -0800 Message-ID: From: Gregory Lebovitz To: "Bhatia, Manav (Manav)" Content-Type: multipart/alternative; boundary=f46d04448159c440e904d14274d2 Cc: karp@ietf.org Subject: Re: [karp] Clearing your DISCUSS on draft-ietf-karp-threats-reqs 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, 20 Dec 2012 06:01:09 -0000 --f46d04448159c440e904d14274d2 Content-Type: text/plain; charset=ISO-8859-1 I'm about to post -07 of the threats-reqs document. The authors have addressed all issues raised on Sean's second round of DISCUSS during IESG review, and Sean has now signed off. The details are all inline below. (cc'ing the KARP mail list so we have a public record of the DISCUSS issues and their resolutions.) Let's publish!! Gregory On Sun, Dec 16, 2012 at 10:37 PM, Bhatia, Manav (Manav) < manav.bhatia@alcatel-lucent.com> wrote: > ** > Hi, > > I am in complete agreement with everything that Gregory has written here > and especially the part about getting the document delayed for this long > without radically improving the readability or the content of the document > ! :-) > > I am ok, as i had said earlier, with the latest version -07 and i think we > should just get it outta our door now! > > I would also concur with Greg on including Brian as a co-author, if thats > acceptable to Brian! > > Cheers, Manav > > ------------------------------ > *From:* Gregory Lebovitz [mailto:gregory.ietf@gmail.com] > *Sent:* Monday, December 17, 2012 11:31 AM > *To:* Brian Weis > *Cc:* Gregory Lebovitz; Bhatia, Manav (Manav); Sean P. Turner > > *Subject:* Re: Clearing your DISCUSS on draft-ietf-karp-threats-reqs > > Brian, Manav & Sean, > Boyz, let's get this thang done!! :-) > > I think it most direct to comment inline to this original email, even > though the last correspondance on the thread was actually Dec 1. > > I'm also wondering, Sean, why did you send your comments to Brian, and not > to Manav and I, the authors? Although at this point I think Brian has put > so much work into this document that you ought to be on the author list > too. (see my comment at the end, below, about Brian and author > recognition). No accusation here, Sean. Just curious. > > Comments inline below... > > > On Wed, Nov 21, 2012 at 5:54 PM, Brian Weis wrote: > >> Hi Gregory and Manov, >> >> Almost done, but Sean has a couple remaining issues. I've attached a >> version with proposed edits to deal with them. Please correct or say you >> can live with them. I've added some explanatory text inline. >> >> On Nov 13, 2012, at 2:46 PM, Sean Turner wrote: >> >> > Just got two left. Maybe I can do this quicker here and you can tell >> me if I'm just not getting it (entirely possible): >> > >> > 1) s4 #3: Algorithm agility means that the protocol doesn't hard code >> an algorithm in. That's covered here, but there's also this: >> > >> > Additionally, more than one algorithm MUST be specified. >> > >> > which could be a whole lot more - is it two MTI algorithms? I don't >> want people to misinterpret this later down the road. Maybe an example >> would clear this up: "(i.e., one mandatory to implement algorithm and one >> or more backup algorithms to guide transition)." >> >> I think it's time to capitulate on two mandatory to implement algorithms. >> But it is important to specify two algorithm, so it makes sense to me to >> specify more than one but only mandate one. >> > > Ok. I don't agree, but I'm willing to let this go for the sake of getting > the document done. > > The only way to be sure implementations can really move between multiple > algorithms, and do so with interoperability, is for them to actually have > multiple algorithms implemented, and test both during bake-offs. I know > from experience, the hard way, with both IKEv1 and IKEv2. Two MTI's is the > only way to ensure this. > > However, I think the text proposed in -07 is about as strong as you can > get without actually mandating two MTI's: > > Mandating support for two algorithms (i.e., one > both redundancy, and a mechanism for enacting that redundancy. > mandatory > to implement algorithm and one or more backup > algorithms to guide transition) provides both redundancy, and a > mechanism for enacting that redundancy. > > I will not block on this issue. The -07 text may stand. > > > >> >> > >> > 2) s4 #5: I'm confused whether the SHOULD in the first paragraph is for >> intra-session replay and the MUST is for inter-session? It's probably also >> worth defining what the two are in the terminology section. >> > >> > Anyway let me give this a shot and see what you think: >> > >> > Terminology: >> > >> > Replay Attacks: For non-TCP based protocols like OSPF [RFC2328], >> > IS-IS [RFC1195], etc., two routers are said to have a session up >> > if they are able to exchange protocol packets (i.e., the peers >> > have an adjacency). Messages replayed during an adjacency are >> > intra-session replays while message replayed between two peers >> > who re-establish an adjacency after a reboot or loss of >> > connectivity are inter-session replays. >> > >> > >> > 5. Routing Protocols (or the transport or network mechanism >> > protecting routing protocols) SHOULD be able to detect and >> > reject replayed messages both intra-session and inter-session. >> > >> > Packets captured from one session MUST not be able to be re-sent >> > and accepted during a later session (i.e., inter-session replay). >> > Additionally, replay mechanisms MUST work correctly even in the >> > presence of routing protocol packet prioritization by the router. >> >> I mostly implemented this, except I think the proper Terminology addition >> is "Replayed Messages" not "Replay Attacks" so I've reworded it to meet >> that term. >> > > > Do I think the new text in -07 for these two points is better? Yes, albeit > marginally. Do I think the document, as a whole will be more successful > because of it? Not at all. I'd have rather seen this published 3 months > ago. But that's the past now. Changes approved. > > > >> >> > >> > is this a little clear for the last paragraph?: >> > >> > For protocols like OSPF [RFC2328], IS-IS [RFC1195], BFD [RFC5880], >> > and RIP [RFC2453] that currently share the same authentication and >> > message integrity key on a broadcast segment, it is important that >> > an integrity check associated associated with a message fail if an >> > attacker has replayed the message with a different origin. >> >> This mostly makes sense to me, but I did reword it. I retained the >> initial sentence. >> > > I approve the text in -07 on this point. (Again, I don't think it will > make the document any more successful; I think we are WAY beyond the point > of truly material critique). > > >> >> > >> > and now for a bunch of nits: >> > >> > 1) s2.3: Step 4: Still having issues with the following but I think >> you're getting closer: >> > >> > Measurably, we >> > would like to see an increase in the number of surveyed >> > respondents who report deploying the updated authentication and >> > integrity mechanisms in their networks, as well as a sharp rise >> > in usage for the total percentage of their network's routers. >> > >> > I think they're trying to say this: >> > >> > We would like to see a measurable increase in the number of surveyed >> > respondents who report [ISR2008] deploying .... >> >> I wrote something similar to this. >> > > fine. (Again, will NOT make the document materially more successful.) > > >> > >> > 2) 2.3: step 4: r/(iBGP/(iBGP) >> > >> > 3) s2.4: If you mention Confidentiality as a non-goal. It would also >> be good to also include non-repudiation: >> > >> > o Confidentiality and non-repuidation of the packets on the wire. >> > Once this roadmap is realized, we may revisit work on >> > confidentiality and non-repudiation. >> >> This is truly a non-goal, but should always be a non-goal. I don't ever >> want to revisit work on "non-repudiation". How about if we add it to the >> list of non-goals, but remove half-promises about possibly working on them >> in the future? Or was this a hot button to someone? > > > The text about confidentiality was indeed a hot button to the folks that > tried to get us to work on confidentiality in this go around. It was > compromise text, that we leave the door open for work later. (And this is a > difficult side effect of doing IETF last calls, and then letting the IESG > do their reviews: IESG can push / demand for things to change that were > the result of WG tussles, negotiations, and compromises, and then the doc > gets changed and published without the WG really okaying those changes.) > > Personally, I don't care. But as a document editor, trying hard to > neutrally include as much input as reasonably possible from the WG, I feel > I'd be failing that minority if we just cut the text behind the scenes at > the last minute. > > Attached is an XML -07a with the following: > > "The following goals are considered out-of-scope for this effort: > o Confidentiality of the packets on the wire. Once this roadmap is > realized, work on confidentiality may be considered. > > o Non-repudiation of the packets on the wire. > > o Message content validity... " > > >> >> > 4) s3.3, INTERFERENCE: denial of receipt is one of the non-repudiation >> so maybe: >> > >> > DENIAL OF RECEIPT (non-repudiation) >> > > fine. > > >> > >> > 5) s5 #6: r/MUST not/MUST NOT >> > > This was actually s4 #5, I think. Fine. > > > >> > >> > 6) s4 #7: I think it's true that any good policy would require a key >> changed ... r/Keys may need to/Keys need to >> >> This is a hot button I think, so I suggest we leave the existing text. >> > > Agreed. Further, changing it wouldn't make the document more successful. > And Sean listed it as a "Nit". Text unchanged. > > >> >> > >> > 7) s4 #14: Maybe: r/immediately verifiable by/immediately and >> independently verifiable by >> > > > Fine. > > > >> > >> > 9) s4 #19: I think the 1st and 3rd sentences are duplicated. And "some >> benefit" is a little squishy: >> > >> > 19. Every new KARP-developed security mechanisms MUST support >> > incremental deployment. >> > >> > Proposed solutions MUST >> > support an incremental deployment method that provides some >> > benefit for those who participate. >> >> There a purpose for each of the lines here. I do suggest changing >> "provides some benefit" to "that benefits" to make it sound less squishy. >> > > Fine (again, will not make a difference to the documents success either > way). > > Brian, I'd like to ask your approval to add you to the author/editor list, > given all the work you've done on this over the last year and a half. Do > you approve? Assuming so, I've added you in the -07a, and touched up the > Acknowledgements accordingly. You'll want to double check your details > under the Author's Addresses section (I pouched them from RFC6411). Once > done you can send me the -07b xml and I'll publish it (or feel free to > publish it yourself, either way is fine). > > Glad to move this to publishing!! Thanks to you all for your hard work. > > Do you guys mind if I send this email to the WG, so Sean's and our > comments become a matter of the open process record? > > Gregory > > >> >> Let me know, >> Brian >> >> >> >> >> > >> > spt >> > >> > On 11/7/12 3:11 PM, Brian Weis wrote: >> >> Hi Sean, >> >> >> >> Just a gentle reminder ... looks like the DISCUSS hasn't been cleared >> yet: < >> http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ballot/>. I >> know this week is busy but maybe early next week you could take care of it? >> >> >> >> Thanks! >> >> Brian >> >> >> >> On Oct 29, 2012, at 2:14 PM, Sean Turner wrote: >> >> >> >>> Got this I'll get to it hopefully by tomorrow, but definitely by >> Friday. >> >>> >> >>> spt >> >>> >> >>> On 10/25/12 12:51 PM, Brian Weis wrote: >> >>>> Hi Sean, >> >>>> >> >>>> You had a lengthy DISCUSS on draft-ietf-karp-threats-reqs, mostly as >> a result of Steve Kent's SecDir review. I have worked extensively with the >> authors, and we believe that all of the comments have been resolved in -06. >> We also re-checked Steve's actual SecDir review and considered comments >> that you may not have entered in your DISCUSS. Please let us know if >> there's any more information that you need to clear your DISCUSS, and I'll >> be happy to provide it. >> >>>> >> >>>> I would ask if you could work through this soon, so that we can move >> on in KARP. I apologize for not reaching out sooner, but I misunderstood >> the process at this point. Diffs are here: < >> http://tools.ietf.org/rfcdiff?url2=draft-ietf-karp-threats-reqs-06.txt>. >> >>>> >> >>>> Thanks, >> >>>> Brian >> >>>> >> >> >> >> >> >> >> > > > -- > ---- > IETF related email from > Gregory M. Lebovitz > > -- ---- IETF related email from Gregory M. Lebovitz --f46d04448159c440e904d14274d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm about to post -07 of the threats-reqs document. The authors have ad= dressed all issues raised on Sean's second round of DISCUSS during IESG= review, and Sean has now signed off. The details are all inline below. (cc= 'ing the KARP mail list so we have a public record of the DISCUSS issue= s and their resolutions.)

Let's publish!!

Gregory

=
On Sun, Dec 16, 2012 at 10:37 PM, Bhatia, Manav = (Manav) <manav.bhatia@alcatel-lucent.com> wrot= e:
Hi,
=A0
I am in complete agreement with everything that Gregory has=20 written here and especially the part about getting the document delayed for= this=20 long without radically improving the readability or the content of the docu= ment=20 ! :-)
=A0
I am ok, as i had said earlier, with the latest version -07=20 and i think we should just get it outta our door now!
=A0
I would also concur with Greg on including Brian as a=20 co-author, if thats acceptable to Brian!
=A0
Cheers, Manav

From: Gregory Lebovitz=20 [mailto:grego= ry.ietf@gmail.com]
Sent: Monday, December 17, 2012=20 11:31 AM
To: Brian Weis
Cc: Gregory Lebovitz; Bhatia,= =20 Manav (Manav); Sean P. Turner

Subject: Re: Cl= earing your DISCUSS on=20 draft-ietf-karp-threats-reqs

Brian, Manav & Sean,
Boyz, let's get this thang done!! :-)

I think it most direct to comment inline to this original email, eve= n=20 though the last correspondance on the thread was actually Dec 1.

I'm also wondering, Sean, why did you send your comments to Bria= n, and=20 not to Manav and I, the authors? Although at this point I think Brian has= put=20 so much work into this document that you ought to be on the author list t= oo.=20 (see my comment at the end, below, about Brian and author recognition). N= o=20 accusation here, Sean. Just curious.

Comments inline below...


On Wed, Nov 21, 2012 at 5:54 PM, Brian Weis <bew@= cisco.com> wrote:
Hi=20 Gregory and Manov,

Almost done, but Sean has a couple remaining= =20 issues. I've attached a version with proposed edits to deal with th= em.=20 Please correct or say you can live with them. I've added some expla= natory=20 text inline.

On Nov 13, 2012, at 2:46 PM, Sean Turner <turners@ieca.com> wr= ote:

>=20 Just got two left. =A0Maybe I can do this quicker here and you can tell= =20 me if I'm just not getting it (entirely possible):
>
> = 1) s4 #3:=20 Algorithm agility means that the protocol doesn't hard code an algo= rithm in.=20 =A0That's covered here, but there's also this:
>
>= =20 =A0Additionally, more than one algorithm MUST be=20 specified.
>
> which could be a whole lot more - is it two = MTI=20 algorithms? =A0I don't want people to misinterpret this later down = the=20 road. =A0Maybe an example would clear this up: "(i.e., one mandato= ry to=20 implement algorithm and one or more backup algorithms to guide=20 transition)."

I think it's time to capitulate on two ma= ndatory to=20 implement algorithms. But it is important to specify two algorithm, so = it=20 makes sense to me to specify more than one but only mandate=20 one.

Ok. I don't agree, but I'm willing to let this go for the sa= ke of getting=20 the document done.=A0

The only way to be sure implementations can really move between mult= iple=20 algorithms, and do so with interoperability,=A0 is for them to actually= =20 have multiple algorithms implemented, and test both during bake-offs. I k= now=20 from experience, the hard way, with both IKEv1 and IKEv2. Two MTI's i= s the=20 only way to ensure this.

However, I think the text proposed in -07 is about as strong as you = can=20 get without actually mandating two MTI's:

=A0 =A0 =A0 =A0Mandating support for two algorithms (i.e.,=20 one
=A0 =A0 =A0 =A0 both redundancy, and a mechanism for enacting=20 that redundancy. =A0 =A0 =A0 =A0mandatory =A0=20 =A0=A0
=A0 =A0 =A0 =A0 to implement algorithm and one or more=20 backup
=A0 =A0 =A0 =A0 algorithms to guide transition) provides both=20 redundancy, and a
=A0 =A0 =A0 =A0 mechanism for enacting that=20 redundancy.

I will not block on this issue. The -07 text may stand.

=A0

>
>=20 2) s4 #5: I'm confused whether the SHOULD in the first paragraph is= for=20 intra-session replay and the MUST is for inter-session? =A0It's pro= bably=20 also worth defining what the two are in the terminology=20 section.
>
> Anyway let me give this a shot and see what yo= u=20 think:
>
> Terminology:
>
> =A0Replay Attacks:= =20 For non-TCP based protocols like OSPF [RFC2328],
> =A0IS-IS=20 [RFC1195], etc., two routers are said to have a session up
> =A0i= f=20 they are able to exchange protocol packets (i.e., the peers
>=20 =A0have an adjacency). =A0Messages replayed during an adjacency=20 are
> =A0intra-session replays while message replayed between two= =20 peers
> =A0who re-establish an adjacency after a reboot or loss= =20 of
> =A0connectivity are inter-session=20 replays.
>
>
> 5. Routing Protocols (or the transport= or=20 network mechanism
> =A0 =A0protecting routing protocols) SHOULD= =20 be able to detect and
> =A0 =A0reject replayed messages both=20 intra-session and inter-session.
>
> =A0 =A0Packets=20 captured from one session MUST not be able to be re-sent
> =A0=20 =A0and accepted during a later session (i.e., inter-session=20 replay).
> =A0 =A0Additionally, replay mechanisms MUST work=20 correctly even in the
> =A0 =A0presence of routing protocol=20 packet prioritization by the router.

I mostly implemented this,= =20 except I think the proper Terminology addition is "Replayed Messag= es" not=20 "Replay Attacks" so I've =A0reworded it to meet that term= .


Do I think the new text in -07 for these two points is better? Yes,= =20 albeit marginally. Do I think the document, as a whole will be more succe= ssful=20 because of it? Not at all. I'd have rather seen this published 3 mont= hs ago.=20 But that's the past now. Changes approved.

=A0

>
>=20 is this a little clear for the last paragraph?:
>
> =A0=20 =A0For protocols like OSPF [RFC2328], IS-IS [RFC1195], BFD=20 [RFC5880],
> =A0 =A0and RIP [RFC2453] that currently share the=20 same authentication and
> =A0 =A0message integrity key on a=20 broadcast segment, it is important that
> =A0 =A0an integrity=20 check associated associated with a message fail if an
> =A0=20 =A0attacker has replayed the message with a different origin.

Th= is=20 mostly makes sense to me, but I did reword it. I retained the initial= =20 sentence.

I approve the text in -07 on this point. (Again, I don't think i= t will=20 make the document any more successful; I think we are WAY beyond the poin= t of=20 truly material critique).
=A0

>
>=20 and now for a bunch of nits:
>
> 1) =A0s2.3: Step 4: Still= =20 having issues with the following but I think you're getting=20 closer:
>
> Measurably, we
> would like to see an inc= rease=20 in the number of surveyed
> respondents who report deploying the= =20 updated authentication and
> integrity mechanisms in their networ= ks,=20 as well as a sharp rise
> in usage for the total percentage of th= eir=20 network's routers.
>
> I think they're trying to sa= y=20 this:
>
> We would like to see a measurable increase in the= =20 number of surveyed
> respondents who report [ISR2008] deploying= =20 ....

I wrote something similar to this.

fine. (Again, will NOT make the document materially more=20 successful.)
=A0
>
>=20 2) 2.3: step 4: r/(iBGP/(iBGP)
>
> 3) s2.4: If you mention= =20 Confidentiality as a non-goal. =A0It would also be good to also include= =20 non-repudiation:
>
> =A0o =A0Confidentiality and=20 non-repuidation of the packets on the wire.
> =A0 =A0 Once this= =20 roadmap is realized, we may revisit work on
> =A0 =A0=20 confidentiality and non-repudiation.

This is truly a non-goal, b= ut=20 should always be a non-goal. I don't ever want to revisit work on= =20 "non-repudiation". How about if we add it to the list of non-= goals, but=20 remove half-promises about possibly working on them in the future? Or w= as=20 this a hot button to someone?

The text about confidentiality was indeed a hot button to the folks = that=20 tried to get us to work on confidentiality in this go around. It was=20 compromise text, that we leave the door open for work later. (And this is= a=20 difficult side effect of doing IETF last calls, and then letting the IESG= do=20 their reviews: =A0IESG can push / demand for things to change that were t= he=20 result of WG tussles, negotiations, and compromises, and then the doc get= s=20 changed and published without the WG really okaying those changes.)

Personally, I don't care. But as a document editor, trying hard = to=20 neutrally include as much input as reasonably possible from the WG, I fee= l I'd=20 be failing that minority if we just cut the text behind the scenes at the= last=20 minute.

Attached is an XML -07a with the following:

"The following goals are considered out-of-scope for this effor= t:
=A0o =A0Confidentiality of the packets on the wire. Once this=20 roadmap is realized, work on confidentiality may be considered.

=A0o Non-repudiation of the packets on the wire.

=A0o Message content validity... "
=A0

>=20 4) s3.3, INTERFERENCE: denial of receipt is one of the non-repudiation = so=20 maybe:
>
> =A0 DENIAL OF RECEIPT=20 (non-repudiation)

fine.
=A0
>
>=20 5) s5 #6: r/MUST not/MUST NOT

This was actually s4 #5, I think. Fine.

=A0
>
>=20 6) s4 #7: I think it's true that any good policy would require a ke= y changed=20 ... r/Keys may need to/Keys need to

This is a hot button I think= , so=20 I suggest we leave the existing text.

Agreed. Further, changing it wouldn't make the document more suc= cessful.=20 And Sean listed it as a "Nit". Text unchanged.
=A0

>
>=20 7) s4 #14: Maybe: r/immediately verifiable by/immediately and independe= ntly=20 verifiable by


Fine.

=A0
>
>=20 9) s4 #19: I think the 1st and 3rd sentences are duplicated. =A0And &qu= ot;some=20 benefit" is a little squishy:
>
> 19. =A0Every new=20 KARP-developed security mechanisms MUST support
> =A0 =A0 =A0=20 =A0incremental deployment.
>
> =A0 =A0 =A0=20 =A0Proposed solutions MUST
> =A0 =A0 =A0 =A0support an=20 incremental deployment method that provides some
> =A0 =A0=20 =A0 =A0benefit for those who participate.

There a purpose for=20 each of the lines here. I do suggest changing "provides some benef= it" to=20 "that benefits" to make it sound less squishy.

Fine (again, will not make a difference to the documents success eit= her=20 way).

Brian, I'd like to ask your approval to add you to the author/ed= itor=20 list, given all the work you've done on this over the last year and a= half. Do=20 you approve? Assuming so, I've added you in the -07a, and touched up = the=20 Acknowledgements accordingly. You'll want to double check your detail= s under=20 the Author's Addresses section (I pouched them from RFC6411). Once do= ne you=20 can send me the -07b xml and I'll publish it (or feel free to publish= it=20 yourself, either way is fine).

Glad to move this to publishing!! Thanks to you all for your hard=20 work.

Do you guys mind if I send this email to the WG, so Sean's and o= ur=20 comments become a matter of the open process record?

Gregory
=A0

Let=20 me know,
Brian




>
> spt
>
> O= n=20 11/7/12 3:11 PM, Brian Weis wrote:
>> Hi=20 Sean,
>>
>> Just a gentle reminder ... looks like the= =20 DISCUSS hasn't been cleared yet: <http:/= /datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ballot/>.=20 I know this week is busy but maybe early next week you could take care = of=20 it?
>>
>> Thanks!
>>=20 Brian
>>
>> On Oct 29, 2012, at 2:14 PM, Sean Turner= =20 <turners@ieca.= com>=20 wrote:
>>
>>> Got this I'll get to it hopefull= y by=20 tomorrow, but definitely by Friday.
>>>
>>>=20 spt
>>>
>>> On 10/25/12 12:51 PM, Brian Weis=20 wrote:
>>>> Hi Sean,
>>>>
>>>= >=20 You had a lengthy DISCUSS on draft-ietf-karp-threats-reqs, mostly as a= =20 result of Steve Kent's SecDir review. I have worked extensively wit= h the=20 authors, and we believe that all of the comments have been resolved in = -06.=20 We also re-checked Steve's actual SecDir review and considered comm= ents that=20 you may not have entered in your DISCUSS. Please let us know if there&#= 39;s any=20 more information that you need to clear your DISCUSS, and I'll be h= appy to=20 provide it.
>>>>
>>>> I would ask if you = could=20 work through this soon, so that we can move on in KARP. I apologize for= not=20 reaching out sooner, but I misunderstood the process at this point. Dif= fs=20 are here: <http://tools.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-karp-threats-reqs-06.txt>.
>>>>>>>>=20 Thanks,
>>>>=20 Brian
>>>>
>>
>>





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




--
----
IETF= related email from
Gregory M. Lebovitz
--f46d04448159c440e904d14274d2-- From internet-drafts@ietf.org Wed Dec 19 22:22: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 1505321F8A5D; Wed, 19 Dec 2012 22:22:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sf403CHH1KaU; Wed, 19 Dec 2012 22:22:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3E521F8A44; Wed, 19 Dec 2012 22:22:37 -0800 (PST) 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.37 Message-ID: <20121220062237.1282.41741.idtracker@ietfa.amsl.com> Date: Wed, 19 Dec 2012 22:22:37 -0800 Cc: karp@ietf.org Subject: [karp] I-D Action: draft-ietf-karp-threats-reqs-07.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, 20 Dec 2012 06:22:58 -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 Pro= tocols Working Group of the IETF. Title : Keying and Authentication for Routing Protocols (KARP) O= verview, Threats, and Requirements Author(s) : Gregory Lebovitz Manav Bhatia Brian Weis Filename : draft-ietf-karp-threats-reqs-07.txt Pages : 32 Date : 2012-12-19 Abstract: Different routing protocols employ different mechanisms for securing 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 Security Area and IETF 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 protocol transport systems. This includes any mechanisms built into the routing protocols themselves, to authenticate packets. 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-karp-threats-reqs-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-karp-threats-reqs-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jmh@joelhalpern.com Thu Dec 20 06:17: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 0F20C21F88C7; Thu, 20 Dec 2012 06:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4XPro-O0F6X; Thu, 20 Dec 2012 06:17:01 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 579D621F84F8; Thu, 20 Dec 2012 06:17:01 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id B8ABCA3679; Thu, 20 Dec 2012 06:17:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8D1551C2B48; Thu, 20 Dec 2012 06:17:00 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-81.clppva.east.verizon.net [70.106.135.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 499D31C07AC; Thu, 20 Dec 2012 06:16:59 -0800 (PST) Message-ID: <50D31DD6.5080100@joelhalpern.com> Date: Thu, 20 Dec 2012 09:16:54 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Nick Hilliard References: <50D0EA56.3050308@inex.ie> <50D0ED83.3090700@joelhalpern.com> <50D24A43.6050608@inex.ie> In-Reply-To: <50D24A43.6050608@inex.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-karp-routing-tcp-analysis.all@tools.ietf.org" , "ietf@ietf.org List" , "karp@ietf.org" Subject: Re: [karp] Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06 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, 20 Dec 2012 14:17:02 -0000 Thank you Nick. With regard to the suggest text replacement of "has to" with "needs to", if you think that will help, lets go wit it (at then let the RFC Editor tell us if it doesn't work.) With regard to obsoleting TCP-MD5, that is what the RFCs say. The TCP-MD5 is obsoleted by the TCP-AO RFC. Further, the security folks are quite adamant that we should be shifting our recommendations, and where possible our practice. If there are not yep implementations, we need to be pushing folks harder to get them. If I understand your next item properly, you are asking that we add a sentence about the fact that implementation of security mechanisms needs to be doe carefully, so as not to make things worse. Seems easy to do and can't hurt, so we should do so. And equally, noting that security is more than cryptography, and more than signatures, is probably sensible. Authors, WG, can we live with these? I would think so. Yours, Joel On 12/19/2012 6:14 PM, Nick Hilliard wrote: > On 18/12/2012 22:26, Joel M. Halpern wrote: >> Nick, I appreciate that you have read this document and commented. >> >> Two general questions: >> 1) Can you be more specific about where you see unclear language usage? It >> is hard to fix a general coment. > > I was referring to the use of "has to", but the phrase only appears three > times so maybe it's not going to be a large amount of work to eradicate it. > This might work: > > s/has to/needs to/g > > I overestimated to myself the number of times it appeared by flicking back > and forwards through the document when looking at it last night. > >> 2) A number of your comments seem to be about general router security. Many >> of them would see far more appicable to RFC 6518. This document is just >> about changes to protect TCP sessions (yes, what we are concerned about are >> the TCP sessions used by routers.) Can you take a look at your comments, >> and tell us which ones are applicable to this document, and which ones >> should be held for when the community is ready to revise RFC 6518? > > 6518 looks like a roadmap to me. I don't see any of these comments as > being especially relevant to that document. > > There are 3 general suggestions and the rest of the issues are either style > or syntax editing issues, and I think they are all relevant to this > document. These suggestions are: > > 1: > >>> I have a general issue with the statement "TCP MD5 [RFC2385] has been >>> obsoleted by TCP-AO [RFC5925]." At this time, I'm not aware of any live >>> TCP-AO implementations. So while I understand that md5 is effectively >>> obsolete from the specification point of view, from the point of view of >>> operational reality it's still the only show in town (no-one uses ipsec for >>> this). > > We don't have running code for the new protocol, but we have very wide > deployment for the older protocol. So I question how appropriate it is to > make a statement on whether the new protocol has obsoleted the old one. > I'm not familiar enough with ietf nous to know whether this is relevant to > a document like this. Wearing my operator hat, it looks a little odd, > that's all. > > 2: > >>> There is a second operational issue which may merit mention here, namely >>> the issue of ensuring that whatever session layer authentication is >>> implemented on an actual network device, that it doesn't create more >>> problems than it solves. Specifically, if session layer authentication is >>> pushed too far down the protocol stack, cryptographic authentication can >>> occur before other basic checks which might be a whole pile less CPU >>> intensive. There was a scare about this several years ago when it turned >>> out that a well-known vendor had implemented tcp md5 checksumming before >>> more basic tcp session checks (e.g. seq numbers, ttl, etc). In the event, >>> this turned out to be a red herring because md5 is sufficiently gentle on >>> the CPU that it didn't make much difference in reality. >>> >>> However, there is cryptographic value in using more computationally >>> intensive hashing algorithms, and if routers (which often have relatively >>> slow general CPUs or route-processor CPUs) were to get trashed with a large >>> flood of packets which were signed with a cpu-intensive hashing algorithm, >>> and if the checksum were to be implemented in the wrong place in the TCP >>> stack, then this could become an actual problem. > > Whatever a router manufacturer does in terms of implementation, they need > to be careful when writing code to ensure that they don't accidentally open > up other attack vectors by implementing transport layer security badly. It > almost happened once before, and this could have caused damage at the time > if we had had been using a computationally expensive algorithm like openbsd > bcrypt instead of md5. > > 3: > >>> It may be useful to consider whether to acknowledge the existence of rfc >>> 6192 in the context of providing a link to what other steps might be useful >>> to secure routers. > > What I'm suggesting here is a single sentence around the first paragraph in > section 2.1 to say that while it's outside the context of transport > security, there's more to protecting routers than cryptography - and then > provide a link to 6192 as an informative reference to someone who might be > interested in the more general area router security. > > General router security is a large subject which is not particularly > pertinent to keying and authentication, but a random operator who happens > to read this ID when it's published might appreciate the pointer. > > Nick > > From iesg-secretary@ietf.org Thu Dec 20 07:03: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 98E5E21F83EF; Thu, 20 Dec 2012 07:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6iinq3MXKRD; Thu, 20 Dec 2012 07:03:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D696921F841C; Thu, 20 Dec 2012 07:03:39 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121220150339.30566.35528.idtracker@ietfa.amsl.com> Date: Thu, 20 Dec 2012 07:03:39 -0800 Cc: karp mailing list , karp chair , RFC Editor Subject: [karp] Document Action: 'Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements' to Informational RFC (draft-ietf-karp-threats-reqs-07.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, 20 Dec 2012 15:03:41 -0000 The IESG has approved the following document: - 'Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and Requirements' (draft-ietf-karp-threats-reqs-07.txt) as Informational RFC This document is the product of the Keying and Authentication for Routing Protocols Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-karp-threats-reqs/ Technical Summary Existing IAB work recommends the tightening of the security of the core routing infrastructure. This document provides a threat analysis for attacks against routing protocols' transports and the then enumerates the requirements for addressing the described threats. It is intended to be used by KARP design teams in their analysis of routing protocols, and will generally be useful in the analysis of routing protocols. Working Group Summary The working group support publication of this document as an informational document. Document Quality This informational document does not specify a protocol or other semantics that can be directly implemented, thus there are no machine implementations. However, in terms of quality it has been reviewed by a number of security experts. Personnel Brian Weis (bew@cisco.com) is the Document Shepherd for this document. Stewart Bryant (stbryant@cisco.com) is the Responsible Area Director. From mjethanandani@gmail.com Thu Dec 20 07:42:29 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 9AC8A21F8923; Thu, 20 Dec 2012 07:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ig1VaWoeM7kL; Thu, 20 Dec 2012 07:42:29 -0800 (PST) Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) by ietfa.amsl.com (Postfix) with ESMTP id 004FC21F892E; Thu, 20 Dec 2012 07:42:28 -0800 (PST) Received: by mail-da0-f48.google.com with SMTP id k18so1594090dae.7 for ; Thu, 20 Dec 2012 07:42:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=TXTWHivgzz9W9yq1nUSt185y+Ud1jscUEr2GefzlUzk=; b=VArWCB8j1qNdbBXb5+lOm9u1rHDAfHtSyWdWwmiiZNDcSrgr0/Tfllh0yU++yVE46W 0ddpTpUVx07Ahfi9oC1CdixBopqPGMw5COd6488jbzEhBy4RsweYKFzaHcZV6q0TP6+k 0eHm1Ql4LDcuOQA+nS6+6NL84AsqeUaoclg6FkqHGQv+VhsMO16NOO9pQytljyE23YK8 tDSNwjZKdHWdv7AJbFb/Y5l/MoaIpo/nedAvhlfP3QMZYVetGTRVkPZjBFMjIIubSbRt p+Q/CyFi7YgBzxI43qkecuQELqwC7GijVkpgSRRLu04ffl98h5DA6qrPnIcN/tCpngT5 qFoA== X-Received: by 10.66.81.198 with SMTP id c6mr28488028pay.50.1356018148689; Thu, 20 Dec 2012 07:42:28 -0800 (PST) Received: from [192.168.1.123] (c-24-6-180-144.hsd1.ca.comcast.net. [24.6.180.144]) by mx.google.com with ESMTPS id o5sm5587281paz.32.2012.12.20.07.42.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Dec 2012 07:42:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-14--246177228 From: Mahesh Jethanandani In-Reply-To: <50D31DD6.5080100@joelhalpern.com> Date: Thu, 20 Dec 2012 07:42:24 -0800 Message-Id: <60A5315E-C898-48D8-BE0F-A57D82A20EE3@gmail.com> References: <50D0EA56.3050308@inex.ie> <50D0ED83.3090700@joelhalpern.com> <50D24A43.6050608@inex.ie> <50D31DD6.5080100@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1085) Cc: "draft-ietf-karp-routing-tcp-analysis.all@tools.ietf.org" , Nick Hilliard , "ietf@ietf.org List" , "karp@ietf.org" Subject: Re: [karp] Gen-ART Telechat Review of draft-ietf-karp-routing-tcp-analysis-06 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, 20 Dec 2012 15:42:29 -0000 --Apple-Mail-14--246177228 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Yes. On Dec 20, 2012, at 6:16 AM, Joel M. Halpern wrote: > Authors, WG, can we live with these? I would think so. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail-14--246177228 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Yes.

On Dec 20, 2012, at 6:16 AM, Joel M. Halpern wrote:

Authors, WG, can we live with these?  I would think so.

Mahesh Jethanandani



--Apple-Mail-14--246177228--