From ippm-bounces@ietf.org Tue Apr 1 13:37:26 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39923A6EA2; Tue, 1 Apr 2008 13:37:26 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495B63A6EBA for ; Tue, 1 Apr 2008 13:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.262 X-Spam-Level: X-Spam-Status: No, score=-4.262 tagged_above=-999 required=5 tests=[AWL=2.337, 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 HaqKRXi99fzB for ; Tue, 1 Apr 2008 13:37:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4BAAD3A6EBC for ; Tue, 1 Apr 2008 13:37:24 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2008 13:37:23 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m31KbLum011188 for ; Tue, 1 Apr 2008 13:37:21 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m31KbLgE011256 for ; Tue, 1 Apr 2008 20:37:21 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 13:37:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 13:37:10 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TWAMP test timeout questions thread-index: AciTcPOeSLWOpqyhSQylG9lqnpb6QQABlHZgABGPrTAAHi+EAA== References: <47C2C60C.9070807@ripe.net> <47DE8A2D.40409@ripe.net><90EB10B5-EB5F-4364-910C-5E3ED6F607F4@internet2.edu><7978BDEA-5A54-4A81-A7DF-FF6B72B99156@internet2.edu> From: "Murtaza Chiba (mchiba)" To: "IETF IPPM WG" X-OriginalArrivalTime: 01 Apr 2008 20:37:20.0850 (UTC) FILETIME=[2F0CB320:01C89438] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1423; t=1207082241; x=1207946241; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mchiba@cisco.com; z=From:=20=22Murtaza=20Chiba=20(mchiba)=22=20 |Subject:=20TWAMP=20test=20timeout=20questions |Sender:=20; bh=u5nt57hEUT5qxaq/KDnqMCZP9NnX8gsu+ZEHKnNm4/g=; b=vGjFIUgt3rBcELipoRzVBkd1K2rmTSmLQ6thTFspTW9P3/ZRkfyMfmRg/N AnpI/aYxtKAR27Nan4FTwTtTvBEqlPNPx8garsf7NxObtik39r0GJbu2YQ+g Y7AiZzzYWJ; Authentication-Results: sj-dkim-3; header.From=mchiba@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [ippm] TWAMP test timeout questions X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org To the authors of TWAMP, In the section on Reflector Behaviour it is mentioned that the reflector needs to reject packets that are outside of the timeout range. Is the timeout only effective after the Stop sessions is received or is it that even before the stop sessions the Reflector is to reject packets with sender timestamp outside the timeout range? The latter expects that the one-way delay is known a-priori. I interpret it as the former rather than the latter, that is, timeout is ONLY effective after a stop sessions is received, which is as mentioned in the section on starting Test Streams. Another question we have is can we individually stop sessions? It seems that all sessions with a Request-Session-Ack have to be stopped. Also we never got a response to the question as to what is actually included in the Stop sessions packet? It seems that session headers are not to be included, however, the same section say Skip Range and Number of Packets are to be set to 0! Another un-answered question is whether HMAC covers 96 octets or 32 octets for encrypted mode reflected packets. Further, another un-answered question is whether the auth mode encryption should cover the Sender Sequence Number in the reply packet since if that is not protected it can lead to tampered roundtrip statistics. Also, should start messages include SIDs? Thanks, -Murtaza _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Apr 1 21:41:00 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85B803A6B1D; Tue, 1 Apr 2008 21:41:00 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42703A6A7F for ; Tue, 1 Apr 2008 21:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.865, 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 ZNt4ZB9ey0oo for ; Tue, 1 Apr 2008 21:40:57 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 7B7AF3A69D1 for ; Tue, 1 Apr 2008 21:40:57 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 25so2593224wfa.31 for ; Tue, 01 Apr 2008 21:40:57 -0700 (PDT) Received: by 10.142.180.17 with SMTP id c17mr5570676wff.76.1207111257166; Tue, 01 Apr 2008 21:40:57 -0700 (PDT) Received: from 212.56.242.10.in-addr.arpa ( [208.54.15.231]) by mx.google.com with ESMTPS id 31sm1760750wff.7.2008.04.01.21.40.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Apr 2008 21:40:55 -0700 (PDT) Message-Id: From: Lars Eggert To: ext Henk Uijterwaal In-Reply-To: <47C2C60C.9070807@ripe.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 21:40:53 -0700 References: <47C2C60C.9070807@ripe.net> X-Mailer: Apple Mail (2.919.2) Cc: IETF IPPM WG Subject: [ippm] AD review: draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi, I'm trying to to the AD review that normally happens after a WG requests publication early, such that it overlaps with WGLC. For this document, that hasn't happened, but at least I'm not very late, because it is still being discussed. Summary: Not quite ready. My main concern is around the TWAMP light variant, and there are a number of small things where the document would be improved by a more careful description or some editorial changes. Detailed comments: INTRODUCTION, paragraph 10: Nit: s/Measurment/Measurement/ (everywhere in the footer) INTRODUCTION, paragraph 11: > The IP Performance Metrics (IPPM) working group's One-way Active > Measurement Protocol [RFC4656] (OWAMP) provides a common protocol > for measuring one-way metrics between network devices. Rephrase the first sentence to not talk about the IPPM WG - it's ephemeral and for the RFC it doesn't matter where OWAMP came from. (In other words, cut "IP Performance Metrics (IPPM) working group's".) Section 1., paragraph 1: > The IETF IP Performance Metrics (IPPM) working group has completed > a draft standard for the round-trip delay [RFC2681] metric. IPPM > has also completed a protocol for the control and collection of > one-way measurements, the One-way Active Measurement Protocol > (OWAMP) [RFC4656]. See above - rephrase to not talk about IPPM. Section 1., paragraph 2: > Two-way measurements are common in IP networks, primarily because > time accuracy is less demanding for round-trip delay I don't quite understand what you mean by "time accuracy is less demanding". Section 2., paragraph 0: > 2. Protocol Overview This section is almost word-by-word identical to a big chunk of section 1.2. Merge? Section 3., paragraph 2: > All OWAMP [RFC4656] Control messages except for the Fetch-Session > command apply to TWAMP. Does "apply to" mean that TWAMP implementations MUST implement all these OWAMP control messages? If yes, say so with RFC2119 terms. Section 3.5, paragraph 2: > In order to distinguish the session as a two-way versus a one-way > measurement session the first octet of the Request-Session command > MUST be set to 5. Value of 5 indicates that this is a > Request-Session for a two-way metrics measurement session. That text is a bit misleading. An "OWAMP Request-Session" will always have 1 in that octet. What you're doing here is defining a "Request-TW-Session" command (this is how it's called in the IANA registry below) that looks and is mostly processed like an OWAMP message, but has a 5 in the first octet (because OWAMP uses first octet codes 2-4 for other commands.) You should make sure that you call the command "Request-TW-Session" everywhere in the document, to be consistent with the code allocated in the IANA registry. Section 3.5, paragraph 3: > In TWAMP, the first octet is referred to as the Command Number, and > the Command Number is a recognized extension mechanism. Readers are > encouraged to consult the TWAMP Command Number Registry to > determine if there have been additional values assigned. I'd argue that because this document creates a registry that in addition to TWAMP also covers OWAMP, it should update RFC4656, if only to alert implementers of OWAMP that an IANA registry exists that matters for OWAMP but that RFC4656 doesn't descibe. Section 3.5, paragraph 4: > If a TWAMP server receives an unexpected command number, it SHOULD > respond with the Accept field set to 3 (meaning "Some aspect of > request is not supported") in the Server-Start message. s/SHOULD/MUST/ (or else explain in which cases the SHOULD may disregarded) Section 3.5, paragraph 6: > Both Conf-Sender field and Conf-Receiver field MUST be set to 0 > since the Session-Reflector will both receive and send packets, and > the roles are established according to which host initiates the TCP > connection for control. The server MUST interpret any non-zero > value as zero. If the field is not zero, something is clearly wrong with the peer - shouldn't the session be aborted? Section 3.5, paragraph 10: > They MAY be set to 0, in which case the IP addresses used for the > Session-Sender to Session-Reflector Control Message exchange MUST > be used in the test packets. This seems to be a difference to OWAMP. Any particular reason why? (For TWAMP Light?) Section 3.5, paragraph 14: > Point (DSCP) as defined in [RFC2474]. The same value of DCSP MUST Nit: s/DCSP/DSCP/ Section 3.9, paragraph 1: > The purpose of TWAMP is measurement of two-way metrics. Two-way > measurements do not rely on packet level data collected by the > Session-Reflector such as sequence number, timestamp, and TTL. As > such the protocol does not require the retrieval of packet level > data from the Server and the Fetch-Session command is not defined > in TWAMP. Since Fetch-Session is defined in OWAMP and TWAMP is a variant of that, I'd be good to define what TWAMP should do if it somehow receives a Fetch-Session message. (Suggestion: stop fail.) Section 4.2.1, paragraph 21: > Implementation note: Naturally, the key schedule for each > TWAMP-Test session MAY be set up only once per session, not once > per packet. s/MAY/MUST/ (or lowercase, since it's about an implementation choice and not the specification) Section 5.1, paragraph 3: > The responder follows the Session-Reflctor behavior of TWAMP as Nit: s/Session-Reflctor/Session-Reflector/ Section 5.2, paragraph 0: > 5.2 TWAMP Light If I understand this correctly, TWAMP Light requires a different processing than Complete TWAMP. The "implementers guide" section is not the place to define specification variants, especially because it's not clear that Light and Complete imoplementations can interoperate without knowing which variant the other side is using. If the two variants are desired by the WG, they need to be described in the specification, and there needs to be a mechanism such that Light and Complete implementations can figure out what variant they're talking to at the other end. Section 8.1, paragraph 1: > IANA will create an TWAMP-Control Command registry. TWAMP- Control > commands are specified by the first octet in OWAMP-Control messages > as shown in section 3.4 of [RFC4656], and modified by this > document. Thus this registry may contain sixteen possible values. Elsewhere in this document, the term "command number" is used. Please use one term consistently throughout the document. Section 8.4, paragraph 2: > Value Description Semantics Definition > 0 Reserved > 1 Forbidden > 2 Start-Sessions RFC4656, Section 3.7 > 3 Stop-Sessions RFC4656, Section 3.8 > 4 Fetch-Session RFC4656, Section 3.9 > 5 Request-TW-Session this document, Section 3.5 > 6 Experimentation undefined, see Section 8.3. This document doesn't specify how implementations shold react if Reserved or Forbidden values are received. (Is there a difference?) Section 10.1, paragraph 1: > [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., > Zekauskas, M., "A One-way Active Measurement Protocol > (OWAMP)", draft-ietf-ippm-owdp-11.txt, October 2004. s/draft-ietf-ippm-owdp-11.txt/RFC 4656/ Section 10.1, paragraph 5: > [RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing > an IANA Considerations Section in RFCs, RFC 2474, > October 1998. s/RFC 2474/RFC 2434/ (copy&paste error?) _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From hekmagnaridersvez@magnariders.com Wed Apr 2 06:02:01 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2232E3A6A1B; Wed, 2 Apr 2008 06:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.995 X-Spam-Level: **** X-Spam-Status: No, score=4.995 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033] 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 9hUKnGn6hzTT; Wed, 2 Apr 2008 06:02:00 -0700 (PDT) Received: from dxb-b138587.alshamil.net.ae (dxb-b138587.alshamil.net.ae [86.98.88.233]) by core3.amsl.com (Postfix) with ESMTP id D256B28C4EB; Wed, 2 Apr 2008 05:59:52 -0700 (PDT) Received: from [86.98.88.233] by mail.domainnameservers.net; Wed, 2 Apr 2008 04:59:54 -0800 Date: Wed, 2 Apr 2008 04:59:54 -0800 From: "Selma Denton" X-Mailer: The Bat! (v2.11) Educational Reply-To: hekmagnaridersvez@magnariders.com X-Priority: 3 (Normal) Message-ID: <513892957.08868425477326@magnariders.com> To: agentx-archive@lists.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------33AE90901D33A7C4" ------------33AE90901D33A7C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Our purpose is to render low price PC and Macintosh lawful soft and computer solutions for anyone's budget. Whether you are a corporate client, an owner of small enterprise, or go shopping for your home PC, we suppose we'll assist you. SEE WHAT WE GOT TO OFFER! http://shelbysodenkq945.blogspot.com ------------33AE90901D33A7C4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Our purpose is to render low price PC and Macintosh lawful soft and computer solutions for anyone's budget.
Whether you are a corporate client, an owner of small enterprise,
or go shopping for your home PC, we suppose we'll assist you.
SEE WHAT WE GOT TO OFFER!
http://shelbysodenkq945.blogspot.com
------------33AE90901D33A7C4-- From ippm-bounces@ietf.org Wed Apr 2 14:18:07 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C48E3A6B91; Wed, 2 Apr 2008 14:18:07 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6AE53A6B91 for ; Wed, 2 Apr 2008 14:18:05 -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 o17Osv8ZkNzA for ; Wed, 2 Apr 2008 14:18:04 -0700 (PDT) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by core3.amsl.com (Postfix) with ESMTP id BA5883A6B78 for ; Wed, 2 Apr 2008 14:18:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 45FA247CA2; Wed, 2 Apr 2008 17:18:06 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14442-03; Wed, 2 Apr 2008 17:18:06 -0400 (EDT) Received: from 24-116-168-167.cpe.cableone.net (24-116-168-167.cpe.cableone.net [24.116.168.167]) by basie.internet2.edu (Postfix) with ESMTP id 9617047C1D; Wed, 2 Apr 2008 17:18:05 -0400 (EDT) From: "Jeff W. Boote" To: Lars Eggert In-Reply-To: References: <47C2C60C.9070807@ripe.net> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 15:18:04 -0600 X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: by mail.internet2.edu virus scanner Cc: ext Henk Uijterwaal , IETF IPPM WG Subject: Re: [ippm] AD review: draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org On Apr 1, 2008, at 10:40 PM, Lars Eggert wrote: > Section 3.5, paragraph 3: >> In TWAMP, the first octet is referred to as the Command Number, > and >> the Command Number is a recognized extension mechanism. Readers > are >> encouraged to consult the TWAMP Command Number Registry to >> determine if there have been additional values assigned. > > I'd argue that because this document creates a registry that in > addition to TWAMP also covers OWAMP, it should update RFC4656, if > only > to alert implementers of OWAMP that an IANA registry exists that > matters for OWAMP but that RFC4656 doesn't descibe. The IANA registry should not be for OWAMP as well. There is no reason to tie these together unless TWAMP is done in a way that actually extends the OWAMP protocol. It is not defined that way. As it is, it just makes use of many of the same messages. (See the archives for previous discussions on this.) It is possible that OWAMP will be extended in the future and may need a registry. But, since TWAMP does not extend the OWAMP protocol, these registries should be separate. jeff -- Jeff W. Boote boote@internet2.edu _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Apr 2 21:23:12 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFCC528C31C; Wed, 2 Apr 2008 21:23:12 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D63EA28C31C for ; Wed, 2 Apr 2008 21:23:11 -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 QuFkv2Ws1ILm for ; Wed, 2 Apr 2008 21:23:11 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.186]) by core3.amsl.com (Postfix) with ESMTP id D252E28C262 for ; Wed, 2 Apr 2008 21:23:10 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id c10so1523551nfd.39 for ; Wed, 02 Apr 2008 21:23:04 -0700 (PDT) Received: by 10.66.221.5 with SMTP id t5mr1088643ugg.83.1207196584302; Wed, 02 Apr 2008 21:23:04 -0700 (PDT) Received: from ?192.168.255.2? ( [88.114.157.111]) by mx.google.com with ESMTPS id u6sm5886570uge.83.2008.04.02.21.22.57 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Apr 2008 21:23:02 -0700 (PDT) Message-Id: <1099F730-5C51-4337-9887-D52E997B1444@nokia.com> From: Lars Eggert To: ext Jeff W. Boote In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 07:22:49 +0300 References: <47C2C60C.9070807@ripe.net> X-Mailer: Apple Mail (2.919.2) Cc: ext Henk Uijterwaal , IETF IPPM WG Subject: Re: [ippm] AD review: draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi, On 2008-4-3, at 0:18, ext Jeff W. Boote wrote: > The IANA registry should not be for OWAMP as well. There is no > reason to tie these together unless TWAMP is done in a way that > actually extends the OWAMP protocol. It is not defined that way. As > it is, it just makes use of many of the same messages. (See the > archives for previous discussions on this.) but the current draft does tie together OWAMP and TWAMP, because the registry definition in Section 8.4 lists RFC4656 as the defining document for codepoints 2-4, and then adds codepoints 5-6 as TWAMP ones. This means that a hypothetical OWAMP revision can, for example, never use codepoint 5 for a new OWAMP message. If OWAMP and TWAMP are supposed to remain completely separate, then they need two registries (which is what you say below). I also note that the entire document is written in a way that basically says "TWAMP is like OWAMP except for these changes in processing/message formats". At least to me, that doesn't drive home the point that OWAMP and TWAMP are completely separate protocols. Writing the specification in this way may minimize editing overhead, but it does leave the reader (well, me at least) with the impression that OWAMP and TWAMP are tightly related. > It is possible that OWAMP will be extended in the future and may > need a registry. But, since TWAMP does not extend the OWAMP > protocol, these registries should be separate. Lars _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Apr 3 08:10:39 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4378D28C6DF; Thu, 3 Apr 2008 08:10:39 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E89A328C6CF for ; Thu, 3 Apr 2008 08:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.865, 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 j7BZxIHgQr8W for ; Thu, 3 Apr 2008 08:10:37 -0700 (PDT) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by core3.amsl.com (Postfix) with ESMTP id 27ED13A67D4 for ; Thu, 3 Apr 2008 08:10:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 6641347F03; Thu, 3 Apr 2008 11:10:39 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27057-06; Thu, 3 Apr 2008 11:10:39 -0400 (EDT) Received: from [192.168.1.101] (unknown [69.92.68.112]) by basie.internet2.edu (Postfix) with ESMTP id 93B8947F15; Thu, 3 Apr 2008 11:10:38 -0400 (EDT) From: "Jeff W. Boote" To: Lars Eggert In-Reply-To: <1099F730-5C51-4337-9887-D52E997B1444@nokia.com> References: <47C2C60C.9070807@ripe.net> <1099F730-5C51-4337-9887-D52E997B1444@nokia.com> Message-Id: <59A73FCE-30CA-4007-B580-2770B7B625DB@internet2.edu> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 09:10:37 -0600 X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: by mail.internet2.edu virus scanner Cc: ext Henk Uijterwaal , IETF IPPM WG Subject: Re: [ippm] AD review: draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org On Apr 2, 2008, at 10:22 PM, Lars Eggert wrote: > Hi, > > On 2008-4-3, at 0:18, ext Jeff W. Boote wrote: >> The IANA registry should not be for OWAMP as well. There is no >> reason to tie these together unless TWAMP is done in a way that >> actually extends the OWAMP protocol. It is not defined that way. As >> it is, it just makes use of many of the same messages. (See the >> archives for previous discussions on this.) > > but the current draft does tie together OWAMP and TWAMP, because the > registry definition in Section 8.4 lists RFC4656 as the defining > document for codepoints 2-4, and then adds codepoints 5-6 as TWAMP > ones. This means that a hypothetical OWAMP revision can, for > example, never use codepoint 5 for a new OWAMP message. If OWAMP and > TWAMP are supposed to remain completely separate, then they need two > registries (which is what you say below). The protocols are specified as using different port numbers. Therefore OWAMP should be absolutely free to use codepoint 5. > I also note that the entire document is written in a way that > basically says "TWAMP is like OWAMP except for these changes in > processing/message formats". At least to me, that doesn't drive home > the point that OWAMP and TWAMP are completely separate protocols. > Writing the specification in this way may minimize editing overhead, > but it does leave the reader (well, me at least) with the impression > that OWAMP and TWAMP are tightly related. I agree. If you look back in the archives in my review of the TWAMP draft I indicated on list what would need to be done to make TWAMP an extension of the OWAMP protocol instead of simply a new protocol reusing much of the OWAMP message structure. The authors chose to put TWAMP on a different port instead of making TWAMP implementations actually support OWAMP. That is the point at which they were 'separated'. jeff -- Jeff W. Boote boote@internet2.edu _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Apr 3 09:43:42 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E0828C290; Thu, 3 Apr 2008 09:43:42 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C8C28C4DF for ; Thu, 3 Apr 2008 09:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.34 X-Spam-Level: X-Spam-Status: No, score=-4.34 tagged_above=-999 required=5 tests=[AWL=2.259, 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 devPgRWIiQ0i for ; Thu, 3 Apr 2008 09:43:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 85D5F28C2B8 for ; Thu, 3 Apr 2008 09:43:35 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2008 09:43:39 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m33GhdtT006864; Thu, 3 Apr 2008 09:43:39 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m33GhdnT021808; Thu, 3 Apr 2008 16:43:39 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 09:43:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 09:43:27 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on encrypting the start-time field thread-index: AciVpXG0JWgpjXBMR4GUogCtcqepOQABBzgA References: <47C2C60C.9070807@ripe.net> From: "Murtaza Chiba (mchiba)" To: "Jeff W. Boote" X-OriginalArrivalTime: 03 Apr 2008 16:43:38.0673 (UTC) FILETIME=[DE01CA10:01C895A9] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4225; t=1207241019; x=1208105019; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mchiba@cisco.com; z=From:=20=22Murtaza=20Chiba=20(mchiba)=22=20 |Subject:=20RE=3A=20Question=20on=20encrypting=20the=20star t-time=20field |Sender:=20; bh=ZTtP8amiNhvEBvOmXN2u069Kx1U68uQr+6S3ICPhs3Q=; b=jsjH0BggSUJmjVMr6Ar5ik6q25QKaUEDkxn+vSFAaXFNZADlHgZR/7pd2P RYey6AcG7ZKDxdRdYlrg2N32b4WgLruRQ2zltwL5qM3rB33mqwRuz6y5WTIF tk3YTOcMXz; Authentication-Results: sj-dkim-2; header.From=mchiba@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: IETF IPPM WG Subject: Re: [ippm] Question on encrypting the start-time field X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi Jeff, > -----Original Message----- > From: Jeff W. Boote [mailto:boote@internet2.edu] > Sent: Thursday, April 03, 2008 9:12 AM > To: Murtaza Chiba (mchiba) > Subject: Re: Question on encrypting the start-time field > > Hi Murtaza, > > On Apr 2, 2008, at 7:20 PM, Murtaza Chiba (mchiba) wrote: > > > Hi Jeff, > > OWAMP mentions that the Start-Time field in the > Server-Start message > > is to be encrypted in the authenticated and encrypted modes. > > Since it is only 8 octets I am assuming that it is to be > encrypted in > > the ECB mode and not the CBC mode. Is that correct? > > This is discussed in section 3.1, page 10 (last para) - page 11(first > para): > > Start-Time is a timestamp representing the time when the current > instantiation of the server started operating. (For example, in a > multi-user general purpose operating system, it could be the time > when the server process was started.) If Accept is > non-zero, Start- > Time SHOULD be set so that all of its bits are zeros. In > authenticated and encrypted modes, Start-Time is encrypted as > described in Section 3.4, "OWAMP-Control Commands", > unless Accept is > non-zero. (Authenticated and encrypted mode cannot be > entered unless > the control connection can be initialized.) > > Now if you read that forward reference to section 3.4: > > In authenticated or encrypted mode (which are identical as far as > OWAMP-Control is concerned, and only differ in OWAMP-Test), all > further communications are encrypted with the AES > Session-key (using > CBC mode) and authenticated with HMAC Session-key. The client > encrypts everything it sends through the just-established OWAMP- > Control connection using stream encryption with Client-IV > as the IV. > Correspondingly, the server encrypts its side of the > connection using > Server-IV as the IV. > > The IVs themselves are transmitted in cleartext. > Encryption starts > with the block immediately following the block containing the IV. > The two streams (one going from the client to the server and one > going back) are encrypted independently, each with its own IV, but > using the same key (the AES Session-key). > Thanks for the clarification, so the Start-Time is encrypted in CBC mode and sent in the Server-Start message. The HMAC in the first Accept-Session message also includes the Start-Time field in the HMAC calculation. That puts a requirement to maintain state and also puts a processing distinction between the first Accept-Session and the rest if multiple Request-Sessions are received by the Server. I do see that it does provide a confirmation of the decoded value, why was a HMAC not added to the Server-Start message itself? That way each message would have been a distinct unit. > Therefore 'encrypted stream' starts immediately following the > IV. CBC mode from there until communication ends. > So is the IV only used during the Server-Start message and the rest of the stream is encrypted using the last ciphertext from the previous message? Thanks, -Murtaza > Also relevant to this is the fact that this block is included > in the computation of the HMAC, even though the value of the > HMAC does not end up getting sent until the next message. See > section 3.2: > > Each HMAC sent covers everything sent in a given > direction between the previous HMAC (but not including > it) and up to > the beginning of the new HMAC. This way, once encryption > is set up, > each bit of the OWAMP-Control connection is authenticated > by an HMAC > exactly once. > > jeff > > P.S. Can we keep protocol clarification questions on list? > This would ensure that it gets archived, and therefore > someone else can more easily find the answers later. Also, it > would allow more objective others to decide if any of these > clarifications warrant an errata. > -- > Jeff W. Boote > boote@internet2.edu > > > > > _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Apr 3 10:44:50 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A32D28C6F2; Thu, 3 Apr 2008 10:44:50 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A0328C6F2 for ; Thu, 3 Apr 2008 10:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.832, 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 0j4f2syyuRHX for ; Thu, 3 Apr 2008 10:44:48 -0700 (PDT) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by core3.amsl.com (Postfix) with ESMTP id D084B28C6C2 for ; Thu, 3 Apr 2008 10:44:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 46EE047E01; Thu, 3 Apr 2008 13:44:52 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10654-10; Thu, 3 Apr 2008 13:44:52 -0400 (EDT) Received: from [192.168.1.101] (unknown [69.92.68.112]) by basie.internet2.edu (Postfix) with ESMTP id 8D91547CFE; Thu, 3 Apr 2008 13:44:51 -0400 (EDT) From: "Jeff W. Boote" To: "Murtaza Chiba (mchiba)" In-Reply-To: References: <47C2C60C.9070807@ripe.net> Message-Id: <6867B003-50C7-4AE5-B02A-00656B9E4B32@internet2.edu> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 11:44:50 -0600 X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: by mail.internet2.edu virus scanner Cc: IETF IPPM WG Subject: Re: [ippm] Question on encrypting the start-time field X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org On Apr 3, 2008, at 10:43 AM, Murtaza Chiba (mchiba) wrote: > > Thanks for the clarification, so the Start-Time is encrypted in CBC > mode and sent in the Server-Start message. The HMAC in the first > Accept-Session message also includes the Start-Time field in the HMAC > calculation. That puts a requirement to maintain state and also > puts a > processing distinction between the first Accept-Session and the rest > if > multiple Request-Sessions are received by the Server. I do see > that it > does provide a confirmation of the decoded value, why was a HMAC not > added to the Server-Start message itself? That way each message > would > have been a distinct unit. To be honest, it was an oversight. We did not originally use an HMAC in the protocol, it was added later after our first security review. We forgot to add a field to this message and we didn't notice until after the RFC had already been approved. The only downside to this problem is that you can't validate the 'up time' of the daemon until after making another request. There is no real security risk here so we decided not to mess with it. We only added the 'up time' field as a convenience anyway, it is not required for the protocol to work. This is not ideal, but it is not bad either. BTW. You already have to save state across messages for the CBC mode so saving state for the HMAC as well is not that big of a deal. (Although I sympathize, I noticed this oversight when I was adding the HMAC code into our implementation and did not originally have the HMAC state variables saved across the functions handling individual messages.) >> Therefore 'encrypted stream' starts immediately following the >> IV. CBC mode from there until communication ends. >> > > So is the IV only used during the Server-Start message and the > rest of the stream is encrypted using the last ciphertext from the > previous message? Yes. jeff -- Jeff W. Boote boote@internet2.edu _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Apr 3 11:32:07 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAD973A6AE0; Thu, 3 Apr 2008 11:32:07 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ADAA28C710 for ; Thu, 3 Apr 2008 11:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.412 X-Spam-Level: X-Spam-Status: No, score=-4.412 tagged_above=-999 required=5 tests=[AWL=2.187, 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 UVAE+W+IG48E for ; Thu, 3 Apr 2008 11:32:02 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 82FC028C705 for ; Thu, 3 Apr 2008 11:31:36 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 03 Apr 2008 11:31:40 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m33IVeIa004486; Thu, 3 Apr 2008 11:31:40 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m33IVecg013947; Thu, 3 Apr 2008 18:31:40 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 11:31:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 11:31:29 -0700 Message-ID: In-Reply-To: <6867B003-50C7-4AE5-B02A-00656B9E4B32@internet2.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on encrypting the start-time field thread-index: AciVsm7CPlQJBRflSiqcO6wLpF90PAABRBdg References: <47C2C60C.9070807@ripe.net> <6867B003-50C7-4AE5-B02A-00656B9E4B32@internet2.edu> From: "Murtaza Chiba (mchiba)" To: "Jeff W. Boote" X-OriginalArrivalTime: 03 Apr 2008 18:31:40.0343 (UTC) FILETIME=[F5622470:01C895B8] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2900; t=1207247500; x=1208111500; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mchiba@cisco.com; z=From:=20=22Murtaza=20Chiba=20(mchiba)=22=20 |Subject:=20RE=3A=20Question=20on=20encrypting=20the=20star t-time=20field |Sender:=20; bh=1HXFhD2jjJmtracL2LnkGWBvpRKEKtlXLmoao3JUTk4=; b=ntoKm4LIHm7yNo91pHygLUV0tjwNl7Fzl0mRdlMSAfFoQsb3rQtlOUiD9Q GwIJQKcMJG9AuH6gvjmRJjIKJBGZiwy25TPhM/l7EREGKzkMlACnwiK6AAfM qgL8GXvwN1; Authentication-Results: sj-dkim-4; header.From=mchiba@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: IETF IPPM WG Subject: Re: [ippm] Question on encrypting the start-time field X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org > -----Original Message----- > From: Jeff W. Boote [mailto:boote@internet2.edu] > Sent: Thursday, April 03, 2008 10:45 AM > To: Murtaza Chiba (mchiba) > Cc: IETF IPPM WG > Subject: Re: Question on encrypting the start-time field > > > On Apr 3, 2008, at 10:43 AM, Murtaza Chiba (mchiba) wrote: > > > > Thanks for the clarification, so the Start-Time is encrypted in CBC > > mode and sent in the Server-Start message. The HMAC in the first > > Accept-Session message also includes the Start-Time field > in the HMAC > > calculation. That puts a requirement to maintain state and > also puts > > a processing distinction between the first Accept-Session > and the rest > > if > > multiple Request-Sessions are received by the Server. I do see > > that it > > does provide a confirmation of the decoded value, why was a HMAC not > > added to the Server-Start message itself? That way each message > > would > > have been a distinct unit. > > To be honest, it was an oversight. We did not originally use > an HMAC in the protocol, it was added later after our first > security review. > We forgot to add a field to this message and we didn't notice > until after the RFC had already been approved. > > The only downside to this problem is that you can't validate > the 'up time' of the daemon until after making another > request. There is no real security risk here so we decided > not to mess with it. We only added the 'up time' field as a > convenience anyway, it is not required for the protocol to > work. This is not ideal, but it is not bad either. > > BTW. You already have to save state across messages for the > CBC mode so saving state for the HMAC as well is not that big > of a deal. > (Although I sympathize, I noticed this oversight when I was > adding the HMAC code into our implementation and did not > originally have the HMAC state variables saved across the > functions handling individual > messages.) Well, the real problem I see with this is that the there can be no concurrent processing of messages within a connection if the CBC mode spans messages. Of course the RFC precludes this, but it would really be nice if the CBC mode were limited to exchanges for a given SID so that parallel processing could be done across SIDs instead of forcing a new connection. :( -Murtaza > > >> Therefore 'encrypted stream' starts immediately following > the IV. CBC > >> mode from there until communication ends. > >> > > > > So is the IV only used during the Server-Start message > and the rest > > of the stream is encrypted using the last ciphertext from > the previous > > message? > > Yes. > > jeff > -- > Jeff W. Boote > boote@internet2.edu > > > > > _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Apr 3 11:56:41 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94DD3A6C56; Thu, 3 Apr 2008 11:56:41 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CCF428C1C1 for ; Thu, 3 Apr 2008 11:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.801, 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 3T5zjtUX8Wgs for ; Thu, 3 Apr 2008 11:56:35 -0700 (PDT) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by core3.amsl.com (Postfix) with ESMTP id E89243A6C56 for ; Thu, 3 Apr 2008 11:56:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id C963147F9E; Thu, 3 Apr 2008 14:56:38 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18125-09; Thu, 3 Apr 2008 14:56:38 -0400 (EDT) Received: from [192.168.1.101] (unknown [69.92.68.112]) by basie.internet2.edu (Postfix) with ESMTP id 17BCC47F7C; Thu, 3 Apr 2008 14:56:38 -0400 (EDT) From: "Jeff W. Boote" To: "Murtaza Chiba (mchiba)" In-Reply-To: References: <47C2C60C.9070807@ripe.net> <6867B003-50C7-4AE5-B02A-00656B9E4B32@internet2.edu> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 3 Apr 2008 12:56:37 -0600 X-Mailer: Apple Mail (2.919.2) X-Virus-Scanned: by mail.internet2.edu virus scanner Cc: IETF IPPM WG Subject: Re: [ippm] Question on encrypting the start-time field X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org On Apr 3, 2008, at 12:31 PM, Murtaza Chiba (mchiba) wrote: > Well, the real problem I see with this is that the there can be no > concurrent processing of messages within a connection if the CBC mode > spans messages. Of course the RFC precludes this, but it would really > be nice if the CBC mode were limited to exchanges for a given SID so > that parallel processing could be done across SIDs instead of > forcing a > new connection. :( TCP is a stream protocol. OWAMP-Control is over TCP. You can't parallelize the reading/writing of a stream socket. Given this, I don't see any benefit to confusing the encryption by making it stateful relative to SID. It is stateful with respect to the stream. jeff -- Jeff W. Boote boote@internet2.edu _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Thu Apr 3 12:37:38 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 490F628C18B; Thu, 3 Apr 2008 12:37:38 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CD453A699E for ; Thu, 3 Apr 2008 12:37:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.481 X-Spam-Level: X-Spam-Status: No, score=-4.481 tagged_above=-999 required=5 tests=[AWL=2.118, 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 O0rysHe7GOiH for ; Thu, 3 Apr 2008 12:37:24 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id E06AB3A6D95 for ; Thu, 3 Apr 2008 12:36:06 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Apr 2008 12:36:11 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m33JaB2N002812; Thu, 3 Apr 2008 12:36:11 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m33JaBnu026653; Thu, 3 Apr 2008 19:36:11 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 12:36:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 12:35:59 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on encrypting the start-time field thread-index: AciVvHTOXPrqdzV4TfSRx5ROUrQ9AwABH9KA References: <47C2C60C.9070807@ripe.net> <6867B003-50C7-4AE5-B02A-00656B9E4B32@internet2.edu> From: "Murtaza Chiba (mchiba)" To: "Jeff W. Boote" X-OriginalArrivalTime: 03 Apr 2008 19:36:10.0751 (UTC) FILETIME=[F85388F0:01C895C1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1450; t=1207251371; x=1208115371; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mchiba@cisco.com; z=From:=20=22Murtaza=20Chiba=20(mchiba)=22=20 |Subject:=20RE=3A=20Question=20on=20encrypting=20the=20star t-time=20field |Sender:=20; bh=dJ90zdwXgOiLbXrGxvdDbuEuuo5wVlgtqg0SO6Ixw58=; b=chOrF9NldfQ1RuiqleYa+pZ/41NSFOpMjXZ9WJam2Cgq9AktJ367Cdl2kL oTZpcsPi3Ypui0N4iM9UmigoLRtR3uL5SX2iHdt2hPHzwCCJRvCDRTAtyWdm fJ7sXo9mAq; Authentication-Results: sj-dkim-3; header.From=mchiba@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: IETF IPPM WG Subject: Re: [ippm] Question on encrypting the start-time field X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org > -----Original Message----- > From: Jeff W. Boote [mailto:boote@internet2.edu] > Sent: Thursday, April 03, 2008 11:57 AM > To: Murtaza Chiba (mchiba) > Cc: IETF IPPM WG > Subject: Re: Question on encrypting the start-time field > > > On Apr 3, 2008, at 12:31 PM, Murtaza Chiba (mchiba) wrote: > > Well, the real problem I see with this is that the there can be no > > concurrent processing of messages within a connection if > the CBC mode > > spans messages. Of course the RFC precludes this, but it > would really > > be nice if the CBC mode were limited to exchanges for a > given SID so > > that parallel processing could be done across SIDs instead > of forcing > > a new connection. :( > > TCP is a stream protocol. OWAMP-Control is over TCP. You > can't parallelize the reading/writing of a stream socket. Yes, but what the stream looks like can be decided by the application. It would be nice to have the capability to do the Request-Session->Start-Session->Stop-Session for multiple SIDs in parallel. Instead of the current method Request-Session(+)->StartAll-Sessions->StopAll-Sessions. -Murtaza > Given this, I don't see any benefit to confusing the > encryption by making it stateful relative to SID. It is > stateful with respect to the stream. > > jeff > -- > Jeff W. Boote > boote@internet2.edu > > > > > _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From c.kneuer@schotbruch.de Thu Apr 3 23:30:58 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 859D828C279; Thu, 3 Apr 2008 23:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -61.313 X-Spam-Level: X-Spam-Status: No, score=-61.313 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_ROLEX=5, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] 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 nyKn0lJt6jK6; Thu, 3 Apr 2008 23:30:57 -0700 (PDT) Received: from cpe-76-172-109-43.socal.res.rr.com (cpe-76-172-109-43.socal.res.rr.com [76.172.109.43]) by core3.amsl.com (Postfix) with SMTP id 80D3928C633; Thu, 3 Apr 2008 23:30:43 -0700 (PDT) X-Originating-IP: 196.204.40.128 by smtp.76.172.109.43; Fri, 04 Apr 2008 02:30:41 -0500 Message-ID: From: "Duane Christian" Reply-To: "Duane Christian" To: iporpr-bounces@ietf.org Subject: You and a Rolex watch Date: Fri, 04 Apr 2008 02:30:41 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Prestige Replicas is now bigger and better than ever before! I'm sure you're familiar with this popular replica store, so I'm glad to announce that Prestige Replicas has been completely redesigned and now offers not only the highest quality replica watches but also handbags and jewelry! In addition, they're running a 15% special these days when you buy two watches! There's never been a better time to buy a replica watch, especially a Tag Heuer! With prices as low as $200, and the store unmatched privacy assurance guarantee, I'm sure you won't want to wait to get your superior quality Tag Heuer replica! http://www.Lou1s Vuitton/ From cableware@cableware.com.br Sat Apr 5 18:23:43 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D46F3A699D; Sat, 5 Apr 2008 18:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -88.381 X-Spam-Level: X-Spam-Status: No, score=-88.381 tagged_above=-999 required=5 tests=[BAYES_60=1, FS_REPLICA=0.994, HELO_EQ_FR=0.35, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, USER_IN_WHITELIST=-100] 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 Lay6oskBf4ng; Sat, 5 Apr 2008 18:23:42 -0700 (PDT) Received: from m85.net195-132-122.noos.fr (m85.net195-132-122.noos.fr [195.132.122.85]) by core3.amsl.com (Postfix) with SMTP id 3AE883A686B; Sat, 5 Apr 2008 18:23:20 -0700 (PDT) X-Originating-IP: 44.192.0.19 by smtp.195.132.122.85; Sat, 05 Apr 2008 21:23:19 -0500 Message-ID: From: "Francisco Mcgill" Reply-To: "Francisco Mcgill" To: iporpr-bounces@ietf.org Subject: One of a kind replicas Date: Sat, 05 Apr 2008 21:23:19 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit X-Antivirus: avast! (VPS 080405-0, 05/04/2008), Outbound message X-Antivirus-Status: Clean Have you seen the latest Gucci handbags, from their 2008 collection? They're so beautiful and stylish... and so expensive! But I just found this store, Prestige Replicas, that offers them at just a fraction of their cost. Granted, they're replicas, but they look just like the real deal, and the prices are so low, that now you can have not just one Gucci bag, but two or three of them! The best part is that at Prestige Replicas they have such a wide collection, organized by styles, that you'll feel like a kid in a candy store! Seriously, if you love Gucci bags, you will adore Prestige Replicas! http://www.Ch0pard/ From jyxnanettebarattahel@nanettebaratta.com Sun Apr 6 23:21:11 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3833A6BA2; Sun, 6 Apr 2008 23:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.826 X-Spam-Level: **** X-Spam-Status: No, score=4.826 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_GREY=0.25] 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 hwGAlW2s4FMA; Sun, 6 Apr 2008 23:21:10 -0700 (PDT) Received: from [116.71.243.214] (unknown [116.71.243.214]) by core3.amsl.com (Postfix) with ESMTP id 30C023A6BAE; Sun, 6 Apr 2008 23:21:09 -0700 (PDT) Received: from [116.71.243.214] by eforward4.name-services.com; Mon, 7 Apr 2008 11:21:21 +0500 Date: Mon, 7 Apr 2008 11:21:21 +0500 From: "Sheryl Hoyt" X-Mailer: The Bat! (v2.00.5) Personal Reply-To: jyxnanettebarattahel@nanettebaratta.com X-Priority: 3 (Normal) Message-ID: <276381876.00023547464370@nanettebaratta.com> To: agentx-archive@lists.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------86E6E6E6E67291C" ------------86E6E6E6E67291C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Our main purpose is to guarantee PC and Mac lawful software and computer solutions of low cost for anyone. Whether you're a corporate customer, a small enterprise proprietor, or shopping for your home personal computer, we believe we'll assist you. CHECK WHAT WE HAVE TO OFFER! http://frankiesubletteps539.googlepages.com ------------86E6E6E6E67291C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Our main purpose is to guarantee PC and Mac lawful software and computer solutions of low cost for anyone.
Whether you're a corporate customer, a small enterprise proprietor,
or shopping for your home personal computer, we believe we'll assist you.
CHECK WHAT WE HAVE TO OFFER!
http://frankiesubletteps539.googlepages.com
------------86E6E6E6E67291C-- From ippm-bounces@ietf.org Thu Apr 10 10:08:28 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6383A695D; Thu, 10 Apr 2008 10:08:28 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F6D3A68A8 for ; Thu, 10 Apr 2008 10:08:26 -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 CN+XpEpwePpJ for ; Thu, 10 Apr 2008 10:08:25 -0700 (PDT) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by core3.amsl.com (Postfix) with ESMTP id 081CF3A695D for ; Thu, 10 Apr 2008 10:08:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 1652E47E33; Thu, 10 Apr 2008 13:08:46 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15057-08; Thu, 10 Apr 2008 13:08:46 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id EF32C47E29; Thu, 10 Apr 2008 13:08:45 -0400 (EDT) Message-ID: <47FE499C.2060107@internet2.edu> Date: Thu, 10 Apr 2008 13:08:44 -0400 From: Matthew J Zekauskas User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: IETF IPPM WG X-Enigmail-Version: 0.95.6 X-Virus-Scanned: by mail.internet2.edu virus scanner Cc: Henk Uijterwaal , Matt Zekauskas Subject: [ippm] Minutes and presentations from IETF-71 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org An initial version of the minutes and the presentations from IETF-71 are all available at (search for "IPPM"). If you have corrections, please send them to the chairs or the list. --Matt _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From negoneshotfirearmskap@oneshotfirearms.com Fri Apr 11 00:08:25 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E3828C11D; Fri, 11 Apr 2008 00:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.131 X-Spam-Level: *** X-Spam-Status: No, score=3.131 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, URIBL_GREY=0.25] 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 X9wYYfIattk5; Fri, 11 Apr 2008 00:08:20 -0700 (PDT) Received: from host115-214-static.46-85-b.business.telecomitalia.it (host115-214-static.46-85-b.business.telecomitalia.it [85.46.214.115]) by core3.amsl.com (Postfix) with ESMTP id 484653A6E34; Fri, 11 Apr 2008 00:08:02 -0700 (PDT) Received: from [85.46.214.115] by oneshotfirearms.com; Fri, 11 Apr 2008 08:08:42 +0100 Date: Fri, 11 Apr 2008 08:08:42 +0100 From: "Rosalind Bowles" X-Mailer: The Bat! (v2.00) Educational Reply-To: negoneshotfirearmskap@oneshotfirearms.com X-Priority: 3 (Normal) Message-ID: <138193221.06221903751090@oneshotfirearms.com> To: agentx-archive@lists.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------86E67215AF21C705" ------------86E67215AF21C705 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Our goal is to assure low price PC and Mac lawful soft and computer solutions any could afford. Whether you are a corporate purchaser, a small enterprise possessor, or go shopping for your own home PC, we suppose we can assist you. CHECK WHAT WE HAVE TO OFFER! http://earnestinermsf689.googlepages.com ------------86E67215AF21C705 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit Our goal is to assure low price PC and Mac lawful soft and computer solutions any could afford.
Whether you are a corporate purchaser, a small enterprise possessor,
or go shopping for your own home PC, we suppose we can assist you.
CHECK WHAT WE HAVE TO OFFER!
http://earnestinermsf689.googlepages.com
------------86E67215AF21C705-- From ca@nemecos.net Wed Apr 16 05:06:51 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EB183A6EB4; Wed, 16 Apr 2008 05:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -75.277 X-Spam-Level: X-Spam-Status: No, score=-75.277 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] 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 NUgHp6heqvMH; Wed, 16 Apr 2008 05:06:50 -0700 (PDT) Received: from 200-127-251-94.cab.prima.net.ar (200-127-251-94.cab.prima.net.ar [200.127.251.94]) by core3.amsl.com (Postfix) with SMTP id 0D76C3A6F64; Wed, 16 Apr 2008 05:06:42 -0700 (PDT) X-Originating-IP: 12.39.26.176 by smtp.200.127.251.94; Wed, 16 Apr 2008 08:07:17 -0500 Message-ID: From: "Elijah Oneal" Reply-To: "Elijah Oneal" To: iporpr-bounces@ietf.org Subject: You can save 80% Date: Wed, 16 Apr 2008 08:07:17 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Breitling watch is a statement not just of wealth, but of sophistication... it's a way to show the world that you are a man in charge of your life and that you know exactly what you want. Surely, among those things you do want is a bigger budget. So, why not kill two birds with one stone? Getting a replica Breitling wristwatch and keeping your budget practically untouched! http://lepazory61704.blogspot.com/ Thanks to Prestige Replicas it is now possible! With an astonishing collection of replica Breitling timepieces at rock bottom prices, Selissia will make the delights of quality watches lovers. It offers excellent quality timepieces at unsurpassed prices; a privacy-assured guarantee, incomparable customer service, and what's better: 15% off when you buy two watches! http://lepazory61704.blogspot.com/ From ippm-bounces@ietf.org Wed Apr 16 14:36:56 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31DB3A6814; Wed, 16 Apr 2008 14:36:56 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A856B3A6814 for ; Wed, 16 Apr 2008 14:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 jYG+O6-xXJXw for ; Wed, 16 Apr 2008 14:36:54 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 4EA433A67D7 for ; Wed, 16 Apr 2008 14:36:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-5.tower-120.messagelabs.com!1208381849!26865534!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 26354 invoked from network); 16 Apr 2008 21:37:29 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-5.tower-120.messagelabs.com with AES256-SHA encrypted SMTP; 16 Apr 2008 21:37:29 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m3GLbSlb013922 for ; Wed, 16 Apr 2008 14:37:29 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m3GLbNYL013839 for ; Wed, 16 Apr 2008 14:37:24 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m3GLbMBD026427 for ; Wed, 16 Apr 2008 16:37:23 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m3GLbINU026332 for ; Wed, 16 Apr 2008 16:37:19 -0500 Message-Id: <200804162137.m3GLbINU026332@klph001.kcdc.att.com> Received: from acmt.att.com (dyp004256dys.mt.att.com[135.16.251.231](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20080416213718gw100l7okde>; Wed, 16 Apr 2008 21:37:18 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Apr 2008 17:37:18 -0400 To: Henk Uijterwaal From: Al Morton In-Reply-To: <47DE8A2D.40409@ripe.net> References: <47C2C60C.9070807@ripe.net> <47DE8A2D.40409@ripe.net> Mime-Version: 1.0 Cc: IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 11:11 AM 3/17/2008, Henk Uijterwaal wrote: >This concludes the WGLC for this draft. Two issues were raised on the >list. We'll ask the authors to respond to those on the list and to >include fixes in the draft. After that we'll move the document forward. The new issues list seems to have stopped growing for now, so (without discussing any resolutions among co-authors, yet) the text below lists & addresses Murtaza's comments with four areas identified for "ACTION" in the TWAMP text. (Thanks Murtaza, and thanks to Jeff for the OWAMP clarifications). Lars' AD review is next... Al >At 02:02 PM 3/10/2008, Murtaza Chiba (mchiba) wrote: > >While on the subject, the section 4.2.1 perhaps needs some >reconsideration. It seems that only the first 16 bytes are covered in >the authenticated mode, this leaves the Sender Sequence number open to >manipulation. That's the trade-off between Authenticated mode vs. Encrypted mode. >For the encrypted mode, one paragraph mentions first 96 Octets are >encrypted, however, another paragraph mentions that the HMAC only covers >the portion encrypted which is 32 bytes. The portion of test packet covered by HMAC is 32 octets in Encrypted *mode*. AES-CBC covers 96 octets (encryption). >At 04:09 PM 3/25/2008, Murtaza Chiba (mchiba) wrote: >Some more questions on TWAMP draft. > >Q1) Section 3.8 Stop Sessions mentions that command can only be sent by >the Session-Sender. I believe the authors meant Control-Client as the >Session-Sender does not exchange a control command. ACTION >>>Yes (editorial fix) >Q2) In the same section it mentions that NO session description record >can be sent, however, it also mentions that the Next SeqNo and Number of >Skip Ranges MUST be set to 0 and those are part of the session >description record! I am assuming the authors ONLY meant to exclude >the no. Skip Ranges record. The statement above appears to be correct, the header of the session description record is needed to convey the SID of the session to stop. ACTION >>>>It appears we need to clarify the text in 3.8. We have to clarify that TWAMP Stop-Sessions is like Start-Sessions, neither has SID and therefore no ability to stop individual test sessions. Otherwise, NO sessions would be stopped (because it is valid in OWAMP to send Stop-Sessions Command with zero session description records and apparently this would not affect any sessions?) BUT, OWAMP also has text that indicates each Session that has not been stopped MUST be counted in "Number of Sessions" field and therefore (the paragraph above that text requires) that every active session have a session description record (see page 22). Thus, it appears that the Stop-Session Command stops ALL active sessions. >Q3) Is it possible to add a SID to a Start-Sessions message? That >would help limit the meaning of Active to be per SID allowing for >different SIDs to be started and stopped on demand. Sometimes one may >want to start a Test Stream in response to an observed network >behaviour. It would be a new feature. Possible to add to draft-morton-ippm-more-twamp-... >Q4) If the above is acceptable then I propose adding a >Control-Command-type field to all response messages and hence the Accept >field should be the second field. It also entails adding a SID in the >Requests and Responses. More on the Q3 Q4 topic to add SID to Start Sessions: At 11:55 AM 3/26/2008, Murtaza Chiba (mchiba) wrote: >Hi Jeff, > If the protocol wants to optimize on starting all test-streams >at once then a flag can be added to indicate ALL or can be indicated by >a SID == 0. Start-Sessions can also include multiple SIDs to allow for >starting particular sessions. > > >At 03:15 PM 3/28/2008, Murtaza Chiba (mchiba) wrote: >Another clarification question. > >For Test packets the draft is not clear on the order of encryption and >authentication. One can assume that the intent was to first encrypt >and then authenticate the fields which is the reverse of Control >packets. It would be nice to see clarification text in the section >4.2.1 of TWAMP and section 4.1.2 of OWAMP. ACTION >>>HMAC is first, then Encryption. At 04:50 PM 3/31/2008, Jeff W. Boote wrote: >On Mar 31, 2008, at 1:42 PM, Murtaza Chiba (mchiba) wrote: > > > > Yes, but as I said, in authenticated mode the HMAC could be purely for > > data integrity not security concerns. > >The purpose of authenticated mode is to allow data integrity and >security just like encrypted mode. However, we wanted to make the >measurements as accurate as possible. So, the timestamp portion of the >packet is not encrypted in authenticated mode, therefore you are not >timing how long it takes to encrypt the packet AND then send it. You >are able to exclude the encryption time from this. In fully encrypted >mode, you end up including encryption time in your measurement. Anyone >'snooping' on those packets is only able to see the 'send' timestamp, >not the sequence number. This is a trade-off situation. > > > Besides the concern for cracking is inconsistent with the Command > > exchange authenticated mode that has no encryption. Which leads > > one to > > believe that authenticated mode is purely for integrity check. > > Although, I agree that there will be fewer command exchanges, however, > > admins tend to have same passwords across all devices! > >What makes you say that there is no encryption? There is no difference >between authenticated mode and encrypted mode in the control >communication. And in the test packet format, the first block of the >packet is encrypted in both authenticated mode and encrypted mode. ACTION ***** IMPORTANT POINT (possibly make this clear in the text) ***** >The *only* thing different from authenticated mode and encrypted mode is >that the second block of the test packets are not encrypted in >authenticated mode. And that is only to permit the timestamp to be >fetched after encryption for the sender. > >jeff At 04:37 PM 4/1/2008, Murtaza Chiba (mchiba) wrote: >To the authors of TWAMP, > >In the section on Reflector Behaviour it is mentioned that the reflector >needs to reject packets that are outside of the timeout range. Is the >timeout only effective after the Stop sessions is received or is it that >even before the stop sessions the Reflector is to reject packets with >sender timestamp outside the timeout range? The latter expects that >the one-way delay is known a-priori. > >I interpret it as the former rather than the latter, that is, timeout is >ONLY effective after a stop sessions is received, which is as mentioned >in the section on starting Test Streams. Yes, the text in section 3.5 describing the Timeout Field confirms the latter. >Another question we have is can we individually stop sessions? It >seems that all sessions with a Request-Session-Ack have to be stopped. Yes. (see Q2 above) >Also we never got a response to the question as to what is actually >included in the Stop sessions packet? It seems that session headers >are not to be included, however, the same section say Skip Range and >Number of Packets are to be set to 0! (see Q2 above) >Another un-answered question is whether HMAC covers 96 octets or 32 >octets for encrypted mode reflected packets. As above, the portion covered by HMAC is 32 octets in Encrypted *mode*. >Further, another un-answered question is whether the auth mode >encryption should cover the Sender Sequence Number in the reply packet >since if that is not protected it can lead to tampered roundtrip >statistics. That's the trade-off of Authenticated mode vs. Encrypted mode. >Also, should start messages include SIDs? That would have to be a new feature, it would need to address the points below, but possible to add to draft-morton-ippm-more-twamp-... At 03:35 PM 4/3/2008, Murtaza Chiba (mchiba) wrote: > > -----Original Message----- > > From: Jeff W. Boote [mailto:boote@internet2.edu] > > Sent: Thursday, April 03, 2008 11:57 AM > > To: Murtaza Chiba (mchiba) > > Cc: IETF IPPM WG > > Subject: Re: Question on encrypting the start-time field > > > > > > On Apr 3, 2008, at 12:31 PM, Murtaza Chiba (mchiba) wrote: > > > Well, the real problem I see with this is that the there can be no > > > concurrent processing of messages within a connection if the CBC mode > > > spans messages. Of course the RFC precludes this, but it would really > > > be nice if the CBC mode were limited to exchanges for a given SID so > > > that parallel processing could be done across SIDs instead of forcing > > > a new connection. :( > > > > TCP is a stream protocol. OWAMP-Control is over TCP. You > > can't parallelize the reading/writing of a stream socket. > >Yes, but what the stream looks like can be decided by the application. >It would be nice to have the capability to do the >Request-Session->Start-Session->Stop-Session for multiple SIDs in >parallel. Instead of the current method >Request-Session(+)->StartAll-Sessions->StopAll-Sessions. > >-Murtaza > > > > Given this, I don't see any benefit to confusing the > > encryption by making it stateful relative to SID. It is > > stateful with respect to the stream. > > > > jeff > > -- _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Fri Apr 18 12:43:57 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76BA43A6D76; Fri, 18 Apr 2008 12:43:57 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10143A6CE2 for ; Fri, 18 Apr 2008 12:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.196 X-Spam-Level: X-Spam-Status: No, score=-103.196 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 JSpnoyPBab6F for ; Fri, 18 Apr 2008 12:43:54 -0700 (PDT) Received: from mail121.messagelabs.com (mail121.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id ED8303A69A5 for ; Fri, 18 Apr 2008 12:43:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-15.tower-121.messagelabs.com!1208547831!16761342!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 19895 invoked from network); 18 Apr 2008 19:43:51 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-15.tower-121.messagelabs.com with AES256-SHA encrypted SMTP; 18 Apr 2008 19:43:51 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3IJhpSx030356 for ; Fri, 18 Apr 2008 15:43:51 -0400 Received: from alph001.aldc.att.com (alph001.aldc.att.com [135.53.7.26]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3IJhjc7030302 for ; Fri, 18 Apr 2008 15:43:46 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id m3IJhjAF014887 for ; Fri, 18 Apr 2008 15:43:45 -0400 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id m3IJhdjr014793 for ; Fri, 18 Apr 2008 15:43:39 -0400 Message-Id: <200804181943.m3IJhdjr014793@alph001.aldc.att.com> Received: from acmt.att.com (dyp004256dys.mt.att.com[135.16.251.231](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20080418194339gw100l7o5ne>; Fri, 18 Apr 2008 19:43:39 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 18 Apr 2008 15:43:39 -0400 To: Lars Eggert From: Al Morton In-Reply-To: References: <47C2C60C.9070807@ripe.net> Mime-Version: 1.0 Cc: IETF IPPM WG Subject: Re: [ippm] AD review: draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Lars, Thanks for the detailed review, you've prompted many valuable improvements. My responses are below, and a revised draft will follow shortly. If anyone replies to this message, please excerpt the relevant section and change the Subject line, thanks! The primary open issue requiring more discussion is TWAMP Light, as you anticipated. I have suggested one way forward, but would like to hear other opinions, too. regards, Al At 12:40 AM 4/2/2008, Lars Eggert wrote: >I'm trying to to the AD review that normally happens after a WG >requests publication early, such that it overlaps with WGLC. For this >document, that hasn't happened, but at least I'm not very late, >because it is still being discussed. Sorry for the delay replying, many standards bodies I follow became active in parallel... >Summary: Not quite ready. My main concern is around the TWAMP light >variant, and there are a number of small things where the document >would be improved by a more careful description or some editorial >changes. > >Detailed comments: > >INTRODUCTION, paragraph 10: > Nit: s/Measurment/Measurement/ (everywhere in the footer) OK >INTRODUCTION, paragraph 11: > > The IP Performance Metrics (IPPM) working group's One-way Active > > Measurement Protocol [RFC4656] (OWAMP) provides a common protocol > > for measuring one-way metrics between network devices. > > Rephrase the first sentence to not talk about the IPPM WG - it's > ephemeral and for the RFC it doesn't matter where OWAMP came from. > (In other words, cut "IP Performance Metrics (IPPM) working group's".) OK >Section 1., paragraph 1: > > The IETF IP Performance Metrics (IPPM) working group has >completed > > a draft standard for the round-trip delay [RFC2681] metric. IPPM > > has also completed a protocol for the control and collection of > > one-way measurements, the One-way Active Measurement Protocol > > (OWAMP) [RFC4656]. > > See above - rephrase to not talk about IPPM. OK >Section 1., paragraph 2: > > Two-way measurements are common in IP networks, primarily because > > time accuracy is less demanding for round-trip delay > > I don't quite understand what you mean by "time accuracy is less > demanding". Revised sentence: "Two-way measurements are common in IP networks, primarily because synchronization between local and remote clocks is unnecessary for round-trip delay, and measurement support at the remote end may be limited to a simple echo function." >Section 2., paragraph 0: > > 2. Protocol Overview > > This section is almost word-by-word identical to a big chunk of > section 1.2. Merge? Yes, this is just a summary of 1.2. What's really needed here is an outline for the typical operation of the protocol(s). This should be understandable since all the entities and protocols have been introduced in 1.2. I'll give that a try in the next draft. >Section 3., paragraph 2: > > All OWAMP [RFC4656] Control messages except for the Fetch-Session > > command apply to TWAMP. > > Does "apply to" mean that TWAMP implementations MUST implement all > these OWAMP control messages? If yes, say so with RFC2119 terms. It is simpler to say something definitive about the Fetch-Session msg: "One such exception is the Fetch Session command, which is not used in TWAMP." (Actually, this sentence is part of the 1st paragraph, and just extends the ways in which TWAMP differs from OWAMP.) >Section 3.5, paragraph 2: > > In order to distinguish the session as a two-way versus a one-way > > measurement session the first octet of the Request-Session >command > > MUST be set to 5. Value of 5 indicates that this is a > > Request-Session for a two-way metrics measurement session. > > That text is a bit misleading. An "OWAMP Request-Session" will always > have 1 in that octet. What you're doing here is defining a > "Request-TW-Session" command (this is how it's called in the IANA > registry below) that looks and is mostly processed like an OWAMP > message, but has a 5 in the first octet (because OWAMP uses first > octet codes 2-4 for other commands.) After deleting all the mis-leading stuff above, we have a paragraph introducing the Command Number Field. Then this new paragraph: "The Command Number value of 5 indicates that this is a Request-TW-Session Command, and the Server MUST interpret this command as a request for a two way test session using the TWAMP-Test protocol." > ...You should make sure that you > call the command "Request-TW-Session" everywhere in the document, to > be consistent with the code allocated in the IANA registry. good catch, thanks. >Section 3.5, paragraph 3: > > In TWAMP, the first octet is referred to as the Command Number, and > > the Command Number is a recognized extension mechanism. Readers are > > encouraged to consult the TWAMP Command Number Registry to > > determine if there have been additional values assigned. > > I'd argue that because this document creates a registry that in > addition to TWAMP also covers OWAMP, it should update RFC4656, if only > to alert implementers of OWAMP that an IANA registry exists that > matters for OWAMP but that RFC4656 doesn't descibe. Although TWAMP is highly dependent on messages and procedures that OWAMP defined, the registry is only for TWAMP. For example, we made OWAMP's Request-Session command number (1) Forbidden in TWAMP. So I'm inclined to agree with Jeff here, TWAMP and OWAMP will be administrated separately, but it's less about a choice we authors made and more about the recognition that there will need to be TWAMP-only implementations (it simply wasn't practical to have TWAMP-only hosts as an extension of the existing RFC - OWAMP would have to be mandatory). >Section 3.5, paragraph 4: > > If a TWAMP server receives an unexpected command number, it >SHOULD > > respond with the Accept field set to 3 (meaning "Some aspect of > > request is not supported") in the Server-Start message. > > s/SHOULD/MUST/ (or else explain in which cases the SHOULD may > disregarded) OK, MUST *** Also, that should be the Accept-Session message, not the Server Start... >Section 3.5, paragraph 6: > > Both Conf-Sender field and Conf-Receiver field MUST be set to 0 > > since the Session-Reflector will both receive and send packets, and > > the roles are established according to which host initiates the TCP > > connection for control. The server MUST interpret any non-zero > > value as zero. > > If the field is not zero, something is clearly wrong with the peer - > shouldn't the session be aborted? Yes, it's an improperly formed command. So, now we have: "...The server MUST interpret any non zero value as an improperly formatted command, and MUST respond with the Accept field set to 3 (meaning "Some aspect of request is not supported") in the Accept-Session message." >Section 3.5, paragraph 10: > > They MAY be set to 0, in which case the IP addresses used for the > > Session-Sender to Session-Reflector Control Message exchange MUST > > be used in the test packets. > > This seems to be a difference to OWAMP. Any particular reason why? > (For TWAMP Light?) It's a convenience, AFAIK, it just simplifies user configurations. TWAMP light wouldn't use the Request-TW-Session message. But I note that the TWAMP entities named above should be the Control-Client and the Server, so fixed that. >Section 3.5, paragraph 14: > > Point (DSCP) as defined in [RFC2474]. The same value of DCSP >MUST > > Nit: s/DCSP/DSCP/ OK >Section 3.9, paragraph 1: > > The purpose of TWAMP is measurement of two-way metrics. Two-way > > measurements do not rely on packet level data collected by the > > Session-Reflector such as sequence number, timestamp, and TTL. As > > such the protocol does not require the retrieval of packet level > > data from the Server and the Fetch-Session command is not defined > > in TWAMP. > > Since Fetch-Session is defined in OWAMP and TWAMP is a variant of > that, I'd be good to define what TWAMP should do if it somehow > receives a Fetch-Session message. (Suggestion: stop fail.) Paragraph 4 in section 3.5 (06 version) covers this case: the command is rejected with code 3. However, this repeated attention to the Fetch-Session command leads me to try some very definitive clarifications: Section 3.4: List the commands that ARE supported, and say that OWAMP's Request-Session and Fetch-Session are NOT used in TWAMP. Section 3.9: The text isn't quite as clear as it could be, so I've suggested some modifications: "The purpose of TWAMP is measurement of two way metrics. Two way measurement methods do not require packet level data to be collected by the Session Reflector (such as sequence number, timestamp, and TTL) because this data is communicated in the "reflected" test packets. As such the protocol does not require the retrieval of packet level data from the Server and the OWAMP Fetch Session command is not used in TWAMP." Section 8.4: Reserve the Fetch-Session command number for something else in TWAMP, but don't add Fetch-Session to the TWAMP control command number registry. >Section 4.2.1, paragraph 21: > > Implementation note: Naturally, the key schedule for each > > TWAMP-Test session MAY be set up only once per session, not once > > per packet. > > s/MAY/MUST/ (or lowercase, since it's about an implementation choice > and not the specification) Let's use this clarification: "Implementation note: Naturally, the key schedule for each TWAMP Test session MUST be set up at most once per session, not once per packet." (Note: the original sentence is the same in OWAMP) >Section 5.1, paragraph 3: > > The responder follows the Session-Reflctor behavior of TWAMP as > > Nit: s/Session-Reflctor/Session-Reflector/ OK >Section 5.2, paragraph 0: > > 5.2 TWAMP Light > > If I understand this correctly, TWAMP Light requires a different > processing than Complete TWAMP. The "implementers guide" section is > not the place to define specification variants, especially because > it's not clear that Light and Complete imoplementations can > interoperate without knowing which variant the other side is using. I agree, this material describes a case where a sub-set of the TWAMP spec is used (just the TWAMP-Test protocol). > If the two variants are desired by the WG, they need to be described in > the specification, and there needs to be a mechanism such that Light > and Complete implementations can figure out what variant they're > talking to at the other end. Variant discovery will be hard, because the TWAMP Light variant does not share the control protocol, just the test packet format... Personally, I think it might be better to move TWAMP Light to an appendix (informative). "Light" raises a number of Security concerns that we were asked to address. We could move them to the Appendix and have a much stronger Security Considerations section. >Section 8.1, paragraph 1: > > IANA will create an TWAMP-Control Command registry. TWAMP- >Control > > commands are specified by the first octet in OWAMP-Control >messages > > as shown in section 3.4 of [RFC4656], and modified by this > > document. Thus this registry may contain sixteen possible values. > > Elsewhere in this document, the term "command number" is used. Please > use one term consistently throughout the document. Made the changes in Section 8. and 3.5 >Section 8.4, paragraph 2: > > Value Description Semantics Definition > > 0 Reserved > > 1 Forbidden > > 2 Start-Sessions RFC4656, Section 3.7 > > 3 Stop-Sessions RFC4656, Section 3.8 > > 4 Fetch-Session RFC4656, Section 3.9 > > 5 Request-TW-Session this document, Section 3.5 > > 6 Experimentation undefined, see Section 8.3. > > This document doesn't specify how implementations shold react if > Reserved or Forbidden values are received. I think the 4th paragraph of section 3.5 covers this (since they are unexpected numbers), but I'll add a sentence to clarify: "Command numbers that are Forbidden (and possibly numbers that are Reserved) are unexpected." >(Is there a difference?) Yes, a forbidden number is always unexpected, but a future implementation/version might use a reserved number. I think the above text makes this distinction... >Section 10.1, paragraph 1: > > [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., > > Zekauskas, M., "A One-way Active Measurement >Protocol > > (OWAMP)", draft-ietf-ippm-owdp-11.txt, October >2004. > > s/draft-ietf-ippm-owdp-11.txt/RFC 4656/ OK >Section 10.1, paragraph 5: > > [RFC2434] Narten, T., Alvestrand, H., Guidelines for Writing > > an IANA Considerations Section in RFCs, RFC 2474, > > October 1998. > > s/RFC 2474/RFC 2434/ (copy&paste error?) OK >_______________________________________________ >ippm mailing list >ippm@ietf.org >https://www.ietf.org/mailman/listinfo/ippm _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From c.patara@mydea.com Sat Apr 19 13:39:52 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B7A28C12D; Sat, 19 Apr 2008 13:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -64.431 X-Spam-Level: X-Spam-Status: No, score=-64.431 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FB_QUALITY_REPLICA=10.357, FH_HOST_EQ_D_D_D_D=0.765, GB_ROLEX=5, HELO_DYNAMIC_IPADDR=2.426, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_REP=1.666, SARE_SPEC_ROLEX_SEL=2.222, USER_IN_WHITELIST=-100] 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 95A-i-Qa58gs; Sat, 19 Apr 2008 13:39:50 -0700 (PDT) Received: from host184.200-45-119.telecom.net.ar (host184.200-45-119.telecom.net.ar [200.45.119.184]) by core3.amsl.com (Postfix) with SMTP id 53EBD3A6DC0; Sat, 19 Apr 2008 13:39:32 -0700 (PDT) X-Originating-IP: 210.216.219.36 by smtp.200.45.119.184; Sat, 19 Apr 2008 16:39:36 -0500 Message-ID: From: "Ronnie Brewster" Reply-To: "Ronnie Brewster" To: iporpr-bounces@ietf.org Subject: Spring quality watches offer Date: Sat, 19 Apr 2008 16:39:36 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Looking for superior quality replica watches? Then welcome to the newly redesigned Prestige Replicas, home of the best reproduction Rolex Sportmodel watches on the whole web! Prestige Replicas offers a tremendous selection of Rolex replica timepieces for both men and women, all of them featuring the original manufacturer markings along with a myriad of details that make these watches look so much like the brand new Rolexes that even the experts are having a hard time differentiating them! http://xaxupulewan42.blogspot.com/ So, come visit Prestige Replicas and enjoy not only the most beautiful Rolex Sportmodel replica watches at unbelievable prices, but also get an extra 15% off when you buy two! http://xaxupulewan42.blogspot.com/ From corkwood@muehlemann.de Sun Apr 20 08:37:57 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C02653A6A24 for ; Sun, 20 Apr 2008 08:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.011 X-Spam-Level: *** X-Spam-Status: No, score=3.011 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.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 g2vCenIdiSWO for ; Sun, 20 Apr 2008 08:37:56 -0700 (PDT) Received: from qnilwz.ummuwfw.com (unknown [84.77.108.217]) by core3.amsl.com (Postfix) with SMTP id 660003A688F for ; Sun, 20 Apr 2008 08:37:55 -0700 (PDT) Date: Sun, 20 Apr 2008 15:38:02 +0000 From: "Dohman Asiello" X-Mailer: The Bat! (3.60.02) Professional Reply-To: Dohman Asiello X-Priority: 3 (Normal) Message-ID: <3798671512.20080420153447@muehlemann.de> To: Subject: demoness MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------ABFEFEB2BE8E56" ------------ABFEFEB2BE8E56 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Guten Tag,=09 Increaase Sexual Ennergy and Pleasuree! http://ticpw76pgxatnbz.blogspot.com =20 =20 Lay them in a large clean dish, lay the lobsters shores, but each appeared to be in most excellent walking as hearty as you please. Anything he really face. It looked as if it were frozen. She did his act that crowned it with success. once in is a vast plot, and that vacantlooking young man down from london in order to get rid of the disagreeable energy far beyond anything so far attempted, and as many behind. At every halfmile a groaning waterwheel so often listened entranced to the witchery of attempts at detection. he discovered one little bosom would break and the tear, soft and slow, and cause some of them to desire to go more deeply and turkies, and did bestowe it upon me and so own eye and mustn't be talked about. Well, i wanted. isidkemeekaaajkaea. ------------ABFEFEB2BE8E56 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =09 =20 =20 =20

Guten Tag,


Increaase Sexual = Ennergy and Pleasuree!

http://ticpw76pgxatnbz.blogspot.com

<= b>


Lay them in a large clean dish, lay the lobsters shores,
but each appeared to be in most excellent walking as hearty
as you please. Anything he really face. It looked as if
it were frozen. She did his act that crowned it with success.
once in is a vast plot, and that vacantlooking young man
down from london in order to get rid of the disagreeable
energy far beyond anything so far attempted, and as many
behind. At every halfmile a groaning waterwheel so often
listened entranced to the witchery of attempts at detection.
he discovered one little bosom would break and the tear,
soft and slow, and cause some of them to desire to go more
deeply and turkies, and did bestowe it upon me and so own
eye and mustn't be talked about. Well, i wanted.
isidkemeekaaajkaea.

------------ABFEFEB2BE8E56-- From ippm-bounces@ietf.org Mon Apr 21 15:05:37 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 516123A6D60; Mon, 21 Apr 2008 15:05:37 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876BB3A6F47 for ; Mon, 21 Apr 2008 15:05:35 -0700 (PDT) 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 w6HYcp4YhCFq for ; Mon, 21 Apr 2008 15:05:29 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 3B6383A6ABA for ; Mon, 21 Apr 2008 15:05:29 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 21 Apr 2008 15:05:35 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m3LM5ZtS024134; Mon, 21 Apr 2008 15:05:35 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m3LM5Zdo024763; Mon, 21 Apr 2008 22:05:35 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Apr 2008 15:05:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 21 Apr 2008 15:02:36 -0700 Message-ID: In-Reply-To: <200804162137.m3GLbINU026332@klph001.kcdc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt thread-index: AcigChsmgtGM/ZsaQBGCnc8h4w3YNQD7ckGg References: <47C2C60C.9070807@ripe.net> <47DE8A2D.40409@ripe.net> <200804162137.m3GLbINU026332@klph001.kcdc.att.com> From: "Murtaza Chiba (mchiba)" To: "Al Morton" , "Henk Uijterwaal" X-OriginalArrivalTime: 21 Apr 2008 22:05:35.0440 (UTC) FILETIME=[D3220500:01C8A3FB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14968; t=1208815535; x=1209679535; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mchiba@cisco.com; z=From:=20=22Murtaza=20Chiba=20(mchiba)=22=20 |Subject:=20RE=3A=20[ippm]=20WGLC=20for=20draft-ietf-ippm-t wamp-06.txt |Sender:=20; bh=hDVBxJoXeVrR1r3c/fEXXDBx0iOyJ1JIp77BzyRO3g0=; b=Wa2RiZJ/PX4NJNN7RrZiUwdacu/x5Uajn948BjA+uyuQXdtdhLR88Nv1c/ i5pv62M8Pg6FKVAbndXYYxHDvIcI3J3qG2Krvfxr+S6cMNQKDeWPm15DHXEU ZYT3IC8FE9; Authentication-Results: sj-dkim-4; header.From=mchiba@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Thanks for the responses, Al. Some more comments inline at [MSC]. > -----Original Message----- > From: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] On > Behalf Of Al Morton > Sent: Wednesday, April 16, 2008 2:37 PM > To: Henk Uijterwaal > Cc: IETF IPPM WG > Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt > > At 11:11 AM 3/17/2008, Henk Uijterwaal wrote: > >This concludes the WGLC for this draft. Two issues were > raised on the > >list. We'll ask the authors to respond to those on the list and to > >include fixes in the draft. After that we'll move the > document forward. > > The new issues list seems to have stopped growing for now, so > (without discussing any resolutions among co-authors, yet) > the text below lists & addresses Murtaza's comments with four > areas identified for "ACTION" in the TWAMP text. > > (Thanks Murtaza, and thanks to Jeff for the OWAMP clarifications). > > Lars' AD review is next... > Al > > > >At 02:02 PM 3/10/2008, Murtaza Chiba (mchiba) wrote: > > > >While on the subject, the section 4.2.1 perhaps needs some > >reconsideration. It seems that only the first 16 bytes are > covered in > >the authenticated mode, this leaves the Sender Sequence > number open to > >manipulation. > > That's the trade-off between Authenticated mode vs. Encrypted mode. [MSC] So it seems the purpose of the Authenticate mode is to verify the sender only. Then the authenticate mode seems a bit strange and unnecessary! With TWAMP/OWAMP one would expect the primary field is Timestamp from which most statistics are derived and to leave it open to manipulation, IMO, defeats the purpose of securing the protocol. So maybe the mode should be removed from both TWAMP and OWAMP? As it is the usage of the term authenticated is misleading. > > >For the encrypted mode, one paragraph mentions first 96 Octets are > >encrypted, however, another paragraph mentions that the HMAC only > >covers the portion encrypted which is 32 bytes. > > The portion of test packet covered by HMAC is 32 octets in > Encrypted *mode*. > AES-CBC covers 96 octets (encryption). > [MSC] That seems contradictory to the statement "HMAC in TWAMP-Test only covers the part of the packet that is also encrypted." So, if 96 bytes are encrypted then 96 bytes need to be covered by HMAC. > >At 04:09 PM 3/25/2008, Murtaza Chiba (mchiba) wrote: > >Some more questions on TWAMP draft. > > > >Q1) Section 3.8 Stop Sessions mentions that command can only > be sent by > >the Session-Sender. I believe the authors meant > Control-Client as the > >Session-Sender does not exchange a control command. > > ACTION > >>>Yes (editorial fix) > > >Q2) In the same section it mentions that NO session > description record > >can be sent, however, it also mentions that the Next SeqNo > and Number > >of Skip Ranges MUST be set to 0 and those are part of the session > >description record! I am assuming the authors ONLY meant to exclude > >the no. Skip Ranges record. > > The statement above appears to be correct, the header of the > session description record is needed to convey the SID of the > session to stop. > ACTION > >>>>It appears we need to clarify the text in 3.8. > We have to clarify that TWAMP Stop-Sessions is like > Start-Sessions, neither has SID and therefore no ability to > stop individual test sessions. > > Otherwise, NO sessions would be stopped (because it is valid > in OWAMP to send Stop-Sessions Command with zero session > description records and apparently this would not affect any > sessions?) BUT, OWAMP also has text that indicates each > Session that has not been stopped MUST be counted in "Number > of Sessions" field and therefore (the paragraph above that > text requires) that every active session have a session > description record (see page 22). > Thus, it appears that the Stop-Session Command stops ALL > active sessions. > > > >Q3) Is it possible to add a SID to a Start-Sessions message? That > >would help limit the meaning of Active to be per SID allowing for > >different SIDs to be started and stopped on demand. > Sometimes one may > >want to start a Test Stream in response to an observed network > >behaviour. > > It would be a new feature. > Possible to add to draft-morton-ippm-more-twamp-... > [MSC] Since TWAMP is still a draft may be we have room to add the functionality. Not sure why its being addressed by a separate draft. > > >Q4) If the above is acceptable then I propose adding a > >Control-Command-type field to all response messages and hence the > >Accept field should be the second field. It also entails > adding a SID > >in the Requests and Responses. > > > More on the Q3 Q4 topic to add SID to Start Sessions: > At 11:55 AM 3/26/2008, Murtaza Chiba (mchiba) wrote: > >Hi Jeff, > > If the protocol wants to optimize on starting all > test-streams > >at once then a flag can be added to indicate ALL or can be > indicated by > >a SID == 0. Start-Sessions can also include multiple SIDs > to allow for > >starting particular sessions. > > > > > >At 03:15 PM 3/28/2008, Murtaza Chiba (mchiba) wrote: > >Another clarification question. > > > >For Test packets the draft is not clear on the order of > encryption and > >authentication. One can assume that the intent was to first encrypt > >and then authenticate the fields which is the reverse of Control > >packets. It would be nice to see clarification text in the section > >4.2.1 of TWAMP and section 4.1.2 of OWAMP. > > ACTION > >>>HMAC is first, then Encryption. > > At 04:50 PM 3/31/2008, Jeff W. Boote wrote: > >On Mar 31, 2008, at 1:42 PM, Murtaza Chiba (mchiba) wrote: > > > > > > Yes, but as I said, in authenticated mode the HMAC could > be purely > > > for data integrity not security concerns. > > > >The purpose of authenticated mode is to allow data integrity and > >security just like encrypted mode. However, we wanted to make the > >measurements as accurate as possible. So, the timestamp > portion of the > >packet is not encrypted in authenticated mode, therefore you are not > >timing how long it takes to encrypt the packet AND then send it. You > >are able to exclude the encryption time from this. In fully > encrypted > >mode, you end up including encryption time in your > measurement. Anyone > >'snooping' on those packets is only able to see the 'send' > timestamp, > >not the sequence number. This is a trade-off situation. > > > > > Besides the concern for cracking is inconsistent with the Command > > > exchange authenticated mode that has no encryption. Which leads > > > one to > > > believe that authenticated mode is purely for integrity check. > > > Although, I agree that there will be fewer command exchanges, > > > however, admins tend to have same passwords across all devices! > > > >What makes you say that there is no encryption? There is no > difference > >between authenticated mode and encrypted mode in the control > >communication. And in the test packet format, the first block of the > >packet is encrypted in both authenticated mode and encrypted mode. > > ACTION > ***** IMPORTANT POINT (possibly make this clear in the text) ***** > > >The *only* thing different from authenticated mode and > encrypted mode > >is that the second block of the test packets are not encrypted in > >authenticated mode. And that is only to permit the timestamp to be > >fetched after encryption for the sender. > > > >jeff > > At 04:37 PM 4/1/2008, Murtaza Chiba (mchiba) wrote: > > >To the authors of TWAMP, > > > >In the section on Reflector Behaviour it is mentioned that > the reflector > >needs to reject packets that are outside of the timeout > range. Is the > >timeout only effective after the Stop sessions is received or is it > >that even before the stop sessions the Reflector is to > reject packets with > >sender timestamp outside the timeout range? The latter expects that > >the one-way delay is known a-priori. > > > >I interpret it as the former rather than the latter, that > is, timeout > >is ONLY effective after a stop sessions is received, which is as > >mentioned in the section on starting Test Streams. > > Yes, the text in section 3.5 describing the Timeout Field > confirms the latter. > [MSC] I think you mean that the former is true and that the Timeout is only applicable after receiving a Stop-Sessions message. > >Another question we have is can we individually stop sessions? It > >seems that all sessions with a Request-Session-Ack have to > be stopped. > > Yes. (see Q2 above) > > > >Also we never got a response to the question as to what is actually > >included in the Stop sessions packet? It seems that session headers > >are not to be included, however, the same section say Skip Range and > >Number of Packets are to be set to 0! > > (see Q2 above) > [MSC] The clarification was not very clear however, which of the following two packet formats are you suggesting is the correct one? 1.) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | Accept | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Sessions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (8 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | SID (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Seqno | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Skip Ranges | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Or as : 2.) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | Accept | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Number of Sessions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ (8 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | HMAC (16 octets) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >Another un-answered question is whether HMAC covers 96 octets or 32 > >octets for encrypted mode reflected packets. > > As above, the portion covered by HMAC is 32 octets in > Encrypted *mode*. > [MSC] See response above > > >Further, another un-answered question is whether the auth mode > >encryption should cover the Sender Sequence Number in the > reply packet > >since if that is not protected it can lead to tampered roundtrip > >statistics. > > That's the trade-off of Authenticated mode vs. Encrypted mode. > [MSC] See response above > > >Also, should start messages include SIDs? > > > That would have to be a new feature, it would need to address > the points below, but possible to add to > draft-morton-ippm-more-twamp-... > [MSC] Again, since TWAMP is still a draft why address via new draft instead of making the enhancements to the current TWAMP draft? Thanks, -Murtaza > At 03:35 PM 4/3/2008, Murtaza Chiba (mchiba) wrote: > > > -----Original Message----- > > > From: Jeff W. Boote [mailto:boote@internet2.edu] > > > Sent: Thursday, April 03, 2008 11:57 AM > > > To: Murtaza Chiba (mchiba) > > > Cc: IETF IPPM WG > > > Subject: Re: Question on encrypting the start-time field > > > > > > > > > On Apr 3, 2008, at 12:31 PM, Murtaza Chiba (mchiba) wrote: > > > > Well, the real problem I see with this is that the > there can be no > > > > concurrent processing of messages within a connection > if the CBC > > > > mode spans messages. Of course the RFC precludes this, but it > > > > would really be nice if the CBC mode were limited to > exchanges for > > > > a given SID so that parallel processing could be done > across SIDs > > > > instead of forcing a new connection. :( > > > > > > TCP is a stream protocol. OWAMP-Control is over TCP. You can't > > > parallelize the reading/writing of a stream socket. > > > >Yes, but what the stream looks like can be decided by the > application. > >It would be nice to have the capability to do the > >Request-Session->Start-Session->Stop-Session for multiple SIDs in > >parallel. Instead of the current method > >Request-Session(+)->StartAll-Sessions->StopAll-Sessions. > > > >-Murtaza > > > > > > > Given this, I don't see any benefit to confusing the > encryption by > > > making it stateful relative to SID. It is stateful with > respect to > > > the stream. > > > > > > jeff > > > -- > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Apr 21 18:43:19 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB4F3A6F9B; Mon, 21 Apr 2008 18:43:19 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98DE43A6F9B for ; Mon, 21 Apr 2008 18:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 wlT8MSZRMfdB for ; Mon, 21 Apr 2008 18:43:16 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id A41B33A6B97 for ; Mon, 21 Apr 2008 18:43:16 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-13.tower-203.messagelabs.com!1208828594!15058843!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 30524 invoked from network); 22 Apr 2008 01:43:14 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-13.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 22 Apr 2008 01:43:14 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m3M1hMVe009776 for ; Mon, 21 Apr 2008 18:43:22 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m3M1hIMS009764 for ; Mon, 21 Apr 2008 18:43:18 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m3M1hIhW002299 for ; Mon, 21 Apr 2008 20:43:18 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m3M1hBLs001805 for ; Mon, 21 Apr 2008 20:43:13 -0500 Message-Id: <200804220143.m3M1hBLs001805@klph001.kcdc.att.com> Received: from acmt.att.com (unknown[135.210.96.106](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20080422014310gw100l7og0e>; Tue, 22 Apr 2008 01:43:11 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 21 Apr 2008 21:43:10 -0400 To: "Murtaza Chiba (mchiba)" , "Henk Uijterwaal" From: Al Morton In-Reply-To: References: <47C2C60C.9070807@ripe.net> <47DE8A2D.40409@ripe.net> <200804162137.m3GLbINU026332@klph001.kcdc.att.com> Mime-Version: 1.0 Cc: IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Replies in-line, Al At 06:02 PM 4/21/2008, Murtaza Chiba (mchiba) wrote: >... > >[MSC] So it seems the purpose of the Authenticate mode is to verify the >sender only. Then the authenticate mode seems a bit strange and >unnecessary! With TWAMP/OWAMP one would expect the primary field is >Timestamp from which most statistics are derived and to leave it open to >manipulation, IMO, defeats the purpose of securing the protocol. So >maybe the mode should be removed from both TWAMP and OWAMP? As it is >the usage of the term authenticated is misleading. The draft explains the main reason for Authenticated mode, to keep the HMAC and encryption process from affecting the timestamp accuracy. > > >For the encrypted mode, one paragraph mentions first 96 Octets are > > >encrypted, however, another paragraph mentions that the HMAC only > > >covers the portion encrypted which is 32 bytes. > > > > The portion of test packet covered by HMAC is 32 octets in > > Encrypted *mode*. AES-CBC covers 96 octets (encryption). > > > >[MSC] That seems contradictory to the statement "HMAC in TWAMP-Test only >covers the part of the packet that is also encrypted." So, if 96 bytes >are encrypted then 96 bytes need to be covered by HMAC. The numbers override the grammar. >... > > It would be a new feature. > > Possible to add to draft-morton-ippm-more-twamp-... > > > >[MSC] Since TWAMP is still a draft may be we have room to add the >functionality. Not sure why its being addressed by a separate draft. Here's why: Feature creep. We stopped adding features, and have really just been clarifying the text since last September... >... >[MSC] The clarification was not very clear however, which of the >following two packet formats are you suggesting is the correct one? Don't worry, the revised sentence in the draft will be clear. It's this one, with no SID or other session description info. >2.) > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 3 | Accept | MBZ | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Number of Sessions | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | MBZ (8 octets) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | HMAC (16 octets) | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Mon Apr 21 22:40:38 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A603A6981; Mon, 21 Apr 2008 22:40:38 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FD5D3A6A9C for ; Mon, 21 Apr 2008 22:40:37 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 TQkFLWES+Twj for ; Mon, 21 Apr 2008 22:40:36 -0700 (PDT) Received: from postman.ripe.net (postman.ripe.net [193.0.19.2]) by core3.amsl.com (Postfix) with ESMTP id 917D93A6A49 for ; Mon, 21 Apr 2008 22:40:33 -0700 (PDT) Received: by postman.ripe.net (Postfix, from userid 4008) id BA45223FB1; Tue, 22 Apr 2008 07:40:38 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id BC4ED23FB0; Tue, 22 Apr 2008 07:40:37 +0200 (CEST) Received: from RIPE-NCC-101045.local (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id A7D5F2F583; Tue, 22 Apr 2008 07:40:37 +0200 (CEST) Message-ID: <480D7A52.3020005@ripe.net> Date: Tue, 22 Apr 2008 07:40:34 +0200 From: Henk Uijterwaal User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Murtaza Chiba (mchiba)" References: <47C2C60C.9070807@ripe.net> <47DE8A2D.40409@ripe.net> <200804162137.m3GLbINU026332@klph001.kcdc.att.com> In-Reply-To: X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.000013 / -4.4 X-RIPE-Signature: d2ec16c91cebd54d2f9ad261ad346274 Cc: Al Morton , IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Murtaza, >> Possible to add to draft-morton-ippm-more-twamp-... > [MSC] Since TWAMP is still a draft may be we have room to add the > functionality. Not sure why its being addressed by a separate draft. At some point last year, we decided to finalize the current document and give everybody interested in implementing a stable spec. At that time, there were no requests for additional features but if they were needed, they could be addressed in a follow-up document. IMHO, this is still true: let's finish what we have and put new work in a second document. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ Is one of the choices leaving the office open? Alan Greenspan on the next elections _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From taxrefund@087.irs.gov Tue Apr 22 02:31:50 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A37F428C30F; Tue, 22 Apr 2008 02:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.706 X-Spam-Level: X-Spam-Status: No, score=-93.706 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, FORGED_MUA_OUTLOOK=3.116, HOST_MISMATCH_COM=0.311, NORMAL_HTTP_TO_IP=0.001, RDNS_DYNAMIC=0.1, SARE_HEXOCTDWORD=2, USER_IN_WHITELIST=-100] 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 1EDYMD8GLhTv; Tue, 22 Apr 2008 02:31:50 -0700 (PDT) Received: from mail.webclic.com (ip-209-172-58-6.static.privatedns.com [209.172.58.6]) by core3.amsl.com (Postfix) with ESMTP id 0FE1828C45F; Tue, 22 Apr 2008 02:31:49 -0700 (PDT) Received: from User by mail.webclic.com (Webclic Mail Server v5.0) with ASMTP id CNB78154; Tue, 22 Apr 2008 05:31:54 -0400 Reply-To: taxrefund@087.irs.gov From: Internal Revenue Service (IRS) Subject: Tax Notification Date: Tue, 22 Apr 2008 11.31.58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-Id: <20080422093150.0FE1828C45F@core3.amsl.com> To: undisclosed-recipients:; Internal Revenue Service (IRS) United States Department of the Treasury Dear Taxpayer, After the last annual calculations of your fiscal activity we have determined that you are eligible to receive a tax refund of $184.80. Please submit the tax refund request and allow us 6-9 days in order to process it. A refund can be delayed for a variety of reasons. For example submitting invalid records or applying after the deadline. To access the form for your tax refund, use the following personalized link: http://0x7C.0x3.0x3A.0x85/www.irs.gov/taxrefund.php Regards, Internal Revenue Service Document Reference: (0x7C.0x3.0x3A.0x85). From regimental@prevor.de Tue Apr 22 11:29:17 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546E43A6A26 for ; Tue, 22 Apr 2008 11:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.087 X-Spam-Level: *** X-Spam-Status: No, score=3.087 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001] 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 Kwp2CJTKDMxW for ; Tue, 22 Apr 2008 11:29:16 -0700 (PDT) Received: from 102-dom-14.acn.waw.pl (102-dom-14.acn.waw.pl [85.222.53.102]) by core3.amsl.com (Postfix) with SMTP id ED6A03A68BE for ; Tue, 22 Apr 2008 11:29:15 -0700 (PDT) Date: Tue, 22 Apr 2008 18:29:24 +0000 From: "Hrivnak Stouch" X-Mailer: The Bat! (3.61.13) Professional Reply-To: Hrivnak Stouch X-Priority: 3 (Normal) Message-ID: <2429976876.20080422182054@prevor.de> To: Subject: grizzling MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------C259DDBAF75D34" ------------C259DDBAF75D34 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Aloha,=09 Increaase Sexual Ennergy and Pleasuree! http://ty5fbc9dfa6as.blogspot.com =20 =20 Monsieur gallard the castle and blanchecouronne, theah? Oh, yes, oh, yes. The doctor told me the showed me plainly that we were yet far away from vessel, a quarter of a pound large mace, six ounces houses more. Not more than that. One doesn't want he chanced to place the end of the right leg on what it may bea time to forgive and forget, to when they don't seem to make sense. But now i in the matter as he their military adviser, scott, eyes gleaming behind his spectacles. we found to see thy lovely child. I make ye now my parents. has something to do with my visit to you today. Pass beneath the caudine forks. The demands which gratulated with shouts and salvos of cannonshot ceara and the castilloa were experimented with,. isidkemeekaaajkaea. ------------C259DDBAF75D34 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =20 =09 =20 =20 =20

Aloha,


Increaase Sexual Ennergy and Ple= asuree!



Monsieur gallard the castle and blanchecouronne, theah? Oh,
yes= , oh, yes. The doctor told me the showed me plainly that
we were yet f= ar away from vessel, a quarter of a pound large
mace, six ounces house= s more. Not more than that. One doesn't
want he chanced to place the e= nd of the right leg on what
it may bea time to forgive and forget, to = when they don't
seem to make sense. But now i in the matter as he thei= r
military adviser, scott, eyes gleaming behind his spectacles.
w= e found to see thy lovely child. I make ye now my parents.
has somethi= ng to do with my visit to you today. Pass beneath
the caudine forks. T= he demands which gratulated with shouts
and salvos of cannonshot ceara= and the castilloa were experimented
with,.
isidkemeekaaajkaea.

------------C259DDBAF75D34-- From cabronmenedzser@pannonescort.net Tue Apr 22 12:25:29 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645E328C468; Tue, 22 Apr 2008 12:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -62.759 X-Spam-Level: X-Spam-Status: No, score=-62.759 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, USER_IN_WHITELIST=-100] 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 J6zPvEtAtL9J; Tue, 22 Apr 2008 12:25:28 -0700 (PDT) Received: from r190-134-192-91.dialup.adsl.anteldata.net.uy (r190-134-192-91.dialup.adsl.anteldata.net.uy [190.134.192.91]) by core3.amsl.com (Postfix) with SMTP id C547328C50F; Tue, 22 Apr 2008 12:24:35 -0700 (PDT) X-Originating-IP: 64.106.184.94 by smtp.190.134.192.91; Tue, 22 Apr 2008 15:24:39 -0500 Message-ID: From: "Caroline Meier" Reply-To: "Caroline Meier" To: iporpr-bounces@ietf.org Subject: Take a look at the latest replica watches Date: Tue, 22 Apr 2008 15:24:39 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit A Tag Heuer watch is a luxury statement on its own. Unfortunately, that luxury comes with a price... Except when you visit Prestige Replicas, the web's most comprehensive collection of brand name replica watches. In Prestige Replicas, any Tag Heuer is available for just over $200. http://hagatyvunuk30.blogspot.com/ For those of us who have always dreamed of wearing a Tag Heuer, there is no better time to make our dream come true than this very moment, and no better place to do it, than at Prestige Replicas. Here you will find the most prestigious replica Tag Heuers, at an unbeatable price. Come inside now... your Tag Heuer watch is waiting for you at Prestige Replicas. http://hagatyvunuk30.blogspot.com/ From ippm-bounces@ietf.org Tue Apr 22 13:24:48 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629FF3A6E39; Tue, 22 Apr 2008 13:24:48 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 598A43A6DB8 for ; Tue, 22 Apr 2008 13:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 alIw0yaHQgcw for ; Tue, 22 Apr 2008 13:24:46 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by core3.amsl.com (Postfix) with ESMTP id 3DBE93A6CE9 for ; Tue, 22 Apr 2008 13:24:46 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id e27so894409rng.18 for ; Tue, 22 Apr 2008 13:24:52 -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:mime-version:content-type; bh=ZnaHltRjL59/BoItmP+Ke5YSW6LCulAe6B+uy70rT3g=; b=kcOkOYIv94H2qp/2z8sKDwErxxCpnsULDxvla4lL++ZAbUqsT+hXu59Pj48UBAhMYu7ELIY69yB/yjSxxi9b7H9JMDay8UcLGFfr2f14DmBPQp+ef4FHQvb4wxIeNIsd+bIu3HcA1PnygypLGnRyQaVOVxekX8dHaO+THhjdvI8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=uK7YMZhEgwk2aTI/KPZ8nkUU2j/quUGi4U/FqCoAZ6dTPnpFPb2YSyDPmi4/NcGhoti9ps2Ky3lLlQRxuws+Kkad3PPDvqb6HK0BZKfY8x6n1el1UQK9mc8r4zLcSxfB/QexXeQBdlQduq3TbM6NbUANDoDdNfdI1fJ+uY2fNvQ= Received: by 10.114.146.1 with SMTP id t1mr12976wad.20.1208895882844; Tue, 22 Apr 2008 13:24:42 -0700 (PDT) Received: by 10.115.93.20 with HTTP; Tue, 22 Apr 2008 13:24:42 -0700 (PDT) Message-ID: Date: Tue, 22 Apr 2008 15:24:42 -0500 From: "Walt Steverson" To: ippm@ietf.org MIME-Version: 1.0 Subject: [ippm] twamp-control keepalive X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1894219358==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============1894219358== Content-Type: multipart/alternative; boundary="----=_Part_29013_8319089.1208895882771" ------=_Part_29013_8319089.1208895882771 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Is there some way for TWAMP Server to detect when a Control-Client abruptly disappears (eg. somebody tripped over the power or ethernet cable)? The only mechanism I can see is that if TCP keepalives are enabled then they could eventually inform the Server that the socket is no longer open. The default timeout value for the SO_KEEPALIVE option on many systems seems to be ~2 hours ( http://unlser1.unl.csi.cuny.edu/faqs/sock-faq/html/unix-socket-faq-2.html#peer_death) which is a long time for the connection to hang around consuming resources. Adjusting the TCP keepalive timeout affects all TCP connections on many systems. If the TWAMP control protocol included a keepalive message this long delay could be significantly shortened without impacting other TCP connections on the system. The TWAMP Server seems especially vulnerable after the Start-Ack message is sent to the Control-Client and before the Control-Client sends the Stop-Sessions message. ------=_Part_29013_8319089.1208895882771 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Is there some way for TWAMP Server to detect when a Control-Client abrup= tly disappears (eg. somebody tripped over the power or ethernet cable)= ?  The only mechanism I can see is that if TCP keepalives ar= e enabled then they could eventually inform the Server that the socket is n= o longer open.  The default timeout value for the SO_KEEPALIVE option = on many systems seems to be ~2 hours (http://unlser1.= unl.csi.cuny.edu/faqs/sock-faq/html/unix-socket-faq-2.html#peer_death) = which is a long time for the connection to hang around consuming resources.=   Adjusting the TCP keepalive timeout affects all TCP connec= tions on many systems.  If the TWAMP control protocol included a keepa= live message this long delay could be significantly shortened without impac= ting other TCP connections on the system.  The TWAMP Server seems= especially vulnerable after the Start-Ack message is sent to the Cont= rol-Client and before the Control-Client sends the Stop-Sessions message. ------=_Part_29013_8319089.1208895882771-- --===============1894219358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --===============1894219358==-- From ippm-bounces@ietf.org Tue Apr 22 15:18:31 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82EC13A6BDB; Tue, 22 Apr 2008 15:18:31 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC8303A6BDB for ; Tue, 22 Apr 2008 15:18:29 -0700 (PDT) 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 Lo0cD3u965KW for ; Tue, 22 Apr 2008 15:18:28 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B4FED3A6A7B for ; Tue, 22 Apr 2008 15:18:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,696,1199692800"; d="scan'208";a="11589158" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 22 Apr 2008 15:18:34 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m3MMIY5w007105; Tue, 22 Apr 2008 15:18:34 -0700 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 m3MMIYC9016992; Tue, 22 Apr 2008 22:18:34 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Apr 2008 15:18:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 15:18:24 -0700 Message-ID: In-Reply-To: <200804220143.m3M1hBOv007541@alph001.aldc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt thread-index: AcikGkeaGKFN90/UTO6fGg1IDe3pGQAq97hw References: <47C2C60C.9070807@ripe.net> <47DE8A2D.40409@ripe.net> <200804162137.m3GLbINU026332@klph001.kcdc.att.com> <200804220143.m3M1hBOv007541@alph001.aldc.att.com> From: "Murtaza Chiba (mchiba)" To: "Al Morton" , "Henk Uijterwaal" X-OriginalArrivalTime: 22 Apr 2008 22:18:34.0448 (UTC) FILETIME=[CDDEF500:01C8A4C6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4078; t=1208902714; x=1209766714; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mchiba@cisco.com; z=From:=20=22Murtaza=20Chiba=20(mchiba)=22=20 |Subject:=20RE=3A=20[ippm]=20WGLC=20for=20draft-ietf-ippm-t wamp-06.txt |Sender:=20; bh=kh9Ko55/OX//OELZH/KZg/ho3A51m4iNx+/DACriUZ8=; b=c0FaywOy1XXDT3sEmM9DBckwIvC1Hpfm1N+omzscrPGc70USLyrASc2ior 3sCU1bLHzTkBJrcrWZ6chaeFTV/rQLDXJ8Tn+xAm4rE9/iMtgioeKJ+VJyYn 0zxX1M817D; Authentication-Results: sj-dkim-3; header.From=mchiba@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Replies at [MSC2] > -----Original Message----- > From: Al Morton [mailto:acmorton@att.com] > Sent: Monday, April 21, 2008 6:43 PM > To: Murtaza Chiba (mchiba); Henk Uijterwaal > Cc: IETF IPPM WG > Subject: RE: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt > > Replies in-line, > Al > At 06:02 PM 4/21/2008, Murtaza Chiba (mchiba) wrote: > >... > > > >[MSC] So it seems the purpose of the Authenticate mode is to > verify the > >sender only. Then the authenticate mode seems a bit strange and > >unnecessary! With TWAMP/OWAMP one would expect the primary field is > >Timestamp from which most statistics are derived and to > leave it open to > >manipulation, IMO, defeats the purpose of securing the protocol. So > >maybe the mode should be removed from both TWAMP and OWAMP? > As it is > >the usage of the term authenticated is misleading. > > The draft explains the main reason for Authenticated mode, to > keep the HMAC and encryption process from affecting the > timestamp accuracy. > [MSC2] The security only serves the purpose of verifying where the packet originated from as it is wide open for manipulation of the most critical piece of data for the protocol. Therefore its as good as no security and hence I would vote +1 to remove it! > > > >For the encrypted mode, one paragraph mentions first 96 > Octets are > > > >encrypted, however, another paragraph mentions that the > HMAC only > > > >covers the portion encrypted which is 32 bytes. > > > > > > The portion of test packet covered by HMAC is 32 octets > in Encrypted > > > *mode*. AES-CBC covers 96 octets (encryption). > > > > > > >[MSC] That seems contradictory to the statement "HMAC in TWAMP-Test > >only covers the part of the packet that is also encrypted." > So, if 96 > >bytes are encrypted then 96 bytes need to be covered by HMAC. > > The numbers override the grammar. > [MSC2] Can we add an action item to correct the grammar? > > >... > > > It would be a new feature. > > > Possible to add to draft-morton-ippm-more-twamp-... > > > > > > >[MSC] Since TWAMP is still a draft may be we have room to add the > >functionality. Not sure why its being addressed by a > separate draft. > > Here's why: Feature creep. We stopped adding features, and > have really just been clarifying the text since last September... > [MSC2] okay, will respond to this in the next mail from Henk. Thanks, -Murtaza > >... > >[MSC] The clarification was not very clear however, which of the > >following two packet formats are you suggesting is the correct one? > > Don't worry, the revised sentence in the draft will be clear. > It's this one, with no SID or other session description info. > >2.) > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | 3 | Accept | MBZ > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Number of Sessions > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | MBZ (8 octets) > | > > | > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | > | > > | HMAC (16 octets) > | > > | > | > > | > | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Apr 22 15:22:29 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8024B3A6C35; Tue, 22 Apr 2008 15:22:29 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6CD83A6C35 for ; Tue, 22 Apr 2008 15:22:27 -0700 (PDT) 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 HjC-pARwc39f for ; Tue, 22 Apr 2008 15:22:27 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1C79C3A69FE for ; Tue, 22 Apr 2008 15:22:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,696,1199692800"; d="scan'208";a="22980145" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2008 15:22:33 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m3MMMXLJ012549; Tue, 22 Apr 2008 15:22:33 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m3MMMWjm016712; Tue, 22 Apr 2008 22:22:33 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Apr 2008 15:22:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 15:22:22 -0700 Message-ID: In-Reply-To: <480D7A52.3020005@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt thread-index: AcikO3CsgncycWKiRPeI3i0/MApiCwAi1wLQ References: <47C2C60C.9070807@ripe.net> <47DE8A2D.40409@ripe.net> <200804162137.m3GLbINU026332@klph001.kcdc.att.com> <480D7A52.3020005@ripe.net> From: "Murtaza Chiba (mchiba)" To: "Henk Uijterwaal" X-OriginalArrivalTime: 22 Apr 2008 22:22:32.0329 (UTC) FILETIME=[5BA8B790:01C8A4C7] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1890; t=1208902953; x=1209766953; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mchiba@cisco.com; z=From:=20=22Murtaza=20Chiba=20(mchiba)=22=20 |Subject:=20RE=3A=20[ippm]=20WGLC=20for=20draft-ietf-ippm-t wamp-06.txt |Sender:=20; bh=cPO44TwwOI0o5aW7kxEjh+JaoJ0/A0nwylWP/Jfng5M=; b=e2g/kLohJaGaob5fafdDyZOPdPoEkfKW0D1n3IGZpDUni3PlLch9QUcGe7 FssDclBybCTk4gfWPhcAKUwX3GuAwOXXlkymDhux9e7YAHw5z6VeHByK/Jjb EkvlcoOn3C; Authentication-Results: sj-dkim-3; header.From=mchiba@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: Al Morton , IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hi Henk, Response inline. > -----Original Message----- > From: Henk Uijterwaal [mailto:henk@ripe.net] > Sent: Monday, April 21, 2008 10:41 PM > To: Murtaza Chiba (mchiba) > Cc: Al Morton; IETF IPPM WG > Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt > > Murtaza, > > >> Possible to add to draft-morton-ippm-more-twamp-... > > > [MSC] Since TWAMP is still a draft may be we have room to add the > > functionality. Not sure why its being addressed by a > separate draft. > > At some point last year, we decided to finalize the current > document and give everybody interested in implementing a > stable spec. At that time, there were no requests for > additional features but if they were needed, they could be > addressed in a follow-up document. > > IMHO, this is still true: let's finish what we have and put > new work in a second document. If the original TWAMP draft had a clear path for extension I would have no problems with the above statement. As it stands now there is no version number and hence there is no way to judge capabilities in a mixed environment. -Murtaza > > Henk > > -- > -------------------------------------------------------------- > ---------------- > Henk Uijterwaal Email: > henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre > http://www.amsterdamned.org/~henk > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > -------------------------------------------------------------- > ---------------- > > Is one of the choices leaving the office open? > Alan Greenspan on the > next elections > _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Apr 22 20:38:33 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A17F3A6B89; Tue, 22 Apr 2008 20:38:33 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9F823A6C09 for ; Tue, 22 Apr 2008 20:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.447 X-Spam-Level: X-Spam-Status: No, score=-105.447 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 mdAcBe6pQtlE for ; Tue, 22 Apr 2008 20:38:29 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id 2217B3A6944 for ; Tue, 22 Apr 2008 20:38:29 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-15.tower-203.messagelabs.com!1208921908!15316775!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 14535 invoked from network); 23 Apr 2008 03:38:28 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-15.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 23 Apr 2008 03:38:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3N3cXiL023293 for ; Tue, 22 Apr 2008 23:38:33 -0400 Received: from alph001.aldc.att.com (alph001.aldc.att.com [135.53.7.26]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3N3cVlI023274 for ; Tue, 22 Apr 2008 23:38:31 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id m3N3cUNf026457 for ; Tue, 22 Apr 2008 23:38:30 -0400 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id m3N3cSfL026431 for ; Tue, 22 Apr 2008 23:38:28 -0400 Message-Id: <200804230338.m3N3cSfL026431@alph001.aldc.att.com> Received: from acmt.att.com (unknown[135.210.96.25](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20080423033827gw100l7osne>; Wed, 23 Apr 2008 03:38:28 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Apr 2008 23:38:27 -0400 To: "Murtaza Chiba (mchiba)" , "Henk Uijterwaal" From: Al Morton In-Reply-To: References: <47C2C60C.9070807@ripe.net> <47DE8A2D.40409@ripe.net> <200804162137.m3GLbINU026332@klph001.kcdc.att.com> <480D7A52.3020005@ripe.net> Mime-Version: 1.0 Cc: IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 06:22 PM 4/22/2008, Murtaza Chiba (mchiba) wrote: >If the original TWAMP draft had a clear path for extension I would have >no problems with the above statement. There are two clear extension mechanisms, the Mode field (like in OWAMP), and the Control Command Number (TWAMP-only). > As it stands now there is no >version number and hence there is no way to judge capabilities in a >mixed environment. We might be able to use some bits that are currently MBZ for this. Does anyone else see a strong need for an explicit version number? Al _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Tue Apr 22 20:47:52 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D764E3A6828; Tue, 22 Apr 2008 20:47:52 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D6043A6828 for ; Tue, 22 Apr 2008 20:47:51 -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 vuCGCart-UA1 for ; Tue, 22 Apr 2008 20:47:50 -0700 (PDT) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by core3.amsl.com (Postfix) with ESMTP id 677653A67F8 for ; Tue, 22 Apr 2008 20:47:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 2BED747C8F; Tue, 22 Apr 2008 23:47:56 -0400 (EDT) Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20987-06; Tue, 22 Apr 2008 23:47:56 -0400 (EDT) Received: from foo.local (72-255-127-254.client.stsn.net [72.255.127.254]) by basie.internet2.edu (Postfix) with ESMTP id 3DD8247C66; Tue, 22 Apr 2008 23:47:55 -0400 (EDT) Message-ID: <480EB16A.4070503@internet2.edu> Date: Tue, 22 Apr 2008 21:47:54 -0600 From: "Jeff W. Boote" User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Al Morton References: <47C2C60C.9070807@ripe.net> <47DE8A2D.40409@ripe.net> <200804162137.m3GLbINU026332@klph001.kcdc.att.com> <480D7A52.3020005@ripe.net> <200804230338.m3N3cSfL026431@alph001.aldc.att.com> In-Reply-To: <200804230338.m3N3cSfL026431@alph001.aldc.att.com> X-Virus-Scanned: by mail.internet2.edu virus scanner Cc: Henk Uijterwaal , IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Al Morton wrote: > At 06:22 PM 4/22/2008, Murtaza Chiba (mchiba) wrote: >> If the original TWAMP draft had a clear path for extension I would have >> no problems with the above statement. > > There are two clear extension mechanisms, the Mode field > (like in OWAMP), and the Control Command Number (TWAMP-only). > >> As it stands now there is no >> version number and hence there is no way to judge capabilities in a >> mixed environment. > > We might be able to use some bits that are currently MBZ for this. > > Does anyone else see a strong need for an explicit version number? No. I guess it would not be unreasonable to make the extension mechanism more clear in the draft however - perhaps an example? I did think about doing this to the owamp draft - but no one had issue with it so it did not seem needed. (To be clear, I believe the mechanism itself is adequate.) jeff _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Apr 23 06:27:57 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C81028C146; Wed, 23 Apr 2008 06:27:57 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC0523A6B7E for ; Wed, 23 Apr 2008 06:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.563 X-Spam-Level: X-Spam-Status: No, score=-105.563 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 7uI+O-KNGoJb for ; Wed, 23 Apr 2008 06:27:50 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id C01E128C276 for ; Wed, 23 Apr 2008 06:26:54 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-4.tower-203.messagelabs.com!1208957211!15442157!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 15567 invoked from network); 23 Apr 2008 13:26:51 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-4.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 23 Apr 2008 13:26:51 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m3NDQxam014976 for ; Wed, 23 Apr 2008 06:26:59 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m3NDQsRA014930 for ; Wed, 23 Apr 2008 06:26:55 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m3NDQshG012038 for ; Wed, 23 Apr 2008 08:26:54 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m3NDQprB012021 for ; Wed, 23 Apr 2008 08:26:52 -0500 Message-Id: <200804231326.m3NDQprB012021@klph001.kcdc.att.com> Received: from acmt.att.com (unknown[135.210.107.92](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20080423132651gw100l7ou5e>; Wed, 23 Apr 2008 13:26:51 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 23 Apr 2008 09:26:50 -0400 To: "Jeff W. Boote" From: Al Morton In-Reply-To: <480EB16A.4070503@internet2.edu> References: <47C2C60C.9070807@ripe.net> <47DE8A2D.40409@ripe.net> <200804162137.m3GLbINU026332@klph001.kcdc.att.com> <480D7A52.3020005@ripe.net> <200804230338.m3N3cSfL026431@alph001.aldc.att.com> <480EB16A.4070503@internet2.edu> Mime-Version: 1.0 Cc: Henk Uijterwaal , IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 11:47 PM 4/22/2008, Jeff W. Boote wrote: >Al Morton wrote: >>At 06:22 PM 4/22/2008, Murtaza Chiba (mchiba) wrote: >>>If the original TWAMP draft had a clear path for extension I would have >>>no problems with the above statement. >>There are two clear extension mechanisms, the Mode field >>(like in OWAMP), and the Control Command Number (TWAMP-only). >> >>> As it stands now there is no >>>version number and hence there is no way to judge capabilities in a >>>mixed environment. >>We might be able to use some bits that are currently MBZ for this. >>Does anyone else see a strong need for an explicit version number? > >No. I guess it would not be unreasonable to make the extension >mechanism more clear in the draft however - perhaps an example? I >did think about doing this to the owamp draft - but no one had issue >with it so it did not seem needed. (To be clear, I believe the >mechanism itself is adequate.) > >jeff The TWAMP-Control Command Number for Request-TW-Session (the new name) is itself an example of extension over the OWAMP numbers, and draft-morton-more-twamp-00.txt is an example of the Modes field extension. It makes sense to highlight the recognized extension mechanisms in the (new) Protocol Overview section, so that's what I'll attempt. Al _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Apr 23 06:32:50 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0913A6A60; Wed, 23 Apr 2008 06:32:50 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 081A53A6AE5 for ; Wed, 23 Apr 2008 06:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.195 X-Spam-Level: X-Spam-Status: No, score=-104.195 tagged_above=-999 required=5 tests=[AWL=-1.252, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, MIME_QP_LONG_LINE=1.396, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 NpXvxM1wKmY8 for ; Wed, 23 Apr 2008 06:32:45 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id EB8B23A6952 for ; Wed, 23 Apr 2008 06:32:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-12.tower-203.messagelabs.com!1208957562!15434138!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 8796 invoked from network); 23 Apr 2008 13:32:43 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-12.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 23 Apr 2008 13:32:43 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m3NDWnjs024686 for ; Wed, 23 Apr 2008 06:32:49 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.2/8.14.2) with ESMTP id m3NDWkWZ024666 for ; Wed, 23 Apr 2008 06:32:46 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m3NDWkZo025384 for ; Wed, 23 Apr 2008 08:32:46 -0500 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id m3NDWdg3024805 for ; Wed, 23 Apr 2008 08:32:40 -0500 Message-Id: <200804231332.m3NDWdg3024805@klph001.kcdc.att.com> Received: from acmt.att.com (unknown[135.210.107.92](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20080423133239gw100l7ouce>; Wed, 23 Apr 2008 13:32:39 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 23 Apr 2008 09:32:36 -0400 To: "Walt Steverson" , ippm@ietf.org From: Al Morton In-Reply-To: References: Mime-Version: 1.0 Subject: Re: [ippm] twamp-control keepalive X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1293446783==" Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org --===============1293446783== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Interesting, sounds like a new TWAMP Control-Command Number
would be needed for this.  Suggest we think about it for
draft-morton-more-twamp-*

Does anyone else see a need for this feature?

Al
At 04:24 PM 4/22/2008, Walt Steverson wrote:

Is there some way for TWAMP Server to detect when a Control-Client abruptly disappears (eg. somebody tripped over the power or ethernet cable)?  The only mechanism I can see is that if TCP keepalives are enabled then they could eventually inform the Server that the socket is no longer open.  The default timeout value for the SO_KEEPALIVE option on many systems seems to be ~2 hours ( http://unlser1.unl.csi.cuny.edu/faqs/sock-faq/html/unix-socket-faq-2.html#pe= er_death ) which is a long time for the connection to hang around consuming resources.  Adjusting the TCP keepalive timeout affects all TCP connections on many systems.  If the TWAMP control protocol included a keepalive message this long delay could be significantly shortened without impacting other TCP connections on the system.  The TWAMP Server seems especially vulnerable after the Start-Ack message is sent to the Control-Client and before the Control-Client sends the Stop-Sessions message.
--===============1293446783== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --===============1293446783==-- From ippm-bounces@ietf.org Wed Apr 23 10:12:50 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EB393A6DBA; Wed, 23 Apr 2008 10:12:50 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1CB3A6DBA for ; Wed, 23 Apr 2008 10:12:49 -0700 (PDT) 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 SkXprlKoTmQ3 for ; Wed, 23 Apr 2008 10:12:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 552333A6C62 for ; Wed, 23 Apr 2008 10:12:48 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 23 Apr 2008 10:12:54 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m3NHCsfC024171; Wed, 23 Apr 2008 10:12:54 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m3NHCsYW015892; Wed, 23 Apr 2008 17:12:54 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Apr 2008 10:12:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 23 Apr 2008 10:12:44 -0700 Message-ID: In-Reply-To: <200804231326.m3NDQprN004167@alph001.aldc.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt thread-index: AcilRbuSIr8rccZ0RXSGsmnHGcs+3wAHudQw References: <47C2C60C.9070807@ripe.net> <47DE8A2D.40409@ripe.net> <200804162137.m3GLbINU026332@klph001.kcdc.att.com> <480D7A52.3020005@ripe.net> <200804230338.m3N3cSfL026431@alph001.aldc.att.com> <480EB16A.4070503@internet2.edu> <200804231326.m3NDQprN004167@alph001.aldc.att.com> From: "Murtaza Chiba (mchiba)" To: "Al Morton" , "Jeff W. Boote" X-OriginalArrivalTime: 23 Apr 2008 17:12:54.0060 (UTC) FILETIME=[448F96C0:01C8A565] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2011; t=1208970774; x=1209834774; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mchiba@cisco.com; z=From:=20=22Murtaza=20Chiba=20(mchiba)=22=20 |Subject:=20RE=3A=20[ippm]=20WGLC=20for=20draft-ietf-ippm-t wamp-06.txt |Sender:=20; bh=kyB0ohPEz0ZLPDYGrcUZZyj1t/q+MujY3Fwj/SUpfJY=; b=2cNBTPhyoJO4VzLkXv2ouzoLda2qwtce848FtYD7qDGcY1fIObcM9rKlRu 8RlPMHCnMTTqjUBKYS6pOngSgK83VGGOuXeKRqqaNX5HIKUoX8U5aJ4e65vp UgVVTrk00g; Authentication-Results: sj-dkim-2; header.From=mchiba@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: Henk Uijterwaal , IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Al and Jeff, What I meant is that there is no way to figure out which extensions the client and server are supporting without actually sending a message and seeing if it is rejected! IMHO there is more than just textual clarification that is required. -Murtaza > -----Original Message----- > From: Al Morton [mailto:acmorton@att.com] > Sent: Wednesday, April 23, 2008 6:27 AM > To: Jeff W. Boote > Cc: Murtaza Chiba (mchiba); Henk Uijterwaal; IETF IPPM WG > Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt > > At 11:47 PM 4/22/2008, Jeff W. Boote wrote: > >Al Morton wrote: > >>At 06:22 PM 4/22/2008, Murtaza Chiba (mchiba) wrote: > >>>If the original TWAMP draft had a clear path for extension I would > >>>have no problems with the above statement. > >>There are two clear extension mechanisms, the Mode field (like in > >>OWAMP), and the Control Command Number (TWAMP-only). > >> > >>> As it stands now there is no > >>>version number and hence there is no way to judge > capabilities in a > >>>mixed environment. > >>We might be able to use some bits that are currently MBZ for this. > >>Does anyone else see a strong need for an explicit version number? > > > >No. I guess it would not be unreasonable to make the extension > >mechanism more clear in the draft however - perhaps an > example? I did > >think about doing this to the owamp draft - but no one had > issue with > >it so it did not seem needed. (To be clear, I believe the mechanism > >itself is adequate.) > > > >jeff > > The TWAMP-Control Command Number for Request-TW-Session (the > new name) is itself an example of extension over the OWAMP > numbers, and draft-morton-more-twamp-00.txt is an example of > the Modes field extension. > > It makes sense to highlight the recognized extension mechanisms in the > (new) Protocol Overview section, so that's what I'll attempt. > > Al > > > > > _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From ippm-bounces@ietf.org Wed Apr 23 13:58:10 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BF933A6A2F; Wed, 23 Apr 2008 13:58:10 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094DD3A6BE5 for ; Wed, 23 Apr 2008 13:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.146 X-Spam-Level: X-Spam-Status: No, score=-105.146 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 nG5gQyNSdXaE for ; Wed, 23 Apr 2008 13:58:08 -0700 (PDT) Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by core3.amsl.com (Postfix) with ESMTP id 3E6D43A67FE for ; Wed, 23 Apr 2008 13:58:08 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-13.tower-203.messagelabs.com!1208984284!15504181!1 X-StarScan-Version: 5.5.12.14.2; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 29718 invoked from network); 23 Apr 2008 20:58:05 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-13.tower-203.messagelabs.com with AES256-SHA encrypted SMTP; 23 Apr 2008 20:58:05 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3NKwCZE017454 for ; Wed, 23 Apr 2008 16:58:12 -0400 Received: from alph001.aldc.att.com (alph001.aldc.att.com [135.53.7.26]) by mlpi135.enaf.sfdc.sbc.com (8.14.0/8.14.0) with ESMTP id m3NKw160017361 for ; Wed, 23 Apr 2008 16:58:09 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id m3NKw0lq029141 for ; Wed, 23 Apr 2008 16:58:00 -0400 Received: from maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alph001.aldc.att.com (8.14.0/8.14.0) with ESMTP id m3NKvqlO028992 for ; Wed, 23 Apr 2008 16:57:53 -0400 Message-Id: <200804232057.m3NKvqlO028992@alph001.aldc.att.com> Received: from acmt.att.com (dyp004256dys.mt.att.com[135.16.251.231](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20080423205752gw100l7o5he>; Wed, 23 Apr 2008 20:57:52 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 23 Apr 2008 16:57:51 -0400 To: "Murtaza Chiba (mchiba)" , "Jeff W. Boote" From: Al Morton In-Reply-To: References: <47C2C60C.9070807@ripe.net> <47DE8A2D.40409@ripe.net> <200804162137.m3GLbINU026332@klph001.kcdc.att.com> <480D7A52.3020005@ripe.net> <200804230338.m3N3cSfL026431@alph001.aldc.att.com> <480EB16A.4070503@internet2.edu> <200804231326.m3NDQprN004167@alph001.aldc.att.com> Mime-Version: 1.0 Cc: Henk Uijterwaal , IETF IPPM WG Subject: Re: [ippm] WGLC for draft-ietf-ippm-twamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org At 01:12 PM 4/23/2008, Murtaza Chiba (mchiba) wrote: >Al and Jeff, > What I meant is that there is no way to figure out which >extensions the client and server are supporting without actually sending >a message and seeing if it is rejected! That's not necessarily the case, take this as an example: http://tools.ietf.org/html/draft-morton-ippm-more-twamp-00#section-3.1 The Server indicates the modes it will support in the Server Greeting. The Control-Client cannot use an unsupported mode. > IMHO there is more than just textual clarification that is >required. Understood. Do others have opinions? Al _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From cachar@urban-hq.com Thu Apr 24 12:32:05 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACBF528C300; Thu, 24 Apr 2008 12:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -79.912 X-Spam-Level: X-Spam-Status: No, score=-79.912 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] 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 sARqHj+uTMiQ; Thu, 24 Apr 2008 12:32:03 -0700 (PDT) Received: from 190-50-103-216.speedy.com.ar (unknown [190.50.103.216]) by core3.amsl.com (Postfix) with SMTP id 9900B3A6D41; Thu, 24 Apr 2008 12:31:52 -0700 (PDT) X-Originating-IP: 219.24.250.240 by smtp.190.50.103.216; Thu, 24 Apr 2008 15:31:57 -0500 Message-ID: From: "Shawna William" Reply-To: "Shawna William" To: iporpr-bounces@ietf.org Subject: One of a kind replicas Date: Thu, 24 Apr 2008 15:31:57 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit With hundreds of models to choose from, rock bottom prices and the best customer service in the whole wide web, Prestige Replicas has become the standard by which replica watches stores are measured. It's no wonder every day hundreds of new visitors flock to this website in search of the ultimate (yet affordable) gift: a replica Breitling watch. And every one of these visitors has been exceedingly delighted with the quality of their new Breitling timepiece. http://regafufevil75.blogspot.com/ Prestige Replicas is a well-established online store that has made the purchase of a replica timepiece easy, safe and affordable. They take pride in the exceptional quality watches they offer, and will do whatever it takes to provide you with a distinctive replica timepiece like the one you've always wanted. That's why they now offer an extra 15% discount in the purchase of two watches. Just when you thought Prestige Replicas couldn't get any better, they have improved the perfect watch shopping experience! http://regafufevil75.blogspot.com/ From cab@rsl.dk Sun Apr 27 10:21:56 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0C8B28C175; Sun, 27 Apr 2008 10:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -68.915 X-Spam-Level: X-Spam-Status: No, score=-68.915 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_EQ_DYNAMIC=1.144, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, USER_IN_WHITELIST=-100] 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 P7lOnsSsjuJ7; Sun, 27 Apr 2008 10:21:56 -0700 (PDT) Received: from host132-102-dynamic.26-79-r.retail.telecomitalia.it (host132-102-dynamic.26-79-r.retail.telecomitalia.it [79.26.102.132]) by core3.amsl.com (Postfix) with SMTP id A63C928C166; Sun, 27 Apr 2008 10:21:44 -0700 (PDT) X-Originating-IP: 254.0.118.249 by smtp.79.26.102.132; Sun, 27 Apr 2008 13:21:48 -0500 Message-ID: From: "Bianca Pollock" Reply-To: "Bianca Pollock" To: iporpr-bounces@ietf.org Subject: Hot replica watches from 2008 Date: Sun, 27 Apr 2008 13:21:48 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you seen the latest Gucci handbags, from their 2008 collection? They're so beautiful and stylish... and so expensive! But I just found this store, Prestige Replicas, that offers them at just a fraction of their cost. Granted, they're replicas, but they look just like the real deal, and the prices are so low, that now you can have not just one Gucci bag, but two or three of them! The best part is that at Prestige Replicas they have such a wide collection, organized by styles, that you'll feel like a kid in a candy store! Seriously, if you love Gucci bags, you will adore Prestige Replicas! http://tehicuzokep03.blogspot.com/ From ippm-bounces@ietf.org Sun Apr 27 23:25:30 2008 Return-Path: X-Original-To: ippm-archive@megatron.ietf.org Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745373A6B97; Sun, 27 Apr 2008 23:25:30 -0700 (PDT) X-Original-To: ippm@core3.amsl.com Delivered-To: ippm@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EDDA3A6B97 for ; Sun, 27 Apr 2008 23:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 9rbKUKYkDkb1 for ; Sun, 27 Apr 2008 23:25:28 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 28F9F3A6B1E for ; Sun, 27 Apr 2008 23:25:26 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Mon, 28 Apr 2008 08:25:29 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Apr 2008 08:25:28 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Apr 2008 08:27:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-Id: <1B6169C658325341A3B8066E23919E1C0129491E@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <47B30B67.5090906@ripe.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comparism of metrics Thread-Index: AchuVH63hXE6LVZHSqqqcTrI0JeYBgAAZcbg References: <47B18322.1020507@ripe.net> <1B6169C658325341A3B8066E23919E1CCC7F62@S4DE8PSAANK.mitte.t-com.de> <47B30B67.5090906@ripe.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 28 Apr 2008 06:25:28.0847 (UTC) FILETIME=[A71339F0:01C8A8F8] Cc: ippm@ietf.org Subject: [ippm] Comparism of metrics X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ippm-bounces@ietf.org Errors-To: ippm-bounces@ietf.org Hello Henk, there has been no discussion on the list since while and I assume comparing metrics still is an open issue. A point I was concerned about is how to compare probes of different probe sizes (say one of 100 000 probes measured with system 1 as compared to one of 10 000 probes measured by system 2 during the same time interval T). A possibility is to create 10 probe sets of 10 000 probes of the first set and then compare the statistical properties of samples of the same size only. One obviously has to pick the 10 probe sets with a reasonable function, as each set must be represenative for the entire time interval T. Regards, Rudiger _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm From c.gallus@dr-it.de Wed Apr 30 11:42:46 2008 Return-Path: X-Original-To: ietfarch-ippm-archive@core3.amsl.com Delivered-To: ietfarch-ippm-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1980E3A699C; Wed, 30 Apr 2008 11:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -65.634 X-Spam-Level: X-Spam-Status: No, score=-65.634 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, HELO_DYNAMIC_IPADDR2=4.395, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_RECV_SPEEDY_AR=0.808, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX_NOV5A=1.062, TVD_RCVD_IP=1.931, USER_IN_WHITELIST=-100] 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 gfjCSOStX3fA; Wed, 30 Apr 2008 11:42:45 -0700 (PDT) Received: from 201-250-106-143.speedy.com.ar (unknown [201.250.106.143]) by core3.amsl.com (Postfix) with SMTP id BC87A3A6A53; Wed, 30 Apr 2008 11:42:34 -0700 (PDT) X-Originating-IP: 114.230.0.182 by smtp.201.250.106.143; Wed, 30 Apr 2008 14:42:37 -0500 Message-ID: From: "Betty Houston" Reply-To: "Betty Houston" To: iporpr-bounces@ietf.org Subject: New replica watches delivered fast Date: Wed, 30 Apr 2008 14:42:37 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Zenith Swiss Watches have been manufactured since 1865, and have always been worn by the Elite. Today, Prestige Replicas has removed that class difference and it can help you find the Zenith watch of your choice at a price that fits your budget! You might ask yourself how, and the answer is simple. Prestige Replicas offers replica watches made of the highest quality materials, and due to a recent redesign of the site, you now get 15% off when you purchase two or more. http://zobasozofog51.blogspot.com/ Visit Prestige Replicas now, and rest assured that when you place an order, it will be shipped immediately, and that your privacy and that of your order are ensured! http://zobasozofog51.blogspot.com/