From rtg-bfd-bounces@ietf.org Sat Nov 1 13:10:28 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E68873A695B; Sat, 1 Nov 2008 13:10:28 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126BC3A695B for ; Sat, 1 Nov 2008 13:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5a+Vm8vVlOP for ; Sat, 1 Nov 2008 13:10:26 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id E84C03A68D7 for ; Sat, 1 Nov 2008 13:10:25 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 7CAB7244194; Sat, 1 Nov 2008 20:10:24 +0000 (UTC) Date: Sat, 1 Nov 2008 16:10:24 -0400 From: Jeffrey Haas To: "Bhatia, Manav (Manav)" Subject: Re: Some comments on BFD Authentication .. Message-ID: <20081101201024.GA6486@slice> References: <6D26D1FE43A66F439F8109CDD4241965021D76BF@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6D26D1FE43A66F439F8109CDD4241965021D76BF@INEXC1U01.in.lucent.com> User-Agent: Mutt/1.5.15+20070412 (2007-04-11) Cc: rtg-bfd@ietf.org, dward@cisco.com X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Manav, Not speaking as a chair nor specifically for the authors: On Sat, Nov 01, 2008 at 12:16:50AM +0530, Bhatia, Manav (Manav) wrote: > It states that the Auth Key/Checksum field (btw this field is a really > not a "checksum" per se) must be filled with the key that is being used > to compute the MD5/SHA1 hash. So what happens if the key size is less > than the hash size? The relevant point in the document is in 6.7.4: : Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 : Authentication : : The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 (Meticulous : Keyed SHA1.) The Auth Len field MUST be set to 28. The Auth Key : ID field MUST be set to the ID of the current authentication key. Thus the key MUST be 28 octets long. I suspect your point is "the key may be ascii text less than 28 octets long". In that particular case, each side must choose to populate the remaining octets in the same fashion. In my opinion, that's a matter of local configuration although it argues the maximally portable configuration syntax is one that allows 28 integers from 0-255 to be input. Clearly, for maximal security, a simple passphrase shouldn't be used. > (b) One of the comments that we received during the GEN-ART review for > ISIS crypto draft was that 1 octet for a Key ID looked to restrictive. > Applying the same logic here, can we increase the size of the Key ID > field to at least 2 octets? Authentication types 1-5 are, I believe, currently deployed. Thus we are unlikely to want to change the size of the key ID in the packet format. 1 octet provides sufficient space to allow regular rotation of keys although perhaps it will require more coordination to update the key set than would be required if the ID space was larger. If this proves to be a problem in deployment, the base specification provides the ability to add new authentication types which could have a larger ID space. > (c) If you are specifying the cryptographic algorithm details in the > Auth Type (MD5, SHA1, etc) then the Auth Len is redundant and can be > simply done away with. One always knows that if the Auth Type is 2-3 > then the size would be 24, etc. Speaking as a developer, I'm usually pleased to have a consistent format for my PDUs even if the length component is implied in some cases. Others may obviously feel differently. > (d) Why don't we add a generic (crypto-algo independent) authentication > type (say type 6) in this document? The sender just fills the Key ID, > the authentication data fields with the hash/digest, and the auth len > with the size of the digest. The BFD neighbor upon receiving this packet > would do a lookup in its local database using the key ID carried in the > packet and determine the auth algo and the secret key associated with it > to verify the packet. (Caveat: I am not a cryptographer.) The security of a given algorithm should not depend on its details being secret. Regardless of the cipher in question, we should expect the security properties of an IETF supported cryptographic algorithm to depend on the security of the crypto instead of any form of security by obscurity. If one were to attempt to do some form of obfuscation, it would require some amount of arbitrary padding in the authentication portion of the packet. In order to give the appearances that this padding is part of the ciphertext, one would presume it was seeded by a form of high-entropy random data. Since BFD is often implemented in line cards, that alone may be a good reason to not do it. > It also allows folks to use "non-standard" > algorithms as that information isn't carried in the BFD packets. Last > but not the least, we don't need to request IANA for a code point or a > new RFC to be published, each time a new cryptographic algorithm is > introduced. Even if we introduced a "vendor specific" authentication type field, we would still require some sort of identifier to remove the ambiguity of whose implementation and which algorithm is being used. You would still require a registry to maintain the code points for at least the vendor. Within the context of the IETF code points for authentication, I personally find it somewhat improbable that we'll have so many significant discoveries of cryptographic hash algorithms that we'd exhaust the remaining key space. :-) > We could also have a meticulous generic crypto auth type (type 7?). > > (e) Any specific reason why we're not using the HMAC constructs? This point was raised in DISCUSS and we're waiting for author response to this in the updated draft. -- Jeff From rtg-bfd-bounces@ietf.org Sat Nov 1 16:54:19 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCB083A6870; Sat, 1 Nov 2008 16:54:19 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7B43A6880 for ; Sat, 1 Nov 2008 16:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czqfColI986v for ; Sat, 1 Nov 2008 16:54:17 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id E9D8A3A6866 for ; Sat, 1 Nov 2008 16:54:16 -0700 (PDT) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mA1Ns7KB005903; Sat, 1 Nov 2008 18:54:07 -0500 (CDT) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Nov 2008 18:54:07 -0500 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Nov 2008 05:23:29 +0530 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 Subject: RE: Some comments on BFD Authentication .. Date: Sun, 2 Nov 2008 05:23:27 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD4241965021D773C@INEXC1U01.in.lucent.com> In-Reply-To: <20081101201024.GA6486@slice> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments on BFD Authentication .. thread-index: Ack8Xed0hiPJnBItQAemwG42WhkZmQAFz7uw References: <6D26D1FE43A66F439F8109CDD4241965021D76BF@INEXC1U01.in.lucent.com> <20081101201024.GA6486@slice> From: "Bhatia, Manav \(Manav\)" To: "Jeffrey Haas" X-OriginalArrivalTime: 01 Nov 2008 23:53:29.0240 (UTC) FILETIME=[09F50180:01C93C7D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: rtg-bfd@ietf.org, dward@cisco.com X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Jeff, Thanks for your comments. Please find my response inline. =20 > On Sat, Nov 01, 2008 at 12:16:50AM +0530, Bhatia, Manav (Manav) wrote: > > It states that the Auth Key/Checksum field (btw this field=20 > is a really > > not a "checksum" per se) must be filled with the key that=20 > is being used > > to compute the MD5/SHA1 hash. So what happens if the key=20 > size is less > > than the hash size? >=20 > The relevant point in the document is in 6.7.4: > : Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 > : Authentication > : > : The Auth Type field MUST be set to 4 (Keyed SHA1) or 5=20 > (Meticulous > : Keyed SHA1.) The Auth Len field MUST be set to 28. =20 > The Auth Key > : ID field MUST be set to the ID of the current=20 > authentication key. >=20 > Thus the key MUST be 28 octets long. No, this is incorrect - it should be 20 octets long and not 28 as you state. Auth Len gives the total size of the Authentication Section in the BFD packet and has no relation with the Key size.=20 The following text in the draft gives a hint of the size restrictions that has been imposed on the key size that should be used: : The current authentication key value MUST be placed into the Auth : Key/Checksum field. A SHA1 checksum MUST be calculated over the : entire BFD control packet. The resulting checksum MUST be stored : in the Auth Key/Checksum field prior to transmission (replacing : the secret key, which MUST NOT be carried in the packet.) This means that the operator must be well versed with the hash size that the underlying hashing algorithm (MD5, SHA-1, SHA-256, etc) would generate and then the same should be used when constructing the key. This sounds extremely odd to me. Why should the user password have any relation with the secret key used in constructing the hash? >=20 > I suspect your point is "the key may be ascii text less than 28 octets > long". In that particular case, each side must choose to populate the > remaining octets in the same fashion. In my opinion, that's=20 > a matter of > local configuration although it argues the maximally portable This is exactly my point. The spec needs to spell out how each side fills the remaining octets if it wants to ensure a consistent behavior. You could add some text like this: In the algorithm description below, the following nomenclature, which is consistent with [FIPS-198], is used:=20 =20 H is the specific hashing algorithm (e.g. MD5-, SHA-1, etc).=20 K is the password for the packet given by the user Ko is the cryptographic key used with the hash algorithm.=20 L is the length of the hash, measured in octets rather than bits.=20 =20 Preparation of the Key=20 =20 In this application, Ko is always L octets long.=20 =20 If the Authentication Key (K) is L octets long, then Ko is equal to K. If K is more than L octets long, then Ko is set to H(K). If K is less than L octets long, then Ko is set to the K with zeros appended to the end of the K such that Ko is L octets long.=20 > > (d) Why don't we add a generic (crypto-algo independent)=20 > authentication > > type (say type 6) in this document? The sender just fills=20 > the Key ID, > > the authentication data fields with the hash/digest, and=20 > the auth len > > with the size of the digest. The BFD neighbor upon=20 > receiving this packet > > would do a lookup in its local database using the key ID=20 > carried in the > > packet and determine the auth algo and the secret key=20 > associated with it > > to verify the packet. >=20 > (Caveat: I am not a cryptographer.) >=20 > The security of a given algorithm should not depend on its=20 > details being > secret. Regardless of the cipher in question, we should expect the > security properties of an IETF supported cryptographic algorithm to > depend on the security of the crypto instead of any form of=20 > security by > obscurity. I agree.=20 The idea btw was not to indulge in steganography, but to just provide, as the name suggested, a generic cryptographic authentication mechanism. This proposal is not new and already exists in OSPF and ISIS. However, I agree that it's a trifle too late to add this to the base spec at this point of time, so I'll withdraw this particular comment. >=20 > If one were to attempt to do some form of obfuscation, it=20 > would require > some amount of arbitrary padding in the authentication portion of the > packet. In order to give the appearances that this padding is part of > the ciphertext, one would presume it was seeded by a form of > high-entropy random data. Since BFD is often implemented in=20 > line cards, > that alone may be a good reason to not do it. Again the idea was not to obfuscate, it was merely to keep the cryptographic algorithm details out of the BFD packet. This is because in cryptography, new algorithms surface continuously and existing ones are continuously attacked - an algorithm believed to be secure today may be demonstrated to be weak tomorrow. In light of this its best to keep the protocols/applications (BFD, etc) independent of the underlying crypto algo being used. You don't later want to publish new RFCs asking people NOT to support some particular auth types because of the obvious weaknesses found there.=20 To give an idea, DES algo in CBC mode was suggested to be used for IPSEC [RFC 2405]. However, later when attacks against this particular algorithm were found, it was removed from the list of mandatory to implement algorithms for IPSEC [4305]. Applying the same analogy here if there are open weaknesses found in MD5 and SHA-1 tomorrow, then we will have to publish new RFCs in BFD WG deprecating the use of Auth Types 2,3,4 and 5 and so on with each auth algo that's exploited in the future. A cleaner way is to keep BFD independent of the underlying crypto algo details and this can be achieved by using a generic authentication mechanism that I had suggested. You could look at how OSPF [RFC 2328] and IS-IS [draft-ietf-isis-hmac-sha-06.txt] do their generic crypto authentication. So I still stand by the merits of using a generic crypto auth mechanism however, I withdraw this particular comment as I believe its too late to update the spec now. We could always add an extension to BFD later ..=20 >=20 > > It also allows folks to use "non-standard" > > algorithms as that information isn't carried in the BFD=20 > packets. Last > > but not the least, we don't need to request IANA for a code=20 > point or a > > new RFC to be published, each time a new cryptographic algorithm is > > introduced. >=20 > Even if we introduced a "vendor specific" authentication type=20 > field, we > would still require some sort of identifier to remove the ambiguity of > whose implementation and which algorithm is being used. You=20 > would still > require a registry to maintain the code points for at least=20 > the vendor. No, you wouldn't. The Key ID would map to the BFD security association and would give all the required details. All that the two ends need to ensure is that they use the same auth algo, key, etc for the negotiated key ID. BFD just doesn't care about the underlying details. For all you know the Auth algo given by the Key ID could be a new NIST approved hash algo, a proprietary algo or a deprecated algo - BFD would work as long as the two ends support that. >=20 > Within the context of the IETF code points for authentication, I > personally find it somewhat improbable that we'll have so many > significant discoveries of cryptographic hash algorithms that we'd > exhaust the remaining key space. :-) I believe you wanted to say the Auth Type and not the key space here! :-) Cheers, Manav From rtg-bfd-bounces@ietf.org Sat Nov 1 18:57:09 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76533A686C; Sat, 1 Nov 2008 18:57:09 -0700 (PDT) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B54CB3A67EC for ; Sat, 1 Nov 2008 18:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCTICNJtruUv for ; Sat, 1 Nov 2008 18:57:07 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by core3.amsl.com (Postfix) with ESMTP id DE8F73A6826 for ; Sat, 1 Nov 2008 18:57:06 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so2038876fkq.5 for ; Sat, 01 Nov 2008 18:57:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=4bQq+XLzs7FhNX4fxujtAW4hhi9hAHTnOWyrpm1yMd4=; b=fk2MJDHmmws2K2pUF4V6lCa1HQCZX2SjUlnFlUera3K1k3o/9R2sDL/7YC3ZRheZdT yNmCdkNsFoZBtpIUf3WLGhJ8wTt4aJOEFQyfEEwb9eweYzZUpCj8KA+seVa3uGx6Hl1z +7/swoI/0X0MzKeWu9gX7JZ62K6JEERt4iF+U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=fBG5PXkHP/a4Ct8x0OuXmW9HW2v49DGZ27LbsUC+aInRv/0pQCtC21VOib3+Uv74gs tyC7tKV+TqG/kiAWFd/geENXLCwmxxeJIvUyKEMeJk4w8lEe3mFUeqzqG+97IoP63V/+ Ob6Eo0+0dw6m/8fxTsMXqsHoCMNZx/QS3PT/I= Received: by 10.180.247.12 with SMTP id u12mr3657789bkh.154.1225591024441; Sat, 01 Nov 2008 18:57:04 -0700 (PDT) Received: by 10.180.226.2 with HTTP; Sat, 1 Nov 2008 18:57:04 -0700 (PDT) Message-ID: <77ead0ec0811011857o57654a6buc961c30b3a34ab25@mail.gmail.com> Date: Sun, 2 Nov 2008 07:27:04 +0530 From: "Vishwas Manral" To: "Bhatia, Manav (Manav)" Subject: Re: Some comments on BFD Authentication .. In-Reply-To: <6D26D1FE43A66F439F8109CDD4241965021D773C@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD4241965021D76BF@INEXC1U01.in.lucent.com> <20081101201024.GA6486@slice> <6D26D1FE43A66F439F8109CDD4241965021D773C@INEXC1U01.in.lucent.com> Cc: rtg-bfd@ietf.org, dward@cisco.com X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Jeff/ Manav, I have raised similar and some more issues about a couple of months back. Do have a look at the below and let me know your comments. www.ietf.org/mail-archive/web/rtg-bfd/current/msg00480.html www.ietf.org/mail-archive/web/rtg-bfd/current/msg00488.html Thanks, Vishwas On 11/2/08, Bhatia, Manav (Manav) wrote: > Jeff, > > Thanks for your comments. Please find my response inline. > >> On Sat, Nov 01, 2008 at 12:16:50AM +0530, Bhatia, Manav (Manav) wrote: >> > It states that the Auth Key/Checksum field (btw this field >> is a really >> > not a "checksum" per se) must be filled with the key that >> is being used >> > to compute the MD5/SHA1 hash. So what happens if the key >> size is less >> > than the hash size? >> >> The relevant point in the document is in 6.7.4: >> : Transmission Using Keyed SHA1 and Meticulous Keyed SHA1 >> : Authentication >> : >> : The Auth Type field MUST be set to 4 (Keyed SHA1) or 5 >> (Meticulous >> : Keyed SHA1.) The Auth Len field MUST be set to 28. >> The Auth Key >> : ID field MUST be set to the ID of the current >> authentication key. >> >> Thus the key MUST be 28 octets long. > > No, this is incorrect - it should be 20 octets long and not 28 as you > state. Auth Len gives the total size of the Authentication Section in > the BFD packet and has no relation with the Key size. > > The following text in the draft gives a hint of the size restrictions > that has been imposed on the key size that should be used: > > : The current authentication key value MUST be placed into the Auth > : Key/Checksum field. A SHA1 checksum MUST be calculated over the > : entire BFD control packet. The resulting checksum MUST be stored > : in the Auth Key/Checksum field prior to transmission (replacing > : the secret key, which MUST NOT be carried in the packet.) > > This means that the operator must be well versed with the hash size that > the underlying hashing algorithm (MD5, SHA-1, SHA-256, etc) would > generate and then the same should be used when constructing the key. > This sounds extremely odd to me. Why should the user password have any > relation with the secret key used in constructing the hash? > >> >> I suspect your point is "the key may be ascii text less than 28 octets >> long". In that particular case, each side must choose to populate the >> remaining octets in the same fashion. In my opinion, that's >> a matter of >> local configuration although it argues the maximally portable > > This is exactly my point. The spec needs to spell out how each side > fills the remaining octets if it wants to ensure a consistent behavior. > You could add some text like this: > > In the algorithm description below, the following nomenclature, which is > consistent with [FIPS-198], is used: > > H is the specific hashing algorithm (e.g. MD5-, SHA-1, etc). > K is the password for the packet given by the user > Ko is the cryptographic key used with the hash algorithm. > L is the length of the hash, measured in octets rather than bits. > > Preparation of the Key > > In this application, Ko is always L octets long. > > If the Authentication Key (K) is L octets long, then Ko is equal to K. > If K is more than L octets long, then Ko is set to H(K). If K is less > than L octets long, then Ko is set to the K with zeros appended to the > end of the K such that Ko is L octets long. > >> > (d) Why don't we add a generic (crypto-algo independent) >> authentication >> > type (say type 6) in this document? The sender just fills >> the Key ID, >> > the authentication data fields with the hash/digest, and >> the auth len >> > with the size of the digest. The BFD neighbor upon >> receiving this packet >> > would do a lookup in its local database using the key ID >> carried in the >> > packet and determine the auth algo and the secret key >> associated with it >> > to verify the packet. >> >> (Caveat: I am not a cryptographer.) >> >> The security of a given algorithm should not depend on its >> details being >> secret. Regardless of the cipher in question, we should expect the >> security properties of an IETF supported cryptographic algorithm to >> depend on the security of the crypto instead of any form of >> security by >> obscurity. > > I agree. > > The idea btw was not to indulge in steganography, but to just provide, > as the name suggested, a generic cryptographic authentication mechanism. > This proposal is not new and already exists in OSPF and ISIS. However, I > agree that it's a trifle too late to add this to the base spec at this > point of time, so I'll withdraw this particular comment. > >> >> If one were to attempt to do some form of obfuscation, it >> would require >> some amount of arbitrary padding in the authentication portion of the >> packet. In order to give the appearances that this padding is part of >> the ciphertext, one would presume it was seeded by a form of >> high-entropy random data. Since BFD is often implemented in >> line cards, >> that alone may be a good reason to not do it. > > Again the idea was not to obfuscate, it was merely to keep the > cryptographic algorithm details out of the BFD packet. This is because > in cryptography, new algorithms surface continuously and existing ones > are continuously attacked - an algorithm believed to be secure today may > be demonstrated to be weak tomorrow. In light of this its best to keep > the protocols/applications (BFD, etc) independent of the underlying > crypto algo being used. You don't later want to publish new RFCs asking > people NOT to support some particular auth types because of the obvious > weaknesses found there. > > To give an idea, DES algo in CBC mode was suggested to be used for IPSEC > [RFC 2405]. However, later when attacks against this particular > algorithm were found, it was removed from the list of mandatory to > implement algorithms for IPSEC [4305]. > > Applying the same analogy here if there are open weaknesses found in MD5 > and SHA-1 tomorrow, then we will have to publish new RFCs in BFD WG > deprecating the use of Auth Types 2,3,4 and 5 and so on with each auth > algo that's exploited in the future. A cleaner way is to keep BFD > independent of the underlying crypto algo details and this can be > achieved by using a generic authentication mechanism that I had > suggested. > > You could look at how OSPF [RFC 2328] and IS-IS > [draft-ietf-isis-hmac-sha-06.txt] do their generic crypto > authentication. > > So I still stand by the merits of using a generic crypto auth mechanism > however, I withdraw this particular comment as I believe its too late to > update the spec now. We could always add an extension to BFD later .. > >> >> > It also allows folks to use "non-standard" >> > algorithms as that information isn't carried in the BFD >> packets. Last >> > but not the least, we don't need to request IANA for a code >> point or a >> > new RFC to be published, each time a new cryptographic algorithm is >> > introduced. >> >> Even if we introduced a "vendor specific" authentication type >> field, we >> would still require some sort of identifier to remove the ambiguity of >> whose implementation and which algorithm is being used. You >> would still >> require a registry to maintain the code points for at least >> the vendor. > > No, you wouldn't. The Key ID would map to the BFD security association > and would give all the required details. All that the two ends need to > ensure is that they use the same auth algo, key, etc for the negotiated > key ID. BFD just doesn't care about the underlying details. For all you > know the Auth algo given by the Key ID could be a new NIST approved hash > algo, a proprietary algo or a deprecated algo - BFD would work as long > as the two ends support that. > >> >> Within the context of the IETF code points for authentication, I >> personally find it somewhat improbable that we'll have so many >> significant discoveries of cryptographic hash algorithms that we'd >> exhaust the remaining key space. :-) > > I believe you wanted to say the Auth Type and not the key space here! > :-) > > Cheers, Manav > From rtg-bfd-bounces@ietf.org Tue Nov 18 08:53:38 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2830B28C213; Tue, 18 Nov 2008 08:53:38 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E142328C1D7 for ; Tue, 18 Nov 2008 08:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.37 X-Spam-Level: X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=-0.771, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhKksRqpPzgr for ; Tue, 18 Nov 2008 08:53:36 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id CE2FC3A68A9 for ; Tue, 18 Nov 2008 08:53:35 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mAIGrYeM012591 for ; Tue, 18 Nov 2008 10:53:34 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 10:53:34 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Nov 2008 22:23:31 +0530 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 Subject: BFD Generic Cryptographic Authentication Date: Tue, 18 Nov 2008 22:23:29 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD4241965022A9020@INEXC1U01.in.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD Generic Cryptographic Authentication thread-index: AclJni73vejnIofgQ2uLF/HkP0VVTQ== From: "Bhatia, Manav \(Manav\)" To: X-OriginalArrivalTime: 18 Nov 2008 16:53:31.0601 (UTC) FILETIME=[30042C10:01C9499E] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi, We have written a small draft on BFD security. 10000ft view of the draft: o Adds two new Auth Types - Cryptographic Authentication and Meticulous Cryptographic Authentication. These types are generic and can be used with any authentication algorithm. We now don't need to raise a request with IANA before providing support for any new algo in the future.=20 o Describes how BFD can use HMAC-SHA to authenticate its packets as opposed to Keyed MD5 and plain SHA-1 that's described in the base spec. o Changes the order of crypto sequence number check when receiving BFD packets. Its now done before any algorithm dependent processing is done. In the base spec the sequence number check is done *after* all the algorithm dependent processing is over - this imo amplifies the possibility of a DoS attack. o Increases the Key ID space to 2 bytes and renames Auth Key/Checksum field in the Auth Section to Authentication Data. Abstract: This document proposes an extension for Bidirectional Forwarding Detection (BFD) to allow the use of any cryptographic authentication algorithm in addition to the already documented authentication schemes, described in the base specification. =20 =20 Although this document has been written specifically to introduce two new Authentication types it describes how BFD can use Hashed Message Authentication Code (HMAC) construct along with the Secure Hash algorithm (SHA) [FIPS-180-3] family of cryptographic hash functions to authenticate the control packets. =20 =20 The method described in this document is generic and can be used to extend BFD to support any cryptographic hash function in the future.=20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bhatia-bfd-crypto-auth-00.txt Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India =20 From rtg-bfd-bounces@ietf.org Thu Nov 20 21:37:53 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0721F28C13A; Thu, 20 Nov 2008 21:37:53 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695FC28C144 for ; Thu, 20 Nov 2008 21:37:51 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptIHEnc7Xp1e for ; Thu, 20 Nov 2008 21:37:50 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 6C1EE3A67EE for ; Thu, 20 Nov 2008 21:37:50 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so400207wag.5 for ; Thu, 20 Nov 2008 21:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=geEeCq2EvfnTwcHZzhILxYezKDBPsyleOxaiC/HYpWg=; b=HgHTANLl8p9hhBwTSHCw/65umDocJFXE8lYCKwnWfpDnTl2wTQYclkeyPX2osdpWwH zCPuJJ9oZwS2ycaAHtAoQWlK1JQKic5YUPJPKo2OCIbaopl9U84ixV71qaI9y037nP+U Zwa6SFrz8ENMYVRDoCPK6RUeT18cGoj1MwYjE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=t8Xv4ul0ANkB8b0Hf26dGF8T/PtoW+FGOntVSBVkN1cTdjMIaDUZ9VhtCpYuBuQYV/ 1t3BFVDeZ9bg9mWlVNLj8UR1qETbWs9Pl1wjQt3COvii35xOpkTdXa6iPaIf7OQSn38z +N4iZ2oYQBgi3LxHUPqZ9Pku8vsWvcDgXWIkc= Received: by 10.114.255.1 with SMTP id c1mr104869wai.4.1227245868898; Thu, 20 Nov 2008 21:37:48 -0800 (PST) Received: by 10.115.48.9 with HTTP; Thu, 20 Nov 2008 21:37:48 -0800 (PST) Message-ID: <6ed23a860811202137m6997d3aq72024cd47baae994@mail.gmail.com> Date: Fri, 21 Nov 2008 11:07:48 +0530 From: "Tom Sanders" To: "Bhatia, Manav (Manav)" Subject: Re: BFD Generic Cryptographic Authentication In-Reply-To: <6D26D1FE43A66F439F8109CDD4241965022A9020@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD4241965022A9020@INEXC1U01.in.lucent.com> Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Manav, I think its a step in the right direction. > o Changes the order of crypto sequence number check when receiving BFD > packets. Its now done before any algorithm dependent processing is done. > In the base spec the sequence number check is done *after* all the > algorithm dependent processing is over - this imo amplifies the > possibility of a DoS attack. I believe this is something very fundamental in how the security ought to be designed for the internet protocols. You dont want to compute the hash/digest, only to later discard the packet because some other parameter isnt what you expected it to be (in this case the sequence number). And this becomes all the more accentuated in case of BFD as this byte crunching may be happening in the line cards. Good catch indeed! You should add a section on BFD too in draft-ietf-opsec-routing-protocols-crypto-issues-00.txt besides PIM, as somebody else in OPSEC meet suggested the other day. > > o Increases the Key ID space to 2 bytes and renames Auth Key/Checksum > field in the Auth Section to Authentication Data. Thanks. I have always found the term "checksum" rather unnerving and is at the very least, trifle misleading. Since this memo deals exclusively with BFD authentication, shouldnt you spend some more time detailing how the keys should be managed (life associated with key, start time, stop time, etc) - some recommendations on the key entropy would also help. -- Toms. From rtg-bfd-bounces@ietf.org Fri Nov 21 09:13:14 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF77628C0F9; Fri, 21 Nov 2008 09:13:14 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930AC28C100 for ; Fri, 21 Nov 2008 09:13:13 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+Lg5akTW3yr for ; Fri, 21 Nov 2008 09:13:12 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id D0D6628C0F0 for ; Fri, 21 Nov 2008 09:13:11 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so773385fga.41 for ; Fri, 21 Nov 2008 09:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=iw4SwGBrTGTaDGA55EdVyrZVLoDMa+zuoZkzJNJtNQA=; b=j1E9T0EJbUycT35ET1c9tT44djVod6LaL/3kYDIbpXzpuwk6rOBlhG68SxwBzmSlZJ oumGWmAq2MJJ8LyKP3B3T3oLdNK+5tAoq5+sl4USqt5jGrKUEq2fdSlb7TonmiF6B6Fo z3+8DHk0QbiisgsNICiEdLf+JG5waCF8N7VOA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=IMnel4nhO7venAUB+7gs9Yg3lSeHe0Ay5YyaTRDzFB5n8tN3BNn4eNIK2lT+ipteq9 piHt+Hdkp/DV62PtEmrrTLTVL/9fa4l7uTwxPLDmDYMIHla8Tquca7tSW3OvxDxtDJAo dNeHntx5/Hr8lqZ94Znd7TbJPygXTXFZ8kjFQ= Received: by 10.181.225.6 with SMTP id c6mr221194bkr.207.1227287589596; Fri, 21 Nov 2008 09:13:09 -0800 (PST) Received: by 10.181.24.20 with HTTP; Fri, 21 Nov 2008 09:13:09 -0800 (PST) Message-ID: <77ead0ec0811210913n1e188090w65ea76d911a38fb1@mail.gmail.com> Date: Fri, 21 Nov 2008 09:13:09 -0800 From: "Vishwas Manral" To: "Tom Sanders" Subject: Re: BFD Generic Cryptographic Authentication In-Reply-To: <6ed23a860811202137m6997d3aq72024cd47baae994@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD4241965022A9020@INEXC1U01.in.lucent.com> <6ed23a860811202137m6997d3aq72024cd47baae994@mail.gmail.com> Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Tom, Thanks for your encouraging comments on the draft. There are some more interesting thoughts in my mind right now, please read below. Manav, I think we can atleast put some of them in the draft. > I think its a step in the right direction. > >> o Changes the order of crypto sequence number check when receiving BFD >> packets. Its now done before any algorithm dependent processing is done. >> In the base spec the sequence number check is done *after* all the >> algorithm dependent processing is over - this imo amplifies the >> possibility of a DoS attack. > > I believe this is something very fundamental in how the security ought > to be designed for the internet protocols. You dont want to compute > the hash/digest, only to later discard the packet because some other > parameter isnt what you expected it to be (in this case the sequence > number). And this becomes all the more accentuated in case of BFD as > this byte crunching may be happening in the line cards. Good catch > indeed! Thanks about this. Generally speaking we would want to do the checksum/ hash before we would do anything because unless that is correct we do not know the sanity of the packet. However the sequence number itself is like a security mechanism (not to the extent of the TCP one), as not all numbers are valid. It is a good idea to do some checks before going in for the CPU heavy hashing mechanism. > You should add a section on BFD too in > draft-ietf-opsec-routing-protocols-crypto-issues-00.txt besides PIM, > as somebody else in OPSEC meet suggested the other day. Yes, we can do that. BFD falls well within scope, we have not looked at PIM yet though. >> >> o Increases the Key ID space to 2 bytes and renames Auth Key/Checksum >> field in the Auth Section to Authentication Data. > > Thanks. I have always found the term "checksum" rather unnerving and > is at the very least, trifle misleading. > > Since this memo deals exclusively with BFD authentication, shouldnt > you spend some more time detailing how the keys should be managed > (life associated with key, start time, stop time, etc) - some > recommendations on the key entropy would also help. One interesting thing about BFD is that BFD packet counters are 64 bits (as unlike other control protocols BFD packets are sent contnuously and at a very fast rate). This will lead to sequence number rotation faster in BFD compared to other protocols. If I was the author of BFD base spec I would make the sequence number counter in BFD to be 64-bits and not 32-bits. Thanks again, Vishwas > -- > Toms. > From rtg-bfd-bounces@ietf.org Fri Nov 21 16:10:38 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09D4E3A6A71; Fri, 21 Nov 2008 16:10:38 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020D53A6A70 for ; Fri, 21 Nov 2008 16:10:37 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frqKspWPpiqZ for ; Fri, 21 Nov 2008 16:10:35 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id 60FB03A67AB for ; Fri, 21 Nov 2008 16:10:35 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so587475wag.5 for ; Fri, 21 Nov 2008 16:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=xTeL94TwqmkC05FqYBi2mM8w4nki7pC/Z2jqZpQCgOI=; b=X3QlBSK93fWEzf3LS5E6uvJPKTc+oGlddan8I0jUtEax2/iLRDK+zVU8mDwpV5G8PO d+77l0HUsn3/q0Nj8dGddxBKuo5BqjWgNeQXFP9ioG0FAS1J0+cPwXaVTDGAEpfRADi2 kb/S8E5fQyY8lgeqTwa6/KjTR2rmqSvvV4SLs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wEUBXpYdVc2aAPdxQWxCIGZ9yyglixXLEoT8GWAuR5xwmbb9F8aKE+qnPXYEaLXwp3 Qq5mMogxyFc7J72FryafBzVfGOVd0DztXa2eWvfWKeKMf+u6Xu+SiJORmDuN4kJf4Vb+ iCrxHvBUlyy5oSEfbAL6fuVXWP0k6+McTanFo= Received: by 10.114.167.10 with SMTP id p10mr587604wae.198.1227312634029; Fri, 21 Nov 2008 16:10:34 -0800 (PST) Received: by 10.115.48.9 with HTTP; Fri, 21 Nov 2008 16:10:34 -0800 (PST) Message-ID: <6ed23a860811211610p7760f109u448828bb1c3bb9e7@mail.gmail.com> Date: Sat, 22 Nov 2008 05:40:34 +0530 From: "Tom Sanders" To: "Vishwas Manral" Subject: Re: BFD Generic Cryptographic Authentication In-Reply-To: <77ead0ec0811210913n1e188090w65ea76d911a38fb1@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD4241965022A9020@INEXC1U01.in.lucent.com> <6ed23a860811202137m6997d3aq72024cd47baae994@mail.gmail.com> <77ead0ec0811210913n1e188090w65ea76d911a38fb1@mail.gmail.com> Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Vishwas, > Thanks about this. Generally speaking we would want to do the > checksum/ hash before we would do anything because unless that is > correct we do not know the sanity of the packet. However the sequence > number itself is like a security mechanism (not to the extent of the > TCP one), as not all numbers are valid. It is a good idea to do some > checks before going in for the CPU heavy hashing mechanism. I agree. >> >> Since this memo deals exclusively with BFD authentication, shouldnt >> you spend some more time detailing how the keys should be managed >> (life associated with key, start time, stop time, etc) - some >> recommendations on the key entropy would also help. > One interesting thing about BFD is that BFD packet counters are 64 ^^^^^^^^ I presume you are talking about the sequence number here and that you really meant 32, and not 64 bits, in the above text. Can you give some computation of the time you think it will take the sequence number space to wrap? -- Toms. From rtg-bfd-bounces@ietf.org Fri Nov 21 16:18:36 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27CCA3A6A6C; Fri, 21 Nov 2008 16:18:36 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6B83A6A6C for ; Fri, 21 Nov 2008 16:18:35 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq7gFtwNvg+m for ; Fri, 21 Nov 2008 16:18:35 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 7A95A3A67AB for ; Fri, 21 Nov 2008 16:18:34 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so884771fga.41 for ; Fri, 21 Nov 2008 16:18:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=/BRUDoK65Yx/LHtowB7itkwf65qof5OdxP5nebSnBTo=; b=JJ7S4qYrwFvpRMYke+2XwLloyStwBbR+6vGRu+tQA4nz46V5LZa5gd3vtXmCb5oguI MDIUmCryUEv39ujJufsbOge7qqsN9+k62+ehqWWJcvMmxO11l1lW+BTIMzsoQlzzy+5j Aw3JO+jYI25ACdGb+CiuXnT1Bl0U6/1QVNTPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=U5epuXX+RXC5gbm0UbLKhrgxXZZ/e41uiXS5dKz2Mv5FCBDAeQdcJ6Lwv03nGVwf4M FL85HZW2fZsuvHujAX14nVyFpFHNdZCS+prK0Ety06c/Ps1j3uVpRlmQIgw7hzW8v0h1 kHWTEO0uv0ttJ1ds+YJWuaptumblgKSrj5oi0= Received: by 10.181.205.15 with SMTP id h15mr63100bkq.19.1227313111365; Fri, 21 Nov 2008 16:18:31 -0800 (PST) Received: by 10.181.24.20 with HTTP; Fri, 21 Nov 2008 16:18:31 -0800 (PST) Message-ID: <77ead0ec0811211618u6c85bbecqe1e075ee77c159ba@mail.gmail.com> Date: Fri, 21 Nov 2008 16:18:31 -0800 From: "Vishwas Manral" To: "Tom Sanders" Subject: Re: BFD Generic Cryptographic Authentication In-Reply-To: <6ed23a860811211610p7760f109u448828bb1c3bb9e7@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD4241965022A9020@INEXC1U01.in.lucent.com> <6ed23a860811202137m6997d3aq72024cd47baae994@mail.gmail.com> <77ead0ec0811210913n1e188090w65ea76d911a38fb1@mail.gmail.com> <6ed23a860811211610p7760f109u448828bb1c3bb9e7@mail.gmail.com> Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Tom, >>> >>> Since this memo deals exclusively with BFD authentication, shouldnt >>> you spend some more time detailing how the keys should be managed >>> (life associated with key, start time, stop time, etc) - some >>> recommendations on the key entropy would also help. >> One interesting thing about BFD is that BFD packet counters are 64 > > ^^^^^^^^ > I presume you are talking about the sequence number here and that you > really meant 32, and not 64 bits, in the above text. No, if you check the MIB packet counters are 64 bits (which is good foresight on the part of the MBI authors). Which means there is an assumption that the packet counts may go higher than 32 bits. > Can you give some computation of the time you think it will take the > sequence number space to wrap? I am sorry I have not done the computation with any real world data and it will depend on the interval at which you send the BFD packets. But with 1 millisecond and 10 neighbors on an interface the counters will wrap in less than 5 days time (for meticulously Keyed sessions). Thanks, Vishwas > -- > Toms. > From rtg-bfd-bounces@ietf.org Fri Nov 21 16:48:31 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F903A690F; Fri, 21 Nov 2008 16:48:31 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F833A690F for ; Fri, 21 Nov 2008 16:48:29 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXEWl9MRc7lM for ; Fri, 21 Nov 2008 16:48:27 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id 441093A6808 for ; Fri, 21 Nov 2008 16:48:27 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so593325wag.5 for ; Fri, 21 Nov 2008 16:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=1zfLrtq6E4Kfrtg9G6QP9FDfMZ842nFaygu1ye5VZ+A=; b=Od88gWG651FqmQSda86sJYYt6clVJ0d/TlF3nV5jL6edRbDaxb4p6yEvJY2XBbqVmF dIbTiyP0yxa9f4ZinBtt9rbyXMWSFZ6EgBwMnTU81/SEzscFRlic5cXfgmQXUP2bgk62 2P8yLyGEqEJ3obTx5VPfnNe1ItaBhpf5y49YU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=MKcFC4Efn2t9uvaYqRXRA0e6QT1iPffGZvCcHw7MB3W+1FdzkOzto+CGGeXZjhfBVU yS9JQsSDDU4rhnuW1PxJMnbjXmiIjrVgogY7hsa7fti8WSJ9dDp0Vi3ZC2c4NV1QHUG4 DHG4/vbJrB0v4MgfX4ql8LlulhBwrkKIzywZ8= Received: by 10.114.127.1 with SMTP id z1mr624996wac.3.1227314905674; Fri, 21 Nov 2008 16:48:25 -0800 (PST) Received: by 10.115.48.9 with HTTP; Fri, 21 Nov 2008 16:48:25 -0800 (PST) Message-ID: <6ed23a860811211648t20bda582l61e59715f9c85d8e@mail.gmail.com> Date: Sat, 22 Nov 2008 06:18:25 +0530 From: "Tom Sanders" To: "Vishwas Manral" Subject: Re: BFD Generic Cryptographic Authentication In-Reply-To: <77ead0ec0811211618u6c85bbecqe1e075ee77c159ba@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD4241965022A9020@INEXC1U01.in.lucent.com> <6ed23a860811202137m6997d3aq72024cd47baae994@mail.gmail.com> <77ead0ec0811210913n1e188090w65ea76d911a38fb1@mail.gmail.com> <6ed23a860811211610p7760f109u448828bb1c3bb9e7@mail.gmail.com> <77ead0ec0811211618u6c85bbecqe1e075ee77c159ba@mail.gmail.com> Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Vishwas, > No, if you check the MIB packet counters are 64 bits (which is good > foresight on the part of the MBI authors). Which means there is an > assumption that the packet counts may go higher than 32 bits. > >> Can you give some computation of the time you think it will take the >> sequence number space to wrap? > I am sorry I have not done the computation with any real world data > and it will depend on the interval at which you send the BFD packets. > But with 1 millisecond and 10 neighbors on an interface the counters > will wrap in less than 5 days time (for meticulously Keyed sessions). Sounds reasonable. Why dont you increase the sequence number space to 64 bits in the new authentication types that you have defined in your draft? -- Toms. From rtg-bfd-bounces@ietf.org Fri Nov 21 18:26:58 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38EB43A6808; Fri, 21 Nov 2008 18:26:58 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFC163A6808 for ; Fri, 21 Nov 2008 18:26:56 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dsBypLoMZl9J for ; Fri, 21 Nov 2008 18:26:56 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by core3.amsl.com (Postfix) with ESMTP id 92D573A67B6 for ; Fri, 21 Nov 2008 18:26:55 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so1302367fkq.5 for ; Fri, 21 Nov 2008 18:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ym0XZGQN0brOi86/NeJwb5T06NSgYQKfKW4kM7iTr84=; b=t7VLqcZlZ/yH5CANHekTLvXUBpU1FumVqf4iyY4JGx/iEXVjeWwQglk+iYzrs0tEGI j5FuXNlohkBYritiyQ/gxZUYzp83KSL/4bzZiuVwCi/tfcpvI0zzMnB33Jk5O22EwZGW 1rMY8Q4PbW2ogEtir9hyTsRV7RYriYJfGv14Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=GfgDrkmiLOTh2RwE65Z9aOzVMaj5fWfK5UYsbE5g0zgtdThUDNAITmVPmUEccW8ZQO zQD7BsznLonycrfIwW0R216XGM3anrefrnk+wGV6naHK15FbVvlWqi7jVoDoOJtDeWGB F6NMma6mV4IkyjAi3FauZiTOoamkQMl56mHi4= Received: by 10.181.235.6 with SMTP id m6mr329132bkr.131.1227320811674; Fri, 21 Nov 2008 18:26:51 -0800 (PST) Received: by 10.181.24.20 with HTTP; Fri, 21 Nov 2008 18:26:51 -0800 (PST) Message-ID: <77ead0ec0811211826m62f3a9cfucff69d84506f673e@mail.gmail.com> Date: Fri, 21 Nov 2008 18:26:51 -0800 From: "Vishwas Manral" To: "Tom Sanders" Subject: Re: BFD Generic Cryptographic Authentication In-Reply-To: <6ed23a860811211648t20bda582l61e59715f9c85d8e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD4241965022A9020@INEXC1U01.in.lucent.com> <6ed23a860811202137m6997d3aq72024cd47baae994@mail.gmail.com> <77ead0ec0811210913n1e188090w65ea76d911a38fb1@mail.gmail.com> <6ed23a860811211610p7760f109u448828bb1c3bb9e7@mail.gmail.com> <77ead0ec0811211618u6c85bbecqe1e075ee77c159ba@mail.gmail.com> <6ed23a860811211648t20bda582l61e59715f9c85d8e@mail.gmail.com> Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Tom, Thanks for the suggestion. Yes we can add that too. Thanks again, Vishwas On Fri, Nov 21, 2008 at 4:48 PM, Tom Sanders wrote: > Vishwas, > >> No, if you check the MIB packet counters are 64 bits (which is good >> foresight on the part of the MBI authors). Which means there is an >> assumption that the packet counts may go higher than 32 bits. >> >>> Can you give some computation of the time you think it will take the >>> sequence number space to wrap? >> I am sorry I have not done the computation with any real world data >> and it will depend on the interval at which you send the BFD packets. >> But with 1 millisecond and 10 neighbors on an interface the counters >> will wrap in less than 5 days time (for meticulously Keyed sessions). > > Sounds reasonable. Why dont you increase the sequence number space to > 64 bits in the new authentication types that you have defined in your > draft? > > -- > Toms. > From rtg-bfd-bounces@ietf.org Sat Nov 22 02:09:19 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F39C73A684F; Sat, 22 Nov 2008 02:09:18 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39AD03A684F for ; Sat, 22 Nov 2008 02:09:14 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSLLsKTLuw77 for ; Sat, 22 Nov 2008 02:09:08 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id B17DB3A676A for ; Sat, 22 Nov 2008 02:09:07 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id mAMA93TO000488; Sat, 22 Nov 2008 04:09:03 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Nov 2008 04:09:03 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Nov 2008 15:39:00 +0530 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 Subject: RE: BFD Generic Cryptographic Authentication Date: Sat, 22 Nov 2008 15:39:01 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD42419650235636B@INEXC1U01.in.lucent.com> In-Reply-To: <6ed23a860811202137m6997d3aq72024cd47baae994@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD Generic Cryptographic Authentication thread-index: AclLm5uV3GyGmzIZRK+DqDE++WmHjgA7bhiw References: <6D26D1FE43A66F439F8109CDD4241965022A9020@INEXC1U01.in.lucent.com> <6ed23a860811202137m6997d3aq72024cd47baae994@mail.gmail.com> From: "Bhatia, Manav \(Manav\)" To: "Tom Sanders" X-OriginalArrivalTime: 22 Nov 2008 10:09:00.0322 (UTC) FILETIME=[56DBE820:01C94C8A] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Tom, > I think its a step in the right direction. >=20 [..] > I believe this is something very fundamental in how the security ought > to be designed for the internet protocols. You dont want to compute > the hash/digest, only to later discard the packet because some other > parameter isnt what you expected it to be (in this case the sequence > number). And this becomes all the more accentuated in case of BFD as > this byte crunching may be happening in the line cards. Good catch > indeed! Thanks for the review. =20 > You should add a section on BFD too in > draft-ietf-opsec-routing-protocols-crypto-issues-00.txt besides PIM, This needs to be taken up in OPSEC and if the folks there feel that its worth including a section on BFD then it can certainly be done.=20 [..] >=20 > Since this memo deals exclusively with BFD authentication, shouldnt > you spend some more time detailing how the keys should be managed > (life associated with key, start time, stop time, etc) - some We can add some text to this effect in the next cut. > recommendations on the key entropy would also help. Regarding the entropy we have the following text in the draft (section 2): Care should also be taken to ensure that the selected key is unpredictable, avoiding any keys known to be weak for the algorithm in use. [RFC4086] contains helpful information on both key generation techniques and cryptographic randomness.=20 [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.=20 Is there something specific that you're looking at? Cheers, Manav >=20 > --=20 > Toms. >=20 From rtg-bfd-bounces@ietf.org Sat Nov 22 17:33:41 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DE703A6941; Sat, 22 Nov 2008 17:33:41 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30A293A6941 for ; Sat, 22 Nov 2008 17:33:40 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zg6IVI6uDxIv for ; Sat, 22 Nov 2008 17:33:39 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 6974C3A68FC for ; Sat, 22 Nov 2008 17:33:38 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mAN1XYwo013193 for ; Sat, 22 Nov 2008 19:33:34 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 22 Nov 2008 19:33:33 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Nov 2008 07:03:29 +0530 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 Subject: TTL/Hop Limit Issues in BFD for on a single hop Date: Sun, 23 Nov 2008 07:03:28 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356386@INEXC1U01.in.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TTL/Hop Limit Issues in BFD for on a single hop thread-index: AclNC3yoOURWhcuUTOKCHJDsTpV6KQ== From: "Bhatia, Manav \(Manav\)" To: X-OriginalArrivalTime: 23 Nov 2008 01:33:29.0458 (UTC) FILETIME=[7D0A5D20:01C94D0B] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi, This is wrt the text in Section 5 of draft-ietf-bfd-v4v6-1hop-08.txt. It states that that BFD Control packets for the session MUST be sent with a TTL or Hop Limit value of 255 irrespective of whether BFD auth is being used or not. Fair enough. Now why is it that when auth is being used the recover *MAY* (and not MUST) reject BFD control packets received with TTL/Hop Limit value other than 255? Why is it not a "MUST" the way it is for un-authenticated sessions? Second, the draft should unequivocally state that the sanity of TTL/Hop Limit MUST be checked first before the authentication data is verified. You don't want the receiver to compute the hash only to later drop the packet because the TTL/Hop limit was incorrect or not within the acceptable range. Cheers, Manav -- Manav Bhatia, IP Division, Alcatel-Lucent, Bangalore - India =20 From rtg-bfd-bounces@ietf.org Sun Nov 23 21:00:58 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D4A28C13B; Sun, 23 Nov 2008 21:00:58 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9CC28C13B for ; Sun, 23 Nov 2008 21:00:57 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3D5flbq5FQl for ; Sun, 23 Nov 2008 21:00:57 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id DAA8928C0E9 for ; Sun, 23 Nov 2008 21:00:56 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mAO50lO4013509; Sun, 23 Nov 2008 23:00:47 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 23 Nov 2008 23:00:47 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 10:30:43 +0530 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 Subject: RE: BFD Generic Cryptographic Authentication Date: Mon, 24 Nov 2008 10:30:42 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD4241965023563DB@INEXC1U01.in.lucent.com> In-Reply-To: <6ed23a860811211648t20bda582l61e59715f9c85d8e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD Generic Cryptographic Authentication thread-index: AclMPAmSgmIjEzFoSsu4X8/Tkn+pSgBmKHFw References: <6D26D1FE43A66F439F8109CDD4241965022A9020@INEXC1U01.in.lucent.com> <6ed23a860811202137m6997d3aq72024cd47baae994@mail.gmail.com> <77ead0ec0811210913n1e188090w65ea76d911a38fb1@mail.gmail.com> <6ed23a860811211610p7760f109u448828bb1c3bb9e7@mail.gmail.com> <77ead0ec0811211618u6c85bbecqe1e075ee77c159ba@mail.gmail.com> <6ed23a860811211648t20bda582l61e59715f9c85d8e@mail.gmail.com> From: "Bhatia, Manav \(Manav\)" To: "Tom Sanders" , "Vishwas Manral" X-OriginalArrivalTime: 24 Nov 2008 05:00:43.0462 (UTC) FILETIME=[9AB28E60:01C94DF1] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Tom, > > I am sorry I have not done the computation with any real world data > > and it will depend on the interval at which you send the=20 > BFD packets. > > But with 1 millisecond and 10 neighbors on an interface the counters > > will wrap in less than 5 days time (for meticulously Keyed=20 > sessions). >=20 > Sounds reasonable. Why don't you increase the sequence number space to > 64 bits in the new authentication types that you have defined in your > draft? You don't really need to send 64 bits in the BFD packet.=20 We could have an extended cryptographic sequence number (ECSN) of 64 bits, where only the low-order 32 bits are transmitted in each packet. The high-order 32 bits would be maintained as part of the sequence number counter by both sender and receiver, and would be included in the computation of the authentication data to prevent replay attacks. Cheers, Manav >=20 > --=20 > Toms. >=20 From rtg-bfd-bounces@ietf.org Sun Nov 23 21:02:39 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C7828C13B; Sun, 23 Nov 2008 21:02:39 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A50FD28C13B for ; Sun, 23 Nov 2008 21:02:38 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fh5gjPIzWmiU for ; Sun, 23 Nov 2008 21:02:38 -0800 (PST) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 54BFA28C0E9 for ; Sun, 23 Nov 2008 21:02:35 -0800 (PST) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKSSo1aGK+kvli5A2EXV4pb6qULVbY0xNU@postini.com; Sun, 23 Nov 2008 21:02:36 PST Received: from emailcorp3.jnpr.net ([66.129.254.13]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 23 Nov 2008 21:01:51 -0800 Received: from 172.24.241.7 ([172.24.241.7]) by emailcorp3.jnpr.net ([66.129.254.13]) with Microsoft Exchange Server HTTP-DAV ; Mon, 24 Nov 2008 05:01:50 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Sun, 23 Nov 2008 21:01:38 -0800 Subject: Re: TTL/Hop Limit Issues in BFD for on a single hop From: Nitin Bahadur To: "Bhatia, Manav (Manav)" , Message-ID: Thread-Topic: TTL/Hop Limit Issues in BFD for on a single hop Thread-Index: AclNC3yoOURWhcuUTOKCHJDsTpV6KQA5j6Mw In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356386@INEXC1U01.in.lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Nov 2008 05:01:51.0667 (UTC) FILETIME=[C359D030:01C94DF1] X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org > Second, the draft should unequivocally state that the sanity of TTL/Hop > Limit MUST be checked first before the authentication data is verified. > You don't want the receiver to compute the hash only to later drop the > packet because the TTL/Hop limit was incorrect or not within the > acceptable range. The above is an implementation optimization. I don't see any need for the spec to specify that. The spec should not dictate implementation details. Someone could design a system that does MD5/SHA1 checksums in hardware and in that case they might end up running the hash first.....and if you change the spec, then that implementation will be out of spec. Thanks Nitin From rtg-bfd-bounces@ietf.org Sun Nov 23 23:38:18 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59EE63A679F; Sun, 23 Nov 2008 23:38:18 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98A173A679F for ; Sun, 23 Nov 2008 23:38:17 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2lD8o-W70uR for ; Sun, 23 Nov 2008 23:38:17 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id D9C7B3A6405 for ; Sun, 23 Nov 2008 23:38:16 -0800 (PST) Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id mAO7cBk4008533; Mon, 24 Nov 2008 01:38:12 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 01:38:11 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.25]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Nov 2008 13:08:07 +0530 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 Subject: RE: TTL/Hop Limit Issues in BFD for on a single hop Date: Mon, 24 Nov 2008 13:08:06 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD42419650235644E@INEXC1U01.in.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TTL/Hop Limit Issues in BFD for on a single hop thread-index: AclNC3yoOURWhcuUTOKCHJDsTpV6KQA5j6MwAABcsVA= References: <6D26D1FE43A66F439F8109CDD424196502356386@INEXC1U01.in.lucent.com> From: "Bhatia, Manav \(Manav\)" To: "Nitin Bahadur" , X-OriginalArrivalTime: 24 Nov 2008 07:38:07.0351 (UTC) FILETIME=[97B1A870:01C94E07] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Fair enough. How about a milder "MAY" to help the guileless implementations then? Cheers, Manav > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 > Sent: Monday, November 24, 2008 10.32 AM > To: Bhatia, Manav (Manav); rtg-bfd@ietf.org > Subject: Re: TTL/Hop Limit Issues in BFD for on a single hop >=20 >=20 > > Second, the draft should unequivocally state that the=20 > sanity of TTL/Hop > > Limit MUST be checked first before the authentication data=20 > is verified. > > You don't want the receiver to compute the hash only to=20 > later drop the > > packet because the TTL/Hop limit was incorrect or not within the > > acceptable range. >=20 > The above is an implementation optimization. I don't see any=20 > need for the > spec to specify that. The spec should not dictate=20 > implementation details. > Someone could design a system that does MD5/SHA1 checksums in=20 > hardware and > in that case they might end up running the hash first.....and=20 > if you change > the spec, then that implementation will be out of spec. >=20 > Thanks > Nitin >=20 >=20 From rtg-bfd-bounces@ietf.org Wed Nov 26 09:57:02 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DB6A28C1E4; Wed, 26 Nov 2008 09:57:02 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B35A128C1E4 for ; Wed, 26 Nov 2008 09:57:00 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nWB7uKgphhWt for ; Wed, 26 Nov 2008 09:57:00 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id A741928C1BD for ; Wed, 26 Nov 2008 09:56:59 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so369973fga.41 for ; Wed, 26 Nov 2008 09:56:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=PLNvU/xV3SYv7uXx6ia0pxHa310zg/YIr40wcjh+QqY=; b=RRSewI0Uov/Xpw2QuBl/PnhFE+65KgF5+dIODLkiE0pR//xJ1EWpYxTHAU+1xqH8XN /NTuPLeiO+46tVcXm2JI96seIZTGlae/piNcqSDIngeulawLtMLDyiGIZaVhwBS8PqVY YZS1VPCE4SR7FPFIfBAULpBmpffF5eyVMIQZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=e5movJMV6UiB3XkPggy+wOqAvvA/GUA2sTc2I83qN6JQewtlhaVlJhQmmMnmrPOozh LTk1Fzdmvcp7mZ0o6ApGHckx3fifnyeWfBewYxw8JbHgBPwj4BtFjYJVW7VcMjFeqiTe xMBFoXQQgMOMumlzMG/h5G7OzfCuPVD8L+T9U= Received: by 10.180.242.5 with SMTP id p5mr2024456bkh.178.1227722216436; Wed, 26 Nov 2008 09:56:56 -0800 (PST) Received: by 10.181.147.16 with HTTP; Wed, 26 Nov 2008 09:56:56 -0800 (PST) Message-ID: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> Date: Wed, 26 Nov 2008 09:56:56 -0800 From: "Vishwas Manral" To: "David Ward" , "Dave Katz" , "Nitin Bahadur" Subject: BFD echo mode MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Dave/ Nitin, I was wondering how the echo mode would actually work for BFD as the specification does not seem to specify the same. I looked up the archive and got the link http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00216.html. Seeing some vendor documentation it seems they use a seperate port for the echo mode - as the source and the destination address. Assuming the forwarding path just loops back the packet by swapping the source and destination address/ port. How would an echo (request) be distinguished from an echo reply. Can the asusmption that the echo mode packet is a BFD packet be made (so the BFD source / dest packet identifiers can be used)? The base BFD spec seems to state the content of the packet need not be specified as the packet is just looped back. Thanks, Vishwas From rtg-bfd-bounces@ietf.org Wed Nov 26 10:34:48 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B07C28C228; Wed, 26 Nov 2008 10:34:48 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464223A6836 for ; Wed, 26 Nov 2008 10:34:46 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPFAHYBVWODA for ; Wed, 26 Nov 2008 10:34:45 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1A6DC28C1BD for ; Wed, 26 Nov 2008 10:34:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,670,1220227200"; d="scan'208";a="29172916" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 26 Nov 2008 18:34:41 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAQIYecw008288; Wed, 26 Nov 2008 13:34:40 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAQIYeoC010461; Wed, 26 Nov 2008 18:34:40 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 13:34:40 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 13:34:01 -0500 In-Reply-To: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> References: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F3460B3-2D98-430A-9108-413574FA1C2B@cisco.com> Content-Transfer-Encoding: 7bit From: David Ward Subject: Re: BFD echo mode Date: Wed, 26 Nov 2008 12:33:59 -0600 To: "Vishwas Manral" X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 26 Nov 2008 18:34:01.0783 (UTC) FILETIME=[8D96EC70:01C94FF5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1191; t=1227724480; x=1228588480; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20BFD=20echo=20mode |Sender:=20 |To:=20=22Vishwas=20Manral=22=20; bh=qC3dB/lMoLMGv+e3RJiyqqu7vswzGPRK/C1bO3h3a00=; b=o728riF0NztU1dR/lvVz892M7mFH8tJTxcrAfffk1EsjTT4+DudvfLup8b hW+GX+GquKEUBifF2ji/2cuhMvV08d4Au4fEQTWHX3jQQWiP2ZJACXoake/7 1BRGqra91b; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: rtg-bfd@ietf.org, David Ward , Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Vishwas - On Nov 26, 2008, at 11:56 AM, Vishwas Manral wrote: > Hi Dave/ Nitin, > > I was wondering how the echo mode would actually work for BFD as the > specification does not seem to specify the same. I looked up the > archive and got the link > http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00216.html. > > Seeing some vendor documentation it seems they use a seperate port for > the echo mode - as the source and the destination address. Assuming > the forwarding path just loops back the packet by swapping the source > and destination address/ port. DW: There is no swapping of values required > How would an echo (request) be > distinguished from an echo reply. > DW: There are no echo request/reply semantics in BFD. > Can the asusmption that the echo mode packet is a BFD packet be made > (so the BFD source / dest packet identifiers can be used)? The base > BFD spec seems to state the content of the packet need not be > specified as the packet is just looped back. > DW: An implementation sets the src from itself and dest to itself. No swapping and no need to look at any contents. -DWard > Thanks, > Vishwas From rtg-bfd-bounces@ietf.org Wed Nov 26 11:49:34 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081F63A69A2; Wed, 26 Nov 2008 11:49:34 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37C53A69A2 for ; Wed, 26 Nov 2008 11:49:33 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXNme78EOz2G for ; Wed, 26 Nov 2008 11:49:32 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by core3.amsl.com (Postfix) with ESMTP id 7213B3A68AD for ; Wed, 26 Nov 2008 11:49:32 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so549015fkq.5 for ; Wed, 26 Nov 2008 11:49:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=lz1rXkVGU/XnSVjyLLhp7PUJBMMeBJvFh09D9u0OL+M=; b=MvZklahZpZ0RW8d1diRof5AQZWLAHfvCFNW5qbvYRBozUnCHTrUsF3/wU6eEOoRkU+ m4Pp/2Dhm72ZfZ3pqC69DW6DLldLqUuBE0faa8DJDZruivrzF00jSlvZCKNpKVhe5qN6 8pbsqA8uIvRmg0v1fiWJBWPar8IWXW2DYgQgg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=X4r57WjcfllKnCbupFKpWRVChYKSr783exDm3QM8pkZ8OmthOnmjrxhynjfeihaqah 4WVv81Ko3VOikWMf4bVq7sI8eBcKfvsizTBe6hMK/pRzTzEG/fn3I6A9ljXbdstt0KTa EFv+h/o/oKepaYk67cTokTfebC67LZ8Ckv99U= Received: by 10.181.148.3 with SMTP id a3mr2066317bko.74.1227728969077; Wed, 26 Nov 2008 11:49:29 -0800 (PST) Received: by 10.181.147.16 with HTTP; Wed, 26 Nov 2008 11:49:29 -0800 (PST) Message-ID: <77ead0ec0811261149t41a462e9g194caff7738ae681@mail.gmail.com> Date: Wed, 26 Nov 2008 11:49:29 -0800 From: "Vishwas Manral" To: "David Ward" Subject: Re: BFD echo mode In-Reply-To: <1F3460B3-2D98-430A-9108-413574FA1C2B@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> <1F3460B3-2D98-430A-9108-413574FA1C2B@cisco.com> Cc: rtg-bfd@ietf.org, Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Dave, Thanks for the reply. I am still a bit confused? So I can see how we could look an IP packet in the case of Single Hop (by having the MAC Destination Address of the peer) but having IP address and destination the same (as of the source). However we would not have a mechanism to loop packet in the case of multihop (unless we are using) unless we use source hop options (thus defining the hops). That said as the mechanism itself is not defined, how can a peer say it supports the Echo-mode, which is necessary for the Echo-mode to work? Thanks again, Vishwas On Wed, Nov 26, 2008 at 10:33 AM, David Ward wrote: > Vishwas - > > > On Nov 26, 2008, at 11:56 AM, Vishwas Manral wrote: > >> Hi Dave/ Nitin, >> >> I was wondering how the echo mode would actually work for BFD as the >> specification does not seem to specify the same. I looked up the >> archive and got the link >> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00216.html. >> >> Seeing some vendor documentation it seems they use a seperate port for >> the echo mode - as the source and the destination address. Assuming >> the forwarding path just loops back the packet by swapping the source >> and destination address/ port. > > DW: There is no swapping of values required > > >> How would an echo (request) be >> distinguished from an echo reply. >> > > DW: There are no echo request/reply semantics in BFD. > > >> Can the asusmption that the echo mode packet is a BFD packet be made >> (so the BFD source / dest packet identifiers can be used)? The base >> BFD spec seems to state the content of the packet need not be >> specified as the packet is just looped back. >> > > DW: An implementation sets the src from itself and dest to itself. No > swapping and no need to look at any contents. > > -DWard > > > >> Thanks, >> Vishwas > > From rtg-bfd-bounces@ietf.org Wed Nov 26 12:45:25 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF6C628C14E; Wed, 26 Nov 2008 12:45:25 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F0793A69AD for ; Wed, 26 Nov 2008 12:45:25 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85leb0CNZ5Kx for ; Wed, 26 Nov 2008 12:45:24 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3C4C63A6767 for ; Wed, 26 Nov 2008 12:45:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,670,1220227200"; d="scan'208";a="29187910" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 26 Nov 2008 20:45:21 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAQKjLGV000783; Wed, 26 Nov 2008 15:45:21 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAQKjHne022853; Wed, 26 Nov 2008 20:45:21 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 15:45:19 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Nov 2008 15:45:05 -0500 In-Reply-To: <77ead0ec0811261149t41a462e9g194caff7738ae681@mail.gmail.com> References: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> <1F3460B3-2D98-430A-9108-413574FA1C2B@cisco.com> <77ead0ec0811261149t41a462e9g194caff7738ae681@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C698ABF-FDED-4046-878E-CAEA6E278249@cisco.com> Content-Transfer-Encoding: 7bit From: David Ward Subject: Re: BFD echo mode Date: Wed, 26 Nov 2008 14:45:05 -0600 To: Vishwas Manral X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 26 Nov 2008 20:45:05.0639 (UTC) FILETIME=[DCD01F70:01C95007] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2127; t=1227732321; x=1228596321; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20BFD=20echo=20mode |Sender:=20 |To:=20Vishwas=20Manral=20; bh=+R1VvDL6IxaXIfwe2k3+pssxIsdrF8u5kNYbRvI0imU=; b=tWdpvwmnwlv6esMmqp20zl+mL2sBKlnDUZejG2FolUQ+fBJdWqRTCqVKSF 9sa7ceCJO4rppAm5EOiLgqQ7tT8gGRtAp9wnDjqi8bhQ7gcB6+DzOUY8dnRT BA60mIqnR6; Authentication-Results: rtp-dkim-2; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: rtg-bfd@ietf.org, David Ward , Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org The spec will be updated that MH echo is not recommended. -DWard On Nov 26, 2008, at 1:49 PM, Vishwas Manral wrote: > Hi Dave, > > Thanks for the reply. I am still a bit confused? > > So I can see how we could look an IP packet in the case of Single Hop > (by having the MAC Destination Address of the peer) but having IP > address and destination the same (as of the source). > > However we would not have a mechanism to loop packet in the case of > multihop (unless we are using) unless we use source hop options (thus > defining the hops). > > That said as the mechanism itself is not defined, how can a peer say > it supports the Echo-mode, which is necessary for the Echo-mode to > work? > > Thanks again, > Vishwas > > On Wed, Nov 26, 2008 at 10:33 AM, David Ward wrote: >> Vishwas - >> >> >> On Nov 26, 2008, at 11:56 AM, Vishwas Manral wrote: >> >>> Hi Dave/ Nitin, >>> >>> I was wondering how the echo mode would actually work for BFD as the >>> specification does not seem to specify the same. I looked up the >>> archive and got the link >>> http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00216.html. >>> >>> Seeing some vendor documentation it seems they use a seperate >>> port for >>> the echo mode - as the source and the destination address. Assuming >>> the forwarding path just loops back the packet by swapping the >>> source >>> and destination address/ port. >> >> DW: There is no swapping of values required >> >> >>> How would an echo (request) be >>> distinguished from an echo reply. >>> >> >> DW: There are no echo request/reply semantics in BFD. >> >> >>> Can the asusmption that the echo mode packet is a BFD packet be made >>> (so the BFD source / dest packet identifiers can be used)? The base >>> BFD spec seems to state the content of the packet need not be >>> specified as the packet is just looped back. >>> >> >> DW: An implementation sets the src from itself and dest to itself. No >> swapping and no need to look at any contents. >> >> -DWard >> >> >> >>> Thanks, >>> Vishwas >> >> From rtg-bfd-bounces@ietf.org Thu Nov 27 01:42:25 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40D263A6CCF; Thu, 27 Nov 2008 01:42:25 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5548F3A6CCF for ; Thu, 27 Nov 2008 01:42:24 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUFdJQmEJj88 for ; Thu, 27 Nov 2008 01:42:23 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 82ADC3A67E9 for ; Thu, 27 Nov 2008 01:42:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,674,1220227200"; d="scan'208";a="110789953" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 27 Nov 2008 09:41:53 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id mAR9fqIT027955; Thu, 27 Nov 2008 01:41:52 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id mAR9fm1k008858; Thu, 27 Nov 2008 09:41:52 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 01:41:52 -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 Subject: RE: BFD echo mode Date: Thu, 27 Nov 2008 01:41:11 -0800 Message-ID: In-Reply-To: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD echo mode Thread-Index: AclP8GNH/wXPju4nTCy2/AtmdLVmZQAgfngg References: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> From: "Nobo Akiya (nobo)" To: "Vishwas Manral" , "David Ward" , "Dave Katz" , "Nitin Bahadur" X-OriginalArrivalTime: 27 Nov 2008 09:41:52.0810 (UTC) FILETIME=[60DA08A0:01C95074] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1286; t=1227778913; x=1228642913; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=nobo@cisco.com; z=From:=20=22Nobo=20Akiya=20(nobo)=22=20 |Subject:=20RE=3A=20BFD=20echo=20mode |Sender:=20; bh=A1jTiAer6aJHeVRRAAp4+A4DO1Zj5L1whAP+jXFd1LY=; b=fv3Lk86oMrp+rFzcbYMsIvPhhzm/ASmMgqf1xBLMXeU+uP9UmmpBn1XNAK QSJ8jE8H22dsjF2qtlVEMPg6gizPiuBw9othf/3D3zTWf+H94ay79Tpci91X Ahi8CN2v87; Authentication-Results: sj-dkim-3; header.From=nobo@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org =20 Hello Vishwas. Couple of add-on comments, for single-hop. > Seeing some vendor documentation it seems they use a seperate=20 > port for the echo mode - as the source and the destination=20 > address. I hope vendors aren't using different udp dest port for echo packets. http://tools.ietf.org/html/draft-ietf-bfd-v4v6-1hop-08 Sec4.1. BFD Echo packets MUST be transmitted in UDP packets with destination UDP port 3785 in an IPv4 packet. > Can the asusmption that the echo mode packet is a BFD packet=20 > be made (so the BFD source / dest packet identifiers can be=20 > used)? The base BFD spec seems to state the content of the=20 > packet need not be specified as the packet is just looped back. BFD echo packets can be identified by UDP dest port 3785. Data beyond UDP header is not specified, and that's left up to vendors. > So I can see how we could look an IP packet in the case of=20 > Single Hop (by having the MAC Destination Address of the=20 > peer) but having IP address and destination the same (as of=20 > the source). I don't think there's anything that specifies that dest & src addresses must be the same. For dest addresses tho, it maybe easier to demultiplex if dest address is the outgoing interface. Thanx, Nobo =20 From rtg-bfd-bounces@ietf.org Thu Nov 27 05:51:52 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE533A68C3; Thu, 27 Nov 2008 05:51:52 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FE083A68C3 for ; Thu, 27 Nov 2008 05:51:51 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpQCOnHn503H for ; Thu, 27 Nov 2008 05:51:50 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by core3.amsl.com (Postfix) with ESMTP id 8AB7E3A6832 for ; Thu, 27 Nov 2008 05:51:48 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so912589fkq.5 for ; Thu, 27 Nov 2008 05:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Ffxfyj0kU6YKc+nsseUAKMyByz41h0qh8wCwR83fIxk=; b=G6wvdzbZMj9Yes9KQjLbMyxuKglKQN5QdHcjJGQvPKva9anyIMl+81rUH7c87Ky3s9 uN1qDrxEK5T0chnJMhIFKRS8T6VaKqFrPQ8/NX6/FUVIU1pTPyMMQ23UuACxRrhh0oBq KrvexFakGmWlaWXYx0Tpfom9Pgsg7W8JYokxk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=GXNFETS//VdIzAeeEYfF6P1PiC13qBTnBbbaKOjSLeEIaG+yL12dJFjPB3fHdYMoPA ZtDEeW9T/FqR9b37Pip7B7tUo+YpxszJrKXKextiUbFhhfk5XNB3e0iO/+9C6Xt8RCb4 oY4p1AI6L5HjspXB/Kisy3yGeD8UqnspqeQ/s= Received: by 10.181.56.1 with SMTP id i1mr1098728bkk.45.1227793903651; Thu, 27 Nov 2008 05:51:43 -0800 (PST) Received: by 10.181.147.16 with HTTP; Thu, 27 Nov 2008 05:51:43 -0800 (PST) Message-ID: <77ead0ec0811270551r71741f18gad85e5189800dd71@mail.gmail.com> Date: Thu, 27 Nov 2008 05:51:43 -0800 From: "Vishwas Manral" To: "Nobo Akiya (nobo)" Subject: Re: BFD echo mode In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> Cc: rtg-bfd@ietf.org, David Ward , Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Nobo, >> Seeing some vendor documentation it seems they use a seperate >> port for the echo mode - as the source and the destination >> address. > > I hope vendors aren't using different udp dest port for echo packets. > > http://tools.ietf.org/html/draft-ietf-bfd-v4v6-1hop-08 Sec4.1. > > BFD Echo packets MUST be transmitted in UDP packets with destination > UDP port 3785 in an IPv4 packet. Thankf for this. >> Can the asusmption that the echo mode packet is a BFD packet >> be made (so the BFD source / dest packet identifiers can be >> used)? The base BFD spec seems to state the content of the >> packet need not be specified as the packet is just looped back. > > BFD echo packets can be identified by UDP dest port 3785. > Data beyond UDP header is not specified, and that's left up to vendors. > >> So I can see how we could look an IP packet in the case of >> Single Hop (by having the MAC Destination Address of the >> peer) but having IP address and destination the same (as of >> the source). > > I don't think there's anything that specifies that dest & src addresses > must be the same. For dest addresses tho, it maybe easier to > demultiplex if dest address is the outgoing interface. That is correct. I guess you mean the destination IP address in your message above, is that right? Thanks, Vishwas > > From rtg-bfd-bounces@ietf.org Thu Nov 27 06:20:37 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597233A6832; Thu, 27 Nov 2008 06:20:37 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99B8A3A680A for ; Thu, 27 Nov 2008 06:20:36 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bT54sT2p-n3g for ; Thu, 27 Nov 2008 06:20:35 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B191F3A6832 for ; Thu, 27 Nov 2008 06:20:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,675,1220227200"; d="scan'208";a="202719031" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 27 Nov 2008 14:20:33 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAREKXBt018714; Thu, 27 Nov 2008 06:20:33 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id mAREKXE1014882; Thu, 27 Nov 2008 14:20:33 GMT Received: from xmb-sjc-22c.amer.cisco.com ([128.107.191.47]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 06:20:33 -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 Subject: RE: BFD echo mode Date: Thu, 27 Nov 2008 06:12:32 -0800 Message-ID: In-Reply-To: <77ead0ec0811270551r71741f18gad85e5189800dd71@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: BFD echo mode Thread-Index: AclQmEdgdDs1KI/CSu6L9Qw0vcII0wAASgvg References: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> <77ead0ec0811270551r71741f18gad85e5189800dd71@mail.gmail.com> From: "Nobo Akiya (nobo)" To: "Vishwas Manral" X-OriginalArrivalTime: 27 Nov 2008 14:20:33.0070 (UTC) FILETIME=[4EE73CE0:01C9509B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=843; t=1227795633; x=1228659633; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=nobo@cisco.com; z=From:=20=22Nobo=20Akiya=20(nobo)=22=20 |Subject:=20RE=3A=20BFD=20echo=20mode |Sender:=20; bh=h+jTYX0/7wjk76eianJhaURGp8bDl/o/9nXSE1GrfAI=; b=mMY2tj5mIi2QBz6tVSqXzgVAyHVIf/3GF8CgtpXhKpUlrJDSTubzfMb/mT py9FuMFJjIVop86KT1e+m1iwXzKAdgP0ntl03w0/zqMzpuDRfA2IHEv5QQID 1k3GUqt43K; Authentication-Results: sj-dkim-2; header.From=nobo@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: rtg-bfd@ietf.org, David Ward , Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hello Vishwas. > >> So I can see how we could look an IP packet in the case of=20 > Single Hop=20 > >> (by having the MAC Destination Address of the > >> peer) but having IP address and destination the same (as of the=20 > >> source). > > > > I don't think there's anything that specifies that dest & src=20 > > addresses must be the same. For dest addresses tho, it=20 > maybe easier to=20 > > demultiplex if dest address is the outgoing interface. > That is correct. I guess you mean the destination IP address=20 > in your message above, is that right? Yup, I meant destination IP address. Another reason why you should specify the outgoing interfaces' address as the destination IP address is that, with any other local IP address (ex: loopback), echo packet COULD come back via different interface. Thanx, Nobo From rtg-bfd-bounces@ietf.org Thu Nov 27 07:46:03 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E2C63A687E; Thu, 27 Nov 2008 07:46:03 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C1D3A687E for ; Thu, 27 Nov 2008 07:46:02 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5cOx9Ra4gyl for ; Thu, 27 Nov 2008 07:46:01 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9CC693A6832 for ; Thu, 27 Nov 2008 07:46:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,675,1220227200"; d="scan'208";a="29265945" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 27 Nov 2008 15:45:56 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mARFjuIw026555; Thu, 27 Nov 2008 10:45:56 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mARFjuDl017216; Thu, 27 Nov 2008 15:45:56 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 10:45:56 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Nov 2008 10:45:19 -0500 In-Reply-To: References: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <100B46D2-FC38-4E33-879A-61F0217CC83D@cisco.com> Content-Transfer-Encoding: 7bit From: David Ward Subject: Re: BFD echo mode Date: Thu, 27 Nov 2008 09:45:17 -0600 To: "Nobo Akiya (nobo)" X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 27 Nov 2008 15:45:19.0585 (UTC) FILETIME=[26B3D510:01C950A7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1478; t=1227800756; x=1228664756; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20BFD=20echo=20mode |Sender:=20 |To:=20=22Nobo=20Akiya=20(nobo)=22=20; bh=K/QE3kfPGiNI0b0b3rS679jg+6/OvwqZ1PPFtk3VxOo=; b=szhbdu1XeQgjDAEfwHHa+HqVnzUQGuisPfw+Z9f3u1fWar4HYJgCKh8mWr WWeaEYGyh37F/A/NAub9EhFxBXoGZaC6BHsrJFn3ajRt+pXAaSTYFFOPYowL wThM4V6ojh; Authentication-Results: rtp-dkim-2; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: rtg-bfd@ietf.org, David Ward , Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Nobo - On Nov 27, 2008, at 3:41 AM, Nobo Akiya (nobo) wrote: > > Hello Vishwas. > > Couple of add-on comments, for single-hop. > >> Seeing some vendor documentation it seems they use a seperate >> port for the echo mode - as the source and the destination >> address. > > I hope vendors aren't using different udp dest port for echo packets. > > http://tools.ietf.org/html/draft-ietf-bfd-v4v6-1hop-08 Sec4.1. > > BFD Echo packets MUST be transmitted in UDP packets with destination > UDP port 3785 in an IPv4 packet. > >> Can the asusmption that the echo mode packet is a BFD packet >> be made (so the BFD source / dest packet identifiers can be >> used)? The base BFD spec seems to state the content of the >> packet need not be specified as the packet is just looped back. > > BFD echo packets can be identified by UDP dest port 3785. > Data beyond UDP header is not specified, and that's left up to > vendors. > >> So I can see how we could look an IP packet in the case of >> Single Hop (by having the MAC Destination Address of the >> peer) but having IP address and destination the same (as of >> the source). > > I don't think there's anything that specifies that dest & src > addresses > must be the same. For dest addresses tho, it maybe easier to > demultiplex if dest address is the outgoing interface. DW: there is nothing in the spec that says the addrs have to be the same. -DWard > > Thanx, > Nobo > From rtg-bfd-bounces@ietf.org Sun Nov 30 11:14:51 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293DD3A6A5F; Sun, 30 Nov 2008 11:14:51 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 671163A6A4F for ; Sun, 30 Nov 2008 11:14:49 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKagq6AhGq-I for ; Sun, 30 Nov 2008 11:14:48 -0800 (PST) Received: from mail-fx0-f19.google.com (mail-fx0-f19.google.com [209.85.220.19]) by core3.amsl.com (Postfix) with ESMTP id 2E8613A68E7 for ; Sun, 30 Nov 2008 11:14:48 -0800 (PST) Received: by fxm12 with SMTP id 12so72604fxm.13 for ; Sun, 30 Nov 2008 11:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=XD369yjmRKneA/pMvqHM+v/7RAoMLUMArKiTn2KfNzc=; b=jbjMhF25zvsPxi/svVKm6xREMPeBJqf1RCKxrrqLAHknf2uR4mnFMqiwrN2Oh46TqZ SL8JkJ0aAr9LTfSHOH3w4K1F5CNBR2ibOIwrisEEdwsr9HqActyI8a3ejMaArTs/Ep8C qyOKLWPiaK/7DDMWW3jxq5lpRgrc8CC1yFK/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=lj4XM29MSB+8bAmjNLxjIFDy7kVwu0Kx/sTttqTOa6P+2/lVoZG8XGKcM7ek04nwoZ nDKqhV+xumnT77VOBhTTgjDn/JdlGcguMzyQ9MrEWo/nFF/e//GV7/FDHyjnvgVk1o5X 7kCcmDRrcDNIYdjtT5z3q90od0qMu9GglK1ek= Received: by 10.181.36.9 with SMTP id o9mr3643436bkj.148.1228072483947; Sun, 30 Nov 2008 11:14:43 -0800 (PST) Received: by 10.180.205.7 with HTTP; Sun, 30 Nov 2008 11:14:43 -0800 (PST) Message-ID: <77ead0ec0811301114p7dbe9cc9kbc0ff482ccdb66d@mail.gmail.com> Date: Sun, 30 Nov 2008 11:14:43 -0800 From: "Vishwas Manral" To: "David Ward" Subject: Re: BFD echo mode In-Reply-To: <100B46D2-FC38-4E33-879A-61F0217CC83D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> <100B46D2-FC38-4E33-879A-61F0217CC83D@cisco.com> Cc: Dave Katz , rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Dave, Agree to what you say. I was also thinking of congestion control considerations to be put into BFD for the Multi-hop case. The draft does not talk about it and because BFD works on very short duration Hello's it may need to be TCP friendly in some cases. Do let me know what you think? Thanks, Vishwas On Thu, Nov 27, 2008 at 7:45 AM, David Ward wrote: > Nobo - > > On Nov 27, 2008, at 3:41 AM, Nobo Akiya (nobo) wrote: > >> >> Hello Vishwas. >> >> Couple of add-on comments, for single-hop. >> >>> Seeing some vendor documentation it seems they use a seperate >>> port for the echo mode - as the source and the destination >>> address. >> >> I hope vendors aren't using different udp dest port for echo packets. >> >> http://tools.ietf.org/html/draft-ietf-bfd-v4v6-1hop-08 Sec4.1. >> >> BFD Echo packets MUST be transmitted in UDP packets with destination >> UDP port 3785 in an IPv4 packet. >> >>> Can the asusmption that the echo mode packet is a BFD packet >>> be made (so the BFD source / dest packet identifiers can be >>> used)? The base BFD spec seems to state the content of the >>> packet need not be specified as the packet is just looped back. >> >> BFD echo packets can be identified by UDP dest port 3785. >> Data beyond UDP header is not specified, and that's left up to vendors. >> >>> So I can see how we could look an IP packet in the case of >>> Single Hop (by having the MAC Destination Address of the >>> peer) but having IP address and destination the same (as of >>> the source). >> >> I don't think there's anything that specifies that dest & src addresses >> must be the same. For dest addresses tho, it maybe easier to >> demultiplex if dest address is the outgoing interface. > > > DW: there is nothing in the spec that says the addrs have to be the same. > > > -DWard > >> >> Thanx, >> Nobo >> > > From rtg-bfd-bounces@ietf.org Sun Nov 30 11:50:29 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D8BD3A6A1C; Sun, 30 Nov 2008 11:50:29 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25E73A6A1C for ; Sun, 30 Nov 2008 11:50:27 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PHSyjK0jdj4 for ; Sun, 30 Nov 2008 11:50:25 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7A6B83A6A06 for ; Sun, 30 Nov 2008 11:50:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,690,1220227200"; d="scan'208";a="29449023" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Nov 2008 19:50:19 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAUJoJ5g017407; Sun, 30 Nov 2008 14:50:19 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAUJoJSr004574; Sun, 30 Nov 2008 19:50:19 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Nov 2008 14:50:19 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 30 Nov 2008 14:50:18 -0500 In-Reply-To: <77ead0ec0811301114p7dbe9cc9kbc0ff482ccdb66d@mail.gmail.com> References: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> <100B46D2-FC38-4E33-879A-61F0217CC83D@cisco.com> <77ead0ec0811301114p7dbe9cc9kbc0ff482ccdb66d@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Ward Subject: Re: BFD echo mode Date: Sun, 30 Nov 2008 13:50:15 -0600 To: "Vishwas Manral" X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 30 Nov 2008 19:50:19.0242 (UTC) FILETIME=[DF9EBCA0:01C95324] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2500; t=1228074619; x=1228938619; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20BFD=20echo=20mode |Sender:=20 |To:=20=22Vishwas=20Manral=22=20; bh=ZIHBw2JhWzMNkIms4I7kHzl23LggFaQIDe3A45PSQHo=; b=OyOKvKk/ndj892cqwDwiPm2eHI+d1T7HAHBkuGJl6TnzH8FpJkBQuTbc5N TsVLtWDaDCUQeqGjv8o45nA0BHnqZPmxHCHLPk+iGct/NRbcHXcLjyhBZd5O zvgGBtlXDc; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: rtg-bfd@ietf.org, David Ward , Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Additional congestion control isn't necessary if an implementation takes into consideration the adaptive timer support. This is if an implementer believes that BFD configuration would be set by an operator such that the already inconsequential amount of data being sent actually causes congestion. BFD should not be run over TCP due to overhead or UDP-lite due to lack of widespread deployment. -DWard On Nov 30, 2008, at 1:14 PM, Vishwas Manral wrote: > Hi Dave, > > Agree to what you say. > > I was also thinking of congestion control considerations to be put > into BFD for the Multi-hop case. The draft does not talk about it and > because BFD works on very short duration Hello's it may need to be TCP > friendly in some cases. > > Do let me know what you think? > > Thanks, > Vishwas > > On Thu, Nov 27, 2008 at 7:45 AM, David Ward wrote: >> Nobo - >> >> On Nov 27, 2008, at 3:41 AM, Nobo Akiya (nobo) wrote: >> >>> >>> Hello Vishwas. >>> >>> Couple of add-on comments, for single-hop. >>> >>>> Seeing some vendor documentation it seems they use a seperate >>>> port for the echo mode - as the source and the destination >>>> address. >>> >>> I hope vendors aren't using different udp dest port for echo >>> packets. >>> >>> http://tools.ietf.org/html/draft-ietf-bfd-v4v6-1hop-08 Sec4.1. >>> >>> BFD Echo packets MUST be transmitted in UDP packets with destination >>> UDP port 3785 in an IPv4 packet. >>> >>>> Can the asusmption that the echo mode packet is a BFD packet >>>> be made (so the BFD source / dest packet identifiers can be >>>> used)? The base BFD spec seems to state the content of the >>>> packet need not be specified as the packet is just looped back. >>> >>> BFD echo packets can be identified by UDP dest port 3785. >>> Data beyond UDP header is not specified, and that's left up to >>> vendors. >>> >>>> So I can see how we could look an IP packet in the case of >>>> Single Hop (by having the MAC Destination Address of the >>>> peer) but having IP address and destination the same (as of >>>> the source). >>> >>> I don't think there's anything that specifies that dest & src >>> addresses >>> must be the same. For dest addresses tho, it maybe easier to >>> demultiplex if dest address is the outgoing interface. >> >> >> DW: there is nothing in the spec that says the addrs have to be >> the same. >> >> >> -DWard >> >>> >>> Thanx, >>> Nobo >>> >> >> From rtg-bfd-bounces@ietf.org Sun Nov 30 12:11:27 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACCF23A6A43; Sun, 30 Nov 2008 12:11:27 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D9503A6A43 for ; Sun, 30 Nov 2008 12:11:27 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Srej0OzCtAH for ; Sun, 30 Nov 2008 12:11:26 -0800 (PST) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.190]) by core3.amsl.com (Postfix) with ESMTP id 98AC83A6A3C for ; Sun, 30 Nov 2008 12:11:24 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id 18so2184702fkq.5 for ; Sun, 30 Nov 2008 12:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=23FUZ+gaR2oM236vVVtFBLJ5wzB0+PEQjAd9r30LTQ8=; b=uQQ97tCF0ad/+yY/floQmFiyNCngtAIZpDhH6LT9bKRADPEGPzIodO7xcg1U+QlTw4 eLBZlnXy6Ibt8a4NY33fKEMh97N70eyPCy6MszUJnBbAIc2hk4ph+IVQUm0ptmv0g2Am 2KnqbU83tr3nD2yLXKuxu94Ze1rxlAX+6KxNM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=TsNHFx0vQm0oJYH1NZsYfJwlB2xDho3hy9y+sSOveL9rXJ4inbR19Nc/+osjYVn9xt MhqwTPnjTAgjC/y/znRbQ55w1FrBlLa+lH16wCY1cxwUxZMCj0djpgJImhh7B8Rr67bU ll3SPS0Yh2LFvq5Mwi2PgK/ZFSDgaYwCWHZlU= Received: by 10.181.134.11 with SMTP id l11mr732146bkn.73.1228075879978; Sun, 30 Nov 2008 12:11:19 -0800 (PST) Received: by 10.180.205.7 with HTTP; Sun, 30 Nov 2008 12:11:19 -0800 (PST) Message-ID: <77ead0ec0811301211i967f3cao810de37ba54315e@mail.gmail.com> Date: Sun, 30 Nov 2008 12:11:19 -0800 From: "Vishwas Manral" To: "David Ward" Subject: Re: BFD echo mode In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> <100B46D2-FC38-4E33-879A-61F0217CC83D@cisco.com> <77ead0ec0811301114p7dbe9cc9kbc0ff482ccdb66d@mail.gmail.com> Cc: Dave Katz , rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Dave, Sounds good. So what you are saying is that adaptive timer support needs to be there? Is the understanding correct. -Vishwas On Sun, Nov 30, 2008 at 11:50 AM, David Ward wrote: > Additional congestion control isn't necessary if an implementation takes > into consideration the adaptive timer support. This is if an implementer > believes that BFD configuration would be set by an operator such that the > already inconsequential amount of data being sent actually causes > congestion. BFD should not be run over TCP due to overhead or UDP-lite due > to lack of widespread deployment. > > -DWard > > On Nov 30, 2008, at 1:14 PM, Vishwas Manral wrote: > >> Hi Dave, >> >> Agree to what you say. >> >> I was also thinking of congestion control considerations to be put >> into BFD for the Multi-hop case. The draft does not talk about it and >> because BFD works on very short duration Hello's it may need to be TCP >> friendly in some cases. >> >> Do let me know what you think? >> >> Thanks, >> Vishwas >> >> On Thu, Nov 27, 2008 at 7:45 AM, David Ward wrote: >>> >>> Nobo - >>> >>> On Nov 27, 2008, at 3:41 AM, Nobo Akiya (nobo) wrote: >>> >>>> >>>> Hello Vishwas. >>>> >>>> Couple of add-on comments, for single-hop. >>>> >>>>> Seeing some vendor documentation it seems they use a seperate >>>>> port for the echo mode - as the source and the destination >>>>> address. >>>> >>>> I hope vendors aren't using different udp dest port for echo packets. >>>> >>>> http://tools.ietf.org/html/draft-ietf-bfd-v4v6-1hop-08 Sec4.1. >>>> >>>> BFD Echo packets MUST be transmitted in UDP packets with destination >>>> UDP port 3785 in an IPv4 packet. >>>> >>>>> Can the asusmption that the echo mode packet is a BFD packet >>>>> be made (so the BFD source / dest packet identifiers can be >>>>> used)? The base BFD spec seems to state the content of the >>>>> packet need not be specified as the packet is just looped back. >>>> >>>> BFD echo packets can be identified by UDP dest port 3785. >>>> Data beyond UDP header is not specified, and that's left up to vendors. >>>> >>>>> So I can see how we could look an IP packet in the case of >>>>> Single Hop (by having the MAC Destination Address of the >>>>> peer) but having IP address and destination the same (as of >>>>> the source). >>>> >>>> I don't think there's anything that specifies that dest & src addresses >>>> must be the same. For dest addresses tho, it maybe easier to >>>> demultiplex if dest address is the outgoing interface. >>> >>> >>> DW: there is nothing in the spec that says the addrs have to be the same. >>> >>> >>> -DWard >>> >>>> >>>> Thanx, >>>> Nobo >>>> >>> >>> > > From rtg-bfd-bounces@ietf.org Sun Nov 30 21:04:14 2008 Return-Path: X-Original-To: rtg-bfd-archive@megatron.ietf.org Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1603A67EE; Sun, 30 Nov 2008 21:04:14 -0800 (PST) X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0464B3A67EE for ; Sun, 30 Nov 2008 21:04:14 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsfvCUG3XteQ for ; Sun, 30 Nov 2008 21:04:13 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B465D3A67B6 for ; Sun, 30 Nov 2008 21:04:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,693,1220227200"; d="scan'208";a="29482135" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Dec 2008 05:04:06 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB1546KH007358; Mon, 1 Dec 2008 00:04:06 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mB1546DL001186; Mon, 1 Dec 2008 05:04:06 GMT Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 00:04:06 -0500 Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 00:03:33 -0500 In-Reply-To: <77ead0ec0811301211i967f3cao810de37ba54315e@mail.gmail.com> References: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> <100B46D2-FC38-4E33-879A-61F0217CC83D@cisco.com> <77ead0ec0811301114p7dbe9cc9kbc0ff482ccdb66d@mail.gmail.com> <77ead0ec0811301211i967f3cao810de37ba54315e@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: David Ward Subject: Re: BFD echo mode Date: Sun, 30 Nov 2008 23:03:30 -0600 To: "Vishwas Manral" X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 01 Dec 2008 05:03:33.0956 (UTC) FILETIME=[29362040:01C95372] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3121; t=1228107846; x=1228971846; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20 |Subject:=20Re=3A=20BFD=20echo=20mode |Sender:=20 |To:=20=22Vishwas=20Manral=22=20; bh=IIYcARt1+bJQOEjoAxGUDiyv4nBPP5bse/80GOP/E/4=; b=lJZvyiJ5L0uSism9uUmaykvoOHEia230FNk+M8e/fPKqgJp5SbLnvfdIeB lNB/BJcy3CK/2JRkri3TG2w9hXkNaX2N7rT/zrMfDsnKVJbyUSv8Hi8AAVf/ i1Vje+7Wwb; Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: rtg-bfd@ietf.org, David Ward , Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org The specification and implementation of adaptive timers was expected to be the congestion control mechanism. -DWard On Nov 30, 2008, at 2:11 PM, Vishwas Manral wrote: > Dave, > > Sounds good. So what you are saying is that adaptive timer support > needs to be there? Is the understanding correct. > > -Vishwas > > On Sun, Nov 30, 2008 at 11:50 AM, David Ward wrote: >> Additional congestion control isn't necessary if an implementation >> takes >> into consideration the adaptive timer support. This is if an >> implementer >> believes that BFD configuration would be set by an operator such >> that the >> already inconsequential amount of data being sent actually causes >> congestion. BFD should not be run over TCP due to overhead or UDP- >> lite due >> to lack of widespread deployment. >> >> -DWard >> >> On Nov 30, 2008, at 1:14 PM, Vishwas Manral wrote: >> >>> Hi Dave, >>> >>> Agree to what you say. >>> >>> I was also thinking of congestion control considerations to be put >>> into BFD for the Multi-hop case. The draft does not talk about it >>> and >>> because BFD works on very short duration Hello's it may need to >>> be TCP >>> friendly in some cases. >>> >>> Do let me know what you think? >>> >>> Thanks, >>> Vishwas >>> >>> On Thu, Nov 27, 2008 at 7:45 AM, David Ward wrote: >>>> >>>> Nobo - >>>> >>>> On Nov 27, 2008, at 3:41 AM, Nobo Akiya (nobo) wrote: >>>> >>>>> >>>>> Hello Vishwas. >>>>> >>>>> Couple of add-on comments, for single-hop. >>>>> >>>>>> Seeing some vendor documentation it seems they use a seperate >>>>>> port for the echo mode - as the source and the destination >>>>>> address. >>>>> >>>>> I hope vendors aren't using different udp dest port for echo >>>>> packets. >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-bfd-v4v6-1hop-08 Sec4.1. >>>>> >>>>> BFD Echo packets MUST be transmitted in UDP packets with >>>>> destination >>>>> UDP port 3785 in an IPv4 packet. >>>>> >>>>>> Can the asusmption that the echo mode packet is a BFD packet >>>>>> be made (so the BFD source / dest packet identifiers can be >>>>>> used)? The base BFD spec seems to state the content of the >>>>>> packet need not be specified as the packet is just looped back. >>>>> >>>>> BFD echo packets can be identified by UDP dest port 3785. >>>>> Data beyond UDP header is not specified, and that's left up to >>>>> vendors. >>>>> >>>>>> So I can see how we could look an IP packet in the case of >>>>>> Single Hop (by having the MAC Destination Address of the >>>>>> peer) but having IP address and destination the same (as of >>>>>> the source). >>>>> >>>>> I don't think there's anything that specifies that dest & src >>>>> addresses >>>>> must be the same. For dest addresses tho, it maybe easier to >>>>> demultiplex if dest address is the outgoing interface. >>>> >>>> >>>> DW: there is nothing in the spec that says the addrs have to be >>>> the same. >>>> >>>> >>>> -DWard >>>> >>>>> >>>>> Thanx, >>>>> Nobo >>>>> >>>> >>>> >> >>