From simon.perreault@viagenie.ca Thu Aug 2 08:44:44 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1265521F850C for ; Thu, 2 Aug 2012 08:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m61Ih6Xfbpcn for ; Thu, 2 Aug 2012 08:44:43 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 6649021F8433 for ; Thu, 2 Aug 2012 08:44:43 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2001:df8:0:16:34aa:41c2:abef:4aa7]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D05B241582 for ; Thu, 2 Aug 2012 11:44:42 -0400 (EDT) Message-ID: <501AA06A.9060006@viagenie.ca> Date: Thu, 02 Aug 2012 08:44:42 -0700 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: behave@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [BEHAVE] A little doubt about draft-ietf-behave-lsn-requirements-08 X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 15:44:44 -0000 Le 2012-07-31 00:59, meng.wei2@zte.com.cn a écrit : > > Hi, > > I have a little doubt about the draft. > > In section 3, > " > REQ-11: When a CGN is unable to create a mapping due to resource > constraints or administrative restrictions (i.e., quotas): > > A. it MUST drop the original packet; > > B. it SHOULD send an ICMP Destination Unreachable message > with code 1 (Host Unreachable) to the sender; > > C. it SHOULD send a notification (e.g., SNMP trap) towards > a management system (if configured to do so); > > D. and it MUST NOT delete existing mappings in order to > "make room" for the new one. (This only applies to > normal CGN behavior, not to manual operator > intervention.) > " > > In item D, In my opinion, a static mapping MAY be created without > recieving the datagram, but the static rule has been configured AND the > corresponding user be online. Under the circumstances, if the packet a > CGN recieved match the STATIC rule , it SHOULDDELETE a existing DYNAMIC > mapping in order to "make room" for the STATIC mapping, because of > ensuring the STATIC rule taking effect. > Otherwise, how to resolve the problem instead of kicking a DYNAMIC > mapping off ? This makes total sense. To fix this I would suggest this: OLD: REQ-11: When a CGN is unable to create a mapping due to resource constraints or administrative restrictions (i.e., quotas): NEW: REQ-11: When a CGN is unable to create a dynamic mapping due to resource constraints or administrative restrictions (i.e., quotas): > On the other hand, if the packet need to be translated by ALG, it > MAY create two mappings but it find that there is "no room" to create > the second mapping after having created the first mapping. What do you propose we do in such a case? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From victor.kuarsingh@gmail.com Thu Aug 2 15:40:29 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397D511E80A5; Thu, 2 Aug 2012 15:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beccnGcz-2zl; Thu, 2 Aug 2012 15:40:28 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55F4A11E80A2; Thu, 2 Aug 2012 15:40:28 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so80405obb.31 for ; Thu, 02 Aug 2012 15:40:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=cfkuWQZh+dIlunpesIJneKuPLbg5bjPat9YYu45jf9E=; b=Qdby3yyLz14IhkLaj6axCyUVy2dX4UbjSZ/a16P2wZuR62btF4YyGYTy/btsNaUi2g P9FR3vG6xUlge+7v4Mn3TPZRLf06aW6y0d08CtEDBUYettvSmFCOWGEupl/Y35PKq9WW z24RvnnKRtzBamb0eGHutvNuEixr6j39FQfLA9NokJKZf1iBGBwcWT8KGAmYElssOdn5 bS6lSzq+02/PApZj4AYAfKYfAcuysvFrHUPyAavwyI7jgFq7H/1EZ0SRVKIX3U87Cc3J DW1XL+iLSW+yBCJiNKIZrn4+P3/YP6R2j2ZXkKpj5icmD30BN4Trg2VelkQqrDZFCScx Ya/A== Received: by 10.60.30.170 with SMTP id t10mr40608345oeh.10.1343947227840; Thu, 02 Aug 2012 15:40:27 -0700 (PDT) Received: from [130.129.19.190] (dhcp-13be.meeting.ietf.org. [130.129.19.190]) by mx.google.com with ESMTPS id hz6sm7413083obb.1.2012.08.02.15.40.24 (version=SSLv3 cipher=OTHER); Thu, 02 Aug 2012 15:40:26 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 02 Aug 2012 15:40:21 -0700 From: Victor Kuarsingh To: , , Message-ID: Thread-Topic: Feedback LSN Deployment Draft Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3426766825_19161737" Subject: [BEHAVE] Feedback LSN Deployment Draft X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:40:29 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3426766825_19161737 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit OPSAWG/Behave/Sunset4 WGs, Following further consideration in OPSAWG, the Chairs have requested addition opportunity for feedback from the Behave and Sunset4 WGs regarding draft-ietf-opsawg-lsn-deployment-00. (link - http://tools.ietf.org/html/draft-ietf-opsawg-lsn-deployment-00) What we are looking for is technical feedback on the architecture/concepts defined in the draft. What we are NOT looking for is opinions on why CGN is bad. I expect there may be textual updates needed along with other minor items. There was also a plan to remove the "Performance" section which was originally added before other drafts were available discussing CGN/NAT444 impacts (like draft-donley-nat444-impacts) The document presupposes an operator has decided to do CGN/NAT444 (business/technical reasons particular to them) and therefore may require architectural options on how to deploy this in an existing network. The document offers once such option using BGP/MPLS IP VPNs. I appreciate feedback. Regards, Victor K --B_3426766825_19161737 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
OPSAWG/Behave/Sunset4 WGs,

