From msec-bounces@ietf.org Mon Nov 3 07:00:15 2008 Return-Path: X-Original-To: msec-archive@lists.ietf.org Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C21F28C237; Mon, 3 Nov 2008 07:00:15 -0800 (PST) X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA4E28C11F for ; Mon, 3 Nov 2008 07:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, NO_RELAYS=-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 mMXxLvcWdajX for ; Mon, 3 Nov 2008 07:00:14 -0800 (PST) Received: from puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [IPv6:2001:628:408:102::30:0]) by core3.amsl.com (Postfix) with ESMTP id 8BA203A697D for ; Mon, 3 Nov 2008 07:00:12 -0800 (PST) Received: from [IPv6?2001?628?408?104?1046?dc94?9a9e?6e27] (unknown [IPv6:2001:628:408:104:1046:dc94:9a9e:6e27]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id 5B05E22977C for ; Mon, 3 Nov 2008 16:00:10 +0100 (CET) Message-ID: <490F11E4.5030006@cosy.sbg.ac.at> Date: Mon, 03 Nov 2008 15:59:48 +0100 From: Michael Noisternig User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: msec@ietf.org Subject: [MSEC] shared SA w/ automatic keying X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: msec-bounces@ietf.org Errors-To: msec-bounces@ietf.org Hi all, the IPsec SA/SP management framework supports SAs shared among multiple devices (for unicast communication). This is probably frequently done when keys are set up manually. Because of this sharing, IKE cannot be used for automatic keying. However, also GKM protocols cannot be used since the SPI (selected by the GCKS) may conflict with current SPIs. (SAs for unicast packets are looked up using the SPI solely. A distinguisher like a multicast dst. address as in msec-ipsec-extensions is not at hand.) It seems that SA sharing is not compatible with automatic keying (or at least, automatic SPI selection); however, I could not find any statement on this in the ipsec/msec documents. Of course, a question is why you would want to do SA sharing. (a) One point is connection state overhead. (b) Another may be unidirectional links. Consider this (contrived) scenario: A (GCKS) ^ ^ / \ v v B---->C A can communicate bidirectionally with B and C, but C cannot send data to B. Therefore, B and C cannot negotiate keys; however, C may receive shared keys from A (which could be the GCKS in addition to a normal group member). Not sure if (b) would happen in real world, but (a) may. What is your opinion on this issue? Thanks for any answers, Michael _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Nov 3 07:00:15 2008 Return-Path: X-Original-To: msec-archive@optimus.ietf.org Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C21F28C237; Mon, 3 Nov 2008 07:00:15 -0800 (PST) X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DA4E28C11F for ; Mon, 3 Nov 2008 07:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, NO_RELAYS=-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 mMXxLvcWdajX for ; Mon, 3 Nov 2008 07:00:14 -0800 (PST) Received: from puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [IPv6:2001:628:408:102::30:0]) by core3.amsl.com (Postfix) with ESMTP id 8BA203A697D for ; Mon, 3 Nov 2008 07:00:12 -0800 (PST) Received: from [IPv6?2001?628?408?104?1046?dc94?9a9e?6e27] (unknown [IPv6:2001:628:408:104:1046:dc94:9a9e:6e27]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id 5B05E22977C for ; Mon, 3 Nov 2008 16:00:10 +0100 (CET) Message-ID: <490F11E4.5030006@cosy.sbg.ac.at> Date: Mon, 03 Nov 2008 15:59:48 +0100 From: Michael Noisternig User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: msec@ietf.org Subject: [MSEC] shared SA w/ automatic keying X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: msec-bounces@ietf.org Errors-To: msec-bounces@ietf.org Hi all, the IPsec SA/SP management framework supports SAs shared among multiple devices (for unicast communication). This is probably frequently done when keys are set up manually. Because of this sharing, IKE cannot be used for automatic keying. However, also GKM protocols cannot be used since the SPI (selected by the GCKS) may conflict with current SPIs. (SAs for unicast packets are looked up using the SPI solely. A distinguisher like a multicast dst. address as in msec-ipsec-extensions is not at hand.) It seems that SA sharing is not compatible with automatic keying (or at least, automatic SPI selection); however, I could not find any statement on this in the ipsec/msec documents. Of course, a question is why you would want to do SA sharing. (a) One point is connection state overhead. (b) Another may be unidirectional links. Consider this (contrived) scenario: A (GCKS) ^ ^ / \ v v B---->C A can communicate bidirectionally with B and C, but C cannot send data to B. Therefore, B and C cannot negotiate keys; however, C may receive shared keys from A (which could be the GCKS in addition to a normal group member). Not sure if (b) would happen in real world, but (a) may. What is your opinion on this issue? Thanks for any answers, Michael _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Nov 3 19:14:24 2008 Return-Path: X-Original-To: msec-archive@lists.ietf.org Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666FC3A6AAB; Mon, 3 Nov 2008 19:14:24 -0800 (PST) X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F9E3A6AAB for ; Mon, 3 Nov 2008 19:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTOTJ4cGV2Sk for ; Mon, 3 Nov 2008 19:14:21 -0800 (PST) Received: from swip002.ftl.affinity.com (lvs00-fl-swip002.ftl.affinity.com [216.219.253.12]) by core3.amsl.com (Postfix) with ESMTP id 9A6063A6931 for ; Mon, 3 Nov 2008 19:14:21 -0800 (PST) Received: ("??"@swip002.ftl.affinity.com) by swip002.ftl.affinity.com id S360815AbYKDDOR for ; Mon, 3 Nov 2008 22:14:17 -0500 References: <490F11E4.5030006@cosy.sbg.ac.at> In-Reply-To: <490F11E4.5030006@cosy.sbg.ac.at> From: gmgietf@identaware.com To: Michael Noisternig Date: Mon, 03 Nov 2008 22:14:17 -0500 Mime-Version: 1.0 Message-Id: Cc: msec@ietf.org Subject: Re: [MSEC] shared SA w/ automatic keying X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: msec-bounces@ietf.org Errors-To: msec-bounces@ietf.org Hi Michael, I am not sure that I understand your question. I think you are describing an application wherein one unicast IPsec SA is shared by a set of three or more endpoints. Although this proposed SA resembles a group IPsec SA, in your scenario the SA is identified only by its SPI, and not using the 2-tuple {destination multicast IP address, SPI}. The SA identifier topic is discussed in section 4.1 of RFC4301. It explains how SPI assignments of a GKM are kept independent of the SPI assigned by an IKE subsystem. Perhaps your question could be rephrased to be: how could IKE and a GKM coordinate their SPI assignments such that IKE does not assign a unicast SPI that has been allocated by the GKM to a group IPsec SA? or assure that an SPI allocated by the IKE is not used by the GKM? There is no IPsec standardized method to achieve this constraint on unicast SPI assignment. Coordination of IKE and the GKM would require the distributed management of the SPI identifier space across all key management systems (both IKE and GKM) participating in a security domain. hth, George Michael Noisternig writes: > Hi all, > > the IPsec SA/SP management framework supports SAs shared among multiple > devices (for unicast communication). This is probably frequently done when > keys are set up manually. Because of this sharing, IKE cannot be used for > automatic keying. However, also GKM protocols cannot be used since the SPI > (selected by the GCKS) may conflict with current SPIs. (SAs for unicast > packets are looked up using the SPI solely. A distinguisher like a > multicast dst. address as in msec-ipsec-extensions is not at hand.) > > It seems that SA sharing is not compatible with automatic keying (or at > least, automatic SPI selection); however, I could not find any statement > on this in the ipsec/msec documents. > > Of course, a question is why you would want to do SA sharing. (a) One > point is connection state overhead. (b) Another may be unidirectional > links. Consider this (contrived) scenario: > > A (GCKS) > ^ ^ > / \ > v v > B---->C > > A can communicate bidirectionally with B and C, but C cannot send data to > B. Therefore, B and C cannot negotiate keys; however, C may receive shared > keys from A (which could be the GCKS in addition to a normal group > member). > > Not sure if (b) would happen in real world, but (a) may. > > What is your opinion on this issue? > > Thanks for any answers, > Michael > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Nov 3 19:14:24 2008 Return-Path: X-Original-To: msec-archive@optimus.ietf.org Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 666FC3A6AAB; Mon, 3 Nov 2008 19:14:24 -0800 (PST) X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6F9E3A6AAB for ; Mon, 3 Nov 2008 19:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTOTJ4cGV2Sk for ; Mon, 3 Nov 2008 19:14:21 -0800 (PST) Received: from swip002.ftl.affinity.com (lvs00-fl-swip002.ftl.affinity.com [216.219.253.12]) by core3.amsl.com (Postfix) with ESMTP id 9A6063A6931 for ; Mon, 3 Nov 2008 19:14:21 -0800 (PST) Received: ("??"@swip002.ftl.affinity.com) by swip002.ftl.affinity.com id S360815AbYKDDOR for ; Mon, 3 Nov 2008 22:14:17 -0500 References: <490F11E4.5030006@cosy.sbg.ac.at> In-Reply-To: <490F11E4.5030006@cosy.sbg.ac.at> From: gmgietf@identaware.com To: Michael Noisternig Date: Mon, 03 Nov 2008 22:14:17 -0500 Mime-Version: 1.0 Message-Id: Cc: msec@ietf.org Subject: Re: [MSEC] shared SA w/ automatic keying X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: msec-bounces@ietf.org Errors-To: msec-bounces@ietf.org Hi Michael, I am not sure that I understand your question. I think you are describing an application wherein one unicast IPsec SA is shared by a set of three or more endpoints. Although this proposed SA resembles a group IPsec SA, in your scenario the SA is identified only by its SPI, and not using the 2-tuple {destination multicast IP address, SPI}. The SA identifier topic is discussed in section 4.1 of RFC4301. It explains how SPI assignments of a GKM are kept independent of the SPI assigned by an IKE subsystem. Perhaps your question could be rephrased to be: how could IKE and a GKM coordinate their SPI assignments such that IKE does not assign a unicast SPI that has been allocated by the GKM to a group IPsec SA? or assure that an SPI allocated by the IKE is not used by the GKM? There is no IPsec standardized method to achieve this constraint on unicast SPI assignment. Coordination of IKE and the GKM would require the distributed management of the SPI identifier space across all key management systems (both IKE and GKM) participating in a security domain. hth, George Michael Noisternig writes: > Hi all, > > the IPsec SA/SP management framework supports SAs shared among multiple > devices (for unicast communication). This is probably frequently done when > keys are set up manually. Because of this sharing, IKE cannot be used for > automatic keying. However, also GKM protocols cannot be used since the SPI > (selected by the GCKS) may conflict with current SPIs. (SAs for unicast > packets are looked up using the SPI solely. A distinguisher like a > multicast dst. address as in msec-ipsec-extensions is not at hand.) > > It seems that SA sharing is not compatible with automatic keying (or at > least, automatic SPI selection); however, I could not find any statement > on this in the ipsec/msec documents. > > Of course, a question is why you would want to do SA sharing. (a) One > point is connection state overhead. (b) Another may be unidirectional > links. Consider this (contrived) scenario: > > A (GCKS) > ^ ^ > / \ > v v > B---->C > > A can communicate bidirectionally with B and C, but C cannot send data to > B. Therefore, B and C cannot negotiate keys; however, C may receive shared > keys from A (which could be the GCKS in addition to a normal group > member). > > Not sure if (b) would happen in real world, but (a) may. > > What is your opinion on this issue? > > Thanks for any answers, > Michael > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Nov 4 06:53:55 2008 Return-Path: X-Original-To: msec-archive@optimus.ietf.org Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3153A692D; Tue, 4 Nov 2008 06:53:55 -0800 (PST) X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C583A6962 for ; Tue, 4 Nov 2008 06:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.117 X-Spam-Level: X-Spam-Status: No, score=0.117 tagged_above=-999 required=5 tests=[AWL=-1.973, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, HOST_EQ_AT=0.745, HOST_EQ_STATIC=1.172] 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 65MQOeF4fLph for ; Tue, 4 Nov 2008 06:53:48 -0800 (PST) Received: from puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [IPv6:2001:628:408:102::30:0]) by core3.amsl.com (Postfix) with ESMTP id 64F8A3A67AA for ; Tue, 4 Nov 2008 06:53:47 -0800 (PST) Received: from [172.16.10.68] (85-124-63-18.static.xdsl-line.inode.at [85.124.63.18]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id D6E87228D65; Tue, 4 Nov 2008 15:53:44 +0100 (CET) Message-ID: <491061E1.1070400@cosy.sbg.ac.at> Date: Tue, 04 Nov 2008 15:53:21 +0100 From: Michael Noisternig User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: gmgietf@identaware.com References: <490F11E4.5030006@cosy.sbg.ac.at> In-Reply-To: Cc: msec@ietf.org Subject: Re: [MSEC] shared SA w/ automatic keying X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: msec-bounces@ietf.org Errors-To: msec-bounces@ietf.org Hi George, gmgietf@identaware.com schrieb: > Hi Michael, > I am not sure that I understand your question. I think you are > describing an application wherein one unicast IPsec SA is shared by a > set of three or more endpoints. Although this proposed SA resembles a Right. A unicast SA shared among several endpoints. > group IPsec SA, in your scenario the SA is identified only by its SPI, > and not using the 2-tuple {destination multicast IP address, SPI}. The Sure, because there is no multicast address used; communication is unicast, just the SA (the keys) are shared/coordinated among all the endpoints. > SA identifier topic is discussed in section 4.1 of RFC4301. It explains > how SPI assignments of a GKM are kept independent of the SPI assigned by > an IKE subsystem. But this only considers multicast SAs, i.e. packets with a multicast address as destination. > Perhaps your question could be rephrased to be: how could IKE and a GKM > coordinate their SPI assignments such that IKE does not assign a unicast > SPI that has been allocated by the GKM to a group IPsec SA? or assure > that an SPI allocated by the IKE is not used by the GKM? Or: How could IKE and a GKM coordinate their SPI assignments such that GKM does not assign a SPI for a group (shared unicast) SA that has been allocated by the IKE to a unicast SA? I could rephrase my question like that, yes. > There is no IPsec standardized method to achieve this constraint on > unicast SPI assignment. Coordination of IKE and the GKM would require > the distributed management of the SPI identifier space across all key > management systems (both IKE and GKM) participating in a security domain. That is what I was thinking, but I was wondering if this issue was touched in any IETF documents. Apparently not. > hth, > George Thanks, Michael > Michael Noisternig writes: >> Hi all, >> the IPsec SA/SP management framework supports SAs shared among >> multiple devices (for unicast communication). This is probably >> frequently done when keys are set up manually. Because of this >> sharing, IKE cannot be used for automatic keying. However, also GKM >> protocols cannot be used since the SPI (selected by the GCKS) may >> conflict with current SPIs. (SAs for unicast packets are looked up >> using the SPI solely. A distinguisher like a multicast dst. address as >> in msec-ipsec-extensions is not at hand.) >> It seems that SA sharing is not compatible with automatic keying (or >> at least, automatic SPI selection); however, I could not find any >> statement on this in the ipsec/msec documents. >> Of course, a question is why you would want to do SA sharing. (a) One >> point is connection state overhead. (b) Another may be unidirectional >> links. Consider this (contrived) scenario: >> A (GCKS) >> ^ ^ >> / \ >> v v >> B---->C >> A can communicate bidirectionally with B and C, but C cannot send data >> to B. Therefore, B and C cannot negotiate keys; however, C may receive >> shared keys from A (which could be the GCKS in addition to a normal >> group member). >> Not sure if (b) would happen in real world, but (a) may. >> What is your opinion on this issue? >> Thanks for any answers, >> Michael >> _______________________________________________ >> MSEC mailing list >> MSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/msec > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Nov 4 06:53:55 2008 Return-Path: X-Original-To: msec-archive@lists.ietf.org Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB3153A692D; Tue, 4 Nov 2008 06:53:55 -0800 (PST) X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98C583A6962 for ; Tue, 4 Nov 2008 06:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.117 X-Spam-Level: X-Spam-Status: No, score=0.117 tagged_above=-999 required=5 tests=[AWL=-1.973, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IP_ADDR=1.119, HOST_EQ_AT=0.745, HOST_EQ_STATIC=1.172] 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 65MQOeF4fLph for ; Tue, 4 Nov 2008 06:53:48 -0800 (PST) Received: from puma.cosy.sbg.ac.at (puma.cosy.sbg.ac.at [IPv6:2001:628:408:102::30:0]) by core3.amsl.com (Postfix) with ESMTP id 64F8A3A67AA for ; Tue, 4 Nov 2008 06:53:47 -0800 (PST) Received: from [172.16.10.68] (85-124-63-18.static.xdsl-line.inode.at [85.124.63.18]) by puma.cosy.sbg.ac.at (Postfix) with ESMTP id D6E87228D65; Tue, 4 Nov 2008 15:53:44 +0100 (CET) Message-ID: <491061E1.1070400@cosy.sbg.ac.at> Date: Tue, 04 Nov 2008 15:53:21 +0100 From: Michael Noisternig User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: gmgietf@identaware.com References: <490F11E4.5030006@cosy.sbg.ac.at> In-Reply-To: Cc: msec@ietf.org Subject: Re: [MSEC] shared SA w/ automatic keying X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: msec-bounces@ietf.org Errors-To: msec-bounces@ietf.org Hi George, gmgietf@identaware.com schrieb: > Hi Michael, > I am not sure that I understand your question. I think you are > describing an application wherein one unicast IPsec SA is shared by a > set of three or more endpoints. Although this proposed SA resembles a Right. A unicast SA shared among several endpoints. > group IPsec SA, in your scenario the SA is identified only by its SPI, > and not using the 2-tuple {destination multicast IP address, SPI}. The Sure, because there is no multicast address used; communication is unicast, just the SA (the keys) are shared/coordinated among all the endpoints. > SA identifier topic is discussed in section 4.1 of RFC4301. It explains > how SPI assignments of a GKM are kept independent of the SPI assigned by > an IKE subsystem. But this only considers multicast SAs, i.e. packets with a multicast address as destination. > Perhaps your question could be rephrased to be: how could IKE and a GKM > coordinate their SPI assignments such that IKE does not assign a unicast > SPI that has been allocated by the GKM to a group IPsec SA? or assure > that an SPI allocated by the IKE is not used by the GKM? Or: How could IKE and a GKM coordinate their SPI assignments such that GKM does not assign a SPI for a group (shared unicast) SA that has been allocated by the IKE to a unicast SA? I could rephrase my question like that, yes. > There is no IPsec standardized method to achieve this constraint on > unicast SPI assignment. Coordination of IKE and the GKM would require > the distributed management of the SPI identifier space across all key > management systems (both IKE and GKM) participating in a security domain. That is what I was thinking, but I was wondering if this issue was touched in any IETF documents. Apparently not. > hth, > George Thanks, Michael > Michael Noisternig writes: >> Hi all, >> the IPsec SA/SP management framework supports SAs shared among >> multiple devices (for unicast communication). This is probably >> frequently done when keys are set up manually. Because of this >> sharing, IKE cannot be used for automatic keying. However, also GKM >> protocols cannot be used since the SPI (selected by the GCKS) may >> conflict with current SPIs. (SAs for unicast packets are looked up >> using the SPI solely. A distinguisher like a multicast dst. address as >> in msec-ipsec-extensions is not at hand.) >> It seems that SA sharing is not compatible with automatic keying (or >> at least, automatic SPI selection); however, I could not find any >> statement on this in the ipsec/msec documents. >> Of course, a question is why you would want to do SA sharing. (a) One >> point is connection state overhead. (b) Another may be unidirectional >> links. Consider this (contrived) scenario: >> A (GCKS) >> ^ ^ >> / \ >> v v >> B---->C >> A can communicate bidirectionally with B and C, but C cannot send data >> to B. Therefore, B and C cannot negotiate keys; however, C may receive >> shared keys from A (which could be the GCKS in addition to a normal >> group member). >> Not sure if (b) would happen in real world, but (a) may. >> What is your opinion on this issue? >> Thanks for any answers, >> Michael >> _______________________________________________ >> MSEC mailing list >> MSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/msec > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Nov 4 11:23:32 2008 Return-Path: X-Original-To: msec-archive@optimus.ietf.org Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A517B3A69A8; Tue, 4 Nov 2008 11:23:32 -0800 (PST) X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E23A3A69A8 for ; Tue, 4 Nov 2008 11:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cPYrQ4H++Z6 for ; Tue, 4 Nov 2008 11:23:30 -0800 (PST) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by core3.amsl.com (Postfix) with ESMTP id A81CE3A6841 for ; Tue, 4 Nov 2008 11:23:30 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 47C265EB99; Tue, 4 Nov 2008 11:22:29 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Nov 2008 11:22:29 -0800 Received: from SC-EXCH1.marvell.com ([10.93.76.25]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Tue, 4 Nov 2008 11:22:28 -0800 From: Paul Lambert To: "gmgietf@identaware.com" , Michael Noisternig Date: Tue, 4 Nov 2008 11:22:27 -0800 Thread-Topic: [MSEC] shared SA w/ automatic keying Thread-Index: Ack+K3BEABE/gj2NS/+XvXvdJ4mVTgAhgkPw Message-ID: <5A22FB9EDAA74547916480634CCC743817AC19CFA3@SC-EXCH1.marvell.com> References: <490F11E4.5030006@cosy.sbg.ac.at> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 04 Nov 2008 19:22:29.0226 (UTC) FILETIME=[AD7904A0:01C93EB2] Cc: "msec@ietf.org" Subject: Re: [MSEC] shared SA w/ automatic keying X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: msec-bounces@ietf.org Errors-To: msec-bounces@ietf.org > -----Original Message----- > From: msec-bounces@ietf.org [mailto:msec-bounces@ietf.org] On Behalf Of > Subject: Re: [MSEC] shared SA w/ automatic keying > > Hi Michael, > > I am not sure that I understand your question. I think you are describing > an > application wherein one unicast IPsec SA is shared by a set of three or > more > endpoints. Although this proposed SA resembles a group IPsec SA, in your > scenario the SA is identified only by its SPI, and not using the 2-tuple > {destination multicast IP address, SPI}. The SA identifier topic is > discussed in section 4.1 of RFC4301. It explains how SPI assignments of a > GKM are kept independent of the SPI assigned by an IKE subsystem. > > Perhaps your question could be rephrased to be: how could IKE and a GKM > coordinate their SPI assignments such that IKE does not assign a unicast > SPI > that has been allocated by the GKM to a group IPsec SA? or assure that an > SPI allocated by the IKE is not used by the GKM? This would be easy if one bit were set aside (like the high order) in the SPI that would be reserved only for multicast SPI. Looking at RFC 4303 ... this is not there :-( but it could be done as a implementation guideline. The notion in RFC 4301 that reuse is possible and then mandating that you are able to demultiplex the overlap is a flawed approach and should be depreciated. The use of an IP address with the SPI should really never be required. Paul > > There is no IPsec standardized method to achieve this constraint on > unicast > SPI assignment. Coordination of IKE and the GKM would require the > distributed management of the SPI identifier space across all key > management > systems (both IKE and GKM) participating in a security domain. > > hth, > George > > Michael Noisternig writes: > > > Hi all, > > > > the IPsec SA/SP management framework supports SAs shared among multiple > > devices (for unicast communication). This is probably frequently done > when > > keys are set up manually. Because of this sharing, IKE cannot be used > for > > automatic keying. However, also GKM protocols cannot be used since the > SPI > > (selected by the GCKS) may conflict with current SPIs. (SAs for unicast > > packets are looked up using the SPI solely. A distinguisher like a > > multicast dst. address as in msec-ipsec-extensions is not at hand.) > > > > It seems that SA sharing is not compatible with automatic keying (or at > > least, automatic SPI selection); however, I could not find any statement > > on this in the ipsec/msec documents. > > > > Of course, a question is why you would want to do SA sharing. (a) One > > point is connection state overhead. (b) Another may be unidirectional > > links. Consider this (contrived) scenario: > > > > A (GCKS) > > ^ ^ > > / \ > > v v > > B---->C > > > > A can communicate bidirectionally with B and C, but C cannot send data > to > > B. Therefore, B and C cannot negotiate keys; however, C may receive > shared > > keys from A (which could be the GCKS in addition to a normal group > > member). > > > > Not sure if (b) would happen in real world, but (a) may. > > > > What is your opinion on this issue? > > > > Thanks for any answers, > > Michael > > _______________________________________________ > > MSEC mailing list > > MSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/msec > > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Nov 4 11:23:32 2008 Return-Path: X-Original-To: msec-archive@lists.ietf.org Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A517B3A69A8; Tue, 4 Nov 2008 11:23:32 -0800 (PST) X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E23A3A69A8 for ; Tue, 4 Nov 2008 11:23:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cPYrQ4H++Z6 for ; Tue, 4 Nov 2008 11:23:30 -0800 (PST) Received: from maili.marvell.com (host2.marvell.com [65.219.4.2]) by core3.amsl.com (Postfix) with ESMTP id A81CE3A6841 for ; Tue, 4 Nov 2008 11:23:30 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 47C265EB99; Tue, 4 Nov 2008 11:22:29 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Nov 2008 11:22:29 -0800 Received: from SC-EXCH1.marvell.com ([10.93.76.25]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Tue, 4 Nov 2008 11:22:28 -0800 From: Paul Lambert To: "gmgietf@identaware.com" , Michael Noisternig Date: Tue, 4 Nov 2008 11:22:27 -0800 Thread-Topic: [MSEC] shared SA w/ automatic keying Thread-Index: Ack+K3BEABE/gj2NS/+XvXvdJ4mVTgAhgkPw Message-ID: <5A22FB9EDAA74547916480634CCC743817AC19CFA3@SC-EXCH1.marvell.com> References: <490F11E4.5030006@cosy.sbg.ac.at> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 04 Nov 2008 19:22:29.0226 (UTC) FILETIME=[AD7904A0:01C93EB2] Cc: "msec@ietf.org" Subject: Re: [MSEC] shared SA w/ automatic keying X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: msec-bounces@ietf.org Errors-To: msec-bounces@ietf.org > -----Original Message----- > From: msec-bounces@ietf.org [mailto:msec-bounces@ietf.org] On Behalf Of > Subject: Re: [MSEC] shared SA w/ automatic keying > > Hi Michael, > > I am not sure that I understand your question. I think you are describing > an > application wherein one unicast IPsec SA is shared by a set of three or > more > endpoints. Although this proposed SA resembles a group IPsec SA, in your > scenario the SA is identified only by its SPI, and not using the 2-tuple > {destination multicast IP address, SPI}. The SA identifier topic is > discussed in section 4.1 of RFC4301. It explains how SPI assignments of a > GKM are kept independent of the SPI assigned by an IKE subsystem. > > Perhaps your question could be rephrased to be: how could IKE and a GKM > coordinate their SPI assignments such that IKE does not assign a unicast > SPI > that has been allocated by the GKM to a group IPsec SA? or assure that an > SPI allocated by the IKE is not used by the GKM? This would be easy if one bit were set aside (like the high order) in the SPI that would be reserved only for multicast SPI. Looking at RFC 4303 ... this is not there :-( but it could be done as a implementation guideline. The notion in RFC 4301 that reuse is possible and then mandating that you are able to demultiplex the overlap is a flawed approach and should be depreciated. The use of an IP address with the SPI should really never be required. Paul > > There is no IPsec standardized method to achieve this constraint on > unicast > SPI assignment. Coordination of IKE and the GKM would require the > distributed management of the SPI identifier space across all key > management > systems (both IKE and GKM) participating in a security domain. > > hth, > George > > Michael Noisternig writes: > > > Hi all, > > > > the IPsec SA/SP management framework supports SAs shared among multiple > > devices (for unicast communication). This is probably frequently done > when > > keys are set up manually. Because of this sharing, IKE cannot be used > for > > automatic keying. However, also GKM protocols cannot be used since the > SPI > > (selected by the GCKS) may conflict with current SPIs. (SAs for unicast > > packets are looked up using the SPI solely. A distinguisher like a > > multicast dst. address as in msec-ipsec-extensions is not at hand.) > > > > It seems that SA sharing is not compatible with automatic keying (or at > > least, automatic SPI selection); however, I could not find any statement > > on this in the ipsec/msec documents. > > > > Of course, a question is why you would want to do SA sharing. (a) One > > point is connection state overhead. (b) Another may be unidirectional > > links. Consider this (contrived) scenario: > > > > A (GCKS) > > ^ ^ > > / \ > > v v > > B---->C > > > > A can communicate bidirectionally with B and C, but C cannot send data > to > > B. Therefore, B and C cannot negotiate keys; however, C may receive > shared > > keys from A (which could be the GCKS in addition to a normal group > > member). > > > > Not sure if (b) would happen in real world, but (a) may. > > > > What is your opinion on this issue? > > > > Thanks for any answers, > > Michael > > _______________________________________________ > > MSEC mailing list > > MSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/msec > > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Nov 6 12:24:58 2008 Return-Path: X-Original-To: msec-archive@lists.ietf.org Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0803A67E3; Thu, 6 Nov 2008 12:24:58 -0800 (PST) X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74FB3A67E3 for ; Thu, 6 Nov 2008 12:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DRUGS_MUSCLE=0.01, J_CHICKENPOX_22=0.6, MANGLED_SOMA=2.5, 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 TZYcanqe0F2S for ; Thu, 6 Nov 2008 12:24:55 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 90DE93A67AC for ; Thu, 6 Nov 2008 12:24:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,559,1220227200"; d="scan'208";a="189934272" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2008 20:24:20 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mA6KOKJb005529; Thu, 6 Nov 2008 12:24:20 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id mA6KOKP5008757; Thu, 6 Nov 2008 20:24:20 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 12:24:20 -0800 Received: from [128.107.114.39] ([128.107.114.39]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 12:24:19 -0800 In-Reply-To: <7964CC56F43D7B47A00DA9CA94D62253014D2D59@DEMUEXC014.nsn-intra.net> References: <7964CC56F43D7B47A00DA9CA94D62253014D2D59@DEMUEXC014.nsn-intra.net> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Weis Date: Thu, 6 Nov 2008 12:24:20 -0800 To: "Jerichow, Anja (NSN - DE/Munich)" X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 06 Nov 2008 20:24:19.0920 (UTC) FILETIME=[A60B7D00:01C9404D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2139; t=1226003060; x=1226867060; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Re=3A=20[MSEC]=20FW=3A=20New=20Version=20Notifi cation=20for=20draft-jerichow-msec-mikey-genext-oma-00 |Sender:=20; bh=rDNXP8Jt32tPq8utHAItPPk42CYkaPvUZ60Axt1lSVA=; b=IbKv/7BmKOjIDLKQuRUre9N7KRBMeEKPSC93uPu1OtwWtZ/pQzvDsWAgUE GJCjb799g0v+gvlnN+hgCF/fRyV2ObHVdcu1xjRSHkaY+baYqnn8OmQfC6ym hV0e0F7tUttUwPeHAYCBwNOQiWEq9UEhjFT1yXS2o8nOAwN9mZ0s4=; Authentication-Results: sj-dkim-1; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: MSEC@ietf.org Subject: Re: [MSEC] FW: New Version Notification for draft-jerichow-msec-mikey-genext-oma-00 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: msec-bounces@ietf.orgFrom msec-bounces@ietf.org Thu Nov 6 12:24:58 2008 Return-Path: X-Original-To: msec-archive@optimus.ietf.org Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0803A67E3; Thu, 6 Nov 2008 12:24:58 -0800 (PST) X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D74FB3A67E3 for ; Thu, 6 Nov 2008 12:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DRUGS_MUSCLE=0.01, J_CHICKENPOX_22=0.6, MANGLED_SOMA=2.5, 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 TZYcanqe0F2S for ; Thu, 6 Nov 2008 12:24:55 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 90DE93A67AC for ; Thu, 6 Nov 2008 12:24:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,559,1220227200"; d="scan'208";a="189934272" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2008 20:24:20 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mA6KOKJb005529; Thu, 6 Nov 2008 12:24:20 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id mA6KOKP5008757; Thu, 6 Nov 2008 20:24:20 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 12:24:20 -0800 Received: from [128.107.114.39] ([128.107.114.39]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 12:24:19 -0800 In-Reply-To: <7964CC56F43D7B47A00DA9CA94D62253014D2D59@DEMUEXC014.nsn-intra.net> References: <7964CC56F43D7B47A00DA9CA94D62253014D2D59@DEMUEXC014.nsn-intra.net> Mime-Version: 1.0 (Apple Message framework v753.1) Message-Id: From: Brian Weis Date: Thu, 6 Nov 2008 12:24:20 -0800 To: "Jerichow, Anja (NSN - DE/Munich)" X-Mailer: Apple Mail (2.753.1) X-OriginalArrivalTime: 06 Nov 2008 20:24:19.0920 (UTC) FILETIME=[A60B7D00:01C9404D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2139; t=1226003060; x=1226867060; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Re=3A=20[MSEC]=20FW=3A=20New=20Version=20Notifi cation=20for=20draft-jerichow-msec-mikey-genext-oma-00 |Sender:=20; bh=rDNXP8Jt32tPq8utHAItPPk42CYkaPvUZ60Axt1lSVA=; b=IbKv/7BmKOjIDLKQuRUre9N7KRBMeEKPSC93uPu1OtwWtZ/pQzvDsWAgUE GJCjb799g0v+gvlnN+hgCF/fRyV2ObHVdcu1xjRSHkaY+baYqnn8OmQfC6ym hV0e0F7tUttUwPeHAYCBwNOQiWEq9UEhjFT1yXS2o8nOAwN9mZ0s4=; Authentication-Results: sj-dkim-1; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: MSEC@ietf.org Subject: Re: [MSEC] FW: New Version Notification for draft-jerichow-msec-mikey-genext-oma-00 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: msec-bounces@ietf.o Errors-To: msec-bounces@ietf.org Hi Anja, Thanks for mentioning your draft to the members of this list. Since the draft is already in IETF last call as an individual submission, comments should be sent to the ietf@ietf.org mailing list rather than the MSEC WG list. Brian On Oct 24, 2008, at 10:46 AM, Jerichow, Anja (NSN - DE/Munich) wrote: > > Hi, > > this draft has been submitted to IETF. > It adds 2 more subtypes to the OMA BCAST payload subtype name space > specified in RFC4909. > > I kindly ask for your review and the further processing to become an > RFC. > > Many thanks in advance, > Anja Jerichow. > > --- > Anja Jerichow (Senior Specialist Standardisation) > Nokia Siemens Networks GmbH & Co.KG > Martinstr. 76 (KuM 65-310), 81541 Munich, Germany > (tel.+49 89 636-45868, mob.+49 160 90983818, fax.+49 89 636-49158) > > -----Original Message----- > From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Friday, October 24, 2008 6:39 PM > To: Jerichow, Anja (NSN - DE/Munich) > Cc: laurent.piron@nagravision.com > Subject: New Version Notification for > draft-jerichow-msec-mikey-genext-oma-00 > > > A new version of I-D, draft-jerichow-msec-mikey-genext-oma-00.txt has > been successfuly submitted by Anja Jerichow and posted to the IETF > repository. > > Filename: draft-jerichow-msec-mikey-genext-oma > Revision: 00 > Title: MIKEY General Extension Payload for OMA BCAST 1.0 > Creation_date: 2008-10-24 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > This document extends the General Extension Payload for OMA BCAST > usage defined in RFC 4909 [1]. It adds necessary support for the > newly specified management data as defined in the Open Mobile > Alliance's (OMA) Broadcast (BCAST) group's Service and Content > protection specification [2]. > > > > > The IETF Secretariat. > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec rg Errors-To: msec-bounces@ietf.org Hi Anja, Thanks for mentioning your draft to the members of this list. Since the draft is already in IETF last call as an individual submission, comments should be sent to the ietf@ietf.org mailing list rather than the MSEC WG list. Brian On Oct 24, 2008, at 10:46 AM, Jerichow, Anja (NSN - DE/Munich) wrote: > > Hi, > > this draft has been submitted to IETF. > It adds 2 more subtypes to the OMA BCAST payload subtype name space > specified in RFC4909. > > I kindly ask for your review and the further processing to become an > RFC. > > Many thanks in advance, > Anja Jerichow. > > --- > Anja Jerichow (Senior Specialist Standardisation) > Nokia Siemens Networks GmbH & Co.KG > Martinstr. 76 (KuM 65-310), 81541 Munich, Germany > (tel.+49 89 636-45868, mob.+49 160 90983818, fax.+49 89 636-49158) > > -----Original Message----- > From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Friday, October 24, 2008 6:39 PM > To: Jerichow, Anja (NSN - DE/Munich) > Cc: laurent.piron@nagravision.com > Subject: New Version Notification for > draft-jerichow-msec-mikey-genext-oma-00 > > > A new version of I-D, draft-jerichow-msec-mikey-genext-oma-00.txt has > been successfuly submitted by Anja Jerichow and posted to the IETF > repository. > > Filename: draft-jerichow-msec-mikey-genext-oma > Revision: 00 > Title: MIKEY General Extension Payload for OMA BCAST 1.0 > Creation_date: 2008-10-24 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > This document extends the General Extension Payload for OMA BCAST > usage defined in RFC 4909 [1]. It adds necessary support for the > newly specified management data as defined in the Open Mobile > Alliance's (OMA) Broadcast (BCAST) group's Service and Content > protection specification [2]. > > > > > The IETF Secretariat. > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www.ietf.org/mailman/listinfo/msec -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Nov 20 11:35:00 2008 Return-Path: X-Original-To: msec-archive@lists.ietf.org Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F3C3A6906; Thu, 20 Nov 2008 11:35:00 -0800 (PST) X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA1E3A6906 for ; Thu, 20 Nov 2008 11:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgAqKEqgwRwR for ; Thu, 20 Nov 2008 11:34:58 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 4A53F3A677D for ; Thu, 20 Nov 2008 11:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1227209697; x=1258745697; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding:x-ironport-av; z=Message-ID:=20<4925BBDC.2020002@qualcomm.com>|Date:=20Th u,=2020=20Nov=202008=2011:34:52=20-0800|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.18=20(Windows/20081105)|MIME-Version:=201 .0|To:=20msec@ietf.org|Subject:=20MSEC=20WGLC=20on=20draf t-ietf-msec-ipsec-group-counter-modes-02=20ending=0D=0A =20Dec=205,=202008|Content-Type:=20text/plain=3B=20charse t=3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5100,188,5440"=3B=20a=3D"13314797"; bh=IXen2wkKYzUma3YQsDzWoUHDcjCUokgs+sglFkUVhU4=; b=EZwGXB/ku/Y6mv/YMPnbXNI4sFQ4IJ4qXKdimubaFa4ovydofFzRt+DP SU0+GVUQDA9mtl/8ATztI5LfhLyNfRdgvXWIArT79hT8HaV7T3Dbldve/ EnAQlT4BhjOmMNRJsdLnrIYsZ1T/mqlj7+VqFC0vYVzPJM2F92vZLd487 I=; X-IronPort-AV: E=McAfee;i="5100,188,5440"; a="13314797" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2008 11:34:57 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKJYuS0025872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Nov 2008 11:34:57 -0800 Received: from [10.50.76.146] (qconnect-10-50-76-146.qualcomm.com [10.50.76.146]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKJYtjR015660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Nov 2008 11:34:56 -0800 Message-ID: <4925BBDC.2020002@qualcomm.com> Date: Thu, 20 Nov 2008 11:34:52 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: msec@ietf.org Subject: [MSEC] MSEC WGLC on draft-ietf-msec-ipsec-group-counter-modes-02 ending Dec 5, 2008 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: msec-bounces@ietf.org Errors-To: msec-bounces@ietf.org Folks, Please review draft-ietf-msec-ipsec-group-counter-modes-02 and send comments tFrom msec-bounces@ietf.org Thu Nov 20 11:35:00 2008 Return-Path: X-Original-To: msec-archive@optimus.ietf.org Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32F3C3A6906; Thu, 20 Nov 2008 11:35:00 -0800 (PST) X-Original-To: msec@core3.amsl.com Delivered-To: msec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BA1E3A6906 for ; Thu, 20 Nov 2008 11:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgAqKEqgwRwR for ; Thu, 20 Nov 2008 11:34:58 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 4A53F3A677D for ; Thu, 20 Nov 2008 11:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1227209697; x=1258745697; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding:x-ironport-av; z=Message-ID:=20<4925BBDC.2020002@qualcomm.com>|Date:=20Th u,=2020=20Nov=202008=2011:34:52=20-0800|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.18=20(Windows/20081105)|MIME-Version:=201 .0|To:=20msec@ietf.org|Subject:=20MSEC=20WGLC=20on=20draf t-ietf-msec-ipsec-group-counter-modes-02=20ending=0D=0A =20Dec=205,=202008|Content-Type:=20text/plain=3B=20charse t=3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5100,188,5440"=3B=20a=3D"13314797"; bh=IXen2wkKYzUma3YQsDzWoUHDcjCUokgs+sglFkUVhU4=; b=EZwGXB/ku/Y6mv/YMPnbXNI4sFQ4IJ4qXKdimubaFa4ovydofFzRt+DP SU0+GVUQDA9mtl/8ATztI5LfhLyNfRdgvXWIArT79hT8HaV7T3Dbldve/ EnAQlT4BhjOmMNRJsdLnrIYsZ1T/mqlj7+VqFC0vYVzPJM2F92vZLd487 I=; X-IronPort-AV: E=McAfee;i="5100,188,5440"; a="13314797" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2008 11:34:57 -0800 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKJYuS0025872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Nov 2008 11:34:57 -0800 Received: from [10.50.76.146] (qconnect-10-50-76-146.qualcomm.com [10.50.76.146]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id mAKJYtjR015660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 20 Nov 2008 11:34:56 -0800 Message-ID: <4925BBDC.2020002@qualcomm.com> Date: Thu, 20 Nov 2008 11:34:52 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: msec@ietf.org Subject: [MSEC] MSEC WGLC on draft-ietf-msec-ipsec-group-counter-modes-02 ending Dec 5, 2008 X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: msec-bounces@ietf.org Errors-To: msec-bounces@ietf.org Folks, Please review draft-ietf-msec-ipsec-group-counter-modes-02 and send commentso the WG mailing list (msec@ietf.org) before Dec 5, 2008 AOE. If there are any issues that you wish to share privately with the chairs or our area advisor, this is your last opportunity; please send email to me (ldondeti@qualcomm.com) or Tim (tim.polk@nist.gov). If there are any existing or planned implementations, we would like to know that as well. Thanks. regards, Lakshminath +1. 858.845.1267 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec to the WG mailing list (msec@ietf.org) before Dec 5, 2008 AOE. If there are any issues that you wish to share privately with the chairs or our area advisor, this is your last opportunity; please send email to me (ldondeti@qualcomm.com) or Tim (tim.polk@nist.gov). If there are any existing or planned implementations, we would like to know that as well. Thanks. regards, Lakshminath +1. 858.845.1267 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www.ietf.org/mailman/listinfo/msec From mariajose.bochatey@agcba.gov.ar Tue Nov 25 17:53:42 2008 Return-Path: X-Original-To: ietfarch-msec-archive@core3.amsl.com Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FD413A6B08 for ; Tue, 25 Nov 2008 17:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.057 X-Spam-Level: X-Spam-Status: No, score=-9.057 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_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_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, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, 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 r4gciEbLkhMm for ; Tue, 25 Nov 2008 17:53:42 -0800 (PST) Received: from 201-42-16-164.dsl.telesp.net.br (201-42-16-164.dsl.telesp.net.br [201.42.16.164]) by core3.amsl.com (Postfix) with SMTP id B94113A6C7E for ; Tue, 25 Nov 2008 17:53:39 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081126015340.B94113A6C7E@core3.amsl.com> Date: Tue, 25 Nov 2008 17:53:39 -0800 (PST) Click here to view as a webpage From mail@aistudios.co.uk Tue Nov 25 22:44:18 2008 Return-Path: X-Original-To: ietfarch-msec-archive@core3.amsl.com Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1EC3A6B2E for ; Tue, 25 Nov 2008 22:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.181 X-Spam-Level: X-Spam-Status: No, score=-20.181 tagged_above=-999 required=5 tests=[BAYES_60=1, 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, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, 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 qI5MLZoIA6VI for ; Tue, 25 Nov 2008 22:44:18 -0800 (PST) Received: from 75-172-69-14.tukw.qwest.net (75-172-69-14.tukw.qwest.net [75.172.69.14]) by core3.amsl.com (Postfix) with SMTP id 1C5DC3A6A31 for ; Tue, 25 Nov 2008 22:44:15 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081126064417.1C5DC3A6A31@core3.amsl.com> Date: Tue, 25 Nov 2008 22:44:15 -0800 (PST) Click here to view as a webpage From jobs@aliceandolivia.com Wed Nov 26 04:03:10 2008 Return-Path: X-Original-To: ietfarch-msec-archive@core3.amsl.com Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13C103A6949 for ; Wed, 26 Nov 2008 04:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.43 X-Spam-Level: X-Spam-Status: No, score=-34.43 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, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_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, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, 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 TKqlesy7+vmF for ; Wed, 26 Nov 2008 04:03:09 -0800 (PST) Received: from c-68-58-202-111.hsd1.sc.comcast.net (c-68-58-202-111.hsd1.sc.comcast.net [68.58.202.111]) by core3.amsl.com (Postfix) with SMTP id A27423A694A for ; Wed, 26 Nov 2008 04:03:08 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081126120308.A27423A694A@core3.amsl.com> Date: Wed, 26 Nov 2008 04:03:08 -0800 (PST) Click here to view as a webpage From mecaton2@almanet.net Wed Nov 26 08:13:36 2008 Return-Path: X-Original-To: ietfarch-msec-archive@core3.amsl.com Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA25D3A688A for ; Wed, 26 Nov 2008 08:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -37.004 X-Spam-Level: X-Spam-Status: No, score=-37.004 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, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, 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 vuETlVe7PK4l for ; Wed, 26 Nov 2008 08:13:36 -0800 (PST) Received: from ppp-58-8-214-32.revip2.asianet.co.th (ppp-58-8-214-32.revip2.asianet.co.th [58.8.214.32]) by core3.amsl.com (Postfix) with SMTP id 9771C3A6774 for ; Wed, 26 Nov 2008 08:13:31 -0800 (PST) To: Subject: Further job slashes From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081126161332.9771C3A6774@core3.amsl.com> Date: Wed, 26 Nov 2008 08:13:31 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From nishiura@air.nittsu.co.jp Thu Nov 27 11:16:24 2008 Return-Path: X-Original-To: ietfarch-msec-archive@core3.amsl.com Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603A03A6A06 for ; Thu, 27 Nov 2008 11:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.606 X-Spam-Level: X-Spam-Status: No, score=-25.606 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, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, 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 Fdu-C-Tw-nkM for ; Thu, 27 Nov 2008 11:16:23 -0800 (PST) Received: from dslb-088-070-232-166.pools.arcor-ip.net (dslb-088-070-232-166.pools.arcor-ip.net [88.70.232.166]) by core3.amsl.com (Postfix) with SMTP id 6E6E23A69E5 for ; Thu, 27 Nov 2008 11:16:20 -0800 (PST) To: Subject: Job cut in our company From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081127191621.6E6E23A69E5@core3.amsl.com> Date: Thu, 27 Nov 2008 11:16:20 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From misc@adax.co.uk Fri Nov 28 09:34:29 2008 Return-Path: X-Original-To: ietfarch-msec-archive@core3.amsl.com Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7573A69EE for ; Fri, 28 Nov 2008 09:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.443 X-Spam-Level: X-Spam-Status: No, score=-21.443 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, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_CUST=0.245, HELO_EQ_SE=0.35, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, 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 LKG1nw8AyHO9 for ; Fri, 28 Nov 2008 09:34:28 -0800 (PST) Received: from 89-253-83-155.customers.ownit.se (89-253-83-155.customers.ownit.se [89.253.83.155]) by core3.amsl.com (Postfix) with SMTP id 4A97D3A676A for ; Fri, 28 Nov 2008 09:34:25 -0800 (PST) To: Subject: Inauguaration committee acts strange From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081128173427.4A97D3A676A@core3.amsl.com> Date: Fri, 28 Nov 2008 09:34:25 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
From moran@amcd.ie Fri Nov 28 20:01:31 2008 Return-Path: X-Original-To: ietfarch-msec-archive@core3.amsl.com Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6363A68B7 for ; Fri, 28 Nov 2008 20:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.388 X-Spam-Level: X-Spam-Status: No, score=-32.388 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_CZ=0.445, HOST_EQ_BROADBND=1.118, HOST_EQ_CZ=0.904, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, 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 8hpe0-xSCaJ7 for ; Fri, 28 Nov 2008 20:01:30 -0800 (PST) Received: from 236.83.broadband4.iol.cz (236.83.broadband4.iol.cz [85.71.83.236]) by core3.amsl.com (Postfix) with SMTP id D274E3A6778 for ; Fri, 28 Nov 2008 20:01:28 -0800 (PST) To: Subject: Private Order 62448 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081129040129.D274E3A6778@core3.amsl.com> Date: Fri, 28 Nov 2008 20:01:28 -0800 (PST) Click here to view as a webpage.


Windows Live Customer Support | Hotmail Support FAQs | Newsletter feedback

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052 As a Windows Live member you have received this e-mail to inform you of updates, changes to the service, or special news and information vital to the service. Our policy is to send e-mail messages only to announce such information, and we'll continue to honor this policy. These communications are required as a part of this service. If you do not wish to receive these letters you may discontinue your participation in the service and close your account.

Microsoft respects your privacy. To learn more, please read our online Privacy Statement

Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
From kama1@agt.net Sun Nov 30 22:07:21 2008 Return-Path: X-Original-To: ietfarch-msec-archive@core3.amsl.com Delivered-To: ietfarch-msec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35823A691C for ; Sun, 30 Nov 2008 22:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.179 X-Spam-Level: X-Spam-Status: No, score=-22.179 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_EXTRA_CLOSE=2.809, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, PLING_QUERY=1.39, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, 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 zzpS4lJvV-HK for ; Sun, 30 Nov 2008 22:07:20 -0800 (PST) Received: from amateurmatch.com (unknown [120.138.115.182]) by core3.amsl.com (Postfix) with SMTP id 79FE93A63CB for ; Sun, 30 Nov 2008 22:07:18 -0800 (PST) To: Subject: they told it can never be enlarged? Lie! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081201060719.79FE93A63CB@core3.amsl.com> Date: Sun, 30 Nov 2008 22:07:18 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052