From wesley.george@twcable.com Tue Jan 3 07:19:05 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143FA21F8501 for ; Tue, 3 Jan 2012 07:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.688 X-Spam-Level: X-Spam-Status: No, score=-0.688 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+dNRGOZ1Uwj for ; Tue, 3 Jan 2012 07:19:04 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4109121F8500 for ; Tue, 3 Jan 2012 07:19:04 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,449,1320642000"; d="scan'208";a="318707537" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 03 Jan 2012 10:12:06 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 3 Jan 2012 10:18:08 -0500 From: "George, Wes" To: "Tissa Senevirathne (tsenevir)" , Alia Atlas , Thomas Narten Date: Tue, 3 Jan 2012 10:18:08 -0500 Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Thread-Index: AczAOV9AO739g+PWQ3KF7sa2WFeXjwAGaGpgAnRWlBA= Message-ID: References: <20111031213450.304.9289.idtracker@ietfa.amsl.com><17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com><201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com><9A429B54-19F8-493A-A729-A0D25C961764@cisco.com><351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net><711DB1AD-52F2-4FCB-8579-0C300A22D409@cisco.com><201112212317.pBLNH4aP019979@cichlid.raleigh.ibm.com> <344037D7CFEFE84E97E9CC1F56C5F4A551AE74@xmb-sjc-214.amer.cisco.com> In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A551AE74@xmb-sjc-214.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Carlos Pignataro \(cpignata\)" , "Enke Chen \(enkechen\)" , "int-area@ietf.org" , "akatlas@juniper.net" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 15:19:05 -0000 > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Tissa Senevirathne (tsenevir) > Sent: Wednesday, December 21, 2011 9:46 PM > Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext- > 03.txt > > Also, do not forget, the authentication object specified here is > similar to what is used in OSPF. If routers can do that for OSPF, they > certainly can do this for Ping. If they cannot we can fall back to > default information and return additional error code to say > authentication failure. > [WEG] Key point here - SP routers don't get a lot of OSPF messages from ran= dom hosts on the internet, and even if we do, we pretty much summarily drop= them because we aren't expecting to use them ever. We do, however get a lo= t of ICMP for traceroute/ping, meaning that the filters already have to be = a lot less restrictive. You're *way* oversimplifying the method to secure t= his such that it doesn't create added router load. Even if we assume multiple tiers of validation - say authorized source IP v= s not, some sort of auth key vs not, and tie independent rate-limits to eac= h, if they're not processed in the right order, you might open an attack ve= ctor simply by receiving too many packets that fail auth check. I'm also wo= ndering about whether it's realistic to assume that looking deeper into the= packet to find the absence or presence of these proposed options can still= be done in hardware, or whether some older (and therefore less stout) plat= forms have to punt it because their hardware is optimized to look to only a= certain depth when handling ICMP in a scalable way. There are lots of oppo= rtunities for assumptions about the relative rate of different types of ICM= P messages such that you can use a more optimized way to process certain on= es at higher scale while punting others, and those are quite likely to bite= us when proposing new ones. Additionally, managing such ACLs and auth keys to govern who has access to = management information and the associated rate limit, scale, and security c= onsiderations for internal stuff is onerous enough without even thinking ab= out adding this capability for external hosts, whether partners or otherwis= e. This is less a technical problem than a political/organizational one, bu= t it exists nonetheless. SNMP is a great example - If you ask every large provider exactly what each= of the permitted SNMP hosts in their config are doing (which MIBs, rate of= query, etc), it's likely that only about half can tell you with any certai= nty, and you're almost guaranteed to find overlap and cruft in what's being= permitted/used. SNMP is one of those things that gradually rots in the con= fig despite everyone's best intentions, because the polling servers and the= polled routers (or VMs or whatever) are managed by different groups that d= on't communicate well with one another, and tools get added/removed/changed= all the time. Depending on how tightly you control your config standards, = people might stand up poller boxes mostly on their own, configure them with= the right IP range and SNMP key and start beating the hell out of your box= es in order to use some new tool, up to and including polling way more info= rmation than they actually need, "just in case." And worse yet, they're oft= en polling for information that is already being polled and stored on a dif= ferent box that they didn't know existed or don't have access to. When impl= ementing a new platform, after exhausting all leads to figure out what the = config is doing, you're often stuck saying "no one knows what that entry do= es, leave it out, let's see who screams". Alternately, you end up troublesh= ooting scale problems because you have too many hosts asking for too much i= nformation in near real-time such that you find and exercise all of the poo= r IPC design in the larger-scale systems and end up with delayed or incompl= ete information from your monitoring system. All of this points to a need for a better method for warehousing, distribut= ing, parsing/correlating, and presenting existing information, not another = method to carry the information between two points. Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Tue Jan 3 07:29:53 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCAE21F850C for ; Tue, 3 Jan 2012 07:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.343 X-Spam-Level: X-Spam-Status: No, score=-0.343 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-0ZmMW+0cyz for ; Tue, 3 Jan 2012 07:29:53 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 215FA21F84F9 for ; Tue, 3 Jan 2012 07:29:53 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,449,1320642000"; d="scan'208";a="302846406" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 03 Jan 2012 10:28:41 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Tue, 3 Jan 2012 10:29:52 -0500 From: "George, Wes" To: "Tissa Senevirathne (tsenevir)" , Jared Mauch , "Naiming Shen (naiming)" Date: Tue, 3 Jan 2012 10:29:51 -0500 Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Thread-Index: AczAQ48on9GebfCqTcakjFDSA6hnuAAEFo8gAnSJ2ZA= Message-ID: References: <20111031213450.304.9289.idtracker@ietfa.amsl.com><17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com><201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com><9A429B54-19F8-493A-A729-A0D25C961764@cisco.com><351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net><711DB1AD-52F2-4FCB-8579-0C300A22D409@cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A551AE75@xmb-sjc-214.amer.cisco.com> In-Reply-To: <344037D7CFEFE84E97E9CC1F56C5F4A551AE75@xmb-sjc-214.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "Carlos Pignataro \(cpignata\)" , "Enke Chen \(enkechen\)" , "int-area@ietf.org" , "akatlas@juniper.net" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 15:29:53 -0000 > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Tissa Senevirathne (tsenevir) > Sent: Wednesday, December 21, 2011 9:49 PM > To: Jared Mauch; Naiming Shen (naiming) > Cc: Thomas Narten; Carlos Pignataro (cpignata); Enke Chen (enkechen); > int-area@ietf.org; akatlas@juniper.net > Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext- > 03.txt > > Yes. But the problem is you have to switch back and forth between > different applications (SNMP browsers, Network Management applications > etc..) to get the information. With integrated ICMP Ping, you should be > able to get interested data as part of the ping output. > [WEG] Sure, "should", except for hosts in the middle that don't support the= new options, are configured to ignore them, or are not configured to see y= our querying host as trusted enough to receive that information, etc. etc. = This is a solution that rapidly loses value in an incremental deployment mo= del if that's indeed the problem it's purporting to solve. The above issue = of needing to switch between tools may be a problem, but it's a presentatio= n/application layer problem with the *tools*, not the network elements or p= rotocols, and therefore the solution belongs in the application space. I lo= ve direct CLI access as much as the next guy, so I'm trying to keep an open= mind on something that potentially makes it better, but I'm really not in = favor of reinventing the wheel if reduction of swivel-seating for NOC folks= is the primary justification. As I have noted in my message about SNMP, there is already a lot of this "s= olution" happening, where instead of using the same information for multipl= e presentation/correlation tools, we end up with multiple pollers/stores of= the same information and a failure to correlate, to the detriment to the s= cale of the device and its risk of attack. Thanks, Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From rajiva@cisco.com Tue Jan 3 09:53:56 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8571321F849B for ; Tue, 3 Jan 2012 09:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9oanJ43x2zR for ; Tue, 3 Jan 2012 09:53:55 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 68A4221F848A for ; Tue, 3 Jan 2012 09:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=5071; q=dns/txt; s=iport; t=1325613235; x=1326822835; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=q0jia1EOX/7hjA27/jsC9xoBcnM17aStGASRecDuo7w=; b=CCOyaeh5/xqm8X/ny2Tgo9a8pqE3XeaDeb+DRx+JqZqcUjp1ffyFtcan LstB6bV7xUBfaSDbLcwvScQ+jAeLUbWFxbUe1PwI9AFhUuHLFPxMRWV0c QXni8K0kISVfWJDN6McojPiUhqlYp+ZUSX1Ec+P7ciSDuCMPbOLd3ic3p k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8AAJVAA0+tJXG+/2dsb2JhbABDggWaGZBAgQWBcgEBAQMBAQEBDwEUCQo0CwUHBAIBCBEEAQEBCgYXAQYBJh8JCAEBBAESCBqHWAiXVQGdeIssYwSIN58e X-IronPort-AV: E=Sophos;i="4.71,451,1320624000"; d="scan'208";a="48355549" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 03 Jan 2012 17:53:54 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q03HrsPO027363; Tue, 3 Jan 2012 17:53:54 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 11:53:54 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Jan 2012 11:53:53 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C06FBD4E8@XMB-RCD-111.cisco.com> In-Reply-To: <3033A87F-4CE9-4F86-B8A9-ACA472776052@puck.nether.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Thread-Index: AczE+RVm0chii98xRZ2pXcUN+o5IXwFRj5AA References: <20111031213450.304.9289.idtracker@ietfa.amsl.com><17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com><201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com><9A429B54-19F8-493A-A729-A0D25C961764@cisco.com><351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net><4EF497F0.6020101@cisco.com> <3033A87F-4CE9-4F86-B8A9-ACA472776052@puck.nether.net> From: "Rajiv Asati (rajiva)" To: "Jared Mauch" , "Carlos Pignataro (cpignata)" X-OriginalArrivalTime: 03 Jan 2012 17:53:54.0252 (UTC) FILETIME=[A89D98C0:01CCCA40] Cc: Thomas Narten , akatlas@juniper.net, "Enke Chen \(enkechen\)" , int-area@ietf.org Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 17:53:56 -0000 Jared, > A commonly used platform can only populate about 8k entries per second > under > load, making a 150k prefix change take 18 seconds or more. This is a > significant > amount of time. Any IPC contention during this time results in further > customer observed downtime. We may be ignoring the fact that CPU could check for the prioritization when scheduling processes, so such important events (as downloading of RIB/FIB changes to the LC) would be prioritized over less important events such as ICMP handling. Of course, this is implementation specific, but I gather that most platforms live by this notion. One could argue that fetching the info from the LC for SNMP related Polling could be qualified as the contender. Microcode programming (or lack thereof) is a way too implementation specific to be discussed (with sufficient details) at the IETF, though I see your point about involved complexity. We would be better off discussing the value of this draft in regards to use-cases of proposed extensions in networks (whether SP or Enterprise). Cheers, Rajiv > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf > Of Jared Mauch > Sent: Tuesday, December 27, 2011 7:39 PM > To: Carlos Pignataro (cpignata) > Cc: Thomas Narten; int-area@ietf.org; akatlas@juniper.net; Enke Chen > (enkechen) > Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt >=20 > Happy Holidays! >=20 > On Dec 23, 2011, at 10:02 AM, Carlos Pignataro wrote: >=20 > > Have you read the Security Considerations section? The first paragraph > > reads: >=20 > I have not, because any additional complexity in the distributed forwarding > plane > or centralized cpu utilization is undesirable in SP operations.. >=20 > Any code where you perform additional checks prior to replying adds load to > the > device and with minimal cpu provided on line cards, this is my main problem. >=20 > Authentication and other mechanisms take away valuable microcode space and > increase the complexity. >=20 > Tier-1 networks have likely evolved significantly since Naiming was in the > space. A single network (Level3) today announces about 50% of the DFZ rib on > a peering session. When this interface goes down, the time spent > processing the rib -> fib -> lc events can be significant on a platform. >=20 > A commonly used platform can only populate about 8k entries per second > under > load, making a 150k prefix change take 18 seconds or more. This is a > significant > amount of time. Any IPC contention during this time results in further > customer observed downtime. >=20 > These are operational challenges that are faced today with modern hardware. > I'm concerned that the innovation provided by this draft is unnecessary for > the network operator and will place undue load upon the network. >=20 > - Jared >=20 > > http://tools.ietf.org/html/draft-shen-traceroute-ping-ext-03#section-6 > > > > 6. Security Considerations > > > > This extension enhances the security of traceroute and ping operation > > in a backwards-compatible fashion. The mechanism allows the receiver > > to verify the sender of the traceroute/ping packet such that certain > > sensitive application, interface and network related information can > > be supplied in the internal network or across trusted networks. > > > > Additionally, the existing framework of RFC 4884 + associated extensions > > (e.g., RFC 4950 and RFC 5837) already address this point: > > > > http://tools.ietf.org/html/rfc4950#section-6 > > > > interaction between MPLS and ICMP. However, this document defines an > > extension that allows an MPLS router to append MPLS information to > > multi-part ICMP messages, and therefore can provide the user of the > > TRACEROUTE application with additional information. Consequently, a > > network operator may wish to provide this information selectively > > based on some policy; for example, only include the MPLS extensions > > in ICMP messages destined to addresses within the network management > > blocks with administrative control over the router. An > > > > http://tools.ietf.org/html/rfc5837#section-6 > > > > It may be desirable to provide this information to a particular > > network's operators and not to others. If such policy controls are > > desirable, then an implementation could determine what sub-objects to > > include based upon the destination IP address of the ICMP message > > that will contain the sub-objects. The implementation of policy > > controls could also be based upon the mechanisms described in > > [TRACEROUTE-EXT] for those limited cases supported. > > > > The authentication in this I-D attempts to make it easier and more scalable. >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From cpignata@cisco.com Tue Jan 3 11:20:50 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4884811E80A3 for ; Tue, 3 Jan 2012 11:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.325 X-Spam-Level: X-Spam-Status: No, score=-110.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjKws2KRQfAH for ; Tue, 3 Jan 2012 11:20:48 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id BBC1411E80A1 for ; Tue, 3 Jan 2012 11:20:48 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q03JKli5009680 for ; Tue, 3 Jan 2012 14:20:47 -0500 (EST) Received: from [10.117.115.55] (rtp-cpignata-8916.cisco.com [10.117.115.55]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q03JKkBn012373; Tue, 3 Jan 2012 14:20:46 -0500 (EST) Message-ID: <4F03550C.2040102@cisco.com> Date: Tue, 03 Jan 2012 14:20:44 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Jared Mauch References: <20111031213450.304.9289.idtracker@ietfa.amsl.com> <17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com> <201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com> <9A429B54-19F8-493A-A729-A0D25C961764@cisco.com> <351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net> <4EF497F0.6020101@cisco.com> <3033A87F-4CE9-4F86-B8A9-ACA472776052@puck.nether.net> In-Reply-To: <3033A87F-4CE9-4F86-B8A9-ACA472776052@puck.nether.net> X-Enigmail-Version: 1.3.4 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "int-area@ietf.org" , "akatlas@juniper.net" , Enke Chen Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:20:50 -0000 Happy Holidays! Jared, Thanks for the responses. I will attempt to group some follow-ups and responses here in a single reply to this email, as most (or all) of your comments are quite related and center around the same root concern. Please see inline. On 12/27/2011 7:38 PM, Jared Mauch wrote: > Happy Holidays! > > On Dec 23, 2011, at 10:02 AM, Carlos Pignataro wrote: > >> Have you read the Security Considerations section? The first paragraph >> reads: > > I have not, because any additional complexity in the distributed forwarding plane > or centralized cpu utilization is undesirable in SP operations.. > > Any code where you perform additional checks prior to replying adds load to the > device and with minimal cpu provided on line cards, this is my main problem. IMHO, there is -- there always is -- a benefit curve and a trade-off. While I understand the point you are making, I would not go as far as saying that any check is bad. Yes, as little as possible given a problem space and an applicabiloity, but certainly not less than that. On the one hand side we have a (security) need for not sending information to any source on an ICMP error. We also have a manageability consideration for *inband* "OAM" requesting specific elements. On the other hand side, there is a (security) consideration to not DoS/overloading a router CPU (or more generically control plane). My point is that there is a curve of benefit between these datapoints that can maximize both. Take for example a layered approach to protection, in which a processing-expensive check (e.g., is performed only after a cheaper test passes, much like GTSM). An authentication check is only performed after rate-limiting and other cheaper checks, or only performed under certain conditions. That said, however, there is an argument that authentication might be too heavyweight. To this, a suggestion of making it optional or even separate from the "probe framework" and modulated by Applicability Considerations seems sensible. > > Authentication and other mechanisms take away valuable microcode space and > increase the complexity. > > Tier-1 networks have likely evolved significantly since Naiming was in the > space. A single network (Level3) today announces about 50% of the DFZ rib on > a peering session. When this interface goes down, the time spent > processing the rib -> fib -> lc events can be significant on a platform. > > A commonly used platform can only populate about 8k entries per second under > load, making a 150k prefix change take 18 seconds or more. This is a significant > amount of time. Any IPC contention during this time results in further > customer observed downtime. > > These are operational challenges that are faced today with modern hardware. > I'm concerned that the innovation provided by this draft is unnecessary for > the network operator and will place undue load upon the network. Staying away from platform specifics but diving into the core of this comment, those are implementation considerations and prioritization to include in a functional spec and not an I-D. I would fundamentally disagree with an advocacy that every check uses CPU cycles and is therefore bad -- and apologies as I might be misunderstanding or mis-generalizing your perspective. > > - Jared > Later, on 12/27/2011 7:52 PM, Jared Mauch wrote: > On Dec 23, 2011, at 10:02 AM, Carlos Pignataro wrote: > >> Jared, >> >> This I-D is not proposing an operational security feature. These generic >> comments are very interesting but perhaps better fitting Opsec; RFC 6192 >> also comes to mind. >> >> What's your take on >> ? > Carlos, > > Including the text for reference: > > -- snip -- > A router needs to protect against purposefully-bogus Traceroute > packets with extensions that fail the authentication, as a high rate > of messages can require significant processing time. [ > RFC1812 > ] > specifies how rate-limiting is applied to the generation of ICMP > messages, and this rate-limiting deters the threat when applied > before checking the Authentication. Additionally, when using > Cryptographic authentication, the HMAC includes the source IP > address, which means the HMAC will not validate if the traceroute/ > ping packet is sent over a NAT. > -- snip -- > > Traceroute packets (ie: ICMP Exception of TTL Expiry). If the authentication is provided in hardware prior to the application of rate-limiting, this can be used to attack the limited CPU resources in a line card. If rate-limited after the authentication, which is more expensive, replying or performing the authentication? While this is an implementation detail, it's important to measure the inherent cost. Sometimes it is more expensive to authenticate vs "just reply". > > Has this cost been measured in the network elements? Reducing performance of the network hardware is not a desired outcome, and a major concern of mine here. > Yes, I would say perform authentication after rate-limiting, make authentication optional, and also default to a very processing cheap reply. Rajiv just mentioned also the difficulties to go into more specifics here. I echo the same comment, and also suggest focusing on the use case and problem being solved. We are after a framework on which we can have more control over what is included in an ICMP message or error. > I'm also concerned that referencing rfc1812 4.3.2.8 could be overly simplistic in talking about rate-limits involved, > are you specifically talking about the Cisco implementation referenced here: No, we are not discussing any particular implementation here, from any vendor. > > http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-addrg_bsc_con.html#wp1373663 > > -- snip -- > In Cisco IOS Release 12.2(8)T or later releases, the IPv6 ICMP rate limiting feature implements a token bucket algorithm for limiting the rate at which IPv6 ICMP error messages are sent out on the network. The initial implementation of IPv6 ICMP rate limiting defined a fixed interval between error messages, but some applications, such as traceroute, often require replies to a group of requests sent in rapid succession. The fixed interval between error messages is not flexible enough to work with applications such as traceroute and can cause the application to fail. > -- snip -- > > Where will this rate-limiting be implemented? Hardware? Software? Both? The 7600 and 6500 platform (for example) have a hardware based rate-limiter on a per-lc basis, but the traffic that is punted to the cpu is the aggregate across all linecards and must be policed a second time before being processed for the punt/exception cases. Processing this policy in actual implementations has proved to be more expensive than "just replying" in operations. > > I'm concerned that without implementation requirements we will see troubles in the future with this. > > I'm also reminded of Solaris 2.6 and the 500ms rate-limit it provided to TTL expiry handling that confused network and sysadmins to think the host may be experiencing loss. The traceroute processing would show the 1st and 3rd packets fine, but the 2nd would be dropped due to rate-limit. > If the reference from RFC 1812 is too simplistic, do you have a better Internet RFC reference to cite? Again, only RFC 6192 comes to mind. > - Jared Minutes after, on 12/27/2011 7:59 PM, Jared Mauch wrote: >> Thanks again, please see inline. > Sure, > >> On 12/21/2011 7:49 PM, Jared Mauch wrote: >>> The data is available via alternate means. Not sure why encoding it >>> in an exception packet is necessary. >>> >> This is from my home, right now: >> # traceroute puck.nether.net >> >> 9 ae-6.r20.asbnva02.us.bb.gin.ntt.net (129.250.3.109) 25 ms 31 ms 28 ms >> MPLS Label=445248 Exp=0 TTL=1 S=1 > Yes, I'm unaware of a way to exclude this information from replies, but this data > is already there on the FPC in the local FIB. Placing the HMAC and other crypto > in the FIB path seems problematic and would increase the cost of replying. > > There was also the case (around JunOS 5.5 iirc) they implemented a hard-limit of > icmp exception handling that caused numerous issues with clueless network admins > thinking they were observing packet loss. The optics of this issue does matter > to operators, even if the forwarding plane is minimally impacted. This again speaks (to me) to the trade-off: more control on the replies at the expense of more checks, sometimes. It also occurs to me that really there is a (lacking) Applicability Statement as to when to use (and when *not* to use) the (optional) authentication. I would here also refer to the Abstract from this I-D: This document specifies extensions to traceroute and ping techniques to facilitate addition application information to be carried in UDP, TCP and ICMP traceroute probe messages and ICMP echo request and reply messages. This proposal also allows the receiver to authenticate the source of the traceroute and ping senders. The main goal is to provide a framework to include application information in the "probe". This is given the fact that RFC4884, RFC4950, and RFC5837 (the first and last from int-area) include extra information in the elicited ICMP message. Note how there is a "This proposal also allows" modifier when describing the authentication. > >> On 12/22/2011 6:33 AM, Jared Mauch wrote: >>> I think you are overestimating the ability of the routers to respond. >>> >>> Cisco and Juniper have so far failed in many ways that have created pain for operators over the years when it comes to processing packets directed to the device. Developers see these as vulnerabilities and have moved to rate-limit packets directed at the control-plane, either by processing on the FPC, DFC, Linecard CPU, or the centralized processor. >>> >>> The experiences I've had demonstrate that platforms are underpowered for processing these packets and leave the system vulnerable to resource exhaustion attacks, even with CPP. If you want to take the discussion off-line I can provide you a number of examples where platforms have gotten this wrong despite the experiences already learned by other groups inside and outside your respective employers. >>> >>> Choosing to ignore these hard learned lessons leads us down a dim path for the future. >>> >>> Additionally, nothing is stopping someone from developing proper management software that processes the TTL expiry packets and mapping that with the various enterprise mibs for the device. Think of a version of MTR that sends a series of SNMP queries based on these messages and can be configured to understand the scope of ones network, e.g.: >>> >>> snmp_poll { >>> address-space 3ffe:2001::/48 { >>> snmp-community public; >>> } >>> } >>> >> MTR hits the routers with a lot more packets, no? After a traceroute it >> starts to ping, I understand. Just to be clear, do you mean that >> processing a set of snmp polls is less processor intensive? > Certainly not. Anyone spending time with ASN.1 will know it's very expensive. > (I used to own one of the internal SNMP tools at a major carrier). > > But providing the information to an authorized set of people (network operators/NOC > would seem to be more appropriate than possibly exposing private data that may be > considered proprietary to ones network). Both are important, and frankly this I-D actually attempts to solve these both issues... > >>> This combined with existing shipping tools/software would keep excessive traffic from degrading the device. >>> >> The challenge is that, often times, troubleshooters do not have access >> to a full-blown NMS. Or the NMS does not have access to the devices. >> Or... This is embedding a response in the traceroute path. > I think trying to solve the trouble of operators without access to manage their > equipment via traceroute extensions is the wrong way to approach the problem. > > This sounds more like a business issue. If the people doing the troubleshooting > don't have access, then there are many jobs available today for qualified network > people. Natural selection and market forces will work against those carriers > without the skill/access to resolve their troubles. No, the comment here is one of inband versus out-of-band. > >> -- Carlos. > - Jared > > > Sorry for the length of this reply, and hopefully I did address all comments. In summary, ack to the "authentication" comment. Have in mind that this is a proposal to support inband information elements in the probes, and reduce the exposure of not having control on the replies. Thanks, -- Carlos. From cpignata@cisco.com Tue Jan 3 11:33:34 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3FB11E80CD for ; Tue, 3 Jan 2012 11:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.364 X-Spam-Level: X-Spam-Status: No, score=-110.364 tagged_above=-999 required=5 tests=[AWL=0.235, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLWnuAEqKSLI for ; Tue, 3 Jan 2012 11:33:34 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 1D66711E80CB for ; Tue, 3 Jan 2012 11:33:34 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q03JXX6w010880 for ; Tue, 3 Jan 2012 14:33:33 -0500 (EST) Received: from [10.117.115.55] (rtp-cpignata-8916.cisco.com [10.117.115.55]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q03JXSFl027607; Tue, 3 Jan 2012 14:33:28 -0500 (EST) Message-ID: <4F035807.5050206@cisco.com> Date: Tue, 03 Jan 2012 14:33:27 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Jared Mauch References: <20111031213450.304.9289.idtracker@ietfa.amsl.com> <17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com> <201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com> <9A429B54-19F8-493A-A729-A0D25C961764@cisco.com> <351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net> <711DB1AD-52F2-4FCB-8579-0C300A22D409@cisco.com> <4EF619BD.2080207@bogus.com> In-Reply-To: X-Enigmail-Version: 1.3.4 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "int-area@ietf.org" , "akatlas@juniper.net" , Enke Chen Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:33:35 -0000 Joel, Jared, On 12/27/2011 8:03 PM, Jared Mauch wrote: > Joel, > > On Dec 24, 2011, at 1:28 PM, Joel jaeggli wrote: > >> So, something targeted through the forwarding plane that filters up to >> the control plane will be filtered first either by source address or >> passed through a rate limiter or both because those are the protections >> we have that actually scale. Authentication increases the vulnerability >> to some kinds of abuse rather that decreasing it. > > > Thanks. I think I mentioned this in another message, but captures an important > concern about the network elements being managed. Implementation details matter. > Yes, this is an inband packet flowing through the forwarding plane, that upon exception needs processing. What you describe is the existing traceroute mechanism, as well as other protocols, some widely operationally deployed (including MPLS Ping in RFC 4379 with the complexity and computational expense of a dsmap hashing, RAO in RFC 5971 and RSVP, etc). I agree with your point that authentication increases the surface area for abuse in some conditions. I think that one approach here is to describe, in an applicability statement, in which cases an authentication is useful versus in which ones it is potentially harmful. Would you agree? Also, please note that the authentication mechanism is not the most important part of draft-shen-traceroute-ping-ext. Thanks, -- Carlos. > - Jared > > From warren@kumari.net Tue Jan 3 11:34:39 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F24011E80CB for ; Tue, 3 Jan 2012 11:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4CEYmLmQh1z for ; Tue, 3 Jan 2012 11:34:38 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 4615D11E80C7 for ; Tue, 3 Jan 2012 11:34:38 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 77BB31B403ED; Tue, 3 Jan 2012 14:34:36 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Tue, 3 Jan 2012 14:34:35 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4E531FE3-9819-49EF-BE40-CD1C0A63D11A@kumari.net> References: <20111031213450.304.9289.idtracker@ietfa.amsl.com><17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com><201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com><9A429B54-19F8-493A-A729-A0D25C961764@cisco.com><351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net><711DB1AD-52F2-4FCB-8579-0C300A22D409@cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A551AE75@xmb-sjc-214.amer.cisco.com> To: "George, Wes" X-Mailer: Apple Mail (2.1084) Cc: int-area@ietf.org Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:34:39 -0000 On Jan 3, 2012, at 10:29 AM, George, Wes wrote: >> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On >> Behalf Of Tissa Senevirathne (tsenevir) >> Sent: Wednesday, December 21, 2011 9:49 PM >> To: Jared Mauch; Naiming Shen (naiming) >> Cc: Thomas Narten; Carlos Pignataro (cpignata); Enke Chen (enkechen); >> int-area@ietf.org; akatlas@juniper.net >> Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext- >> 03.txt >>=20 >> Yes. But the problem is you have to switch back and forth between >> different applications (SNMP browsers, Network Management = applications >> etc..) to get the information. With integrated ICMP Ping, you should = be >> able to get interested data as part of the ping output. >>=20 >=20 > [WEG] Sure, "should", except for hosts in the middle that don't = support the new options, are configured to ignore them, or are not = configured to see your querying host as trusted enough to receive that = information, etc. etc. This is a solution that rapidly loses value in an = incremental deployment model if that's indeed the problem it's = purporting to solve. The above issue of needing to switch between tools = may be a problem, but it's a presentation/application layer problem with = the *tools*, not the network elements or protocols, and therefore the = solution belongs in the application space. ++. And I note that you didn't say "Application Area" -- I'm assuming that = this was intentional. This proposal still seems to me to be solving a non-problem, and doing = it in a way / place that the operators involved in the discussions have = repeatedly expressed concerns about. I already have a number of well supported methods to get diagnostic and = reporting information from my devices from within my network, and they = work well. I filter SNMP and ssh (and other management type protocols) = at the edge of my network because a: it's none of your business and b: I = don't want to burn cycles throwing away management attempts from you -- = this is currently easy to do because I can easily filter on port and = protocol. This proposal would require me looking much further into the packet to = be able to filter this stuff from the outside (and no, I don't want to = just allow it in and filter on each device -- security is like an = onion[0]) and so all I am left with is filtering out ICMP.. oh, and = UDP... and TCP. For obvious reasons this is, um, suboptimal... > I love direct CLI access as much as the next guy, so I'm trying to = keep an open mind on something that potentially makes it better, but I'm = really not in favor of reinventing the wheel if reduction of = swivel-seating for NOC folks is the primary justification. > As I have noted in my message about SNMP, there is already a lot of = this "solution" happening, where instead of using the same information = for multiple presentation/correlation tools, we end up with multiple = pollers/stores of the same information and a failure to correlate, to = the detriment to the scale of the device and its risk of attack. Yup. Effort would be much better spent on being able to share the = currently collected information amongst multiple tools. >=20 > Thanks, > Wes George >=20 W [0]: It makes you cry. > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 From warren@kumari.net Tue Jan 3 11:38:42 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AF611E80CE for ; Tue, 3 Jan 2012 11:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.521 X-Spam-Level: X-Spam-Status: No, score=-106.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wuH8PiL274F for ; Tue, 3 Jan 2012 11:38:42 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 45D7811E8099 for ; Tue, 3 Jan 2012 11:38:33 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 8605A1B403ED; Tue, 3 Jan 2012 14:38:32 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4F035807.5050206@cisco.com> Date: Tue, 3 Jan 2012 14:38:30 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111031213450.304.9289.idtracker@ietfa.amsl.com> <17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com> <201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com> <9A429B54-19F8-493A-A729-A0D25C961764@cisco.com> <351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net> <711DB1AD-52F2-4FCB-8579-0C300A22D409@cisco.com> <4EF619BD.2080207@bogus.com> <4F035807.5050206@cisco.com> To: Carlos Pignataro X-Mailer: Apple Mail (2.1084) Cc: int-area@ietf.org Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:38:43 -0000 On Jan 3, 2012, at 2:33 PM, Carlos Pignataro wrote: > Joel, Jared, >=20 > On 12/27/2011 8:03 PM, Jared Mauch wrote: >> Joel, >>=20 >> On Dec 24, 2011, at 1:28 PM, Joel jaeggli wrote: >>=20 >>> So, something targeted through the forwarding plane that filters up = to >>> the control plane will be filtered first either by source address or >>> passed through a rate limiter or both because those are the = protections >>> we have that actually scale. Authentication increases the = vulnerability >>> to some kinds of abuse rather that decreasing it. >>=20 >>=20 >> Thanks. I think I mentioned this in another message, but captures an = important >> concern about the network elements being managed. Implementation = details matter. >>=20 >=20 > Yes, this is an inband packet flowing through the forwarding plane, = that > upon exception needs processing. What you describe is the existing > traceroute mechanism, as well as other protocols, some widely > operationally deployed (including MPLS Ping in RFC 4379 with the > complexity and computational expense of a dsmap hashing, RAO in RFC = 5971 > and RSVP, etc). >=20 > I agree with your point that authentication increases the surface area > for abuse in some conditions. I think that one approach here is to > describe, in an applicability statement, in which cases an > authentication is useful versus in which ones it is potentially = harmful. > Would you agree? >=20 > Also, please note that the authentication mechanism is not the most > important part of draft-shen-traceroute-ping-ext. To me the biggest issue is that there is no way to easily filter this = out at the edge of the network (or anywhere else) without looking deeply = into the packet. If this didn't look (and smell) like packets that I = have to let into my network for normal operations I would be fine it = it... W >=20 > Thanks, >=20 > -- Carlos. >=20 >> - Jared >>=20 >>=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 From cpignata@cisco.com Tue Jan 3 11:46:43 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED4B11E80E3 for ; Tue, 3 Jan 2012 11:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.393 X-Spam-Level: X-Spam-Status: No, score=-110.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1onq65j4xmHc for ; Tue, 3 Jan 2012 11:46:43 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 4D20811E80E1 for ; Tue, 3 Jan 2012 11:46:43 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q03JkgQt012231 for ; Tue, 3 Jan 2012 14:46:42 -0500 (EST) Received: from [10.117.115.55] (rtp-cpignata-8916.cisco.com [10.117.115.55]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q03Jkful010708; Tue, 3 Jan 2012 14:46:41 -0500 (EST) Message-ID: <4F035B20.7030105@cisco.com> Date: Tue, 03 Jan 2012 14:46:40 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: "George, Wes" References: <20111031213450.304.9289.idtracker@ietfa.amsl.com><17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com><201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com><9A429B54-19F8-493A-A729-A0D25C961764@cisco.com><351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net><711DB1AD-52F2-4FCB-8579-0C300A22D409@cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A551AE75@xmb-sjc-214.amer.cisco.com> In-Reply-To: X-Enigmail-Version: 1.3.4 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "int-area@ietf.org" , "akatlas@juniper.net" , "Enke Chen \(enkechen\)" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:46:44 -0000 Wes, Thanks for the comment, please see inline. On 1/3/2012 10:29 AM, George, Wes wrote: >> From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On >> Behalf Of Tissa Senevirathne (tsenevir) >> Sent: Wednesday, December 21, 2011 9:49 PM >> To: Jared Mauch; Naiming Shen (naiming) >> Cc: Thomas Narten; Carlos Pignataro (cpignata); Enke Chen (enkechen); >> int-area@ietf.org; akatlas@juniper.net >> Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext- >> 03.txt >> >> Yes. But the problem is you have to switch back and forth between >> different applications (SNMP browsers, Network Management applications >> etc..) to get the information. With integrated ICMP Ping, you should be >> able to get interested data as part of the ping output. >> > > [WEG] Sure, "should", except for hosts in the middle that don't support the new options, are configured to ignore them, or are not configured to see your querying host as trusted enough to receive that information, etc. etc. This is a solution that rapidly loses value in an incremental deployment model if that's indeed the problem it's purporting to solve. The above issue of needing to switch between tools may be a problem, but it's a presentation/application layer problem with the *tools*, not the network elements or protocols, and therefore the solution belongs in the application space. I love direct CLI access as much as the next guy, so I'm trying to keep an open mind on something that potentially makes it better, but I'm really not in favor of reinventing the wheel if reduction of swivel-seating for NOC folks is the primary justification. > As I have noted in my message about SNMP, there is already a lot of this "solution" happening, where instead of using the same information for multiple presentation/correlation tools, we end up with multiple pollers/stores of the same information and a failure to correlate, to the detriment to the scale of the device and its risk of attack. > Not disagreeing with anything you wrote here, and in fact all very good points. Just one comment that from my perspective, the difference here between draft-shen-traceroute-ping-ext versus what you describe is in-band / in-flow versus out-of-band. > Thanks, > Wes George > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > > Thanks, -- Carlos. From rajiva@cisco.com Tue Jan 3 11:56:11 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8136D1F0C3D for ; Tue, 3 Jan 2012 11:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZVYJSD8Fb4n for ; Tue, 3 Jan 2012 11:56:10 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A69B01F0C3B for ; Tue, 3 Jan 2012 11:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3158; q=dns/txt; s=iport; t=1325620570; x=1326830170; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=tHHOxJ4GKilGzZBhWbnOXKjKm9gfMilYEXgZDv8y7j8=; b=PTjLynymffEwhk5je2p39j5Ll8tgVaePM6IenbvDJ4m1CwAjZuF81rgT 7EuSQ+vFe0yrlcslb3aW4adpRLDdiZiFRYB/30xUzRTQzXLkDIPfq1HsW XVItS+ZHYf3HdRRxwB7B/l/U1mtIzHYzwLovWcodjLoMAvFuHH4bYhIis M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYIANlcA0+tJV2Y/2dsb2JhbABDggWqW4EFgXIBAQEDAQEBAQ8BHQo0CwUHBAIBCBEEAQEBCgYXAQYBJh8JCAEBBAESCBqHWAiXSgGdeQSLLGMEiDefHg X-IronPort-AV: E=Sophos;i="4.71,451,1320624000"; d="scan'208";a="48384526" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 03 Jan 2012 19:56:10 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q03JuAog031258; Tue, 3 Jan 2012 19:56:10 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 13:56:10 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Jan 2012 13:56:08 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C06FBD5C2@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Thread-Index: AczKT1mqXWi1PVXKSciXgW5JLj7mRAAALasQ References: <20111031213450.304.9289.idtracker@ietfa.amsl.com><17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com><201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com><9A429B54-19F8-493A-A729-A0D25C961764@cisco.com><351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net><711DB1AD-52F2-4FCB-8579-0C300A22D409@cisco.com><4EF619BD.2080207@bogus.com><4F035807.5050206@cisco.com> From: "Rajiv Asati (rajiva)" To: "Warren Kumari" , "Carlos Pignataro (cpignata)" X-OriginalArrivalTime: 03 Jan 2012 19:56:10.0144 (UTC) FILETIME=[BD25E200:01CCCA51] Cc: int-area@ietf.org Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 19:56:11 -0000 Hi Warren, > If this didn't look (and smell) like packets that I have to let into my network for > normal operations I would be fine it it... That's reasonable.=20 If the default behavior is to not provide any additional info to the probe sender (upon ttl expiry, for example), then it could meet the deployment expectation. =20 One could compare this to not enabling any IGP on the external-facing interfaces to avoid advertise internal prefix info. Cheers, Rajiv > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf > Of Warren Kumari > Sent: Tuesday, January 03, 2012 2:39 PM > To: Carlos Pignataro (cpignata) > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt >=20 >=20 > On Jan 3, 2012, at 2:33 PM, Carlos Pignataro wrote: >=20 > > Joel, Jared, > > > > On 12/27/2011 8:03 PM, Jared Mauch wrote: > >> Joel, > >> > >> On Dec 24, 2011, at 1:28 PM, Joel jaeggli wrote: > >> > >>> So, something targeted through the forwarding plane that filters up to > >>> the control plane will be filtered first either by source address or > >>> passed through a rate limiter or both because those are the protections > >>> we have that actually scale. Authentication increases the vulnerability > >>> to some kinds of abuse rather that decreasing it. > >> > >> > >> Thanks. I think I mentioned this in another message, but captures an > important > >> concern about the network elements being managed. Implementation > details matter. > >> > > > > Yes, this is an inband packet flowing through the forwarding plane, that > > upon exception needs processing. What you describe is the existing > > traceroute mechanism, as well as other protocols, some widely > > operationally deployed (including MPLS Ping in RFC 4379 with the > > complexity and computational expense of a dsmap hashing, RAO in RFC 5971 > > and RSVP, etc). > > > > I agree with your point that authentication increases the surface area > > for abuse in some conditions. I think that one approach here is to > > describe, in an applicability statement, in which cases an > > authentication is useful versus in which ones it is potentially harmful. > > Would you agree? > > > > Also, please note that the authentication mechanism is not the most > > important part of draft-shen-traceroute-ping-ext. >=20 > To me the biggest issue is that there is no way to easily filter this out at the > edge of the network (or anywhere else) without looking deeply into the packet. > If this didn't look (and smell) like packets that I have to let into my network for > normal operations I would be fine it it... >=20 > W >=20 >=20 >=20 > > > > Thanks, > > > > -- Carlos. > > > >> - Jared > >> > >> > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From jared@puck.nether.net Tue Jan 3 12:47:47 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EE911E810F for ; Tue, 3 Jan 2012 12:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5NYxlvaaF0s for ; Tue, 3 Jan 2012 12:47:46 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id CD47911E810C for ; Tue, 3 Jan 2012 12:47:46 -0800 (PST) Received: from [10.31.201.15] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q03Kl3Xe012159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jan 2012 15:47:04 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Jared Mauch In-Reply-To: <4F03550C.2040102@cisco.com> Date: Tue, 3 Jan 2012 15:47:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <559CE3D8-2BA0-469E-AE2C-67F0676C56A8@puck.nether.net> References: <20111031213450.304.9289.idtracker@ietfa.amsl.com> <17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com> <201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com> <9A429B54-19F8-493A-A729-A0D25C961764@cisco.com> <351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net> <4EF497F0.6020101@cisco.com> <3033A87F-4CE9-4F86-B8A9-ACA472776052@puck.nether.net> <4F03550C.2040102@cisco.com> To: Carlos Pignataro X-Mailer: Apple Mail (2.1251.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 03 Jan 2012 15:47:04 -0500 (EST) Cc: Thomas Narten , "int-area@ietf.org" , "akatlas@juniper.net" , Enke Chen Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:47:47 -0000 On Jan 3, 2012, at 2:20 PM, Carlos Pignataro wrote: > Take for example a layered approach to protection, in which a > processing-expensive check (e.g., is performed only after a cheaper = test > passes, much like GTSM). An authentication check is only performed = after > rate-limiting and other cheaper checks, or only performed under = certain > conditions. Not all vendors and platforms do GTSM in hardware, some do it in = software after it has passed the hardware filters. > That said, however, there is an argument that authentication might be > too heavyweight. To this, a suggestion of making it optional or even > separate from the "probe framework" and modulated by Applicability > Considerations seems sensible. >=20 >>=20 >> Authentication and other mechanisms take away valuable microcode = space and >> increase the complexity. =20 >>=20 >> Tier-1 networks have likely evolved significantly since Naiming was = in the >> space. A single network (Level3) today announces about 50% of the = DFZ rib on >> a peering session. When this interface goes down, the time spent >> processing the rib -> fib -> lc events can be significant on a = platform. >>=20 >> A commonly used platform can only populate about 8k entries per = second under >> load, making a 150k prefix change take 18 seconds or more. This is a = significant >> amount of time. Any IPC contention during this time results in = further=20 >> customer observed downtime. >>=20 >> These are operational challenges that are faced today with modern = hardware. >> I'm concerned that the innovation provided by this draft is = unnecessary for >> the network operator and will place undue load upon the network. >=20 > Staying away from platform specifics but diving into the core of this > comment, those are implementation considerations and prioritization to > include in a functional spec and not an I-D. >=20 > I would fundamentally disagree with an advocacy that every check uses > CPU cycles and is therefore bad -- and apologies as I might be > misunderstanding or mis-generalizing your perspective. I think it's a concern, but not a hard blocker issue. I've been on the = wrong side of someones "functional spec" before where the developers = lacked the creative experience of the global internet backbone space. But citing the platform specifics and repeated mistakes is important to = capture here before the devices melted down. I'm not in a trusting mood = and want to protect the vendors from making a customers network melt due = to the repeated mistakes after the lessons have been learned. - jared= From jared@puck.nether.net Tue Jan 3 12:49:32 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1945211E810F for ; Tue, 3 Jan 2012 12:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZvgTjy2boUW for ; Tue, 3 Jan 2012 12:49:31 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 90E6411E810C for ; Tue, 3 Jan 2012 12:49:31 -0800 (PST) Received: from [10.31.201.15] (neustargw.va.neustar.com [209.173.53.233]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q03KmmMd012679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jan 2012 15:48:48 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Tue, 3 Jan 2012 15:49:37 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111031213450.304.9289.idtracker@ietfa.amsl.com> <17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com> <201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com> <9A429B54-19F8-493A-A729-A0D25C961764@cisco.com> <351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net> <711DB1AD-52F2-4FCB-8579-0C300A22D409@cisco.com> <4EF619BD.2080207@bogus.com> <4F035807.5050206@cisco.com> To: Warren Kumari X-Mailer: Apple Mail (2.1251.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 03 Jan 2012 15:48:48 -0500 (EST) Cc: Carlos Pignataro , int-area@ietf.org Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 20:49:32 -0000 On Jan 3, 2012, at 2:38 PM, Warren Kumari wrote: > To me the biggest issue is that there is no way to easily filter this = out at the edge of the network (or anywhere else) without looking deeply = into the packet. If this didn't look (and smell) like packets that I = have to let into my network for normal operations I would be fine it = it... +1 From wesley.george@twcable.com Tue Jan 3 13:13:30 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63781F0C3E for ; Tue, 3 Jan 2012 13:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.063 X-Spam-Level: X-Spam-Status: No, score=-0.063 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh6wMIKOMQK3 for ; Tue, 3 Jan 2012 13:13:30 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB931F0C44 for ; Tue, 3 Jan 2012 13:13:30 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,451,1320642000"; d="scan'208";a="303075954" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 03 Jan 2012 16:12:17 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Tue, 3 Jan 2012 16:13:29 -0500 From: "George, Wes" To: Carlos Pignataro Date: Tue, 3 Jan 2012 16:13:28 -0500 Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Thread-Index: AczKUG1KOKX9rG5tR9W9K9T0bR9qBQAC010w Message-ID: References: <20111031213450.304.9289.idtracker@ietfa.amsl.com><17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com><201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com><9A429B54-19F8-493A-A729-A0D25C961764@cisco.com><351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net><711DB1AD-52F2-4FCB-8579-0C300A22D409@cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A551AE75@xmb-sjc-214.amer.cisco.com> <4F035B20.7030105@cisco.com> In-Reply-To: <4F035B20.7030105@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "int-area@ietf.org" , "akatlas@juniper.net" , "Enke Chen \(enkechen\)" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:13:30 -0000 > From: Carlos Pignataro [mailto:cpignata@cisco.com] > Sent: Tuesday, January 03, 2012 2:47 PM > Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext- > 03.txt > > Just one comment that from my perspective, the difference here between > draft-shen-traceroute-ping-ext versus what you describe is in-band / > in-flow versus out-of-band. [WEG] I've seen reference to this distinction in a couple of your replies, = and I'm not sure I'm understanding it. Fundamentally I understand in-band v= s out of band, but I'm not sure I'm making the connection you're drawing he= re. Can you try to explain why this difference is important in this case? Thanks Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Tue Jan 3 13:39:53 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F375C11E80CB for ; Tue, 3 Jan 2012 13:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.607 X-Spam-Level: X-Spam-Status: No, score=-0.607 tagged_above=-999 required=5 tests=[AWL=0.856, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIw3JXvnoJxm for ; Tue, 3 Jan 2012 13:39:52 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 06BBE11E80B2 for ; Tue, 3 Jan 2012 13:39:48 -0800 (PST) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,451,1320642000"; d="scan'208";a="318964202" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 03 Jan 2012 16:32:11 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 3 Jan 2012 16:38:14 -0500 From: "George, Wes" To: Carlos Pignataro , Jared Mauch Date: Tue, 3 Jan 2012 16:38:13 -0500 Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Thread-Index: AczKTaU9bT0OU6YsQlCtlCiZjxm3GQADqeeQ Message-ID: References: <20111031213450.304.9289.idtracker@ietfa.amsl.com> <17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com> <201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com> <9A429B54-19F8-493A-A729-A0D25C961764@cisco.com> <351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net> <4EF497F0.6020101@cisco.com> <3033A87F-4CE9-4F86-B8A9-ACA472776052@puck.nether.net> <4F03550C.2040102@cisco.com> In-Reply-To: <4F03550C.2040102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "akatlas@juniper.net" , Enke Chen , "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2012 21:39:53 -0000 > From: Carlos Pignataro [mailto:cpignata@cisco.com] > Sent: Tuesday, January 03, 2012 2:21 PM > Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext- > 03.txt > > > That said, however, there is an argument that authentication might be > too heavyweight. To this, a suggestion of making it optional or even > separate from the "probe framework" and modulated by Applicability > Considerations seems sensible. [WEG] I think you're misunderstanding our concern. We're not saying that we= don't want authentication. In fact, in many cases, just the opposite. We'r= e saying that most of the examples that you've provided of "additional info= rmation" to be carried in these responses are considered private info thus = necessitating one or more methods of controlling its availability and distr= ibution. However, the value in providing this information makes it question= able as to whether the scale impact of controlling access (via authenticati= on and other filtering methods) to it is justified. > > This again speaks (to me) to the trade-off: more control on the replies > at the expense of more checks, sometimes. > > It also occurs to me that really there is a (lacking) Applicability > Statement as to when to use (and when *not* to use) the (optional) > authentication. > > I would here also refer to the Abstract from this I-D: > > This document specifies extensions to traceroute and ping techniques > to facilitate addition application information to be carried in UDP, > TCP and ICMP traceroute probe messages and ICMP echo request and > reply messages. This proposal also allows the receiver to > authenticate the source of the traceroute and ping senders. > > > The main goal is to provide a framework to include application > information in the "probe". This is given the fact that RFC4884, > RFC4950, and RFC5837 (the first and last from int-area) include extra > information in the elicited ICMP message. > > Note how there is a "This proposal also allows" modifier when > describing > the authentication. > [WEG] This is the fundamental disconnect. Currently, this is providing a fr= amework to distribute information, and thus far the examples of the type of= information that could be distributed have all been things which are avail= able via other methods. So acknowledging that these exist, I guess the ques= tion still remains - what would this framework be used for in terms of uniq= ue information-passing or solving a problem that exists in the current opti= ons that make this implementation worth the tradeoffs? That's where you're = currently on the wrong side of the benefit/tradeoff curve - implementing so= mething that represents a security risk and a scale risk with no documented= use case to justify this particular solution to a problem. I know you're p= roposing a framework with the idea that it might be flexible enough to addr= ess future uses, but typically such things have at least one valid use case= that drives their implementation now vs when a valid use case presents its= elf. Hope this helps... Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From joelja@bogus.com Wed Jan 4 01:24:47 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC38521F870F for ; Wed, 4 Jan 2012 01:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O07Qqa4IPp0U for ; Wed, 4 Jan 2012 01:24:47 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 4A49921F870A for ; Wed, 4 Jan 2012 01:24:47 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q049OjjZ015160 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Wed, 4 Jan 2012 09:24:45 GMT (envelope-from joelja@bogus.com) Message-ID: <4F041ADD.2060303@bogus.com> Date: Wed, 04 Jan 2012 01:24:45 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Carlos Pignataro References: <20111031213450.304.9289.idtracker@ietfa.amsl.com> <17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com> <201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com> <9A429B54-19F8-493A-A729-A0D25C961764@cisco.com> <351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net> <711DB1AD-52F2-4FCB-8579-0C300A22D409@cisco.com> <4EF619BD.2080207@bogus.com> <4F035807.5050206@cisco.com> In-Reply-To: <4F035807.5050206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Wed, 04 Jan 2012 09:24:46 +0000 (UTC) Cc: Thomas Narten , "int-area@ietf.org" , "akatlas@juniper.net" , Enke Chen Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 09:24:47 -0000 On 1/3/12 11:33 , Carlos Pignataro wrote: > Joel, Jared, > > On 12/27/2011 8:03 PM, Jared Mauch wrote: >> Joel, >> >> On Dec 24, 2011, at 1:28 PM, Joel jaeggli wrote: >> >>> So, something targeted through the forwarding plane that filters up to >>> the control plane will be filtered first either by source address or >>> passed through a rate limiter or both because those are the protections >>> we have that actually scale. Authentication increases the vulnerability >>> to some kinds of abuse rather that decreasing it. >> >> >> Thanks. I think I mentioned this in another message, but captures an important >> concern about the network elements being managed. Implementation details matter. >> > > Yes, this is an inband packet flowing through the forwarding plane, that > upon exception needs processing. What you describe is the existing > traceroute mechanism, as well as other protocols, some widely > operationally deployed (including MPLS Ping in RFC 4379 with the > complexity and computational expense of a dsmap hashing, RAO in RFC 5971 > and RSVP, etc). The existing icmp exception generation mechanism can and is distributed to line card cpus in some router platforms. there's quantitative differences associated with handling those requests in a distributed fashion and punting them up to the control plane because you need more information than is generally available on a linecard in order to process the request. that applies both to the contents and the authentication mechanism. > I agree with your point that authentication increases the surface area > for abuse in some conditions. I think that one approach here is to > describe, in an applicability statement, in which cases an > authentication is useful versus in which ones it is potentially harmful. > Would you agree? I think that would be acceptable. > Also, please note that the authentication mechanism is not the most > important part of draft-shen-traceroute-ping-ext. > > Thanks, > > -- Carlos. > >> - Jared >> >> > From rbonica@juniper.net Wed Jan 4 11:01:49 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182FA21F8595 for ; Wed, 4 Jan 2012 11:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.501 X-Spam-Level: X-Spam-Status: No, score=-106.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNisbecy--3m for ; Wed, 4 Jan 2012 11:01:48 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 062FF21F856B for ; Wed, 4 Jan 2012 11:01:47 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTwSiDq4FbwEKNp/I+qSTQv9FgWVpcenZ@postini.com; Wed, 04 Jan 2012 11:01:48 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 4 Jan 2012 11:01:27 -0800 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 4 Jan 2012 11:01:26 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 4 Jan 2012 14:01:05 -0500 From: Ronald Bonica To: "int-area@ietf.org" Date: Wed, 4 Jan 2012 14:01:04 -0500 Thread-Topic: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Thread-Index: AczLEzVir83daNYxSdmn7o1JJKLB4g== Message-ID: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 19:01:49 -0000 Authors, This draft changes the meaning of bits in the ICMP, TCP and UDP headers. Th= erefore, if published, it would UPDATE RFCs 792, 793 and 768. You may find = that a very high bar to clear! In order to lower the bar, I recommend the following changes to your draft: 1) Don't attempt to enhance PING. Therefore, you won't need to redefine any= bits in the ICMP header. 2) Encode the Trace Extension structure at a fixed position in the TCP/UDP = payload. Therefore, you won't need to redefine any bits in the TCP or UDP h= eaders. There isn't any reason to enhance PING. If you want information from a host= beyond that which PING already provides, the appropriate protocol is SNMP. The document doesn't explain why the starting position of the Trace Extensi= on Structure needs to be variable. Possibilities are: 1) To reduce the probability of processing errors caused by magic numbers t= hat sometimes occur in non-traceroute packets with TTL equal to 0 2) To preserve the low order bits of the TCP/UDP payload If you are trying to address problem #1, you can do so by increasing the si= ze of the magic number. If you are trying to address problem #2, you can do so by encoding the exte= nsion structure at some reasonably large but fixed location in the TCP/UDP = payload. -------------------------- Ron Bonica vcard: www.bonica.org/ron/ronbonica.vcf From naiming@cisco.com Wed Jan 4 11:21:33 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BE911E8097 for ; Wed, 4 Jan 2012 11:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id By+Dy1SWEHNy for ; Wed, 4 Jan 2012 11:21:30 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C1C5711E8098 for ; Wed, 4 Jan 2012 11:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naiming@cisco.com; l=2391; q=dns/txt; s=iport; t=1325704890; x=1326914490; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=k6NtEOztZbEY6XNu72g+smXWuomLYscmM79PZ5m9RE0=; b=AAsUmsgyQfZRV0q1taPj2dB4Q2MKkKH9hxWZhD7NWkT/sYf4OoUnzbtv V37da1006JkXv+hIhZV6DV7hxTkQ57sHqJGOVSuZGEYKerVcIQWT8PNgT mz/es4C5n1qv136PyPL4pHTvcUgVdIdoOY0qFm+iRFBC5KM5TpqSwTGTv M=; X-IronPort-AV: E=Sophos;i="4.71,457,1320624000"; d="scan'208";a="22099389" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 04 Jan 2012 19:21:30 +0000 Received: from [10.155.35.193] ([10.155.35.193]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q04JLUdk027880; Wed, 4 Jan 2012 19:21:30 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Naiming Shen In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> Date: Wed, 4 Jan 2012 11:21:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1084) Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 19:21:33 -0000 Hi Ron, Thanks for the good suggestions, some replies inline, On Jan 4, 2012, at 11:01 AM, Ronald Bonica wrote: > Authors, >=20 > This draft changes the meaning of bits in the ICMP, TCP and UDP = headers. Therefore, if published, it would UPDATE RFCs 792, 793 and 768. = You may find that a very high bar to clear! We defined this only in the context of traceroute and ping applications, = since the source port and ID field only had private meaning to the sender. Those bits change has no meaning = outside this context. >=20 > In order to lower the bar, I recommend the following changes to your = draft: >=20 > 1) Don't attempt to enhance PING. Therefore, you won't need to = redefine any bits in the ICMP header. > 2) Encode the Trace Extension structure at a fixed position in the = TCP/UDP payload. Therefore, you won't need to redefine any bits in the = TCP or UDP headers. >=20 > There isn't any reason to enhance PING. If you want information from a = host beyond that which PING already provides, the appropriate protocol = is SNMP. >=20 > The document doesn't explain why the starting position of the Trace = Extension Structure needs to be variable. Possibilities are: >=20 > 1) To reduce the probability of processing errors caused by magic = numbers that sometimes occur in non-traceroute packets with TTL equal to = 0 > 2) To preserve the low order bits of the TCP/UDP payload >=20 > If you are trying to address problem #1, you can do so by increasing = the size of the magic number. >=20 > If you are trying to address problem #2, you can do so by encoding the = extension structure at some reasonably large but fixed location in the = TCP/UDP payload. The intension is only #2. To have a fixed location is a good solution too, although the intention = of the draft is to allow a '0xf' to indicate we have no extension in this trace/ping = packet, not even bother with looking for it, to save some cpu time. Though I agree that, = to have a fixed location, and to just check the 'magic number' is also not much = overhead. thanks. - Naiming >=20 >=20 > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf >=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From cpignata@cisco.com Wed Jan 4 12:08:59 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC33F21F86BE for ; Wed, 4 Jan 2012 12:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.416 X-Spam-Level: X-Spam-Status: No, score=-110.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPZLlslm3dFC for ; Wed, 4 Jan 2012 12:08:57 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 4145721F86AE for ; Wed, 4 Jan 2012 12:08:57 -0800 (PST) X-TACSUNS: Virus Scanned Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q04K8uvm026359 for ; Wed, 4 Jan 2012 15:08:56 -0500 (EST) Received: from [10.117.115.55] (rtp-cpignata-8916.cisco.com [10.117.115.55]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q04K8s79000515; Wed, 4 Jan 2012 15:08:55 -0500 (EST) Message-ID: <4F04B1D6.8090401@cisco.com> Date: Wed, 04 Jan 2012 15:08:54 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: "George, Wes" References: <20111031213450.304.9289.idtracker@ietfa.amsl.com><17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com><201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com><9A429B54-19F8-493A-A729-A0D25C961764@cisco.com><351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net><711DB1AD-52F2-4FCB-8579-0C300A22D409@cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A551AE75@xmb-sjc-214.amer.cisco.com> <4F035B20.7030105@cisco.com> In-Reply-To: X-Enigmail-Version: 1.3.4 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "int-area@ietf.org" , "akatlas@juniper.net" , "Enke Chen \(enkechen\)" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:08:59 -0000 Hello, Wes, On 1/3/2012 4:13 PM, George, Wes wrote: >> From: Carlos Pignataro [mailto:cpignata@cisco.com] >> Sent: Tuesday, January 03, 2012 2:47 PM >> Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext- >> 03.txt >> >> Just one comment that from my perspective, the difference here between >> draft-shen-traceroute-ping-ext versus what you describe is in-band / >> in-flow versus out-of-band. > > [WEG] I've seen reference to this distinction in a couple of your replies, and I'm not sure I'm understanding it. Fundamentally I understand in-band vs out of band, but I'm not sure I'm making the connection you're drawing here. Can you try to explain why this difference is important in this case? > Sure. What I meant is this: an NMS can query nodes to figure out a path a packet/flow would take, as well as specific information along that path, such as the MPLS label stack, information about the unnumbered incoming interface, etc. It can then correlate all that information and present it to a human (or a machine) in various formats. However, that does not tell the user (or script) that the path is dataplane-alive. As a troubleshooting (or management, sla, etc.) tool, a goal here is to complement RFC 4884 on the probe side, as a packet flows inband through the forwarding path checking the path. Hope that clarifies, sorry for the lack of precision. -- Carlos. > Thanks > Wes George > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > > From cpignata@cisco.com Wed Jan 4 12:29:54 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2558711E80A6 for ; Wed, 4 Jan 2012 12:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.434 X-Spam-Level: X-Spam-Status: No, score=-110.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQJvqZHeUeHT for ; Wed, 4 Jan 2012 12:29:53 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB4011E80A5 for ; Wed, 4 Jan 2012 12:29:53 -0800 (PST) X-TACSUNS: Virus Scanned Received: from mastaba.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q04KTqgh028471 for ; Wed, 4 Jan 2012 15:29:52 -0500 (EST) Received: from [10.117.115.55] (rtp-cpignata-8916.cisco.com [10.117.115.55]) by mastaba.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q04KTiki014501; Wed, 4 Jan 2012 15:29:44 -0500 (EST) Message-ID: <4F04B6B8.6030208@cisco.com> Date: Wed, 04 Jan 2012 15:29:44 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Ronald Bonica References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> X-Enigmail-Version: 1.3.4 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 20:29:54 -0000 Hi Ron, Thanks for the comments, please see inline. On 1/4/2012 2:01 PM, Ronald Bonica wrote: > Authors, > > This draft changes the meaning of bits in the ICMP, TCP and UDP headers. Therefore, if published, it would UPDATE RFCs 792, 793 and 768. You may find that a very high bar to clear! > This draft is not really changing the meaning of bits in the ICMP, TCP, and UDP headers. This draft is just describing a way to allocate udp and tcp source port and icmp identifier. And described within the context of the application of this I-D, traceroute. Do you agree? > In order to lower the bar, I recommend the following changes to your draft: > > 1) Don't attempt to enhance PING. Therefore, you won't need to redefine any bits in the ICMP header. This is what draft-shen-udp-traceroute-ext (a predecessor) was doing to some extent. The extension to ICMP (and TCP) came as a consequence to feedback (IIRC) on including ICMP- and TCP-based traceroutes. Based on the response above, if this is not redefining bits, do you have the same suggestion? > 2) Encode the Trace Extension structure at a fixed position in the TCP/UDP payload. Therefore, you won't need to redefine any bits in the TCP or UDP headers. > This is also good, and I'd be glad to go this route if this is consensus. One reason to include the pointer to a variable start is that during RFC 4884, the structure was at a fixed start and there was strong consensus to have it variable and explicit. > There isn't any reason to enhance PING. If you want information from a host beyond that which PING already provides, the appropriate protocol is SNMP. > > The document doesn't explain why the starting position of the Trace Extension Structure needs to be variable. Possibilities are: > > 1) To reduce the probability of processing errors caused by magic numbers that sometimes occur in non-traceroute packets with TTL equal to 0 > 2) To preserve the low order bits of the TCP/UDP payload > > If you are trying to address problem #1, you can do so by increasing the size of the magic number. > > If you are trying to address problem #2, you can do so by encoding the extension structure at some reasonably large but fixed location in the TCP/UDP payload. > Problem #2. And same as above: I think that a fixed reasonably large location would work as well, though it might imply more checks. Thanks, -- Carlos. > > -------------------------- > Ron Bonica > vcard: www.bonica.org/ron/ronbonica.vcf > > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area > > From wesley.george@twcable.com Wed Jan 4 13:27:27 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D4111E80A6 for ; Wed, 4 Jan 2012 13:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gPvuEUzruVS for ; Wed, 4 Jan 2012 13:27:27 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC3911E808F for ; Wed, 4 Jan 2012 13:27:27 -0800 (PST) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,457,1320642000"; d="scan'208";a="319581244" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 04 Jan 2012 16:16:24 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Wed, 4 Jan 2012 16:22:29 -0500 From: "George, Wes" To: Carlos Pignataro Date: Wed, 4 Jan 2012 16:22:28 -0500 Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Thread-Index: AczLHLOoXuRp1VNYSXOtZ8NArt+b4wACaXeA Message-ID: References: <20111031213450.304.9289.idtracker@ietfa.amsl.com><17B4FA88-22F8-481C-A653-4C75A195F37A@cisco.com><201112201901.pBKJ1WIV007776@cichlid.raleigh.ibm.com><9A429B54-19F8-493A-A729-A0D25C961764@cisco.com><351E00D7-C0E2-4F9C-A58A-3D75172F0023@puck.nether.net><711DB1AD-52F2-4FCB-8579-0C300A22D409@cisco.com> <344037D7CFEFE84E97E9CC1F56C5F4A551AE75@xmb-sjc-214.amer.cisco.com> <4F035B20.7030105@cisco.com> <4F04B1D6.8090401@cisco.com> In-Reply-To: <4F04B1D6.8090401@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "int-area@ietf.org" , "akatlas@juniper.net" , "Enke Chen \(enkechen\)" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:27:27 -0000 > From: Carlos Pignataro [mailto:cpignata@cisco.com] > Sent: Wednesday, January 04, 2012 3:09 PM > Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext- > 03.txt > > However, that > does not tell the user (or script) that the path is dataplane-alive. As > a troubleshooting (or management, sla, etc.) tool, a goal here is to > complement RFC 4884 on the probe side, as a packet flows inband through > the forwarding path checking the path. [WEG] Ah, but that's largely dependent on the way that the management tools= and other bits are implemented. Not all networks use separate out of band = paths for things like SNMP, so in many cases, if it's SNMP-reachable, it's = alive, and SNMP actually can represent something very similar to what Ping = might be able to. You're right that it doesn't necessarily validate the exa= ct path that a ping or trace might, but often those don't follow the exact = same path either since they're punted to either the LC or the RP's slow pat= h for processing vs going through the forwarding machinery like normal pack= ets. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From narten@us.ibm.com Wed Jan 4 14:44:39 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F213311E80E4 for ; Wed, 4 Jan 2012 14:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.855 X-Spam-Level: X-Spam-Status: No, score=-105.855 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CR9rWiakGjW for ; Wed, 4 Jan 2012 14:44:38 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id 47D6011E80E8 for ; Wed, 4 Jan 2012 14:44:38 -0800 (PST) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Jan 2012 15:44:32 -0700 Received: from d03relay05.boulder.ibm.com (9.17.195.107) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 4 Jan 2012 15:43:56 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q04Mhtja116482 for ; Wed, 4 Jan 2012 15:43:55 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q04Mhsxl006749 for ; Wed, 4 Jan 2012 15:43:54 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-48-42-19.mts.ibm.com [9.48.42.19]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q04Mhrhi006655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 15:43:54 -0700 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q04Mhpk8014959; Wed, 4 Jan 2012 17:43:52 -0500 Message-Id: <201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com> To: Carlos Pignataro In-reply-to: <4F04B6B8.6030208@cisco.com> References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> <4F04B6B8.6030208@cisco.com> Comments: In-reply-to Carlos Pignataro message dated "Wed, 04 Jan 2012 15:29:44 -0500." Date: Wed, 04 Jan 2012 17:43:51 -0500 From: Thomas Narten x-cbid: 12010422-4242-0000-0000-000000717F5B Cc: Ronald Bonica , "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:44:39 -0000 Carlos Pignataro writes: > Hi Ron, > Thanks for the comments, please see inline. > On 1/4/2012 2:01 PM, Ronald Bonica wrote: > > Authors, > > This draft changes the meaning of bits in the ICMP, TCP and UDP > > headers. Therefore, if published, it would UPDATE RFCs 792, 793 > > and 768. You may find that a very high bar to clear! > This draft is not really changing the meaning of bits in the ICMP, TCP, > and UDP headers. Actually, it sort of does and sort of doesn't. It's not black and white. True, it doesn't redefine TCP/UDP headers in any way. However, it does call for the placement of "magic values" within an arbitrary TCP/UDP packet. When generating ICMP responses to such packets, when the magic value is present, ICMP behaves differently than before. That is a change. Also, this technique by defintion encourages the creation of "test" or "probe" TCP/UDP packets as part of network debugging (or even regular monitoring). Should those probe packets "escape" and actually be delivered to the destinations as defined by the TCP/IP headers and port numbers, there may be unintended consequences to applications that happen to be using those port numbers already. Oops. Consequently, use of this technique may actually cause collateral damage to existing, deployed applications. Maybe not a big risk, but a risk nonetheless. I would feel much more comfortable with this technique if it could be guaranteed that when probe packets are generated, they do not go "anywhere" in the Internet, but stay within (say) a domain where debugging is necessary. I.e, I could see an ISP doing this within their network, but also preventing such packets from leaving their networks. Not sure how to enforce this though... Now, I brought up this document because over in Trill, OAM is being discussed, and the approach outlined in draft-shen-traceroute-ping-ext-03.txt was cited as something that might be useful to leverage. In a Trill environment, it might well be possible to ensure that no OAM packet leaves a Trill campus. In that case, the above concern largely goes away. In terms of next steps, I'd suggest thinking of two kinds of issues, and dealing with them separately. First, is the concept OK? Second, is the actual format of the packet, the encoding details, etc. right? I personally don't want to bother discussing the latter details unless we decide the basic concept itself is workable and a good way forward. And my own opinion, based on the discussion so far leaves me on the fence. I'm not yet convinced that the idea itself as defined in this document makes sense. We need to listen very carefully to what operators are saying. We want to provide them with tools that will actually help them. If they have concerns (which they do), and we brush them off, we may well end up spending a lot of time developing a solution that they won't ever get used. That's not a good use of anyone's time/effort. Thomas From naiming@cisco.com Wed Jan 4 15:32:08 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA79111E8125 for ; Wed, 4 Jan 2012 15:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2aLGy7szc6E for ; Wed, 4 Jan 2012 15:32:08 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0031D11E810F for ; Wed, 4 Jan 2012 15:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naiming@cisco.com; l=4451; q=dns/txt; s=iport; t=1325719928; x=1326929528; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=USUj0z2jdAGtfOwH/5+GGTQBBoNh3RXjbr0YI6aFIR4=; b=VdHCeisWFAHc5znu2+X5TRT7UQdnmMqSVKlivMC10LAcjZrJ/SVCIBie TYH+LunHxazDeLv6R8ATy9DszuTDxqF6U2I8Jsk/zMLoj6tTQkhTrhvYu fitWWKDwROtCl4Plm6NOyBYpJL6RfoF/GlOvQblbDK3Uh22HQfsMNcBjc w=; X-IronPort-AV: E=Sophos;i="4.71,458,1320624000"; d="scan'208";a="23778748" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 04 Jan 2012 23:32:07 +0000 Received: from [10.155.35.193] ([10.155.35.193]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q04NW7Q4032542; Wed, 4 Jan 2012 23:32:07 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Naiming Shen In-Reply-To: <201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com> Date: Wed, 4 Jan 2012 15:32:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com> References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> <4F04B6B8.6030208@cisco.com> <201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: Carlos Pignataro , "int-area@ietf.org" , Ronald Bonica Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:32:08 -0000 Hi Thomas, On Jan 4, 2012, at 2:43 PM, Thomas Narten wrote: > Carlos Pignataro writes: >=20 >> Hi Ron, >=20 >> Thanks for the comments, please see inline. >=20 >> On 1/4/2012 2:01 PM, Ronald Bonica wrote: >>> Authors, >=20 >>> This draft changes the meaning of bits in the ICMP, TCP and UDP >>> headers. Therefore, if published, it would UPDATE RFCs 792, 793 >>> and 768. You may find that a very high bar to clear! >=20 >> This draft is not really changing the meaning of bits in the ICMP, = TCP, >> and UDP headers. >=20 > Actually, it sort of does and sort of doesn't. It's not black and > white. >=20 > True, it doesn't redefine TCP/UDP headers in any way. >=20 > However, it does call for the placement of "magic values" within an > arbitrary TCP/UDP packet. When generating ICMP responses to such > packets, when the magic value is present, ICMP behaves differently > than before. That is a change. >=20 > Also, this technique by defintion encourages the creation of "test" or > "probe" TCP/UDP packets as part of network debugging (or even regular > monitoring). Should those probe packets "escape" and actually be > delivered to the destinations as defined by the TCP/IP headers and > port numbers, there may be unintended consequences to applications > that happen to be using those port numbers already. Oops. >=20 > Consequently, use of this technique may actually cause collateral > damage to existing, deployed applications. Maybe not a big risk, but a > risk nonetheless.=20 This draft actually does not change those attributes. The current = traceroute/ping application has already picked up those high port numbers, and already = has used the source port and id field for some private number no one else cares. = Let's say if this draft is using a fixed location scheme, then there is no change to any = of that. >=20 > I would feel much more comfortable with this technique if it could be > guaranteed that when probe packets are generated, they do not go > "anywhere" in the Internet, but stay within (say) a domain where > debugging is necessary. I.e, I could see an ISP doing this within > their network, but also preventing such packets from leaving their > networks. >=20 > Not sure how to enforce this though... Let's say if I'm using this extension in an particular ISP only meant to = get some private info for our management stations. First I think the = operator usually specify the destination to be within the range of the network = they want; secondly, even if not, the packet actually goes off the network, = there is not much harm done, those off-net stations should not supply those private information or they probably don't care. yes, it will waste = someone's cpu and bandwidth resource, but it's also due to the operator didn't = check the address carefully. I agree to focus on the concept or framework is the key for now. thanks. - Naiming >=20 > Now, I brought up this document because over in Trill, OAM is being > discussed, and the approach outlined in > draft-shen-traceroute-ping-ext-03.txt was cited as something that > might be useful to leverage. In a Trill environment, it might well be > possible to ensure that no OAM packet leaves a Trill campus. In that > case, the above concern largely goes away. >=20 > In terms of next steps, I'd suggest thinking of two kinds of issues, > and dealing with them separately. >=20 > First, is the concept OK? >=20 > Second, is the actual format of the packet, the encoding details, > etc. right? I personally don't want to bother discussing the latter > details unless we decide the basic concept itself is workable and a > good way forward. >=20 > And my own opinion, based on the discussion so far leaves me on the > fence. I'm not yet convinced that the idea itself as defined in this > document makes sense. We need to listen very carefully to what > operators are saying. We want to provide them with tools that will > actually help them. If they have concerns (which they do), and we > brush them off, we may well end up spending a lot of time developing a > solution that they won't ever get used. That's not a good use of > anyone's time/effort. >=20 > Thomas >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From narten@us.ibm.com Wed Jan 4 16:24:59 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B161F0C46 for ; Wed, 4 Jan 2012 16:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.227 X-Spam-Level: X-Spam-Status: No, score=-106.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ys1DVZQqb1O for ; Wed, 4 Jan 2012 16:24:58 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id F2AB91F0C3B for ; Wed, 4 Jan 2012 16:24:55 -0800 (PST) Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Jan 2012 17:24:55 -0700 Received: from d03relay03.boulder.ibm.com (9.17.195.228) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 4 Jan 2012 17:24:19 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q050OIcc162844 for ; Wed, 4 Jan 2012 17:24:18 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q050OIOg002020 for ; Wed, 4 Jan 2012 17:24:18 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-48-42-19.mts.ibm.com [9.48.42.19]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q050OGgN001584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Jan 2012 17:24:17 -0700 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.5/8.12.5) with ESMTP id q050OFw1016925; Wed, 4 Jan 2012 19:24:15 -0500 Message-Id: <201201050024.q050OFw1016925@cichlid.raleigh.ibm.com> To: Naiming Shen In-reply-to: <7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com> References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> <4F04B6B8.6030208@cisco.com> <201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com> <7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com> Comments: In-reply-to Naiming Shen message dated "Wed, 04 Jan 2012 15:32:07 -0800." Date: Wed, 04 Jan 2012 19:24:14 -0500 From: Thomas Narten x-cbid: 12010500-7282-0000-0000-0000056337FC Cc: Carlos Pignataro , "int-area@ietf.org" , Ronald Bonica Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 00:24:59 -0000 Naiming Shen writes: > > Consequently, use of this technique may actually cause collateral > > damage to existing, deployed applications. Maybe not a big risk, but a > > risk nonetheless. > This draft actually does not change those attributes. The current > traceroute/ping application has already picked up those high port > numbers, and already has used the source port and id field for some > private number no one else cares. Let's say if this draft is using a > fixed location scheme, then there is no change to any of that. This draft doesn't introduce the problem, but it will likely make it worse. I.e., if this draft is successful (which presumably is the goal), more collateral damage may result. I.e, the more such packets are generated, the more likely some will cause problems. > Let's say if I'm using this extension in an particular ISP only meant to get > some private info for our management stations. First I think the operator > usually specify the destination to be within the range of the network they > want; False assumption. The reason why *any* packet (i.e., any src/dest address) would be used is precisely to debug problems related to traffic between a particular src/dest pair, and that src/dest pair may not even belong to the ISP that gets a help desk call. I.e., if you get a help desk call about some sort of packet loss or unreachability for certain flows, you then generate trace packets that mimic those flows. If we could just use regular packets to debug such problems, we wouldn't need the proposed mechanism at all. > secondly, even if not, the packet actually goes off the network, there > is not much harm done, those off-net stations should not supply those > private information or they probably don't care. My concern isn't about the *response* messages leaking outside of the site, it's that the *probe* packets will leak. Those are the ones that could be delivered to a destination incorrectly, causing problems for the receiving application. Thomas From naiming@cisco.com Wed Jan 4 21:36:04 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC6921F8711 for ; Wed, 4 Jan 2012 21:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THNOi2NKp9vG for ; Wed, 4 Jan 2012 21:35:58 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 34F5F21F8681 for ; Wed, 4 Jan 2012 21:35:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naiming@cisco.com; l=3521; q=dns/txt; s=iport; t=1325741758; x=1326951358; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=hYrFaaBKCCrdlQa+Z2V99MT9jqhUltUaDYX8GnsBR64=; b=hq4WWmV2QX1eoOp5fQ49RjIn2scue/35WZ3ybMoxyMmXMuNO3ghml79v xZPjM6EbV0i0E8h6Ljt2Mw0LMWo36CzZ33bIUulvM8Rh6zhZS/5eZN2rN GnzfxV/yiFhyvdsjkY+t5RqQE2NprVRcPtUwCkzZgsJmKAhBKHIwIKk0j s=; X-IronPort-AV: E=Sophos;i="4.71,460,1320624000"; d="scan'208";a="23885157" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 05 Jan 2012 05:35:58 +0000 Received: from sjc-vpn5-956.cisco.com (sjc-vpn5-956.cisco.com [10.21.91.188]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q055ZvE1014714; Thu, 5 Jan 2012 05:35:57 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Naiming Shen In-Reply-To: <201201050024.q050OFw1016925@cichlid.raleigh.ibm.com> Date: Wed, 4 Jan 2012 21:35:57 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> <4F04B6B8.6030208@cisco.com> <201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com> <7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com> <201201050024.q050OFw1016925@cichlid.raleigh.ibm.com> To: Thomas Narten X-Mailer: Apple Mail (2.1084) Cc: Carlos Pignataro , "int-area@ietf.org" , Ronald Bonica Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 05:36:04 -0000 On Jan 4, 2012, at 4:24 PM, Thomas Narten wrote: > Naiming Shen writes: >>> Consequently, use of this technique may actually cause collateral >>> damage to existing, deployed applications. Maybe not a big risk, but = a >>> risk nonetheless.=20 >=20 >> This draft actually does not change those attributes. The current >> traceroute/ping application has already picked up those high port >> numbers, and already has used the source port and id field for some >> private number no one else cares. Let's say if this draft is using a >> fixed location scheme, then there is no change to any of that. >=20 > This draft doesn't introduce the problem, but it will likely make it > worse. I.e., if this draft is successful (which presumably is the > goal), more collateral damage may result. I.e, the more such packets > are generated, the more likely some will cause problems. But the popular traceroute application is using a > 32K port#, so those are not well-known ports, not used by well-known applications. In the = case of someone is using those ports (by destination), then the socket = addresses will not match, the receiver will send an different icmp error code back(instead of port = unreachable), those are the existing implementations, and works fine. this draft does = not change any of those, and unlikely causing problems. >=20 >> Let's say if I'm using this extension in an particular ISP only meant = to get >> some private info for our management stations. First I think the = operator >> usually specify the destination to be within the range of the network = they >> want; >=20 > False assumption. The reason why *any* packet (i.e., any src/dest > address) would be used is precisely to debug problems related to > traffic between a particular src/dest pair, and that src/dest pair may > not even belong to the ISP that gets a help desk call. >=20 But we are just using exact the same traceroute/ping packets, only with = payload change with addition information. it's not going to affect any = source/destination address or layer4 ports (those layer 4 ports are designed to be = incremented each additional ttl packets and they are random anyway) comparing to the = existing way. > I.e., if you get a help desk call about some sort of packet loss or > unreachability for certain flows, you then generate trace packets that > mimic those flows. If we could just use regular packets to debug such > problems, we wouldn't need the proposed mechanism at all. >=20 >> secondly, even if not, the packet actually goes off the network, = there >> is not much harm done, those off-net stations should not supply those >> private information or they probably don't care. >=20 > My concern isn't about the *response* messages leaking outside of the > site, it's that the *probe* packets will leak. Those are the ones that > could be delivered to a destination incorrectly, causing problems for > the receiving application. what I'm saying is, saying the probe is going outside the = network(off-net), it's just a ping packet, or a traceroute packet. yes it has some request = in the payload, but the receiver does not have to reply. it's like when I send = a SNMP query, but typed the host address wrong, the host can either not send me = back anything, or it can reply also if it does not really care who query this = information. but that is not a problem. thanks. - Naiming >=20 > Thomas >=20 From naiming@cisco.com Thu Jan 5 11:11:33 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DE721F8870 for ; Thu, 5 Jan 2012 11:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.279 X-Spam-Level: X-Spam-Status: No, score=-6.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wjt5QuX6FFYK for ; Thu, 5 Jan 2012 11:11:32 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6813B21F886F for ; Thu, 5 Jan 2012 11:11:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naiming@cisco.com; l=4635; q=dns/txt; s=iport; t=1325790692; x=1327000292; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=0C/rbNTm1xH38IpOcdg5A+UJywK/OPo3q9XAbCy9c38=; b=bs79SPequHZVPhxROxIeGW2RRQPJlB1Zt5H6SvW3Pfc+B1lxk57eCufS VbYR8weyvcH4yplQyeMU74TnH0Cmff/KcO6yXktz2ySVlMWVPMfNEBAqp /aJRCFVotkU3481gp+LOBBRulql3HwGOQ0cMqQieeFwdEm/m7ujDDXypn 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAPb0BU+rRDoI/2dsb2JhbABCggWqeIEFgXIBAQEDAQEBAQ8BJzQbCxguJzAZIodYCJgLAZ4WBIsuYwSIOYxNhU+NBw X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; d="scan'208";a="22290660" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 05 Jan 2012 19:11:31 +0000 Received: from [10.155.35.193] ([10.155.35.193]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q05JBVk7010720 for ; Thu, 5 Jan 2012 19:11:31 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Naiming Shen In-Reply-To: Date: Thu, 5 Jan 2012 11:11:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <40DD6862-7716-40FB-A2CB-25FB27D29CCA@cisco.com> References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> <4F04B6B8.6030208@cisco.com> <201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com> <7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com> <201201050024.q050OFw1016925@cichlid.raleigh.ibm.com> To: int-area@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:11:33 -0000 One note with this draft is that, for the past 30 years, Traceroute and = Ping has been widely implemented and used; every implementation has some "private" = data in the payload, which only the sender cares and understands. This draft, in the essence, is to make some of the data in the payload = to be "public", not only the sender understands, but also the receiver may also = understands them. With that the sender have a mechanism to pass some message along to the receivers during the Traceroute and Ping operations. each receiver has = the option of completely ignoring this 'public' data, or only replying to the = interested ones. The extra cpu is only spent on the checking the 'magic number' in a defined = location. Regards, - Naiming On Jan 4, 2012, at 9:35 PM, Naiming Shen wrote: >=20 > On Jan 4, 2012, at 4:24 PM, Thomas Narten wrote: >=20 >> Naiming Shen writes: >>>> Consequently, use of this technique may actually cause collateral >>>> damage to existing, deployed applications. Maybe not a big risk, = but a >>>> risk nonetheless.=20 >>=20 >>> This draft actually does not change those attributes. The current >>> traceroute/ping application has already picked up those high port >>> numbers, and already has used the source port and id field for some >>> private number no one else cares. Let's say if this draft is using a >>> fixed location scheme, then there is no change to any of that. >>=20 >> This draft doesn't introduce the problem, but it will likely make it >> worse. I.e., if this draft is successful (which presumably is the >> goal), more collateral damage may result. I.e, the more such packets >> are generated, the more likely some will cause problems. >=20 > But the popular traceroute application is using a > 32K port#, so = those > are not well-known ports, not used by well-known applications. In the = case > of someone is using those ports (by destination), then the socket = addresses will not match, > the receiver will send an different icmp error code back(instead of = port unreachable), > those are the existing implementations, and works fine. this draft = does not change > any of those, and unlikely causing problems. >=20 >=20 >>=20 >>> Let's say if I'm using this extension in an particular ISP only = meant to get >>> some private info for our management stations. First I think the = operator >>> usually specify the destination to be within the range of the = network they >>> want; >>=20 >> False assumption. The reason why *any* packet (i.e., any src/dest >> address) would be used is precisely to debug problems related to >> traffic between a particular src/dest pair, and that src/dest pair = may >> not even belong to the ISP that gets a help desk call. >>=20 >=20 > But we are just using exact the same traceroute/ping packets, only = with payload > change with addition information. it's not going to affect any = source/destination > address or layer4 ports (those layer 4 ports are designed to be = incremented each > additional ttl packets and they are random anyway) comparing to the = existing way. >=20 >> I.e., if you get a help desk call about some sort of packet loss or >> unreachability for certain flows, you then generate trace packets = that >> mimic those flows. If we could just use regular packets to debug such >> problems, we wouldn't need the proposed mechanism at all. >>=20 >>> secondly, even if not, the packet actually goes off the network, = there >>> is not much harm done, those off-net stations should not supply = those >>> private information or they probably don't care. >>=20 >> My concern isn't about the *response* messages leaking outside of the >> site, it's that the *probe* packets will leak. Those are the ones = that >> could be delivered to a destination incorrectly, causing problems for >> the receiving application. >=20 > what I'm saying is, saying the probe is going outside the = network(off-net), > it's just a ping packet, or a traceroute packet. yes it has some = request in the > payload, but the receiver does not have to reply. it's like when I = send a SNMP > query, but typed the host address wrong, the host can either not send = me back > anything, or it can reply also if it does not really care who query = this information. > but that is not a problem. >=20 > thanks. > - Naiming >=20 >=20 >>=20 >> Thomas >>=20 >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From rajiva@cisco.com Thu Jan 5 11:47:03 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C1621F8872 for ; Thu, 5 Jan 2012 11:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANqzbtFxboUk for ; Thu, 5 Jan 2012 11:47:02 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 56F4D21F8866 for ; Thu, 5 Jan 2012 11:47:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=4887; q=dns/txt; s=iport; t=1325792822; x=1327002422; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+96yGtSPo2Imwqk6vY0WNSbMohqPrpH+edLKdb5ypNA=; b=U+G7LdJXS6ChWNA+SS81/eO2hNsyORJyrXWbdnFYz+ScuTybreK2fXL9 x3BT7daElEzheGb29C4nV8ngd4d7iP4SEPchQPSVN17cm53awDjGloCSs QED5erUeC0bFCZKQdf3l0s+xzbB0GrJlOIQepW6Jn0ZguPjitLwNZCKaR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAE39BU+tJXG8/2dsb2JhbABCggWqeYEFgXIBAQEDAQEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEmHwkIAQEEARIIGodYCJd/AZ4bBIsuYwSIOZ8h X-IronPort-AV: E=Sophos;i="4.71,463,1320624000"; d="scan'208";a="49004746" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 05 Jan 2012 19:47:02 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q05Jl1WM023869; Thu, 5 Jan 2012 19:47:01 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 13:47:01 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Jan 2012 13:47:00 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C070D7261@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Thread-Index: AczLa+2TOjATsSZtRuWZNmHvfdcHkgAdbXsQ References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net><4F04B6B8.6030208@cisco.com><201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com><7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com><201201050024.q050OFw1016925@cichlid.raleigh.ibm.com> From: "Rajiv Asati (rajiva)" To: "Naiming Shen (naiming)" , "Thomas Narten" X-OriginalArrivalTime: 05 Jan 2012 19:47:01.0706 (UTC) FILETIME=[CB1462A0:01CCCBE2] Cc: "Carlos Pignataro \(cpignata\)" , int-area@ietf.org, Ronald Bonica Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 19:47:03 -0000 > > False assumption. The reason why *any* packet (i.e., any src/dest > > address) would be used is precisely to debug problems related to > > traffic between a particular src/dest pair, and that src/dest pair may > > not even belong to the ISP that gets a help desk call. Is it really possible?=20 I am not aware of any implementation that allows the source address of the ping/traceroute packet to be any arbitrary number. In fact, Most implementations limit the source address to be one of those assigned to the device itself. The point here is that if the helpdesk needs additional information from their network devices during troubleshooting, then this proposal could be useful. Cheers, Rajiv > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf > Of Naiming Shen (naiming) > Sent: Thursday, January 05, 2012 12:36 AM > To: Thomas Narten > Cc: Carlos Pignataro (cpignata); int-area@ietf.org; Ronald Bonica > Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt >=20 >=20 > On Jan 4, 2012, at 4:24 PM, Thomas Narten wrote: >=20 > > Naiming Shen writes: > >>> Consequently, use of this technique may actually cause collateral > >>> damage to existing, deployed applications. Maybe not a big risk, but a > >>> risk nonetheless. > > > >> This draft actually does not change those attributes. The current > >> traceroute/ping application has already picked up those high port > >> numbers, and already has used the source port and id field for some > >> private number no one else cares. Let's say if this draft is using a > >> fixed location scheme, then there is no change to any of that. > > > > This draft doesn't introduce the problem, but it will likely make it > > worse. I.e., if this draft is successful (which presumably is the > > goal), more collateral damage may result. I.e, the more such packets > > are generated, the more likely some will cause problems. >=20 > But the popular traceroute application is using a > 32K port#, so those > are not well-known ports, not used by well-known applications. In the case > of someone is using those ports (by destination), then the socket addresses will > not match, > the receiver will send an different icmp error code back(instead of port > unreachable), > those are the existing implementations, and works fine. this draft does not > change > any of those, and unlikely causing problems. >=20 >=20 > > > >> Let's say if I'm using this extension in an particular ISP only meant to get > >> some private info for our management stations. First I think the operator > >> usually specify the destination to be within the range of the network they > >> want; > > > > False assumption. The reason why *any* packet (i.e., any src/dest > > address) would be used is precisely to debug problems related to > > traffic between a particular src/dest pair, and that src/dest pair may > > not even belong to the ISP that gets a help desk call. > > >=20 > But we are just using exact the same traceroute/ping packets, only with > payload > change with addition information. it's not going to affect any > source/destination > address or layer4 ports (those layer 4 ports are designed to be incremented > each > additional ttl packets and they are random anyway) comparing to the existing > way. >=20 > > I.e., if you get a help desk call about some sort of packet loss or > > unreachability for certain flows, you then generate trace packets that > > mimic those flows. If we could just use regular packets to debug such > > problems, we wouldn't need the proposed mechanism at all. > > > >> secondly, even if not, the packet actually goes off the network, there > >> is not much harm done, those off-net stations should not supply those > >> private information or they probably don't care. > > > > My concern isn't about the *response* messages leaking outside of the > > site, it's that the *probe* packets will leak. Those are the ones that > > could be delivered to a destination incorrectly, causing problems for > > the receiving application. >=20 > what I'm saying is, saying the probe is going outside the network(off-net), > it's just a ping packet, or a traceroute packet. yes it has some request in the > payload, but the receiver does not have to reply. it's like when I send a SNMP > query, but typed the host address wrong, the host can either not send me back > anything, or it can reply also if it does not really care who query this > information. > but that is not a problem. >=20 > thanks. > - Naiming >=20 >=20 > > > > Thomas > > >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From rbonica@juniper.net Thu Jan 5 13:19:03 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516C421F8895 for ; Thu, 5 Jan 2012 13:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.518 X-Spam-Level: X-Spam-Status: No, score=-106.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1S-iRsy1M829 for ; Thu, 5 Jan 2012 13:19:02 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4610321F8850 for ; Thu, 5 Jan 2012 13:19:02 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTwYTxVIiwS25PuVXxQHPzgqIkHci7gPl@postini.com; Thu, 05 Jan 2012 13:19:02 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 5 Jan 2012 13:15:00 -0800 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 5 Jan 2012 13:14:59 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 5 Jan 2012 16:14:59 -0500 From: Ronald Bonica To: Carlos Pignataro Date: Thu, 5 Jan 2012 16:14:57 -0500 Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Thread-Index: AczLH5/cov5JIY+FSmunUJ04TrB9NwAypTQA Message-ID: <13205C286662DE4387D9AF3AC30EF456D74EE306E9@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> <4F04B6B8.6030208@cisco.com> In-Reply-To: <4F04B6B8.6030208@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 21:19:03 -0000 Carlos, Regardless whether the ICMP header is being updated, I don't think that it = is necessary to enhance PING. Ping tells you that a host is reachable. SNMP= can tell you anything else that you need to know about the host. Ron > -----Original Message----- > From: Carlos Pignataro [mailto:cpignata@cisco.com] > Sent: Wednesday, January 04, 2012 3:30 PM > To: Ronald Bonica > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext- > 03.txt >=20 > Hi Ron, >=20 > Thanks for the comments, please see inline. >=20 > On 1/4/2012 2:01 PM, Ronald Bonica wrote: > > Authors, > > > > This draft changes the meaning of bits in the ICMP, TCP and UDP > headers. Therefore, if published, it would UPDATE RFCs 792, 793 and > 768. You may find that a very high bar to clear! > > >=20 > This draft is not really changing the meaning of bits in the ICMP, TCP, > and UDP headers. This draft is just describing a way to allocate udp > and > tcp source port and icmp identifier. And described within the context > of > the application of this I-D, traceroute. Do you agree? >=20 > > In order to lower the bar, I recommend the following changes to your > draft: > > > > 1) Don't attempt to enhance PING. Therefore, you won't need to > redefine any bits in the ICMP header. >=20 > This is what draft-shen-udp-traceroute-ext (a predecessor) was doing to > some extent. The extension to ICMP (and TCP) came as a consequence to > feedback (IIRC) on including ICMP- and TCP-based traceroutes. >=20 > Based on the response above, if this is not redefining bits, do you > have > the same suggestion? >=20 > > 2) Encode the Trace Extension structure at a fixed position in the > TCP/UDP payload. Therefore, you won't need to redefine any bits in the > TCP or UDP headers. > > >=20 > This is also good, and I'd be glad to go this route if this is > consensus. One reason to include the pointer to a variable start is > that > during RFC 4884, the structure was at a fixed start and there was > strong > consensus to have it variable and explicit. >=20 > > There isn't any reason to enhance PING. If you want information from > a host beyond that which PING already provides, the appropriate > protocol is SNMP. > > > > The document doesn't explain why the starting position of the Trace > Extension Structure needs to be variable. Possibilities are: > > > > 1) To reduce the probability of processing errors caused by magic > numbers that sometimes occur in non-traceroute packets with TTL equal > to 0 > > 2) To preserve the low order bits of the TCP/UDP payload > > > > If you are trying to address problem #1, you can do so by increasing > the size of the magic number. > > > > If you are trying to address problem #2, you can do so by encoding > the extension structure at some reasonably large but fixed location in > the TCP/UDP payload. > > >=20 > Problem #2. And same as above: I think that a fixed reasonably large > location would work as well, though it might imply more checks. >=20 > Thanks, >=20 > -- Carlos. >=20 > > > > -------------------------- > > Ron Bonica > > vcard: www.bonica.org/ron/ronbonica.vcf > > > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > > > From naiming@cisco.com Thu Jan 5 14:14:38 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F0B21F88D9 for ; Thu, 5 Jan 2012 14:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wp+qq5GUq62H for ; Thu, 5 Jan 2012 14:14:37 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9DD21F88D7 for ; Thu, 5 Jan 2012 14:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naiming@cisco.com; l=3974; q=dns/txt; s=iport; t=1325801676; x=1327011276; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=4eZEV+om7JiAfOE87tUd+S5O2SQaS6r4cojGlm7Px8Q=; b=E0DRUhQFV0YRqCQDXs07d7BpTddINLPYhl3JwZLntI8whekMnbiU8JW0 Abfeirvhu+7as5784GvJttRJGxOXQa3IAZhDycyy5+h9S0owF8NGIxmAw CEi1x6TEVMYWb7ovT1vjz1j0XNASSE0Rx9TmCsPwwINq5JqTsQg+vnBRq E=; X-IronPort-AV: E=Sophos;i="4.71,464,1320624000"; d="scan'208";a="24022054" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 05 Jan 2012 22:14:36 +0000 Received: from [10.155.35.193] ([10.155.35.193]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q05MEaNm008211; Thu, 5 Jan 2012 22:14:36 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Naiming Shen In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74EE306E9@EMBX01-WF.jnpr.net> Date: Thu, 5 Jan 2012 14:14:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> <4F04B6B8.6030208@cisco.com> <13205C286662DE4387D9AF3AC30EF456D74EE306E9@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1084) Cc: Carlos Pignataro , "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 22:14:38 -0000 Hi Ron, the traceroute can use either udp/tcp or icmp for transport, e.g. = microsoft's 'tracer' uses icmp for the transport actually. thanks. - Naiming On Jan 5, 2012, at 1:14 PM, Ronald Bonica wrote: > Carlos, >=20 > Regardless whether the ICMP header is being updated, I don't think = that it is necessary to enhance PING. Ping tells you that a host is = reachable. SNMP can tell you anything else that you need to know about = the host. >=20 > Ron >=20 >=20 >=20 >> -----Original Message----- >> From: Carlos Pignataro [mailto:cpignata@cisco.com] >> Sent: Wednesday, January 04, 2012 3:30 PM >> To: Ronald Bonica >> Cc: int-area@ietf.org >> Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext- >> 03.txt >>=20 >> Hi Ron, >>=20 >> Thanks for the comments, please see inline. >>=20 >> On 1/4/2012 2:01 PM, Ronald Bonica wrote: >>> Authors, >>>=20 >>> This draft changes the meaning of bits in the ICMP, TCP and UDP >> headers. Therefore, if published, it would UPDATE RFCs 792, 793 and >> 768. You may find that a very high bar to clear! >>>=20 >>=20 >> This draft is not really changing the meaning of bits in the ICMP, = TCP, >> and UDP headers. This draft is just describing a way to allocate udp >> and >> tcp source port and icmp identifier. And described within the context >> of >> the application of this I-D, traceroute. Do you agree? >>=20 >>> In order to lower the bar, I recommend the following changes to your >> draft: >>>=20 >>> 1) Don't attempt to enhance PING. Therefore, you won't need to >> redefine any bits in the ICMP header. >>=20 >> This is what draft-shen-udp-traceroute-ext (a predecessor) was doing = to >> some extent. The extension to ICMP (and TCP) came as a consequence to >> feedback (IIRC) on including ICMP- and TCP-based traceroutes. >>=20 >> Based on the response above, if this is not redefining bits, do you >> have >> the same suggestion? >>=20 >>> 2) Encode the Trace Extension structure at a fixed position in the >> TCP/UDP payload. Therefore, you won't need to redefine any bits in = the >> TCP or UDP headers. >>>=20 >>=20 >> This is also good, and I'd be glad to go this route if this is >> consensus. One reason to include the pointer to a variable start is >> that >> during RFC 4884, the structure was at a fixed start and there was >> strong >> consensus to have it variable and explicit. >>=20 >>> There isn't any reason to enhance PING. If you want information from >> a host beyond that which PING already provides, the appropriate >> protocol is SNMP. >>>=20 >>> The document doesn't explain why the starting position of the Trace >> Extension Structure needs to be variable. Possibilities are: >>>=20 >>> 1) To reduce the probability of processing errors caused by magic >> numbers that sometimes occur in non-traceroute packets with TTL equal >> to 0 >>> 2) To preserve the low order bits of the TCP/UDP payload >>>=20 >>> If you are trying to address problem #1, you can do so by increasing >> the size of the magic number. >>>=20 >>> If you are trying to address problem #2, you can do so by encoding >> the extension structure at some reasonably large but fixed location = in >> the TCP/UDP payload. >>>=20 >>=20 >> Problem #2. And same as above: I think that a fixed reasonably large >> location would work as well, though it might imply more checks. >>=20 >> Thanks, >>=20 >> -- Carlos. >>=20 >>>=20 >>> -------------------------- >>> Ron Bonica >>> vcard: www.bonica.org/ron/ronbonica.vcf >>>=20 >>>=20 >>> _______________________________________________ >>> Int-area mailing list >>> Int-area@ietf.org >>> https://www.ietf.org/mailman/listinfo/int-area >>>=20 >>>=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From tsenevir@cisco.com Fri Jan 6 11:26:51 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E214721F8876 for ; Fri, 6 Jan 2012 11:26:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNE+DZbxIF0d for ; Fri, 6 Jan 2012 11:26:50 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id CE2AF21F8867 for ; Fri, 6 Jan 2012 11:26:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tsenevir@cisco.com; l=4852; q=dns/txt; s=iport; t=1325878011; x=1327087611; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=y7LPAVjt2JRfMaK8QnKLpcc3jxpfVxKlIytpGZc+3uQ=; b=KnOgPJOoxlDbQtiRL1wD/ql2Rq3058gtFC1BvWV3ciBJvzrFSqKjfAlP SVi1tNH6WmphTHTrDfmGLm10Df9RWn6gwDEr+Wiyi1g4FzF7OSYIEefqG hYcTWm6r3S+BdOBaXq0ZGe8zfEaoHgE5hSxSBFPmfYTqlHkOBzYq9dxME s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKZKB0+rRDoH/2dsb2JhbAA5CqxBgQWBcgEBAQQBAQEPAR0KDyULDAQCAQgOAwQBAQEKBhcBBgEmHwkIAQEEARIIARmHYJgRAZ4diFaCWGMEiDmfJA X-IronPort-AV: E=Sophos;i="4.71,469,1320624000"; d="scan'208";a="24195231" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 06 Jan 2012 19:26:50 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q06JQoL0007144; Fri, 6 Jan 2012 19:26:50 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Jan 2012 11:26:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Jan 2012 11:26:49 -0800 Message-ID: <344037D7CFEFE84E97E9CC1F56C5F4A55CD1A6@xmb-sjc-214.amer.cisco.com> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D74EE306E9@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Thread-Index: AczLH5/cov5JIY+FSmunUJ04TrB9NwAypTQAAC8bjcA= References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net><4F04B6B8.6030208@cisco.com> <13205C286662DE4387D9AF3AC30EF456D74EE306E9@EMBX01-WF.jnpr.net> From: "Tissa Senevirathne (tsenevir)" To: "Ronald Bonica" , "Carlos Pignataro (cpignata)" X-OriginalArrivalTime: 06 Jan 2012 19:26:50.0373 (UTC) FILETIME=[237B6350:01CCCCA9] Cc: int-area@ietf.org Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2012 19:26:52 -0000 Hi Ron Please see my comments in-line below -----Original Message----- From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf Of Ronald Bonica Sent: Thursday, January 05, 2012 1:15 PM To: Carlos Pignataro (cpignata) Cc: int-area@ietf.org Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Carlos, Regardless whether the ICMP header is being updated, I don't think that it is necessary to enhance PING. Ping tells you that a host is reachable. SNMP can tell you anything else that you need to know about the host. Ron [TISSA] What you indicated above may be true in general sense, however, with various overlay technologies and virtualizations and use of ECMP in networks require us to have ability to obtain additional information that may not be possible or straightforward using SNMP. Case in point is MPLS ping, we use MPLS ping to obtain label stack information. Or derive various ECMP paths combinations. In IP world similar information can be very useful. As an example in an ECMP environments, it is very useful to identify upstream path that a packet arrived.=20 Currently there is no way ICMP ping can communicate this information nor SNMP can tell that. Extension proposed in this draft, in my opinion, allow to extend ICMP echo messages in a manner that is backward compatible yet allow flexible framework to extend to overlay networks and ECMP enviorements.=20 Thanks Tissa > -----Original Message----- > From: Carlos Pignataro [mailto:cpignata@cisco.com] > Sent: Wednesday, January 04, 2012 3:30 PM > To: Ronald Bonica > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext- > 03.txt >=20 > Hi Ron, >=20 > Thanks for the comments, please see inline. >=20 > On 1/4/2012 2:01 PM, Ronald Bonica wrote: > > Authors, > > > > This draft changes the meaning of bits in the ICMP, TCP and UDP > headers. Therefore, if published, it would UPDATE RFCs 792, 793 and > 768. You may find that a very high bar to clear! > > >=20 > This draft is not really changing the meaning of bits in the ICMP, TCP, > and UDP headers. This draft is just describing a way to allocate udp > and > tcp source port and icmp identifier. And described within the context > of > the application of this I-D, traceroute. Do you agree? >=20 > > In order to lower the bar, I recommend the following changes to your > draft: > > > > 1) Don't attempt to enhance PING. Therefore, you won't need to > redefine any bits in the ICMP header. >=20 > This is what draft-shen-udp-traceroute-ext (a predecessor) was doing to > some extent. The extension to ICMP (and TCP) came as a consequence to > feedback (IIRC) on including ICMP- and TCP-based traceroutes. >=20 > Based on the response above, if this is not redefining bits, do you > have > the same suggestion? >=20 > > 2) Encode the Trace Extension structure at a fixed position in the > TCP/UDP payload. Therefore, you won't need to redefine any bits in the > TCP or UDP headers. > > >=20 > This is also good, and I'd be glad to go this route if this is > consensus. One reason to include the pointer to a variable start is > that > during RFC 4884, the structure was at a fixed start and there was > strong > consensus to have it variable and explicit. >=20 > > There isn't any reason to enhance PING. If you want information from > a host beyond that which PING already provides, the appropriate > protocol is SNMP. > > > > The document doesn't explain why the starting position of the Trace > Extension Structure needs to be variable. Possibilities are: > > > > 1) To reduce the probability of processing errors caused by magic > numbers that sometimes occur in non-traceroute packets with TTL equal > to 0 > > 2) To preserve the low order bits of the TCP/UDP payload > > > > If you are trying to address problem #1, you can do so by increasing > the size of the magic number. > > > > If you are trying to address problem #2, you can do so by encoding > the extension structure at some reasonably large but fixed location in > the TCP/UDP payload. > > >=20 > Problem #2. And same as above: I think that a fixed reasonably large > location would work as well, though it might imply more checks. >=20 > Thanks, >=20 > -- Carlos. >=20 > > > > -------------------------- > > Ron Bonica > > vcard: www.bonica.org/ron/ronbonica.vcf > > > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > > > _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area From warren@kumari.net Sat Jan 7 12:44:56 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC4A21F84B3 for ; Sat, 7 Jan 2012 12:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.536 X-Spam-Level: X-Spam-Status: No, score=-106.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JH4ZQgh0su3 for ; Sat, 7 Jan 2012 12:44:55 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 48D9521F84AF for ; Sat, 7 Jan 2012 12:44:54 -0800 (PST) Received: from [192.168.0.12] (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id B979D1B403ED; Sat, 7 Jan 2012 15:44:52 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com> Date: Sat, 7 Jan 2012 15:44:51 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> <4F04B6B8.6030208@cisco.com> <201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com> <7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com> To: Naiming Shen X-Mailer: Apple Mail (2.1084) Cc: Thomas Narten , Carlos Pignataro , "int-area@ietf.org" , Ronald Bonica Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 20:44:56 -0000 On Jan 4, 2012, at 6:32 PM, Naiming Shen wrote: >=20 > Hi Thomas, >=20 > On Jan 4, 2012, at 2:43 PM, Thomas Narten wrote: >=20 >> Carlos Pignataro writes: >>=20 >>> Hi Ron, >>=20 >>> Thanks for the comments, please see inline. >>=20 >>> On 1/4/2012 2:01 PM, Ronald Bonica wrote: >>>> Authors, >>=20 >>>> This draft changes the meaning of bits in the ICMP, TCP and UDP >>>> headers. Therefore, if published, it would UPDATE RFCs 792, 793 >>>> and 768. You may find that a very high bar to clear! >>=20 >>> This draft is not really changing the meaning of bits in the ICMP, = TCP, >>> and UDP headers. >>=20 >> Actually, it sort of does and sort of doesn't. It's not black and >> white. >>=20 >> True, it doesn't redefine TCP/UDP headers in any way. >>=20 >> However, it does call for the placement of "magic values" within an >> arbitrary TCP/UDP packet. When generating ICMP responses to such >> packets, when the magic value is present, ICMP behaves differently >> than before. That is a change. >>=20 >> Also, this technique by defintion encourages the creation of "test" = or >> "probe" TCP/UDP packets as part of network debugging (or even regular >> monitoring). Should those probe packets "escape" and actually be >> delivered to the destinations as defined by the TCP/IP headers and >> port numbers, there may be unintended consequences to applications >> that happen to be using those port numbers already. Oops. >>=20 >> Consequently, use of this technique may actually cause collateral >> damage to existing, deployed applications. Maybe not a big risk, but = a >> risk nonetheless.=20 >=20 > This draft actually does not change those attributes. The current = traceroute/ping > application has already picked up those high port numbers, and already = has used the > source port and id field for some private number no one else cares. = Let's say if this > draft is using a fixed location scheme, then there is no change to any = of that. >=20 >>=20 >> I would feel much more comfortable with this technique if it could be >> guaranteed that when probe packets are generated, they do not go >> "anywhere" in the Internet, but stay within (say) a domain where >> debugging is necessary. I.e, I could see an ISP doing this within >> their network, but also preventing such packets from leaving their >> networks. >>=20 >> Not sure how to enforce this though... >=20 > Let's say if I'm using this extension in an particular ISP only meant = to get > some private info for our management stations. First I think the = operator > usually specify the destination to be within the range of the network = they > want; secondly, even if not, the packet actually goes off the network, = there > is not much harm done, those off-net stations should not supply those > private information or they probably don't care. yes, it will waste = someone's > cpu and bandwidth resource, Speaking as a "someone", I don't want you wasting my cpu and bandwidth = resources. > but it's also due to the operator didn't check > the address carefully. You are looking at this from the wrong side. I run a large network, with many many devices. I allow ping (and = traceroute) into my network because lots of *customers* ping / = traceroute to test their connectivity, especially if they think there is = some sort of issue. I allow these packets because it benefits me and the = customers, and the benefits outweigh the costs. I (and I believe the other operators speaking) are not concerned that = *we* accidentally leak these extended packets (because a: this so isn't = something we want to run, b: we have no reason to destine these outside = our networks, c: can filter these outbound if we want really easily and = d: are relatively small in number), the big concern is that *large = numbers* of *users* start sending these at our devices (or, attackers = start sending them intentionally, and causing more work for my devices). If ping processing goes from being a negligible use of resources to = something noticeable, the only reasonable solution I have is "deny icmp = any any echo" on edge.=20 This is not good for me, this is not good for my customers, this is not = good for the Internet at large. This is why we are concerned about having protocols we have to (or are = expected to) allow in from the Internet and would prefer it to be in a = separate protocol that can be *easily* filtered at the edge of the = network. If the proposal was to carry this in a protocol with a well = known port (like, oh, I dunno, UDP/161) that I can filter I wouldn't = care. It is *not* an accident that: snmpget -c public 209.85.254.233 SNMPv2-MIB::sysDescr.0 does not give you a response. W >=20 > I agree to focus on the concept or framework is the key for now. >=20 > thanks. > - Naiming >=20 >>=20 >> Now, I brought up this document because over in Trill, OAM is being >> discussed, and the approach outlined in >> draft-shen-traceroute-ping-ext-03.txt was cited as something that >> might be useful to leverage. In a Trill environment, it might well be >> possible to ensure that no OAM packet leaves a Trill campus. In that >> case, the above concern largely goes away. >>=20 >> In terms of next steps, I'd suggest thinking of two kinds of issues, >> and dealing with them separately. >>=20 >> First, is the concept OK? >>=20 >> Second, is the actual format of the packet, the encoding details, >> etc. right? I personally don't want to bother discussing the latter >> details unless we decide the basic concept itself is workable and a >> good way forward. >>=20 >> And my own opinion, based on the discussion so far leaves me on the >> fence. I'm not yet convinced that the idea itself as defined in this >> document makes sense. We need to listen very carefully to what >> operators are saying. We want to provide them with tools that will >> actually help them. If they have concerns (which they do), and we >> brush them off, we may well end up spending a lot of time developing = a >> solution that they won't ever get used. That's not a good use of >> anyone's time/effort. >>=20 >> Thomas >>=20 >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 --- Don't be impressed with unintelligible stuff said condescendingly . -- Radia Perlman. Warren Kumari warren@kumari.net From sm@resistor.net Sun Jan 8 03:00:16 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3167121F8492 for ; Sun, 8 Jan 2012 03:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMhozTK-Tw6Y for ; Sun, 8 Jan 2012 03:00:12 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE8021F8491 for ; Sun, 8 Jan 2012 03:00:12 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q08AxwiB027312 for ; Sun, 8 Jan 2012 03:00:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1326020407; i=@resistor.net; bh=RWDabot/d52akus+tcpXXksOlxlQdH+kfekrJGbh0KM=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=nhc5SQVbtAybaEK/dBBAylMNXOxznIlIdJuiEz7BabxUhqaMMJ0tgzcffpLjLbgmu qt295d1fGXsakTi2u/MpnyrUwvO77isUfPhNSuYR+87NDmiJ8z44KfO00RSq8V01nj j0xf97N9A+jzd2YwxXunSF1Ixo9aPX7KZwGUzgk4= Message-Id: <6.2.5.6.2.20120108022206.0c765c58@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 08 Jan 2012 02:49:39 -0800 To: int-area@ietf.org From: SM In-Reply-To: References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> <4F04B6B8.6030208@cisco.com> <201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com> <7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 11:00:16 -0000 At 12:44 07-01-2012, Warren Kumari wrote: >If ping processing goes from being a negligible use of resources to >something noticeable, the only reasonable solution I have is "deny >icmp any any echo" on edge. >This is not good for me, this is not good for my customers, this is >not good for the Internet at large. Agreed. If the authors really want to see draft-shen-traceroute-ping-ext-03 published, they could add an Applicability Statement saying that the domain of use is not the Internet. Not giving due consideration to input from operators can only discourage them from providing input in future. Regards, -sm From naiming@cisco.com Sun Jan 8 12:54:14 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A78D21F852D for ; Sun, 8 Jan 2012 12:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKqbbZWyB+qd for ; Sun, 8 Jan 2012 12:54:13 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 776C221F852C for ; Sun, 8 Jan 2012 12:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=naiming@cisco.com; l=4687; q=dns/txt; s=iport; t=1326056053; x=1327265653; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0gQuo2+GknsqTQC9t7xt/83Rnyk4pc9AQ9DFwVsdkas=; b=HKV24i82R8OGWeQQABvYDIGBiQS9pwJh1UoDTIExxlzuj72wFrYLbMsM H8Ji3/bEeVppIb0mRyEVvUbq27g1EKsRCp7NNPcst+Mvf9ZRQSLGsBSrC HwRalmS2Yt4hWaRzqsrjj8oJhwLBZzQBAhUOA5obnazo/7/XrGofF87oP g=; X-IronPort-AV: E=Sophos;i="4.71,476,1320624000"; d="scan'208";a="24375452" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 08 Jan 2012 20:54:12 +0000 Received: from sjc-vpn3-507.cisco.com (sjc-vpn3-507.cisco.com [10.21.65.251]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q08KsCrg009946; Sun, 8 Jan 2012 20:54:12 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Naiming Shen In-Reply-To: <6.2.5.6.2.20120108022206.0c765c58@resistor.net> Date: Sun, 8 Jan 2012 12:54:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> <4F04B6B8.6030208@cisco.com> <201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com> <7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com> <6.2.5.6.2.20120108022206.0c765c58@resistor.net> To: SM X-Mailer: Apple Mail (2.1084) Cc: int-area@ietf.org Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 20:54:14 -0000 I have seen several comments regarding this extension having scaling = issue on the Internet and this probably is due to confusion on how this extension will be used = or how the traceroute/ping application is processed today. Let's do some analysis = here. Traceroute packets if they are not TTL expired you don't process them on = the router; or Ping packets not destination to your address, you don't process them = on your router. This extension does not change those behavior. You only check those = extension while you are normally processing those packets anyway. So if you don't = normally filter those packets (which is a good thing you are doing), you will have no need to = filter them just because the router support this extension later. I hope this point is = clear. Now let's see what will be the percentage of processing which is = actually related to this Traceroute/ping extension. For normal Traceroute for example, you need = to check UDP header information, you need to verify things such as checksum, you need = to fetch information to format packet to send back through your ICMP socket, information can = be many, such as interface IP address, Nexthop information, interface names (all defined = in RFCs now), copy the original payload (even you don't understand the format) and finally = format the ICMP packet to send it back. Now with this extension, you just check (in a well = known location of the packet) if it exists this extension by the magic#, if not there is nothing more = to do. Or you can have a policy to check only if the probe source address is from network = x.x.x.x/y, otherwise don't even bother with the extension. For those checks, I = would say may be 2-5% of the original processing you have already needed to do. So, does this = actually cause a concern of scaling on the Internet? For every Traceroute/ping router implementation, they do rate-limiting. = Some do flow based, some just do a flat time based rate-limiting, e.g. they only = allow 100 such packets per minute. Let's forget about the Moor's Law, forget about the = hardware/cpu capability these days, let's forget about multi-core cpu development anymore; let's = only concentrate on the legacy stuff of the past. Say take a 15 years old router, let's = upgrade the software to this extension for the Traceroute/ping. Let's assume also this = extension actually consume 10% more cpu. So instead of default punting 100 such a packet per = minute, now this router is programmed only punting 90 such packets to process. Nothing = wrong with that. This 100 per minute was some vendor's arbitrary decision 15 years back, = who can say 50 is not perfect or 200 is not the right thing for now. There is no = place you actually need to do special filtering just due to this extension. The point here is that, if = the implementation does want to take this overhead into account, they can adjust that easily = with also in consideration of today's hardware/cpu capabilities. Then if you think about this extension can actually ask for a subset of = information, instead of just dumping everything the ICMP RFCs have defined, one may save some = cpu and bandwidth in that sense. On the other hand if one has an implementation using this extension, for = example an OpenFlow ID trace which actually trace through the real path on the = programed OpenFlow based switches. this operation let's say cost 100% of the normal = Traceroute processing, but here we hope it does not do this for every Traceroute packet, and it = actually checks to see if this is from an authorized network or station for using this feature. = And this is a new feature you want so you are willing to spend more cpu on that. thanks. - Naiming On Jan 8, 2012, at 2:49 AM, SM wrote: > At 12:44 07-01-2012, Warren Kumari wrote: >> If ping processing goes from being a negligible use of resources to = something noticeable, the only reasonable solution I have is "deny icmp = any any echo" on edge. >> This is not good for me, this is not good for my customers, this is = not good for the Internet at large. >=20 > Agreed. >=20 > If the authors really want to see draft-shen-traceroute-ping-ext-03 = published, they could add an Applicability Statement saying that the = domain of use is not the Internet. Not giving due consideration to = input from operators can only discourage them from providing input in = future. >=20 > Regards, > -sm=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From jared@puck.nether.net Sun Jan 8 13:34:34 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD4DF21F84E6 for ; Sun, 8 Jan 2012 13:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.543, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIXE4waFL9to for ; Sun, 8 Jan 2012 13:34:34 -0800 (PST) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1C61F21F8472 for ; Sun, 8 Jan 2012 13:34:34 -0800 (PST) Received: from [10.0.0.163] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q08LXjoh031187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 8 Jan 2012 16:33:46 -0500 References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> <4F04B6B8.6030208@cisco.com> <201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com> <7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com> <6.2.5.6.2.20120108022206.0c765c58@resistor.net> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <6B28E728-96FF-4948-AE3A-A90BF6D88899@puck.nether.net> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9A405) From: Jared Mauch Date: Sun, 8 Jan 2012 16:34:30 -0500 To: Naiming Shen X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Sun, 08 Jan 2012 16:33:47 -0500 (EST) Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2012 21:34:34 -0000 If your goal is to replace snmp since it doesn't do what you want, it seems l= ike that is another I-d Jared Mauch On Jan 8, 2012, at 3:54 PM, Naiming Shen wrote: >=20 > I have seen several comments regarding this extension having scaling issue= on the Internet > and this probably is due to confusion on how this extension will be used o= r how the > traceroute/ping application is processed today. Let's do some analysis her= e. >=20 > Traceroute packets if they are not TTL expired you don't process them on t= he router; > or Ping packets not destination to your address, you don't process them on= your router. > This extension does not change those behavior. You only check those extens= ion while > you are normally processing those packets anyway. So if you don't normally= filter those > packets (which is a good thing you are doing), you will have no need to fi= lter them just > because the router support this extension later. I hope this point is clea= r. >=20 > Now let's see what will be the percentage of processing which is actually r= elated to this > Traceroute/ping extension. For normal Traceroute for example, you need to c= heck UDP > header information, you need to verify things such as checksum, you need t= o fetch information > to format packet to send back through your ICMP socket, information can be= many, such as > interface IP address, Nexthop information, interface names (all defined in= RFCs now), copy the > original payload (even you don't understand the format) and finally format= the ICMP packet > to send it back. Now with this extension, you just check (in a well known l= ocation of the packet) > if it exists this extension by the magic#, if not there is nothing more to= do. Or you can > have a policy to check only if the probe source address is from network x.= x.x.x/y, > otherwise don't even bother with the extension. For those checks, I would s= ay may be 2-5% > of the original processing you have already needed to do. So, does this ac= tually cause a > concern of scaling on the Internet? >=20 > For every Traceroute/ping router implementation, they do rate-limiting. So= me do flow > based, some just do a flat time based rate-limiting, e.g. they only allow 1= 00 such packets > per minute. Let's forget about the Moor's Law, forget about the hardware/c= pu capability > these days, let's forget about multi-core cpu development anymore; let's o= nly concentrate > on the legacy stuff of the past. Say take a 15 years old router, let's upg= rade the software > to this extension for the Traceroute/ping. Let's assume also this extensio= n actually consume > 10% more cpu. So instead of default punting 100 such a packet per minute, n= ow this > router is programmed only punting 90 such packets to process. Nothing wron= g with that. > This 100 per minute was some vendor's arbitrary decision 15 years back, wh= o can say > 50 is not perfect or 200 is not the right thing for now. There is no place= you actually need to do > special filtering just due to this extension. The point here is that, if t= he implementation does > want to take this overhead into account, they can adjust that easily with a= lso in consideration > of today's hardware/cpu capabilities. >=20 > Then if you think about this extension can actually ask for a subset of in= formation, instead > of just dumping everything the ICMP RFCs have defined, one may save some c= pu and bandwidth > in that sense. >=20 > On the other hand if one has an implementation using this extension, for e= xample an > OpenFlow ID trace which actually trace through the real path on the progra= med OpenFlow > based switches. this operation let's say cost 100% of the normal Tracerout= e processing, > but here we hope it does not do this for every Traceroute packet, and it a= ctually checks to see > if this is from an authorized network or station for using this feature. A= nd this is a new feature > you want so you are willing to spend more cpu on that. >=20 > thanks. > - Naiming >=20 >=20 > On Jan 8, 2012, at 2:49 AM, SM wrote: >=20 >> At 12:44 07-01-2012, Warren Kumari wrote: >>> If ping processing goes from being a negligible use of resources to some= thing noticeable, the only reasonable solution I have is "deny icmp any any e= cho" on edge. >>> This is not good for me, this is not good for my customers, this is not g= ood for the Internet at large. >>=20 >> Agreed. >>=20 >> If the authors really want to see draft-shen-traceroute-ping-ext-03 publi= shed, they could add an Applicability Statement saying that the domain of us= e is not the Internet. Not giving due consideration to input from operators= can only discourage them from providing input in future. >>=20 >> Regards, >> -sm=20 >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From rajiva@cisco.com Wed Jan 11 10:01:59 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B9E21F85FC for ; Wed, 11 Jan 2012 10:01:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaM8nMTpH5R2 for ; Wed, 11 Jan 2012 10:01:58 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6CF21F85F9 for ; Wed, 11 Jan 2012 10:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5701; q=dns/txt; s=iport; t=1326304918; x=1327514518; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=jgpyNvlBmzSdoe6lIRM4Q8/J6gAsc43D1nl7ChjOs4g=; b=FbUPAr+wKO0Gk+5VOxr8c23CwFygrR/1+wFw3w1VgLXiK42RR1OehVkD ef6xQCZ4yz22XcxR/o7Z3bzkAHz1dkqJDGy245n8fUE/EJuiuTch1iteR p/ov1r9VLfc78MX6RzVD7130nNTgq1WjPBcki1jKMkdjIXtlKe07hA0Rq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAzODU+tJXHA/2dsb2JhbABCrQOBBYFyAQEBBAEBAQ8BHQo0CwwEAgEIEQQBAQEKBgUEAgwBBgEmHwkIAQEEARIIEweHYJkGAZ4/BIh1HQKCJmMEiDqfLQ X-IronPort-AV: E=Sophos;i="4.71,493,1320624000"; d="scan'208";a="47754505" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 11 Jan 2012 18:01:58 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q0BI1vrO010930; Wed, 11 Jan 2012 18:01:57 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 12:01:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2012 12:01:55 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C07172A0F@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Thread-Index: AczOR7DxH4ySBfvwSfOqp0pvfkjOrgCPFxlw References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net><4F04B6B8.6030208@cisco.com><201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com><7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com><6.2.5.6.2.20120108022206.0c765c58@resistor.net> From: "Rajiv Asati (rajiva)" To: "Naiming Shen (naiming)" , "SM" X-OriginalArrivalTime: 11 Jan 2012 18:01:57.0529 (UTC) FILETIME=[1BF9D090:01CCD08B] Cc: int-area@ietf.org Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 18:01:59 -0000 Hi Naiming, Very good clarification. Additionally, an implementation could simply require this functionality to be not enabled via default (or disabled via CLI), erasing any concern one may have in the existing deployments. In other words, if I want this functionality in my network, then I will go enable it (at whatever cost I need to bear). Cheers, Rajiv=20 > -----Original Message----- > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On Behalf > Of Naiming Shen (naiming) > Sent: Sunday, January 08, 2012 3:54 PM > To: SM > Cc: int-area@ietf.org > Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt >=20 >=20 > I have seen several comments regarding this extension having scaling issue on > the Internet > and this probably is due to confusion on how this extension will be used or how > the > traceroute/ping application is processed today. Let's do some analysis here. >=20 > Traceroute packets if they are not TTL expired you don't process them on the > router; > or Ping packets not destination to your address, you don't process them on your > router. > This extension does not change those behavior. You only check those extension > while > you are normally processing those packets anyway. So if you don't normally > filter those > packets (which is a good thing you are doing), you will have no need to filter > them just > because the router support this extension later. I hope this point is clear. >=20 > Now let's see what will be the percentage of processing which is actually > related to this > Traceroute/ping extension. For normal Traceroute for example, you need to > check UDP > header information, you need to verify things such as checksum, you need to > fetch information > to format packet to send back through your ICMP socket, information can be > many, such as > interface IP address, Nexthop information, interface names (all defined in RFCs > now), copy the > original payload (even you don't understand the format) and finally format the > ICMP packet > to send it back. Now with this extension, you just check (in a well known > location of the packet) > if it exists this extension by the magic#, if not there is nothing more to do. Or > you can > have a policy to check only if the probe source address is from network > x.x.x.x/y, > otherwise don't even bother with the extension. For those checks, I would say > may be 2-5% > of the original processing you have already needed to do. So, does this actually > cause a > concern of scaling on the Internet? >=20 > For every Traceroute/ping router implementation, they do rate-limiting. Some > do flow > based, some just do a flat time based rate-limiting, e.g. they only allow 100 > such packets > per minute. Let's forget about the Moor's Law, forget about the hardware/cpu > capability > these days, let's forget about multi-core cpu development anymore; let's only > concentrate > on the legacy stuff of the past. Say take a 15 years old router, let's upgrade the > software > to this extension for the Traceroute/ping. Let's assume also this extension > actually consume > 10% more cpu. So instead of default punting 100 such a packet per minute, now > this > router is programmed only punting 90 such packets to process. Nothing wrong > with that. > This 100 per minute was some vendor's arbitrary decision 15 years back, who > can say > 50 is not perfect or 200 is not the right thing for now. There is no place you > actually need to do > special filtering just due to this extension. The point here is that, if the > implementation does > want to take this overhead into account, they can adjust that easily with also in > consideration > of today's hardware/cpu capabilities. >=20 > Then if you think about this extension can actually ask for a subset of > information, instead > of just dumping everything the ICMP RFCs have defined, one may save some > cpu and bandwidth > in that sense. >=20 > On the other hand if one has an implementation using this extension, for > example an > OpenFlow ID trace which actually trace through the real path on the > programed OpenFlow > based switches. this operation let's say cost 100% of the normal Traceroute > processing, > but here we hope it does not do this for every Traceroute packet, and it actually > checks to see > if this is from an authorized network or station for using this feature. And this is > a new feature > you want so you are willing to spend more cpu on that. >=20 > thanks. > - Naiming >=20 >=20 > On Jan 8, 2012, at 2:49 AM, SM wrote: >=20 > > At 12:44 07-01-2012, Warren Kumari wrote: > >> If ping processing goes from being a negligible use of resources to > something noticeable, the only reasonable solution I have is "deny icmp any any > echo" on edge. > >> This is not good for me, this is not good for my customers, this is not good > for the Internet at large. > > > > Agreed. > > > > If the authors really want to see draft-shen-traceroute-ping-ext-03 published, > they could add an Applicability Statement saying that the domain of use is not > the Internet. Not giving due consideration to input from operators can only > discourage them from providing input in future. > > > > Regards, > > -sm > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area From ran4chap@yahoo.com Wed Jan 11 12:44:40 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28BF321F86D6 for ; Wed, 11 Jan 2012 12:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.91 X-Spam-Level: * X-Spam-Status: No, score=1.91 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKpmX7ujMiRm for ; Wed, 11 Jan 2012 12:44:39 -0800 (PST) Received: from nm20-vm0.bullet.mail.ac4.yahoo.com (nm20-vm0.bullet.mail.ac4.yahoo.com [98.139.53.214]) by ietfa.amsl.com (Postfix) with SMTP id 5640B21F8585 for ; Wed, 11 Jan 2012 12:44:39 -0800 (PST) Received: from [98.139.52.188] by nm20.bullet.mail.ac4.yahoo.com with NNFMP; 11 Jan 2012 20:44:33 -0000 Received: from [98.139.52.167] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 11 Jan 2012 20:44:33 -0000 Received: from [127.0.0.1] by omp1050.mail.ac4.yahoo.com with NNFMP; 11 Jan 2012 20:44:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 61543.29402.bm@omp1050.mail.ac4.yahoo.com Received: (qmail 35005 invoked by uid 60001); 11 Jan 2012 20:44:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1326314672; bh=wT5vviTtrxyrrfeIOVpTEjNMutJ4jVnT3utT1MBYrkY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=mDTc5CZrftlkh3hs6YHNsXMmtmqL7RvpPBaJfrx22n+8OTsqV5UXqGNNL9Cmha19aMLr5paZPbkDZCen59i1k5gnmtbE2eWC/mWNumyYPsTTTwYiY+Tf6vjhvx6I+74Ez6aMY3aHPHdPxaSZp37Sq+5hBR9F6ToNMVSfGYMOSIQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ch8KzKnMFCcuj21ymTJyg6aXf46osUZMXjhseuvw2lCiyuzTGDE67Uj8p9GeZCRHVo6QVVrWSVeUOHFhaivheRj9T2o7gSNU1vVB7PAfGrJGytHYwqfgZr6qyt8LeH5Er4wCsV0sz6QC2xS8KEyo4Ed3Cqu1gQpM0gPcCI4rZH0=; X-YMail-OSG: wGc2PQYVM1lA7Pw5NvACwuoMWZKPMKuu6toFFx5aeoBTNge Wvtw3j2OT7xlkpV4lTroLZFG8dxTzZn68OiFsEUXXO9gFVPLbeU3iT8ur93_ tnx_RRHesmEjO_wm.XUU8ctDd2Qdk8iZ4P5uKg_Na8WDIkfqJmI8fxstSBIE ub5Pzl0PC5HbE6DYHPfZ.ZUyBGX5wJ38iftZicxDCQFBxTyPXIu3OSwX3Ix8 6Al1T9HCbxjDcOWget27o2UoUq4b648I83z9y8_gaIVG1c8KwxJfcNRNccsb IrIyENy_oUuZPJFeW.o_imcOWj9513luJSqfx5Xx0uHnoU6SI_caD_6LRE8F 0NDLJ42Vr8CBUlqtHVx9gpjGWkvqU2j3XFYNHOy2s6I773Bhhk7HEByjkCo7 .YRI1O730cDISRXYaZPAETNtPvJARQJAjZGRBZNhekaq1cVgFXhR0Ym5N2dt DdUwj7ZfGzeQVSBNySltYE7m2tRi40EjR3X6EvxEnbH__EEA4ftMqA9j.QJL MCzEw_MEftZ9C_5tRQJ6psGPHyOU8MmhLa8zcM0nqY3mGKJjZJoI- Received: from [2.211.190.233] by web30702.mail.mud.yahoo.com via HTTP; Wed, 11 Jan 2012 12:44:32 PST X-Mailer: YahooMailWebService/0.8.115.331698 References: Message-ID: <1326314672.34107.YahooMailNeo@web30702.mail.mud.yahoo.com> Date: Wed, 11 Jan 2012 12:44:32 -0800 (PST) From: Ranganai Chaparadza To: "int-area@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="575268677-1407100938-1326314672=:34107" Subject: [Int-area] Request for Comments and Discussion on the Draft on a Generic Control Protocol Framework X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ranganai Chaparadza List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 20:44:40 -0000 --575268677-1407100938-1326314672=:34107 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dear all,=0A=0AI am writing to kindly request for a review of the following= ID, and discussions on the proposed Framework that allows to design custom= ized Control Protocols for different purposes. Please your comments will he= lp us.=0A=0AThe Draft can be found on the link below.=0A=0Ahttps://tools.ie= tf.org/html/draft-chaparadza-intarea-igcp-00=0A=0AI thank you for you comme= nts, feedback and discussions on IGCP (IP based Generic Control Protocol).= =0A=0A=0ABest Regards,=0A=0ARanganai=A0 --575268677-1407100938-1326314672=:34107 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

I am writing to kindly request for a review = of the following ID, and discussions on the proposed Framework that allows = to design customized Control Protocols for different purposes. Please your = comments will help us.

The Draft can be found on the link below.

htt= ps://tools.ietf.org/html/draft-chaparadza-intarea-igcp-00

I thank you for= you comments, feedback and discussions on IGCP (IP based Generic Control Proto= col).

Best Regards,

Ranganai=  

--575268677-1407100938-1326314672=:34107-- From warren@kumari.net Wed Jan 11 13:01:50 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C0C11E8073 for ; Wed, 11 Jan 2012 13:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.219 X-Spam-Level: X-Spam-Status: No, score=-106.219 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlsBXRraykbf for ; Wed, 11 Jan 2012 13:01:49 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5C421F87B3 for ; Wed, 11 Jan 2012 13:01:48 -0800 (PST) Received: from dhcp-172-19-119-228.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 895C61B40BCB; Wed, 11 Jan 2012 16:01:47 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Wed, 11 Jan 2012 16:01:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4A1E6E8A-700B-4FF9-946D-AC2B84D5EFF0@kumari.net> References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> <4F04B6B8.6030208@cisco.com> <201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com> <7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com> <6.2.5.6.2.20120108022206.0c765c58@resistor.net> To: Naiming Shen X-Mailer: Apple Mail (2.1084) Cc: int-area@ietf.org Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2012 21:01:50 -0000 On Jan 8, 2012, at 3:54 PM, Naiming Shen wrote: >=20 > I have seen several comments regarding this extension having scaling = issue on the Internet > and this probably is due to confusion on how this extension will be = used or how the > traceroute/ping application is processed today. Or potentially the comments are coming from operators who understand how = traceroute/ping work, how their devices currently operate, what sort of = traffic they allow in (and why). > Let's do some analysis here. >=20 > Traceroute packets if they are not TTL expired you don't process them = on the router; > or Ping packets not destination to your address, you don't process = them on your router. > This extension does not change those behavior. You only check those = extension while > you are normally processing those packets anyway. Wow, cool, I never knew that... You mean that there is some sort of = separation between data traffic that transits the device and control / = exception traffic? Neat! > So if you don't normally filter those > packets (which is a good thing you are doing), you will have no need = to filter them just > because the router support this extension later. I hope this point is = clear. No. The point is clear, but I don't agree with it. >=20 > Now let's see what will be the percentage of processing which is = actually related to this > Traceroute/ping extension. For normal Traceroute for example, you need = to check UDP > header information, you need to verify things such as checksum, you = need to fetch information > to format packet to send back through your ICMP socket, information = can be many, such as > interface IP address, Nexthop information, interface names (all = defined in RFCs now), copy the > original payload (even you don't understand the format) and finally = format the ICMP packet > to send it back. Now with this extension, you just check (in a well = known location of the packet) > if it exists this extension by the magic#, if not there is nothing = more to do. Or you can > have a policy to check only if the probe source address is from = network x.x.x.x/y, > otherwise don't even bother with the extension. For those checks, I = would say may be 2-5% > of the original processing you have already needed to do. So, does = this actually cause a > concern of scaling on the Internet? Sure, you chose traceroute over ICMP because that helps support your = position, fine. How did you come up with this 2-5% number? Is this only under the you = have a policy to check the source address case, or are you trying to = claim that authentication will only be an additional 2-5%? >=20 > For every Traceroute/ping router implementation, they do = rate-limiting. Some do flow > based, some just do a flat time based rate-limiting, e.g. they only = allow 100 such packets > per minute. Let's forget about the Moor's Law, forget about the = hardware/cpu capability > these days, let's forget about multi-core cpu development anymore; = let's only concentrate > on the legacy stuff of the past. Say take a 15 years old router, let's = upgrade the software > to this extension for the Traceroute/ping. Let's assume also this = extension actually consume > 10% more cpu. > So instead of default punting 100 such a packet per minute, now this > router is programmed only punting 90 such packets to process. Or 0.1% CPU, or 100000% more CPU. Where (and more why!) are you coming = up with these numbers? What router from 15 years ago supported (non-CPU) = rate-limiting of TTL expired at around 100ppm, and might still be in = use? > Nothing wrong with that. > This 100 per minute was some vendor's arbitrary decision 15 years = back, who can say > 50 is not perfect or 200 is not the right thing for now. Ah, arbitrary vendor decisions. Is there *any* chance that instead of = picking a number out of the air they based it upon what customers were = looking for / what the device was capable of? > There is no place you actually need to do > special filtering just due to this extension. Yes, yes there is... 1: I only run management protocols that support some level of = authentication (e.g SSH, SNMP) 2: My internal devices only accept management traffic from specified = (internal) addresses. 3: I *also* filter out SSH, SNMP, Telnet and similar at the edge of my = network. If I have 1 and 2, why do I bother with 3 as well? A: During new turnups / testing / maintenance, etc it is possible that = the filters in 2 might get dropped. B: Where the rate-limiters and filters get invoked differs between = implementations. If I don't filter at the edge my (legitimate) = management traffic (5-10pps) may be competing with O(tens of thousands) = of attack packets. C: Not all of the devices in the network are managed by a single group. = In many (most?) organizations the security policy is set by a security = group and they would like to ensure that ALL devices get some level of = protection. If someone in a different group installs a device on the = network, it should get some level of protection, even if they = misconfigure it. See layered security, etc. > The point here is that, if the implementation does > want to take this overhead into account, they can adjust that easily = with also in consideration > of today's hardware/cpu capabilities. >=20 Yes. I *have* todays hardware/cpu capabilities, and they are *already* = busy. I don't want *want* them spending any additional time on a = protocol that doesn't solve an actual issue. > Then if you think about this extension can actually ask for a subset = of information, instead > of just dumping everything the ICMP RFCs have defined, one may save = some cpu and bandwidth > in that sense. So I can save CPU? Over my current usage? >=20 > On the other hand if one has an implementation using this extension, = for example an > OpenFlow ID trace which actually trace through the real path on the = programed OpenFlow > based switches. this operation let's say cost 100% of the normal = Traceroute processing, > but here we hope it does not do this for every Traceroute packet, and = it actually checks to see > if this is from an authorized network or station for using this = feature. And this is a new feature > you want so you are willing to spend more cpu on that. Ah, thank you for telling me what I want, and what I'm willing to spend = CPU on.=20 W >=20 > thanks. > - Naiming >=20 >=20 > On Jan 8, 2012, at 2:49 AM, SM wrote: >=20 >> At 12:44 07-01-2012, Warren Kumari wrote: >>> If ping processing goes from being a negligible use of resources to = something noticeable, the only reasonable solution I have is "deny icmp = any any echo" on edge. >>> This is not good for me, this is not good for my customers, this is = not good for the Internet at large. >>=20 >> Agreed. >>=20 >> If the authors really want to see draft-shen-traceroute-ping-ext-03 = published, they could add an Applicability Statement saying that the = domain of use is not the Internet. Not giving due consideration to = input from operators can only discourage them from providing input in = future. >>=20 >> Regards, >> -sm=20 >> _______________________________________________ >> Int-area mailing list >> Int-area@ietf.org >> https://www.ietf.org/mailman/listinfo/int-area >=20 > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > https://www.ietf.org/mailman/listinfo/int-area >=20 From wesley.george@twcable.com Thu Jan 12 06:56:16 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CE421F8587 for ; Thu, 12 Jan 2012 06:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.827 X-Spam-Level: X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[AWL=0.636, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuOotHTIajYI for ; Thu, 12 Jan 2012 06:56:15 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 50A9A21F8588 for ; Thu, 12 Jan 2012 06:56:15 -0800 (PST) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.71,498,1320642000"; d="scan'208";a="323179666" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 12 Jan 2012 09:49:54 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Thu, 12 Jan 2012 09:56:14 -0500 From: "George, Wes" To: Naiming Shen Date: Thu, 12 Jan 2012 09:56:13 -0500 Thread-Topic: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt Thread-Index: AczOR7HLpXje/n0lTeaKV3rdPs+ikwC61sxA Message-ID: References: <13205C286662DE4387D9AF3AC30EF456D74ED699B3@EMBX01-WF.jnpr.net> <4F04B6B8.6030208@cisco.com> <201201042243.q04Mhpk8014959@cichlid.raleigh.ibm.com> <7E187243-EAB3-4814-A78C-56DCEAE2C67C@cisco.com> <6.2.5.6.2.20120108022206.0c765c58@resistor.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "int-area@ietf.org" Subject: Re: [Int-area] I-D Action: draft-shen-traceroute-ping-ext-03.txt X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2012 14:56:16 -0000 > From: int-area-bounces@ietf.org [mailto:int-area-bounces@ietf.org] On > Behalf Of Naiming Shen > Sent: Sunday, January 08, 2012 3:54 PM > > Traceroute packets if they are not TTL expired you don't process them > on the router; > or Ping packets not destination to your address, you don't process them > on your router. > This extension does not change those behavior. You only check those > extension while > you are normally processing those packets anyway. So if you don't > normally filter those > packets (which is a good thing you are doing), you will have no need to > filter them just > because the router support this extension later. I hope this point is > clear. [WEG] Yes, that's clear. The concern is that the presence of this extension= means that there will be an increase in "to us" traffic for each router in= the network. If there is indeed a need for this extension to pass informat= ion back, there is an additional incentive for malicious use as well as sim= ple non-malicious overuse, both of which result in an increase in the flow = of trace/ping packets that your average box has to deal with somehow. Wheth= er it drops them due to a filter, a rate-limit, a failed authentication, or= responds to good packets, it still is going to see more of them than it do= es today. *That* is the scaling problem. This might not be a completely una= cceptable tradeoff in all cases, but you've failed to make your case that t= he benefit outweighs this risk, nor to my knowledge have there been other o= perators who have stood up and said "we need this feature for X reason" suc= h that we can validate your assertion that this would be something that is = helpful for operations. > > Now let's see what will be the percentage of processing which is > actually related to this > Traceroute/ping extension. For normal Traceroute for example, you need > to [snip - do a bunch of stuff] > Now with this extension, you just check (in a well > known location of the packet) > if it exists this extension by the magic#, if not there is nothing more > to do. Or you can > have a policy to check only if the probe source address is from network > x.x.x.x/y, > otherwise don't even bother with the extension. For those checks, I > would say may be 2-5% > of the original processing you have already needed to do. So, does this > actually cause a > concern of scaling on the Internet? [WEG] Yes, because you're leaving out several VERY important details - 1) the information this extension is proposing to supply back in a response= requires additional IPC to collect information that is not available on th= e local linecard. That IPC isn't free, so it'll definitely increase overhea= d far more than just processing additional data in the packet, especially i= f your IPC isn't particularly efficient and scalable. This also eliminates = any possibility that response to pings and traces can be offloaded exclusiv= ely to the linecard hardware instead of punting it to the RP. 2) as noted above, if this extension gets implemented, it'll generate more = traffic from people trying to use it, either to gain access to information = they're not authorized to, as another DoS attack vector, or assumedly, for = its intended purpose. This is not exclusively about the minor overhead gene= rated from processing this extension. It is also about the combined overhea= d of enforcing your proposed policy filtering, plus whatever else is alread= y going on in the box, etc. > Say take a 15 years old router, let's > upgrade the software > to this extension for the Traceroute/ping. Let's assume also this > extension actually consume > 10% more cpu. So instead of default punting 100 such a packet per > minute, now this > router is programmed only punting 90 such packets to process. Nothing > wrong with that. [WEG] Actually yes, yes there is. *Especially* on boxes that have very limi= ted resources to start with, the last thing you need to be doing is being c= avalier with the available resources. There are already plenty of boxes out= there that are running at or above their designed scale limits because the= re aren't funds to replace/upgrade them, and they basically do what they ne= ed to do. Those same vendor assumptions about what is "good enough", whethe= r arbitrary or based on what state of the art was capable of at the time ar= e likely part of the problem in today's world where things have changed and= they're no longer "good enough. " Further, your assumption is totally wrong if the box is already processing = enough traffic that it's routinely bumping up against that rate-limit with = routine and legitimate traffic, because now it's being potentially crowded = out by new traffic that may not even be legitimate. It's even worse if the = box gets hit with enough traffic that its built-in filtering mechanisms can= 't cope and therefore can't differentiate between good and bad traffic enou= gh to keep the box functional. For boxes that are more modern, your assumption that this is essentially a = non-impact is still wrong. Throwing more hardware at the problem is rarely = the right solution when compared with being more efficient and judicious wi= th your use of the existing hardware. Just because the latest and greatest = CPU hardware is currently running at 25% utilization doesn't mean that it a= lways will be. The combination of code bloat, new features, and increases i= n all of the scaling vectors that contribute to steady-state and peak CPU (= route churn, multicast joins/prunes, protocol keepalives, etc) gradually ea= t up that spare capacity. We buy hardware so that we can use it for a perio= d of years to recover our investment - the average Telco equipment deprecia= tion cycle is 7 years, and we're lucky to get anywhere near that as it is! = Anything that you do to tilt the growth curve in the wrong direction repres= ents an opportunity cost against when we have to replace/upgrade the hardwa= re. Sure, there are bigger impactors out there than your proposed extension= , but they all add up, and it's our job as operators to make sure we don't = end up dying the death of a thousand cuts anymore than we turn on one big t= hing that blows up the router or busts all of our scaling and growth assump= tions. > > Then if you think about this extension can actually ask for a subset of > information, instead > of just dumping everything the ICMP RFCs have defined, one may save > some cpu and bandwidth > in that sense. [WEG] Unlikely, because for the most part, if that information is available= via another, more widely implemented means (eg SNMP), chances are quite go= od that a) I already am polling the box for it and b) that I won't stop pol= ling it and replace that with this extension. It is simply not a valid assu= mption that this will do anything other than duplicate existing methods unl= ess it's pulling some unique information that isn't available via other met= hods. And so far, you have not presented a unique use case for this applica= tion. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From jsaldana@unizar.es Tue Jan 17 10:31:02 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE0211E8091 for ; Tue, 17 Jan 2012 10:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UE+zRTCgY2J for ; Tue, 17 Jan 2012 10:31:01 -0800 (PST) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id E9F2A11E808D for ; Tue, 17 Jan 2012 10:31:00 -0800 (PST) Received: from unizar.es (mesa.unizar.es [155.210.1.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id q0HIUtqX024317 for ; Tue, 17 Jan 2012 19:30:55 +0100 Received: from wsip-70-165-225-204.lv.lv.cox.net (wsip-70-165-225-204.lv.lv.cox.net [70.165.225.204]) by webmail.unizar.es (Horde MIME library) with HTTP; Tue, 17 Jan 2012 19:30:51 +0100 Message-ID: <20120117193051.7nf9fz8vi8swck40@webmail.unizar.es> Date: Tue, 17 Jan 2012 19:30:51 +0100 From: jsaldana@unizar.es To: int-area@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Subject: [Int-area] Proposal for updating RFC4170 (TCRTP) X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 18:31:02 -0000 Hello all. My name is Jose Saldana, from the University of Zaragoza, in Spain. I am new in this area. I would like to share with Internet Area a proposal, in case it could be considered interesting. The main idea is to update TCRTP. This is a "Best current practice" RFC =20 (http://datatracker.ietf.org/doc/rfc4170/) which was developed in =20 Audio/Video Transport working group in 2005-11. It "describes a method =20 to improve the bandwidth utilization of RTP streams over network paths =20 that carry multiple Real-time Transport Protocol (RTP) streams in parallel between two endpoints, as in voice trunking. The method combines standard protocols that provide compression, multiplexing, and tunneling over a network path for the purpose of reducing the bandwidth used when multiple RTP streams are carried over that path." (from the introduction of RFC4170). I have first sent this proposal to avtcore working group, but Magnus =20 Westerlund has answered this: ________ Hi, As you are proposing to go towards a more generic scheme I don't think this proposal really belongs in the WG, most likely not this area even. I think this is a topic that primarily are related to Intarea and Transport. Intarea as the owner of the tunneling work in IETF and Transport as the actual aggregation and header compression is primarily transport topics. A question I would have is where this type of mechanism would make sense. Where do you have scarce bandwidth capacity and are willing to pay the downsides of the ingress egress complexities and the impact on the traffic in regards to additional delay. Cheers Magnus ___________________ So I would like to know if the work can better fit this area. The scheme of TCRTP is: RTP/UDP/IP | | ECRTP (compressing layer). Compresses RTP/UDP/IP headers | | PPPMux (multiplexing layer). Includes a number of compressed packets into a bigger one | | L2TP (tunneling layer). Permits its use end-to-end | | IP However, there exist many real-time flows that do not use RTP: - Online "First Person Shooter" (FPS) games use UDP datagrams, and they are one of the most "real-time" applications nowadays. Some examples: Counter Strike, Halo, Quake, etc.[1]. - Online "Massively Multiplayer Online Role Playing Games" (MMORPG): They use TCP, but can be considered "real-time", since the actions of the players have to be transmitted very quickly to the server. It should be taken into account that player vs player fights are one of the possible activities of the game. Some examples: World of Warcraft (more than 10 million subscribers) [2]. - TCP is also getting used for media delivery. For many reasons, such as avoiding firewalls, the standard IP/ UDP/ RTP protocol stack is substituted in many cases by IP/ TCP/ HTTP/ FLV [3]. - Another interesting scenario is satellite communication links. Multiplexing small packets into one packet for transmission would improve the efficiency. Satellite links would also find it useful to multiplex small TCP packets into one packet - this could be especially interesting for compressing TCP ACKs. In our recent research activities, we have adapted TCRTP scheme for its use when the traffic is not RTP. The idea is to substitute ECRTP by other compression scheme which can be used for UDP or TCP headers. In 2006, the IETF formed the Robust Header Compression (ROHC) working group which created specifications for header compression over links for RTP, UDP and TCP. These specifications were extended to compress headers over other networks. For most RTP flows, ROHC is more bandwidth efficient than ECRTP, at the cost of implementation complexity. It has a special care of context synchronization, defining some states at the compressor and decompressor. Once the effort for designing ROHC has been conducted, it is worth including it in the compressing and multiplexing standard. In a recent paper in Nov. issue of IEEE Communications Magazine, it was shown that 30% of bandwidth saving can be achieved for 8 FPS different games using IPv4. If IPv6 is used, savings can be up to 54% [4]. Another recent study, which is still under review, has estimated 45% bandwidth saving for World of Warcraft. After talking to other researchers, including some of the authors of RFC4170, the possible scheme of the proposal could be this one: G.711.0 payload compression TCP UDP UDP/RTP | | | | | \ | / | \ | / | nothing or ROHC or ECRTP | | \ / \ / multiplexing layer (other or PPPMUX) | | tunneling layer (other or GRE or L2TP) | | IP It should be more "open" than TCRTP. I mean, it could be "orthogonal" to different protocols: different header compression algorithms could be used, depending on the application and the scenario; also different multiplexing and tunneling protocols could be included. Finally, we have also included the G.711.0 "branch": it could be interesting to convert G.711 to G.711.0 (a lossless encoding of G.711) and back, using a similar tunneling mechanism. In a similar way to TCRTP, the G.711 to G.711.0 and vice versa conversion does not involve SIP/SDP/RTSP signaling with the endpoints, since G.711 has a fixed RTP payload number. Regarding the scenarios, we have considered some of them: - A provider of a real-time service (e.g. game or voip) can have an =20 infrastructure with a number of proxies that can group traffic from different users and send =20 it to the server. - An Internet caf=E9, where a number (sometimes big) of players share =20 the same access link. Bandwidth is scarce in that scenario. - A satellite link, where the bandwidth and the pps have to be saved. We have not written a draft. This is only the first idea, so we look forward to hearing the opinion of the Area. Thank you very much, and sorry for writing such a long message, Jose Saldana University of Zaragoza ______________ [1] Ratti, S.; Hariri, B.; Shirmohammadi, S., "A Survey of First-Person Shooter Gaming Traffic on the Internet," Internet Computing, IEEE , vol.14, no.5, pp.60-69, Sept.-Oct. 2010. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5445069&isnumber= =3D5562482 [2] P. Svoboda, W Karner and M. Rupp, "Traffic Analysis and Modeling for World of Warcraft," ICC '07. IEEE International Conference on Communications, pp.1612-1617, 24-28, Jun. 2007. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D4288941&isnumber= =3D4288671 [3] G. Marfia and M. Roccetti, "TCP At Last: Reconsidering TCP's Role for Wireless Entertainment Centers at Home," IEEE Transactions on Consumer Electronics, Vol. 56, N. 4, Nov. 2010, pp. 2233-2240. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D5681095&isnumber= =3D5681060 [4] J. Saldana, J. Fern=E1ndez-Navajas, J. Ruiz-Mas, J. I. Aznar, E. Viruete and L. Casadesus, "First Person Shooters: Can a Smarter Network Save Bandwidth without Annoying the Players?," IEEE Communications Magazine, Consumer Communications and Networking Series, vol. 49, no. 11, pp. 190-198, Nov. 2011. URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=3D&arnumber=3D6069728&isnumber= =3D6069696 From brian.e.carpenter@gmail.com Tue Jan 17 13:16:09 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B9B21F853F for ; Tue, 17 Jan 2012 13:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id je-YxUHSmjez for ; Tue, 17 Jan 2012 13:16:08 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42FC121F853D for ; Tue, 17 Jan 2012 13:16:08 -0800 (PST) Received: by wics10 with SMTP id s10so2723630wic.31 for ; Tue, 17 Jan 2012 13:16:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:content-type:content-transfer-encoding; bh=scqyXW0GEeUa3pPDVjMbmOgEi69pjF//Ut/en8Fa41E=; b=SQ5FHolBRvB9Ob1SlNDItQAensT5tzc2OOaP8qcrZrW0iV9DgC5p12AO4VDpDS+ll2 6nJc/Edux3vYnhdGXtbZJ8SlxN+j3uVqHDHs1/ZMjjr//VDg72P7G8TJxgettLJ7uI46 OCB/XmZFy1er2YMu9zVpVbvgHJHn0Bs68o1mc= Received: by 10.180.97.166 with SMTP id eb6mr1666174wib.5.1326834967405; Tue, 17 Jan 2012 13:16:07 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id l2sm35633297wie.11.2012.01.17.13.16.05 (version=SSLv3 cipher=OTHER); Tue, 17 Jan 2012 13:16:07 -0800 (PST) Message-ID: <4F15E512.7000903@gmail.com> Date: Wed, 18 Jan 2012 10:16:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: int-area@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Willy Tarreau Subject: [Int-area] [Fwd: I-D Action: draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 21:16:09 -0000 This is a significant update since the version discussed in Taipei, with an additional author who is a practitioner in the field, and incorporating comments from implementors. Of course we would like more feedback. For the moment I suggest discussion on the v6ops@ietf.org list, although that may not be the final home for this draft. Please keep Willy on CC since I'm not sure he's on this list. Brian Carpenter -------- Original Message -------- Subject: I-D Action: draft-carpenter-v6ops-label-balance-01.txt Date: Tue, 17 Jan 2012 12:40:05 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using the IPv6 Flow Label for Server Load Balancing Author(s) : Brian Carpenter Sheng Jiang Willy Tarreau Filename : draft-carpenter-v6ops-label-balance-01.txt Pages : 12 Date : 2012-01-17 This document describes how the IPv6 flow label can be used in support of layer 3/4 load distribution and balancing for large server farms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Jeff.Hodges@KingsMountain.com Fri Jan 20 10:35:15 2012 Return-Path: X-Original-To: int-area@ietfa.amsl.com Delivered-To: int-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280E521F85D7 for ; Fri, 20 Jan 2012 10:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.181 X-Spam-Level: X-Spam-Status: No, score=-100.181 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPl8HgDw9Eip for ; Fri, 20 Jan 2012 10:35:14 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 7D89921F85EC for ; Fri, 20 Jan 2012 10:35:14 -0800 (PST) Received: (qmail 23553 invoked by uid 0); 20 Jan 2012 18:35:13 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 20 Jan 2012 18:35:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=mUy2U1BpfNYMDd5EKhchuMU7oiyAGNCTZ2DMQcshBKg=; b=KTPCG/+XPr3LmN6yrlI5X/qLJkbTFTEZec8zcYn0YZh/PunejMofSBUHZfSVD8NCtD5t5ndJbD7NALn4pwOS7y2tLeTydDxEoafdXy4BPXt+BkBC7NQnHTEei4Vie2JL; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.101]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RoJIu-0000BZ-TG; Fri, 20 Jan 2012 11:35:12 -0700 Message-ID: <4F19B3DF.5050402@KingsMountain.com> Date: Fri, 20 Jan 2012 10:35:11 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Apps Discuss , IETF WebSec WG , RAI Discuss , Internet Area Discuss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [Int-area] TheRightKey@ietf.org -- next gen broad user-facing internet trust infrastructure discussion X-BeenThere: int-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Internet Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 18:35:15 -0000 this list, TheRightKey@ietf.org -- where next gen broad user-facing internet trust infrastructure is being discussed, was originally advertised to SAAG, PKIX, TLS, and DANE. Sending to these lists in case any potentially interested parties missed it. HTH, =JeffH ------- Forwarded Message Subject: New Non-WG Mailing List: therightkey Date: Fri, 13 Jan 2012 10:23:58 -0800 (PST) From: IETF Secretariat To: IETF Announcement list CC: therightkey@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie A new IETF non-working group email list has been created. List address: therightkey@ietf.org Archive: http://www.ietf.org/mail-archive/web/therightkey/ To subscribe: https://www.ietf.org/mailman/listinfo/therightkey Purpose: A number of people are interested in discussing proposals that have been developed in response to recent attacks on the Internet security infrastructure, in particular those that affected sites using TLS and other protocols relying on PKI. This list is intended for discussion of those proposals and how they might result in potential work items for the IETF. One short-term outcome may be the holding of a non-wg-forming BoF at IETF-83. For additional information, please contact the list administrators. ------- End of Forwarded Message