Following further consideration in OPSAWG, the Chair= s have requested addition opportunity for feedback from the Behave and Sunse= t4 WGs regarding draft-ietf-opsawg-lsn-deployment-00. (link - http://tools= .ietf.org/html/draft-ietf-opsawg-lsn-deployment-00)

=
What we are looking for is technical feedback on the architecture/conce= pts defined in the draft.  What we are NOT looking for is opinions on w= hy CGN is bad.  I expect there may be textual updates needed along with= other minor items. 

There was also a plan to = remove the "Performance" section which was originally added before other dra= fts were available discussing CGN/NAT444 impacts (like draft-donley-nat= 444-impacts)

The document presupposes an operator h= as decided to do CGN/NAT444 (business/technical reasons particular to them) = and therefore may require architectural options on how to deploy this in an = existing network.  The document offers once such option using BGP/MPLS = IP VPNs.

I appreciate feedback.

Regards,

Victor K
--B_3426766825_19161737-- From internet-drafts@ietf.org Thu Aug 9 12:10:14 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7F821F8798; Thu, 9 Aug 2012 12:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37b1+voVqf7h; Thu, 9 Aug 2012 12:10:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0585121F879B; Thu, 9 Aug 2012 12:10:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120809191014.22807.40102.idtracker@ietfa.amsl.com> Date: Thu, 09 Aug 2012 12:10:14 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-lsn-requirements-09.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:10:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : Common requirements for Carrier Grade NATs (CGNs) Author(s) : Simon Perreault Ikuhei Yamagata Shin Miyakawa Akira Nakagawa Hiroyuki Ashida Filename : draft-ietf-behave-lsn-requirements-09.txt Pages : 17 Date : 2012-08-09 Abstract: This document defines common requirements for Carrier-Grade NAT (CGN). It updates RFC 4787. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-lsn-requirements-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Thu Aug 9 12:12:00 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02EE21F8768; Thu, 9 Aug 2012 12:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS0M+sYV-+cn; Thu, 9 Aug 2012 12:12:00 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 1756821F874C; Thu, 9 Aug 2012 12:12:00 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:c98b:cee4:ff27:7548]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 204B745C40; Thu, 9 Aug 2012 15:11:59 -0400 (EDT) Message-ID: <50240B7E.2090003@viagenie.ca> Date: Thu, 09 Aug 2012 15:11:58 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: The IESG References: <20120809191014.22807.51556.idtracker@ietfa.amsl.com> In-Reply-To: <20120809191014.22807.51556.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120809191014.22807.51556.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "behave@ietf.org" Subject: [BEHAVE] Fwd: New Version Notification for draft-ietf-behave-lsn-requirements-09.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 19:12:00 -0000 IESG, This new revision should address all COMMENTs and DISCUSSes that were received. Simon -------- Message original -------- Sujet: New Version Notification for draft-ietf-behave-lsn-requirements-09.txt Date : Thu, 09 Aug 2012 12:10:14 -0700 De : internet-drafts@ietf.org Pour : simon.perreault@viagenie.ca Copie à : assie@hir.jp, miyakawa@nttv6.jp, a-nakagawa@jpix.ad.jp, ikuhei@nttv6.jp A new version of I-D, draft-ietf-behave-lsn-requirements-09.txt has been successfully submitted by Simon Perreault and posted to the IETF repository. Filename: draft-ietf-behave-lsn-requirements Revision: 09 Title: Common requirements for Carrier Grade NATs (CGNs) Creation date: 2012-08-09 WG ID: behave Number of pages: 17 URL: http://www.ietf.org/internet-drafts/draft-ietf-behave-lsn-requirements-09.txt Status: http://datatracker.ietf.org/doc/draft-ietf-behave-lsn-requirements Htmlized: http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-09 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-lsn-requirements-09 Abstract: This document defines common requirements for Carrier-Grade NAT (CGN). It updates RFC 4787. The IETF Secretariat From internet-drafts@ietf.org Wed Aug 15 06:00:02 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833FB21F87DA; Wed, 15 Aug 2012 06:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPbf5HnC7pWq; Wed, 15 Aug 2012 06:00:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B37A21F87B9; Wed, 15 Aug 2012 06:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120815130001.28344.5260.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2012 06:00:01 -0700 Cc: behave@ietf.org Subject: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 13:00:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Behavior Engineering for Hindrance Avoida= nce Working Group of the IETF. Title : Additional Managed Objects for Network Address Translato= rs (NAT) Author(s) : Simon Perreault Tina Tsou Senthil Sivakumar Filename : draft-ietf-behave-nat-mib-03.txt Pages : 75 Date : 2012-08-15 Abstract: This memo defines a portion of the Management Information Base (MIB) for devices implementing Network Address Translator (NAT) function. This MIB module may be used for monitoring of a device capable of NAT function. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-behave-nat-mib-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-behave-nat-mib-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From simon.perreault@viagenie.ca Wed Aug 15 06:32:45 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF0021F8752 for ; Wed, 15 Aug 2012 06:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pHhW2n5ckVC for ; Wed, 15 Aug 2012 06:32:44 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 5057F21F8749 for ; Wed, 15 Aug 2012 06:32:44 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:6062:c6d2:d4b6:7453]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8D8FD41595; Wed, 15 Aug 2012 09:32:43 -0400 (EDT) Message-ID: <502BA4FA.40000@viagenie.ca> Date: Wed, 15 Aug 2012 09:32:42 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Dave Thaler , "Reinaldo Penno (repenno)" References: <20120815130001.28344.5260.idtracker@ietfa.amsl.com> In-Reply-To: <20120815130001.28344.5260.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: behave@ietf.org Subject: Re: [BEHAVE] I-D Action: draft-ietf-behave-nat-mib-03.txt X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 13:32:45 -0000 (I couldn't find Julia Renouard's email address, hopefully she's on the list...) Dave, Reinaldo, Julia, The new NAT MIB draft has been submitted and is ready for your review. Here's a summary of the changes: - Added an "Obsoletes: 4008" header. - Introduction section has been replaced by the one from RFC 4008. - New section 2 has been copied from RFC 4008. - Security considerations section has been adapted from RFC 4008. - IANA considerations section mentions the already existing MIB OID. - New feature: realms (see section 3.3) - New feature: RFC 4787 terminology (as asked by Reinaldo in Vancouver) Simon Le 2012-08-15 09:00, internet-drafts@ietf.org a écrit : > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. > > Title : Additional Managed Objects for Network Address Translators (NAT) > Author(s) : Simon Perreault > Tina Tsou > Senthil Sivakumar > Filename : draft-ietf-behave-nat-mib-03.txt > Pages : 75 > Date : 2012-08-15 > > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for devices implementing Network Address Translator (NAT) function. > This MIB module may be used for monitoring of a device capable of NAT > function. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-behave-nat-mib-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-behave-nat-mib-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From wwwrun@rfc-editor.org Mon Aug 20 11:25:56 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F0521F866E for ; Mon, 20 Aug 2012 11:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.312 X-Spam-Level: X-Spam-Status: No, score=-102.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id es1UWFef441D for ; Mon, 20 Aug 2012 11:25:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id EEAE721F85FF for ; Mon, 20 Aug 2012 11:25:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0AA6CB1E004; Mon, 20 Aug 2012 11:24:08 -0700 (PDT) To: jdrosen@cisco.com, rohan@ekabal.com, philip_matthews@magma.ca, dwing@cisco.com, wes@mti-systems.com, martin.stiemerling@neclab.eu, dwing@cisco.com, dthaler@microsoft.com From: RFC Errata System Message-Id: <20120820182408.0AA6CB1E004@rfc-editor.org> Date: Mon, 20 Aug 2012 11:24:08 -0700 (PDT) Cc: behave@ietf.org, taherman@verizon.net, rfc-editor@rfc-editor.org Subject: [BEHAVE] [Technical Errata Reported] RFC5389 (3327) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 18:25:56 -0000 The following errata report has been submitted for RFC5389, "Session Traversal Utilities for NAT (STUN)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5389&eid=3327 -------------------------------------- Type: Technical Reported by: Todd Herman Section: 15.3 Original Text ------------- The USERNAME attribute is used for message integrity. It identifies the username and password combination used in the message-integrity check. Corrected Text -------------- Notes ----- There is no explanation or description as to where this "password" comes from. The statement indicates that the password is also part of the username field but that may not actually be true according to additional research I conducted and other portions of the specification. If the password is part of this field than it should be explicitly noted how the two values are concatenated. If this is not accurate, than the "and password combination" portion should be removed. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5389 (draft-ietf-behave-rfc3489bis-18) -------------------------------------- Title : Session Traversal Utilities for NAT (STUN) Publication Date : October 2008 Author(s) : J. Rosenberg, R. Mahy, P. Matthews, D. Wing Category : PROPOSED STANDARD Source : Behavior Engineering for Hindrance Avoidance Area : Transport Stream : IETF Verifying Party : IESG From simon.perreault@viagenie.ca Mon Aug 20 11:30:47 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1000D21F86C8 for ; Mon, 20 Aug 2012 11:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJxrmr8t6412 for ; Mon, 20 Aug 2012 11:30:46 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id D18A721F8600 for ; Mon, 20 Aug 2012 11:30:43 -0700 (PDT) Received: from [192.168.1.149] (modemcable212.59-179-173.mc.videotron.ca [173.179.59.212]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D5B984581F; Mon, 20 Aug 2012 14:30:40 -0400 (EDT) Message-ID: <50328253.3020009@viagenie.ca> Date: Mon, 20 Aug 2012 14:30:43 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: RFC Errata System References: <20120820182408.0AA6CB1E004@rfc-editor.org> In-Reply-To: <20120820182408.0AA6CB1E004@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: rohan@ekabal.com, behave@ietf.org, jdrosen@cisco.com, wes@mti-systems.com, taherman@verizon.net, dthaler@microsoft.com, dwing@cisco.com, martin.stiemerling@neclab.eu, philip_matthews@magma.ca Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5389 (3327) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 18:30:47 -0000 Isn't it clearly spelled out in section 10? As an implementer I fail to see what the problem is. Simon Le 20/08/2012 2:24 PM, RFC Errata System a écrit : > > The following errata report has been submitted for RFC5389, > "Session Traversal Utilities for NAT (STUN)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=5389&eid=3327 > > -------------------------------------- > Type: Technical > Reported by: Todd Herman > > Section: 15.3 > > Original Text > ------------- > The USERNAME attribute is used for message integrity. It identifies > the username and password combination used in the message-integrity > check. > > Corrected Text > -------------- > > > Notes > ----- > There is no explanation or description as to where this "password" comes from. The statement indicates that the password is also part of the username field but that may not actually be true according to additional research I conducted and other portions of the specification. > > If the password is part of this field than it should be explicitly noted how the two values are concatenated. If this is not accurate, than the "and password combination" portion should be removed. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5389 (draft-ietf-behave-rfc3489bis-18) > -------------------------------------- > Title : Session Traversal Utilities for NAT (STUN) > Publication Date : October 2008 > Author(s) : J. Rosenberg, R. Mahy, P. Matthews, D. Wing > Category : PROPOSED STANDARD > Source : Behavior Engineering for Hindrance Avoidance > Area : Transport > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > From petithug@acm.org Mon Aug 20 11:43:16 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D92421F8673 for ; Mon, 20 Aug 2012 11:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssNR6dop6QLV for ; Mon, 20 Aug 2012 11:43:15 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 9F93B21F8629 for ; Mon, 20 Aug 2012 11:43:15 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 4BC3D202AA; Mon, 20 Aug 2012 18:43:14 +0000 (UTC) Message-ID: <50328540.4060009@acm.org> Date: Mon, 20 Aug 2012 11:43:12 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: taherman@verizon.net References: <20120820182408.0AA6CB1E004@rfc-editor.org> In-Reply-To: <20120820182408.0AA6CB1E004@rfc-editor.org> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5389 (3327) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 18:43:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/20/2012 11:24 AM, RFC Errata System wrote: > > The following errata report has been submitted for RFC5389, "Session > Traversal Utilities for NAT (STUN)". > > -------------------------------------- You may review the report below and > at: http://www.rfc-editor.org/errata_search.php?rfc=5389&eid=3327 > > -------------------------------------- Type: Technical Reported by: Todd > Herman > > Section: 15.3 > > Original Text ------------- The USERNAME attribute is used for message > integrity. It identifies the username and password combination used in the > message-integrity check. > > Corrected Text -------------- > > > Notes ----- There is no explanation or description as to where this > "password" comes from. The statement indicates that the password is also > part of the username field but that may not actually be true according to > additional research I conducted and other portions of the specification. > > If the password is part of this field than it should be explicitly noted > how the two values are concatenated. If this is not accurate, than the > "and password combination" portion should be removed. > Why didn't you sent an email to the authors or to the behave mailing-list before polluting the Errata database? The statement does *not* indicate that the password is part of the username field, just that the username field *identifies* the password (as in "querying a database" or "searching in an hash map"). - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQMoU8AAoJECnERZXWan7EJQgQAL3wPCUSIDp26xNuTeN/eP+f 3KpjBIwDoLdhldPAEhFLLIeGEP7W6d/k+onKfsDno0q6NQY/Fmp9oMBftBEhDA6h UCF3aYuarpB3YxYj6C+J56b6eThrMqrZj9ZpVfmRmLb/P5rM7Eo10r8rljzxX211 3AfKB9cU6m0UOWNnuWU3Cq1rwnL1KFN5veiCp0FpxsmAnhFZL9rBBzvXBKl6+fQU efHJrnshK5IDllxCN3AxEjZtZNKE6q8t/S0tT8F5BFy6d5EWf0zB9M3clDx0Us+v T0b3k72Szop0WjAPAFyopHHE/TzL+u8ZGyZEB+CFW26DRXpoGvvw9oCtJJE7+csb vNHmZnmtMO8K5hrpI8yWD8uYz17COXwOKoUBXIh1lv+cRx7g18gaa5mkNuecbgiX ex//nCb7r39wla41ZDWOt3hER2ejRR6gFQrsC6tFrnRPuQUn9+6lP7h3b5z/rHUE Phz4GlTjgDTVUa14g2RVMgsRzaW6SxZEhLSFjYxJIbJCxmtOyW7gUZLN51vUZAdn GPH5R9/1pnV+YLAgRVqnqZhBkXiiT8BJjOwtiOCvKDGuUknvdKOuAQx6butccx2f 9f9iNfwWl9t6vO0BuPC7xrTlm3K1pDioqju3kJIrbF9MVmys47hJrNnUlKO8agNu QCNX3w3iTnNC4l/Mnhqa =en6h -----END PGP SIGNATURE----- From petithug@acm.org Mon Aug 20 13:46:11 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8693821F8602 for ; Mon, 20 Aug 2012 13:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1YiAlwVw1hp for ; Mon, 20 Aug 2012 13:46:10 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 731BA21F85B4 for ; Mon, 20 Aug 2012 13:46:10 -0700 (PDT) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 189A9202AA; Mon, 20 Aug 2012 20:46:08 +0000 (UTC) Message-ID: <5032A20E.8080300@acm.org> Date: Mon, 20 Aug 2012 13:46:06 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6 MIME-Version: 1.0 To: Todd Herman References: <20120820182408.0AA6CB1E004@rfc-editor.org> <50328540.4060009@acm.org> <000c01cd7f11$ec3329c0$c4997d40$@verizon.net> In-Reply-To: <000c01cd7f11$ec3329c0$c4997d40$@verizon.net> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: behave@ietf.org Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5389 (3327) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 20:46:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/20/2012 01:25 PM, Todd Herman wrote: >> -----Original Message----- From: Marc Petit-Huguenin >> [mailto:petithug@acm.org] Sent: Monday, August 20, 2012 2:43 PM To: >> taherman@verizon.net Cc: behave@ietf.org Subject: Re: [BEHAVE] [Technical >> Errata Reported] RFC5389 (3327) >> > > On 08/20/2012 11:24 AM, RFC Errata System wrote: >>>> >>>> The following errata report has been submitted for RFC5389, "Session >>>> Traversal Utilities for NAT (STUN)". >>>> >>>> -------------------------------------- You may review the report >>>> below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=5389&eid=3327 >>>> >>>> -------------------------------------- Type: Technical Reported by: >>>> Todd Herman >>>> >>>> Section: 15.3 >>>> >>>> Original Text ------------- The USERNAME attribute is used for >>>> message integrity. It identifies the username and password >>>> combination used in the message-integrity check. >>>> >>>> Corrected Text -------------- >>>> >>>> >>>> Notes ----- There is no explanation or description as to where this >>>> "password" comes from. The statement indicates that the password is >>>> also part of the username field but that may not actually be true >>>> according to additional research I conducted and other portions of >>>> the > specification. >>>> >>>> If the password is part of this field than it should be explicitly >>>> noted how the two values are concatenated. If this is not accurate, >>>> than the "and password combination" portion should be removed. >>>> > > Why didn't you sent an email to the authors or to the behave mailing-list > before polluting the Errata database? > >> My apologies. I did not intend to pollute the errata database with such >> a stupid thing. > > The statement does *not* indicate that the password is part of the username > field, just that the username field *identifies* the password (as >> in > "querying a database" or "searching in an hash map"). > >> I would argue that the statement "It identifies the username and >> password combination used" can be easily read that the attribute contains >> both username and password information. If the intention is that the >> USERNAME attribute contains only the username the I don't think password >> should be mentioned here at all as it could lead to confusion. [The Concise Oxford Dictionary, tenth edition] identify v. (-ies, -ied) 3 (identify someone/thing with) associate someone or something closely with. I am not a native English speaker, and as an implementer I am also known for insisting in precision in the language used in RFCs, but I see no ambiguity here. - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQMqIMAAoJECnERZXWan7EmfoP/2KA+UvOgwnU6BSaib1UCgmL GVbkUzyzZDVv7/gzvuiY9p0Y0UUVtCHm9bLxNy98x1C1Puu/rzH0j/sTCZIEXjY9 yZ5/16j6h9X47sePp6BCHurhsd2PoB38sQZCltS4M7qzp+VnJvx/sYGikEoLIi+3 ux/j/aXXHG4yA5OaX5LggmxY+x5phbOl02xiyHfqazVWvOMbkueMni8C5QGp25pz Z5HKvYNoy2Vq42lyorgaFCb3XuWj8kUXbOgyNsSSUrxJ7ZamwYJxQfFnw0/Vwint bMBRcsSm0XLK18cGddgDaLc4il1M3ffjjktS3ECvT/ogGlzJEYPeH7E2oAZAbQUb /2RIRG/zruCerN2144PyTVzLkPrFM/bHIRo12Rf1TXIgx/ZCcrbeNj+O80gDntYi 6M634xF+eUPFB8ygYFp+sXJVwnH0cGg35WmXwy/FdtOP+X7yx7FRdu0VJhFL2NhU 17bGMIvl2m/9db0QJx4LlEcZPjDbD9NbMJHBGi7GrQWxBjcE+/6LtunCQyBNofVj mNo3J5VE5xmicFTEzk1+Z/gyCWOIkksStVQ2iY10Y6f3NFbJmd2UX7nFS4+7fFNL 9h85EvrKm1tzRy/YSHVqq1scQG4V9UTytEPeanMXhbbVGfF3NfN96V79aJuvwKZW 4w9sYmp8aoTjKjMkcal8 =SUJ3 -----END PGP SIGNATURE----- From repenno@cisco.com Mon Aug 20 19:24:50 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A14011E80A4; Mon, 20 Aug 2012 19:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.359 X-Spam-Level: X-Spam-Status: No, score=-10.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c6kaIoevcoA; Mon, 20 Aug 2012 19:24:50 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id CF8EC11E809A; Mon, 20 Aug 2012 19:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=1268; q=dns/txt; s=iport; t=1345515890; x=1346725490; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7SBdHV1CANR2yheI8fGQKBCf6P+VtyPARXz7HQgL5M8=; b=RlCpaSnUdCuZn5a+zpKomLTUxtbyJEpKhVI4dsB0x0PVGStN4DFRgak7 kbsCfEWAVtFFCm3TzL0V4lQK0QZ5IPih7Isw3uvPfl5MO9NeKrEZO3h4W gdf7670UcK/z/OWCCSAz2IYaKUFvYvmhqbPpsJT6jLhqVHBpfnCJ4y5Kt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPzvMlCtJXG9/2dsb2JhbABFuluBB4InEgEnPxIBPkIlAgQOHgIHh2uZJKA6kicDlVCOLIFmgmE X-IronPort-AV: E=Sophos;i="4.77,799,1336348800"; d="scan'208";a="113624791" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 21 Aug 2012 02:24:49 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q7L2Onuj000372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Aug 2012 02:24:49 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Mon, 20 Aug 2012 21:24:48 -0500 From: "Reinaldo Penno (repenno)" To: "pcp@ietf.org" Thread-Topic: Comment on REQ-9A of LSN requirements (PCP) Thread-Index: AQHNf0Qj9EHhzDdBA0m9uGbHtDuTEQ== Date: Tue, 21 Aug 2012 02:24:48 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.155.70.70] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19128.001 x-tm-as-result: No--27.330000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <58B31ABC34AD18438D06D0F7FA90A4F5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: [BEHAVE] Comment on REQ-9A of LSN requirements (PCP) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 02:24:50 -0000 "A. It MUST NOT permit the lifetime of a mapping to be reduced beyond its current life or be set to zero (deleted)." In the case of renumbering how a CPE that gets a new address can delete stale mappings of the previous user of that IP address? Given some of the requirements, it can not. Before mapping 'nonce' CPE/host could just send a delete all and we would rely on ingress filtering to make sure things are okay. But now with the mapping nonce the new owner of an IP address has no way of deleting the stale mappings because it does not know the nonce. If renumbering happens frequently (as in some networks as short as 30 minutes) and there are many PCP MAP mappings from each CPE/host, then soon depending on the Lifetime there will be no more resources on CGN/AFTR/Firewall due to stale mappings A possible solution would be for DHCP Server or other provisioning server to send a PCP message with THIRD_PARTY to delete all MAP mappings. But again, it does not know the nonce. Not to mention that coupling provisioning and PCP becomes a barrier for adoption. Reducing the 'lifetime' defeats the purpose of having PCP. Not sure of any solution given all requirements in place. Thanks, Reinaldo From mohamed.boucadair@orange.com Mon Aug 20 22:57:27 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FA511E80BF; Mon, 20 Aug 2012 22:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtDlGJmijUyO; Mon, 20 Aug 2012 22:57:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5DA21F8596; Mon, 20 Aug 2012 22:57:26 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 7380F325058; Tue, 21 Aug 2012 07:57:25 +0200 (CEST) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 555AE27C046; Tue, 21 Aug 2012 07:57:25 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Tue, 21 Aug 2012 07:57:04 +0200 From: To: "Reinaldo Penno (repenno)" , "pcp@ietf.org" Date: Tue, 21 Aug 2012 07:57:03 +0200 Thread-Topic: Comment on REQ-9A of LSN requirements (PCP) Thread-Index: AQHNf0Qj9EHhzDdBA0m9uGbHtDuTEZdjwh9w Message-ID: <94C682931C08B048B7A8645303FDC9F36E5229895A@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.21.10322 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Comment on REQ-9A of LSN requirements (PCP) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 05:57:27 -0000 Hi Reinaldo, Stale mapping is a real issue which may consume per-user quota. The issue, = exacerbated with the use of nonce, is discussed in detail in http://tools.i= etf.org/html/draft-boucadair-pcp-failure-04 which proposes also a mechanism= to recover the mapping nonce. Below some excerpts from the draft: Section 2.2 of the failure draft reads: If the same port number is used but a distinct mapping nonce is generated, the request will be rejected with a NOT_AUTHORIZED error with the Lifetime of the error indicating duration of that existing mapping. This issue can be solved if the PCP Client uses GET OpCode (Section 4) to recover the mapping nonce used when instantiating the mapping. Section 2.3 of the failure draft reads: If the PCP Client does not store the explicit dynamic mappings and new mapping nonces are assigned, the PCP Server will reject to refresh these mappings. This issue can be solved if the PCP Client uses GET OpCode (Section 4) to recover the mapping nonces used when instantiating the mappings. Section 2.6 of the failure draft reads: On the reboot of the IWF, if no mapping table is maintained in a permanent storage, "stale" mappings will be maintained by the PCP Server and per-user quota will be consumed. This is even exacerbated if new mapping nonces are assigned by the IWF. This issue can be soften by synchronizing the mapping table owing to the invocation of the GET OpCode defined in Section 4. =20 Cheers, Med >-----Message d'origine----- >De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la=20 >part de Reinaldo Penno (repenno) >Envoy=E9 : mardi 21 ao=FBt 2012 04:25 >=C0 : pcp@ietf.org >Cc : behave@ietf.org >Objet : [pcp] Comment on REQ-9A of LSN requirements (PCP) > >"A. It MUST NOT permit the lifetime of a mapping to be > reduced beyond its current life or be set to zero > (deleted)." > >In the case of renumbering how a CPE that gets a new address can delete >stale mappings of the previous user of that IP address? Given=20 >some of the >requirements, it can not. > >Before mapping 'nonce' CPE/host could just send a delete all=20 >and we would >rely on ingress filtering to make sure things are okay. But=20 >now with the >mapping nonce the new owner of an IP address has no way of deleting the >stale mappings because it does not know the nonce. > >If renumbering happens frequently (as in some networks as short as 30 >minutes) and there are many PCP MAP mappings from each=20 >CPE/host, then soon >depending on the Lifetime there will be no more resources on >CGN/AFTR/Firewall due to stale mappings > >A possible solution would be for DHCP Server or other=20 >provisioning server >to send a PCP message with THIRD_PARTY to delete all MAP mappings. But >again, it does not know the nonce. Not to mention that coupling >provisioning and PCP becomes a barrier for adoption. Reducing the >'lifetime' defeats the purpose of having PCP. > >Not sure of any solution given all requirements in place. > >Thanks, > >Reinaldo > > > > > > >_______________________________________________ >pcp mailing list >pcp@ietf.org >https://www.ietf.org/mailman/listinfo/pcp >= From repenno@cisco.com Tue Aug 21 03:16:16 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13BA21F869F; Tue, 21 Aug 2012 03:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id te13NuTc2qu3; Tue, 21 Aug 2012 03:16:16 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 08BDF21F86AA; Tue, 21 Aug 2012 03:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=repenno@cisco.com; l=4098; q=dns/txt; s=iport; t=1345544176; x=1346753776; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Is0UXtokxZhdjn1dl1Px5qvMWmQwvRaljdEzNakuJ/4=; b=h9wME8djdoFAyD/HhA45LA3X6IVggWG79SwcrxRMistVjHL61W3c0Sa2 4BEl2nBEWyOHJMnmZ46chOdEwtSWYOpiuWN5Ch/yShOuIIP7IhASzwdRc jgFppbrU/19Y40ftrINnhpApFuq5hds0akojNtUm8xPzY1hYKZOWZ2e+x k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAANfM1CtJV2Y/2dsb2JhbABFul+BB4IgAQEBBAEBAQ8BWwsMBgEIEQMBAiguCxQJCAIEAQ0FGQIHh2sLmROgPIsIHASGfAOIGo04gRSNGYFmgmGBWQ X-IronPort-AV: E=Sophos;i="4.77,801,1336348800"; d="scan'208";a="113695432" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 21 Aug 2012 10:16:15 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7LAGFBL002027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Aug 2012 10:16:15 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Tue, 21 Aug 2012 05:16:15 -0500 From: "Reinaldo Penno (repenno)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" Thread-Topic: Comment on REQ-9A of LSN requirements (PCP) Thread-Index: AQHNf0Qj9EHhzDdBA0m9uGbHtDuTEZdjwh9wgAApyoA= Date: Tue, 21 Aug 2012 10:16:14 +0000 Message-ID: In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E5229895A@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [10.21.74.208] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19128.005 x-tm-as-result: No--52.736900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "behave@ietf.org" Subject: Re: [BEHAVE] Comment on REQ-9A of LSN requirements (PCP) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 10:16:16 -0000 -----Original Message----- From: Date: Tue, 21 Aug 2012 07:57:03 +0200 To: Reinaldo Penno , "pcp@ietf.org" Cc: "behave@ietf.org" Subject: RE: Comment on REQ-9A of LSN requirements (PCP) >Hi Reinaldo, > >Stale mapping is a real issue which may consume per-user quota. The >issue, exacerbated with the use of nonce, is discussed in detail in >http://tools.ietf.org/html/draft-boucadair-pcp-failure-04 which proposes >also a mechanism to recover the mapping nonce. Below some excerpts from >the draft: > >Section 2.2 of the failure draft reads: > > If the same port number is used but a distinct mapping nonce is > generated, the request will be rejected with a NOT_AUTHORIZED error > with the Lifetime of the error indicating duration of that existing > mapping. This issue can be solved if the PCP Client uses GET OpCode > (Section 4) to recover the mapping nonce used when instantiating the > mapping. That's a good idea but unless the PCP Client recovers all nonces by trying to map to all internal ports the problem would still exist, right? I mean, only those mappings that resulted in collisions would be recovered. Alos, wouldn't this opcode allow an attacker to recover opcodes belonging to others. But anyway, the problem we are facing is due to base spec which is at WGLC. If something, we need to solve there. =20 > >Section 2.3 of the failure draft reads: > > If the PCP Client does not store the explicit dynamic mappings and > new mapping nonces are assigned, the PCP Server will reject to > refresh these mappings. This issue can be solved if the PCP Client > uses GET OpCode (Section 4) to recover the mapping nonces used when > instantiating the mappings. > >Section 2.6 of the failure draft reads: > > On the reboot of the IWF, if no mapping table is maintained in a > permanent storage, "stale" mappings will be maintained by the PCP > Server and per-user quota will be consumed. This is even exacerbated > if new mapping nonces are assigned by the IWF. This issue can be > soften by synchronizing the mapping table owing to the invocation of > the GET OpCode defined in Section 4. >=20 > >Cheers, >Med > >>-----Message d'origine----- >>De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la >>part de Reinaldo Penno (repenno) >>Envoy=E9 : mardi 21 ao=FBt 2012 04:25 >>=C0 : pcp@ietf.org >>Cc : behave@ietf.org >>Objet : [pcp] Comment on REQ-9A of LSN requirements (PCP) >> >>"A. It MUST NOT permit the lifetime of a mapping to be >> reduced beyond its current life or be set to zero >> (deleted)." >> >>In the case of renumbering how a CPE that gets a new address can delete >>stale mappings of the previous user of that IP address? Given >>some of the >>requirements, it can not. >> >>Before mapping 'nonce' CPE/host could just send a delete all >>and we would >>rely on ingress filtering to make sure things are okay. But >>now with the >>mapping nonce the new owner of an IP address has no way of deleting the >>stale mappings because it does not know the nonce. >> >>If renumbering happens frequently (as in some networks as short as 30 >>minutes) and there are many PCP MAP mappings from each >>CPE/host, then soon >>depending on the Lifetime there will be no more resources on >>CGN/AFTR/Firewall due to stale mappings >> >>A possible solution would be for DHCP Server or other >>provisioning server >>to send a PCP message with THIRD_PARTY to delete all MAP mappings. But >>again, it does not know the nonce. Not to mention that coupling >>provisioning and PCP becomes a barrier for adoption. Reducing the >>'lifetime' defeats the purpose of having PCP. >> >>Not sure of any solution given all requirements in place. >> >>Thanks, >> >>Reinaldo >> >> >> >> >> >> >>_______________________________________________ >>pcp mailing list >>pcp@ietf.org >>https://www.ietf.org/mailman/listinfo/pcp From philip_matthews@magma.ca Tue Aug 21 14:26:46 2012 Return-Path: X-Original-To: behave@ietfa.amsl.com Delivered-To: behave@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F1921F865D for ; Tue, 21 Aug 2012 14:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.715 X-Spam-Level: X-Spam-Status: No, score=-1.715 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0xCSuk2Nypp for ; Tue, 21 Aug 2012 14:26:46 -0700 (PDT) Received: from mail-06.primus.ca (mail16.primus.ca [216.254.141.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3458721F8613 for ; Tue, 21 Aug 2012 14:26:45 -0700 (PDT) Received: from [74.198.165.20] (helo=[172.20.10.2]) by mail-06.primus.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1T3vyB-0005VC-1d; Tue, 21 Aug 2012 17:26:42 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Philip Matthews In-Reply-To: <000d01cd7f12$6a6f4b70$3f4de250$@verizon.net> Date: Tue, 21 Aug 2012 17:26:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <39B999A4-C35D-48AA-81D8-A85D5E4E647C@magma.ca> References: <20120820182408.0AA6CB1E004@rfc-editor.org> <50328253.3020009@viagenie.ca> <000d01cd7f12$6a6f4b70$3f4de250$@verizon.net> To: Todd Herman X-Mailer: Apple Mail (2.1084) X-Authenticated: philip_matthews - ([172.20.10.2]) [74.198.165.20] Cc: behave@ietf.org, jdrosen@cisco.com, rohan@ekabal.com, wes@mti-systems.com, dthaler@microsoft.com, dwing@cisco.com, martin.stiemerling@neclab.eu, 'RFC Errata System' Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5389 (3327) X-BeenThere: behave@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: mailing list of BEHAVE IETF WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 21:26:47 -0000 Indeed, the USERNAME attribute contains just the username. What the text is trying to say is that there could be multiple = (username,password) combinations, and that each combination is uniquely = identified by the username. That is, one cannot have multiple passwords = per username. That is why it says "It identifies the username and password combination". - Philip On 2012-08-20, at 16:28 , Todd Herman wrote: > It is somewhat spelled out in section 10 and I understand that the = USERNAME > attribute contains the user name. My point is that since it contains = only > the USERNAME then I feel "password" shouldn't be mentioned in 15.3 as = it > could cause confusion. The statement in 15.3, "It identifies the = username > and password" seems contradictory to the other portions of the = document > which seem to imply that the password comes from somewhere else and = that the > USERNAME attribute contains just the user name. >=20 > I apologize for causing issues by submitting this errata. I will = refrain > from doing so in the future. >=20 >> -----Original Message----- >> From: Simon Perreault [mailto:simon.perreault@viagenie.ca] >> Sent: Monday, August 20, 2012 2:31 PM >> To: RFC Errata System >> Cc: jdrosen@cisco.com; rohan@ekabal.com; philip_matthews@magma.ca; >> dwing@cisco.com; wes@mti-systems.com; martin.stiemerling@neclab.eu; >> dthaler@microsoft.com; behave@ietf.org; taherman@verizon.net >> Subject: Re: [BEHAVE] [Technical Errata Reported] RFC5389 (3327) >>=20 >> Isn't it clearly spelled out in section 10? >>=20 >> As an implementer I fail to see what the problem is. >>=20 >> Simon >>=20 >> Le 20/08/2012 2:24 PM, RFC Errata System a =E9crit : >>>=20 >>> The following errata report has been submitted for RFC5389, "Session >>> Traversal Utilities for NAT (STUN)". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D5389&eid=3D3327 >>>=20 >>> -------------------------------------- >>> Type: Technical >>> Reported by: Todd Herman >>>=20 >>> Section: 15.3 >>>=20 >>> Original Text >>> ------------- >>> The USERNAME attribute is used for message integrity. It = identifies >>> the username and password combination used in the = message-integrity >>> check. >>>=20 >>> Corrected Text >>> -------------- >>>=20 >>>=20 >>> Notes >>> ----- >>> There is no explanation or description as to where this "password" = comes >> from. The statement indicates that the password is also part of the >> username field but that may not actually be true according to = additional >> research I conducted and other portions of the specification. >>>=20 >>> If the password is part of this field than it should be explicitly = noted > how >> the two values are concatenated. If this is not accurate, than the = "and >> password combination" portion should be removed. >>>=20 >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or = rejected. >>> When a decision is reached, the verifying party (IESG) can log in to >>> change the status and edit the report, if necessary. >>>=20 >>> -------------------------------------- >>> RFC5389 (draft-ietf-behave-rfc3489bis-18) >>> -------------------------------------- >>> Title : Session Traversal Utilities for NAT (STUN) >>> Publication Date : October 2008 >>> Author(s) : J. Rosenberg, R. Mahy, P. Matthews, D. Wing >>> Category : PROPOSED STANDARD >>> Source : Behavior Engineering for Hindrance Avoidance >>> Area : Transport >>> Stream : IETF >>> Verifying Party : IESG >>> _______________________________________________ >>> Behave mailing list >>> Behave@ietf.org >>> https://www.ietf.org/mailman/listinfo/behave >>>=20 >=20 >=20