From rtg-bfd-bounces@ietf.org Wed Jan 7 03:28:00 2009 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 2EB0428C12A; Wed, 7 Jan 2009 03:28:00 -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 8C66228C119 for ; Wed, 7 Jan 2009 03:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[AWL=2.410, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 qJE-J38qOWuR for ; Wed, 7 Jan 2009 03:26:26 -0800 (PST) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by core3.amsl.com (Postfix) with ESMTP id 63D803A680E for ; Wed, 7 Jan 2009 03:26:25 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,225,1231131600"; d="scan'208,217";a="34796448" Received: from ftlpexchmx02.citrite.net ([10.9.154.127]) by FTLPIPO02.CITRIX.COM with ESMTP; 07 Jan 2009 06:26:08 -0500 Received: from banpexch01.citrite.net ([10.103.128.11]) by FTLPEXCHMX02.citrite.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Jan 2009 06:26:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C970BA.BA688301" Subject: General Query new commer Date: Wed, 7 Jan 2009 16:56:05 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: General Query new commer Thread-Index: Aclwurn8xDmXlrLkRuSgiQU2v3EeyQ== From: "Nanda Kishore Salem" To: X-OriginalArrivalTime: 07 Jan 2009 11:26:08.0660 (UTC) FILETIME=[BC90BD40:01C970BA] 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C970BA.BA688301 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have seen router/switch vendors supporting BFD for routing and other protocol needs does any server software (OS Microsoft, sun, unix, linux) vendors support (beta or otherwise) BFD.=20 =20 I am primarily looking from Content Switches/server load balancer requirements to support BFD.=20 Content switch vendors like (Citrix, F5, Cisco) etc would want their switches to be able to=20 do all that is offered by BFD with the server machines.=20 i.e. quickly detect a server is DOWN and transfer the load to another.=20 multiplex various protocol/deamon state detections (http, ftp, ssl etc) =20 To do this server software vendors need to be supporting BFD so that content switch vendors can use it to improve detection times etc.=20 =20 Question: Is there any server/OS software vendor supporting BFD? Is there any content switch vendor (Cisco, F5, Radware etc) supporting BFD for load balancers?=20 =20 =20 =20 Thank you,=20 Nanda Kishore =20 ------_=_NextPart_001_01C970BA.BA688301 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have seen router/switch vendors supporting BFD for = routing and other protocol needs

does any server software (OS Microsoft, sun, unix, = linux) vendors support (beta or otherwise) BFD.

 

I am primarily looking from Content Switches/server = load balancer requirements to support BFD.

Content switch vendors like (Citrix, F5, Cisco) etc = would want their switches to be able to

do all that is offered by BFD with the server = machines.

i.e. quickly detect a server is DOWN and transfer the = load to another.

      multiplex various = protocol/deamon state detections (http, ftp, ssl etc)

 

To do this server software vendors need to be = supporting BFD so that content switch vendors can use it

to improve detection times etc. =

 

Question:

Is there any server/OS software vendor supporting = BFD?

Is there any content switch vendor (Cisco, F5, = Radware etc) supporting BFD for load balancers?

 

 

 

Thank you,

Nanda Kishore

 

------_=_NextPart_001_01C970BA.BA688301-- From rtg-bfd-bounces@ietf.org Wed Jan 7 03:28:00 2009 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 621FC28C132; Wed, 7 Jan 2009 03:28:00 -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 0278328C12A for ; Wed, 7 Jan 2009 03:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=1.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_OTHER=0.135, SARE_SUB_OBFU_Z=0.259] 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 m2GQdvKnZDMG for ; Wed, 7 Jan 2009 03:27:50 -0800 (PST) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by core3.amsl.com (Postfix) with ESMTP id 3C15A3A6A19 for ; Wed, 7 Jan 2009 03:27:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,225,1231131600"; d="scan'208";a="34796548" Received: from ftlpexchmx02.citrite.net ([10.9.154.127]) by FTLPIPO02.CITRIX.COM with ESMTP; 07 Jan 2009 06:27:36 -0500 Received: from banpexch01.citrite.net ([10.103.128.11]) by FTLPEXCHMX02.citrite.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Jan 2009 06:27:36 -0500 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: Confirm: rtg-bfd@core3.amsl.com:8Krlf9SWSRYw:dvP19w5wsucP-8iICPgJzyYokDvIcYfrdK3Ofw Date: Wed, 7 Jan 2009 16:57:34 +0530 Message-ID: In-Reply-To: <20090107112627.96DF63A680E@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Confirm: rtg-bfd@core3.amsl.com:8Krlf9SWSRYw:dvP19w5wsucP-8iICPgJzyYokDvIcYfrdK3Ofw Thread-Index: AclwusKfs3zZLhN3Rf+eT3sdO3v+bQAACSwg From: "Nanda Kishore Salem" To: X-OriginalArrivalTime: 07 Jan 2009 11:27:36.0737 (UTC) FILETIME=[F1103910:01C970BA] 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 -----Original Message----- From: rtg-bfd@core3.amsl.com [mailto:rtg-bfd@core3.amsl.com]=20 Sent: Wednesday, January 07, 2009 4:56 PM To: Nanda Kishore Salem Subject: Confirm: rtg-bfd@core3.amsl.com:8Krlf9SWSRYw:dvP19w5wsucP-8iICPgJzyYokDvIcYfrdK3O fw Confirmation of list posting -- confirmation ID: 8Krlf9SWSRYw The ietf.org mailing-list server has received a list posting from=20 nandas@citrix.com to rtg-bfd@core3.amsl.com with the subject=20 'General Query new commer ' As the sender address isn't subscribed to the list, and has not been confirmed earlier, we have to request a confirmation of the address. To confirm the address, send a message to rtg-bfd@core3.amsl.com, with the same subject line as this message. (Simply sending a 'reply' to this message should work from most email interfaces, since that usually leaves the subject line in the right form. The reply's additional "Re:" is ok.) If you do not wish your posting to the list to go through, simply disregard this message. Questions to postmaster@ietf.org. From rtg-bfd-bounces@ietf.org Mon Jan 26 20:31:29 2009 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 750D23A6A5E; Mon, 26 Jan 2009 20:31: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 562493A6A5E for ; Mon, 26 Jan 2009 20:31:28 -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 YGcCsOmJ+YHW for ; Mon, 26 Jan 2009 20:31:27 -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 11C473A6A5B for ; Mon, 26 Jan 2009 20:31:26 -0800 (PST) Received: by fk-out-0910.google.com with SMTP id f33so2948777fkf.5 for ; Mon, 26 Jan 2009 20:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=w+gST1HccwtCKryzIT+rlnWWKZE0JpgIIEEOmjZv088=; b=qKChS3kaQn2TFL6tpDk/QrYclHsfKB2WtJb03ZLjx8/pvUaPYCUKwVjIYa6MpwPgNP 2JSYKjmhJefV3iUOtH0ftepNAzQSJElnXucqn6oYCUjf76fXbev6bV6FSEszt8qRC2oB uVcCk33QFIVXSVdMMPMUdSDh2j/ozwWOFQ6+I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=XUwRAar2eVlorTG9JNfR8monbtS5fZ25AL/nFnG51Np3NgA+M+hzAivWPyhexO8cOp gUHuSfJsnTAL2fsEVVmNHGOkL4IGm+0bmQEcEP3wDlJ3IQbtrOM4lcsd+TJ7V5MQ7Gu/ MpSxEudMnzDYbJNdNbZw5HPZeQHb7ZPfEhn8Q= MIME-Version: 1.0 Received: by 10.181.235.6 with SMTP id m6mr3099949bkr.190.1233030668524; Mon, 26 Jan 2009 20:31:08 -0800 (PST) Date: Mon, 26 Jan 2009 20:31:08 -0800 Message-ID: <77ead0ec0901262031na13b3fud7350094e02b59df@mail.gmail.com> Subject: Generic BFD Crypto From: Vishwas Manral To: rtg-bfd@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 folks, Please see below the discussion with the Security-AD's regarding the crypto algorithms to support and recommend. We have written a draft to satisfy some part of the same. Do have a look and let us know any comments you may have regarding the same? http://tools.ietf.org/html/draft-bhatia-bfd-crypto-auth-00 Thanks, Vishwas ---------- Forwarded message ---------- From: Date: Mon, Jan 26, 2009 at 5:28 AM Subject: RE: MD5 Vs SHA-1 direction To: vishwas.ietf@gmail.com, tim.polk@nist.gov Cc: joelja@bogus.com, manav@alcatel-lucent.com Hi Vishwas, And apologies that replying to your email took so long! We wanted to consult with some hash function experts, and our deliberations took longer than we had expected. Anyway, here's our advice currently: - For HMAC, there are no practical attacks (yet) for HMAC-MD5 or HMAC-SHA1. We agree with Hugo Krawczyk that HMAC-MD5 is starting to look suspicious, and should be replaced (before attacks become practical). We believe that HMAC-SHA1 provides an acceptable level of security for most applications for the time being, and is a big improvement over HMAC-MD5. For most applications HMAC-SHA1 is a good choice as the mandatory to implement algorithm. However, we're encouraging folks to design for algorithm agility, and also support other MAC algorithms in addition to HMAC-SHA1 (such as AES-CMAC). - Some routing area protocols use MD5/SHA-1 based MACs that are not HMAC -- for example, the "secret-suffix/append-only" construction in OSPFv2 and current BFD drafts. These constructions have known to be problematic for more than a decade, even when used with a perfectly good hash function. As far as we know, using them with broken hash functions (like MD5) has not been thoroughly analyzed yet, but the likelihood of practical attacks is much higher than for HMAC-MD5. We recommend replacing these with HMAC-SHA1 and/or AES-CMAC (and at the same time, considering algorithm agility so that other MACs can be easily added in the future). - For anything involving public-key signatures, neither MD5 or SHA-1 is a good idea. MD5 has practical attacks, and SHA-1 is showing signs of weakness. The U.S. Government is phasing out SHA-1 for most public-key signatures by the end of next year. For the time being, we recommend specifying SHA-256 as the mandatory to implement algorithm. Even though other hash functions might be coming in the future (e.g. from the NIST hash competition), SHA-256 appears to be a good choice today (and has a safety margin that should make attacks impractical for a long time). As with HMAC, designing for algorithm agility is important step in the right direction. - Hash functions might also be used in other contexts than public-key signatures and MACs/PRFs (although that's much rarer, and does not occur in every protocol). It's possible that some of these places don't actually need a cryptographically secure hash function (and using MD5, or even CRC32, would be OK), but doing the analysis for each case is a lot of work. We believe that for most cases, the simplest (least work) solution is to use a good hash function with a sufficient safety margin, like SHA-256. (Note that while we believe HMAC-SHA1 continues to be OK, we do not recommend using SHA-1 for anything that assumes collision resistance.) Best regards, Pasi & Tim