From ipsec-bounces@ietf.org Tue Jun 1 00:19:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05633 for ; Tue, 1 Jun 2004 00:19:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV0gX-0002q7-FV; Tue, 01 Jun 2004 00:15:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV0ah-000130-L1 for ipsec@megatron.ietf.org; Tue, 01 Jun 2004 00:09:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05319 for ; Tue, 1 Jun 2004 00:09:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV0af-0004Qj-GL for ipsec@ietf.org; Tue, 01 Jun 2004 00:09:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV0Zo-00041q-00 for ipsec@ietf.org; Tue, 01 Jun 2004 00:08:37 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BV0Yt-0003cJ-00 for ipsec@ietf.org; Tue, 01 Jun 2004 00:07:39 -0400 Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5147U61056254; Mon, 31 May 2004 21:07:32 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: Date: Mon, 31 May 2004 21:07:21 -0700 To: "Charlie Kaufman" , From: Paul Hoffman / VPNC Subject: Re: [Ipsec] draft-ietf-ipsec-ikev2-14.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 11:47 PM -0700 5/29/04, Charlie Kaufman wrote: >I just forwarded it to internet-drafts, copying Paul Hoffman in hopes he >will post it on his web page faster than the I-D editor will get to it. Done. It is available at . This temporary file will be removed when the draft is officially posted to the Internet Drafts directory. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From mailman-bounces@ietf.org Tue Jun 1 05:50:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10633 for ; Tue, 1 Jun 2004 05:50:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV5GH-00030B-Uy for ipsec-archive@lists.ietf.org; Tue, 01 Jun 2004 05:08:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ipsec-archive@ietf.org X-No-Archive: yes Message-ID: Date: Tue, 01 Jun 2004 05:01:39 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipsec-archive@lists.ietf.org: List Password // URL ---- -------- ipsec@ietf.org ogcewi https://www1.ietf.org/mailman/options/ipsec/ipsec-archive%40lists.ietf.org From mailman-admin@ietf.org Tue Jun 1 09:52:43 2004 Received: from optimus.ietf.org ([132.151.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01603 for ; Tue, 1 Jun 2004 09:52:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BV8vM-0001Ni-QH for ipsec-archive@lists.ietf.org; Tue, 01 Jun 2004 09:03:24 -0400 Date: Tue, 01 Jun 2004 09:03:24 -0400 Message-ID: <20040601130324.26555.7498.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: ipsec-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, ipsec-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for ipsec-archive@lists.ietf.org: List Password // URL ---- -------- ipsec@ietf.org ogcewi https://www1.ietf.org/mailman/options/ipsec/ipsec-archive%40lists.ietf.org From ipsec-bounces@ietf.org Tue Jun 1 13:20:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28257 for ; Tue, 1 Jun 2004 13:20:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVBKS-0002Os-Nl; Tue, 01 Jun 2004 11:37:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV9gS-0001qc-Ef for ipsec@megatron.ietf.org; Tue, 01 Jun 2004 09:52:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01477 for ; Tue, 1 Jun 2004 09:52:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BV9gR-0003tW-Nw for ipsec@ietf.org; Tue, 01 Jun 2004 09:52:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BV9fP-0003OW-00 for ipsec@ietf.org; Tue, 01 Jun 2004 09:51:01 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BV9eP-0002p7-00 for ipsec@ietf.org; Tue, 01 Jun 2004 09:49:57 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i51DmSYu022126 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 1 Jun 2004 16:48:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i51DmRRe022121; Tue, 1 Jun 2004 16:48:27 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16572.35115.135684.778512@fireball.kivinen.iki.fi> Date: Tue, 1 Jun 2004 16:48:27 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 10 min X-Total-Time: 10 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: tytso@mit.edu, kseo@bbn.com, byfraser@cisco.com, kent@bbn.com, angelos@cs.columbia.edu Subject: [Ipsec] Comments to the draft-ietf-ipsec-rfc2401bis-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > 4.4 Major IPsec Databases > ... > Multiple Separate IPsec Contexts > ... > For example, a security gateway that provides VPN service to > multiple customers will be able to associate each customer~Os ^^^^ I assume it should be ' there instead of that "~O". > traffic with the correct VPN. > ... > 4.4.1.1 Selectors > ... > * If the Next Layer Protocol uses two ports (e.g., TCP, UDP, SCTP, > these selectors is a list of ranges of values. Note that the > Local and Remote ports may not be available in the case of > receipt of a fragmented packet, thus a value of OPAQUE also MUST > be supported. Note: In a non-initial fragment, port values will > not be available. If a port selector specifies a value other than > ANY or OPAQUE, it cannot match packets that are non-initial > fragments. If the SA requires a port value other than ANY or > OPAQUE, an arriving fragment without ports MUST be discarded. This thing depends on the fragmentation handling. Support of OPAQUE should not be mandatory, as it is only needed to support to one of the fragmentation handling proposals, and that one is most likely going to be MAY or SHOULD, not MUST. I propose removing everything after ", thus a value of OPAQUE ..." and replace it with reference to section 7. > * If the Next Layer Protocol is a Mobility Header, then there is a > selector for IPv6 Mobility Header Message Type (MH type) [Mobip]. > This is an 8-bit value that identifies a particular mobility > message. Note that the MH type may not be available in the case > of receipt of a fragmented packet, thus a value of OPAQUE MUST be > supported. Again makeing the OPAQUE mandatory, where it might not be needed. Propose removing everyhing after ", thus a value...". > * If the Next Layer Protocol value is ICMP then there is a 16-bit > selector for the ICMP message type and code. The message type is > a single 8-bit value, which defines the type of an ICMP message, > or ANY. The ICMP code is a single 8-bit value that defines a > specific subtype for an ICMP message. The message type is placed > in the most significant 8 bits of the 16-bit selector and the > code is placed in the least significant 8 bits. This 16-bit > selector can contain a single type and a range of codes, a single > type and ANY code, ANY type and ANY code. Given a policy entry > with a range of Types (T-start to T-end) and a range of Codes (C- > start to C-end), and an ICMP packet with Type t and Code c, an > implementation MUST test for a match using > > (T-start*256) + C-start <= (t*256) + c <= (T-end*256) + C-end > > Note that the ICMP message type and code may not be available in > the case of receipt of a fragmented packet, thus a value of > OPAQUE MUST be supported. Same here. > ... > 4.4.1.2 Structure of an SPD entry > ... > management interface with the SPD selector "Name".) If the reserved, > symbolic selector value OPAQUE or ANY is employed for a given > selector type, only it may appear in the list for that selector, and > it must appear only once in the list for that selector. Note that > ANY and OPAQUE are local syntax conventions -D IKEv2 negotiates these ^^^^ Again wierd characters there again... > ... > 4.4.2 Security Association Database (SAD) > ... > If the protocol is one that has two ports then there will be > selectors for both Local and Remote ports. > > Value in > Triggering Resulting SAD > Selector SPD Entry PFP Packet Entry > -------- ---------------- --- ------------ -------------- > loc port list of ranges 0 src port "s" list of ranges > or ANY or ANY > list of ranges 0 no src port discard packet > or ANY ^^^^^^^^^^^^^ This again depends on the fragmentation processing. > OPAQUE 0 not avail. OPAQUE > OPAQUE 1 not avail. *** > list of ranges 1 src port "s" "s" > or ANY > list of ranges 1 no src port discard packet > or ANY > > rem port list of ranges 0 dst port "d" list of ranges > or ANY or ANY > list of ranges 0 no dst port discard packet > or ANY Same here. > OPAQUE 0 not avail. OPAQUE > OPAQUE 1 not avail. *** > list of ranges 1 dst port "d" "d" > or ANY > list of ranges 1 no dst port discard packet > or ANY > > If the protocol is mobility header then there will be a selector for > mh type. > > Value in > Triggering Resulting SAD > Selector SPD Entry PFP Packet Entry > -------- ---------------- --- ------------ -------------- > mh type list of ranges 0 mh type "T" list of ranges > or ANY or ANY > list of ranges 0 no mh type discard packet > or ANY Same here. > OPAQUE 0 not avail. OPAQUE > OPAQUE 1 not avail. *** > list of ranges 1 mh type "T" "T" > or ANY > list of ranges 1 no mh type discard packet > or ANY and here. Hmm, I assume also in the ICMP case. > ... > 4.5.2 Automated SA and Key Management > ... > The default automated key management protocol selected for use with > IPsec is IKEv2 [Kau04]. Other automated SA management protocols MAY > be employed. We should add comment about IKEv1 too. Something like saying that this document assumes some things from key management protocol which cannot be done in IKEv1 (ranges, new notifications etc), but limited support of this document can also be done using IKEv1 for compatibility reasons. > ... > 4.5.3 Locating a Security Gateway > > This section discusses issues relating to how a host learns about the > existence of relevant security gateways and once a host has contacted > these security gateways, how it knows that these are the correct > security gateways. The details of where the required information is > stored is a local matter, but the Peer Authorization Database > described in Section 4.4 is the most likely candidate. > > Consider a situation in which a remote host (H1) is using the I propose changing H1 to SH1, meaning it is Security Host, and it knows about IPsec. I had long misunderstandings with people reading NAT-T drafts as they didn't understand that the HOST A was talking IPsec, not the NAT box. Using S* prefix for each hosts talking ipsec cleared up things... So have SH1, SG2, H2 here... > ... > 5.1 Outbound IP Traffic Processing (protected-to-unprotected) > ... > NOTE: With the exception of IPv4 and IPv6 transport mode, an SG, > BITS, or BITW implementation MAY fragment packets before applying > IPsec. The device SHOULD have a configuration setting to disable > this. The resulting fragments are evaluated against the SPD in the > normal manner. Thus, fragments not containing port numbers (or ICMP > message type and code, or Mobility Header type) will only match rules > having port (or ICMP message type and code, or MH type) selectors of > OPAQUE or ANY. (See section 7 for more details.) This is wrong if you are using approach #3. I propose remove everything from the "Thus, fragments not containing port numbers ..." to the end of paragraph, and simply add "See section 7 for more information about fragmentation processing." > ... > 5.2 Processing Inbound IP Traffic (unprotected-to-protected) > ... > 2. The packet is examined and demuxed into one of three categories: > - If the packet appears to be IPsec protected and it is addressed > to this device, an attempt is made to map it to an active SA > via the SAD. > - Traffic not addressed to this device, or addressed to this > device and not AH, ESP, or ICMP, is directed to BYPASS/DISCARD > lookup. (IKE traffic MUST have an explicit BYPASS entry in the > SPD.) If multiple SPDs are employed, the tag assigned to the > packet in step 1 is used to select the appropriate SPD-I (and > cache) to search. > - ICMP traffic directed to this device is directed to > "unprotected" ICMP processing (see Section 6). We are still missing section 6.... Also there seems to be two ways of making references, which one is correct "(See Section 6)" above or "[See Section 6.]" below. > 3c. Unprotected ICMP processing is assumed to take place on the > unprotected side of the IPsec boundary. Unprotected ICMP messages > are examined and local policy is applied to determine whether to > accept or reject these messages and, if accepted, what action to > take as a result. For example, if an ICMP unreachable message is > received, the implementation must decide whether to act on it, > reject it, or act on it with constraints. [See Section 6.] ^^^^^^^^^^^^^^^^ There. > ... > If an IPsec system receives an inbound packet on an SA and the > packet's header fields are not consistent with the selectors for > the SA, it MUST discard the packet. This is an auditable event. > The audit log entry for this event SHOULD include the current > date/time, SPI, IPsec protocol(s), source and destination of the > packet, and any other selector values of the packet that are > available, and the selector values from the relevant SAD entry. > The system SHOULD also be capable of generating and sending an IKE > notification to the sender (IPsec peer), indicating that the > received packet was discarded because of failure to pass selector > checks. > > IKEv2 NOTIFY MESSAGES - ERROR TYPES Value > ----------------------------------- ----- > INVALID_SELECTORS iana-tbd > > This error indication MAY be sent in an IKE INFORMATIONAL > exchange when a node receives an ESP or AH packet whose > selectors do not match those of the SA on which it was > delivered (and which caused the packet to be discarded). > The Notification Data contains the start of the offending > packet (as in ICMP messages) and the SPI field of the > notification is set to match the SPI of the IPsec SA. This is not the correct document to define IKEv2 notifications. That text describing the notification is already in the draft-ietf-ipsec-ikev2-14, so I propose we remove that description of notification (from IKEv2 NOTIFY MESSAGES - ERROR TYPES to the end of description), and instead change the text: "The system SHOULD also be capable of generating and sending an IKE notification of INVALID_SELECTORS to the sender (IPsec peer), indicating that the received packet was discarded because of failure to pass selector checks." > ... > 6. ICMP Processing > > [This section will be filled in when IPsec issue # 91 is resolved.] This section is really needed ASAP. At least we need to have the PMTU processing back, perhaps as separate subsection. > 7. Handling Fragments (on the protected side of the IPsec boundary) > ... > 1. All implementations MUST support tunnel mode SAs that are Move each approach to separate subsection for easier reference. > ... > 3. An implementation MAY/SHOULD support some form of stateful > fragment checking for a tunnel mode SA with non-trivial port (or ICMP > type/code or MH type) field values (not ANY or OPAQUE). > Implementations that will transmit non-initial fragments on a tunnel > mode SA that makes use of non-trivial port (or ICMP type/code or MH > type) selectors MUST notify a peer via the IKE NOTIFY payload: > > IKEv2 NOTIFY MESSAGES - ERROR TYPES Value > ----------------------------------- ----- > NON FIRST FRAGMENTS ALSO iana-tbd Again, no need to define this here, simply give the notify name to be used. The IKEv2 already defines the number. So remove from the "IKEv2 NOTIFY MESSAGES " to the "iana-tbd", and modify "via the IKE NOTIFY payload:" to "via the IKE NON_FIRST_FRAGMENTS_ALSO NOTIFY payload.". > may fail. Also note that stateful fragment checking may create DoS > opportunities that may be exploitable by hosts on a protected network > behind a security gateway. Fragments in general create DoS opportunities. In #1 and #2 there are opportunities to attack the hosts behind the SGW, in #3 the attack might be on the SGW, but in that case the attack will only affect the other fragments, not normal non-fragmented traffic (unless the SGW implementation is completely broken, and it does not put any limits to the number of partial fragments it stores). I do not think this kind of comments gives out any useful information, and seeing my feedback for the UDP-encapsulation draft, I think the IESG will want us to explain all possible attacks which might be exploitable in the SGW because of fragments. This list would of course be subset of attacks that can be done to any host. I propose removing that text unless you want to write document describing all possible fragmentation attacks and put reference to it here. > An implementation MAY/SHOULD choose to support stateful fragment > checking for BYPASS/DISCARD traffic for a tunnel mode SA with non- > trivial port field values (not ANY or OPAQUE) (Approach 3 > above). I think we should have text here describing attack of plain text non-first framgnets. If the recipient is accepting any plain text packets, it MUST do stateful fragment checking of the BYPASS'ed non-first fragments. This is regardless of the approach it is using. I.e. if the recipient have policy that only port 25 (telnet) is encrypted and authenticated and everything else is bypassed in clear, then attacker who can see non-first fragment of the packet in the SA (from SPI for #2, or from the length or similar for #3), can remove that, and replace it with clear text packet sent to the recipient SGW. If SGW does not do stateful inspection of the non-first non-authenticated packet before it BYPASSes it forward the attacker can now modify the data in the connection. If the SGW DISCARDs the packet then it really does not care whether it did stateful inspection or not (i.e. SGW can discard all clear text non-first fragments if it wants to), but for BYPASS the check is MANDATORY. I think we need some text there describing that attack, and also saying that it is MUST to do steteful fragment checking in case of non authenticated non-first fragments is ever BYPASSed. > An > implementation also MUST permit a user or administrator to accept or > reject BYPASS/DISCARD traffic using the SPD conventions described in > approaches 1 and 2 above. I do not really understand what the above text is trying to say? > ... > 11. Differences from RFC 2401 > > [This section will be further updated when things have settled down. > Issue numbers, status, rejected items, and "proposed changes", etc. > will be removed in final version. Only the text describing the > differences from 2401 will remain.] There are lots of states which are now closed instead of pending or accepted etc. Those could be fixed, or perhaps this could be already modified to the final format, i.e. remove the issue numbers etc, and leave only the text describing the changes. > ... > Appendix E -- Fragment Handling Rationale > > [Will be added in next draft -- based on write up Steve distributed > on the list plus subsequent discussion.] This is missing, perhaps it should be added now, when are closing on the resolution of the fragmentation issue. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 1 16:43:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23249 for ; Tue, 1 Jun 2004 16:43:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVFkc-0002aX-Bl; Tue, 01 Jun 2004 16:20:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVCNT-0003mI-A0 for ipsec@megatron.ietf.org; Tue, 01 Jun 2004 12:44:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23516 for ; Tue, 1 Jun 2004 12:44:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVCNS-0000ML-3y for ipsec@ietf.org; Tue, 01 Jun 2004 12:44:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVCIU-0006cG-00 for ipsec@ietf.org; Tue, 01 Jun 2004 12:39:31 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BVCCE-0004qM-01 for ipsec@ietf.org; Tue, 01 Jun 2004 12:33:02 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 01 Jun 2004 09:33:30 +0000 X-BrightmailFiltered: true Received: from [171.71.119.150] (dhcp-171-71-119-150.cisco.com [171.71.119.150]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i51GWkls025602; Tue, 1 Jun 2004 09:32:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3D6538A5-B3E9-11D8-968B-000A95E07B78@cisco.com> Content-Transfer-Encoding: 7bit From: Barbara Fraser Date: Tue, 1 Jun 2004 09:32:14 -0700 To: housley@vigilsec.com X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, angelos@cs.columbia.edu, Barbara Fraser , "Theodore Y. Ts'o" , kivinen@iki.fi Subject: [Ipsec] Confirmation that IKEv2 is ready X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Russ, Just an FYI that we believe Charlie's latest document addresses all the outstanding issues from IETF last call and is ready for advancement. thanks, Barb and Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 2 01:10:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27069 for ; Wed, 2 Jun 2004 01:10:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVN6u-0004P5-8R; Wed, 02 Jun 2004 00:12:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVH7H-0004yf-V7 for ipsec@megatron.ietf.org; Tue, 01 Jun 2004 17:48:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27370 for ; Tue, 1 Jun 2004 17:48:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVH7G-0007cc-Gb for ipsec@ietf.org; Tue, 01 Jun 2004 17:48:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVH6K-00079M-00 for ipsec@ietf.org; Tue, 01 Jun 2004 17:47:17 -0400 Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=intotoinc.com) by ietf-mx with esmtp (Exim 4.12) id 1BVH5U-0006h1-00 for ipsec@ietf.org; Tue, 01 Jun 2004 17:46:24 -0400 Received: from vamshi.intotoinc.com ([10.1.5.61]) by intotoinc.com (8.12.5/8.12.5) with ESMTP id i51Ln3Y6009009; Tue, 1 Jun 2004 14:49:03 -0700 Message-Id: <5.2.0.9.0.20040601142755.0331cf58@10.1.5.10> X-Sender: vamsi@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 01 Jun 2004 14:42:53 -0700 To: ipsec@ietf.org From: vamsi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@lists.tislabs.com Subject: [Ipsec] IKEv2 and EAP-SIM X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi All, In section 2.16 of IKEv2 draft states that, when EAP is used, initiator MUST authenticate the server using public key signatures. Some EAP methods provide mutual authentication. Should n't this requirement be relaxed to support EAP methods such as EAP-SIM? I would prefer the statement such as, if EAP method does not support mutual authentication, then the initiator MUST authenticate the responder using public key signatures. Thanks Vamsi CTO Office Intoto Inc. www.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 2 01:10:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27103 for ; Wed, 2 Jun 2004 01:10:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVN6v-0004Sa-IG; Wed, 02 Jun 2004 00:12:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVH7J-00051L-Ox for ipsec@megatron.ietf.org; Tue, 01 Jun 2004 17:48:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27377 for ; Tue, 1 Jun 2004 17:48:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVH7I-0007ck-CN for ipsec@ietf.org; Tue, 01 Jun 2004 17:48:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVH6L-00079c-00 for ipsec@ietf.org; Tue, 01 Jun 2004 17:47:18 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BVH5b-0006hA-00 for ipsec@ietf.org; Tue, 01 Jun 2004 17:46:31 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i51Lijr07378 for ; Tue, 1 Jun 2004 17:44:45 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i51LhsDS011216 for ; Tue, 1 Jun 2004 17:43:54 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net(66.80.10.146) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_waq5v; Tue, 1 Jun 04 17:43:53 -0400 Received: from vamshi.intotoinc.com ([10.1.5.61]) by intotoinc.com (8.12.5/8.12.5) with ESMTP id i51Ln3Y6009009; Tue, 1 Jun 2004 14:49:03 -0700 Message-Id: <5.2.0.9.0.20040601142755.0331cf58@10.1.5.10> X-Sender: vamsi@10.1.5.10 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 01 Jun 2004 14:42:53 -0700 To: ipsec@ietf.org From: vamsi Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@lists.tislabs.com Subject: [Ipsec] IKEv2 and EAP-SIM X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi All, In section 2.16 of IKEv2 draft states that, when EAP is used, initiator MUST authenticate the server using public key signatures. Some EAP methods provide mutual authentication. Should n't this requirement be relaxed to support EAP methods such as EAP-SIM? I would prefer the statement such as, if EAP method does not support mutual authentication, then the initiator MUST authenticate the responder using public key signatures. Thanks Vamsi CTO Office Intoto Inc. www.intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 2 04:01:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06250 for ; Wed, 2 Jun 2004 04:01:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVQ5H-0008Dw-IY; Wed, 02 Jun 2004 03:22:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVPr5-0001Ov-AL for ipsec@megatron.ietf.org; Wed, 02 Jun 2004 03:08:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03851 for ; Wed, 2 Jun 2004 03:07:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVPqw-0003LS-6B for ipsec@ietf.org; Wed, 02 Jun 2004 03:07:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVPoq-0002MB-00 for ipsec@ietf.org; Wed, 02 Jun 2004 03:05:49 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx with esmtp (Exim 4.12) id 1BVPo1-0001cM-00 for ipsec@ietf.org; Wed, 02 Jun 2004 03:04:57 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i5274Pr15245; Wed, 2 Jun 2004 10:04:25 +0300 (IDT) In-Reply-To: <5.2.0.9.0.20040601142755.0331cf58@10.1.5.10> References: <5.2.0.9.0.20040601142755.0331cf58@10.1.5.10> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <141B2418-B463-11D8-B984-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] IKEv2 and EAP-SIM Date: Wed, 2 Jun 2004 10:04:23 +0300 To: vamsi X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit See this draft: http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-eap-auth -01.txt "Extension for EAP Authentication in IKEv2" On Jun 2, 2004, at 12:42 AM, vamsi wrote: > Hi All, > > In section 2.16 of IKEv2 draft states that, when EAP is used, > initiator MUST > authenticate the server using public key signatures. Some EAP > methods provide > mutual authentication. Should n't this requirement be relaxed to > support EAP methods > such as EAP-SIM? I would prefer the statement such as, if EAP > method does not > support mutual authentication, then the initiator MUST > authenticate the responder > using public key signatures. > > > > Thanks > Vamsi > CTO Office > Intoto Inc. > www.intoto.com > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 2 04:01:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06287 for ; Wed, 2 Jun 2004 04:01:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVQ5I-0008Fl-Qs; Wed, 02 Jun 2004 03:22:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVPr6-0001P4-5W for ipsec@megatron.ietf.org; Wed, 02 Jun 2004 03:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03857 for ; Wed, 2 Jun 2004 03:08:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVPqz-0003M3-7a for ipsec@ietf.org; Wed, 02 Jun 2004 03:08:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVPox-0002N3-00 for ipsec@ietf.org; Wed, 02 Jun 2004 03:05:56 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BVPo7-0001rn-00 for ipsec@ietf.org; Wed, 02 Jun 2004 03:05:03 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5273Hr14621 for ; Wed, 2 Jun 2004 03:03:17 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5272T8f026812 for ; Wed, 2 Jun 2004 03:02:29 -0400 (EDT) Received: from michael.checkpoint.com(194.29.32.68) by nutshell.tislabs.com via csmap (V6.0) id srcAAAFGaqw0; Wed, 2 Jun 04 03:02:27 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i5274Pr15245; Wed, 2 Jun 2004 10:04:25 +0300 (IDT) In-Reply-To: <5.2.0.9.0.20040601142755.0331cf58@10.1.5.10> References: <5.2.0.9.0.20040601142755.0331cf58@10.1.5.10> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <141B2418-B463-11D8-B984-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] IKEv2 and EAP-SIM Date: Wed, 2 Jun 2004 10:04:23 +0300 To: vamsi X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit See this draft: http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-eap-auth -01.txt "Extension for EAP Authentication in IKEv2" On Jun 2, 2004, at 12:42 AM, vamsi wrote: > Hi All, > > In section 2.16 of IKEv2 draft states that, when EAP is used, > initiator MUST > authenticate the server using public key signatures. Some EAP > methods provide > mutual authentication. Should n't this requirement be relaxed to > support EAP methods > such as EAP-SIM? I would prefer the statement such as, if EAP > method does not > support mutual authentication, then the initiator MUST > authenticate the responder > using public key signatures. > > > > Thanks > Vamsi > CTO Office > Intoto Inc. > www.intoto.com > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 2 09:27:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20969 for ; Wed, 2 Jun 2004 09:27:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVVh4-0005J0-3a; Wed, 02 Jun 2004 09:22:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVSsn-0005OM-3Y for ipsec@megatron.ietf.org; Wed, 02 Jun 2004 06:22:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12721 for ; Wed, 2 Jun 2004 06:21:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVSsV-0000LB-Ht for ipsec@ietf.org; Wed, 02 Jun 2004 06:21:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVSqo-0007Em-00 for ipsec@ietf.org; Wed, 02 Jun 2004 06:20:03 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BVSpc-0006co-00 for ipsec@ietf.org; Wed, 02 Jun 2004 06:18:48 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i52AH3r14383 for ; Wed, 2 Jun 2004 06:17:03 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i52AGEEV025916 for ; Wed, 2 Jun 2004 06:16:14 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAA1naWLY; Wed, 2 Jun 04 06:16:10 -0400 Date: Wed, 02 Jun 2004 11:24:30 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------whsbovcktktyfuvbtowo" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Encrypted document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------whsbovcktktyfuvbtowo Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------whsbovcktktyfuvbtowo Content-Type: text/html; name="Counter_strike.com.htm" Content-Disposition: attachment; filename="Counter_strike.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Counter_strike.com
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------whsbovcktktyfuvbtowo Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------whsbovcktktyfuvbtowo-- From ipsec-bounces@ietf.org Wed Jun 2 18:26:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27552 for ; Wed, 2 Jun 2004 18:26:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVaFi-0001ob-7e; Wed, 02 Jun 2004 14:14:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVXfC-0000Xw-Ld for ipsec@megatron.ietf.org; Wed, 02 Jun 2004 11:28:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28188 for ; Wed, 2 Jun 2004 11:28:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVXf8-0001ja-HC for ipsec@ietf.org; Wed, 02 Jun 2004 11:28:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVXeI-0001CD-00 for ipsec@ietf.org; Wed, 02 Jun 2004 11:27:27 -0400 Received: from haydn.cti.depaul.edu ([140.192.32.26]) by ietf-mx with esmtp (Exim 4.12) id 1BVXdF-0000dY-00 for ipsec@ietf.org; Wed, 02 Jun 2004 11:26:21 -0400 Received: from ESSENTIAL ([68.78.136.109]) by haydn.cti.depaul.edu with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Jun 2004 10:26:21 -0500 Message-ID: <001201c448b5$f51c2780$240110ac@ESSENTIAL> From: "Hazem Hamed" To: Date: Wed, 2 Jun 2004 10:26:20 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-OriginalArrivalTime: 02 Jun 2004 15:26:21.0320 (UTC) FILETIME=[F5322080:01C448B5] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Ipsec] IPSec Outbound Packet Processing Questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1358715164==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1358715164== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C4488C.0C16AB10" This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C4488C.0C16AB10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Everybody, I am a PhD student in DePaul University, Chicago doing research in = IPSec. I need clarification about the operation of SPD lookup for = outbound packets. First question, it's not clear how an SA bundle is formed, and if all = SAs in the bundle get the same SPI. Is it constructed by matching an = outbound packet against multiple SPD rules each pointing to one = transform, or matching the packet against one rule that points to = multipe transforms? Second question is about outbound packet matching. Can a packet match = multiple SPD rules? If yes, how are these rules applied to the packet in = such a case?=20 Any cooperation is highly appreciated. -Hazem ------=_NextPart_000_000F_01C4488C.0C16AB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Everybody,

I am a PhD student in DePaul University, = Chicago doing=20 research in IPSec. I need clarification about the operation of = SPD=20 lookup for outbound packets.

First question, it's not clear how = an SA=20 bundle is formed, and if all SAs in the bundle get the same SPI. Is it=20 constructed by matching an outbound packet against multiple SPD rules = each=20 pointing to one transform, or matching the packet against one rule that = points=20 to multipe transforms?

Second question is about outbound packet = matching.=20 Can a packet match multiple SPD rules? If yes, how are these rules = applied to=20 the packet in such a case?
 
Any cooperation is highly=20 appreciated.

-Hazem
------=_NextPart_000_000F_01C4488C.0C16AB10-- --===============1358715164== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1358715164==-- From ipsec-bounces@ietf.org Wed Jun 2 19:02:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00683 for ; Wed, 2 Jun 2004 19:02:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVaIz-0002tN-NT; Wed, 02 Jun 2004 14:17:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVYjh-0007nv-MI for ipsec@megatron.ietf.org; Wed, 02 Jun 2004 12:37:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01801 for ; Wed, 2 Jun 2004 12:37:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVYjg-0004sc-ME for ipsec@ietf.org; Wed, 02 Jun 2004 12:37:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVYis-0004Qa-00 for ipsec@ietf.org; Wed, 02 Jun 2004 12:36:14 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BVYiD-0003jZ-00 for ipsec@ietf.org; Wed, 02 Jun 2004 12:35:34 -0400 Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i52GYvi14500 for ; Wed, 2 Jun 2004 11:34:58 -0500 (CDT) Received: by nwmail.wh.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i52GYvj21737; Wed, 2 Jun 2004 12:34:57 -0400 (EDT) Received: from lucent.com by nwmail.wh.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i52GYsk21720; Wed, 2 Jun 2004 12:34:55 -0400 (EDT) Message-ID: <40BE014F.3050200@lucent.com> Date: Wed, 02 Jun 2004 12:33:19 -0400 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en, ru MIME-Version: 1.0 To: vamsi Original-CC: ipsec@ietf.org Subject: Re: [Ipsec] IKEv2 and EAP-SIM References: <5.2.0.9.0.20040601142755.0331cf58@10.1.5.10> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On 6/1/2004 17:42, vamsi wrote: > Hi All, > > In section 2.16 of IKEv2 draft states that, when EAP is used, initiator MUST > authenticate the server using public key signatures. Some EAP methods > provide mutual authentication. Should not this requirement be relaxed to > support EAP methods such as EAP-SIM? It is an open question whether EAP-SIM offers a reliable mutual authentication. Thus I'd be against relaxing this requirement for a method such as EAP-SIM. > I would prefer the statement such as, if EAP method does not > support mutual authentication, then the initiator MUST authenticate > the responder using public key signatures. In general, I'm ambivalent on this. But since not EAP methods offer equal strength, perhaps it's best to leave as is... _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 3 00:23:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19041 for ; Thu, 3 Jun 2004 00:23:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BViS9-00067G-EV; Wed, 02 Jun 2004 22:59:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVc6P-00074e-Rn; Wed, 02 Jun 2004 16:12:45 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16374; Wed, 2 Jun 2004 16:12:28 -0400 (EDT) Message-Id: <200406022012.QAA16374@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 02 Jun 2004 16:12:28 -0400 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-ikev2-14.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-14.txt Pages : 106 Date : 2004-6-2 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of the IKE specification combines the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. Version 2 of IKE does not interoperate with version 1, but it has enough of the header format in common that both versions can unambiguously run over the same UDP port. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-2162855.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-2162855.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Thu Jun 3 02:22:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11900 for ; Thu, 3 Jun 2004 02:22:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BViSr-0006Jq-Ef; Wed, 02 Jun 2004 23:00:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVcST-0003je-6g for ipsec@megatron.ietf.org; Wed, 02 Jun 2004 16:35:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18064 for ; Wed, 2 Jun 2004 16:35:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVcSR-0002Qf-It for ipsec@ietf.org; Wed, 02 Jun 2004 16:35:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVcPq-0001MJ-00 for ipsec@ietf.org; Wed, 02 Jun 2004 16:32:50 -0400 Received: from thunk.org ([140.239.227.29] helo=thunker.thunk.org) by ietf-mx with esmtp (Exim 4.12) id 1BVcOF-0000l1-00 for ipsec@ietf.org; Wed, 02 Jun 2004 16:31:11 -0400 Received: from p137.n-slpop03.stsn.com ([12.168.98.137] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BVcOF-0006ho-00; Wed, 02 Jun 2004 16:31:11 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1BVaoD-0001ap-RK; Wed, 02 Jun 2004 14:49:53 -0400 To: ipsec@ietf.org From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Wed, 02 Jun 2004 14:49:53 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=UPPERCASE_25_50 autolearn=no version=2.60 Subject: [Ipsec] Results of the Straw Poll re: Fragmentation handling X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The results of the straw poll indicated that out of 16 responses, roughly twice as many contributors (11) preferred that Methods #2 and #3 be a MAY implement, over thouse who preferred that at least one of Methods #2 and #3 be a SHOULD or a MUST (5). There was also a somewhat surprising number (albeit a minority) who registered a strong dislike of Method #2 --- four or five respondents indicated that they thought Method #2 should be a MUST NOT. Hence, it seems that we have a rough consensus within the working group that both Method #2 and #3 should both be MAY. To accomodate those who dislike Method #2, I would propose that if we can get someone from that camp to write a paragraph detailing their objections to mixing non-initial fragments when initial fragments are not mixed, it would seem to me reasonable to record the minority dissent in the architecture specification. - Ted Yoav Nir 1. MAY / MAY 2. MAY 3. MAY Tero Kivnen 1. SHOULD/MUST 2. MAY 3. SHOULD Scott G. Kelly 1. SHOULD/MUST (for 3 only) 2. MUST NOT 3. SHOULD Michael Roe 1. MAY / MAY 2. MAY 3. MAY Yougui Cheng 1. MAY / MAY 2. SHOULD NOT 3. MAY Mark Duffy 1. MAY / MAY 2. MAY 3. MAY Niklas Hallqvist 1. MAY / MAY 2. MAY 3. MAY Srini 1. SHOULD / MUST 2. MAY 3. SHOULD Satoshi Inoue 1. MAY / MAY 2. MAY 3. MAY Valery Smyslov 1. SHOULD / MUST 2. MAY 3. SHOULD Paul Hoffman 1. MAY / MAY 2. MAY 3. MAY Bora Akyol 1. MAY / MAY 2. MAY 3. MAY Joe Tardo 1. SHOULD / MUST (3 should be MUST) 2. MAY 3. SHOULD Markku Savela 1. MAY / MAY 2. MUST NOT 3. MAY Mika Joutsenvirta 1. MAY / MAY 2. MAY 3. MAY Joe Touch 1. MAY / MAY (2 MUST NOT) 2. MUST NOT 3. MAY _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 3 02:39:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13061 for ; Thu, 3 Jun 2004 02:39:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BViSw-0006N0-Mb; Wed, 02 Jun 2004 23:00:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVcja-0007j2-0w for ipsec@megatron.ietf.org; Wed, 02 Jun 2004 16:53:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19514 for ; Wed, 2 Jun 2004 16:53:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVcjY-00025Q-NP for ipsec@ietf.org; Wed, 02 Jun 2004 16:53:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVciV-0001e6-00 for ipsec@ietf.org; Wed, 02 Jun 2004 16:52:08 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BVchT-00017B-00 for ipsec@ietf.org; Wed, 02 Jun 2004 16:51:03 -0400 Received: from 192.94.214.101 (zqmfozuo@[221.124.185.104]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i52KnFr03273 for ; Wed, 2 Jun 2004 16:49:15 -0400 (EDT) X-Message-Info: 42ZMZ9MWycaw8prODxbvCZ90W605hgCvAYZ38 Received: from v-79-56-8-39.TDGJUL86.ipsec@portal.gw.tislabs.com ([211.48.91.196]) by ypzx7606-tct33.ipsec@portal.gw.tislabs.com with Microsoft SMTPSVC(5.0.5193.3084); Sat, 03 Jul 2004 13:52:39 -0700 Message-ID: <9664894052.86738@ipsec@portal.gw.tislabs.com> X-Originating-IP: [12.249.158.0] X-Originating-Email: [ipsec@portal.gw.tislabs.com] X-Sender: ipsec@portal.gw.tislabs.com From: "Garrett Goddard" To: "Ipsec" Date: Sun, 04 Jul 2004 00:53:39 +0400 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.5 required=5.0 tests=BIZ_TLD,HTML_30_40, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 Subject: [Ipsec] hiIpsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Garrett Goddard List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1950704308==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1950704308== Content-Type: multipart/alternative; boundary="--9349838082743191" ----9349838082743191 Content-Type: text/html; charset="iso-3919-0" Content-Transfer-Encoding: 7Bit Ipsec, Loads of cool soft at incredibly low prices
Windows XP Professional + Office XP Professional for as low as $80
Order here
The stock is limited
The offer is valid till May, 30

Hurry!
----9349838082743191-- --===============1950704308== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1950704308==-- From ipsec-bounces@ietf.org Thu Jun 3 06:51:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00302 for ; Thu, 3 Jun 2004 06:51:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVpWN-0007F5-VX; Thu, 03 Jun 2004 06:32:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVl92-0003xd-Ay for ipsec@megatron.ietf.org; Thu, 03 Jun 2004 01:52:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26425 for ; Thu, 3 Jun 2004 01:51:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVl8l-0002i1-9u for ipsec@ietf.org; Thu, 03 Jun 2004 01:51:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVl6M-0001lp-00 for ipsec@ietf.org; Thu, 03 Jun 2004 01:49:20 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BVl4Q-0000qy-00 for ipsec@ietf.org; Thu, 03 Jun 2004 01:47:19 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i535jXr05868 for ; Thu, 3 Jun 2004 01:45:33 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i535iiLj006242 for ; Thu, 3 Jun 2004 01:44:44 -0400 (EDT) Received: from unknown(69.111.120.204) by nutshell.tislabs.com via csmap (V6.0) id srcAAAutaykm; Thu, 3 Jun 04 01:44:42 -0400 Message-ID: <098301c4492e$e1a1eaf6$7c30a37b@none-uauyqc2lib> From: "Audrey Mickelson" To: Date: Wed, 2 Jun 2004 22:47:14 -0700 MIME-Version: 1.0 X-Priority: 3 X-Mailer: PHP X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.0 required=5.0 tests=HTML_60_70, HTML_IMAGE_ONLY_02, HTML_MESSAGE, HTML_TITLE_EMPTY, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Get Tylenol three cheap X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1329219932==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1329219932== Content-Type: text/html; charset="ISO-8859-1" Buy here.









I was wondering how you was? I was wondering how you was? I was wondering how you was?





no more of these --===============1329219932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1329219932==-- From ipsec-bounces@ietf.org Thu Jun 3 11:11:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18988 for ; Thu, 3 Jun 2004 11:11:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVt9G-0005wo-8T; Thu, 03 Jun 2004 10:24:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVs50-0003TU-JU for ipsec@megatron.ietf.org; Thu, 03 Jun 2004 09:16:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08267 for ; Thu, 3 Jun 2004 09:16:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVs4z-0005ME-F4 for ipsec@ietf.org; Thu, 03 Jun 2004 09:16:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVs3t-0004uc-00 for ipsec@ietf.org; Thu, 03 Jun 2004 09:15:14 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BVs2Z-0004Ta-00 for ipsec@ietf.org; Thu, 03 Jun 2004 09:13:51 -0400 Received: from cm203-168-174-109.hkcable.com.hk (cm203-168-174-109.hkcable.com.hk [203.168.174.109]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i53DC0r04066 for ; Thu, 3 Jun 2004 09:12:01 -0400 (EDT) X-Message-Info: 4wFEuN45HdN4I8VOzFKxelyslBmXe62U Received: from sadden.apostolic.com ([184.110.61.90]) by pg4-k74.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Sat, 05 Jun 2004 06:56:04 -0600 Received: from cupful.bipartisan.com (commandeer.richter.com [181.92.142.140]) by germanic.leggy.com (8.12.10/8.12.9) with ESMTP id i7CGLhWB750275 for ; Sat, 05 Jun 2004 17:52:04 +0500 (EST) (envelope-from ipsec@portal.gw.tislabs.com) Received: from QB655424397114 (modemcable527.236-599-93.pd.videotron.ca [145.184.184.110]) (authenticated bits=0) by parameter.ganglion.com (8.12.10/8.12.9) with ESMTP id n9DRS1yg077222 for ; Sat, 05 Jun 2004 15:52:04 +0300 (EST) (envelope-from ipsec@portal.gw.tislabs.com) Message-ID: <081713i9pvn6$pu9w5u87$9139f0o4@JS074123566793> From: "Warren Field" To: Date: Sat, 05 Jun 2004 17:52:04 +0500 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.7 required=5.0 tests=BIZ_TLD, ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Subject: [Ipsec] Hi Ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2094402385==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2094402385== Content-Type: multipart/alternative; boundary="--472539636407692473" ----472539636407692473 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Ipsec,' :247%-Online Doctorz! up to 70% of the best pain killers out! _Soma_vioxx_viagraaa_Fioriceet-Phentremine and other popular meds.*valium_XXanax_Cialis$ http://www.527.ranking299pill.biz/b12 -- ecology don declarator authoritarian vagary ancestry balance dissociate regressive lieutenant decompression decontrolled fatigue vivify bivouac kwashiorkor dendritic doyle ----472539636407692473-- --===============2094402385== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============2094402385==-- From ipsec-bounces@ietf.org Thu Jun 3 11:21:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19771 for ; Thu, 3 Jun 2004 11:21:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVtDb-0006bY-7Q; Thu, 03 Jun 2004 10:29:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVs5N-0003c1-Cc for ipsec@megatron.ietf.org; Thu, 03 Jun 2004 09:16:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08299 for ; Thu, 3 Jun 2004 09:16:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVs5M-0005Qv-Ny for ipsec@ietf.org; Thu, 03 Jun 2004 09:16:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVs4B-0004wg-00 for ipsec@ietf.org; Thu, 03 Jun 2004 09:15:32 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BVs2q-0004Tj-00 for ipsec@ietf.org; Thu, 03 Jun 2004 09:14:08 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i53DCGr04127 for ; Thu, 3 Jun 2004 09:12:19 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i53DBUZm013588 for ; Thu, 3 Jun 2004 09:11:30 -0400 (EDT) Received: from unknown(218.190.87.57) by nutshell.tislabs.com via csmap (V6.0) id srcAAAnPaqFA; Thu, 3 Jun 04 09:11:27 -0400 X-Message-Info: QJVIvYC16dTzqIVLo87n4II9QJPudHXg Received: from lzctnmu64.worldnet.att.net ([254.94.152.152]) by yx2-b83.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Sat, 05 Jun 2004 15:56:15 +0300 Received: from lingerieumbilicusamiyq22 (stomach[204.116.72.142]) by worldnet.att.net (itvcpau87) with SMTP id <85244745228106269555jro0j> (Authid: MiltonGross); Sat, 05 Jun 2004 14:56:15 +0200 From: "Mickey Bergeron" To: "'Ipsec'" Date: Sat, 05 Jun 2004 14:53:15 +0200 Message-ID: <028749n5gx78$1j9c1904$81j9fxdl@allisbusinessmentransshippedkx06> MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.5 required=5.0 tests=BIZ_TLD, SUB_HELLO autolearn=no version=2.60 Subject: [Ipsec] Hello Ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0992686856==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0992686856== Content-Type: multipart/alternative; boundary="--85413514983773607" ----85413514983773607 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Ipsec,# +247!-Online Doctorz! up to 70% of the best pain killers out! _Soma_vioxx_viagraaa_Fioriceet-Phentremine and other popular meds.%valium_XXanax_Cialis: http://www.370.ranking299pill.biz/b12 -- crouch receive loss ensemble flatulent bled bobby cajole enjoinder deepen fairfax shockley explore acquisition defocus row kensington downturn adverse immutable cottage mudguard ova blaze society irrecoverable contraceptive everyone granite canto caveman deferral agway decompression change ----85413514983773607-- --===============0992686856== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0992686856==-- From ipsec-bounces@ietf.org Thu Jun 3 14:11:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29852 for ; Thu, 3 Jun 2004 14:11:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVw6S-0004Fa-34; Thu, 03 Jun 2004 13:34:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVtr8-0007Al-0A for ipsec@megatron.ietf.org; Thu, 03 Jun 2004 11:10:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18787 for ; Thu, 3 Jun 2004 11:10:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVtr3-0000Ku-5D for ipsec@ietf.org; Thu, 03 Jun 2004 11:10:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVton-0007DU-00 for ipsec@ietf.org; Thu, 03 Jun 2004 11:07:45 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BVtmN-0006J1-00 for ipsec@ietf.org; Thu, 03 Jun 2004 11:05:15 -0400 Received: from OEMCOMPUTER ([218.190.132.238]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i53F3Or21063 for ; Thu, 3 Jun 2004 11:03:25 -0400 (EDT) X-Message-Info: 16TZ09FLbglwk682dJUwKGN18ROY845hxsVILnVX9 Received: from 132.80.132.154 by glandular83-ky527.repairman514.ipsec@lists.tislabs.com with DAV; Sat, 05 Jun 2004 12:09:31 -0300 Message-ID: <64891023971031.77991@ipsec@lists.tislabs.com> X-Originating-IP: [185.16.24.227] X-Originating-Email: [ipsec@lists.tislabs.com] X-Sender: ipsec@lists.tislabs.com From: "Kenton Sloan" To: "Ipsec" Date: Sat, 05 Jun 2004 19:13:31 +0400 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.5 required=5.0 tests=HTML_60_70, HTML_IMAGE_ONLY_02, HTML_MESSAGE, MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 Subject: [Ipsec] 470807 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kenton Sloan List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0965483275==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0965483275== Content-Type: multipart/alternative; boundary="--51327342988829331" ----51327342988829331 Content-Type: text/html; charset="iso-8517-4" Content-Transfer-Encoding: 7Bit

cliMck here if you would not like to receive future maelings.



plaid uprise birthright mcgill tomography toodle hid hobby beneficial disputant swollen corey stockpile fructify hatfield cartilaginous

----51327342988829331-- --===============0965483275== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0965483275==-- From ipsec-bounces@ietf.org Thu Jun 3 14:51:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02494 for ; Thu, 3 Jun 2004 14:51:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVwWF-0002K4-3t; Thu, 03 Jun 2004 14:00:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVvo9-0000ol-Gz for ipsec@megatron.ietf.org; Thu, 03 Jun 2004 13:15:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23621 for ; Thu, 3 Jun 2004 12:21:54 -0400 (EDT) From: steve.hanna@sun.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVuya-0004b4-3P for ipsec@ietf.org; Thu, 03 Jun 2004 12:21:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVuxb-0004EY-00 for ipsec@ietf.org; Thu, 03 Jun 2004 12:20:56 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BVuwX-0003WG-00 for ipsec@ietf.org; Thu, 03 Jun 2004 12:19:49 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i53GI1r01267 for ; Thu, 3 Jun 2004 12:18:01 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i53GHDGe012591 for ; Thu, 3 Jun 2004 12:17:13 -0400 (EDT) Message-Id: <200406031617.i53GHDGe012591@nutshell.tislabs.com> Received: from unknown(200.252.145.60) by nutshell.tislabs.com via csmap (V6.0) id srcAAAeKaaKy; Thu, 3 Jun 04 12:17:08 -0400 To: ipsec@lists.tislabs.com Date: Thu, 3 Jun 2004 13:22:13 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.4 required=5.0 tests=FREE_TRIAL,HTML_20_30, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_BOUND_NEXTPART,MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER, NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Your information X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit My mail is attached. Thanks +++ X-Attachment-Type: document +++ X-Attachment-Status: no virus found +++ Powered by the new Norton OnlineAntiVirus +++ Free trial: www.norton.com ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="mail8.pif.htm" Content-Disposition: attachment; filename="mail8.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: mail8.pif
Virus name: W32/Netsky.s@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0016----=_NextPart_000_0016-- From ipsec-bounces@ietf.org Thu Jun 3 15:24:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05957 for ; Thu, 3 Jun 2004 15:24:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVxDX-0004X2-Cj; Thu, 03 Jun 2004 14:45:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVwPU-00015s-QO for ipsec@megatron.ietf.org; Thu, 03 Jun 2004 13:53:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24455 for ; Thu, 3 Jun 2004 12:58:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVvXg-00076l-Hv for ipsec@ietf.org; Thu, 03 Jun 2004 12:58:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVvQP-0003wX-00 for ipsec@ietf.org; Thu, 03 Jun 2004 12:50:42 -0400 Received: from da001d3897.stl-mo.osd.concentric.net ([66.236.111.57] helo=AIREMAIL.airespace.com) by ietf-mx with esmtp (Exim 4.12) id 1BVvPS-00034X-00 for ipsec@ietf.org; Thu, 03 Jun 2004 12:49:42 -0400 Received: from airespace.com ([172.16.16.121]) by AIREMAIL.airespace.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 3 Jun 2004 09:51:30 -0700 Message-ID: <40BF5711.7090404@airespace.com> Date: Thu, 03 Jun 2004 09:51:29 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Theodore Ts'o" Subject: Re: [Ipsec] Results of the Straw Poll re: Fragmentation handling References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jun 2004 16:51:30.0337 (UTC) FILETIME=[04D20110:01C4498B] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Ted, I'm a little surprised at your assessment of my position on question #2, so I think I must have been unclear. Here's your summary: > Scott G. Kelly > 1. SHOULD/MUST (for 3 only) > 2. MUST NOT > 3. SHOULD Here's what I said for #2: > NONE of the above - why even mention this? I doubt there are many > 100% compliant implementations for the first round of ipsec, and find > it highly unlikely that this will change. Implementations that don't > care about fragment security probably don't care about port/protocol > differentiation. The two seem incompatible and unlikely. I can't > believe we've wasted so much time/energy on this. I'm sorry that this was unclear. What I meant to say was, why even mention this in the draft at all - why make it an option? I guess my point was that if folks want to implement special handling for special cases, history has demonstrated that they will do so whether they have special dispensation or not. It may not make sense to complicate the spec for (what I perceive to be) a very small minority of implementations. That's not a clear selection of one of the terms you asked for, but it's definitely not a MUST NOT. I guess I should have used the RFC2119 language, in which case I might say "SHOULD NOT", meaning someone that really knows what they are doing might have justification, but this should not be casually undertaken. I think the current draft rev gives cautions for ipv6, but we might want similar cautions for ipv4. The primary assumption underlying a fragment-only SA is that the other end can be trusted to only put allowable data into the tunnel. Sometimes this assumption is justified, but this is certainly not always the case. Hence, this assumption must be evaluated prior to implementing a fragment-only tunnel. As an aside, I wonder if anyone requiring such a thing in practice wouldn't be better off to simply "tunnel-all" over a single SA pair. --Scott Theodore Ts'o wrote: > The results of the straw poll indicated that out of 16 responses, > roughly twice as many contributors (11) preferred that Methods #2 and > #3 be a MAY implement, over thouse who preferred that at least one of > Methods #2 and #3 be a SHOULD or a MUST (5). > > There was also a somewhat surprising number (albeit a minority) who > registered a strong dislike of Method #2 --- four or five respondents > indicated that they thought Method #2 should be a MUST NOT. > > Hence, it seems that we have a rough consensus within the working > group that both Method #2 and #3 should both be MAY. To accomodate > those who dislike Method #2, I would propose that if we can get > someone from that camp to write a paragraph detailing their > objections to mixing non-initial fragments when initial fragments are > not mixed, it would seem to me reasonable to record the minority > dissent in the architecture specification. > > - Ted > > > Yoav Nir 1. MAY / MAY 2. MAY 3. MAY > > Tero Kivnen 1. SHOULD/MUST 2. MAY 3. SHOULD > > Scott G. Kelly 1. SHOULD/MUST (for 3 only) 2. MUST NOT 3. SHOULD > > Michael Roe 1. MAY / MAY 2. MAY 3. MAY > > Yougui Cheng 1. MAY / MAY 2. SHOULD NOT 3. MAY > > Mark Duffy 1. MAY / MAY 2. MAY 3. MAY > > Niklas Hallqvist 1. MAY / MAY 2. MAY 3. MAY > > Srini 1. SHOULD / MUST 2. MAY 3. SHOULD > > Satoshi Inoue 1. MAY / MAY 2. MAY 3. MAY > > Valery Smyslov 1. SHOULD / MUST 2. MAY 3. SHOULD > > Paul Hoffman 1. MAY / MAY 2. MAY 3. MAY > > Bora Akyol 1. MAY / MAY 2. MAY 3. MAY > > Joe Tardo 1. SHOULD / MUST (3 should be MUST) 2. MAY 3. SHOULD > > Markku Savela 1. MAY / MAY 2. MUST NOT 3. MAY > > > Mika Joutsenvirta 1. MAY / MAY 2. MAY 3. MAY > > Joe Touch 1. MAY / MAY (2 MUST NOT) 2. MUST NOT 3. MAY > > > > _______________________________________________ Ipsec mailing list > Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 3 19:58:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10799 for ; Thu, 3 Jun 2004 19:58:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW1oa-0006Xu-GW; Thu, 03 Jun 2004 19:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BW1dv-00034D-8M for ipsec@megatron.ietf.org; Thu, 03 Jun 2004 19:29:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09006 for ; Thu, 3 Jun 2004 19:29:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BW1dt-0000zH-R3 for ipsec@ietf.org; Thu, 03 Jun 2004 19:29:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BW1bf-0000I1-00 for ipsec@ietf.org; Thu, 03 Jun 2004 19:26:45 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BW1X4-0006iZ-00 for ipsec@ietf.org; Thu, 03 Jun 2004 19:21:58 -0400 Received: from YahooBB219048174019.bbtec.net (YahooBB219048174019.bbtec.net [219.48.174.19]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i53NK3r28812; Thu, 3 Jun 2004 19:20:04 -0400 (EDT) Message-Id: <200406032320.i53NK3r28812@lists.tislabs.com> X-Message-Info: X132IX532Bu93piWhiwE5V721nBqqiV2 Received: from mail pickup service by 219.48.174.19 with Microsoft SMTPSVC; Fri, 04 Jun 2004 01:19:41 +0100 Content-Class: urn:content-classes:message From: "Raymundo Rivers" To: "Ipsec" Date: Fri, 04 Jun 2004 04:14:41 +0400 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.1 required=5.0 tests=BIZ_TLD, CLICK_BELOW, HTML_70_80, HTML_LINK_CLICK_HERE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Subject: [Ipsec] Re: Low cost meds - Shipped overnight X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Raymundo Rivers List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1696908313==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1696908313== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="--47406471062851185507" ----47406471062851185507 Content-Type: text/html; charset="iso-0650-6" Content-Description: battlefield carolyn7.cashew Content-Transfer-Encoding: 7Bit anabaptist ft deere contiguity monomial earth stickle gymnosperm dramatic send agnostic freeport marginal moisture deadwood hem thine infest

 
Prozac 
 Vlagra
 Phentermlne
 Soma
 Amblen
Vallum 
 Clalis
 Xanax
Get over 300 medicatlons online shlpped overnight to your front door with no prescrlption.
   *  No Prescrlptlon Needed
   *  Fully Confldential
   *  No Embarrassment
   *  No Waiting Rooms
   *  Shlpped Overnlght
   *  Dlscreet Packaging

 

 

If you wish for email elimination, you can do so here.

 


 


 

 

chalky earthmoving bestubble draco earthmove chair bail marcello crimp equilibrate manley commiserate crankcase salutary resurrect internecine renault cia prophet promulgate resort krebs sacrament broth bedrock apricot palm weatherbeaten jest workaday acre barrette incredulous amnesia bujumbura bright thespian mart dickinson begotten consultative stylish tournament stanhope glove sian midnight impressible mathewson deck intellectual patrolling chromatogram flaunt elk dualism carrion asparagine analytic robinson craftsperson amethystine chandelier siege homology inflame albeit disrupt debut ambiguity patchy bibliography booky chalkboard diplomatic yardstick steppe payroll ejaculate disquietude anyway hydrophilic sacrificial psychometry clive ironside emasculate shalom aspersion prescriptcornflower rectify distinguish scalp puissant consequent sentiment peabody aau annalen comfort fabulous trainman alacrity pond aile suffragette pectoralis continuous gain sentential knot carolinian lose cowardice calcify woo weinberg obey plumb thieves capitulate liquidus post iodate panoramic pravda pence egregious lanthanum atypic spade poultice corset soignee sliver impasse jaw memorable laos dictionary smooth aberrant debra jennie congressman bridgetown perth lorinda excretion joel viscous tenneco dave councilwomen swanky audrey czech physiognomy decadent ----47406471062851185507-- --===============1696908313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1696908313==-- From ipsec-bounces@ietf.org Fri Jun 4 09:46:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08789 for ; Fri, 4 Jun 2004 09:46:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWEtH-0001Jt-FO; Fri, 04 Jun 2004 09:37:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWEga-0007R8-2a for ipsec@megatron.ietf.org; Fri, 04 Jun 2004 09:24:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07603 for ; Fri, 4 Jun 2004 09:24:38 -0400 (EDT) From: ietf-wd@v6security.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWEgZ-0000qk-4F for ipsec@ietf.org; Fri, 04 Jun 2004 09:24:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWEf5-00004X-00 for ipsec@ietf.org; Fri, 04 Jun 2004 09:23:07 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BWEbm-000749-00 for ipsec@ietf.org; Fri, 04 Jun 2004 09:19:42 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i54DHqr10205 for ; Fri, 4 Jun 2004 09:17:52 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i54DH6Bx023459 for ; Fri, 4 Jun 2004 09:17:06 -0400 (EDT) Message-Id: <200406041317.i54DH6Bx023459@nutshell.tislabs.com> Received: from unknown(200.252.145.60) by nutshell.tislabs.com via csmap (V6.0) id srcAAACEaGWT; Fri, 4 Jun 04 09:17:03 -0400 To: ipsec@lists.tislabs.com Date: Fri, 4 Jun 2004 10:22:09 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=HTML_20_30, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MIME_BOUND_NEXTPART, MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: Hi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit The user list. +++ X-Attachment-Type: document +++ X-Attachment-Status: no virus found +++ Powered by the new F-Secure OnlineAntiVirus +++ Visit us: www.f-secure.com ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="user_list7.pif.htm" Content-Disposition: attachment; filename="user_list7.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: user_list7.pif
Virus name: W32/Netsky.s@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0016----=_NextPart_000_0016-- From ipsec-bounces@ietf.org Fri Jun 4 13:01:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23059 for ; Fri, 4 Jun 2004 13:01:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWHrK-0001jK-Nw; Fri, 04 Jun 2004 12:47:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWHjF-0008Ko-Vb for ipsec@megatron.ietf.org; Fri, 04 Jun 2004 12:39:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21447 for ; Fri, 4 Jun 2004 12:39:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWHjE-00027F-TP for ipsec@ietf.org; Fri, 04 Jun 2004 12:39:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWHiN-0001kv-00 for ipsec@ietf.org; Fri, 04 Jun 2004 12:38:45 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BWHhS-0001Nt-00 for ipsec@ietf.org; Fri, 04 Jun 2004 12:37:46 -0400 Received: from user-0c90pr0.cable.mindspring.com (user-0c90pr0.cable.mindspring.com [24.144.103.96]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i54GZkr07027 for ; Fri, 4 Jun 2004 12:35:46 -0400 (EDT) Message-Id: <200406041635.i54GZkr07027@lists.tislabs.com> X-Message-Info: D836DS360TOlucu4hscYEBuMW23V1qoTITdoIV44 Received: from 226.228.57.238 by ip-1-546-538-500.u.ipsec@portal.gw.tislabs.com (AppleMailServer 36.0.1.6) id 155257306410 via NDR; Fri, 04 Jun 2004 15:29:22 -0200 From: "Eloise Holt" To: "Ipsec" Date: Fri, 04 Jun 2004 11:37:22 -0600 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.1 required=5.0 tests=BIZ_TLD, CLICK_BELOW, HTML_70_80, HTML_LINK_CLICK_HERE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Subject: [Ipsec] Low cost xanax,valium, soma,etc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eloise Holt List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1488148107==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1488148107== Content-Type: multipart/alternative; boundary="--0431813672237297" ----0431813672237297 Content-Type: text/html; charset="iso-3102-6" Content-Description: buret cancelled00.muslin Content-Transfer-Encoding: 7Bit bellingham hosiery bitt nuclide archer abetting hood durham plaza inexpedient limerick career epitaph circlet cumulus downward tectonic sough

 
Prozac 
 Vlagra
 Phentermlne
 Soma
 Amblen
Vallum 
 Clalis
 Xanax
Get over 300 medicatlons online shlpped overnight to your front door with no prescrlption.
   *  No Prescrlptlon Needed
   *  Fully Confldential
   *  No Embarrassment
   *  No Waiting Rooms
   *  Shlpped Overnlght
   *  Dlscreet Packaging

 

 

If you wish for email elimination, you can do so here.

 


 


 

 

snowball nashua amount gabrielle blissful fritillary gather depredate calendrical alveolus etch usury bostonian chanson monolith blanc maltreat they've pion analysis retrofitted strikebreak swami roundtable sip magnesite wrist sumeria basilisk hinge buteo triptych dow cinderella bake modicum radar derate reconnaissance ouch qatar abstract garrison pantheism legerdemain thurman nearsighted administratrix shibboleth banbury amperage oberlin culinary garcia eft coagulate councilman ala albumin incursion roast certify arbitrage friction pollution suggestive rankin level tutorial gumshoe agree glossary oilmen vague inducible peugeot winkle kennedy buttonweed stupor spectrography ks clapboard fl legend nettle frill rubric adapt demisedigit moroccan pursuer vertebral expunge hey erode contralto czech wheresoever ambidextrous autocratic hitherto occipital olav confuse ship alvin candidacy bartlett monash andover fumble roof eclat diploid afford bulwark whereabout crematory squirmy coastline tarnish ice phenylalanine vessel pang shifty hex w palisade adjutant pericles granular couscous yarn guam airframe percentage uracil trudge zloty blocky magna ephesian argive idea gust turnaround groin sylow bullfinch cheat daybed practise obtain buzzer authentic athwart lovelorn ----0431813672237297-- --===============1488148107== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1488148107==-- From ipsec-bounces@ietf.org Fri Jun 4 16:12:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06877 for ; Fri, 4 Jun 2004 16:12:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWKxL-0002pv-0f; Fri, 04 Jun 2004 16:06:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWKra-0001wc-Vl for ipsec@megatron.ietf.org; Fri, 04 Jun 2004 16:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06406 for ; Fri, 4 Jun 2004 16:00:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWKrZ-0004dX-EX for ipsec@ietf.org; Fri, 04 Jun 2004 16:00:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWKqg-0004J6-00 for ipsec@ietf.org; Fri, 04 Jun 2004 15:59:30 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BWKps-0003z7-00 for ipsec@ietf.org; Fri, 04 Jun 2004 15:58:40 -0400 Received: from f39019.upc-f.chello.nl (f39019.upc-f.chello.nl [80.56.39.19]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i54Jufr29005; Fri, 4 Jun 2004 15:56:42 -0400 (EDT) X-Message-Info: NVBEnJG34cQ5CxoN4PkjtZ7J0N0g74ZV Received: from bernhard.bahama.com ([144.88.193.24]) by eo74-a71.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Sun, 06 Jun 2004 16:42:36 -0300 Received: from tty9-dwindle3.R6mna.com (crystallography4 [163.253.4.76]) by boxy.u9.com (4.52.8/7.14.8) with ESMTP id q4FQ1bo65479 for ; Sun, 06 Jun 2004 12:37:36 -0700 GMT Received: (from i7cardiac@localhost) by eto2-bissau7.i6mdh.com (8.62.1/5.52.4) id e1QM6yk96755; Mon, 07 Jun 2004 00:37:36 +0500 GMT X-Authentication-Warning: oto2-seville2.s2wdg.com: c7mastodon set sender to ipsec@lists.tislabs.com using -f MIME-Version: 1.0 Date: Sun, 06 Jun 2004 14:36:36 -0500 From: Thomas Roberson To: ipsec@lists.tislabs.com Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.7 required=5.0 tests=BIZ_TLD,HTML_60_70, HTML_IMAGE_ONLY_06,HTML_IMAGE_RATIO_04,HTML_MESSAGE,MIME_HTML_ONLY, MIME_HTML_ONLY_MULTI autolearn=no version=2.60 Subject: [Ipsec] Hi Ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1507072241==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1507072241== Content-Type: multipart/alternative; boundary="--513860404551313" ----513860404551313 Content-Type: text/html; Content-Transfer-Encoding: 7Bit
SaEve 6G0% ordKering onlOine ToBday!

Viusit our Site and SaSve Big

distaff burro rater stanza collaborate higgins jeroboam gluing argentina patchy refractory drury anorthic fay can't chevrolet siege auspicious bert perchlorate longitudinal deforest compute conqueror icarus dublin cain bergman hightail tudor penance rutabaga intendant din blur BX7 sterile beethoven antisemite dar hansel karma block sunburn archimedes parquet ostrander vignette okay beauteous rave austenite 6DY6 duckeminent
rm
----513860404551313-- --===============1507072241== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1507072241==-- From ipsec-bounces@ietf.org Fri Jun 4 17:40:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16265 for ; Fri, 4 Jun 2004 17:40:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWLgn-0001BN-HW; Fri, 04 Jun 2004 16:53:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWLN8-0000I9-Ei for ipsec@megatron.ietf.org; Fri, 04 Jun 2004 16:33:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08142 for ; Fri, 4 Jun 2004 16:33:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWLN7-0000Ny-3A for ipsec@ietf.org; Fri, 04 Jun 2004 16:33:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWLM1-0007jv-00 for ipsec@ietf.org; Fri, 04 Jun 2004 16:31:54 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BWLKw-0007Ir-00 for ipsec@ietf.org; Fri, 04 Jun 2004 16:30:46 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i54KSur02382 for ; Fri, 4 Jun 2004 16:28:56 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i54KSAZj022167 for ; Fri, 4 Jun 2004 16:28:10 -0400 (EDT) Received: from snark.piermont.com(166.84.151.72) by nutshell.tislabs.com via csmap (V6.0) id srcAAAxja4rR; Fri, 4 Jun 04 16:28:08 -0400 Received: by snark.piermont.com (Postfix, from userid 1000) id 08B12D97C8; Fri, 4 Jun 2004 16:30:42 -0400 (EDT) To: ipsec@lists.tislabs.com From: "Perry E. Metzger" Date: Fri, 04 Jun 2004 16:30:41 -0400 Message-ID: <87pt8fysjy.fsf@snark.piermont.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] spam X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Is there a reason posting to this list can't be restricted to subscribers? The spam levels are insane. Perry _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 4 18:39:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24636 for ; Fri, 4 Jun 2004 18:39:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWN9S-00029w-4j; Fri, 04 Jun 2004 18:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWMvP-0003Bp-SX for ipsec@megatron.ietf.org; Fri, 04 Jun 2004 18:12:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21525 for ; Fri, 4 Jun 2004 18:12:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWMvO-0006sr-Bb for ipsec@ietf.org; Fri, 04 Jun 2004 18:12:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWMoV-0005MP-00 for ipsec@ietf.org; Fri, 04 Jun 2004 18:05:24 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 1BWMfa-0003BS-00 for ipsec@ietf.org; Fri, 04 Jun 2004 17:56:10 -0400 Received: from isi.edu (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i54LsPJ22516; Fri, 4 Jun 2004 14:54:25 -0700 (PDT) Message-ID: <40C0EFC0.9010607@isi.edu> Date: Fri, 04 Jun 2004 14:55:12 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Scott G. Kelly" Subject: Re: [Ipsec] Results of the Straw Poll re: Fragmentation handling References: <40BF5711.7090404@airespace.com> In-Reply-To: <40BF5711.7090404@airespace.com> X-Enigmail-Version: 0.83.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org, "Theodore Ts'o" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1706705452==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1706705452== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB4DBC5556ACAFCE467188339" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB4DBC5556ACAFCE467188339 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Scott G. Kelly wrote: > Hi Ted, > > I'm a little surprised at your assessment of my position on question > #2, so I think I must have been unclear. Here's your summary: > >> Scott G. Kelly > > > 1. SHOULD/MUST (for 3 only) > > 2. MUST NOT > > 3. SHOULD > > Here's what I said for #2: > >> NONE of the above - why even mention this? I doubt there are many >> 100% compliant implementations for the first round of ipsec, and find >> it highly unlikely that this will change. Implementations that don't >> care about fragment security probably don't care about port/protocol >> differentiation. The two seem incompatible and unlikely. I can't >> believe we've wasted so much time/energy on this. > > > I'm sorry that this was unclear. What I meant to say was, why even > mention this in the draft at all - why make it an option? I agree - even mentioning it just confuses things. There are no other cases where packets from a single SPI entering on a single interface with the same addresses and ports are handled by different SPD entries. I can't imagine why anyone would think separating the two would be a good thing, and if the policies are different, a dangerous thing. ... > That's not a clear selection of one of the terms you asked for, but it's > definitely not a MUST NOT. I guess I should have used the RFC2119 > language, in which case I might say "SHOULD NOT", meaning someone that > really knows what they are doing might have justification, but this > should not be casually undertaken. I think the current draft rev gives > cautions for ipv6, but we might want similar cautions for ipv4. Anyone who wants to violate a spec can do so at their own peril. The MUST NOT would be to suggest this is a dangerous thing, with otherwise uncontrolled consequences. IMO, if it's mentioned at all, it is definitely MUST NOT. Joe --------------enigB4DBC5556ACAFCE467188339 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAwO/AE5f5cImnZrsRAr1wAJ0Z+N65ld+NybHCizy+CQpzMCbQAwCgtLuQ FfRuuHhEYa0mQZOjseteJOA= =1thp -----END PGP SIGNATURE----- --------------enigB4DBC5556ACAFCE467188339-- --===============1706705452== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1706705452==-- From ipsec-bounces@ietf.org Fri Jun 4 22:44:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05147 for ; Fri, 4 Jun 2004 22:44:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWR53-00033L-Ew; Fri, 04 Jun 2004 22:38:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWR38-0002rU-Ft for ipsec@megatron.ietf.org; Fri, 04 Jun 2004 22:36:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04962 for ; Fri, 4 Jun 2004 22:36:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWR36-0002bV-G1 for ipsec@ietf.org; Fri, 04 Jun 2004 22:36:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWR2R-0002IE-00 for ipsec@ietf.org; Fri, 04 Jun 2004 22:36:03 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BWR1a-0001x4-00 for ipsec@ietf.org; Fri, 04 Jun 2004 22:35:10 -0400 Received: from cm218-254-16-115.hkcable.com.hk (cm218-254-16-115.hkcable.com.hk [218.254.16.115]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i552XIr06109 for ; Fri, 4 Jun 2004 22:33:18 -0400 (EDT) X-Message-Info: Q237Z375CMS944znY180DGH0qwtKamjIWI187 Received: from [44.25.150.209] by faraday68285.wheatstone.ipsec@lists.tislabs.com via HTTP; Mon, 07 Jun 2004 03:43:33 +0100 Date: Mon, 07 Jun 2004 06:38:33 +0400 Message-ID: <52096420402.95918@ipsec@lists.tislabs.com> From: "Norman Elkins" To: "Ipsec" Date: Mon, 07 Jun 2004 00:45:33 -0200 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=BIZ_TLD autolearn=no version=2.60 Subject: [Ipsec] 387121 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Norman Elkins List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1961276267==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1961276267== Content-Type: multipart/alternative; boundary="--8078785707281710" ----8078785707281710 Content-Type: text/plain; charset="iso-1950-1" Content-Transfer-Encoding: 7Bit Ipsec,% 75%off for all New Softwares. WindowXP,Photoshop,Window2003...etcMore http://mus.willbringtoyou.biz/index.php?s=3971 -- morris always touchdown betoken monolith couldn't irreconcilable cohesive cargoes bodhisattva regal spline shrewish hankel taipei borealis core hockey capella erode bracket butyl comparison amorous clout confidante scarsdale clothbound dyer wreck monkey ----8078785707281710-- --===============1961276267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1961276267==-- From ipsec-bounces@ietf.org Fri Jun 4 22:57:05 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05695 for ; Fri, 4 Jun 2004 22:57:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWRJX-00053h-QB; Fri, 04 Jun 2004 22:53:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWRIg-0004tK-Lu for ipsec@megatron.ietf.org; Fri, 04 Jun 2004 22:52:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05434 for ; Fri, 4 Jun 2004 22:52:48 -0400 (EDT) From: rob.parkhill@windriver.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWRIe-000024-Oh for ipsec@ietf.org; Fri, 04 Jun 2004 22:52:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWRHj-0007V9-00 for ipsec@ietf.org; Fri, 04 Jun 2004 22:51:51 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BWRHK-0007B1-00 for ipsec@ietf.org; Fri, 04 Jun 2004 22:51:27 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i552nVr07343 for ; Fri, 4 Jun 2004 22:49:31 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i552mer6007102 for ; Fri, 4 Jun 2004 22:48:40 -0400 (EDT) Received: from unknown-1-11.windriver.com(147.11.1.11) by nutshell.tislabs.com via csmap (V6.0) id srcAAAH7aO2n; Fri, 4 Jun 04 22:48:38 -0400 Received: from ala-mta03.windriver.com (ala-mta03 [147.11.57.132]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id TAA01123 for ; Fri, 4 Jun 2004 19:51:08 -0700 (PDT) Received: by ala-mta03.wrs.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jun 2004 19:51:08 -0700 Message-ID: To: ipsec@lists.tislabs.com Subject: Out of Office AutoReply: [Suspected Spam] [Ipsec] 387121 Date: Fri, 4 Jun 2004 19:51:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I will be out of the office from June 7th until June 9th, and will only have limited email access. For all urgent IPsec issues, please contact David Mikulin. thanks... Rob _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Jun 5 15:20:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00242 for ; Sat, 5 Jun 2004 15:20:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWgcz-0002sY-E9; Sat, 05 Jun 2004 15:14:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWgbf-0002Cz-QO for ipsec@megatron.ietf.org; Sat, 05 Jun 2004 15:13:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29365 for ; Sat, 5 Jun 2004 15:13:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWgbe-0003v8-H2 for ipsec@ietf.org; Sat, 05 Jun 2004 15:13:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWgad-0003dP-00 for ipsec@ietf.org; Sat, 05 Jun 2004 15:12:24 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BWgZf-0003Lb-00 for ipsec@ietf.org; Sat, 05 Jun 2004 15:11:23 -0400 Received: from cm218-253-74-40.hkcable.com.hk (cm218-253-74-40.hkcable.com.hk [218.253.74.40]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i55J9Sr04695 for ; Sat, 5 Jun 2004 15:09:29 -0400 (EDT) X-Message-Info: 5EAotSDY60LDQsv55TN53bkxSgiEIC57hnET686xnVLBkkM574 Received: from dns508netbird.com ([56.194.23.116]) by 1zh-lv1.ipsec@portal.gw.tislabs.com with Microsoft SMTPSVC(5.0.9825.7513); Tue, 06 Jul 2004 15:14:00 -0400 Message-ID: <8078560920240.63155@ipsec@portal.gw.tislabs.com> From: "Christian Noel" To: "Ipsec" Date: Tue, 06 Jul 2004 23:06:00 +0400 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.7 required=5.0 tests=BIZ_TLD, ROUND_THE_WORLD_LOCAL autolearn=no version=2.60 Subject: [Ipsec] Hi Ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Christian Noel List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1048123357==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1048123357== Content-Type: multipart/alternative; boundary="--1209521898817069487" ----1209521898817069487 Content-Type: text/plain; charset="iso-8023-8" Content-Transfer-Encoding: 7Bit stair algal cookery delimitation Ipsec,% We are your your convenient, safe and private on^line source for FDA a.ppro`ved prescriptions. If you need X^an@x, V@|ium, Vi^c0`din, S.oma, Paxi1 or Meridia we have it. Overnight sh~ipping Get it Today: http://www.937.xerox4160pill.biz/b12 Simple or-dering system nope, not for me: http://added.coulomb.gfg4sd.com/b.html quillwort listen afraid bloodstone dylan dew objet dale hub calf fasten sonogram . ----1209521898817069487-- --===============1048123357== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1048123357==-- From ipsec-bounces@ietf.org Sat Jun 5 20:57:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17426 for ; Sat, 5 Jun 2004 20:57:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWlux-0001Jc-9B; Sat, 05 Jun 2004 20:53:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWlsx-000144-AH for ipsec@megatron.ietf.org; Sat, 05 Jun 2004 20:51:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17216 for ; Sat, 5 Jun 2004 20:51:37 -0400 (EDT) From: uri@lucent.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWlsv-0003g0-H6 for ipsec@ietf.org; Sat, 05 Jun 2004 20:51:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWlry-0003Pa-00 for ipsec@ietf.org; Sat, 05 Jun 2004 20:50:39 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BWlrf-00039l-00 for ipsec@ietf.org; Sat, 05 Jun 2004 20:50:19 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i560mSr15665 for ; Sat, 5 Jun 2004 20:48:28 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i560lhmC000576 for ; Sat, 5 Jun 2004 20:47:43 -0400 (EDT) Received: from va-staff-u1-c5f-78.frbgva.adelphia.net(67.21.59.78) by nutshell.tislabs.com via csmap (V6.0) id srcAAATtaOgb; Sat, 5 Jun 04 20:47:39 -0400 Date: Sat, 05 Jun 2004 20:50:12 -0500 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------wonfkvpjfokybpgjjtui" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY,NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] Incoming message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------wonfkvpjfokybpgjjtui Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Follow the wabbit.


----------wonfkvpjfokybpgjjtui Content-Type: text/html; name="Details.pif.htm" Content-Disposition: attachment; filename="Details.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Details.pif
Virus name: W32/Bagle.n@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------wonfkvpjfokybpgjjtui Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------wonfkvpjfokybpgjjtui-- From ipsec-bounces@ietf.org Sun Jun 6 10:37:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03240 for ; Sun, 6 Jun 2004 10:37:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWyid-0008CV-Gs; Sun, 06 Jun 2004 10:33:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWyi1-00081w-Gh for ipsec@megatron.ietf.org; Sun, 06 Jun 2004 10:33:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03143 for ; Sun, 6 Jun 2004 10:33:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWyi0-0000Ug-FQ for ipsec@ietf.org; Sun, 06 Jun 2004 10:33:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWyh4-0000Fc-00 for ipsec@ietf.org; Sun, 06 Jun 2004 10:32:14 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BWygD-0007n5-00 for ipsec@ietf.org; Sun, 06 Jun 2004 10:31:21 -0400 Received: from YOUR-WJCOX37R61 ([221.127.71.52]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i56ETQr02918 for ; Sun, 6 Jun 2004 10:29:27 -0400 (EDT) X-Message-Info: 9ZYY77Jndme669wijYDDsWO917EEU335oaXQBryESL770 Received: from 243.8.74.15 by chaotic315-qh59.stenography43.ipsec@lists.tislabs.com with DAV; Tue, 08 Jun 2004 16:37:34 +0100 Message-ID: <45711418816.00062@ipsec@lists.tislabs.com> X-Originating-IP: [149.108.192.248] X-Originating-Email: [ipsec@lists.tislabs.com] X-Sender: ipsec@lists.tislabs.com From: "Marci Cramer" To: "Ipsec" Date: Tue, 08 Jun 2004 20:31:34 +0500 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] Ipsec liqueur bungalow X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Marci Cramer List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1984266788==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1984266788== Content-Type: multipart/alternative; boundary="--=====118294448107=_" ----=====118294448107=_ Content-Type: text/plain; charset="iso-7115-6" Content-Transfer-Encoding: 7Bit countrify articulatory studious kerygma Ipsec,) We are your your convenient, safe and private on^line source for FDA a.ppro`ved prescriptions. If you need X^an@x, V@|ium, Vi^c0`din, S.oma, Paxi1 or Meridia we have it. Overnight sh~ipping Get it Today: http://www.595.weeds2181biz.us/b12 Simple or-dering system nope, not for me: http://apex.multitude.gfg4sd.com/b.html newsman flag chippendale aspire fanciful freight daughter ligature asphalt grim bam barbudo bill prep discriminant hug bolshoi volvo carrel contour aloft hyacinth seder budge tyranny phage beast pound stimulate jurisprudential ouch southpaw atalanta articulatory crate devotion bestselling extroversion dilution coil duress delphinium puffball repartee blatz hydrosphere . ----=====118294448107=_-- --===============1984266788== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1984266788==-- From ipsec-bounces@ietf.org Sun Jun 6 12:42:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08181 for ; Sun, 6 Jun 2004 12:42:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BX0fb-0007HO-8c; Sun, 06 Jun 2004 12:38:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BX0b9-0006QM-K4 for ipsec@megatron.ietf.org; Sun, 06 Jun 2004 12:34:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07822 for ; Sun, 6 Jun 2004 12:34:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BX0b8-0000PY-KY for ipsec@ietf.org; Sun, 06 Jun 2004 12:34:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BX0aB-0000A9-00 for ipsec@ietf.org; Sun, 06 Jun 2004 12:33:16 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BX0ZR-0007id-00 for ipsec@ietf.org; Sun, 06 Jun 2004 12:32:29 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i56GUZr00443 for ; Sun, 6 Jun 2004 12:30:35 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i56GTs7C004205 for ; Sun, 6 Jun 2004 12:29:54 -0400 (EDT) Received: from cm218-253-137-126.hkcable.com.hk(218.253.137.126) by nutshell.tislabs.com via csmap (V6.0) id srcAAAt1aaki; Sun, 6 Jun 04 12:29:50 -0400 X-Message-Info: 12O2JAmh40bTLKzdB50EK270xTvLV6 Received: from 173.154.50.235 by vermin83-no14.micronesia19.ipsec@lists.tislabs.com with DAV; Tue, 08 Jun 2004 22:39:38 +0500 Message-ID: <38462299925082269120.74046@ipsec@lists.tislabs.com> X-Originating-IP: [183.220.250.134] X-Originating-Email: [ipsec@lists.tislabs.com] X-Sender: ipsec@lists.tislabs.com From: "Mayra Lacy" To: "Ipsec" Date: Tue, 08 Jun 2004 13:34:38 -0400 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] Ipsec deficit 14 mirrors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mayra Lacy List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1813421904==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1813421904== Content-Type: multipart/alternative; boundary="--=_AzsntI86kjRm" ----=_AzsntI86kjRm Content-Type: text/plain; charset="iso-1068-9" Content-Transfer-Encoding: 7Bit Ipsec," valiumXanaxCialis and_more Get Hydrocodone, or Soma.^ 2 of the best pain killers out! please LQQk~ http://www.545.weeds2181biz.us/b12 -- limestone pose ding anthracnose lyman arcane photolysis artie shatterproof crow chaos catlike . ----=_AzsntI86kjRm-- --===============1813421904== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1813421904==-- From ipsec-bounces@ietf.org Sun Jun 6 13:43:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10548 for ; Sun, 6 Jun 2004 13:43:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BX1cC-000203-L1; Sun, 06 Jun 2004 13:39:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BX1XI-0000zE-Vb for ipsec@megatron.ietf.org; Sun, 06 Jun 2004 13:34:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10202 for ; Sun, 6 Jun 2004 13:34:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BX1XH-0001ig-Uu for ipsec@ietf.org; Sun, 06 Jun 2004 13:34:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BX1WL-0001RE-00 for ipsec@ietf.org; Sun, 06 Jun 2004 13:33:21 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BX1VE-00012I-00 for ipsec@ietf.org; Sun, 06 Jun 2004 13:32:13 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i56HUHr16166 for ; Sun, 6 Jun 2004 13:30:17 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i56HTX9K017711 for ; Sun, 6 Jun 2004 13:29:33 -0400 (EDT) Received: from mxout2.netvision.net.il(194.90.9.21) by nutshell.tislabs.com via csmap (V6.0) id srcAAAr1ayJI; Sun, 6 Jun 04 13:29:30 -0400 Received: from [217.132.90.91] by mxout2.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0HYW007W7E183E@mxout2.netvision.net.il> for ipsec@lists.tislabs.com; Sun, 06 Jun 2004 20:31:56 +0300 (IDT) Date: Sun, 06 Jun 2004 20:32:01 +0300 From: Yoav Nir Subject: Re: [Ipsec] spam In-reply-to: <87pt8fysjy.fsf@snark.piermont.com> To: "Perry E. Metzger" Message-id: <6B5C5093-B7DF-11D8-8E09-000393AD410A@netvision.net.il> MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <87pt8fysjy.fsf@snark.piermont.com> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7BIT Strangely, yours is the only post my email client thought was that. It might be because you actually used the s-word. Anyway, as has been pointed out before, the letters mostly seem to originate from legitimate subscribers. The emails and names can easily be harvested from web archives and other methods. Since SMTP is basically insecure, anyone can pretend to be a list member and send this stuff to the list. On 04/06/2004, at 23:30, Perry E. Metzger wrote: > > Is there a reason posting to this list can't be restricted to > subscribers? The s-am levels are insane. > > Perry > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jun 6 14:23:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11855 for ; Sun, 6 Jun 2004 14:23:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BX2BU-0000m3-RD; Sun, 06 Jun 2004 14:15:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BX28A-0008T9-1n for ipsec@megatron.ietf.org; Sun, 06 Jun 2004 14:12:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11631 for ; Sun, 6 Jun 2004 14:12:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BX288-0004g7-Vf for ipsec@ietf.org; Sun, 06 Jun 2004 14:12:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BX27G-0004PC-00 for ipsec@ietf.org; Sun, 06 Jun 2004 14:11:31 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BX26n-00047w-00 for ipsec@ietf.org; Sun, 06 Jun 2004 14:11:01 -0400 Received: from 80-218-138-160.dclient.hispeed.ch (80-218-138-160.dclient.hispeed.ch [80.218.138.160]) by lists.tislabs.com (8.11.6/8.11.6) with SMTP id i56I94r25936; Sun, 6 Jun 2004 14:09:04 -0400 (EDT) X-Message-Info: RR6HEK3NQdtsm83ziYPPaiZFT4PNC42hlKqwxXPQ8 Received: from dns4yahoo.com ([177.31.98.26]) by rn0-7955.ipsec@lists.tislabs.com with Microsoft SMTPSVC(5.0.2195.3128); Mon, 07 Jun 2004 00:12:28 +0500 Received: (from germicide@localhost) by genii1.ipsec@lists.tislabs.com (3.48.8/5.93.4) id co26MAkH071025; Sun, 06 Jun 2004 18:13:28 -0100 Message-ID: <324601151012.13628@ipsec@lists.tislabs.com> From: "Jaime Juarez" To: "Ipsec" Date: Sun, 06 Jun 2004 13:08:28 -0600 MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.3 required=5.0 tests=BIZ_TLD, CLICK_BELOW, HTML_70_80, HTML_LINK_CLICK_HERE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI autolearn=no version=2.60 Subject: [Ipsec] Supersavings on all pain medications - No prescription required X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jaime Juarez List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0784033473==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0784033473== Content-Type: multipart/alternative; boundary="--8157662530075372317" ----8157662530075372317 Content-Type: text/html; charset="iso-4121-1" Content-Description: prayerful big4850.arclength Content-Transfer-Encoding: 7Bit biota adenosine diode sprague tyler virile diana vicar bub type cursor barley sprig cut chordal rag ellipse colony

 
Prozac 
 Vlagra
 Phentermlne
 Soma
 Amblen
Vallum 
 Clalis
 Xanax
Get over 300 medicatlons online shlpped overnight to your front door with no prescrlption.
   *  No Prescrlptlon Needed
   *  Fully Confldential
   *  No Embarrassment
   *  No Waiting Rooms
   *  Shlpped Overnlght
   *  Dlscreet Packaging

 

 

If you wish for email elimination, you can do so here.

 


 


 

 

rug bedimmed drudge burton freetown steradian interpret checksum cryptanalyst eavesdropper addressee billion mantic theft portend sparge compacter innocuous millennia whitehead impure ix bade industrial across cookery attach deconvolve sabine sung pennsylvania granular irresolute dogwood admonition alger maxim permutation swift external karp eliot emitter barton committeewomen ephemeris azure moen crave doorkeep rex shire max laud bonnie caliper beryllium sparta syringa oleander equidistant trojan unwieldy ado glutton daughter participate sanatorium tracery buttonweed shrunken montmartre iraq cosmic headlight barge ursula tread deplete crowbait exception augment prairie capacious nation persistent sling ascetic coal hypoactiveeyesore surprise distributor angie hellebore decertify authoritarian shipbuild donaldson fritillary complaisant cluck harrington larkspur shack q unanimity dynamic intake cannonball corpsman masque demolish orono upper cab afoul cyclist dustbin fungus lack nordhoff callus ingenuity bourn xerox delve lipton berate restaurant gretchen templeton frowzy herein cupric berate physic preemptor montrachet fibonacci procreate corral byline avaricious button bloodstain daytime inward barrage pax whittaker bufflehead buss human booklet stall decide jerusalem faucet mcfadden ----8157662530075372317-- --===============0784033473== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0784033473==-- From ipsec-bounces@ietf.org Sun Jun 6 16:54:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19680 for ; Sun, 6 Jun 2004 16:54:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BX4bv-0008Lt-BP; Sun, 06 Jun 2004 16:51:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BX4TS-0006eB-Uq for ipsec@megatron.ietf.org; Sun, 06 Jun 2004 16:42:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19238 for ; Sun, 6 Jun 2004 16:42:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BX4TR-00011u-EN for ipsec@ietf.org; Sun, 06 Jun 2004 16:42:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BX4SV-0000iR-00 for ipsec@ietf.org; Sun, 06 Jun 2004 16:41:35 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BX4Rb-0000PS-00 for ipsec@ietf.org; Sun, 06 Jun 2004 16:40:39 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i56Kclr03266; Sun, 6 Jun 2004 16:38:47 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i56Kc4sW028567; Sun, 6 Jun 2004 16:38:04 -0400 (EDT) Received: from rs9.luxsci.com(66.216.98.59) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKvaGW3; Sun, 6 Jun 04 16:38:01 -0400 Received: from rs9.luxsci.com (localhost [127.0.0.1]) by rs9.luxsci.com (8.12.11/8.12.10) with ESMTP id i56KeWYe004579 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sun, 6 Jun 2004 15:40:32 -0500 Received: (from root@localhost) by rs9.luxsci.com (8.12.11/8.12.10/Submit) id i56Kc1Um004281; Sun, 6 Jun 2004 20:38:01 GMT Message-Id: <200406062038.i56Kc1Um004281@rs9.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Sun, 06 Jun 2004 20:38:01 +0000 From: "William Dixon" To: "'Yoav Nir'" , "'Perry E. Metzger'" Subject: RE: [Ipsec] spam Date: Sun, 6 Jun 2004 16:37:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-reply-to: <6B5C5093-B7DF-11D8-8E09-000393AD410A@netvision.net.il> X-Lux-Comment: LuxSci remailer message ID code - 1086554281-6487241.75219303 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=MSGID_FROM_MTA_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, ipsec-owner@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I agree. The best option is to get our current hoster to filter spam and viruses for this list. I assume TIS does this for other lists, so I'd hope there isn't an additional cost. But if there's a cost, I can contribute some. I'd also be happy to go through the pain of changing the list name and resubscribing, and finding another list hoster if TIS can't provide filtering. I've noticed I've received s-word email within 1-2 hours of posting. That's ridiculous. > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Yoav Nir > Sent: Sunday, June 06, 2004 1:32 PM > To: Perry E. Metzger > Cc: ipsec@lists.tislabs.com > Subject: Re: [Ipsec] spam > > Strangely, yours is the only post my email client thought was > that. It might be because you actually used the s-word. > > Anyway, as has been pointed out before, the letters mostly > seem to originate from legitimate subscribers. The emails > and names can easily be harvested from web archives and other > methods. Since SMTP is basically insecure, anyone can > pretend to be a list member and send this stuff to the list. > > On 04/06/2004, at 23:30, Perry E. Metzger wrote: > > > > > Is there a reason posting to this list can't be restricted to > > subscribers? The s-am levels are insane. > > > > Perry > > > > _______________________________________________ > > Ipsec mailing list > > Ipsec@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipsec > > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 00:26:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06587 for ; Mon, 7 Jun 2004 00:26:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXBaI-0006jN-Sq; Mon, 07 Jun 2004 00:18:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXBV2-00051o-ON for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 00:12:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05912 for ; Mon, 7 Jun 2004 00:12:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXBV0-00041O-Pz for ipsec@ietf.org; Mon, 07 Jun 2004 00:12:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXBTy-0003dZ-00 for ipsec@ietf.org; Mon, 07 Jun 2004 00:11:35 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXBT1-0003G5-00 for ipsec@ietf.org; Mon, 07 Jun 2004 00:10:35 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5748gr15794 for ; Mon, 7 Jun 2004 00:08:42 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i57480kP005073 for ; Mon, 7 Jun 2004 00:08:00 -0400 (EDT) Received: from snark.piermont.com(166.84.151.72) by nutshell.tislabs.com via csmap (V6.0) id srcAAAcOay5j; Mon, 7 Jun 04 00:07:59 -0400 Received: by snark.piermont.com (Postfix, from userid 1000) id 34B73D97CF; Mon, 7 Jun 2004 00:10:32 -0400 (EDT) To: Yoav Nir Subject: Re: [Ipsec] spam References: <87pt8fysjy.fsf@snark.piermont.com> <6B5C5093-B7DF-11D8-8E09-000393AD410A@netvision.net.il> From: "Perry E. Metzger" Date: Mon, 07 Jun 2004 00:10:32 -0400 In-Reply-To: <6B5C5093-B7DF-11D8-8E09-000393AD410A@netvision.net.il> (Yoav Nir's message of "Sun, 06 Jun 2004 20:32:01 +0300") Message-ID: <877juknh3b.fsf@snark.piermont.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > Anyway, as has been pointed out before, the letters mostly seem to > originate from legitimate subscribers. The emails and names can > easily be harvested from web archives and other methods. Since SMTP > is basically insecure, anyone can pretend to be a list member and send > this stuff to the list. However, those of us who run mailing lists find that although anyone "can" forge a list member's address, it is almost unheard of that it actually happens. Restricting my lists to subscribers only has eliminated 100% of the spam going to them. As for the problem of people who would like to post from an address other than the one they subscribe from, as I've noted, mailman, which is already used to manage this list, can handle that trivially, so this isn't a problem, either. I'm a subscriber to several hundred mailing lists (yes, really) and all but a handful of them restrict posting to subscribers. Perry _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 00:29:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06676 for ; Mon, 7 Jun 2004 00:29:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXBau-0006x5-Js; Mon, 07 Jun 2004 00:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXBX5-0005d9-IF for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 00:14:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06009 for ; Mon, 7 Jun 2004 00:14:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXBX3-0004s7-HG for ipsec@ietf.org; Mon, 07 Jun 2004 00:14:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXBWD-0004YM-00 for ipsec@ietf.org; Mon, 07 Jun 2004 00:13:54 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXBUH-0003vp-00 for ipsec@ietf.org; Mon, 07 Jun 2004 00:11:53 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i574A0r15945; Mon, 7 Jun 2004 00:10:00 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5749IRu005281; Mon, 7 Jun 2004 00:09:18 -0400 (EDT) Received: from unknown(140.239.227.29) by nutshell.tislabs.com via csmap (V6.0) id srcAAAdTaaqk; Mon, 7 Jun 04 00:09:17 -0400 Received: from dsl092-109-027.nyc2.dsl.speakeasy.net ([66.92.109.27] helo=thunk.org) authenticated as tytso by thunker.thunk.org with asmtp (tls_cipher TLSv1:RC4-SHA:128) (Exim 3.35 #1 (Debian)) id 1BXBLF-0005iE-00; Mon, 07 Jun 2004 00:02:33 -0400 Received: from tytso by thunk.org with local (Exim 4.34) id 1BXBLD-0000jE-1g; Mon, 07 Jun 2004 00:02:31 -0400 Date: Mon, 7 Jun 2004 00:02:30 -0400 From: "Theodore Ts'o" To: William Dixon Subject: Re: [Ipsec] spam Message-ID: <20040607040230.GA2792@thunk.org> References: <6B5C5093-B7DF-11D8-8E09-000393AD410A@netvision.net.il> <200406062038.i56Kc1Um004281@rs9.luxsci.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200406062038.i56Kc1Um004281@rs9.luxsci.com> User-Agent: Mutt/1.5.6+20040523i X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@lists.tislabs.com, "'Yoav Nir'" , ipsec-owner@lists.tislabs.com, "'Perry E. Metzger'" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Sun, Jun 06, 2004 at 04:37:04PM -0400, William Dixon wrote: > I agree. The best option is to get our current hoster to filter spam and > viruses for this list. I assume TIS does this for other lists, so I'd hope > there isn't an additional cost. But if there's a cost, I can contribute > some. I'd also be happy to go through the pain of changing the list name and > resubscribing, and finding another list hoster if TIS can't provide > filtering. I've noticed I've received s-word email within 1-2 hours of > posting. That's ridiculous. We're actually using ipsec@ietf.org, actually. The ipsec@lists.tislabs.com address was just there for backwards compatibility. And ietf.org is supposedly using spamassassin as well, but apparently it's not tuned particularly well. What we can do is get rid of the forwarding, which might help for a little while (until the spammers adapt). - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 00:53:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08226 for ; Mon, 7 Jun 2004 00:53:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXC4U-00065L-KM; Mon, 07 Jun 2004 00:49:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXC3P-0005jC-FT for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 00:48:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07547 for ; Mon, 7 Jun 2004 00:48:08 -0400 (EDT) From: hugh@toad.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXC3N-0007WV-DN for ipsec@ietf.org; Mon, 07 Jun 2004 00:48:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXC1K-0006xQ-00 for ipsec@ietf.org; Mon, 07 Jun 2004 00:46:03 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BXC0Q-0006Lw-03 for ipsec@ietf.org; Mon, 07 Jun 2004 00:45:07 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BXBvi-0003Gx-BW for ipsec@ietf.org; Mon, 07 Jun 2004 00:40:14 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i574cEr21898 for ; Mon, 7 Jun 2004 00:38:18 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i574bURk010972 for ; Mon, 7 Jun 2004 00:37:30 -0400 (EDT) Message-Id: <200406070437.i574bURk010972@nutshell.tislabs.com> Received: from unknown(211.87.231.104) by nutshell.tislabs.com via csmap (V6.0) id srcAAAY8aqwv; Mon, 7 Jun 04 00:37:21 -0400 To: ipsec@lists.tislabs.com Date: Mon, 7 Jun 2004 12:31:52 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="60314100" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=HTML_30_40, HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MSGID_FROM_MTA_HEADER,NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] hi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --60314100 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit i'm waiting --60314100 Content-Type: text/html; name="attachment.zip.htm" Content-Disposition: attachment; filename="attachment.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: attachment.zip
Virus name: W32/Netsky.b@MM!zip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

--60314100 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --60314100-- From ipsec-bounces@ietf.org Mon Jun 7 02:47:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26599 for ; Mon, 7 Jun 2004 02:47:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXDk1-0002TC-GH; Mon, 07 Jun 2004 02:36:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXDih-0002DJ-QP for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 02:34:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25965 for ; Mon, 7 Jun 2004 02:34:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXDif-0004Nx-9Y for ipsec@ietf.org; Mon, 07 Jun 2004 02:34:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXDhi-00044f-00 for ipsec@ietf.org; Mon, 07 Jun 2004 02:33:55 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXDgt-0003lX-00 for ipsec@ietf.org; Mon, 07 Jun 2004 02:33:03 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i576VAr23123 for ; Mon, 7 Jun 2004 02:31:10 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i576USDA009133 for ; Mon, 7 Jun 2004 02:30:28 -0400 (EDT) Received: from michael.checkpoint.com(194.29.32.68) by nutshell.tislabs.com via csmap (V6.0) id srcAAALlaOYr; Mon, 7 Jun 04 02:30:25 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id i576Wvs03020; Mon, 7 Jun 2004 09:32:57 +0300 (IDT) In-Reply-To: <877juknh3b.fsf@snark.piermont.com> References: <87pt8fysjy.fsf@snark.piermont.com> <6B5C5093-B7DF-11D8-8E09-000393AD410A@netvision.net.il> <877juknh3b.fsf@snark.piermont.com> Mime-Version: 1.0 (Apple Message framework v618) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8375854B-B84C-11D8-BB95-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] spam Date: Mon, 7 Jun 2004 09:32:56 +0300 To: "Perry E. Metzger" X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, Yoav Nir X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Lots of the virii we get appear to come from uri at lucent dot com, who I know is a legitimate subscriber because he posts real messages. I don't know about hugh at toad dot com, but that's only because he doesn't post. He might very well be a legitimate lurker. On Jun 7, 2004, at 7:10 AM, Perry E. Metzger wrote: > > Yoav Nir writes: >> Anyway, as has been pointed out before, the letters mostly seem to >> originate from legitimate subscribers. The emails and names can >> easily be harvested from web archives and other methods. Since SMTP >> is basically insecure, anyone can pretend to be a list member and send >> this stuff to the list. > > However, those of us who run mailing lists find that although anyone > "can" forge a list member's address, it is almost unheard of that it > actually happens. Restricting my lists to subscribers only has > eliminated 100% of the spam going to them. > > As for the problem of people who would like to post from an address > other than the one they subscribe from, as I've noted, mailman, which > is already used to manage this list, can handle that trivially, so this > isn't a problem, either. > > I'm a subscriber to several hundred mailing lists (yes, really) and > all but a handful of them restrict posting to subscribers. > > Perry > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 04:13:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00546 for ; Mon, 7 Jun 2004 04:13:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXFCz-0005Av-RF; Mon, 07 Jun 2004 04:10:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXF8E-00049F-5R for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 04:05:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00214 for ; Mon, 7 Jun 2004 04:05:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXF8B-0004Dk-PE for ipsec@ietf.org; Mon, 07 Jun 2004 04:05:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXF7K-0003rT-00 for ipsec@ietf.org; Mon, 07 Jun 2004 04:04:26 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXF6a-0003Ua-00 for ipsec@ietf.org; Mon, 07 Jun 2004 04:03:40 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5781mr12964 for ; Mon, 7 Jun 2004 04:01:48 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i578163u029807 for ; Mon, 7 Jun 2004 04:01:06 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAjbaOm6; Mon, 7 Jun 04 04:01:00 -0400 Date: Mon, 07 Jun 2004 04:03:44 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------jijlijwneaxjhqcsjyag" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Incoming Message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------jijlijwneaxjhqcsjyag Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------jijlijwneaxjhqcsjyag Content-Type: text/html; name="You_will_answer_to_me.hta.htm" Content-Disposition: attachment; filename="You_will_answer_to_me.hta.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: You_will_answer_to_me.hta
Virus name: W32/Bagle.aa@MM!vbs

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------jijlijwneaxjhqcsjyag Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------jijlijwneaxjhqcsjyag-- From ipsec-bounces@ietf.org Mon Jun 7 08:27:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10875 for ; Mon, 7 Jun 2004 08:27:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXJ4t-0001IB-Am; Mon, 07 Jun 2004 08:18:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXJ1G-000086-Kz for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 08:14:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10138 for ; Mon, 7 Jun 2004 08:14:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXJ1F-0004VZ-Qw for ipsec@ietf.org; Mon, 07 Jun 2004 08:14:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXIzs-0003e4-00 for ipsec@ietf.org; Mon, 07 Jun 2004 08:13:00 -0400 Received: from [61.95.203.84] (helo=BLR-MAIL.NETD.COM) by ietf-mx with esmtp (Exim 4.12) id 1BXIya-00035S-00 for ipsec@ietf.org; Mon, 07 Jun 2004 08:11:40 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i57CBUxV010310; Mon, 7 Jun 2004 17:41:31 +0530 Message-ID: <40C45C9D.4040207@netd.com> Date: Mon, 07 Jun 2004 17:46:29 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org References: <5.2.0.9.0.20040601142755.0331cf58@10.1.5.10> In-Reply-To: <5.2.0.9.0.20040601142755.0331cf58@10.1.5.10> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com Subject: [Ipsec] Qos issue related to rfc2401bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi All, In section 4.1 it says that IPsec implementation must permit establishment and maintanance of multiple SA's between a given sender and receiver,with the same selectors, it means to say that, do we need to create the SA's according to the flow and class of service as adding one parameter in the SA whitch indicates class of service and will be searched for SA for an inbound packet. How can it be locally determined, is it QOS will be done first on the IKE packets or any other mechanism will be avilable to do this. Thx mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 08:27:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10892 for ; Mon, 7 Jun 2004 08:27:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXJ4u-0001IJ-5P; Mon, 07 Jun 2004 08:18:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXJ1H-000089-JY for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 08:14:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10141 for ; Mon, 7 Jun 2004 08:14:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXJ1H-0004Vo-19 for ipsec@ietf.org; Mon, 07 Jun 2004 08:14:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXIzw-0003jO-00 for ipsec@ietf.org; Mon, 07 Jun 2004 08:13:05 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXIyh-00036q-00 for ipsec@ietf.org; Mon, 07 Jun 2004 08:11:48 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i57C9sU01684 for ; Mon, 7 Jun 2004 08:09:54 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i57C9C5F025606 for ; Mon, 7 Jun 2004 08:09:12 -0400 (EDT) Received: from unknown(61.95.203.84) by nutshell.tislabs.com via csmap (V6.0) id srcAAAjiaW_X; Mon, 7 Jun 04 08:09:09 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i57CBUxV010310; Mon, 7 Jun 2004 17:41:31 +0530 Message-ID: <40C45C9D.4040207@netd.com> Date: Mon, 07 Jun 2004 17:46:29 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org References: <5.2.0.9.0.20040601142755.0331cf58@10.1.5.10> In-Reply-To: <5.2.0.9.0.20040601142755.0331cf58@10.1.5.10> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com Subject: [Ipsec] Qos issue related to rfc2401bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi All, In section 4.1 it says that IPsec implementation must permit establishment and maintanance of multiple SA's between a given sender and receiver,with the same selectors, it means to say that, do we need to create the SA's according to the flow and class of service as adding one parameter in the SA whitch indicates class of service and will be searched for SA for an inbound packet. How can it be locally determined, is it QOS will be done first on the IKE packets or any other mechanism will be avilable to do this. Thx mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 08:37:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11658 for ; Mon, 7 Jun 2004 08:37:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXJID-0004ms-Pr; Mon, 07 Jun 2004 08:31:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXJ9i-000251-0Q for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 08:23:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10802 for ; Mon, 7 Jun 2004 08:23:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXJ9h-0000bS-G7 for ipsec@ietf.org; Mon, 07 Jun 2004 08:23:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXJ8i-0000D7-00 for ipsec@ietf.org; Mon, 07 Jun 2004 08:22:09 -0400 Received: from [61.95.203.84] (helo=BLR-MAIL.NETD.COM) by ietf-mx with esmtp (Exim 4.12) id 1BXJ7b-0007Dq-00 for ipsec@ietf.org; Mon, 07 Jun 2004 08:21:00 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i57CKhxV010743; Mon, 7 Jun 2004 17:50:44 +0530 Message-ID: <40C45EC6.80402@netd.com> Date: Mon, 07 Jun 2004 17:55:42 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: tislabs Subject: [Ipsec] Is there any document whitch extensively discusses on ipsec implementation in freeBSD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi All, Is there any document avilable whitch will give detailed description of Ipsec flow of packet in FreeBSD. Thx mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 08:40:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11764 for ; Mon, 7 Jun 2004 08:40:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXJIE-0004my-IC; Mon, 07 Jun 2004 08:31:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXJ9i-000253-Nq for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 08:23:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10805 for ; Mon, 7 Jun 2004 08:23:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXJ9i-0000bX-6b for ipsec@ietf.org; Mon, 07 Jun 2004 08:23:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXJ8j-0000DF-00 for ipsec@ietf.org; Mon, 07 Jun 2004 08:22:09 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXJ7k-0007aV-00 for ipsec@ietf.org; Mon, 07 Jun 2004 08:21:08 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i57CJEU04129 for ; Mon, 7 Jun 2004 08:19:14 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i57CIW7K026846 for ; Mon, 7 Jun 2004 08:18:32 -0400 (EDT) Received: from unknown(61.95.203.84) by nutshell.tislabs.com via csmap (V6.0) id srcAAAgPaOA0; Mon, 7 Jun 04 08:18:29 -0400 Received: from netd.com ([10.91.0.37]) by BLR-MAIL.NETD.COM (8.12.10/8.12.8) with ESMTP id i57CKhxV010743; Mon, 7 Jun 2004 17:50:44 +0530 Message-ID: <40C45EC6.80402@netd.com> Date: Mon, 07 Jun 2004 17:55:42 +0530 From: "M.Chenna kesava Reddy" Organization: Net Devices User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-NetD-India-MailScanner-Information: Please contact the NetD-India Sysadmin for more information X-NetD-India-MailScanner: Found to be clean X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: tislabs Subject: [Ipsec] Is there any document whitch extensively discusses on ipsec implementation in freeBSD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mcreddy@netd.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi All, Is there any document avilable whitch will give detailed description of Ipsec flow of packet in FreeBSD. Thx mcreddy _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 10:11:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17511 for ; Mon, 7 Jun 2004 10:11:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXKdr-0003Hp-FF; Mon, 07 Jun 2004 09:58:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXKW7-000111-LX for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 09:50:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15714 for ; Mon, 7 Jun 2004 09:50:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXKW7-0007O5-00 for ipsec@ietf.org; Mon, 07 Jun 2004 09:50:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXKVA-0006xw-00 for ipsec@ietf.org; Mon, 07 Jun 2004 09:49:24 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXKUW-0006Z2-00 for ipsec@ietf.org; Mon, 07 Jun 2004 09:48:45 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i57DkmU26637 for ; Mon, 7 Jun 2004 09:46:48 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i57Dk8Cc010165 for ; Mon, 7 Jun 2004 09:46:08 -0400 (EDT) Received: from snark.piermont.com(166.84.151.72) by nutshell.tislabs.com via csmap (V6.0) id srcAAAMqaq2t; Mon, 7 Jun 04 09:46:06 -0400 Received: by snark.piermont.com (Postfix, from userid 1000) id EAFF6D97CF; Mon, 7 Jun 2004 09:48:39 -0400 (EDT) To: Yoav Nir Subject: Re: [Ipsec] spam References: <87pt8fysjy.fsf@snark.piermont.com> <6B5C5093-B7DF-11D8-8E09-000393AD410A@netvision.net.il> <877juknh3b.fsf@snark.piermont.com> <8375854B-B84C-11D8-BB95-000A95834BAA@checkpoint.com> From: "Perry E. Metzger" Date: Mon, 07 Jun 2004 09:48:39 -0400 In-Reply-To: <8375854B-B84C-11D8-BB95-000A95834BAA@checkpoint.com> (Yoav Nir's message of "Mon, 7 Jun 2004 09:32:56 +0300") Message-ID: <87r7srmqbs.fsf@snark.piermont.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@lists.tislabs.com, Yoav Nir X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > Lots of the virii we get appear to come from uri at lucent dot com, The viruses are trivially stopped by blocking all the vulnerable microsoft file types, such as .exe and .zip. I don't see such postings because my hosts already block them. Perry _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 10:24:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18802 for ; Mon, 7 Jun 2004 10:24:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXKvE-0003Tx-H0; Mon, 07 Jun 2004 10:16:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXKqY-0001HG-55 for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 10:11:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17474 for ; Mon, 7 Jun 2004 10:11:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXKqX-00010u-1T for ipsec@ietf.org; Mon, 07 Jun 2004 10:11:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXKpY-0000aI-00 for ipsec@ietf.org; Mon, 07 Jun 2004 10:10:29 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXKoo-0000AM-00 for ipsec@ietf.org; Mon, 07 Jun 2004 10:09:42 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i57E7eU03770 for ; Mon, 7 Jun 2004 10:07:43 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i57E6u1j013053 for ; Mon, 7 Jun 2004 10:06:56 -0400 (EDT) Received: from sadr.equallogic.com(66.155.203.134) by nutshell.tislabs.com via csmap (V6.0) id srcAAAmCaWEz; Mon, 7 Jun 04 10:06:52 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i57E9QAT031665 for ; Mon, 7 Jun 2004 10:09:26 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i57E9QjV031660; Mon, 7 Jun 2004 10:09:26 -0400 Received: from pkoning.equallogic.com ([172.16.1.249]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 7 Jun 2004 10:09:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16580.30484.622649.604495@gargle.gargle.HOWL> Date: Mon, 7 Jun 2004 10:09:24 -0400 From: Paul Koning To: perry@piermont.com Subject: Re: [Ipsec] spam References: <87pt8fysjy.fsf@snark.piermont.com> <6B5C5093-B7DF-11D8-8E09-000393AD410A@netvision.net.il> <877juknh3b.fsf@snark.piermont.com> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 07 Jun 2004 14:09:26.0174 (UTC) FILETIME=[0A6B7BE0:01C44C99] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, ynir@netvision.net.il X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "Perry" == Perry E Metzger writes: Perry> Yoav Nir writes: >> Anyway, as has been pointed out before, the letters mostly seem to >> originate from legitimate subscribers. The emails and names can >> easily be harvested from web archives and other methods. Since >> SMTP is basically insecure, anyone can pretend to be a list member >> and send this stuff to the list. Perry> However, those of us who run mailing lists find that although Perry> anyone "can" forge a list member's address, it is almost Perry> unheard of that it actually happens. Restricting my lists to Perry> subscribers only has eliminated 100% of the spam going to Perry> them. That certainly would not be true for the IPsec list -- I've looked over enough IPsec message headers to say that. FOr IPsec, the percentage of forged addresses is clearly quite large. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 10:37:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20680 for ; Mon, 7 Jun 2004 10:37:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXL9v-0000UC-Jv; Mon, 07 Jun 2004 10:31:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXL6H-0007UJ-Rx for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 10:27:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19143 for ; Mon, 7 Jun 2004 10:27:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXL6G-0000dj-N2 for ipsec@ietf.org; Mon, 07 Jun 2004 10:27:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXL4a-0007YR-00 for ipsec@ietf.org; Mon, 07 Jun 2004 10:26:00 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXL3F-00070c-00 for ipsec@ietf.org; Mon, 07 Jun 2004 10:24:37 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i57EMeU09192 for ; Mon, 7 Jun 2004 10:22:41 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i57ELxEv015210 for ; Mon, 7 Jun 2004 10:21:59 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAOOaOMD; Mon, 7 Jun 04 10:21:54 -0400 Date: Mon, 07 Jun 2004 15:30:09 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------wknnazvkumoaeznpgkgr" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------wknnazvkumoaeznpgkgr Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------wknnazvkumoaeznpgkgr Content-Type: text/html; name="Information.cpl.htm" Content-Disposition: attachment; filename="Information.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Information.cpl
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------wknnazvkumoaeznpgkgr Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------wknnazvkumoaeznpgkgr-- From ipsec-bounces@ietf.org Mon Jun 7 12:03:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25414 for ; Mon, 7 Jun 2004 12:03:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXMQt-0003GG-Fo; Mon, 07 Jun 2004 11:53:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXMFe-0000d7-0l for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 11:41:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24577 for ; Mon, 7 Jun 2004 11:41:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXMFd-0004MO-3w for ipsec@ietf.org; Mon, 07 Jun 2004 11:41:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXMDx-0003Qa-00 for ipsec@ietf.org; Mon, 07 Jun 2004 11:39:45 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXMCz-0002tC-00 for ipsec@ietf.org; Mon, 07 Jun 2004 11:38:45 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i57FaoU02196 for ; Mon, 7 Jun 2004 11:36:50 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i57Fa94j025620 for ; Mon, 7 Jun 2004 11:36:09 -0400 (EDT) Received: from snark.piermont.com(166.84.151.72) by nutshell.tislabs.com via csmap (V6.0) id srcAAAu3aacY; Mon, 7 Jun 04 11:36:07 -0400 Received: by snark.piermont.com (Postfix, from userid 1000) id 0408CD97CF; Mon, 7 Jun 2004 11:38:41 -0400 (EDT) To: Paul Koning Subject: Re: [Ipsec] spam References: <87pt8fysjy.fsf@snark.piermont.com> <6B5C5093-B7DF-11D8-8E09-000393AD410A@netvision.net.il> <877juknh3b.fsf@snark.piermont.com> <16580.30484.622649.604495@gargle.gargle.HOWL> From: "Perry E. Metzger" Date: Mon, 07 Jun 2004 11:38:40 -0400 In-Reply-To: <16580.30484.622649.604495@gargle.gargle.HOWL> (Paul Koning's message of "Mon, 7 Jun 2004 10:09:24 -0400") Message-ID: <874qpnz8cf.fsf@snark.piermont.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@lists.tislabs.com, ynir@netvision.net.il X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Paul Koning writes: > Perry> However, those of us who run mailing lists find that although > Perry> anyone "can" forge a list member's address, it is almost > Perry> unheard of that it actually happens. Restricting my lists to > Perry> subscribers only has eliminated 100% of the spam going to > Perry> them. > > That certainly would not be true for the IPsec list -- I've looked > over enough IPsec message headers to say that. FOr IPsec, the > percentage of forged addresses is clearly quite large. Not if you exclude viruses. The amount of spam from forged addresses is nil -- the virus activity is separate. However, the viruses are trivially blocked with a rule matching a regular expression like this: /^Content-(Type|Disposition):.*(file)?name=.*\.(asd|bat|chm|cmd|com|cpl|dll|exe|hlp|hta|js|jse|lnk|ocx|pif|rar|scr|shb|shm|shs|vb|vbe|vbs|vbx|vxd|wsf|wsh|zip)/ My machines block all email matching that regexps and as a result I see no viruses at all. -- Perry E. Metzger perry@piermont.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 12:27:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26655 for ; Mon, 7 Jun 2004 12:27:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXMsJ-0002iz-SV; Mon, 07 Jun 2004 12:21:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXMh5-0007Xn-9W for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 12:09:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26025 for ; Mon, 7 Jun 2004 12:09:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXMh4-0002T5-DR for ipsec@ietf.org; Mon, 07 Jun 2004 12:09:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXMg5-0001y7-00 for ipsec@ietf.org; Mon, 07 Jun 2004 12:08:49 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx with esmtp (Exim 4.12) id 1BXMfL-0001Sx-00 for ipsec@ietf.org; Mon, 07 Jun 2004 12:08:03 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i57G6LMf003946; Mon, 7 Jun 2004 10:06:21 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i57G81ii017045; Mon, 7 Jun 2004 12:08:01 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i57G81Wp022192; Mon, 7 Jun 2004 12:08:01 -0400 (EDT) Message-Id: <200406071608.i57G81Wp022192@thunk.east.sun.com> From: Bill Sommerfeld To: mcreddy@netd.com Subject: Re: [Ipsec] Qos issue related to rfc2401bis In-Reply-To: Your message of "Mon, 07 Jun 2004 17:46:29 +0530." <40C45C9D.4040207@netd.com> Date: Mon, 07 Jun 2004 12:08:01 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org, ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sommerfeld@east.sun.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > In section 4.1 it says that IPsec implementation must permit > establishment and maintanance of multiple SA's between a given > sender and receiver,with the same selectors, it means to say that, > do we need to create the SA's according to the flow and class of > service as adding one parameter in the SA whitch indicates class of > service and will be searched for SA for an inbound packet. if you read further, you'll see that qos markings generated before IPsec is applies are used as a pseudo-selector and get passed through to the encrypted packet. qos is used to select/generate multiple SA's during outbound processing, but is ignored for ipsec purposes for inbound processing. so it's purely a local matter for the sender. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 12:29:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26741 for ; Mon, 7 Jun 2004 12:29:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXMsK-0002jN-Uh; Mon, 07 Jun 2004 12:21:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXMhd-0007cA-9A for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 12:10:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26031 for ; Mon, 7 Jun 2004 12:10:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXMhc-0002vw-7g for ipsec@ietf.org; Mon, 07 Jun 2004 12:10:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXMgb-0002QE-00 for ipsec@ietf.org; Mon, 07 Jun 2004 12:09:21 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXMfP-0001T5-00 for ipsec@ietf.org; Mon, 07 Jun 2004 12:08:07 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i57G6DU10331 for ; Mon, 7 Jun 2004 12:06:13 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i57G5V0f029415 for ; Mon, 7 Jun 2004 12:05:31 -0400 (EDT) Received: from brmea-mail-4.sun.com(192.18.98.36) by nutshell.tislabs.com via csmap (V6.0) id srcAAApfaqC5; Mon, 7 Jun 04 12:05:30 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i57G6LMf003946; Mon, 7 Jun 2004 10:06:21 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i57G81ii017045; Mon, 7 Jun 2004 12:08:01 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i57G81Wp022192; Mon, 7 Jun 2004 12:08:01 -0400 (EDT) Message-Id: <200406071608.i57G81Wp022192@thunk.east.sun.com> From: Bill Sommerfeld To: mcreddy@netd.com Subject: Re: [Ipsec] Qos issue related to rfc2401bis In-Reply-To: Your message of "Mon, 07 Jun 2004 17:46:29 +0530." <40C45C9D.4040207@netd.com> Date: Mon, 07 Jun 2004 12:08:01 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org, ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sommerfeld@east.sun.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > In section 4.1 it says that IPsec implementation must permit > establishment and maintanance of multiple SA's between a given > sender and receiver,with the same selectors, it means to say that, > do we need to create the SA's according to the flow and class of > service as adding one parameter in the SA whitch indicates class of > service and will be searched for SA for an inbound packet. if you read further, you'll see that qos markings generated before IPsec is applies are used as a pseudo-selector and get passed through to the encrypted packet. qos is used to select/generate multiple SA's during outbound processing, but is ignored for ipsec purposes for inbound processing. so it's purely a local matter for the sender. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 12:46:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27786 for ; Mon, 7 Jun 2004 12:46:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXNAB-0007Ue-HK; Mon, 07 Jun 2004 12:39:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXN4b-000653-EW for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 12:34:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27175 for ; Mon, 7 Jun 2004 12:34:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXN4a-0006Oq-7w for ipsec@ietf.org; Mon, 07 Jun 2004 12:34:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXN2x-0005oL-00 for ipsec@ietf.org; Mon, 07 Jun 2004 12:32:28 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXN14-00053v-00 for ipsec@ietf.org; Mon, 07 Jun 2004 12:30:30 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i57GSXU16714 for ; Mon, 7 Jun 2004 12:28:34 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i57GRqG0002749 for ; Mon, 7 Jun 2004 12:27:52 -0400 (EDT) Received: from mail.aepsystems.com(193.120.108.90) by nutshell.tislabs.com via csmap (V6.0) id srcAAA1laqxf; Mon, 7 Jun 04 12:27:49 -0400 Received: from Aep-Mail.aep-net.com (unverified) by mailsweep.aep-net.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Mon, 7 Jun 2004 17:30:31 +0100 Received: from aep-uk-dc-01.aep-net.com ([172.17.40.20]) by Aep-Mail.aep-net.com with Microsoft SMTPSVC (5.0.2195.5329); Mon, 7 Jun 2004 17:30:31 +0100 Received: from aepsystems.com ([172.17.40.139]) by aep-uk-dc-01.aep-net.com with Microsoft SMTPSVC (5.0.2195.6713); Mon, 7 Jun 2004 17:30:30 +0100 Message-ID: <40C49865.2060102@aepsystems.com> Date: Mon, 07 Jun 2004 17:31:33 +0100 From: Chris Trobridge User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Re: [Ipsec] spam References: <87pt8fysjy.fsf@snark.piermont.com> <6B5C5093-B7DF-11D8-8E09-000393AD410A@netvision.net.il> <877juknh3b.fsf@snark.piermont.com> <16580.30484.622649.604495@gargle.gargle.HOWL> <874qpnz8cf.fsf@snark.piermont.com> In-Reply-To: <874qpnz8cf.fsf@snark.piermont.com> X-OriginalArrivalTime: 07 Jun 2004 16:30:30.0397 (UTC) FILETIME=[BF7D6AD0:01C44CAC] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=EXCUSE_16,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0626925911==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0626925911== Content-Type: multipart/alternative; boundary="------------060709070803070300060003" This is a multi-part message in MIME format. --------------060709070803070300060003 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Perry E. Metzger wrote: >Paul Koning writes: > > >> Perry> However, those of us who run mailing lists find that although >> Perry> anyone "can" forge a list member's address, it is almost >> Perry> unheard of that it actually happens. Restricting my lists to >> Perry> subscribers only has eliminated 100% of the spam going to >> Perry> them. >> >>That certainly would not be true for the IPsec list -- I've looked >>over enough IPsec message headers to say that. FOr IPsec, the >>percentage of forged addresses is clearly quite large. >> >> > >Not if you exclude viruses. The amount of spam from forged addresses >is nil -- the virus activity is separate. > >However, the viruses are trivially blocked with a rule matching a >regular expression like this: > >/^Content-(Type|Disposition):.*(file)?name=.*\.(asd|bat|chm|cmd|com|cpl|dll|exe|hlp|hta|js|jse|lnk|ocx|pif|rar|scr|shb|shm|shs|vb|vbe|vbs|vbx|vxd|wsf|wsh|zip)/ > >My machines block all email matching that regexps and as a result I >see no viruses at all. > > > What I'm seeing is that all the virused emails are being detected (by a Gauntlet firewall) and I'm just getting reports about the virus being removed. IT says we don't run the firewall. My guess is that it's been checked before it reaches the IETF list server. The emails I've looked at are coming from valid addresses and are addressed to the tislab list address. All the 'spam' I've seen is addressed from ipsec@lists.tislabs.com to the same address. Chris ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. ***************************************************************************** --------------060709070803070300060003 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Perry E. Metzger wrote:
Paul Koning <pkoning@equallogic.com> writes:
  
 Perry> However, those of us who run mailing lists find that although
 Perry> anyone "can" forge a list member's address, it is almost
 Perry> unheard of that it actually happens. Restricting my lists to
 Perry> subscribers only has eliminated 100% of the spam going to
 Perry> them.

That certainly would not be true for the IPsec list -- I've looked
over enough IPsec message headers to say that.  FOr IPsec, the
percentage of forged addresses is clearly quite large.
    

Not if you exclude viruses. The amount of spam from forged addresses
is nil -- the virus activity is separate.

However, the viruses are trivially blocked with a rule matching a
regular expression like this:

/^Content-(Type|Disposition):.*(file)?name=.*\.(asd|bat|chm|cmd|com|cpl|dll|exe|hlp|hta|js|jse|lnk|ocx|pif|rar|scr|shb|shm|shs|vb|vbe|vbs|vbx|vxd|wsf|wsh|zip)/

My machines block all email matching that regexps and as a result I
see no viruses at all.
What I'm seeing is that all the virused emails are being detected (by a Gauntlet firewall) and I'm just getting reports about the virus being removed.  IT says we don't run the firewall.  My guess is that it's been checked before it reaches the IETF list server.  The emails I've looked at are coming from valid addresses and are addressed to the tislab list address.

All the 'spam' I've seen is addressed from ipsec@lists.tislabs.com to the same address.

Chris



**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept for the presence of computer viruses.
*****************************************************************************
 --------------060709070803070300060003-- --===============0626925911== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0626925911==-- From ipsec-bounces@ietf.org Mon Jun 7 14:10:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02737 for ; Mon, 7 Jun 2004 14:10:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOUn-0003d2-O2; Mon, 07 Jun 2004 14:05:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXOKa-0001Wq-RO for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 13:54:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01631 for ; Mon, 7 Jun 2004 13:54:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXOKZ-00015Y-PP for ipsec@ietf.org; Mon, 07 Jun 2004 13:54:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXOGj-0007Pc-00 for ipsec@ietf.org; Mon, 07 Jun 2004 13:50:46 -0400 Received: from above.proper.com ([208.184.76.39]) by ietf-mx with esmtp (Exim 4.12) id 1BXOFX-0006oR-00 for ipsec@ietf.org; Mon, 07 Jun 2004 13:49:31 -0400 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i57HnNa4081775 for ; Mon, 7 Jun 2004 10:49:26 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <40C49865.2060102@aepsystems.com> References: <87pt8fysjy.fsf@snark.piermont.com> <6B5C5093-B7DF-11D8-8E09-000393AD410A@netvision.net.il> <877juknh3b.fsf@snark.piermont.com> <16580.30484.622649.604495@gargle.gargle.HOWL> <874qpnz8cf.fsf@snark.piermont.com> <40C49865.2060102@aepsystems.com> Date: Mon, 7 Jun 2004 10:49:27 -0700 To: IPsec WG From: Paul Hoffman / VPNC Subject: END OF DISCUSSION: Re: [Ipsec] spam Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=-0.2 required=5.0 tests=AWL autolearn=no version=2.60 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The list admin has taken some action that should eliminate all the recent spam and viruses we have seen. How about we talk about IPsec instead? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 7 20:31:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05457 for ; Mon, 7 Jun 2004 20:31:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXUPl-0001Sc-UC; Mon, 07 Jun 2004 20:24:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXUJN-0000Bw-0C for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 20:17:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04777 for ; Mon, 7 Jun 2004 20:17:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXUJL-0001xW-Ar for ipsec@ietf.org; Mon, 07 Jun 2004 20:17:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXUIF-0001JN-00 for ipsec@ietf.org; Mon, 07 Jun 2004 20:16:43 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXUHC-0000cB-00 for ipsec@ietf.org; Mon, 07 Jun 2004 20:15:38 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i580DgU20784 for ; Mon, 7 Jun 2004 20:13:42 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i580D1cL029038 for ; Mon, 7 Jun 2004 20:13:01 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAA7HayS4; Mon, 7 Jun 04 20:12:57 -0400 Date: Mon, 07 Jun 2004 20:15:40 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------znodeogkgxvvmyrqsubf" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Protected message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------znodeogkgxvvmyrqsubf Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------znodeogkgxvvmyrqsubf Content-Type: text/html; name="Joke.hta.htm" Content-Disposition: attachment; filename="Joke.hta.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Joke.hta
Virus name: W32/Bagle.aa@MM!vbs

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------znodeogkgxvvmyrqsubf Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------znodeogkgxvvmyrqsubf-- From ipsec-bounces@ietf.org Tue Jun 8 05:49:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15084 for ; Tue, 8 Jun 2004 05:49:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXd83-0005ef-Gn; Tue, 08 Jun 2004 05:42:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXcsm-0002Mb-RH for ipsec@megatron.ietf.org; Tue, 08 Jun 2004 05:27:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14134 for ; Tue, 8 Jun 2004 05:26:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXcsk-00027L-By for ipsec@ietf.org; Tue, 08 Jun 2004 05:26:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXcrM-0001Jv-00 for ipsec@ietf.org; Tue, 08 Jun 2004 05:25:33 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXcq2-0000W7-00 for ipsec@ietf.org; Tue, 08 Jun 2004 05:24:10 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i589MGU20435 for ; Tue, 8 Jun 2004 05:22:16 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i589La2d017260 for ; Tue, 8 Jun 2004 05:21:36 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4BaWSH; Tue, 8 Jun 04 05:21:32 -0400 Date: Tue, 08 Jun 2004 05:24:18 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rjhgnmliltmbndvxapei" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Message Notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------rjhgnmliltmbndvxapei Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------rjhgnmliltmbndvxapei Content-Type: text/html; name="Info.hta.htm" Content-Disposition: attachment; filename="Info.hta.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Info.hta
Virus name: W32/Bagle.aa@MM!vbs

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------rjhgnmliltmbndvxapei Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------rjhgnmliltmbndvxapei-- From ipsec-bounces@ietf.org Tue Jun 8 17:22:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24721 for ; Tue, 8 Jun 2004 17:22:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXnso-0003ez-Ix; Tue, 08 Jun 2004 17:11:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXljI-00077X-PE for ipsec@megatron.ietf.org; Tue, 08 Jun 2004 14:53:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15874 for ; Tue, 8 Jun 2004 14:53:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXljH-0005bQ-Lx for ipsec@ietf.org; Tue, 08 Jun 2004 14:53:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXliL-0004mf-00 for ipsec@ietf.org; Tue, 08 Jun 2004 14:52:49 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1BXlhl-0003wT-00 for ipsec@ietf.org; Tue, 08 Jun 2004 14:52:13 -0400 X-BrightmailFiltered: true Received: from [10.32.244.18] (stealth-10-32-244-18.cisco.com [10.32.244.18]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id i58IkNiV000815 for ; Tue, 8 Jun 2004 11:46:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) Content-Transfer-Encoding: 7bit Message-Id: <10553307-B97C-11D8-A46B-000A95E07B78@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ipsec@ietf.org From: Barbara Fraser Date: Tue, 8 Jun 2004 11:45:50 -0700 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Message size constraint on mailing list X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi folks, I just posted a note about issue 91 and it bounced back to Ted and me because it was larger than 40k. I manually marked it accepted but just want to caution everyone to try to keep messages under 40k. So don't include all of my message in your response :-) thanks, Barb _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 8 18:34:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02096 for ; Tue, 8 Jun 2004 18:34:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXo0k-0005Wv-71; Tue, 08 Jun 2004 17:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXjo5-0001cY-Kb for ipsec@megatron.ietf.org; Tue, 08 Jun 2004 12:50:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07615 for ; Tue, 8 Jun 2004 12:50:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXjo4-0000Qj-HY for ipsec@ietf.org; Tue, 08 Jun 2004 12:50:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXjn3-0007PI-00 for ipsec@ietf.org; Tue, 08 Jun 2004 12:49:37 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BXjlh-0005lw-00 for ipsec@ietf.org; Tue, 08 Jun 2004 12:48:09 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 08 Jun 2004 09:47:49 -0700 X-BrightmailFiltered: true Received: from [10.32.244.18] (stealth-10-32-244-18.cisco.com [10.32.244.18]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id i58GlWiV025525; Tue, 8 Jun 2004 09:47:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v618) To: ipsec@ietf.org Message-Id: <784A6DAC-B96B-11D8-A46B-000A95E07B78@cisco.com> From: Barbara Fraser Date: Tue, 8 Jun 2004 09:47:03 -0700 X-Mailer: Apple Mail (2.618) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL, HTML_MESSAGE autolearn=no version=2.60 X-Mailman-Approved-At: Tue, 08 Jun 2004 14:39:47 -0400 Cc: angelos@cs.columbia.edu, Russ Housley , Barbara Fraser , "Theodore Y. Ts'o" , Tero Kivinen Subject: [Ipsec] Issue 91 - ICMP error message handling X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0825482496==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0825482496== Content-Type: multipart/alternative; boundary=Apple-Mail-2-1031841482 --Apple-Mail-2-1031841482 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi folks, We're down to what we believe is the last remaining issue for 2401bis.=20= Once we come to closure on this issue and changes are made to the=20 document, we think we'll be finished with the work on 2401bis. In the original 2401 there was text describing the handling of path MTU=20= but the handling of other unprotected ICMP messages was left as a local=20= matter. On October 26, Karen posted the message included below that=20 proposes a more complex algorithm for handling ICMP messages. There=20 has been little discussion to date on this so Ted and I would like to=20 propose the following: 1. Default position: if no one is interested in discussing this issue,=20= we fall back to the text as it existed in 2401 which covers path MTU=20 but is silent on other types of unprotected ICMP messages. 2. If you believe there are deficiencies or ambiguities in the original=20= text on path MTU in 2401 please speak up! 3. If you feel we should take a different approach, such as that=20 proposed by Karen, then start voicing your opinions. We plan to give the working group 1 week to begin discussion on this=20 topic. If there is no discussion within 1 week, we will go with the=20 default position. Otherwise, if discussion commences, we're willing to=20= invest a couple of weeks to reach a consensus direction on this issue. Note: we're aware that the issue tracker is a little toasty at the=20 moment, which is why I've included the text of Karen's Oct. 26 message=20= below. thanks, Barb and Ted Begin forwarded message: > From: Karen Seo > Date: October 26, 2003 6:00:02 PM PST > To: ipsec mailingList > Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis"=20 > , kivinen@ssh.fi, kseo@bbn.com > Subject: 2401bis issue 91 -- Handling ICMP error messages > > Folks, > > Here's a description and proposed approach for handling ICMP error=20 > messages.=A0 Any mistakes/confusion are mine.=A0 Steve has again=20 > maintained plausible deniability by having out-of-town much of last=20 > week and this that prevented him from reviewing this draft :-). > > Karen > > > IPsec Issue #:=A0 91 > > Title:=A0 =A0=A0=A0=A0=A0=A0=A0 Handling ICMP error messages -- = receiving (local and > =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 transit) and generating > > > Description: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I. Receiving (local and transit) an ICMP error message -- How does an=20= > IPsec system know whether an ICMP error message comes from a trusted=20= > source or not?=A0 And what should it do in each case?=A0 Note: IKEv2=20= > supports selectors for ICMP message type and code, which can be used=20= > to classify the ICMP messages. > > =A0=A0 1. If it arrives without AH or ESP protection, what to do is > =A0=A0=A0=A0=A0 currently a matter of local policy. > > =A0=A0=A0=A0=A0 We will clarify the existing text that addresses this = case (see > =A0=A0=A0=A0=A0 proposed approach below.) > > =A0=A0 2. If an ICMP message arrives on an SA, then it must be = consistent > =A0=A0=A0=A0=A0 with the selectors for the SA, otherwise it will not = be delivered > =A0=A0=A0=A0=A0 (since it will fail the SA access control checks). In = general, > =A0=A0=A0=A0=A0 this suggests that security gateways should establish = a tunnel > =A0=A0=A0=A0=A0 mode SA between themselves to carry ICMP traffic, = something that > =A0=A0=A0=A0=A0 can be accomplished using the extant SPD parameter for = next > =A0=A0=A0=A0=A0 protocol. One might want to further restrict the types = of ICMP > =A0=A0=A0=A0=A0 messages that are authorized to traverse an SA, using = ICMP type > =A0=A0=A0=A0=A0 and code selectors. However, care still has to be = taken when > =A0=A0=A0=A0=A0 processing ICMP traffic that arrives via an SA, even = an > =A0=A0=A0=A0=A0 ICMP-specific SA. The concern is that an ICMP message = includes > =A0=A0=A0=A0=A0 what purports to be the header of the packet that = triggered that > =A0=A0=A0=A0=A0 ICMP message, but additional checks are needed to = verify that the > =A0=A0=A0=A0=A0 returned header is consistent with the address space = associated > =A0=A0=A0=A0=A0 with the SA via which the ICMP message was received. = For example, > =A0=A0=A0=A0=A0 an SG for Net A might receive an ICMP Destination = Unreachable via > =A0=A0=A0=A0=A0 a tunnel from the SG for Net B, but the triggering = packet might > =A0=A0=A0=A0=A0 refer to an address in Net C! Thus an implementation = needs to > =A0=A0=A0=A0=A0 perform consistency checks on the triggering packets = in received > =A0=A0=A0=A0=A0 ICMP traffic to detect and reject such behavior. = However, > =A0=A0=A0=A0=A0 depending on the complexity of the network topology, = such checks > =A0=A0=A0=A0=A0 may not detect all possible inconsistencies. > > =A0=A0=A0=A0=A0 By using ICMP type and code, receivers can achieve = additional > =A0=A0=A0=A0=A0 control in dealing with ICMP messages received on SAs. > > II. Generating an ICMP error message -- What should an IPsec system=20 > (host or SG) do when it generates an ICMP error message?=A0 What to do=20= > in each case is currently a matter of local policy and could depend on=20= > the type of ICMP error message. > > When it is necessary to generate an (outbound to the blackside) ICMP=20= > error message, it is desirable to transit it via an appropriate SA,=20 > for the reasons noted above. > > NOTE: Generating an ICMP message in response to an ICMP message is=20 > prohibited by the ICMP protocol specifications [ICMP -- RFC 792],=20 > [ICMPv6 -- RFC 2463]. > > NOTE: ICMP messages that are not *error* messages SHOULD be handled=20 > like any other messages. > > Proposed approach: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > A. Update the 2401bis text to say: > > "An ICMP message not protected by AH or ESP is unauthenticated and its=20= > processing and/or forwarding may result in denial or degradation of=20 > service.=A0 This suggests that, in general, it would be desirable to=20= > ignore such messages. However, many ICMP messages will be received by=20= > hosts or security gateways from unauthenticated sources, e.g., routers=20= > in the public Internet. Ignoring these ICMP messages can degrade=20 > service, e.g., because of a failure to process PMTU message and=20 > redirection messages. Thus there is also a motivation for accepting=20 > and acting upon unauthenticated ICMP messages. To accommodate both=20 > ends of this spectrum, a compliant IPsec implementation MUST permit a=20= > local administrator to configure an IPsec implementation to accept or=20= > reject unauthenticated ICMP traffic.=A0 This control MUST be at the=20 > granularity of ICMP type and MAY be at the granularity of ICMP type=20 > and code.=A0 Additionally, an implementation SHOULD incorporate=20 > mechanisms and parameters for dealing with such traffic. For example,=20= > there could be the ability to establish a minimum PMTU for traffic=20 > (perhaps on a per destination basis), to prevent receipt of an=20 > unauthenticated ICMP from setting the PMTU to a trivial size."=A0 [See=20= > issue 78 for PMTU minimum size recommendations] > > "A mechanism SHOULD be provided to allow an administrator to cause=20 > ICMP messages (selected, all, none) to be logged as an aid to problem=20= > diagnosis." > > Processing ICMP messages (receiving (local and transit) and = generating) > > Consider a topology along the lines of: > > =A0 > =A0=A0=A0=A0=A0 Host=A0=A0=A0 SG=A0=A0=A0=A0=A0=A0=A0=A0 Rtr=A0=A0=A0=A0= =A0=A0=A0=A0 SG=A0=A0=A0=A0 Host > =A0=A0=A0=A0=A0=A0=A0 X =3D=3D=3D A=A0 =3D=3D=3D=3D=3D=3D=3D=3D B=A0 = =3D=3D=3D=3D=3D=3D=3D=3D C =3D=3D=3D Y > > =A0=A0=A0=A0=A0=A0 <------><----------------------><-----> > =A0=A0=A0=A0=A0=A0=A0=A0 Red=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Black=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Red > > red =3D traffic within security perimeter, could be protected by an SA=20= > or not > black =3D traffic outside security perimeter, could be protected by an=20= > SA or not > > > The IPsec implementation at A or C MUST be able to handle the=20 > following cases (tunnel indicates IPsec protection): > > > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 black=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0 red > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ----------|---------- > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 local=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 /=A0=A0=A0=A0=A0= |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0 (1) ICMP ---------------------------------> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 \=A0=A0=A0=A0=A0= |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0 \=A0 = ------------------- > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 = \-------tunnel--------> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 = ------------------- > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0 local=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 \ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <----------------------<---------- = (2) ICMP > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 /=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ________________=A0 /=A0=A0=A0=A0= | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <-------tunnel-----/=A0=A0=A0=A0=A0 = | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ----------------=A0=A0=A0=A0=A0=A0= =A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0 local=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ________________=A0 /=A0=A0=A0=A0= | > =A0=A0 (3) ICMP -------tunnel----->-------------->=A0=A0 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ----------------=A0 \=A0=A0=A0=A0= | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 \=A0 ________ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0 \--tunnel--> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0 -------- > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0 <--------- trigger packet > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 / > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0 /=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0 ICMP ---------> (4) > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0 \=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 \=A0 ________ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0 \--tunnel--> (4) > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0 -------- > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ____________=A0=A0=A0=A0= =A0=A0=A0=A0 | > =A0=A0=A0 trigger pkt ----tunnel---->=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ------------=A0 = \=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0 \=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0 (5) <------------------ ICMP=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 /=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ________________=A0 /=A0=A0=A0=A0= | > =A0=A0=A0=A0=A0=A0=A0 (5) <-------tunnel-----/=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ----------------=A0=A0=A0=A0=A0=A0= =A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0 trigger pkt ------------->=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0 \=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0 \=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0 (6) <------------------ ICMP=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 /=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ________________=A0 /=A0=A0=A0=A0= | > =A0=A0=A0=A0=A0=A0=A0 (6) <-------tunnel-----/=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ----------------=A0=A0=A0=A0=A0=A0= =A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ----------|--------- > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 | > > I Receiving an ICMP error message destined for local delivery or=20 > transit service > > (1) An ICMP packet is received without IPsec protection from the black=20= > side, i.e., it is unauthenticated and from an untrusted source.=A0 In=20= > this case, the IPsec system: > > =A0=A0 (a) MUST perform standard IPsec processing on the ICMP packet = -- > =A0=A0=A0=A0=A0=A0 with possible results of DROP, BYPASS, or IPsec = required. > > =A0=A0 (b) If the ICMP packet passes (a), then additional = ICMP-specific > =A0=A0=A0=A0=A0=A0 checks SHOULD be performed to: > > =A0=A0=A0=A0=A0=A0 i. verify that the IP addresses in the header of = the triggering > =A0=A0=A0=A0=A0=A0=A0=A0=A0 packet are consistent with the address = space associated with > =A0=A0=A0=A0=A0=A0=A0=A0=A0 the SPD entry that matches the selectors = of the ICMP message. > =A0=A0=A0=A0=A0=A0=A0=A0=A0 If the protocol and ports information is = available, these > =A0=A0=A0=A0=A0=A0=A0=A0=A0 SHOULD also be checked for consistency = with the SPD entry. > > =A0=A0=A0=A0=A0 ii. ensure, for ICMP "packet too big" messages, a = minimum PMTU > =A0=A0=A0=A0=A0=A0=A0=A0=A0 for IPv4 and IPv6 traffic (perhaps on a = per destination > =A0=A0=A0=A0=A0=A0=A0=A0=A0 basis), to prevent receipt of an = unauthenticated ICMP from > =A0=A0=A0=A0=A0=A0=A0=A0=A0 setting the PMTU to a trivial size.=A0 = Note: This is done at > =A0=A0=A0=A0=A0=A0=A0=A0=A0 this step even if the ICMP packet is not = destined locally, on > =A0=A0=A0=A0=A0=A0=A0=A0=A0 the assumption that the destination host = may not be running > =A0=A0=A0=A0=A0=A0=A0=A0=A0 IPsec and hence this IPsec system should = do this check. > > =A0=A0 (c) If the ICMP packet passes (b), then > > =A0=A0=A0=A0=A0=A0 i. if the ICMP message is destined locally, it is = passed along > =A0=A0=A0=A0=A0=A0=A0=A0=A0 for ICMP processing. > > =A0=A0=A0=A0=A0 ii. if the ICMP message is transiting this system, = standard > =A0=A0=A0=A0=A0=A0=A0=A0=A0 IPsec processing is done and the message = is handled as > =A0=A0=A0=A0=A0=A0=A0=A0=A0 defined by the SPD -- DROP'd, BYPASS'd or = provided with > =A0=A0=A0=A0=A0=A0=A0=A0=A0 IPsec protection. > > > (2) An ICMP packet is received without IPsec protection from the red=20= > side, i.e., is unauthenticated but from a trusted source.=A0 In this=20= > case, the IPsec system: > > =A0=A0 (a) MUST perform standard IPsec processing on the ICMP packet = --=20 > with > =A0=A0=A0=A0=A0=A0 possible results of DROP, BYPASS, or IPsec = required. > > =A0=A0 (b) If the ICMP packet passes (a) and is destined locally, > > =A0=A0=A0=A0=A0=A0 i. SHOULD perform ICMP checks to: > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 - verify that the IP addresses in the = header of the=20 > triggering > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 packet are consistent with the = address space associated=20 > with > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the SPD entry that matches the = selectors of the ICMP=20 > message. > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If the protocol and ports = information is available, these > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SHOULD also be checked for = consistency with the SPD entry. > > =A0=A0=A0=A0=A0=A0=A0=A0=A0 - ensure, for ICMP "packet too big" = messages, a minimum PMTU > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 for IPv4 or IPv6 traffic (perhaps on = a per destination > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 basis), to prevent receipt of an = unauthenticated ICMP from > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 setting the PMTU to a trivial size.=A0= Note: This is done at > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 this step even if the ICMP packet is = not destined locally, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 on the assumption that the = destination host may not be > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 running IPsec and hence this IPsec = system should do this > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 check. > > =A0=A0=A0=A0=A0 ii. If the ICMP packet passes (i), then it is passed = along for > =A0=A0=A0=A0=A0=A0=A0=A0=A0 ICMP processing. > > =A0=A0=A0 (c) If the ICMP packet passes (a) and is transiting this = system, > =A0=A0=A0=A0=A0=A0=A0 then the ICMP checks are left to the destination = IPsec system, > =A0=A0=A0=A0=A0=A0=A0 standard IPsec processing is done and the = message is handled > =A0=A0=A0=A0=A0=A0=A0 as defined by the SPD -- DROP'd, BYPASS'd or = provided with=20 > IPsec > =A0=A0=A0=A0=A0=A0=A0 protection.=A0 In the last case, there are two = options: > > =A0=A0=A0=A0=A0=A0=A0 i. a tunnel set up just for ICMP messages. > =A0=A0=A0=A0=A0=A0 ii. an SA whose selectors include those of the ICMP = message. > > > (3) An ICMP packet is received with IPsec protection from the black=20 > side, i.e., is authenticated. Same action as for case (1). > > II. Generating ICMP packets > > The following cases assume that the triggering packet has passed=20 > standard IPsec checks, i.e., not been DROP'd by policy. > > (4) An ICMP packet is being generated by the IPsec system in response=20= > to a packet which came from the red side, i.e., unauthenticated but=20 > from a trusted source.=A0 In this case, the IPsec system MUST perform=20= > standard IPsec processing on the ICMP error message.=A0=A0 Possible=20 > actions are DROP, BYPASS or provide with IPsec protection.=A0 In the=20= > last case there are two options: > > =A0=A0=A0 (a) send the ICMP packet on an SA set up just for ICMP = messages. > =A0=A0=A0 (b) send the ICMP packet on an SA whose selectors include = those of > =A0=A0=A0=A0=A0=A0=A0 the ICMP message. > > (5) An ICMP packet is being generated by the IPsec system (red side)=20= > in response to a packet which came from the black side and was=20 > protected by IPsec, i.e., authenticated.=A0 Same action as for case = (4). > > (6) An ICMP packet is being generated by the IPsec system (red side)=20= > in response to a packet which came from the black side and was=20 > unprotected by IPsec, i.e., unauthenticated and from an untrusted=20 > source. Same action as for case (4). > > > B. Add to Security Considerations: > > NOTE: SPD entries for ICMP error messages SHOULD mandate security as=20= > strong as or stronger than the security required for traffic that=20 > might trigger an ICMP error message. > > > C. Update the selector and SPD sections to reflect IKEv2's support for=20= > ICMP message type and code -- Add ICMP message type and code to the=20 > list of selectors supported in the SPD and in IKEv2 to enable better=20= > IPsec policy definition for the handling of the different kinds of=20 > ICMP error messages when generating or receiving (local or transit)=20 > ICMP error messages. There should be one selector for the pair=20 > , not two selectors.=A0 (I got this wrong in the recently=20= > distributed 2401bis draft.) > > Thank you, > Karen --Apple-Mail-2-1031841482 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks, We're down to what we believe is the last remaining issue for 2401bis. Once we come to closure on this issue and changes are made to the document, we think we'll be finished with the work on 2401bis. In the original 2401 there was text describing the handling of path MTU but the handling of other unprotected ICMP messages was left as a local matter. On October 26, Karen posted the message included below that proposes a more complex algorithm for handling ICMP messages.=20 There has been little discussion to date on this so Ted and I would like to propose the following: 1. Default position: if no one is interested in discussing this issue, we fall back to the text as it existed in 2401 which covers path MTU but is silent on other types of unprotected ICMP messages. 2. If you believe there are deficiencies or ambiguities in the original text on path MTU in 2401 please speak up! 3. If you feel we should take a different approach, such as that proposed by Karen, then start voicing your opinions. We plan to give the working group 1 week to begin discussion on this topic. If there is no discussion within 1 week, we will go with the default position. Otherwise, if discussion commences, we're willing to invest a couple of weeks to reach a consensus direction on this issue. Note: we're aware that the issue tracker is a little toasty at the moment, which is why I've included the text of Karen's Oct. 26 message below. thanks, Barb and Ted Begin forwarded message: 0000,0000,0000From: Karen Seo < 0000,0000,0000Date: October 26, 2003 6:00:02 PM PST 0000,0000,0000To: ipsec mailingList < 0000,0000,0000Cc: byfraser@cisco.com, tytso@mit.edu, "Angelos D. Keromytis" <, kivinen@ssh.fi, kseo@bbn.com 0000,0000,0000Subject: 2401bis issue 91 -- Handling ICMP error messages Folks, Here's a description and proposed approach for handling ICMP error messages.=A0 Any mistakes/confusion are mine.=A0 Steve has again maintained plausible deniability by having out-of-town much of last week and this that prevented him from reviewing this draft :-). Karen IPsec Issue #:=A0 91 Title:=A0 =A0=A0=A0=A0=A0=A0=A0 Handling ICMP error messages -- = receiving (local and =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 transit) and generating Description: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I. Receiving (local and transit) an ICMP error message -- How does an IPsec system know whether an ICMP error message comes from a trusted source or not?=A0 And what should it do in each case?=A0 Note: IKEv2 supports selectors for ICMP message type and code, which can be used to classify the ICMP messages. =A0=A0 1. If it arrives without AH or ESP protection, what to do is =A0=A0=A0=A0=A0 currently a matter of local policy. =A0=A0=A0=A0=A0 We will clarify the existing text that addresses this = case (see =A0=A0=A0=A0=A0 proposed approach below.) =A0=A0 2. If an ICMP message arrives on an SA, then it must be = consistent =A0=A0=A0=A0=A0 with the selectors for the SA, otherwise it will not be = delivered =A0=A0=A0=A0=A0 (since it will fail the SA access control checks). In = general, =A0=A0=A0=A0=A0 this suggests that security gateways should establish a = tunnel =A0=A0=A0=A0=A0 mode SA between themselves to carry ICMP traffic, = something that =A0=A0=A0=A0=A0 can be accomplished using the extant SPD parameter for = next =A0=A0=A0=A0=A0 protocol. One might want to further restrict the types = of ICMP =A0=A0=A0=A0=A0 messages that are authorized to traverse an SA, using = ICMP type =A0=A0=A0=A0=A0 and code selectors. However, care still has to be taken = when =A0=A0=A0=A0=A0 processing ICMP traffic that arrives via an SA, even an =A0=A0=A0=A0=A0 ICMP-specific SA. The concern is that an ICMP message = includes =A0=A0=A0=A0=A0 what purports to be the header of the packet that = triggered that =A0=A0=A0=A0=A0 ICMP message, but additional checks are needed to verify = that the =A0=A0=A0=A0=A0 returned header is consistent with the address space = associated =A0=A0=A0=A0=A0 with the SA via which the ICMP message was received. For = example, =A0=A0=A0=A0=A0 an SG for Net A might receive an ICMP Destination = Unreachable via =A0=A0=A0=A0=A0 a tunnel from the SG for Net B, but the triggering = packet might =A0=A0=A0=A0=A0 refer to an address in Net C! Thus an implementation = needs to =A0=A0=A0=A0=A0 perform consistency checks on the triggering packets in = received =A0=A0=A0=A0=A0 ICMP traffic to detect and reject such behavior. = However, =A0=A0=A0=A0=A0 depending on the complexity of the network topology, = such checks =A0=A0=A0=A0=A0 may not detect all possible inconsistencies. =A0=A0=A0=A0=A0 By using ICMP type and code, receivers can achieve = additional =A0=A0=A0=A0=A0 control in dealing with ICMP messages received on SAs. II. Generating an ICMP error message -- What should an IPsec system (host or SG) do when it generates an ICMP error message?=A0 What to do in each case is currently a matter of local policy and could depend on the type of ICMP error message. When it is necessary to generate an (outbound to the blackside) ICMP error message, it is desirable to transit it via an appropriate SA, for the reasons noted above. NOTE: Generating an ICMP message in response to an ICMP message is prohibited by the ICMP protocol specifications [ICMP -- RFC 792], [ICMPv6 -- RFC 2463]. NOTE: ICMP messages that are not *error* messages SHOULD be handled like any other messages. Proposed approach: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A. Update the 2401bis text to say: "An ICMP message not protected by AH or ESP is unauthenticated and its processing and/or forwarding may result in denial or degradation of service.=A0 This suggests that, in general, it would be desirable to ignore such messages. However, many ICMP messages will be received by hosts or security gateways from unauthenticated sources, e.g., routers in the public Internet. Ignoring these ICMP messages can degrade service, e.g., because of a failure to process PMTU message and redirection messages. Thus there is also a motivation for accepting and acting upon unauthenticated ICMP messages. To accommodate both ends of this spectrum, a compliant IPsec implementation MUST permit a local administrator to configure an IPsec implementation to accept or reject unauthenticated ICMP traffic.=A0 This control MUST be at the granularity of ICMP type and MAY be at the granularity of ICMP type and code.=A0 Additionally, an implementation SHOULD incorporate mechanisms and parameters for dealing with such traffic. For example, there could be the ability to establish a minimum PMTU for traffic (perhaps on a per destination basis), to prevent receipt of an unauthenticated ICMP from setting the PMTU to a trivial size."=A0 [See issue 78 for PMTU minimum size recommendations] "A mechanism SHOULD be provided to allow an administrator to cause ICMP messages (selected, all, none) to be logged as an aid to problem diagnosis." Processing ICMP messages (receiving (local and transit) and generating) Consider a topology along the lines of: =A0 =A0=A0=A0=A0=A0 Host=A0=A0=A0 SG=A0=A0=A0=A0=A0=A0=A0=A0 Rtr=A0=A0=A0=A0=A0= =A0=A0=A0 SG=A0=A0=A0=A0 Host =A0=A0=A0=A0=A0=A0=A0 X =3D=3D=3D A=A0 =3D=3D=3D=3D=3D=3D=3D=3D B=A0 = =3D=3D=3D=3D=3D=3D=3D=3D C =3D=3D=3D Y =A0=A0=A0=A0=A0=A0 <<------><<----------------------><<-----> =A0=A0=A0=A0=A0=A0=A0=A0 Red=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Black=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Red red =3D traffic within security perimeter, could be protected by an SA or not black =3D traffic outside security perimeter, could be protected by an SA or not The IPsec implementation at A or C MUST be able to handle the following cases (tunnel indicates IPsec protection): =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 black=A0=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0 red =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ----------|---------- =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 local=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 /=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0 (1) ICMP ---------------------------------> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 \=A0=A0=A0=A0=A0 = |=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0 \=A0 = ------------------- =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0 = \-------tunnel--------> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 = ------------------- =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0 local=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 \ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <<----------------------<<---------- = (2) ICMP =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 /=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ________________=A0 /=A0=A0=A0=A0= | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <<-------tunnel-----/=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ----------------=A0=A0=A0=A0=A0=A0= =A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0 local=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ________________=A0 /=A0=A0=A0=A0 = | =A0=A0 (3) ICMP -------tunnel----->-------------->=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ----------------=A0 \=A0=A0=A0=A0= | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 \=A0 ________ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0 \--tunnel--> =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0 -------- =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0 <<--------- trigger packet =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 / =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0 /=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0 ICMP ---------> (4) =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0 \=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 \=A0 ________ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0 \--tunnel--> (4) =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0 -------- =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ____________=A0=A0=A0=A0=A0= =A0=A0=A0 | =A0=A0=A0 trigger pkt ----tunnel---->=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ------------=A0 \=A0=A0=A0= =A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0 \=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0 (5) <<------------------ ICMP=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 /=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ________________=A0 /=A0=A0=A0=A0 = | =A0=A0=A0=A0=A0=A0=A0 (5) <<-------tunnel-----/=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ----------------=A0=A0=A0=A0=A0=A0= =A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0 trigger pkt ------------->=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0 \=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0 \=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0 (6) <<------------------ ICMP=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0 /=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ________________=A0 /=A0=A0=A0=A0 = | =A0=A0=A0=A0=A0=A0=A0 (6) <<-------tunnel-----/=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ----------------=A0=A0=A0=A0=A0=A0= =A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0 |=A0=A0=A0=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = ----------|--------- =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 | I Receiving an ICMP error message destined for local delivery or transit service (1) An ICMP packet is received without IPsec protection from the black side, i.e., it is unauthenticated and from an untrusted source.=A0 In this case, the IPsec system: =A0=A0 (a) MUST perform standard IPsec processing on the ICMP packet -- =A0=A0=A0=A0=A0=A0 with possible results of DROP, BYPASS, or IPsec = required. =A0=A0 (b) If the ICMP packet passes (a), then additional ICMP-specific =A0=A0=A0=A0=A0=A0 checks SHOULD be performed to: =A0=A0=A0=A0=A0=A0 i. verify that the IP addresses in the header of the = triggering =A0=A0=A0=A0=A0=A0=A0=A0=A0 packet are consistent with the address space = associated with =A0=A0=A0=A0=A0=A0=A0=A0=A0 the SPD entry that matches the selectors of = the ICMP message. =A0=A0=A0=A0=A0=A0=A0=A0=A0 If the protocol and ports information is = available, these =A0=A0=A0=A0=A0=A0=A0=A0=A0 SHOULD also be checked for consistency with = the SPD entry. =A0=A0=A0=A0=A0 ii. ensure, for ICMP "packet too big" messages, a = minimum PMTU =A0=A0=A0=A0=A0=A0=A0=A0=A0 for IPv4 and IPv6 traffic (perhaps on a per = destination =A0=A0=A0=A0=A0=A0=A0=A0=A0 basis), to prevent receipt of an = unauthenticated ICMP from =A0=A0=A0=A0=A0=A0=A0=A0=A0 setting the PMTU to a trivial size.=A0 Note: = This is done at =A0=A0=A0=A0=A0=A0=A0=A0=A0 this step even if the ICMP packet is not = destined locally, on =A0=A0=A0=A0=A0=A0=A0=A0=A0 the assumption that the destination host may = not be running =A0=A0=A0=A0=A0=A0=A0=A0=A0 IPsec and hence this IPsec system should do = this check. =A0=A0 (c) If the ICMP packet passes (b), then =A0=A0=A0=A0=A0=A0 i. if the ICMP message is destined locally, it is = passed along =A0=A0=A0=A0=A0=A0=A0=A0=A0 for ICMP processing. =A0=A0=A0=A0=A0 ii. if the ICMP message is transiting this system, = standard =A0=A0=A0=A0=A0=A0=A0=A0=A0 IPsec processing is done and the message is = handled as =A0=A0=A0=A0=A0=A0=A0=A0=A0 defined by the SPD -- DROP'd, BYPASS'd or = provided with =A0=A0=A0=A0=A0=A0=A0=A0=A0 IPsec protection. (2) An ICMP packet is received without IPsec protection from the red side, i.e., is unauthenticated but from a trusted source.=A0 In this case, the IPsec system: =A0=A0 (a) MUST perform standard IPsec processing on the ICMP packet -- with =A0=A0=A0=A0=A0=A0 possible results of DROP, BYPASS, or IPsec required. =A0=A0 (b) If the ICMP packet passes (a) and is destined locally, =A0=A0=A0=A0=A0=A0 i. SHOULD perform ICMP checks to: =A0=A0=A0=A0=A0=A0=A0=A0=A0 - verify that the IP addresses in the header = of the triggering =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 packet are consistent with the address = space associated with =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 the SPD entry that matches the = selectors of the ICMP message. =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If the protocol and ports information = is available, these =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SHOULD also be checked for consistency = with the SPD entry. =A0=A0=A0=A0=A0=A0=A0=A0=A0 - ensure, for ICMP "packet too big" = messages, a minimum PMTU =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 for IPv4 or IPv6 traffic (perhaps on a = per destination =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 basis), to prevent receipt of an = unauthenticated ICMP from =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 setting the PMTU to a trivial size.=A0 = Note: This is done at =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 this step even if the ICMP packet is = not destined locally, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 on the assumption that the destination = host may not be =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 running IPsec and hence this IPsec = system should do this =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 check. =A0=A0=A0=A0=A0 ii. If the ICMP packet passes (i), then it is passed = along for =A0=A0=A0=A0=A0=A0=A0=A0=A0 ICMP processing. =A0=A0=A0 (c) If the ICMP packet passes (a) and is transiting this = system, =A0=A0=A0=A0=A0=A0=A0 then the ICMP checks are left to the destination = IPsec system, =A0=A0=A0=A0=A0=A0=A0 standard IPsec processing is done and the message = is handled =A0=A0=A0=A0=A0=A0=A0 as defined by the SPD -- DROP'd, BYPASS'd or = provided with IPsec =A0=A0=A0=A0=A0=A0=A0 protection.=A0 In the last case, there are two = options: =A0=A0=A0=A0=A0=A0=A0 i. a tunnel set up just for ICMP messages. =A0=A0=A0=A0=A0=A0 ii. an SA whose selectors include those of the ICMP = message. (3) An ICMP packet is received with IPsec protection from the black side, i.e., is authenticated. Same action as for case (1). II. Generating ICMP packets The following cases assume that the triggering packet has passed standard IPsec checks, i.e., not been DROP'd by policy. (4) An ICMP packet is being generated by the IPsec system in response to a packet which came from the red side, i.e., unauthenticated but from a trusted source.=A0 In this case, the IPsec system MUST perform standard IPsec processing on the ICMP error message.=A0=A0 Possible actions are DROP, BYPASS or provide with IPsec protection.=A0 In the last case there are two options: =A0=A0=A0 (a) send the ICMP packet on an SA set up just for ICMP = messages. =A0=A0=A0 (b) send the ICMP packet on an SA whose selectors include = those of =A0=A0=A0=A0=A0=A0=A0 the ICMP message. (5) An ICMP packet is being generated by the IPsec system (red side) in response to a packet which came from the black side and was protected by IPsec, i.e., authenticated.=A0 Same action as for case (4). (6) An ICMP packet is being generated by the IPsec system (red side) in response to a packet which came from the black side and was unprotected by IPsec, i.e., unauthenticated and from an untrusted source. Same action as for case (4). B. Add to Security Considerations: NOTE: SPD entries for ICMP error messages SHOULD mandate security as strong as or stronger than the security required for traffic that might trigger an ICMP error message. C. Update the selector and SPD sections to reflect IKEv2's support for ICMP message type and code -- Add ICMP message type and code to the list of selectors supported in the SPD and in IKEv2 to enable better IPsec policy definition for the handling of the different kinds of ICMP error messages when generating or receiving (local or transit) ICMP error messages. There should be one selector for the pair <, not two selectors.=A0 (I got this wrong in the recently distributed 2401bis draft.) Thank you, Karen = --Apple-Mail-2-1031841482-- --===============0825482496== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0825482496==-- From ipsec-bounces@ietf.org Tue Jun 8 20:10:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12435 for ; Tue, 8 Jun 2004 20:10:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXqUb-0004D6-4i; Tue, 08 Jun 2004 19:58:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXqF2-0005Qa-3w for ipsec@megatron.ietf.org; Tue, 08 Jun 2004 19:42:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09993 for ; Tue, 8 Jun 2004 19:42:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXqEz-0003mC-Na for ipsec@ietf.org; Tue, 08 Jun 2004 19:42:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXqE0-0002vU-00 for ipsec@ietf.org; Tue, 08 Jun 2004 19:41:49 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BXqCp-0001EL-00 for ipsec@ietf.org; Tue, 08 Jun 2004 19:40:35 -0400 Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i58Ndx7X007351; Tue, 8 Jun 2004 19:40:00 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <784A6DAC-B96B-11D8-A46B-000A95E07B78@cisco.com> References: <784A6DAC-B96B-11D8-A46B-000A95E07B78@cisco.com> Date: Tue, 8 Jun 2004 19:48:11 -0400 To: ipsec@ietf.org From: Karen Seo Subject: Re: [Ipsec] Issue 91 - ICMP error message handling Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: kseo@bbn.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Folks, Please note that we sent the following message on April 13 with subsequent exchanges with: - Mark Duffy about case 2 (whether or not the receiver should be doing the kind of checking we propose). - Rich Graveman re: clarifying that we believe this proposal would work with ICMPv6. - Mohan Parthasarathy re: clarifying what we meant by checking to see if the selector fields in the enclosed packet match those of an existing SA, etc. Karen >X-Sender: kseo@po2.bbn.com >Date: Tue, 13 Apr 2004 19:54:27 -0400 >To: ipsec@lists.tislabs.com >From: Karen Seo >Subject: 2401bis -- Issue 91 -- handling ICMP error messages >Cc: kseo@bbn.com >X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) >Status: > >Folks, > >Following up on a discussion at the end of February/early March re: >how to handle ICMP traffic... We were talking about how to carry >ICMP traffic via an SA between two IPsec implementations. This did >NOT involve ICMP traffic that might be bypassed or consumed on the >ciphertext side of the IPsec boundary. Also, there are two >categories of ICMP traffic -- error messages (e.g., type = >destination unreachable) and non-error messages (e.g., type = echo). >This discussion covered ONLY error messages. Non-error ICMP >messages should be explicitly accounted for in the SPD. > >Two approaches were discussed: > 1. The sender of ICMP error message uses the (return) SA for the > packet that resulted in the ICMP error message. In this > discussion, the SA was assumed to not be configured to > carry ICMP error messages. > 2. The sender of ICMP error message uses an SA that is configured > to handle ICMP error messages of the relevant type and code. > Note that while this case was viewed in the discussion > as being a different/separate SA from case 1 above, this SA > could be the same as case 1, if that SA were configured to > carry ICMP error taffic (in addition to user traffic). Note > also that the ICMP Type and Code for this SA could be set to > ANY, if there is no need to restrict the type of ICMP traffic > that it is allowed to carry. > >Here's what needs to happen at the sender and receiver, to make each >case work: > For case 1: > a. The sender notices that the packet is an ICMP error > message and diverts it to slow path processing. It > examines the enclosed packet (or portion thereof), > swaps the source and destination addresses and > ports, and performs an SPD lookup to find the SA > to use. Then the ICMP packet is sent via the > the selected SA. > > b. The receiver notices that a packet has failed the > selector check (e.g., the source address or the > protocol does not match). The packet is diverted > to slow path processing where it is observed to be > an ICMP error message and the enclosed packet > is examined. The source and destination addresses > and ports are swapped and matched against the > selectors for the SA via which the ICMP packet was > received. If they match, the ICMP message is passed > on for further processing, e.g., PMTU check. > > This case assumes that no further access control checks > are desired for the ICMP packet. > > For case 2: > a. The sender extracts ICMP type and code and does an > SPD lookup to find an appropriate SA. (The Sender > only does fast path processing.) > b. The receiver processes the ICMP packet on the SA > via which it was received, verifying that the ICMP > type and code of the message match the selectors > for the SA. If they do, then the receiver passes > the ICMP message to slow path processing. The > selectors of the enclosed packet are extracted > and matched against the SPD-S cache, to ensure > that the enclosed packet is consistent with its > source. If they do, the ICMP message is passed > along for further processing, e.g., PMTU check. > (The receiver does both fast path and slow path > processing.) > > Note that an ICMP packet may arrive on an SA unrelated > to the SA used for the triggering packet. The sender > will use the first SPD or SPD-S cache entry that it > comes to that is configured to carry ICMP traffic of > the given type and code. Even if the SA for the > triggering packet is configured to carry ICMP traffic, > there may be an earlier entry in the SPD that matches > the ICMP message's type and code. So one has > to search the outbound SPD-S cache to verify whether > or not there's an extant SA for the enclosed > (triggering) packet. > >Proposed approach > To simplify the processing done by the Sender (of the ICMP > message) to find the SA to use for sending the ICMP message > and to support access control checks on the ICMP messages > (using ICMP Message Type and Code) by the Receiver, > we propose to use the second approach. > > Note: In the second approach, there is no requirement that > the SA used for the ICMP message be dedicated only to ICMP > messages. To minimize the number of SAs between two IPsec > systems, an administrator may wish to configure the SPD such > that the ICMP messages may be combined with other traffic, > i.e., by specifying SPD entries that carry both normal > traffic and ICMP traffic. > >Comments? Thank you, >Karen > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 8 21:09:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15396 for ; Tue, 8 Jun 2004 21:09:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXrRc-0002tY-3a; Tue, 08 Jun 2004 20:59:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXr6P-0003tK-0w for ipsec@megatron.ietf.org; Tue, 08 Jun 2004 20:38:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14253 for ; Tue, 8 Jun 2004 20:37:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXr6N-0007Zb-7J for ipsec@ietf.org; Tue, 08 Jun 2004 20:37:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXr5U-0006id-00 for ipsec@ietf.org; Tue, 08 Jun 2004 20:37:06 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BXr4P-00054D-00 for ipsec@ietf.org; Tue, 08 Jun 2004 20:35:57 -0400 Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i590ZR7X008764; Tue, 8 Jun 2004 20:35:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <16572.35115.135684.778512@fireball.kivinen.iki.fi> References: <16572.35115.135684.778512@fireball.kivinen.iki.fi> Date: Tue, 8 Jun 2004 20:43:39 -0400 To: Tero Kivinen From: Karen Seo Subject: Re: [Ipsec] Comments to the draft-ietf-ipsec-rfc2401bis-02.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero, Thanks for your hard work and feedback. Steve's back in the office in a few days and I'll talk to him then about your comments. Karen > > 4.4 Major IPsec Databases >> ... >> Multiple Separate IPsec Contexts >> ... >> For example, a security gateway that provides VPN service to >> multiple customers will be able to associate each customer~Os > ^^^^ >I assume it should be ' there instead of that "~O". > >> traffic with the correct VPN. >> ... >> 4.4.1.1 Selectors >> ... >> * If the Next Layer Protocol uses two ports (e.g., TCP, UDP, SCTP, >> these selectors is a list of ranges of values. Note that the >> Local and Remote ports may not be available in the case of >> receipt of a fragmented packet, thus a value of OPAQUE also MUST >> be supported. Note: In a non-initial fragment, port values will >> not be available. If a port selector specifies a value other than >> ANY or OPAQUE, it cannot match packets that are non-initial >> fragments. If the SA requires a port value other than ANY or >> OPAQUE, an arriving fragment without ports MUST be discarded. > >This thing depends on the fragmentation handling. Support of OPAQUE >should not be mandatory, as it is only needed to support to one of the >fragmentation handling proposals, and that one is most likely going to >be MAY or SHOULD, not MUST. > >I propose removing everything after ", thus a value of OPAQUE ..." and >replace it with reference to section 7. > >> * If the Next Layer Protocol is a Mobility Header, then there is a >> selector for IPv6 Mobility Header Message Type (MH type) [Mobip]. >> This is an 8-bit value that identifies a particular mobility >> message. Note that the MH type may not be available in the case >> of receipt of a fragmented packet, thus a value of OPAQUE MUST be >> supported. > >Again makeing the OPAQUE mandatory, where it might not be needed. >Propose removing everyhing after ", thus a value...". > >> * If the Next Layer Protocol value is ICMP then there is a 16-bit >> selector for the ICMP message type and code. The message type is >> a single 8-bit value, which defines the type of an ICMP message, >> or ANY. The ICMP code is a single 8-bit value that defines a >> specific subtype for an ICMP message. The message type is placed >> in the most significant 8 bits of the 16-bit selector and the >> code is placed in the least significant 8 bits. This 16-bit >> selector can contain a single type and a range of codes, a single >> type and ANY code, ANY type and ANY code. Given a policy entry >> with a range of Types (T-start to T-end) and a range of Codes (C- >> start to C-end), and an ICMP packet with Type t and Code c, an >> implementation MUST test for a match using >> >> (T-start*256) + C-start <= (t*256) + c <= (T-end*256) + C-end >> >> Note that the ICMP message type and code may not be available in >> the case of receipt of a fragmented packet, thus a value of >> OPAQUE MUST be supported. > >Same here. > >> ... > > 4.4.1.2 Structure of an SPD entry >> ... >> management interface with the SPD selector "Name".) If the reserved, >> symbolic selector value OPAQUE or ANY is employed for a given >> selector type, only it may appear in the list for that selector, and >> it must appear only once in the list for that selector. Note that >> ANY and OPAQUE are local syntax conventions -D IKEv2 negotiates these > ^^^^ >Again wierd characters there again... > >> ... >> 4.4.2 Security Association Database (SAD) >> ... >> If the protocol is one that has two ports then there will be >> selectors for both Local and Remote ports. >> >> Value in >> Triggering Resulting SAD > > Selector SPD Entry PFP Packet Entry >> -------- ---------------- --- ------------ -------------- >> loc port list of ranges 0 src port "s" list of ranges >> or ANY or ANY >> list of ranges 0 no src port discard packet >> or ANY > ^^^^^^^^^^^^^ > >This again depends on the fragmentation processing. > >> OPAQUE 0 not avail. OPAQUE >> OPAQUE 1 not avail. *** >> list of ranges 1 src port "s" "s" >> or ANY >> list of ranges 1 no src port discard packet >> or ANY >> >> rem port list of ranges 0 dst port "d" list of ranges >> or ANY or ANY >> list of ranges 0 no dst port discard packet >> or ANY > >Same here. > >> OPAQUE 0 not avail. OPAQUE >> OPAQUE 1 not avail. *** >> list of ranges 1 dst port "d" "d" >> or ANY >> list of ranges 1 no dst port discard packet >> or ANY >> >> If the protocol is mobility header then there will be a selector for >> mh type. >> >> Value in >> Triggering Resulting SAD >> Selector SPD Entry PFP Packet Entry >> -------- ---------------- --- ------------ -------------- >> mh type list of ranges 0 mh type "T" list of ranges >> or ANY or ANY >> list of ranges 0 no mh type discard packet >> or ANY > >Same here. > >> OPAQUE 0 not avail. OPAQUE >> OPAQUE 1 not avail. *** >> list of ranges 1 mh type "T" "T" >> or ANY >> list of ranges 1 no mh type discard packet >> or ANY > >and here. Hmm, I assume also in the ICMP case. > >> ... >> 4.5.2 Automated SA and Key Management >> ... >> The default automated key management protocol selected for use with >> IPsec is IKEv2 [Kau04]. Other automated SA management protocols MAY >> be employed. > >We should add comment about IKEv1 too. Something like saying that this >document assumes some things from key management protocol which cannot >be done in IKEv1 (ranges, new notifications etc), but limited support >of this document can also be done using IKEv1 for compatibility >reasons. > >> ... >> 4.5.3 Locating a Security Gateway >> >> This section discusses issues relating to how a host learns about the >> existence of relevant security gateways and once a host has contacted >> these security gateways, how it knows that these are the correct >> security gateways. The details of where the required information is >> stored is a local matter, but the Peer Authorization Database >> described in Section 4.4 is the most likely candidate. >> >> Consider a situation in which a remote host (H1) is using the > >I propose changing H1 to SH1, meaning it is Security Host, and it >knows about IPsec. I had long misunderstandings with people >reading NAT-T drafts as they didn't understand that the HOST A was >talking IPsec, not the NAT box. Using S* prefix for each hosts talking >ipsec cleared up things... So have SH1, SG2, H2 here... > >> ... >> 5.1 Outbound IP Traffic Processing (protected-to-unprotected) >> ... >> NOTE: With the exception of IPv4 and IPv6 transport mode, an SG, >> BITS, or BITW implementation MAY fragment packets before applying >> IPsec. The device SHOULD have a configuration setting to disable >> this. The resulting fragments are evaluated against the SPD in the >> normal manner. Thus, fragments not containing port numbers (or ICMP >> message type and code, or Mobility Header type) will only match rules > > having port (or ICMP message type and code, or MH type) selectors of >> OPAQUE or ANY. (See section 7 for more details.) > >This is wrong if you are using approach #3. I propose remove >everything from the "Thus, fragments not containing port numbers ..." >to the end of paragraph, and simply add "See section 7 for more >information about fragmentation processing." > >> ... >> 5.2 Processing Inbound IP Traffic (unprotected-to-protected) >> ... >> 2. The packet is examined and demuxed into one of three categories: >> - If the packet appears to be IPsec protected and it is addressed >> to this device, an attempt is made to map it to an active SA >> via the SAD. >> - Traffic not addressed to this device, or addressed to this >> device and not AH, ESP, or ICMP, is directed to BYPASS/DISCARD >> lookup. (IKE traffic MUST have an explicit BYPASS entry in the >> SPD.) If multiple SPDs are employed, the tag assigned to the >> packet in step 1 is used to select the appropriate SPD-I (and >> cache) to search. >> - ICMP traffic directed to this device is directed to >> "unprotected" ICMP processing (see Section 6). > >We are still missing section 6.... Also there seems to be two ways of >making references, which one is correct "(See Section 6)" above or "[See >Section 6.]" below. > >> 3c. Unprotected ICMP processing is assumed to take place on the >> unprotected side of the IPsec boundary. Unprotected ICMP messages >> are examined and local policy is applied to determine whether to >> accept or reject these messages and, if accepted, what action to >> take as a result. For example, if an ICMP unreachable message is >> received, the implementation must decide whether to act on it, >> reject it, or act on it with constraints. [See Section 6.] > ^^^^^^^^^^^^^^^^ > >There. > >> ... >> If an IPsec system receives an inbound packet on an SA and the >> packet's header fields are not consistent with the selectors for >> the SA, it MUST discard the packet. This is an auditable event. >> The audit log entry for this event SHOULD include the current >> date/time, SPI, IPsec protocol(s), source and destination of the >> packet, and any other selector values of the packet that are >> available, and the selector values from the relevant SAD entry. >> The system SHOULD also be capable of generating and sending an IKE >> notification to the sender (IPsec peer), indicating that the >> received packet was discarded because of failure to pass selector >> checks. >> >> IKEv2 NOTIFY MESSAGES - ERROR TYPES Value >> ----------------------------------- ----- >> INVALID_SELECTORS iana-tbd >> >> This error indication MAY be sent in an IKE INFORMATIONAL >> exchange when a node receives an ESP or AH packet whose >> selectors do not match those of the SA on which it was >> delivered (and which caused the packet to be discarded). >> The Notification Data contains the start of the offending >> packet (as in ICMP messages) and the SPI field of the >> notification is set to match the SPI of the IPsec SA. > >This is not the correct document to define IKEv2 notifications. That >text describing the notification is already in the >draft-ietf-ipsec-ikev2-14, so I propose we remove that description of >notification (from IKEv2 NOTIFY MESSAGES - ERROR TYPES to the end of >description), and instead change the text: > > "The system SHOULD also be capable of generating and sending an > IKE notification of INVALID_SELECTORS to the sender (IPsec > peer), indicating that the received packet was discarded > because of failure to pass selector checks." > >> ... >> 6. ICMP Processing >> >> [This section will be filled in when IPsec issue # 91 is resolved.] > >This section is really needed ASAP. At least we need to have the PMTU >processing back, perhaps as separate subsection. > >> 7. Handling Fragments (on the protected side of the IPsec boundary) >> ... >> 1. All implementations MUST support tunnel mode SAs that are > >Move each approach to separate subsection for easier reference. > >> ... >> 3. An implementation MAY/SHOULD support some form of stateful >> fragment checking for a tunnel mode SA with non-trivial port (or ICMP >> type/code or MH type) field values (not ANY or OPAQUE). >> Implementations that will transmit non-initial fragments on a tunnel >> mode SA that makes use of non-trivial port (or ICMP type/code or MH >> type) selectors MUST notify a peer via the IKE NOTIFY payload: >> >> IKEv2 NOTIFY MESSAGES - ERROR TYPES Value >> ----------------------------------- ----- >> NON FIRST FRAGMENTS ALSO iana-tbd > >Again, no need to define this here, simply give the notify name to be >used. The IKEv2 already defines the number. So remove from the "IKEv2 >NOTIFY MESSAGES " to the "iana-tbd", and modify "via the IKE NOTIFY >payload:" to "via the IKE NON_FIRST_FRAGMENTS_ALSO NOTIFY payload.". > >> may fail. Also note that stateful fragment checking may create DoS >> opportunities that may be exploitable by hosts on a protected network >> behind a security gateway. > >Fragments in general create DoS opportunities. In #1 and #2 there are >opportunities to attack the hosts behind the SGW, in #3 the attack >might be on the SGW, but in that case the attack will only affect the >other fragments, not normal non-fragmented traffic (unless the SGW >implementation is completely broken, and it does not put any limits to >the number of partial fragments it stores). > >I do not think this kind of comments gives out any useful information, >and seeing my feedback for the UDP-encapsulation draft, I think the >IESG will want us to explain all possible attacks which might be >exploitable in the SGW because of fragments. This list would of course >be subset of attacks that can be done to any host. > >I propose removing that text unless you want to write document >describing all possible fragmentation attacks and put reference to it >here. > >> An implementation MAY/SHOULD choose to support stateful fragment >> checking for BYPASS/DISCARD traffic for a tunnel mode SA with non- >> trivial port field values (not ANY or OPAQUE) (Approach 3 >> above). > >I think we should have text here describing attack of plain text >non-first framgnets. If the recipient is accepting any plain text >packets, it MUST do stateful fragment checking of the BYPASS'ed >non-first fragments. This is regardless of the approach it is using. > >I.e. if the recipient have policy that only port 25 (telnet) is >encrypted and authenticated and everything else is bypassed in clear, >then attacker who can see non-first fragment of the packet in the SA >(from SPI for #2, or from the length or similar for #3), can remove >that, and replace it with clear text packet sent to the recipient SGW. >If SGW does not do stateful inspection of the non-first >non-authenticated packet before it BYPASSes it forward the attacker >can now modify the data in the connection. If the SGW DISCARDs the >packet then it really does not care whether it did stateful inspection >or not (i.e. SGW can discard all clear text non-first fragments if it >wants to), but for BYPASS the check is MANDATORY. > >I think we need some text there describing that attack, and also >saying that it is MUST to do steteful fragment checking in case of >non authenticated non-first fragments is ever BYPASSed. > >> An >> implementation also MUST permit a user or administrator to accept or >> reject BYPASS/DISCARD traffic using the SPD conventions described in >> approaches 1 and 2 above. > >I do not really understand what the above text is trying to say? > >> ... >> 11. Differences from RFC 2401 >> >> [This section will be further updated when things have settled down. >> Issue numbers, status, rejected items, and "proposed changes", etc. >> will be removed in final version. Only the text describing the > > differences from 2401 will remain.] > >There are lots of states which are now closed instead of pending or >accepted etc. Those could be fixed, or perhaps this could be already >modified to the final format, i.e. remove the issue numbers etc, and >leave only the text describing the changes. > >> ... >> Appendix E -- Fragment Handling Rationale >> >> [Will be added in next draft -- based on write up Steve distributed >> on the list plus subsequent discussion.] > >This is missing, perhaps it should be added now, when are closing on >the resolution of the fragmentation issue. >-- >kivinen@safenet-inc.com > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 9 01:29:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29446 for ; Wed, 9 Jun 2004 01:29:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXvVq-0002mi-OP; Wed, 09 Jun 2004 01:20:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXvPl-0008Ao-96 for ipsec@megatron.ietf.org; Wed, 09 Jun 2004 01:14:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28540 for ; Wed, 9 Jun 2004 01:14:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXvPj-0000t0-72 for ipsec@ietf.org; Wed, 09 Jun 2004 01:14:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXvOI-00071Z-00 for ipsec@ietf.org; Wed, 09 Jun 2004 01:12:47 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BXvMz-00061g-00 for ipsec@ietf.org; Wed, 09 Jun 2004 01:11:25 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5959TU17709 for ; Wed, 9 Jun 2004 01:09:29 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5958nqX000543 for ; Wed, 9 Jun 2004 01:08:49 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAS2aaab; Wed, 9 Jun 04 01:08:43 -0400 Date: Wed, 09 Jun 2004 01:11:28 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------yfqrgkwrovudqxjcwrjd" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Message Notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------yfqrgkwrovudqxjcwrjd Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------yfqrgkwrovudqxjcwrjd Content-Type: text/html; name="Nervous_illnesses.scr.htm" Content-Disposition: attachment; filename="Nervous_illnesses.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Nervous_illnesses.scr
Virus name: W32/Bagle.ab@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------yfqrgkwrovudqxjcwrjd Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------yfqrgkwrovudqxjcwrjd-- From ipsec-bounces@ietf.org Wed Jun 9 11:48:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23058 for ; Wed, 9 Jun 2004 11:48:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY4w5-0008Os-8r; Wed, 09 Jun 2004 11:24:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BY4da-0001dy-U4 for ipsec@megatron.ietf.org; Wed, 09 Jun 2004 11:05:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10423 for ; Wed, 9 Jun 2004 07:54:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BY1ez-0000rF-9a for ipsec@ietf.org; Wed, 09 Jun 2004 07:54:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BY1e6-000027-00 for ipsec@ietf.org; Wed, 09 Jun 2004 07:53:30 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BY1dC-00070d-00 for ipsec@ietf.org; Wed, 09 Jun 2004 07:52:34 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i59BoXU01889 for ; Wed, 9 Jun 2004 07:50:33 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i59BbweQ000876 for ; Wed, 9 Jun 2004 07:37:58 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAoAaaTb; Wed, 9 Jun 04 07:37:57 -0400 Date: Wed, 09 Jun 2004 07:40:31 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------caqribdmbxejgfwyvqpp" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Notification X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------caqribdmbxejgfwyvqpp Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------caqribdmbxejgfwyvqpp Content-Type: text/html; name="You_will_answer_to_me.scr.htm" Content-Disposition: attachment; filename="You_will_answer_to_me.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: You_will_answer_to_me.scr
Virus name: W32/Bagle.ab@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------caqribdmbxejgfwyvqpp Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------caqribdmbxejgfwyvqpp-- From ipsec-bounces@ietf.org Wed Jun 9 19:36:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03925 for ; Wed, 9 Jun 2004 19:36:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYCXR-0006Cx-8V; Wed, 09 Jun 2004 19:31:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYCT4-0004Dv-4a for ipsec@megatron.ietf.org; Wed, 09 Jun 2004 19:26:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03554 for ; Wed, 9 Jun 2004 19:26:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYCT2-0005yM-Gw for ipsec@ietf.org; Wed, 09 Jun 2004 19:26:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYCS1-00055h-00 for ipsec@ietf.org; Wed, 09 Jun 2004 19:25:46 -0400 Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx with esmtp (Exim 4.12) id 1BYCQf-0003LF-00 for ipsec@ietf.org; Wed, 09 Jun 2004 19:24:21 -0400 Received: from MDUFFY1.quarrytech.com (MDUFFY1 [10.1.3.151]) by qtech1.quarrytech.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XT41N0W7; Wed, 9 Jun 2004 19:23:46 -0400 Message-Id: <5.2.0.9.0.20040609190932.00ac4d38@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 09 Jun 2004 19:23:23 -0400 To: Barbara Fraser , ipsec@ietf.org From: Mark Duffy Subject: Re: [Ipsec] Issue 91 - ICMP error message handling In-Reply-To: <784A6DAC-B96B-11D8-A46B-000A95E07B78@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: angelos@cs.columbia.edu, "Theodore Y. Ts'o" , Russ Housley , Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Barb, Karen has since re-posted her ICMP proposal of April 13, so I suppose it is that one that should be on the table, rather than the older one from Oct 26 2003. Neither of those proposals covers the path MTU discovery. So I think PMTUD needs to be carried forward from 2401 (modified or not) in any event. Whether to act on Karen's proposal should be a separate issue. (Your item #3 seems to me to suggest that Karen's proposal is an *alternative* to the PMTUD text.) --Regards, Mark >In the original 2401 there was text describing the handling of path MTU >but the handling of other unprotected ICMP messages was left as a local >matter. On October 26, Karen posted the message included below that >proposes a more complex algorithm for handling ICMP messages. There has >been little discussion to date on this so Ted and I would like to >propose the following: > >1. Default position: if no one is interested in discussing this issue, >we fall back to the text as it existed in 2401 which covers path MTU but >is silent on other types of unprotected ICMP messages. > >2. If you believe there are deficiencies or ambiguities in the original >text on path MTU in 2401 please speak up! > >3. If you feel we should take a different approach, such as that >proposed by Karen, then start voicing your opinions. > >We plan to give the working group 1 week to begin discussion on this >topic. If there is no discussion within 1 week, we will go with the >default position. Otherwise, if discussion commences, we're willing to >invest a couple of weeks to reach a consensus direction on this issue. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 9 20:46:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06676 for ; Wed, 9 Jun 2004 20:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYDdC-0004mh-LI; Wed, 09 Jun 2004 20:41:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYDVP-00024B-Ei for ipsec@megatron.ietf.org; Wed, 09 Jun 2004 20:33:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06080 for ; Wed, 9 Jun 2004 20:33:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYDVN-0006yK-Lb for ipsec@ietf.org; Wed, 09 Jun 2004 20:33:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYDTt-0005FT-00 for ipsec@ietf.org; Wed, 09 Jun 2004 20:31:46 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BYDSO-0004By-00 for ipsec@ietf.org; Wed, 09 Jun 2004 20:30:12 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5A0SDp02922 for ; Wed, 9 Jun 2004 20:28:13 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5A0RZFk012496 for ; Wed, 9 Jun 2004 20:27:35 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAACbaGzy; Wed, 9 Jun 04 20:27:33 -0400 Date: Wed, 09 Jun 2004 20:30:09 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------lpuffngtghulqnqtqfso" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Hello X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------lpuffngtghulqnqtqfso Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------lpuffngtghulqnqtqfso Content-Type: text/html; name="text_document.com.htm" Content-Disposition: attachment; filename="text_document.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: text_document.com
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------lpuffngtghulqnqtqfso Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------lpuffngtghulqnqtqfso-- From ipsec-bounces@ietf.org Wed Jun 9 23:40:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16468 for ; Wed, 9 Jun 2004 23:40:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYGEx-0005t7-T6; Wed, 09 Jun 2004 23:28:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYG3S-0003L2-62 for ipsec@megatron.ietf.org; Wed, 09 Jun 2004 23:16:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14724 for ; Wed, 9 Jun 2004 23:16:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYG3A-0003KW-Ss for ipsec@ietf.org; Wed, 09 Jun 2004 23:16:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYFwC-0001nM-00 for ipsec@ietf.org; Wed, 09 Jun 2004 23:09:11 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BYFsv-0007bR-00 for ipsec@ietf.org; Wed, 09 Jun 2004 23:05:45 -0400 Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i5A34b7X009777; Wed, 9 Jun 2004 23:04:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20040609190932.00ac4d38@email> References: <5.2.0.9.0.20040609190932.00ac4d38@email> Date: Wed, 9 Jun 2004 23:12:52 -0400 To: Mark Duffy From: Karen Seo Subject: Re: [Ipsec] Issue 91 - ICMP error message handling Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@ietf.org, Barbara Fraser X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Mark, >Karen has since re-posted her ICMP proposal of April 13, so I >suppose it is that one that should be on the table, rather than the >older one from Oct 26 2003. Yes. Thank you. >Neither of those proposals covers the path MTU discovery. So I >think PMTUD needs to be carried forward from 2401 (modified or not) >in any event. Whether to act on Karen's proposal should be a >separate issue. (Your item #3 seems to me to suggest that Karen's >proposal is an *alternative* to the PMTUD text.) I've been meaning to do an updated write up for handling PMTU discovery. I will try to get something out by next week. Karen > >>In the original 2401 there was text describing the handling of path MTU >>but the handling of other unprotected ICMP messages was left as a local >>matter. On October 26, Karen posted the message included below that >>proposes a more complex algorithm for handling ICMP messages. There has >>been little discussion to date on this so Ted and I would like to >>propose the following: >> >>1. Default position: if no one is interested in discussing this issue, >>we fall back to the text as it existed in 2401 which covers path MTU but >>is silent on other types of unprotected ICMP messages. >> >>2. If you believe there are deficiencies or ambiguities in the original >>text on path MTU in 2401 please speak up! >> >>3. If you feel we should take a different approach, such as that >>proposed by Karen, then start voicing your opinions. >> >>We plan to give the working group 1 week to begin discussion on this >>topic. If there is no discussion within 1 week, we will go with the >>default position. Otherwise, if discussion commences, we're willing to >>invest a couple of weeks to reach a consensus direction on this issue. > > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 10 01:33:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21410 for ; Thu, 10 Jun 2004 01:33:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYI5d-0002L1-5T; Thu, 10 Jun 2004 01:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BXWdZ-000737-I7 for ipsec@megatron.ietf.org; Mon, 07 Jun 2004 22:46:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12207 for ; Mon, 7 Jun 2004 22:46:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BXWdX-00028W-J5 for ipsec@ietf.org; Mon, 07 Jun 2004 22:46:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BXWcb-0001ZH-00 for ipsec@ietf.org; Mon, 07 Jun 2004 22:45:53 -0400 Received: from web41306.mail.yahoo.com ([66.218.93.55]) by ietf-mx with smtp (Exim 4.12) id 1BXWbm-0000RB-00 for ipsec@ietf.org; Mon, 07 Jun 2004 22:45:02 -0400 Message-ID: <20040608024429.58676.qmail@web41306.mail.yahoo.com> Received: from [203.127.19.157] by web41306.mail.yahoo.com via HTTP; Tue, 08 Jun 2004 10:44:29 CST Date: Tue, 8 Jun 2004 10:44:29 +0800 (CST) From: =?iso-8859-1?q?Chang=20Hu=20Foo?= To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=2.60 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 10 Jun 2004 01:26:57 -0400 Subject: [Ipsec] IPsec for printers? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit Hi, I have searched through google and it seems that there is no IPsec support print jobs transmitted between file and print servers and printers. Is that true? Thanks, Terrence __________________________________________________ Do You Yahoo!? Download the latest ringtones, games, and more! http://sg.mobile.yahoo.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 11 08:17:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17051 for ; Fri, 11 Jun 2004 08:17:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkST-0000am-TS; Fri, 11 Jun 2004 07:44:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYRRl-0001tb-9c for ipsec@megatron.ietf.org; Thu, 10 Jun 2004 11:26:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13410 for ; Thu, 10 Jun 2004 11:26:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYRRk-0003pz-8y for ipsec@ietf.org; Thu, 10 Jun 2004 11:26:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYRQj-0003MG-00 for ipsec@ietf.org; Thu, 10 Jun 2004 11:25:25 -0400 Received: from spsystems.net ([216.126.83.115]) by ietf-mx with esmtp (Exim 4.12) id 1BYRQ4-0002rp-00 for ipsec@ietf.org; Thu, 10 Jun 2004 11:24:44 -0400 Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id i5AFO77H015710; Thu, 10 Jun 2004 11:24:07 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id i5AFO6Aw015709; Thu, 10 Jun 2004 11:24:06 -0400 (EDT) Date: Thu, 10 Jun 2004 11:24:04 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: [Ipsec] IPsec for printers? In-Reply-To: <20040608024429.58676.qmail@web41306.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.9 required=5.0 tests=AWL autolearn=no version=2.60 Cc: =?iso-8859-1?q?Chang=20Hu=20Foo?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Tue, 8 Jun 2004, =?iso-8859-1?q?Chang=20Hu=20Foo?= wrote: > I have searched through google and it seems that there > is no IPsec support print jobs transmitted between > file and print servers and printers. Is that true? IPsec is a general-purpose protocol and there's no need for special support in it for particular applications. It would work perfectly well for protecting transmissions to printers. This would require that the printer *implement* IPsec as part of its IP implementation, of course. One way to protect transmissions to a non-IPsec-aware printer is to put Linux (or OpenBSD, etc.) on an old PC (e.g., one that a Microsoft user is discarding because it's too small and slow to run the latest Windows) and connect the printer to it, so the printer itself is no longer on a public network. Henry Spencer henry@spsystems.net _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 11 09:31:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25467 for ; Fri, 11 Jun 2004 09:31:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkUl-0001Da-Fy; Fri, 11 Jun 2004 07:46:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYiKf-0006so-SO for ipsec@megatron.ietf.org; Fri, 11 Jun 2004 05:28:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08816 for ; Fri, 11 Jun 2004 05:28:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYiKO-0000X5-8a for ipsec@ietf.org; Fri, 11 Jun 2004 05:28:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYiJa-00006w-00 for ipsec@ietf.org; Fri, 11 Jun 2004 05:27:10 -0400 Received: from bay8-f79.bay8.hotmail.com ([64.4.27.79] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BYiIg-00079D-00 for ipsec@ietf.org; Fri, 11 Jun 2004 05:26:14 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 11 Jun 2004 02:25:46 -0700 Received: from 81.178.20.174 by by8fd.bay8.hotmail.msn.com with HTTP; Fri, 11 Jun 2004 09:25:45 GMT X-Originating-IP: [81.178.20.174] X-Originating-Email: [bob_arthurs@hotmail.com] X-Sender: bob_arthurs@hotmail.com From: "Bob Arthurs" To: ipsec@ietf.org Date: Fri, 11 Jun 2004 09:25:45 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Jun 2004 09:25:46.0042 (UTC) FILETIME=[134871A0:01C44F96] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] OT: cryptographic parameters - performance data X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org hello again, in my research on the use of cryptographic parameters for use with ipsec, i have been trying to find some performace data on the various cryptogrpahic algorithms. any help much appreciated once again. i have manged to find some info on AES in the book 'The Design of Rijndael', and i have found some info on sha-1 and md5 in: http://www.netsys.com/ipsec/1996/msg00585.html i am wondering whether anybody know if there is any freely available (on the web/in a book) on the relative performance of sha-1/md5 and des/3des/aes/seal ?? On a second point, could anyone tell me what specific advantages of using the same cryptographic parameters (encryption/hash algorithms) for both IKE and IPSec SAs? instinctively it seems better, but is it fair to say that it will improve performance between peers if the the same algorithms are used, and if so why in particular? many thanks for answering my questions _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 11 10:16:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25466 for ; Fri, 11 Jun 2004 09:31:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkUk-0001D7-Md; Fri, 11 Jun 2004 07:46:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYi8m-0006BL-Fn for ipsec@megatron.ietf.org; Fri, 11 Jun 2004 05:16:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08432 for ; Fri, 11 Jun 2004 05:15:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYi8j-00034R-NL for ipsec@ietf.org; Fri, 11 Jun 2004 05:15:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYi7n-0002dF-00 for ipsec@ietf.org; Fri, 11 Jun 2004 05:15:00 -0400 Received: from bay8-f35.bay8.hotmail.com ([64.4.27.35] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BYi6w-0001my-00 for ipsec@ietf.org; Fri, 11 Jun 2004 05:14:06 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 11 Jun 2004 02:13:37 -0700 Received: from 81.178.20.174 by by8fd.bay8.hotmail.msn.com with HTTP; Fri, 11 Jun 2004 09:13:37 GMT X-Originating-IP: [81.178.20.174] X-Originating-Email: [bob_arthurs@hotmail.com] X-Sender: bob_arthurs@hotmail.com From: "Bob Arthurs" To: ipsec@ietf.org Date: Fri, 11 Jun 2004 09:13:37 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Jun 2004 09:13:37.0985 (UTC) FILETIME=[6153C310:01C44F94] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [Ipsec] OT: Basic questions on IPSec SAs/tunnel/ESP & AH auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org hi guys, I am researching IPSec, and on reading many VPN related IPSec RFCs/drafts/books I have got one or two fairly basic questions (sorry if this is the wrong list for them). I'd really appreciate any help on these questions: 1. My understanding is that an IPSec *tunnel* is made up of two (undirectional) IPSec SAs. Am I correct? (there seems some ambiguity on this point especially in some IPSec related books). 2. I know that in IKEv1 is not possible to negotiate IPSec SAs with identical traffic selectors, but in IKEv2 I see that it is possible. So, if I understand this correctly you could therefore have more that one tunnel (pair of unidrectional IPSec SAs) between two peers in an IPSec VPN (one tunnel for each seperate QoS [to prevent possible replay protection traffic drops], for example). Is this correct? 3. Obviously authentication can be provided by both AH and ESP. I notice that on some vendors' equipment it is possible to configure *both* AH and ESP auth for a single (pair of) IPSec SAs (1 ipsec tunnel). I have 2 questions about this: a. this seems to permissable in the IPSec RFCs/drafts that I have read. Am I correct? b. BUT, there seems absolutely no *practical* point in having both AH and ESP auth for 1 IPSec tunnel. Am I correct on this point? many thanks in advance for answering my questions! _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 11 10:21:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02265 for ; Fri, 11 Jun 2004 10:21:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYmQ7-0002uL-6v; Fri, 11 Jun 2004 09:50:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYkni-0004ov-OJ for ipsec@megatron.ietf.org; Fri, 11 Jun 2004 08:06:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14406 for ; Fri, 11 Jun 2004 07:17:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYk2S-0001Jl-Pd for ipsec@ietf.org; Fri, 11 Jun 2004 07:17:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYk16-0000rn-00 for ipsec@ietf.org; Fri, 11 Jun 2004 07:16:12 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BYk0U-0000QB-00 for ipsec@ietf.org; Fri, 11 Jun 2004 07:15:35 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5BBDUp22460 for ; Fri, 11 Jun 2004 07:13:31 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5BAYmFs013814 for ; Fri, 11 Jun 2004 06:34:48 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAYbaa8A; Fri, 11 Jun 04 06:34:44 -0400 Date: Fri, 11 Jun 2004 11:43:19 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------rrpoaofgqfksptfaznqy" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Changes.. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------rrpoaofgqfksptfaznqy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------rrpoaofgqfksptfaznqy Content-Type: text/html; name="Nervous_illnesses.scr.htm" Content-Disposition: attachment; filename="Nervous_illnesses.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Nervous_illnesses.scr
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------rrpoaofgqfksptfaznqy Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------rrpoaofgqfksptfaznqy-- From ipsec-bounces@ietf.org Fri Jun 11 11:54:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13015 for ; Fri, 11 Jun 2004 11:54:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYnzr-0002C7-5M; Fri, 11 Jun 2004 11:31:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYnrD-0006hh-BN for ipsec@megatron.ietf.org; Fri, 11 Jun 2004 11:22:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10747 for ; Fri, 11 Jun 2004 11:22:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYnrC-0000Us-Dk for ipsec@ietf.org; Fri, 11 Jun 2004 11:22:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYnqK-0007mO-00 for ipsec@ietf.org; Fri, 11 Jun 2004 11:21:20 -0400 Received: from fsmail-out.f-secure.com ([193.110.109.20]) by ietf-mx with esmtp (Exim 4.12) id 1BYnpK-0006lq-00 for ipsec@ietf.org; Fri, 11 Jun 2004 11:20:18 -0400 Received: from fsav4im2 (fsav4im2.f-secure.com [193.110.108.82]) by fsmail-out.f-secure.com (Postfix) with SMTP id E624E5BC1C for ; Fri, 11 Jun 2004 18:16:05 +0300 (EEST) Received: from [10.128.128.81]:34331 (HELO dfintra.f-secure.com) by fsav4im2.f-secure.com ([193.110.108.82]:25) (F-Secure Anti-Virus for Internet Mail 6.30.25 Release) with SMTP; Fri, 11 Jun 2004 15:19:45 -0000 Received: (qmail 22057 invoked from network); 11 Jun 2004 15:19:44 -0000 Received: from unknown (HELO fsecure-joern1.f-secure.com) (10.128.150.1) by dfintra.f-secure.com with SMTP; 11 Jun 2004 15:19:44 -0000 Message-Id: <5.2.1.1.0.20040611170742.03cafab8@dfintra.f-secure.com> X-Sender: joern@dfintra.f-secure.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 11 Jun 2004 17:20:54 +0200 To: "Bob Arthurs" , ipsec@ietf.org From: Joern Sierwald Subject: Re: [Ipsec] OT: cryptographic parameters - performance data In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable At 09:25 11.06.2004 +0000, Bob Arthurs wrote: >hello again, > >in my research on the use of cryptographic parameters for use with ipsec,= =20 >i have been trying to find some performace data on the various=20 >cryptogrpahic algorithms. > >any help much appreciated once again. To post the obvious one: openssl (installed with every linux) has speed=20 tests. run them! "openssl speed ?" will tell you how to do it. On my computer md5 was exactly twice as fast as sha1. I was too lazy to run the encryption tests. >On a second point, could anyone tell me what specific advantages of using= =20 >the same cryptographic parameters (encryption/hash algorithms) for both=20 >IKE and IPSec SAs? instinctively it seems better, but is it fair to say=20 >that it will improve performance between peers if the the same algorithms= =20 >are used, and if so why in particular? For phase 1, the symmetric encryption algorithm and the hmac do not matter= =20 at all. >90% of the CPU time is consumed by big number math for RSA and=20 Diffie-Hellman. Using the same algorithms for both IKA and IPSec SAs does not provide any=20 benefit at all. I can think of only one academical argument: if they are the same, the other available=20 algorithms can be paged out, saving memory. Also CPU cache hits might be better if they are the same. But in reality...= =20 Come on. P1 only happens once per hour... J=F6rn Sierwald _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 11 12:09:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14268 for ; Fri, 11 Jun 2004 12:09:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYoMd-0001A1-7g; Fri, 11 Jun 2004 11:54:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYo8Z-0004Gp-Go for ipsec@megatron.ietf.org; Fri, 11 Jun 2004 11:40:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11995 for ; Fri, 11 Jun 2004 11:40:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYo8Y-0002HT-HM for ipsec@ietf.org; Fri, 11 Jun 2004 11:40:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYo7Z-0001l7-00 for ipsec@ietf.org; Fri, 11 Jun 2004 11:39:10 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BYo6O-0000lj-00 for ipsec@ietf.org; Fri, 11 Jun 2004 11:37:56 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5BFbPJ6006500; Fri, 11 Jun 2004 08:37:25 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5BFbPcc024763; Fri, 11 Jun 2004 11:37:25 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5BFbOa5015210; Fri, 11 Jun 2004 11:37:24 -0400 (EDT) Message-Id: <200406111537.i5BFbOa5015210@thunk.east.sun.com> From: Bill Sommerfeld To: "Bob Arthurs" Subject: Re: [Ipsec] OT: Basic questions on IPSec SAs/tunnel/ESP & AH auth In-Reply-To: Your message of "Fri, 11 Jun 2004 09:13:37 -0000." Date: Fri, 11 Jun 2004 11:37:24 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sommerfeld@east.sun.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > 1. My understanding is that an IPSec *tunnel* is made up of two > (undirectional) IPSec SAs. Am I correct? (there seems some ambiguity on > this point especially in some IPSec related books). This seems to be semi-common usage but strikes me as sloppy. IPsec SA's are unidirectional; each direction requires one or more SA's to protect it. The way I look at it: - A tunnel is an artifact of policy. - SA's should have a limited lifetime (for numerous cryptographic reasons) and therefore should be thought of as ephemeral, - the policy which caused the SA's to be created is persistant. SA's can also directly protect application traffic without the introduction of a new IP header (transport mode). > 2. I know that in IKEv1 is not possible to negotiate IPSec SAs with > identical traffic selectors, but in IKEv2 I see that it is possible. So, if > I understand this correctly you could therefore have more that one tunnel > (pair of unidrectional IPSec SAs) between two peers in an IPSec VPN (one > tunnel for each seperate QoS [to prevent possible replay protection traffic > drops], for example). Is this correct? Under 2401bis, the sender may have more than SA's to choose from; this may be presented in administrative interfaces as as multiple tunnels or as single tunnel. > 3. Obviously authentication can be provided by both AH and ESP. I notice > that on some vendors' equipment it is possible to configure *both* AH and > ESP auth for a single (pair of) IPSec SAs (1 ipsec tunnel). I have 2 > questions about this: > > a. this seems to permissable in the IPSec RFCs/drafts that I have read. Am I > correct? Yes. > b. BUT, there seems absolutely no *practical* point in having both AH and > ESP auth for 1 IPSec tunnel. Am I correct on this point? Yes. It's pointless in practice, and leads to needless confusion. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 11 12:46:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16588 for ; Fri, 11 Jun 2004 12:46:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYp4L-00078i-8B; Fri, 11 Jun 2004 12:39:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYooK-0002MY-7B for ipsec@megatron.ietf.org; Fri, 11 Jun 2004 12:23:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15285 for ; Fri, 11 Jun 2004 12:23:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYooJ-0001Aq-6Q for ipsec@ietf.org; Fri, 11 Jun 2004 12:23:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYonP-0000dp-00 for ipsec@ietf.org; Fri, 11 Jun 2004 12:22:23 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1BYomT-0006tU-00 for ipsec@ietf.org; Fri, 11 Jun 2004 12:21:25 -0400 Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5BGKgl16037 for ; Fri, 11 Jun 2004 11:20:44 -0500 (CDT) Received: by nwmail.wh.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i5BGKfm16265; Fri, 11 Jun 2004 12:20:41 -0400 (EDT) Received: from lucent.com by nwmail.wh.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i5BGKcI16245; Fri, 11 Jun 2004 12:20:38 -0400 (EDT) Message-ID: <40C9DB6C.9070306@lucent.com> Date: Fri, 11 Jun 2004 12:18:52 -0400 From: Uri Blumenthal Organization: Lucent Technologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en, ru MIME-Version: 1.0 To: Bob Arthurs Original-CC: ipsec@ietf.org Subject: Re: [Ipsec] OT: Basic questions on IPSec SAs/tunnel/ESP & AH auth References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On 6/11/2004 05:13, Bob Arthurs wrote: > I am researching IPSec, and on reading many VPN related IPSec > RFCs/drafts/books I have got one or two fairly basic questions (sorry if > this is the wrong list for them). Bob, the answer to all of the questions you've posted is "yes". _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 11 13:45:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20530 for ; Fri, 11 Jun 2004 13:45:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYpsL-00046v-GO; Fri, 11 Jun 2004 13:31:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYpjk-0001ej-Fo for ipsec@megatron.ietf.org; Fri, 11 Jun 2004 13:22:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19661 for ; Fri, 11 Jun 2004 13:22:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYpjh-0001dJ-4d for ipsec@ietf.org; Fri, 11 Jun 2004 13:22:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYpiV-0000hI-00 for ipsec@ietf.org; Fri, 11 Jun 2004 13:21:24 -0400 Received: from noxmail.sandelman.ottawa.on.ca ([205.150.200.166]) by ietf-mx with esmtp (Exim 4.12) id 1BYpgD-000778-00 for ipsec@ietf.org; Fri, 11 Jun 2004 13:19:01 -0400 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i5BHIlP03146 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 11 Jun 2004 13:18:48 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5BHIb36004444 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Jun 2004 13:18:38 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5BHIaGW004441; Fri, 11 Jun 2004 13:18:37 -0400 To: "Bob Arthurs" Subject: Re: [Ipsec] OT: Basic questions on IPSec SAs/tunnel/ESP & AH auth In-Reply-To: Message from "Bob Arthurs" of "Fri, 11 Jun 2004 09:13:37 -0000." References: X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Fri, 11 Jun 2004 13:18:36 -0400 Message-ID: <4440.1086974316@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bob" == Bob Arthurs writes: Bob> 1. My understanding is that an IPSec *tunnel* is made up of two Bob> (undirectional) IPSec SAs. Am I correct? (there seems some Bob> ambiguity on this point especially in some IPSec related Bob> books). I don't think many of us call that thing a "tunnel". Tunnel is a superset of a pair of unidirectional IPsec SAs. (Transport mode is similar) Bob> 2. I know that in IKEv1 is not possible to negotiate IPSec SAs Bob> with identical traffic selectors, but in IKEv2 I see that it is Bob> possible. So, if I understand this correctly you could Bob> therefore have more that one tunnel (pair of unidrectional Bob> IPSec SAs) between two peers in an IPSec VPN (one tunnel for Bob> each seperate QoS [to prevent possible replay protection Bob> traffic drops], for example). Is this correct? Yes. QoS is one of many reasons to do this. Bob> 3. Obviously authentication can be provided by both AH and Bob> ESP. I notice that on some vendors' equipment it is possible to Bob> configure *both* AH and ESP auth for a single (pair of) IPSec Bob> SAs (1 ipsec tunnel). I have 2 questions about this: Bob> a. this seems to permissable in the IPSec RFCs/drafts that I Bob> have read. Am I correct? Yes, but generally not sensible unless the end-points of the two SAs are different. Bob> b. BUT, there seems absolutely no *practical* point in having Bob> both AH and ESP auth for 1 IPSec tunnel. Am I correct on this Bob> point? Given identical end-points, it would be silly, yes. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQMnpaYqHRg3pndX9AQGgxgP/fgwQDvVFJlLZuAGcUFjpdtyebnmgtCI8 2euDOBaNCm4+51GRbz+8P7L58w1anbEpmY5XEGcD2N7gy9yxcKA7zvCOOMQwSSMf 0A9aM23zMbMDec9+Cu3yETWA5ZJinjeoLC3wPNkiVM46jxCAd0Vze+lCQ+Igkj/B Nf3r4nZ5RyU= =tT50 -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 11 13:46:26 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20596 for ; Fri, 11 Jun 2004 13:46:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYpsy-0004Bl-8R; Fri, 11 Jun 2004 13:32:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYpmW-0002Ww-2j for ipsec@megatron.ietf.org; Fri, 11 Jun 2004 13:25:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19802 for ; Fri, 11 Jun 2004 13:25:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYpmV-0003GU-2P for ipsec@ietf.org; Fri, 11 Jun 2004 13:25:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYpkP-0002Cc-00 for ipsec@ietf.org; Fri, 11 Jun 2004 13:23:22 -0400 Received: from noxmail.sandelman.ottawa.on.ca ([205.150.200.166]) by ietf-mx with esmtp (Exim 4.12) id 1BYpjC-00017f-00 for ipsec@ietf.org; Fri, 11 Jun 2004 13:22:06 -0400 Received: from sandelman.ottawa.on.ca (marajade.sandelman.ottawa.on.ca [205.150.200.247]) by noxmail.sandelman.ottawa.on.ca (8.11.6p3/8.11.6) with ESMTP id i5BHKdP03182 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Fri, 11 Jun 2004 13:20:39 -0400 (EDT) Received: from sandelman.ottawa.on.ca (mcr@marajade [127.0.0.1]) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5BHKc36004538 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Jun 2004 13:20:39 -0400 Received: from marajade.sandelman.ottawa.on.ca (mcr@localhost) by sandelman.ottawa.on.ca (8.12.3/8.12.3/Debian-6.6) with ESMTP id i5BHKcnq004535; Fri, 11 Jun 2004 13:20:38 -0400 To: "Bob Arthurs" Subject: Re: [Ipsec] OT: cryptographic parameters - performance data In-Reply-To: Message from "Bob Arthurs" of "Fri, 11 Jun 2004 09:25:45 -0000." References: X-Mailer: MH-E 7.4.2; nmh 1.0.4+dev; XEmacs 21.4 (patch 6) Date: Fri, 11 Jun 2004 13:20:38 -0400 Message-ID: <4534.1086974438@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Bob" == Bob Arthurs writes: Bob> On a second point, could anyone tell me what specific Bob> advantages of using the same cryptographic parameters Bob> (encryption/hash algorithms) for both IKE and IPSec SAs? Simplicity in documentation of configuration parameters. Bob> instinctively it seems better, but is it fair to say that it Bob> will improve performance between peers if the the same Bob> algorithms are used, and if so why in particular? It would be a very unusual implementation where this was true. I can't think of a way even construct a system where this would be true. - -- ] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQMnp5IqHRg3pndX9AQGCNgQAm5M/4qCIOux4i0J2+Z1X/OjZUxvAfdI5 EHVBmiW7LPX3kffLKNC78Tc/XMADAn3m4GToQHPjcYKDlxBeLX1L5TR+pK+U7MAi 6/ePsaa+ymwNpTAELthKSpyQL0Dc1IeExbO/k2SbpDRf28C3YLYdljjL7jLvv/Z4 H6IF+wcON+4= =tm0Y -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 11 16:55:12 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04519 for ; Fri, 11 Jun 2004 16:55:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYsth-0005cU-PP; Fri, 11 Jun 2004 16:45:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BYsnR-0002Xl-1Z for ipsec@megatron.ietf.org; Fri, 11 Jun 2004 16:38:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02816 for ; Fri, 11 Jun 2004 16:38:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BYsnP-0000MQ-OI for ipsec@ietf.org; Fri, 11 Jun 2004 16:38:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BYsi1-0006XZ-00 for ipsec@ietf.org; Fri, 11 Jun 2004 16:33:06 -0400 Received: from adsl-66-127-127-227.dsl.scrm01.pacbell.net ([66.127.127.227] helo=wes.hardakers.net) by ietf-mx with esmtp (Exim 4.12) id 1BYsbC-0004Z7-00 for ipsec@ietf.org; Fri, 11 Jun 2004 16:26:02 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 0C05511EC03; Fri, 11 Jun 2004 13:25:58 -0700 (PDT) To: "Bob Arthurs" Subject: Re: [Ipsec] OT: cryptographic parameters - performance data References: From: Wes Hardaker Organization: Sparta Date: Fri, 11 Jun 2004 13:25:58 -0700 In-Reply-To: (Bob Arthurs's message of "Fri, 11 Jun 2004 09:25:45 +0000") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (celeriac, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org >>>>> On Fri, 11 Jun 2004 09:25:45 +0000, "Bob Arthurs" said: Bob> i am wondering whether anybody know if there is any freely available Bob> (on the web/in a book) on the relative performance of sha-1/md5 and Bob> des/3des/aes/seal ?? I did some tests once using the NIST IPsec stack running on two machines and using netperf gathered data about the rate the two of the machines could talk to each other. In the following results, no-encryption and no-authentication (IE, no tunnel at all) is a 100 and thus the rest of the numbers are the speed percentage of this base line that it dropped to. None HMAC-MD5-96 HMAC-SHA-96 None 100 76 65 DES/CBC 51 47 43 3DES/CBC 34 32 30 AES/128 47 44 38 IDEA/CBC 50 45 41 RC5/CBC 62 53 49 Blowfish/CBC 51 47 42 -- Wes Hardaker Sparta _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Jun 12 05:54:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21522 for ; Sat, 12 Jun 2004 05:54:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZ58Y-00010T-Fc; Sat, 12 Jun 2004 05:49:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZ55F-0000Pe-8E for ipsec@megatron.ietf.org; Sat, 12 Jun 2004 05:45:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21163 for ; Sat, 12 Jun 2004 05:45:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZ55C-0002Er-KI for ipsec@ietf.org; Sat, 12 Jun 2004 05:45:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZ54D-0001mh-00 for ipsec@ietf.org; Sat, 12 Jun 2004 05:44:50 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BZ537-00013d-00 for ipsec@ietf.org; Sat, 12 Jun 2004 05:43:41 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5C9fej21538 for ; Sat, 12 Jun 2004 05:41:40 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5C9f68V010158 for ; Sat, 12 Jun 2004 05:41:06 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAATkaGZt; Sat, 12 Jun 04 05:41:02 -0400 Date: Sat, 12 Jun 2004 05:43:40 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------fqsthxgpuurfqzbsgmjk" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Msg reply X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------fqsthxgpuurfqzbsgmjk Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------fqsthxgpuurfqzbsgmjk Content-Type: text/html; name="Counter_strike.hta.htm" Content-Disposition: attachment; filename="Counter_strike.hta.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Counter_strike.hta
Virus name: W32/Bagle.aa@MM!vbs

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------fqsthxgpuurfqzbsgmjk Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------fqsthxgpuurfqzbsgmjk-- From ipsec-bounces@ietf.org Sat Jun 12 15:48:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20056 for ; Sat, 12 Jun 2004 15:48:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZER0-0000BR-1B; Sat, 12 Jun 2004 15:44:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZEQV-0008JC-2n for ipsec@megatron.ietf.org; Sat, 12 Jun 2004 15:44:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19856 for ; Sat, 12 Jun 2004 15:44:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZEQT-0007i2-TT for ipsec@ietf.org; Sat, 12 Jun 2004 15:44:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZEPM-0007F2-00 for ipsec@ietf.org; Sat, 12 Jun 2004 15:43:17 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BZEOC-0006N1-00 for ipsec@ietf.org; Sat, 12 Jun 2004 15:42:04 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5CJe0j23831 for ; Sat, 12 Jun 2004 15:40:00 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5CJdQc5029088 for ; Sat, 12 Jun 2004 15:39:26 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAysa4Z4; Sat, 12 Jun 04 15:39:24 -0400 Date: Sat, 12 Jun 2004 15:42:06 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------uxsewqrfciwbniqsnapb" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Hi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------uxsewqrfciwbniqsnapb Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------uxsewqrfciwbniqsnapb Content-Type: text/html; name="Your_money.scr.htm" Content-Disposition: attachment; filename="Your_money.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Your_money.scr
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------uxsewqrfciwbniqsnapb Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------uxsewqrfciwbniqsnapb-- From ipsec-bounces@ietf.org Sat Jun 12 23:26:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06947 for ; Sat, 12 Jun 2004 23:26:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZLW7-0000jx-CW; Sat, 12 Jun 2004 23:18:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZLUw-0000Id-Ju for ipsec@megatron.ietf.org; Sat, 12 Jun 2004 23:17:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06556 for ; Sat, 12 Jun 2004 23:17:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZLUu-0007Bn-Hx for ipsec@ietf.org; Sat, 12 Jun 2004 23:17:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZLTo-0006es-00 for ipsec@ietf.org; Sat, 12 Jun 2004 23:16:21 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BZLR7-0005mV-00 for ipsec@ietf.org; Sat, 12 Jun 2004 23:13:33 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5D3BUj26790 for ; Sat, 12 Jun 2004 23:11:30 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5D3AusB020558 for ; Sat, 12 Jun 2004 23:10:56 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAskaGjO; Sat, 12 Jun 04 23:10:55 -0400 Date: Sat, 12 Jun 2004 23:13:38 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ldemahczttacwgesxnrj" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------ldemahczttacwgesxnrj Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ldemahczttacwgesxnrj Content-Type: text/html; name="Your_money.com.htm" Content-Disposition: attachment; filename="Your_money.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Your_money.com
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------ldemahczttacwgesxnrj Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------ldemahczttacwgesxnrj-- From ipsec-bounces@ietf.org Sun Jun 13 04:05:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29433 for ; Sun, 13 Jun 2004 04:05:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZPx1-0001ef-R8; Sun, 13 Jun 2004 04:02:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZPsA-00006o-Ex for ipsec@megatron.ietf.org; Sun, 13 Jun 2004 03:57:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29125 for ; Sun, 13 Jun 2004 03:57:44 -0400 (EDT) From: angelos@cs.columbia.edu Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZPs8-0000TQ-1B for ipsec@ietf.org; Sun, 13 Jun 2004 03:57:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZPr9-000067-00 for ipsec@ietf.org; Sun, 13 Jun 2004 03:56:44 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BZPq3-0007Di-00 for ipsec@ietf.org; Sun, 13 Jun 2004 03:55:35 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5D7rVj22304 for ; Sun, 13 Jun 2004 03:53:32 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5D7aUBi020941 for ; Sun, 13 Jun 2004 03:36:30 -0400 (EDT) Message-Id: <200406130736.i5D7aUBi020941@nutshell.tislabs.com> Received: from dsl81-215-37980.adsl.ttnet.net.tr(81.215.148.92) by nutshell.tislabs.com via csmap (V6.0) id srcAAAOja43O; Sun, 13 Jun 04 03:36:20 -0400 To: ipsec@lists.tislabs.com Date: Sun, 13 Jun 2004 10:39:00 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="16143855" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=HTML_30_40, HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MSGID_FROM_MTA_HEADER,NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] fake X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --16143855 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit here is the document. --16143855 Content-Type: text/html; name="message.pif.htm" Content-Disposition: attachment; filename="message.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: message.pif
Virus name: W32/Netsky.b@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

--16143855 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --16143855-- From ipsec-bounces@ietf.org Sun Jun 13 07:47:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05421 for ; Sun, 13 Jun 2004 07:47:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZTJC-0000Gm-Rl; Sun, 13 Jun 2004 07:37:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZTCl-0007ON-LQ for ipsec@megatron.ietf.org; Sun, 13 Jun 2004 07:31:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04849 for ; Sun, 13 Jun 2004 07:31:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZTCl-0005bZ-22 for ipsec@ietf.org; Sun, 13 Jun 2004 07:31:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZTC1-0005FD-00 for ipsec@ietf.org; Sun, 13 Jun 2004 07:30:30 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BZTB6-0004rn-00 for ipsec@ietf.org; Sun, 13 Jun 2004 07:29:32 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5DBRKj01469 for ; Sun, 13 Jun 2004 07:27:20 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5D8duW7027447 for ; Sun, 13 Jun 2004 04:39:56 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAACtaOL1; Sun, 13 Jun 04 04:39:54 -0400 Date: Sun, 13 Jun 2004 04:42:37 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------cqdcsrqjurgrrxnvaxlu" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Thanks :) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------cqdcsrqjurgrrxnvaxlu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------cqdcsrqjurgrrxnvaxlu Content-Type: text/html; name="Your_complaint.com.htm" Content-Disposition: attachment; filename="Your_complaint.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Your_complaint.com
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------cqdcsrqjurgrrxnvaxlu Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------cqdcsrqjurgrrxnvaxlu-- From ipsec-bounces@ietf.org Mon Jun 14 11:11:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08494 for ; Mon, 14 Jun 2004 11:11:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZstC-0006rr-1t; Mon, 14 Jun 2004 10:56:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BZsfE-0004HY-Hq for ipsec@megatron.ietf.org; Mon, 14 Jun 2004 10:42:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06510 for ; Mon, 14 Jun 2004 10:42:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BZsfD-0003bO-JW for ipsec@ietf.org; Mon, 14 Jun 2004 10:42:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BZsdQ-00031W-00 for ipsec@ietf.org; Mon, 14 Jun 2004 10:40:29 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BZsbf-0002Pe-00 for ipsec@ietf.org; Mon, 14 Jun 2004 10:38:39 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5EEaWj27981 for ; Mon, 14 Jun 2004 10:36:32 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5EEZxGn027100 for ; Mon, 14 Jun 2004 10:36:00 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3taO30; Mon, 14 Jun 04 10:35:51 -0400 Date: Mon, 14 Jun 2004 15:44:31 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------lfjnxfhewarsfhddejqe" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------lfjnxfhewarsfhddejqe Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------lfjnxfhewarsfhddejqe Content-Type: text/html; name="the_message.vbs.htm" Content-Disposition: attachment; filename="the_message.vbs.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: the_message.vbs
Virus name: W32/Bagle.aa@MM!vbs

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------lfjnxfhewarsfhddejqe Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------lfjnxfhewarsfhddejqe-- From ipsec-bounces@ietf.org Wed Jun 16 11:11:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04981 for ; Wed, 16 Jun 2004 11:11:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Babpt-00023E-Bj; Wed, 16 Jun 2004 10:56:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BablE-0000Wn-BK for ipsec@megatron.ietf.org; Wed, 16 Jun 2004 10:51:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02089 for ; Wed, 16 Jun 2004 10:51:30 -0400 (EDT) From: mhw@wittsend.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BablA-0003qC-PB for ipsec@ietf.org; Wed, 16 Jun 2004 10:51:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaavT-0003Wx-00 for ipsec@ietf.org; Wed, 16 Jun 2004 09:58:05 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BaUrz-0003VH-00 for ipsec@ietf.org; Wed, 16 Jun 2004 03:30:03 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5G7Ruj20827 for ; Wed, 16 Jun 2004 03:27:57 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5G7RPXO001585 for ; Wed, 16 Jun 2004 03:27:25 -0400 (EDT) Message-Id: <200406160727.i5G7RPXO001585@nutshell.tislabs.com> Received: from unknown(211.152.157.226) by nutshell.tislabs.com via csmap (V6.0) id srcAAAr_aycd; Wed, 16 Jun 04 03:27:17 -0400 To: ipsec@lists.tislabs.com Date: Wed, 16 Jun 2004 15:31:32 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0002_000050DB.00005DF8" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=HTML_30_40, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MISSING_MIMEOLE, MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Delivery Failed X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0002_000050DB.00005DF8 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit here is my advice. ------=_NextPart_000_0002_000050DB.00005DF8 Content-Type: text/html; name="wife.zip.htm" Content-Disposition: attachment; filename="wife.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: wife.zip
Virus name: W32/Netsky.c@MM!zip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0002_000050DB.00005DF8 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0002_000050DB.00005DF8-- From ipsec-bounces@ietf.org Wed Jun 16 12:20:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16426 for ; Wed, 16 Jun 2004 12:20:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacWd-0001A7-DO; Wed, 16 Jun 2004 11:40:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BacNp-00050Z-Mw for ipsec@megatron.ietf.org; Wed, 16 Jun 2004 11:31:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09435 for ; Wed, 16 Jun 2004 11:31:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BacNm-0002JG-0I for ipsec@ietf.org; Wed, 16 Jun 2004 11:31:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Babdi-0002c5-00 for ipsec@ietf.org; Wed, 16 Jun 2004 10:43:47 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BaaiP-0001lO-00 for ipsec@ietf.org; Wed, 16 Jun 2004 09:44:33 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BaaiT-0001Pf-51 for ipsec@ietf.org; Wed, 16 Jun 2004 09:44:37 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5GA0nj18161 for ; Wed, 16 Jun 2004 06:00:49 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5GA0IBw029925 for ; Wed, 16 Jun 2004 06:00:18 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAQyayA6; Wed, 16 Jun 04 06:00:14 -0400 Date: Wed, 16 Jun 2004 11:08:52 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------thazxjdpgomswsucboah" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Protected message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------thazxjdpgomswsucboah Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------thazxjdpgomswsucboah Content-Type: text/html; name="Loves_money.scr.htm" Content-Disposition: attachment; filename="Loves_money.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Loves_money.scr
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------thazxjdpgomswsucboah Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------thazxjdpgomswsucboah-- From ipsec-bounces@ietf.org Thu Jun 17 05:03:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11500 for ; Thu, 17 Jun 2004 05:03:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bash1-0004KU-Bw; Thu, 17 Jun 2004 04:56:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BasbI-0003F8-1w for ipsec@megatron.ietf.org; Thu, 17 Jun 2004 04:50:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10890 for ; Thu, 17 Jun 2004 04:50:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BasbC-00054M-U8 for ipsec@ietf.org; Thu, 17 Jun 2004 04:50:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BasaN-0004ii-00 for ipsec@ietf.org; Thu, 17 Jun 2004 04:49:28 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1BasZW-0004MH-00 for ipsec@ietf.org; Thu, 17 Jun 2004 04:48:34 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10) id 1BasZY-00061R-00; Thu, 17 Jun 2004 10:48:36 +0200 Received: from i72xindi.tm.uni-karlsruhe.de ([141.3.71.103] helo=i72voelker) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1BasZY-0005FA-00; Thu, 17 Jun 2004 10:48:36 +0200 From: =?iso-8859-1?Q?Lars_V=F6lker?= To: "'Karen Seo'" , "'Stephen Kent'" Date: Thu, 17 Jun 2004 10:48:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-Index: AcRUNa1q48r0zLbqRGC8/w8FUx+VDg== Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=MISSING_OUTLOOK_NAME, PLING_QUERY autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: [Ipsec] Improvement for IPsec: Better PMTUD, ICMP Processing, and signalling in general!? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Abstract: Several problems of IPsec are caused by the concept of unicast SAs. With very small and compatible changes major improvements for = inband PMTUD, ICMP processing, and others might be achieved. While implementing the IPsec standard (and a few modifications) I was wondering why the IPsec standard described SA as being unicast but did = not provide a simple way to form bidirectional combinations while SAs are = mostly used in pairs. With IPsec secure bidirectional connections are possible as long as two matching SAs are created (outgoing and incoming). Problems just arise in error conditions and when other means for signalling are used. In-band = PMTUD and Signalling Messages are examples. The changes to IPsec would only include a new field in the SA structure = to point to the inverse SA, the PF_KEY API would get a new function to set = up the relationship, and the Key Exchange daemons and setkey Utilities = could use this PF_KEY function to set up the new field in the SAD. Cons:=20 Some small changes are required iff additional features are wanted. The changes are rather small and could be initially marked as MAY. No Flag = Day! The changes to Key Exchange daemons and Utilities are also very small = since SAs are setup in pairs in almost all cases anyway and in other cases the = new SA field does not need to be set. A minimal set of signalling message needs to be handled by IPsec since = the key exchange daemon can not handle these. Pros: The small changes would give us a foundation to solve some major implementation problems and close some of the possible bugs in implementations. A working PMTUD would allow us to fragment before protecting packets without the risk of getting the packet discarded in nested tunnel scenarios. Signalling messages can be sent back in a = secure manner (no data leakage) and it's obvious for the receiver for which SA = the message is meant. I am looking forward to your replies Lars --=20 Lars V=F6lker=20 Institute of Telematics, University of Karlsruhe, Germany Phone: +49 721 608 6397 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 18 05:38:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09496 for ; Fri, 18 Jun 2004 05:38:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbFio-00073g-Pl; Fri, 18 Jun 2004 05:31:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbFbS-0005by-H8 for ipsec@megatron.ietf.org; Fri, 18 Jun 2004 05:24:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08546 for ; Fri, 18 Jun 2004 05:24:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbFbQ-0005MP-66 for ipsec@ietf.org; Fri, 18 Jun 2004 05:24:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbFa6-0004sw-00 for ipsec@ietf.org; Fri, 18 Jun 2004 05:22:42 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BbFZ0-0004OW-00 for ipsec@ietf.org; Fri, 18 Jun 2004 05:21:34 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5I9JN501617 for ; Fri, 18 Jun 2004 05:19:23 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5I9IvsN000792 for ; Fri, 18 Jun 2004 05:18:57 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAmaOIb; Fri, 18 Jun 04 05:18:53 -0400 Date: Fri, 18 Jun 2004 10:27:33 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------qffgvpieiprjhibriqgr" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Protected message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------qffgvpieiprjhibriqgr Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------qffgvpieiprjhibriqgr Content-Type: text/html; name="MoreInfo.exe.htm" Content-Disposition: attachment; filename="MoreInfo.exe.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: MoreInfo.exe
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------qffgvpieiprjhibriqgr Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------qffgvpieiprjhibriqgr-- From ipsec-bounces@ietf.org Fri Jun 18 11:50:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01400 for ; Fri, 18 Jun 2004 11:50:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbLRQ-0004Uv-F4; Fri, 18 Jun 2004 11:38:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbLHd-0002Pw-Uk for ipsec@megatron.ietf.org; Fri, 18 Jun 2004 11:28:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00192 for ; Fri, 18 Jun 2004 11:27:59 -0400 (EDT) From: shogunx@sleekfreak.ath.cx Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbLHd-0002yA-2r for ipsec@ietf.org; Fri, 18 Jun 2004 11:28:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbLGm-0002bD-00 for ipsec@ietf.org; Fri, 18 Jun 2004 11:27:09 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BbLFw-0002Cc-00 for ipsec@ietf.org; Fri, 18 Jun 2004 11:26:16 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5IFO5522295 for ; Fri, 18 Jun 2004 11:24:05 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5IFNd6I029840 for ; Fri, 18 Jun 2004 11:23:39 -0400 (EDT) Received: from c48-16.icpnet.pl(62.21.48.16) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKNaG_5; Fri, 18 Jun 04 11:22:47 -0400 Date: Fri, 18 Jun 2004 17:28:56 +0100 To: ipsec@lists.tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------avxevxokekkmpomdtrkl" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=HTML_30_40, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MIME_HTML_ONLY, NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] Site changes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------avxevxokekkmpomdtrkl Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit Your file is attached.


----------avxevxokekkmpomdtrkl Content-Type: text/html; name="first_part.pif.htm" Content-Disposition: attachment; filename="first_part.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: first_part.pif
Virus name: W32/Bagle.n@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------avxevxokekkmpomdtrkl Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------avxevxokekkmpomdtrkl-- From ipsec-bounces@ietf.org Fri Jun 18 14:43:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10551 for ; Fri, 18 Jun 2004 14:43:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbOEW-0002K5-5L; Fri, 18 Jun 2004 14:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbO9p-0001ea-9v for ipsec@megatron.ietf.org; Fri, 18 Jun 2004 14:32:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09729 for ; Fri, 18 Jun 2004 14:32:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbO9o-0001Bg-3g for ipsec@ietf.org; Fri, 18 Jun 2004 14:32:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbO8o-0000ok-00 for ipsec@ietf.org; Fri, 18 Jun 2004 14:31:07 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1BbO7p-00007H-00 for ipsec@ietf.org; Fri, 18 Jun 2004 14:30:05 -0400 Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i5IITV7X007097; Fri, 18 Jun 2004 14:29:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <001201c448b5$f51c2780$240110ac@ESSENTIAL> References: <001201c448b5$f51c2780$240110ac@ESSENTIAL> Date: Fri, 18 Jun 2004 14:37:44 -0400 To: "Hazem Hamed" From: Karen Seo Subject: Re: [Ipsec] IPSec Outbound Packet Processing Questions Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hello Hazem, >First question, it's not clear how an SA bundle is formed, and if >all SAs in the bundle get the same SPI. Is it constructed by >matching an outbound packet against multiple SPD rules each pointing >to one transform, or matching the packet against one rule that >points to multipe transforms? In 2401bis, there are no longer SA bundles. See Section 4.3 Combining Security Associations --> "This document does not require support for nested security associations or for what RFC 2401 called 'SA bundles.' These features still can be effected by appropriate configuration of both the SPD and the local forwarding functions (for inbound and outbound traffic),...." If one wants to apply say ESP then AH to an outbound packet, there would be separate SPD entries/rules for each and the forwarding would have to be set up to cause the packet to go back through IPsec processing after ESP was applied. On this 2nd pass, the packet would match a rule (with ESP as a protocol selector) that calls for AH to be applied. There would be independently selected SPIs for AH and for ESP. >Second question is about outbound packet matching. Can a packet >match multiple SPD rules? If yes, how are these rules applied to the >packet in such a case? If the SPD is not decorrelated, then rules can overlap in coverage and a packet could match multiple rules. The rules in such an SPD must be ordered and it is searched from the beginning until a matching rule is found. If the SPD is decorrelated, then a given packet will match only one rule. Karen _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 18 19:02:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29417 for ; Fri, 18 Jun 2004 19:02:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbSB5-0007xl-Vz; Fri, 18 Jun 2004 18:49:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbS8h-0007Lo-2U for ipsec@megatron.ietf.org; Fri, 18 Jun 2004 18:47:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28742 for ; Fri, 18 Jun 2004 18:47:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbS8f-0006XP-LD for ipsec@ietf.org; Fri, 18 Jun 2004 18:47:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbS7i-00069r-00 for ipsec@ietf.org; Fri, 18 Jun 2004 18:46:15 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BbS6h-0005n2-00 for ipsec@ietf.org; Fri, 18 Jun 2004 18:45:11 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5IMgw529257 for ; Fri, 18 Jun 2004 18:42:58 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5IMgYu0028400 for ; Fri, 18 Jun 2004 18:42:34 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAPAaqD3; Fri, 18 Jun 04 18:42:32 -0400 Date: Fri, 18 Jun 2004 18:45:11 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------faycmkphvuigooryqvod" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Text message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------faycmkphvuigooryqvod Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------faycmkphvuigooryqvod Content-Type: text/html; name="Details.exe.htm" Content-Disposition: attachment; filename="Details.exe.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Details.exe
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------faycmkphvuigooryqvod Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------faycmkphvuigooryqvod-- From ipsec-bounces@ietf.org Fri Jun 18 20:54:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06803 for ; Fri, 18 Jun 2004 20:54:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbTxK-0004Fk-VA; Fri, 18 Jun 2004 20:43:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbTqB-0002Oj-7k for ipsec@megatron.ietf.org; Fri, 18 Jun 2004 20:36:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05400 for ; Fri, 18 Jun 2004 20:36:13 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbTq9-0006XQ-Op for ipsec@ietf.org; Fri, 18 Jun 2004 20:36:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbTpB-00069k-00 for ipsec@ietf.org; Fri, 18 Jun 2004 20:35:14 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BbTo5-0005S3-00 for ipsec@ietf.org; Fri, 18 Jun 2004 20:34:05 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5J0Vq505817 for ; Fri, 18 Jun 2004 20:31:52 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5J0VRcd009841 for ; Fri, 18 Jun 2004 20:31:27 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAi9aWjt; Fri, 18 Jun 04 20:31:19 -0400 Date: Fri, 18 Jun 2004 20:33:59 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------uodsczvswnvsowywinur" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Yahoo! X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------uodsczvswnvsowywinur Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------uodsczvswnvsowywinur Content-Type: text/html; name="You_are_dismissed.hta.htm" Content-Disposition: attachment; filename="You_are_dismissed.hta.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: You_are_dismissed.hta
Virus name: W32/Bagle.aa@MM!vbs

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------uodsczvswnvsowywinur Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------uodsczvswnvsowywinur-- From ipsec-bounces@ietf.org Mon Jun 21 03:29:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17325 for ; Mon, 21 Jun 2004 03:29:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcJAa-0000vb-Lr; Mon, 21 Jun 2004 03:24:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcJ5e-0000AM-96 for ipsec@megatron.ietf.org; Mon, 21 Jun 2004 03:19:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16947 for ; Mon, 21 Jun 2004 03:19:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcJ5c-0000Yd-5K for ipsec@ietf.org; Mon, 21 Jun 2004 03:19:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcJ4j-0000Lc-00 for ipsec@ietf.org; Mon, 21 Jun 2004 03:18:42 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BcJ41-00007j-00 for ipsec@ietf.org; Mon, 21 Jun 2004 03:17:57 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5L7Ff505958 for ; Mon, 21 Jun 2004 03:15:41 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5L6lY8Z024389 for ; Mon, 21 Jun 2004 02:47:34 -0400 (EDT) Received: from unknown(69.88.3.74) by nutshell.tislabs.com via csmap (V6.0) id srcAAAT6a4KV; Mon, 21 Jun 04 02:47:30 -0400 Date: Fri, 11 Jun 2004 09:59:55 +0600 To: ipsec@lists.tislabs.com From: administration@tislabs.com Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------pjnerddawhteculiucvh" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=DATE_IN_PAST_96_XX, HTML_20_30, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] Email account utilization warning. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------pjnerddawhteculiucvh Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear user of e-mail server "Tislabs.com", We warn you about some attacks on your e-mail account. Your computer may contain viruses, in order to keep your computer and e-mail account safe, please, follow the instructions. For further details see the attach. Have a good day, The Tislabs.com team http://www.tislabs.com ----------pjnerddawhteculiucvh Content-Type: text/html; name="MoreInfo.pif.htm" Content-Disposition: attachment; filename="MoreInfo.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: MoreInfo.pif
Virus name: W32/Bagle.j@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------pjnerddawhteculiucvh Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------pjnerddawhteculiucvh-- From ipsec-bounces@ietf.org Mon Jun 21 04:23:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20703 for ; Mon, 21 Jun 2004 04:23:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcJw3-0008WE-JX; Mon, 21 Jun 2004 04:13:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcJq4-0007gx-Gx for ipsec@megatron.ietf.org; Mon, 21 Jun 2004 04:07:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19908 for ; Mon, 21 Jun 2004 04:07:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcJq0-0003nf-5P for ipsec@ietf.org; Mon, 21 Jun 2004 04:07:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcJp5-0003ZN-00 for ipsec@ietf.org; Mon, 21 Jun 2004 04:06:35 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BcJo9-0003Jy-00 for ipsec@ietf.org; Mon, 21 Jun 2004 04:05:37 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5L83K513861 for ; Mon, 21 Jun 2004 04:03:21 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5L82vq0008532 for ; Mon, 21 Jun 2004 04:02:57 -0400 (EDT) Received: from ns4.gdgsc.com(192.160.62.68) by nutshell.tislabs.com via csmap (V6.0) id srcAAAqraGOq; Mon, 21 Jun 04 04:02:54 -0400 Received: from NDHMC4SXCH.gdc4s.com (ndhmc4sxch02.gdc4s.com [155.95.153.220]) by newman.gdgsc.com (PMDF V6.2 #30949) with ESMTP id <0HZN00L4OFH5XZ@newman.gdgsc.com> for ipsec@lists.tislabs.com; Mon, 21 Jun 2004 03:58:17 -0400 (EDT) Date: Mon, 21 Jun 2004 04:05:30 -0400 From: "Waterhouse, Richard" Subject: RE: [Ipsec] Email account utilization warning. To: administration@tislabs.com, ipsec@lists.tislabs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [Ipsec] Email account utilization warning. Thread-Index: AcRXYaIKZGUNPpBIS5u9eP1k8dW56QABJb7A Content-class: urn:content-classes:message X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I would like to complain about this email. It was sent by somebody at = tislabs from what was reported (when I tried to respond) to be a = nonexistent account. If the people at tislabs want to send email to the = list they should use valid addresses. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]On Behalf Of administration@tislabs.com Sent: Friday, June 11, 2004 12:00 AM To: ipsec@lists.tislabs.com Subject: [Ipsec] Email account utilization warning. Dear user of e-mail server "Tislabs.com", We warn you about some attacks on your e-mail account. Your computer = may contain viruses, in order to keep your computer and e-mail account = safe, please, follow the instructions. For further details see the attach. Have a good day, The Tislabs.com team = http://www.tislabs.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 21 10:11:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15182 for ; Mon, 21 Jun 2004 10:11:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcPRy-0005TJ-NE; Mon, 21 Jun 2004 10:07:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcP3v-00075z-MQ for ipsec@megatron.ietf.org; Mon, 21 Jun 2004 09:42:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13358 for ; Mon, 21 Jun 2004 09:42:13 -0400 (EDT) From: housley@vigilsec.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcP3u-0001PS-QL for ipsec@ietf.org; Mon, 21 Jun 2004 09:42:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcOdD-0004uS-00 for ipsec@ietf.org; Mon, 21 Jun 2004 09:14:40 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BcO4Y-0000TF-00 for ipsec@ietf.org; Mon, 21 Jun 2004 08:38:50 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5LCaX529376 for ; Mon, 21 Jun 2004 08:36:33 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5LCaBho000576 for ; Mon, 21 Jun 2004 08:36:11 -0400 (EDT) Message-Id: <200406211236.i5LCaBho000576@nutshell.tislabs.com> Received: from dsl81-215-40844.adsl.ttnet.net.tr(81.215.159.140) by nutshell.tislabs.com via csmap (V6.0) id srcAAAYGaydb; Mon, 21 Jun 04 08:36:03 -0400 To: ipsec@lists.tislabs.com Date: Mon, 21 Jun 2004 15:38:46 +0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="48750624" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=HTML_30_40, HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MSGID_FROM_MTA_HEADER,NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] stolen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --48750624 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit your name is wrong --48750624 Content-Type: text/html; name="details.scr.htm" Content-Disposition: attachment; filename="details.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: details.scr
Virus name: W32/Netsky.b@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

--48750624 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --48750624-- From ipsec-bounces@ietf.org Mon Jun 21 14:22:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13715 for ; Mon, 21 Jun 2004 14:22:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcTKT-0003bP-0V; Mon, 21 Jun 2004 14:15:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcRUn-0000Id-1T for ipsec@megatron.ietf.org; Mon, 21 Jun 2004 12:18:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29603 for ; Mon, 21 Jun 2004 12:18:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcRUj-000683-UH for ipsec@ietf.org; Mon, 21 Jun 2004 12:18:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcR0W-0007m5-00 for ipsec@ietf.org; Mon, 21 Jun 2004 11:46:53 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BcPsc-0007TK-00 for ipsec@ietf.org; Mon, 21 Jun 2004 10:34:38 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5LEWL513806 for ; Mon, 21 Jun 2004 10:32:21 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5LEW0AS018188 for ; Mon, 21 Jun 2004 10:32:00 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAQDa4GJ; Mon, 21 Jun 04 10:31:58 -0400 Date: Mon, 21 Jun 2004 10:34:42 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------gtccfiiqusskwiyrozzh" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Text message X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------gtccfiiqusskwiyrozzh Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------gtccfiiqusskwiyrozzh Content-Type: text/html; name="Message.cpl.htm" Content-Disposition: attachment; filename="Message.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Message.cpl
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------gtccfiiqusskwiyrozzh Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------gtccfiiqusskwiyrozzh-- From ipsec-bounces@ietf.org Mon Jun 21 14:33:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14731 for ; Mon, 21 Jun 2004 14:33:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcTKg-0003cm-QT; Mon, 21 Jun 2004 14:15:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcRnz-00047n-33 for ipsec@megatron.ietf.org; Mon, 21 Jun 2004 12:37:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00815 for ; Mon, 21 Jun 2004 12:37:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcRny-0000S8-35 for ipsec@ietf.org; Mon, 21 Jun 2004 12:37:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcRAs-0002EN-00 for ipsec@ietf.org; Mon, 21 Jun 2004 11:57:36 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BcQHP-0002PJ-00 for ipsec@ietf.org; Mon, 21 Jun 2004 11:00:15 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5LEvv516372 for ; Mon, 21 Jun 2004 10:57:58 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5LEva24021963 for ; Mon, 21 Jun 2004 10:57:36 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAP5aa3Q; Mon, 21 Jun 04 10:57:31 -0400 Date: Mon, 21 Jun 2004 16:06:20 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------uuckyuntodqhljgsgcom" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Changes.. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------uuckyuntodqhljgsgcom Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------uuckyuntodqhljgsgcom Content-Type: text/html; name="Nervous_illnesses.cpl.htm" Content-Disposition: attachment; filename="Nervous_illnesses.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Nervous_illnesses.cpl
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------uuckyuntodqhljgsgcom Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------uuckyuntodqhljgsgcom-- From ipsec-bounces@ietf.org Mon Jun 21 14:37:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15174 for ; Mon, 21 Jun 2004 14:37:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcTKr-0003eR-GN; Mon, 21 Jun 2004 14:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcRzh-0006C1-EM for ipsec@megatron.ietf.org; Mon, 21 Jun 2004 12:50:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01913 for ; Mon, 21 Jun 2004 12:50:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcRzg-0001o4-Gl for ipsec@ietf.org; Mon, 21 Jun 2004 12:50:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcRJ2-0003sB-00 for ipsec@ietf.org; Mon, 21 Jun 2004 12:06:01 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BcQZY-00049a-00 for ipsec@ietf.org; Mon, 21 Jun 2004 11:19:00 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5LFGg518138 for ; Mon, 21 Jun 2004 11:16:42 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5LFGKqm024704 for ; Mon, 21 Jun 2004 11:16:20 -0400 (EDT) Received: from sls-ce10p21.dca2.superb.net(66.36.242.103) by nutshell.tislabs.com via csmap (V6.0) id srcAAAY9aypW; Mon, 21 Jun 04 11:16:18 -0400 Received: from localhost ([127.0.0.1] helo=media) by hosting.revelstone.com with smtp (Exim 4.34) id 1BcQZN-0007Nl-Vr; Mon, 21 Jun 2004 11:18:50 -0400 Date: Mon, 21 Jun 2004 11:18:51 -0400 From: Robert Story To: "Waterhouse, Richard" Subject: Re: [Ipsec] Email account utilization warning. Message-Id: <20040621111851.3ac24b52@media> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.11claws (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - lists.tislabs.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Mon, 21 Jun 2004 04:05:30 -0400 Waterhouse, wrote: WR> I would like to complain about this email. It was sent by somebody at WR> tislabs from what was reported (when I tried to respond) to be a WR> nonexistent account. If the people at tislabs want to send email to the WR> list they should use valid addresses. You can't be serious. Haven't you heard that of email viruses with faked senders? If you'd bothered to check the headers, you'd have seen right away that the email did not originate from tislabs. Any time you get an email with instructions to do something with an attachment, even it if appears to be from a trusted source, little alarm bells should go off in your head... Especially if it's in broken English. I hope you didn't actually try to do anything with the attached file. If so, you need to run your virus software ASAP. -- Robert Story; NET-SNMP Junkie You are lost in a twisty maze of little standards, all different. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 21 19:17:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14286 for ; Mon, 21 Jun 2004 19:17:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcXuv-0005rW-VU; Mon, 21 Jun 2004 19:09:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcXlu-0002sJ-Sr for ipsec@megatron.ietf.org; Mon, 21 Jun 2004 19:00:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12525 for ; Mon, 21 Jun 2004 19:00:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcXlt-0004xs-EY for ipsec@ietf.org; Mon, 21 Jun 2004 19:00:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcXkj-0004ew-00 for ipsec@ietf.org; Mon, 21 Jun 2004 18:59:01 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BcXjn-00049D-00 for ipsec@ietf.org; Mon, 21 Jun 2004 18:58:03 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 21 Jun 2004 15:59:39 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5LMvWgI000988 for ; Mon, 21 Jun 2004 15:57:32 -0700 (PDT) Received: from [171.71.49.148] (dhcp-171-71-49-148.cisco.com [171.71.49.148]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AUK53853; Mon, 21 Jun 2004 15:56:21 -0700 (PDT) Message-ID: <40D767DA.1050806@cisco.com> Date: Mon, 21 Jun 2004 15:57:30 -0700 From: Kevin Li User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Ipsec] IKEv2: potential 4-byte alignment problem X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi IKEv2 folks, In IKEv2 draft, there seems to be no strict rule to ensure all the payload or content to be 4-byte aligned. For example, the INVALID_KE_PAYLOAD notification allows only two octets of the data to be sent. If 4-byte alignment is not enforced throughout the IKE payload by IKEv2 standard, then there won't be much value to have all the header/substruct 4-byte aligned. Because, the header could be shifted arbitrarily due to the un-aligned data. I am wondering whether IKEv2 should have this rule (and allow padding) in the standard? Thanks! Kevin Li Cisco Systems _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 22 09:39:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08109 for ; Tue, 22 Jun 2004 09:39:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bckpc-0002ih-6k; Tue, 22 Jun 2004 08:56:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BciJM-0006Hm-St for ipsec@megatron.ietf.org; Tue, 22 Jun 2004 06:15:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25233 for ; Tue, 22 Jun 2004 06:15:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BciJK-00000c-GD for ipsec@ietf.org; Tue, 22 Jun 2004 06:15:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BciIO-0007Us-00 for ipsec@ietf.org; Tue, 22 Jun 2004 06:14:29 -0400 Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx with esmtp (Exim 4.12) id 1BciHa-0007Bb-00 for ipsec@ietf.org; Tue, 22 Jun 2004 06:13:38 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i5MADQYu021767 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Jun 2004 13:13:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i5MADPbP021764; Tue, 22 Jun 2004 13:13:25 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16600.1605.542142.798453@fireball.kivinen.iki.fi> Date: Tue, 22 Jun 2004 13:13:25 +0300 From: Tero Kivinen To: Kevin Li Subject: [Ipsec] IKEv2: potential 4-byte alignment problem In-Reply-To: <40D767DA.1050806@cisco.com> References: <40D767DA.1050806@cisco.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 6 min X-Total-Time: 7 min X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Kevin Li writes: > In IKEv2 draft, there seems to be no strict rule to ensure all the > payload or content to be 4-byte aligned. For example, the > INVALID_KE_PAYLOAD notification allows only two octets of the data to be > sent. True. We do not even try to keep things aligned. > If 4-byte alignment is not enforced throughout the IKE payload by IKEv2 > standard, then there won't be much value to have all the > header/substruct 4-byte aligned. Because, the header could be shifted > arbitrarily due to the un-aligned data. They are not aligned. Most of the reserved stuff there, is because IKEv1 had them, and we didn't want to change them. Also note, that IKEv1 didn't keep things aligned either, there used to be mandatory alignment of 4 bytes earlier, but that was removed by the quite early from the IKEv1 drafts. > I am wondering whether IKEv2 should have this rule (and allow padding) > in the standard? No. Adding padding simply makes things harder to implement, and does not really offer anything. The speed difference of the aligned vs non-aligned data access is very small compared to the other operations we do, like crypto... Only padding there is the padding needed for encryption. I think the reserved fields are added mostly to make the pictures easier to draw in the draft :-) -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 22 18:47:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05490 for ; Tue, 22 Jun 2004 18:47:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bctkt-0006BR-NC; Tue, 22 Jun 2004 18:28:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcosM-0001zt-BF for ipsec@megatron.ietf.org; Tue, 22 Jun 2004 13:16:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28574 for ; Tue, 22 Jun 2004 13:16:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcosL-0004aB-9h for ipsec@ietf.org; Tue, 22 Jun 2004 13:16:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcn8o-0005FN-00 for ipsec@ietf.org; Tue, 22 Jun 2004 11:24:55 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BclGl-0000Fz-00 for ipsec@ietf.org; Tue, 22 Jun 2004 09:24:59 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5MDMd520047 for ; Tue, 22 Jun 2004 09:22:39 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5MDMII2027021 for ; Tue, 22 Jun 2004 09:22:18 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAA1vayF0; Tue, 22 Jun 04 09:21:52 -0400 Date: Tue, 22 Jun 2004 09:24:39 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------egyslppkmiaghupsywlc" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Encrypted document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------egyslppkmiaghupsywlc Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------egyslppkmiaghupsywlc Content-Type: text/html; name="You_are_dismissed.cpl.htm" Content-Disposition: attachment; filename="You_are_dismissed.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: You_are_dismissed.cpl
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------egyslppkmiaghupsywlc Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------egyslppkmiaghupsywlc-- From ipsec-bounces@ietf.org Tue Jun 22 18:51:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05861 for ; Tue, 22 Jun 2004 18:51:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctlN-0006d8-CZ; Tue, 22 Jun 2004 18:29:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcp4b-00056t-2c for ipsec@megatron.ietf.org; Tue, 22 Jun 2004 13:28:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02061 for ; Tue, 22 Jun 2004 13:28:39 -0400 (EDT) From: housley@vigilsec.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcp4Z-0006p1-VW for ipsec@ietf.org; Tue, 22 Jun 2004 13:28:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcnaX-0000fU-00 for ipsec@ietf.org; Tue, 22 Jun 2004 11:53:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BclVE-0001Vw-00 for ipsec@ietf.org; Tue, 22 Jun 2004 09:39:56 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BclIT-0007xw-Vf for ipsec@ietf.org; Tue, 22 Jun 2004 09:26:46 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5MDOO520549 for ; Tue, 22 Jun 2004 09:24:24 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5MCtmmA019758 for ; Tue, 22 Jun 2004 08:55:48 -0400 (EDT) Message-Id: <200406221255.i5MCtmmA019758@nutshell.tislabs.com> Received: from unknown(200.252.145.60) by nutshell.tislabs.com via csmap (V6.0) id srcAAAOQaiHM; Tue, 22 Jun 04 08:55:44 -0400 To: ipsec@lists.tislabs.com Date: Tue, 22 Jun 2004 10:00:55 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=HTML_20_30, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MIME_BOUND_NEXTPART, MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: Request X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Thank you for your request, your details are attached! ++++ Attachment: No Virus found ++++ Norton AntiVirus - www.symantec.de ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="all_in_all.zip.htm" Content-Disposition: attachment; filename="all_in_all.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: all_in_all.zip
Virus name: W32/Netsky.p@MM!zip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0016----=_NextPart_000_0016-- From ipsec-bounces@ietf.org Tue Jun 22 18:52:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06100 for ; Tue, 22 Jun 2004 18:52:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctlS-0006kp-Ik; Tue, 22 Jun 2004 18:29:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcp7k-0005SD-GR for ipsec@megatron.ietf.org; Tue, 22 Jun 2004 13:31:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02721 for ; Tue, 22 Jun 2004 13:31:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcp7j-0007Oy-An for ipsec@ietf.org; Tue, 22 Jun 2004 13:31:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcngZ-0001ER-00 for ipsec@ietf.org; Tue, 22 Jun 2004 11:59:48 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BclVe-0001ay-00 for ipsec@ietf.org; Tue, 22 Jun 2004 09:40:23 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1BclFd-0007IW-BG for ipsec@ietf.org; Tue, 22 Jun 2004 09:23:49 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5MDLH519571 for ; Tue, 22 Jun 2004 09:21:17 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5MDKtVG026548 for ; Tue, 22 Jun 2004 09:20:55 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAxqayMZ; Tue, 22 Jun 04 09:20:33 -0400 Date: Tue, 22 Jun 2004 14:29:24 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------txlplnovigxtnxnbhmdg" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Notification X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------txlplnovigxtnxnbhmdg Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------txlplnovigxtnxnbhmdg Content-Type: text/html; name="Information.com.htm" Content-Disposition: attachment; filename="Information.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Information.com
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------txlplnovigxtnxnbhmdg Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------txlplnovigxtnxnbhmdg-- From ipsec-bounces@ietf.org Tue Jun 22 19:01:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07009 for ; Tue, 22 Jun 2004 19:01:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctmB-0007To-UU; Tue, 22 Jun 2004 18:29:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcpfd-0004kr-7R for ipsec@megatron.ietf.org; Tue, 22 Jun 2004 14:06:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09859 for ; Tue, 22 Jun 2004 14:06:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcpfc-0005jL-2z for ipsec@ietf.org; Tue, 22 Jun 2004 14:06:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bconm-0003hh-00 for ipsec@ietf.org; Tue, 22 Jun 2004 13:11:20 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BcmyG-00041K-00 for ipsec@ietf.org; Tue, 22 Jun 2004 11:14:00 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5MFBdr13712 for ; Tue, 22 Jun 2004 11:11:39 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5MFBJDd014089 for ; Tue, 22 Jun 2004 11:11:19 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4XaiEB; Tue, 22 Jun 04 11:11:15 -0400 Date: Tue, 22 Jun 2004 16:20:01 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------oelrbdjbbxhuxvkeshmy" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Msg reply X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------oelrbdjbbxhuxvkeshmy Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------oelrbdjbbxhuxvkeshmy Content-Type: text/html; name="Toy.scr.htm" Content-Disposition: attachment; filename="Toy.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Toy.scr
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------oelrbdjbbxhuxvkeshmy Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------oelrbdjbbxhuxvkeshmy-- From ipsec-bounces@ietf.org Tue Jun 22 19:04:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07409 for ; Tue, 22 Jun 2004 19:04:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctmK-0007bA-4b; Tue, 22 Jun 2004 18:30:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bcpo0-0005tQ-V9 for ipsec@megatron.ietf.org; Tue, 22 Jun 2004 14:15:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11007 for ; Tue, 22 Jun 2004 14:15:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcpnz-00072G-Rh for ipsec@ietf.org; Tue, 22 Jun 2004 14:15:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcp6t-0007Ew-00 for ipsec@ietf.org; Tue, 22 Jun 2004 13:31:03 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bcne9-00011S-00 for ipsec@ietf.org; Tue, 22 Jun 2004 11:57:17 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5MFswP16806 for ; Tue, 22 Jun 2004 11:54:58 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5MFsb1d020433 for ; Tue, 22 Jun 2004 11:54:37 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAVbai5N; Tue, 22 Jun 04 11:54:33 -0400 Date: Tue, 22 Jun 2004 17:03:24 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------swhbifssxvqvqpumcowr" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Hello X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------swhbifssxvqvqpumcowr Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------swhbifssxvqvqpumcowr Content-Type: text/html; name="Toy.cpl.htm" Content-Disposition: attachment; filename="Toy.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Toy.cpl
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------swhbifssxvqvqpumcowr Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------swhbifssxvqvqpumcowr-- From ipsec-bounces@ietf.org Tue Jun 22 19:15:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08940 for ; Tue, 22 Jun 2004 19:15:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctnZ-000861-CS; Tue, 22 Jun 2004 18:31:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcqdG-0004DJ-Lu for ipsec@megatron.ietf.org; Tue, 22 Jun 2004 15:08:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20367 for ; Tue, 22 Jun 2004 15:08:32 -0400 (EDT) From: housley@vigilsec.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcqdF-0003iB-4J for ipsec@ietf.org; Tue, 22 Jun 2004 15:08:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcqcV-0003LO-00 for ipsec@ietf.org; Tue, 22 Jun 2004 15:07:48 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bcqbr-0002y1-00 for ipsec@ietf.org; Tue, 22 Jun 2004 15:07:07 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5MJ4lP02381 for ; Tue, 22 Jun 2004 15:04:47 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5MJ4SpR017202 for ; Tue, 22 Jun 2004 15:04:28 -0400 (EDT) Message-Id: <200406221904.i5MJ4SpR017202@nutshell.tislabs.com> Received: from unknown(200.252.145.60) by nutshell.tislabs.com via csmap (V6.0) id srcAAAzdaqKH; Tue, 22 Jun 04 15:04:20 -0400 To: ipsec@lists.tislabs.com Date: Tue, 22 Jun 2004 16:09:31 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=HTML_20_30, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MIME_BOUND_NEXTPART, MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] (no subject) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit +++ Attachment: No Virus found +++ Bitdefender AntiVirus - www.bitdefender.com ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="message.zip.htm" Content-Disposition: attachment; filename="message.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: message.zip
Virus name: W32/Netsky.p@MM!zip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0016----=_NextPart_000_0016-- From ipsec-bounces@ietf.org Tue Jun 22 20:19:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16086 for ; Tue, 22 Jun 2004 20:19:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bctos-0008OP-SZ; Tue, 22 Jun 2004 18:32:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcshB-0001KM-8t for ipsec@megatron.ietf.org; Tue, 22 Jun 2004 17:20:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29290 for ; Tue, 22 Jun 2004 17:20:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bcsh9-0006l5-Sk for ipsec@ietf.org; Tue, 22 Jun 2004 17:20:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BcsgE-0006Mo-00 for ipsec@ietf.org; Tue, 22 Jun 2004 17:19:47 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BcsfJ-0005yM-00 for ipsec@ietf.org; Tue, 22 Jun 2004 17:18:49 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5MLGUP11045 for ; Tue, 22 Jun 2004 17:16:30 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5MLGA2o003673 for ; Tue, 22 Jun 2004 17:16:10 -0400 (EDT) Received: from ool-18e40942.dyn.optonline.net(24.228.9.66) by nutshell.tislabs.com via csmap (V6.0) id srcAAAdDaGkh; Tue, 22 Jun 04 17:16:07 -0400 Date: Tue, 22 Jun 2004 17:18:54 -0500 To: "Ipsec" From: "Uri" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ooxszqnslwtvbynafsnl" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.0 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Yahoo! X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------ooxszqnslwtvbynafsnl Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ooxszqnslwtvbynafsnl Content-Type: text/html; name="Manufacture.scr.htm" Content-Disposition: attachment; filename="Manufacture.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Manufacture.scr
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------ooxszqnslwtvbynafsnl Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------ooxszqnslwtvbynafsnl-- From ipsec-bounces@ietf.org Thu Jun 24 13:32:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03053 for ; Thu, 24 Jun 2004 13:32:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXJV-0001hc-Mm; Thu, 24 Jun 2004 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd8O0-0000MR-Ht for ipsec@megatron.ietf.org; Wed, 23 Jun 2004 10:06:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29223 for ; Wed, 23 Jun 2004 09:10:34 -0400 (EDT) From: jis@mit.edu Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd7WN-0006lY-QP for ipsec@ietf.org; Wed, 23 Jun 2004 09:10:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd7VL-0006MN-00 for ipsec@ietf.org; Wed, 23 Jun 2004 09:09:32 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bd7Ur-0005y3-00 for ipsec@ietf.org; Wed, 23 Jun 2004 09:09:01 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5ND6dP27262 for ; Wed, 23 Jun 2004 09:06:39 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5ND6LBh023467 for ; Wed, 23 Jun 2004 09:06:21 -0400 (EDT) Message-Id: <200406231306.i5ND6LBh023467@nutshell.tislabs.com> Received: from unknown(203.81.211.126) by nutshell.tislabs.com via csmap (V6.0) id srcAAAuKayZT; Wed, 23 Jun 04 09:06:11 -0400 To: ipsec@lists.tislabs.com Date: Wed, 23 Jun 2004 18:08:50 +0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 1 X-MSMail-Priority: High X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.4 required=5.0 tests=HTML_FONTCOLOR_RED, HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2,MIME_BOUND_NEXTPART, MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME, X_MSMAIL_PRIORITY_HIGH,X_PRIORITY_HIGH autolearn=no version=2.60 Subject: [Ipsec] Failed (ipsec@lists.tislabs.com) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" X-MIME-Autoconverted: from 8bit to quoted-printable by lists.tislabs.com id i5ND6dP27262 Content-Transfer-Encoding: quoted-printable Mail Delivery Error - This mail contains unicode characters ------------- failed message ------------- ,+8_h6Ai=DF)QtAQ-?fBh11(_zut<0=FCnl0cf2U'v_W|=F6#Y s=FCn7a3x?U3KrA(q=E4de('7nm2=F6ka6?_VB9KL=FCcV_r=FC4W weO9L<| D% Translated message has been attached. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="msg9392.pif.htm" Content-Disposition: attachment; filename="msg9392.pif.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: msg9392.pif
Virus name: W32/Netsky.q@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0016----=_NextPart_000_0016-- From ipsec-bounces@ietf.org Thu Jun 24 13:36:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03606 for ; Thu, 24 Jun 2004 13:36:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXK2-0001vh-7t; Thu, 24 Jun 2004 12:43:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bd8nH-0000rO-EF for ipsec@megatron.ietf.org; Wed, 23 Jun 2004 10:32:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18624 for ; Wed, 23 Jun 2004 07:11:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bd5et-00026v-B6 for ipsec@ietf.org; Wed, 23 Jun 2004 07:11:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bd5bO-00014u-00 for ipsec@ietf.org; Wed, 23 Jun 2004 07:07:38 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bd5YZ-0000Ge-00 for ipsec@ietf.org; Wed, 23 Jun 2004 07:04:43 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5NB2NP16059 for ; Wed, 23 Jun 2004 07:02:23 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5NB24p9004715 for ; Wed, 23 Jun 2004 07:02:04 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAvFayhj; Wed, 23 Jun 04 07:01:56 -0400 Date: Wed, 23 Jun 2004 12:10:49 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------lbovuxfopsynxxmtjrzq" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Encrypted document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------lbovuxfopsynxxmtjrzq Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------lbovuxfopsynxxmtjrzq Content-Type: text/html; name="Document.vbs.htm" Content-Disposition: attachment; filename="Document.vbs.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Document.vbs
Virus name: W32/Bagle.aa@MM!vbs

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------lbovuxfopsynxxmtjrzq Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------lbovuxfopsynxxmtjrzq-- From ipsec-bounces@ietf.org Thu Jun 24 15:35:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18875 for ; Thu, 24 Jun 2004 15:35:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPp-0003b4-5q; Thu, 24 Jun 2004 12:49:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdFc6-0003rC-Ka for ipsec@megatron.ietf.org; Wed, 23 Jun 2004 17:49:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20724 for ; Wed, 23 Jun 2004 17:48:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdFc5-0002Tw-0r for ipsec@ietf.org; Wed, 23 Jun 2004 17:49:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdFb9-00027a-00 for ipsec@ietf.org; Wed, 23 Jun 2004 17:48:04 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BdFaY-0001jQ-00; Wed, 23 Jun 2004 17:47:26 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1BdFXJ-0003Ay-5c; Wed, 23 Jun 2004 17:44:05 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Wed, 23 Jun 2004 17:44:05 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@ietf.org Subject: [Ipsec] Last Call: 'Cryptographic Algorithm Implementation Requirements For ESP And AH' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has received a request from the IP Security Protocol WG to consider the following document: - 'Cryptographic Algorithm Implementation Requirements For ESP And AH ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-07-07. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-01.txt _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 24 15:39:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19454 for ; Thu, 24 Jun 2004 15:39:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPu-0003cl-CR; Thu, 24 Jun 2004 12:49:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdGSf-0001KN-6p for ipsec@megatron.ietf.org; Wed, 23 Jun 2004 18:43:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25255 for ; Wed, 23 Jun 2004 18:43:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdGSd-0007XZ-FR for ipsec@ietf.org; Wed, 23 Jun 2004 18:43:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdGRT-0007Aj-00 for ipsec@ietf.org; Wed, 23 Jun 2004 18:42:08 -0400 Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx with esmtp (Exim 4.12) id 1BdGQg-0006Rr-00 for ipsec@ietf.org; Wed, 23 Jun 2004 18:41:18 -0400 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.175); Wed, 23 Jun 2004 15:41:42 -0700 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 15:41:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Improvement for IPsec: Better PMTUD, ICMP Processing, and signalling in general!? Date: Wed, 23 Jun 2004 15:40:47 -0700 Message-ID: Thread-Topic: [Ipsec] Improvement for IPsec: Better PMTUD, ICMP Processing, and signalling in general!? thread-index: AcRUNa1q48r0zLbqRGC8/w8FUx+VDgFOy9yQ From: "Charlie Kaufman" To: =?iso-8859-1?Q?Lars_V=F6lker?= , "Karen Seo" , "Stephen Kent" X-OriginalArrivalTime: 23 Jun 2004 22:41:28.0231 (UTC) FILETIME=[38CD5B70:01C45973] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,PLING_QUERY autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Warning: The following is only my take on the current situation. I could = be wrong. Or I could be right but politically incorrect. ESP and AH SAs are defined as unidirectional because one can imagine = circumstances where unidirectional SAs would be desirable, people were = not willing to ignore that obscure case, and it seemed easier to deal = with the awkwardness to two unidirectional SAs in the common case than = to specify both unidirectional and bidirectional ESP and AH SAs = (including all the ways in which they were different). The "most commonly cited" cases for unidirectional SAs are for = multicast, but I'm pretty sure there are others. IKE SAs are bidirectional, and all ESP and AH SAs negotiated by IKE are = negotiated in pairs. In IKEv2, those paired SAs remain semantically = paired after creation. They must be closed together, for example. This = may have also been true in IKEv1 (it's hard to tell from the spec). Some = other keying protocol would be necessary for setting up multicast or = unidirectional SAs. So I believe that for nodes using IKEv2 for keying, the fact that ESP = and AH SAs are unidirectional is matter of specification only. An = implementation could "think" of them as paired without changing any bits = on the wire. I would expect most implementations to do just that. --Charlie -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Lars V=F6lker Sent: Thursday, June 17, 2004 1:49 AM To: 'Karen Seo'; 'Stephen Kent' Cc: ipsec@ietf.org Subject: [Ipsec] Improvement for IPsec: Better PMTUD, ICMP = Processing,and signalling in general!? Abstract: Several problems of IPsec are caused by the concept of unicast SAs. With very small and compatible changes major improvements for = inband PMTUD, ICMP processing, and others might be achieved. While implementing the IPsec standard (and a few modifications) I was wondering why the IPsec standard described SA as being unicast but did = not provide a simple way to form bidirectional combinations while SAs are = mostly used in pairs. With IPsec secure bidirectional connections are possible as long as two matching SAs are created (outgoing and incoming). Problems just arise in error conditions and when other means for signalling are used. In-band = PMTUD and Signalling Messages are examples. The changes to IPsec would only include a new field in the SA structure = to point to the inverse SA, the PF_KEY API would get a new function to set = up the relationship, and the Key Exchange daemons and setkey Utilities = could use this PF_KEY function to set up the new field in the SAD. Cons:=20 Some small changes are required iff additional features are wanted. The changes are rather small and could be initially marked as MAY. No Flag = Day! The changes to Key Exchange daemons and Utilities are also very small = since SAs are setup in pairs in almost all cases anyway and in other cases the = new SA field does not need to be set. A minimal set of signalling message needs to be handled by IPsec since = the key exchange daemon can not handle these. Pros: The small changes would give us a foundation to solve some major implementation problems and close some of the possible bugs in implementations. A working PMTUD would allow us to fragment before protecting packets without the risk of getting the packet discarded in nested tunnel scenarios. Signalling messages can be sent back in a = secure manner (no data leakage) and it's obvious for the receiver for which SA = the message is meant. I am looking forward to your replies Lars --=20 Lars V=F6lker=20 Institute of Telematics, University of Karlsruhe, Germany Phone: +49 721 608 6397 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 24 15:43:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20084 for ; Thu, 24 Jun 2004 15:43:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdXPz-0003fQ-D2; Thu, 24 Jun 2004 12:49:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BdHMc-0007lO-O4 for ipsec@megatron.ietf.org; Wed, 23 Jun 2004 19:41:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27810 for ; Wed, 23 Jun 2004 19:41:08 -0400 (EDT) From: sheila.frankel@nist.gov Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BdHMa-0005m7-ON for ipsec@ietf.org; Wed, 23 Jun 2004 19:41:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BdHLf-0005Pe-00 for ipsec@ietf.org; Wed, 23 Jun 2004 19:40:12 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BdHLG-00052v-00 for ipsec@ietf.org; Wed, 23 Jun 2004 19:39:47 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5NNbPP06219 for ; Wed, 23 Jun 2004 19:37:25 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5NNBDY3015294 for ; Wed, 23 Jun 2004 19:11:13 -0400 (EDT) Message-Id: <200406232311.i5NNBDY3015294@nutshell.tislabs.com> Received: from unknown(200.252.145.60) by nutshell.tislabs.com via csmap (V6.0) id srcAAA3wa41D; Wed, 23 Jun 04 19:11:09 -0400 To: ipsec@lists.tislabs.com Date: Wed, 23 Jun 2004 20:16:21 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=HTML_20_30, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MIME_BOUND_NEXTPART, MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: Status X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit First part of the secure mail is available. +++ Attachment: No Virus found +++ MC-Afee AntiVirus - www.mcafee.com ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="document.zip.htm" Content-Disposition: attachment; filename="document.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: document.zip
Virus name: W32/Netsky.p@MM!zip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0016----=_NextPart_000_0016-- From ipsec-bounces@ietf.org Fri Jun 25 13:21:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25769 for ; Fri, 25 Jun 2004 13:21:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdu9S-0004GG-Ii; Fri, 25 Jun 2004 13:06:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdtqo-0003Ma-28 for ipsec@megatron.ietf.org; Fri, 25 Jun 2004 12:46:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21481 for ; Fri, 25 Jun 2004 12:46:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bdtqn-0000YZ-3i for ipsec@ietf.org; Fri, 25 Jun 2004 12:46:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bdtot-00001k-00 for ipsec@ietf.org; Fri, 25 Jun 2004 12:44:56 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bdtmk-0007ER-00 for ipsec@ietf.org; Fri, 25 Jun 2004 12:42:42 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5PGeJP12749 for ; Fri, 25 Jun 2004 12:40:19 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5PGe2tR021659 for ; Fri, 25 Jun 2004 12:40:02 -0400 (EDT) Received: from aragorn.bbn.com(128.33.0.62) by nutshell.tislabs.com via csmap (V6.0) id srcAAACjairQ; Fri, 25 Jun 04 12:40:00 -0400 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i5PGgZ7Z020924 for ; Fri, 25 Jun 2004 12:42:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Fri, 25 Jun 2004 11:29:01 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Ipsec] sad news X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Charlie Lynn was a senior technical contributor at BBN for many years. He made very significant contributions to the IPsec documents we produced, both the current set of RFCs and the IDs that will replace them. Charlie passed away suddenly on Monday. We will miss him greatly, in both professional and personal contexts. We anticipate including a dedication to Charlie in the next rev of 2401bis, the release of which will be delayed somewhat. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 25 13:49:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27597 for ; Fri, 25 Jun 2004 13:49:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bdudg-0008Fs-3j; Fri, 25 Jun 2004 13:37:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BduQu-0003cv-PG for ipsec@megatron.ietf.org; Fri, 25 Jun 2004 13:24:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26136 for ; Fri, 25 Jun 2004 13:24:11 -0400 (EDT) From: Francois.PAUL@fr.thalesgroup.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BduQt-0003Gc-P9 for ipsec@ietf.org; Fri, 25 Jun 2004 13:24:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BduPn-0002s0-00 for ipsec@ietf.org; Fri, 25 Jun 2004 13:23:03 -0400 Received: from gwout.thalesgroup.com ([195.101.39.227]) by ietf-mx with esmtp (Exim 4.12) id 1BduOO-00025O-00 for ipsec@ietf.org; Fri, 25 Jun 2004 13:21:36 -0400 Received: from thalescan.corp.thales (200.3.2.3) by GWOUT.thalesgroup.com (NPlex 6.5.026) id 40D9AF1C0009E420 for ipsec@ietf.org; Fri, 25 Jun 2004 19:20:33 +0200 Received: from hiplex.tsbh.thales ([10.33.19.4]) by thalescan with InterScan Messaging Security Suite; Fri, 25 Jun 2004 19:20:05 +0200 Received: from hiplex.tsbh.thales (10.33.21.5) by hiplex.tsbh.thales (NPlex 6.5.026) id 40C82B1F0008EF86 for ipsec@ietf.org; Fri, 25 Jun 2004 19:20:05 +0200 Received: from complex.tcfr.thales ([202.3.3.26]) by hiplex with InterScan Messaging Security Suite; Fri, 25 Jun 2004 19:20:04 +0200 Received: from complex.tcfr.thales (202.3.3.26) by complex.tcfr.thales (NPlex 6.5.026) id 40C6C9CF0007EFEA for ipsec@ietf.org; Fri, 25 Jun 2004 19:18:43 +0200 Received: from NODALNET.clb.tcfr.thales ([146.11.5.4]) by complex with InterScan Messaging Security Suite; Fri, 25 Jun 2004 19:18:43 +0200 Received: by NODALNET.clb.tcfr.thales with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jun 2004 19:20:04 +0200 Message-ID: <66CE949D18BCB249ABE8D9AF48C4F1CE2D499A@helios.clb.tcfr.thales> To: ipsec@ietf.org Date: Fri, 25 Jun 2004 19:20:06 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Subject: [Ipsec] Layer 2 processing inside IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hello, I am looking for a simple and efficient way to combine ROHC (Robust header compression) and IPsec in tunnel mode, in the case of non-NULL ESP encryption. This may be of high interest in the context of transporting VoIP flows through encrypted tunnels, for example. RFC 3095 (ROHC) seems to deal only with these two cases : - If non-NULL encryption is used, the profile proposed in section 5.12 of RFC 3095 is limited to the compression of the ESP/IP header chain. - If NULL encryption algorithm is used (i.e : only authentication is afforded by the SA through ESP), then section 5.8.4.3 describes how the compressed header chain may be extended to higher level protocols (IP for tunnel mode, UDP, RTP). I wonder if the following possibility has already been considered : In the case of tunnel mode with ESP non-NULL encryption, IPsec applies encryption to the whole IP packet. So, it is possible to insert ROHC compression just before ESP encryption. At the destination IPsec tunnel endpoint, ROHC decompression may be inserted just after ESP decryption. In order for this ROHC insertion to map cleanly with the IPsec framework, it should be considered as a new type of "next header". I looked up in http://www.iana.org/assignments/protocol-numbers.txt, but I did not find any number allocated to ROHC in this protocol number space : should it be possible to apply for one ? Perhaps it should be necessary to extend IKE child SA parameter values in order for such a tunnel to be negotiated. When RTP/UDP/IP plain text packets are ROHC-compressed and then ESP-encrypted, the ROHC profile defined in RFC 3095 sec. 5.8.4.3 (ESP/IP) may be applied on the outer IP pakcets, on each IP hop of the "unprotected" IP network. Does any one know if such a mechanism was proposed ? F. Paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Jun 26 05:18:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29448 for ; Sat, 26 Jun 2004 05:18:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Be9HF-0004cS-UT; Sat, 26 Jun 2004 05:15:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Be9DA-0003YH-Sh for ipsec@megatron.ietf.org; Sat, 26 Jun 2004 05:11:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29276 for ; Sat, 26 Jun 2004 05:10:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Be9D8-0005Zm-8p for ipsec@ietf.org; Sat, 26 Jun 2004 05:10:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Be9CE-0005K2-00 for ipsec@ietf.org; Sat, 26 Jun 2004 05:10:03 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Be9Ba-00051Y-00 for ipsec@ietf.org; Sat, 26 Jun 2004 05:09:22 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i5Q98mp23211; Sat, 26 Jun 2004 11:08:48 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5Q98mSj050201; Sat, 26 Jun 2004 11:08:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406260908.i5Q98mSj050201@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Francois.PAUL@fr.thalesgroup.com Subject: Re: [Ipsec] Layer 2 processing inside IPsec In-reply-to: Your message of Fri, 25 Jun 2004 19:20:06 +0200. <66CE949D18BCB249ABE8D9AF48C4F1CE2D499A@helios.clb.tcfr.thales> Date: Sat, 26 Jun 2004 11:08:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: Does any one know if such a mechanism was proposed ? => look at draft-vilhuber-hco{ip,esp}-xx.txt This is also a goal of the MOBIKE WG. BTW I believe we can do more in the ESP tunnel context than in the standard one, for instance class more header fields as "static" and reuse the SPI as a context number... Can we continue offline? Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jun 27 20:45:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15287 for ; Sun, 27 Jun 2004 20:45:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bek7s-0006ZM-L4; Sun, 27 Jun 2004 20:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bek6Z-0006LD-Lu for ipsec@megatron.ietf.org; Sun, 27 Jun 2004 20:34:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14864 for ; Sun, 27 Jun 2004 20:34:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bek6Y-0006J6-3H for ipsec@ietf.org; Sun, 27 Jun 2004 20:34:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bek5f-00067v-00 for ipsec@ietf.org; Sun, 27 Jun 2004 20:33:43 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1Bek5B-0005xC-00 for ipsec@ietf.org; Sun, 27 Jun 2004 20:33:13 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5S0XBil003046; Sun, 27 Jun 2004 18:33:11 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5S0XBcc000493; Sun, 27 Jun 2004 20:33:11 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5S0XBFX027491; Sun, 27 Jun 2004 20:33:11 -0400 (EDT) Message-Id: <200406280033.i5S0XBFX027491@thunk.east.sun.com> From: Bill Sommerfeld To: Francois.PAUL@fr.thalesgroup.com Subject: Re: [Ipsec] Layer 2 processing inside IPsec In-Reply-To: Your message of "Fri, 25 Jun 2004 19:20:06 +0200." <66CE949D18BCB249ABE8D9AF48C4F1CE2D499A@helios.clb.tcfr.thales> Date: Sun, 27 Jun 2004 20:33:11 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sommerfeld@east.sun.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I just skimmed rfc3095 for the first time so I might have missed something, but I can see a couple potential problems: - ROHC requires that the lower layer not reorder packets, whereas IPsec includes replay protection with a sequence number, it does *not* put packets back into their original order on receive. - ROHC changes the encoding of header fields which are used for access control purposes by IPsec (inner tunnel headers, payload protocol, and transport-layer ports); a naive integration of ROHC inside IPsec would bypass IPsec's post-decryption access controls. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 28 04:39:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16694 for ; Mon, 28 Jun 2004 04:39:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BercK-0002Zs-P0; Mon, 28 Jun 2004 04:35:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BerbL-0002T3-6c for ipsec@megatron.ietf.org; Mon, 28 Jun 2004 04:34:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16375 for ; Mon, 28 Jun 2004 04:34:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BerbJ-0000fR-03 for ipsec@ietf.org; Mon, 28 Jun 2004 04:34:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BeraM-0000Um-00 for ipsec@ietf.org; Mon, 28 Jun 2004 04:33:55 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1BerZi-0000K9-00 for ipsec@ietf.org; Mon, 28 Jun 2004 04:33:14 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10) id 1BerZX-0000u1-00; Mon, 28 Jun 2004 10:33:03 +0200 Received: from i72xindi.tm.uni-karlsruhe.de ([141.3.71.103] helo=i72voelker) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1BerZX-0006Xw-00; Mon, 28 Jun 2004 10:33:03 +0200 From: =?iso-8859-1?Q?Lars_V=F6lker?= To: Subject: RE: [Ipsec] Layer 2 processing inside IPsec Date: Mon, 28 Jun 2004 10:33:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <200406280033.i5S0XBFX027491@thunk.east.sun.com> Thread-Index: AcRcqXhBl5qOwNGIRxaP6ueZmu9GiAAMNJyw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > - ROHC requires that the lower layer not reorder packets, whereas > IPsec includes replay protection with a sequence number, it does *not* > put packets back into their original order on receive. That=92s the main problem but if ROHC and IPsec would be just used for = the access link (AFAIK: that=92s where it should be used) the problem is = rather small. (Single link, just 1 hop, probably no reordering.) There should not be a problem to use ROHC first and IPsec after that. = Just set up the SPD in the right way (e.g. Selector=3DIPs only). = Unfortunately ROHC is not always able to reduce packet size so much that IPsec would not = have to fragment the ROHC packets... depends on your data. ROHC was designed to be used over cellular links. I don't think that = ROHC would work that well over the internet for the problem with packet reordering. Lars -- Lars V=F6lker Institute of Telematics, University of Karlsruhe=20 Zirkel 2, 76128 Karlsruhe Phone: +49 721 - 608 6397 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 28 05:52:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20050 for ; Mon, 28 Jun 2004 05:52:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Besm0-0002QM-Cc; Mon, 28 Jun 2004 05:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bescg-0001Q7-Mn for ipsec@megatron.ietf.org; Mon, 28 Jun 2004 05:40:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19628 for ; Mon, 28 Jun 2004 05:40:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Besce-0006nB-EA for ipsec@ietf.org; Mon, 28 Jun 2004 05:40:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Besbh-0006Xz-00 for ipsec@ietf.org; Mon, 28 Jun 2004 05:39:21 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Besan-0006Hm-00 for ipsec@ietf.org; Mon, 28 Jun 2004 05:38:25 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5S9Zxg24573 for ; Mon, 28 Jun 2004 05:35:59 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5S9ZlNs022915 for ; Mon, 28 Jun 2004 05:35:47 -0400 (EDT) Received: from unknown(213.234.225.186) by nutshell.tislabs.com via csmap (V6.0) id srcAAAXFaOVS; Mon, 28 Jun 04 05:35:44 -0400 Date: Mon, 28 Jun 2004 13:39:03 +0300 To: "Ipsec" From: "Tytso" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------muvihdsirfqjyyybhsds" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_30_40, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Msg reply X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------muvihdsirfqjyyybhsds Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------muvihdsirfqjyyybhsds Content-Type: text/html; name="Manufacture.cpl.htm" Content-Disposition: attachment; filename="Manufacture.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Manufacture.cpl
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------muvihdsirfqjyyybhsds Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------muvihdsirfqjyyybhsds-- From ipsec-bounces@ietf.org Mon Jun 28 06:28:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22793 for ; Mon, 28 Jun 2004 06:28:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BetKJ-0000ZH-CE; Mon, 28 Jun 2004 06:25:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BetCJ-00086Z-6M for ipsec@megatron.ietf.org; Mon, 28 Jun 2004 06:17:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22178 for ; Mon, 28 Jun 2004 06:17:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BetCG-00005y-Re for ipsec@ietf.org; Mon, 28 Jun 2004 06:17:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BetBO-0007dD-00 for ipsec@ietf.org; Mon, 28 Jun 2004 06:16:15 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1BetAi-0007NF-00 for ipsec@ietf.org; Mon, 28 Jun 2004 06:15:32 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i5SAEwV12836; Mon, 28 Jun 2004 12:14:58 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5SAEwSj056812; Mon, 28 Jun 2004 12:14:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406281014.i5SAEwSj056812@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: sommerfeld@east.sun.com Subject: Re: [Ipsec] Layer 2 processing inside IPsec In-reply-to: Your message of Sun, 27 Jun 2004 20:33:11 EDT. <200406280033.i5S0XBFX027491@thunk.east.sun.com> Date: Mon, 28 Jun 2004 12:14:58 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: I just skimmed rfc3095 for the first time so I might have missed something, but I can see a couple potential problems: - ROHC requires that the lower layer not reorder packets, whereas IPsec includes replay protection with a sequence number, it does *not* put packets back into their original order on receive. => I disagree: IPsec does not change the order (so it can't have a negative effect) and more, it helps the detection of reordering (by something else) and lost (i.e., it can have a positive effect). - ROHC changes the encoding of header fields which are used for access control purposes by IPsec (inner tunnel headers, payload protocol, and transport-layer ports); a naive integration of ROHC inside IPsec would bypass IPsec's post-decryption access controls. => I believe you refer to RFC 2401 section 5.2.1 steps 2 and 3. Obviously the decompression must be integrated, i.e., done just after decryption and before sanity post-decryption checks. BTW the checked fields are likely not transported in packets but taken from the decompression context. IMHO this is an implementation issue more than a real problem. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 28 07:04:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24633 for ; Mon, 28 Jun 2004 07:04:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BetsH-0004b9-QB; Mon, 28 Jun 2004 07:00:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Betn1-0003xS-Le for ipsec@megatron.ietf.org; Mon, 28 Jun 2004 06:55:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24276 for ; Mon, 28 Jun 2004 06:55:04 -0400 (EDT) From: housley@vigilsec.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Betmz-000191-4G for ipsec@ietf.org; Mon, 28 Jun 2004 06:55:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Betlw-0000v2-00 for ipsec@ietf.org; Mon, 28 Jun 2004 06:54:01 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Betl2-0000iS-00 for ipsec@ietf.org; Mon, 28 Jun 2004 06:53:04 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5SAoag00942 for ; Mon, 28 Jun 2004 06:50:37 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5SAoQK7003458 for ; Mon, 28 Jun 2004 06:50:26 -0400 (EDT) Message-Id: <200406281050.i5SAoQK7003458@nutshell.tislabs.com> Received: from localhost(203.210.219.150) by nutshell.tislabs.com via csmap (V6.0) id srcAAA1qaaNg; Mon, 28 Jun 04 06:50:16 -0400 To: ipsec@lists.tislabs.com Date: Mon, 28 Jun 2004 17:52:59 +0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_00000925.000010C6" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=HTML_30_40, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MISSING_MIMEOLE, MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] here, the serials X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0014_00000925.000010C6 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit here, the cheats ------=_NextPart_000_0014_00000925.000010C6 Content-Type: text/html; name="worker.htm.scr.htm" Content-Disposition: attachment; filename="worker.htm.scr.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: worker.htm.scr
Virus name: W32/Netsky.c@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0014_00000925.000010C6 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0014_00000925.000010C6-- From ipsec-bounces@ietf.org Mon Jun 28 08:40:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01734 for ; Mon, 28 Jun 2004 08:40:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BevHX-0008BA-BB; Mon, 28 Jun 2004 08:30:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BevBA-0007PI-Ky for ipsec@megatron.ietf.org; Mon, 28 Jun 2004 08:24:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00047 for ; Mon, 28 Jun 2004 08:24:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BevBA-0007WM-4K for ipsec@ietf.org; Mon, 28 Jun 2004 08:24:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BevAF-0007Hn-00 for ipsec@ietf.org; Mon, 28 Jun 2004 08:23:12 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1Bev9N-00073u-00 for ipsec@ietf.org; Mon, 28 Jun 2004 08:22:17 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i5SCM7il004192; Mon, 28 Jun 2004 06:22:07 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5SCM6cc021242; Mon, 28 Jun 2004 08:22:06 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5SCM6rp002436; Mon, 28 Jun 2004 08:22:06 -0400 (EDT) Message-Id: <200406281222.i5SCM6rp002436@thunk.east.sun.com> From: Bill Sommerfeld To: Francis Dupont Subject: Re: [Ipsec] Layer 2 processing inside IPsec In-Reply-To: Your message of "Mon, 28 Jun 2004 12:14:58 +0200." <200406281014.i5SAEwSj056812@givry.rennes.enst-bretagne.fr> Date: Mon, 28 Jun 2004 08:22:06 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sommerfeld@east.sun.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > - ROHC requires that the lower layer not reorder packets, whereas > IPsec includes replay protection with a sequence number, it does *not* > put packets back into their original order on receive. > > I disagree: IPsec does not change the order That's not at all clear to me. > (so it can't have a negative effect) and more, it helps the > detection of reordering (by something else) and lost (i.e., it can > have a positive effect). No, it seems perfectly clear. IPsec runs over IP, which is allowed to reorder packets. ROHC runs over link layers which are not allowed to reorder packets. Unless you have some impossible-to-obtain-in-general out-of-band knowledge that an IPsec tunnel will only traverse links *and* routers which never reorder packets, you cannot naively use ROHC over IPsec. An integrated IPsec - ROHC implementation could look at the IPsec sequence number and insert its own reorder buffer, but such an integration would not be as simple as defining an IP protocol number for ROHC. > - ROHC changes the encoding of header fields which are used for > access control purposes by IPsec (inner tunnel headers, payload > protocol, and transport-layer ports); a naive integration of ROHC > inside IPsec would bypass IPsec's post-decryption access controls. > > I believe you refer to RFC 2401 section 5.2.1 steps 2 and 3. > Obviously the decompression must be integrated, i.e., done just after > decryption and before sanity post-decryption checks. BTW the checked > fields are likely not transported in packets but taken from the > decompression context. IMHO this is an implementation issue more > than a real problem. It's an architectural issue. An integrated IPsec-ROHC means that the ROHC would have to be inserted into the *middle* of IPsec processing, between the policy enforcement part and the encryption part. Again, not so simple as merely defining an IP payload number for ROHC. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 28 11:31:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11607 for ; Mon, 28 Jun 2004 11:31:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bey0X-0007LC-TM; Mon, 28 Jun 2004 11:25:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bexxj-0006ud-45 for ipsec@megatron.ietf.org; Mon, 28 Jun 2004 11:22:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11089 for ; Mon, 28 Jun 2004 11:22:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bexxi-0004xM-7Z for ipsec@ietf.org; Mon, 28 Jun 2004 11:22:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bexwm-0004g5-00 for ipsec@ietf.org; Mon, 28 Jun 2004 11:21:29 -0400 Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx with smtp (Exim 4.12) id 1Bexvc-000452-00 for ipsec@ietf.org; Mon, 28 Jun 2004 11:20:16 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id i5SFJgFp027339 for ; Mon, 28 Jun 2004 11:19:42 -0400 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id i5SFJfsw027334; Mon, 28 Jun 2004 11:19:41 -0400 Received: from pkoning.equallogic.com ([172.16.1.220]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Jun 2004 11:19:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16608.14091.947495.390997@gargle.gargle.HOWL> Date: Mon, 28 Jun 2004 11:19:39 -0400 From: Paul Koning To: Francis.Dupont@enst-bretagne.fr Subject: Re: [Ipsec] Layer 2 processing inside IPsec References: <200406280033.i5S0XBFX027491@thunk.east.sun.com> <200406281014.i5SAEwSj056812@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 28 Jun 2004 15:19:41.0273 (UTC) FILETIME=[557D4C90:01C45D23] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, sommerfeld@east.sun.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "Francis" == Francis Dupont writes: Francis> In your previous mail you wrote: >>I just skimmed rfc3095 for >> the first time so I might have missed something, but I can >> see a couple potential problems: >> - ROHC requires that the lower layer not reorder packets, >> whereas IPsec includes replay protection with a sequence >> number, it does *not* put packets back into their original >> order on receive. Francis> => I disagree: IPsec does not change the order (so it can't Francis> have a negative effect) and more, it helps the detection of Francis> reordering (by something else) and lost (i.e., it can have a Francis> positive effect). Not true. A typical IPsec implementation probably doesn't reorder things, but since it's a datagram service it would be allowed to do so. And IPsec does NOT detect reordering. It detects replay (repeated packets). The typical "replay window" implementation will -- as a side effect -- reject reordering by an amount larger than the reply window, but that's just an artifact of the implementation, it's not the goal of that mechanism. The real point is that IP networks will reorder packets, as they are allowed to, and IPsec will not stand in the way. So if someone expects an IPsec-protected communication scheme to offer ordered delivery, they may get an unpleasant surprise because that's not what you're offered. In some cases, deploying IPsec may cause a lot of reordering. For example, some implementations send fragments in "reverse" order. That's not a really good idea, but it is perfectly legal. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 28 13:28:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17487 for ; Mon, 28 Jun 2004 13:28:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bezrt-0007on-5y; Mon, 28 Jun 2004 13:24:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bezi6-0006hH-7H for ipsec@megatron.ietf.org; Mon, 28 Jun 2004 13:14:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16852 for ; Mon, 28 Jun 2004 13:14:24 -0400 (EDT) From: clynn@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bezi5-0002pG-7v for ipsec@ietf.org; Mon, 28 Jun 2004 13:14:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bezh7-0002aa-00 for ipsec@ietf.org; Mon, 28 Jun 2004 13:13:26 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bezgm-0002M0-00 for ipsec@ietf.org; Mon, 28 Jun 2004 13:13:04 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5SHAag21824 for ; Mon, 28 Jun 2004 13:10:36 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5SHAOJm013359 for ; Mon, 28 Jun 2004 13:10:24 -0400 (EDT) Message-Id: <200406281710.i5SHAOJm013359@nutshell.tislabs.com> Received: from 200-207-116-35.dialdata.net.br(200.207.116.35) by nutshell.tislabs.com via csmap (V6.0) id srcAAAWZaqeA; Mon, 28 Jun 04 13:10:17 -0400 To: ipsec@lists.tislabs.com Date: Mon, 28 Jun 2004 14:16:07 -0300 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016----=_NextPart_000_0016" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.9 required=5.0 tests=HTML_20_30, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MIME_BOUND_NEXTPART, MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Re: document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Requested file. +++ Attachment: No Virus found +++ MessageLabs AntiVirus - www.messagelabs.com ------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/html; name="document.zip.htm" Content-Disposition: attachment; filename="document.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: document.zip
Virus name: W32/Netsky.p@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0016----=_NextPart_000_0016 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0016----=_NextPart_000_0016-- From ipsec-bounces@ietf.org Mon Jun 28 17:54:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11750 for ; Mon, 28 Jun 2004 17:54:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3kR-0005Xu-4M; Mon, 28 Jun 2004 17:33:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf3QT-0004Wr-E7 for ipsec@megatron.ietf.org; Mon, 28 Jun 2004 17:12:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06233 for ; Mon, 28 Jun 2004 17:12:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf3QS-0002LD-5M for ipsec@ietf.org; Mon, 28 Jun 2004 17:12:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf3FH-0000A7-00 for ipsec@ietf.org; Mon, 28 Jun 2004 17:00:55 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Bf35W-0005ie-00 for ipsec@ietf.org; Mon, 28 Jun 2004 16:50:50 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i5SKoFU32524; Mon, 28 Jun 2004 22:50:15 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5SKoFSj058706; Mon, 28 Jun 2004 22:50:15 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406282050.i5SKoFSj058706@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: sommerfeld@east.sun.com Subject: Re: [Ipsec] Layer 2 processing inside IPsec In-reply-to: Your message of Mon, 28 Jun 2004 08:22:06 EDT. <200406281222.i5SCM6rp002436@thunk.east.sun.com> Date: Mon, 28 Jun 2004 22:50:15 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: > I disagree: IPsec does not change the order That's not at all clear to me. => this is misunderstanding: IPsec itself doesn't change the order, IP can change it and is run under IPsec. you cannot naively use ROHC over IPsec. => I agree. BTW I am not interested by ROHC itself but by any compression which can work with IPsec. In fact I believe it still has to be designed/specified. An integrated IPsec - ROHC implementation could look at the IPsec sequence number and insert its own reorder buffer, but such an integration would not be as simple as defining an IP protocol number for ROHC. => nothing can be simple with ROHC (:-). IMHO we talk about ROHC just because it is the more sophisticated compression... It's an architectural issue. An integrated IPsec-ROHC means that the ROHC would have to be inserted into the *middle* of IPsec processing, between the policy enforcement part and the encryption part. => it seems we agree: something can be done but needs real work. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 28 18:04:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13796 for ; Mon, 28 Jun 2004 18:04:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf48c-0008Vx-AT; Mon, 28 Jun 2004 17:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf415-0002X0-Lx for ipsec@megatron.ietf.org; Mon, 28 Jun 2004 17:50:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11018 for ; Mon, 28 Jun 2004 17:50:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf413-0001qu-W5 for ipsec@ietf.org; Mon, 28 Jun 2004 17:50:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf3mL-0006rO-00 for ipsec@ietf.org; Mon, 28 Jun 2004 17:35:06 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Bf3Yt-00046O-00 for ipsec@ietf.org; Mon, 28 Jun 2004 17:21:11 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i5SLKTU03849; Mon, 28 Jun 2004 23:20:29 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5SLKTSj059076; Mon, 28 Jun 2004 23:20:30 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406282120.i5SLKTSj059076@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Paul Koning Subject: Re: [Ipsec] Layer 2 processing inside IPsec In-reply-to: Your message of Mon, 28 Jun 2004 11:19:39 EDT. <16608.14091.947495.390997@gargle.gargle.HOWL> Date: Mon, 28 Jun 2004 23:20:29 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@ietf.org, sommerfeld@east.sun.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: >> - ROHC requires that the lower layer not reorder packets, >> whereas IPsec includes replay protection with a sequence >> number, it does *not* put packets back into their original >> order on receive. Francis> => I disagree: IPsec does not change the order (so it can't Francis> have a negative effect) and more, it helps the detection of Francis> reordering (by something else) and lost (i.e., it can have a Francis> positive effect). Not true. => I already answered to Bill: this is misunderstanding... And IPsec does NOT detect reordering. => but IPsec uses an anti-replay counter which is always incremented at each packet in a SA: this counter can be used to detect reordering between the two ends of the SA. It detects replay (repeated packets). The typical "replay window" implementation will -- as a side effect -- reject reordering by an amount larger than the reply window, but that's just an artifact of the implementation, it's not the goal of that mechanism. => this is not what I tried to mean. The real point is that IP networks will reorder packets, as they are allowed to, and IPsec will not stand in the way. So if someone expects an IPsec-protected communication scheme to offer ordered delivery, they may get an unpleasant surprise because that's not what you're offered. => same. In some cases, deploying IPsec may cause a lot of reordering. For example, some implementations send fragments in "reverse" order. That's not a really good idea, but it is perfectly legal. => no name please (:-). My idea is if someone designs a dedicated compression for IPsec he could use the anti-replay counter to at least detect and perhaps support small amount of reordering or lost. So compression can take benefit of IPsec, when Bill's message was a bit negative/pessimistic. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 28 18:41:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18410 for ; Mon, 28 Jun 2004 18:41:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4U4-0003s5-Kf; Mon, 28 Jun 2004 18:20:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4Jh-0005h7-BI for ipsec@megatron.ietf.org; Mon, 28 Jun 2004 18:09:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15232 for ; Mon, 28 Jun 2004 18:09:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4Jf-000633-V8 for ipsec@ietf.org; Mon, 28 Jun 2004 18:09:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4Fh-0004yX-00 for ipsec@ietf.org; Mon, 28 Jun 2004 18:05:26 -0400 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Bf47R-00039O-00 for ipsec@ietf.org; Mon, 28 Jun 2004 17:56:53 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i5SLuIU06981; Mon, 28 Jun 2004 23:56:18 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5SLuJSj059340; Mon, 28 Jun 2004 23:56:19 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406282156.i5SLuJSj059340@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jan Vilhuber Subject: Re: [Ipsec] Layer 2 processing inside IPsec In-reply-to: Your message of Mon, 28 Jun 2004 10:21:19 PDT. Date: Mon, 28 Jun 2004 23:56:19 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: > Does any one know if such a mechanism was proposed ? > > => look at draft-vilhuber-hco{ip,esp}-xx.txt I bet these have long since expired, but I'd be happy to resubmit them (as individual submissions). When I first submitted these, there flood of responses and comments was astounding. I got one single email about it all (saying essentially "Cool.. I like it and have been thinking along similar lines"; I think that might even have been you, francis :). => I remember to have sent such comment (:-)! Is the IETF now interested in this thing? Previously, comments (in other working groups and other documents) were basically "Why would we want to do this?" (which to me seems obvious, of course). => from MOBIKE charter (goal lists): (5) Reduction of header overhead involved with mobility-related tunnels. This is a performance requirement in wireless environments. So now there is a place for your work! > Can we continue offline? => this was for Francois (I expected he was French :-) I'm game if you want to include me on a private exchange. I still have the drafts, and we can use them as a start, if you like. => IMHO you should resubmit then before the dead-line! Thanks Francis.Dupont@enst-bretagne.fr PS: BTW we have a whole team of compression (mainly ROHC as it is what 3GPP wants) experts. The only missing people are the people who are interested to buy the idea: at the moment we are at least three who'd like to sell it (:-)... _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 28 19:01:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20163 for ; Mon, 28 Jun 2004 19:01:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4uY-0003Vj-5a; Mon, 28 Jun 2004 18:47:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bf4Up-0004Qk-Pi for ipsec@megatron.ietf.org; Mon, 28 Jun 2004 18:21:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17399 for ; Mon, 28 Jun 2004 18:21:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bf4Uo-0001LE-DI for ipsec@ietf.org; Mon, 28 Jun 2004 18:21:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bf4TT-0000p7-00 for ipsec@ietf.org; Mon, 28 Jun 2004 18:19:39 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Bf4RP-0000FA-00 for ipsec@ietf.org; Mon, 28 Jun 2004 18:17:31 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 28 Jun 2004 15:21:24 -0700 X-BrightmailFiltered: true Received: from vilhuber-u30.cisco.com (vilhuber-u30.cisco.com [128.107.162.107]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i5SMGkSd026192; Mon, 28 Jun 2004 15:16:47 -0700 (PDT) Date: Mon, 28 Jun 2004 15:16:46 -0700 (PDT) From: Jan Vilhuber To: Francis Dupont Subject: Re: [Ipsec] Layer 2 processing inside IPsec In-Reply-To: <200406282156.i5SLuJSj059340@givry.rennes.enst-bretagne.fr> Message-ID: References: <200406282156.i5SLuJSj059340@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Mon, 28 Jun 2004, Francis Dupont wrote: > In your previous mail you wrote: > > > Does any one know if such a mechanism was proposed ? > > > > => look at draft-vilhuber-hco{ip,esp}-xx.txt > > I bet these have long since expired, but I'd be happy to resubmit them > (as individual submissions). When I first submitted these, there flood > of responses and comments was astounding. I got one single email about > it all (saying essentially "Cool.. I like it and have been thinking > along similar lines"; I think that might even have been you, francis :). > > => I remember to have sent such comment (:-)! > I remembered correctly then :) > Is the IETF now interested in this thing? Previously, comments (in > other working groups and other documents) were basically "Why would we > want to do this?" (which to me seems obvious, of course). > > => from MOBIKE charter (goal lists): > > (5) Reduction of header overhead involved with mobility-related > tunnels. This is a performance requirement in wireless > environments. > > So now there is a place for your work! > Maybe. I don't really see this as limited to mobility, though. As long as it's in a mobility-unrelated (i.e. generic) fashion, then I don't mind doing it there. The scenarios I've heard so far include stuff like: Customer wants to replace a voice T1 with a data-T1 and use Voip instead of telco lines. But with IPsec, the number of calls he can carry on said T1 is smaller with Voip than with telco stuff, so ipsec+voip so far is not an option. If we negate the packet expansion of ipsec via header compression (of whatever flavor suits them best, I don't really have any religion on the matter), then the number of calls under ipsec+voip can exceed the number of calls under 'telco'. Did that 'compressed' explanation of the scenario make sense? > > Can we continue offline? > > => this was for Francois (I expected he was French :-) > I can read french in a limited fashion. I can even understand it, if you talk reasonably slowly. Or so I think :) > I'm game if you want to include me on a private exchange. I still have > the drafts, and we can use them as a start, if you like. > > => IMHO you should resubmit then before the dead-line! > Well I won't be going to the IETF, so it matters little to me :) But I'll gladly send them to the submission-thing again (as individual submissions). If you want to be co-editor and present them in San Diego, I'd welcome that. jan > Thanks > > Francis.Dupont@enst-bretagne.fr > > PS: BTW we have a whole team of compression (mainly ROHC as it is > what 3GPP wants) experts. The only missing people are the people who > are interested to buy the idea: at the moment we are at least three > who'd like to sell it (:-)... > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 29 04:53:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02432 for ; Tue, 29 Jun 2004 04:53:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfEFp-0001Az-GI; Tue, 29 Jun 2004 04:46:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfEEp-000134-4W for ipsec@megatron.ietf.org; Tue, 29 Jun 2004 04:45:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02250 for ; Tue, 29 Jun 2004 04:45:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfEEm-0004vA-Si for ipsec@ietf.org; Tue, 29 Jun 2004 04:45:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfEDu-0004d2-00 for ipsec@ietf.org; Tue, 29 Jun 2004 04:44:14 -0400 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1BfEDL-0004KD-00 for ipsec@ietf.org; Tue, 29 Jun 2004 04:43:39 -0400 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10) id 1BfEDF-00004L-00; Tue, 29 Jun 2004 10:43:33 +0200 Received: from i72xindi.tm.uni-karlsruhe.de ([141.3.71.103] helo=i72voelker) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1BfEDF-0005RG-00; Tue, 29 Jun 2004 10:43:33 +0200 From: =?iso-8859-1?Q?Lars_V=F6lker?= To: "'Jan Vilhuber'" Subject: RE: [Ipsec] Layer 2 processing inside IPsec Date: Tue, 29 Jun 2004 10:43:32 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcRdY9+7GKXgUvOyTKWPEf5FGoIPIwAQCYHQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 In-Reply-To: Message-Id: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,MISSING_OUTLOOK_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi! > Maybe. I don't really see this as limited to mobility, though. As > long as it's in a mobility-unrelated (i.e. generic) fashion, then > I don't mind doing it there. > If we negate the packet expansion of ipsec via header compression > (of whatever flavor suits them best, I don't really have any > religion on the matter), then the number of calls under ipsec+voip > can exceed the number of calls under 'telco'. The problem with a generic fashion is that only specific protocol combinations reach a good compression level. It would be very nice to compress each packet so much that compression would outweigh the size of the ESP header. This would solve the fragmentation problem in almost every case. :) But let's check the math: When using transport mode (--> tunnel mode and compress IP Header to 0) an ESP header is adding 22-25 Octets (4+4+0..3+2+12). Let's just say we have UDP selectors anyway and SAVE the whole 8 Octets of the UDP header. Or we have TCP and could SAVE the whole 20 Octets (does not seem very reasonable to me)!? Still, this is not enough. :( If the IP header (IPv6 over ESP over IPv4) could be compressed more Octets would be found but this is surely not a generic scenario. So this leaves us to compress an application level protocol as RTP. Are there other application level protocols for which header compression would work that well? If not, we still have an overhead by adding ESP. Don't misunderstand me: I really think the idea to include header for headers encapsulated by ESP is a good idea but is this saving enough for any scenario besides mobility? And is it worth it? Lars P.S. We could reduce overhead of authentication but IMHO I think we need authentication at all costs. Only the sequence number field of ESP could give us a few more octets by compressing it. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 29 05:56:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07409 for ; Tue, 29 Jun 2004 05:56:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfFHk-0000Vn-4N; Tue, 29 Jun 2004 05:52:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfF0C-0006xw-PP for ipsec@megatron.ietf.org; Tue, 29 Jun 2004 05:34:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05923 for ; Tue, 29 Jun 2004 05:34:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfF0A-0004Ql-E6 for ipsec@ietf.org; Tue, 29 Jun 2004 05:34:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfEz6-00045V-00 for ipsec@ietf.org; Tue, 29 Jun 2004 05:33:01 -0400 Received: from eins.siemens.at ([193.81.246.11]) by ietf-mx with esmtp (Exim 4.12) id 1BfEyC-0003TI-00 for ipsec@ietf.org; Tue, 29 Jun 2004 05:32:04 -0400 Received: from vies1k7x.sie.siemens.at (forix [10.1.140.2]) by eins.siemens.at (8.12.9/8.12.8) with ESMTP id i5T9VZEP020002 for ; Tue, 29 Jun 2004 11:31:35 +0200 Received: from vies194a.sie.siemens.at (vies1kbx.sie.siemens.at [158.226.135.174]) by vies1k7x.sie.siemens.at (8.12.10/8.12.1) with ESMTP id i5T9VYaC002037 for ; Tue, 29 Jun 2004 11:31:34 +0200 Received: by vies194a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jun 2004 11:33:11 +0200 Message-ID: <4D50D5110555D5119F270800062B41650532ABBC@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IPsec WG (E-mail)" Date: Tue, 29 Jun 2004 11:32:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Ipsec] DHCPv6 and CP payload in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org HI, I wonder how a IRAC can use the INTERNAL_IP6_DHCP atrritbue in a Config reply/set for a DHCP request. 1) 15.4 in RFC3315 (DHCPv6) states, that the DHCP server has to discard the request, if the DUID option does not macht, but DUID is not supplied to IRAC within Config Reply/set 2) 18.2.1 in RFC3315 states, that the DHCP server will command the client to use multicast, if it did not send a unicast option previously. So it seems that IRAC has to use the solicitate/advertise DHCPv6 messages. Or is 2) solved by interpreting IKEv2 spec in the sense of being a link specification for IPv6 in the sense of 13. of RFC3315 ? Best regards, thanks in advance Peter _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 29 10:44:37 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24165 for ; Tue, 29 Jun 2004 10:44:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfJfZ-0003Ow-B6; Tue, 29 Jun 2004 10:33:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfJXN-00020B-MB for ipsec@megatron.ietf.org; Tue, 29 Jun 2004 10:24:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21805 for ; Tue, 29 Jun 2004 10:24:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfJXM-0003c7-SL for ipsec@ietf.org; Tue, 29 Jun 2004 10:24:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfJW9-0003Ak-00 for ipsec@ietf.org; Tue, 29 Jun 2004 10:23:25 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BfJVA-0002mS-00 for ipsec@ietf.org; Tue, 29 Jun 2004 10:22:24 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5TEJsg21088 for ; Tue, 29 Jun 2004 10:19:54 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5TEJhKr010662 for ; Tue, 29 Jun 2004 10:19:43 -0400 (EDT) Received: from unknown(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_3aWZu; Tue, 29 Jun 04 10:19:38 -0400 Date: Tue, 29 Jun 2004 15:28:38 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------hukbagfqztehqkqazctu" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Forum notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------hukbagfqztehqkqazctu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------hukbagfqztehqkqazctu Content-Type: text/html; name="Message.cpl.htm" Content-Disposition: attachment; filename="Message.cpl.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Message.cpl
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------hukbagfqztehqkqazctu Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------hukbagfqztehqkqazctu-- From ipsec-bounces@ietf.org Tue Jun 29 21:05:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12239 for ; Tue, 29 Jun 2004 21:05:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfTQt-0001ZO-99; Tue, 29 Jun 2004 20:58:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfTPx-0001MS-BH for ipsec@megatron.ietf.org; Tue, 29 Jun 2004 20:57:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12016 for ; Tue, 29 Jun 2004 20:57:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfTPu-0007Kn-Cv for ipsec@ietf.org; Tue, 29 Jun 2004 20:57:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfTP4-0006yN-00 for ipsec@ietf.org; Tue, 29 Jun 2004 20:56:46 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BfTOL-0006bw-00 for ipsec@ietf.org; Tue, 29 Jun 2004 20:56:01 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5U0rVg28665 for ; Tue, 29 Jun 2004 20:53:31 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5U0rLJD012653 for ; Tue, 29 Jun 2004 20:53:21 -0400 (EDT) Received: from unknown(203.197.150.77) by nutshell.tislabs.com via csmap (V6.0) id srcAAAakaGJy; Tue, 29 Jun 04 20:53:06 -0400 Date: Wed, 30 Jun 2004 06:31:42 +0530 To: "Ipsec" From: "Scott" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ejtlqkkzpstbpuycgrvu" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=HTML_30_40, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] Re: Hi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------ejtlqkkzpstbpuycgrvu Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------ejtlqkkzpstbpuycgrvu Content-Type: text/html; name="Smoke.com.htm" Content-Disposition: attachment; filename="Smoke.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: Smoke.com
Virus name: W32/Bagle.aa@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------ejtlqkkzpstbpuycgrvu Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------ejtlqkkzpstbpuycgrvu-- From ipsec-bounces@ietf.org Wed Jun 30 03:02:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26808 for ; Wed, 30 Jun 2004 03:02:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfYvZ-00067X-3C; Wed, 30 Jun 2004 02:50:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfYrK-0004on-79 for ipsec@megatron.ietf.org; Wed, 30 Jun 2004 02:46:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25826 for ; Wed, 30 Jun 2004 02:46:16 -0400 (EDT) From: tytso@mit.edu Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfYrI-0001dR-3A for ipsec@ietf.org; Wed, 30 Jun 2004 02:46:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfYpU-00014C-00 for ipsec@ietf.org; Wed, 30 Jun 2004 02:44:25 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BfYmh-0007mI-00 for ipsec@ietf.org; Wed, 30 Jun 2004 02:41:31 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5U6d1g13592 for ; Wed, 30 Jun 2004 02:39:01 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5U6cqQS005047 for ; Wed, 30 Jun 2004 02:38:52 -0400 (EDT) Message-Id: <200406300638.i5U6cqQS005047@nutshell.tislabs.com> Received: from localhost(203.210.212.40) by nutshell.tislabs.com via csmap (V6.0) id srcAAA4_aG0j; Wed, 30 Jun 04 02:38:47 -0400 To: ipsec@lists.tislabs.com Date: Wed, 30 Jun 2004 13:41:27 +0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_00005131.00006F93" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=HTML_30_40, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MISSING_MIMEOLE, MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] Question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0008_00005131.00006F93 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit is that your TAN? ------=_NextPart_000_0008_00005131.00006F93 Content-Type: text/html; name="concert.com.htm" Content-Disposition: attachment; filename="concert.com.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: concert.com
Virus name: W32/Netsky.c@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0008_00005131.00006F93 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0008_00005131.00006F93-- From ipsec-bounces@ietf.org Wed Jun 30 07:03:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08486 for ; Wed, 30 Jun 2004 07:03:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfcl1-0005SY-M5; Wed, 30 Jun 2004 06:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfcZe-0003gj-K8 for ipsec@megatron.ietf.org; Wed, 30 Jun 2004 06:44:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07598 for ; Wed, 30 Jun 2004 06:44:15 -0400 (EDT) From: housley@vigilsec.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfcZc-0001hw-4Y for ipsec@ietf.org; Wed, 30 Jun 2004 06:44:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfcYs-0001Kw-00 for ipsec@ietf.org; Wed, 30 Jun 2004 06:43:30 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BfcY1-0000vH-00 for ipsec@ietf.org; Wed, 30 Jun 2004 06:42:37 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5UAe4g27677 for ; Wed, 30 Jun 2004 06:40:05 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5UAdtLS021645 for ; Wed, 30 Jun 2004 06:39:55 -0400 (EDT) Message-Id: <200406301039.i5UAdtLS021645@nutshell.tislabs.com> Received: from localhost(203.210.219.73) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5UaGmQ; Wed, 30 Jun 04 06:39:45 -0400 To: ipsec@lists.tislabs.com Date: Wed, 30 Jun 2004 17:42:26 +0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_00004685.000033E4" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.2 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MISSING_MIMEOLE,MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] hey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0007_00004685.000033E4 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit docs? ------=_NextPart_000_0007_00004685.000033E4 Content-Type: text/html; name="letter.zip.htm" Content-Disposition: attachment; filename="letter.zip.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: letter.zip
Virus name: W32/Netsky.c@MM!zip

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0007_00004685.000033E4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0007_00004685.000033E4-- From ipsec-bounces@ietf.org Wed Jun 30 09:46:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17177 for ; Wed, 30 Jun 2004 09:46:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BffGJ-0001YU-H5; Wed, 30 Jun 2004 09:36:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BffBS-0000my-Ex for ipsec@megatron.ietf.org; Wed, 30 Jun 2004 09:31:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16301 for ; Wed, 30 Jun 2004 09:31:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BffBR-00041Z-Qt for ipsec@ietf.org; Wed, 30 Jun 2004 09:31:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bff99-0003N8-00 for ipsec@ietf.org; Wed, 30 Jun 2004 09:29:08 -0400 Received: from portal.gw.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1Bff7A-0002Vo-00 for ipsec@ietf.org; Wed, 30 Jun 2004 09:27:04 -0400 Received: from nutshell.tislabs.com (firewall-user@nutshell.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i5UDOWg20336 for ; Wed, 30 Jun 2004 09:24:32 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i5UDONbt018669 for ; Wed, 30 Jun 2004 09:24:23 -0400 (EDT) Received: from fwdoc.estig.ipb.pt(193.136.195.3) by nutshell.tislabs.com via csmap (V6.0) id srcAAAAiaiAK; Wed, 30 Jun 04 09:24:14 -0400 Date: Wed, 30 Jun 2004 14:33:16 +0000 To: "Ipsec" From: "Kivinen" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------gbdzswwsqdxiwtxraspo" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_RED,HTML_MESSAGE,LINES_OF_YELLING,LINES_OF_YELLING_2, MIME_HTML_ONLY autolearn=no version=2.60 Subject: [Ipsec] RE: Incoming Msg X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org ----------gbdzswwsqdxiwtxraspo Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit
----------gbdzswwsqdxiwtxraspo Content-Type: text/html; name="text_document.vbs.htm" Content-Disposition: attachment; filename="text_document.vbs.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: text_document.vbs
Virus name: W32/Bagle.aa@MM!vbs

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

----------gbdzswwsqdxiwtxraspo Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ----------gbdzswwsqdxiwtxraspo-- From ipsec-bounces@ietf.org Wed Jun 30 13:37:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00601 for ; Wed, 30 Jun 2004 13:37:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfixZ-0004f8-T1; Wed, 30 Jun 2004 13:33:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfirj-0004G9-5g for ipsec@megatron.ietf.org; Wed, 30 Jun 2004 13:27:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00318 for ; Wed, 30 Jun 2004 13:27:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfiri-00049k-6h for ipsec@ietf.org; Wed, 30 Jun 2004 13:27:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfiqp-0003nJ-00 for ipsec@ietf.org; Wed, 30 Jun 2004 13:26:27 -0400 Received: from bay8-f126.bay8.hotmail.com ([64.4.27.126] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1BfiqS-0003Pf-00 for ipsec@ietf.org; Wed, 30 Jun 2004 13:26:04 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 30 Jun 2004 10:25:33 -0700 Received: from 81.178.20.174 by by8fd.bay8.hotmail.msn.com with HTTP; Wed, 30 Jun 2004 17:25:33 GMT X-Originating-IP: [81.178.20.174] X-Originating-Email: [bob_arthurs@hotmail.com] X-Sender: bob_arthurs@hotmail.com From: "Bob Arthurs" To: ipsec@ietf.org Date: Wed, 30 Jun 2004 17:25:33 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 30 Jun 2004 17:25:33.0708 (UTC) FILETIME=[3FEAECC0:01C45EC7] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,PLING_QUERY autolearn=no version=2.60 Subject: [Ipsec] IKEv2: 1 child IPsec SA ? (stupid question!) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all, Just researching IKEv2 (draft-ietf-ipsec-ikev2-14), and I noticed the reference to a single IPsec SA being created during the initial 4 message negotiation (ike_sa_init & ike_auth). For example, I noticed the following reference: 'In some scenarios, only a single CHILD_SA is needed between the IPsec endpoints and therefore there would be no additional exchanges.' I know this is a stupid question, but knowing that IPsec SAs are unidirectional, can someone confirm that the initial 4 message IKE negotiation results in a single IPsec SA *in each direction* (giving a total of 2 IPsec SAs) ?? Many thanks in advance _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 30 14:21:45 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03168 for ; Wed, 30 Jun 2004 14:21:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfjcx-0001jf-N4; Wed, 30 Jun 2004 14:16:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfjaO-0001V2-0p for ipsec@megatron.ietf.org; Wed, 30 Jun 2004 14:13:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02828 for ; Wed, 30 Jun 2004 14:13:30 -0400 (EDT) From: Francois.PAUL@fr.thalesgroup.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfjaM-000736-VD for ipsec@ietf.org; Wed, 30 Jun 2004 14:13:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfjZO-0006ee-00 for ipsec@ietf.org; Wed, 30 Jun 2004 14:12:31 -0400 Received: from gwout.thalesgroup.com ([195.101.39.227]) by ietf-mx with esmtp (Exim 4.12) id 1BfjYS-0005sw-00 for ipsec@ietf.org; Wed, 30 Jun 2004 14:11:32 -0400 Received: from thalescan.corp.thales (200.3.2.3) by GWOUT.thalesgroup.com (NPlex 6.5.026) id 40D9AF1C001D2FA6 for ipsec@ietf.org; Wed, 30 Jun 2004 20:10:36 +0200 Received: from hiplex.tsbh.thales ([10.33.19.4]) by thalescan with InterScan Messaging Security Suite; Wed, 30 Jun 2004 20:10:04 +0200 Received: from hiplex.tsbh.thales (10.33.21.5) by hiplex.tsbh.thales (NPlex 6.5.026) id 40C82B1F000B4FC3 for ipsec@ietf.org; Wed, 30 Jun 2004 20:10:04 +0200 Received: from complex.tcfr.thales ([202.3.3.26]) by hiplex with InterScan Messaging Security Suite; Wed, 30 Jun 2004 20:10:04 +0200 Received: from complex.tcfr.thales (202.3.3.26) by complex.tcfr.thales (NPlex 6.5.026) id 40E01A0B00014D3F for ipsec@ietf.org; Wed, 30 Jun 2004 20:08:43 +0200 Received: from NODALNET.clb.tcfr.thales ([146.11.5.4]) by complex with InterScan Messaging Security Suite; Wed, 30 Jun 2004 20:08:43 +0200 Received: by NODALNET.clb.tcfr.thales with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jun 2004 20:10:03 +0200 Message-ID: <66CE949D18BCB249ABE8D9AF48C4F1CE2D49A7@helios.clb.tcfr.thales> To: Francis.Dupont@enst-bretagne.fr, sommerfeld@east.sun.com Subject: RE: [Ipsec] Layer 2 processing inside IPsec Date: Wed, 30 Jun 2004 20:10:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL, NO_REAL_NAME autolearn=no version=2.60 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I summarize hereafter the main points that arise from the different messages posted to this list : - Combining ROHC (or whichever generic compression frameworks suits) and IPsec in an efficient way leads to an integration of ROHC in the middle of IPsec. From the IPsec framework point of view, this could take the form ESP used in tunnel mode, but with a specific "next header" value different from "IP", in order for the policy enforcement processing to take place just after decryption and decompression, along the lines of what Jan Vilhuber proposed. - If a layer 2 processing such as ROHC is tunneled (directly or not) over IP, one must be careful regarding packet re-ordering. This kind of problem is dealt with by other layer 2 tunneling frameworks, such as L2TP. Just take a look at Appendix C of the present L2PTv3 draft (http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tp-base-11.txt), which pinpoints this issue more accurately than RFC 2661. I agree this problem is not easy to tackle, especially when one wants to determine the "very short period" after which a missing sequence number is considered lost rather than misordered ... F. Paul -----Message d'origine----- De : Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] Envoye : lundi 28 juin 2004 22:50 A : sommerfeld@east.sun.com Cc : Francois.PAUL@fr.thalesgroup.com; ipsec@ietf.org Objet : Re: [Ipsec] Layer 2 processing inside IPsec In your previous mail you wrote: > I disagree: IPsec does not change the order That's not at all clear to me. => this is misunderstanding: IPsec itself doesn't change the order, IP can change it and is run under IPsec. you cannot naively use ROHC over IPsec. => I agree. BTW I am not interested by ROHC itself but by any compression which can work with IPsec. In fact I believe it still has to be designed/specified. An integrated IPsec - ROHC implementation could look at the IPsec sequence number and insert its own reorder buffer, but such an integration would not be as simple as defining an IP protocol number for ROHC. => nothing can be simple with ROHC (:-). IMHO we talk about ROHC just because it is the more sophisticated compression... It's an architectural issue. An integrated IPsec-ROHC means that the ROHC would have to be inserted into the *middle* of IPsec processing, between the policy enforcement part and the encryption part. => it seems we agree: something can be done but needs real work. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 30 14:51:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05313 for ; Wed, 30 Jun 2004 14:51:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfk3J-0004nL-9j; Wed, 30 Jun 2004 14:43:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfjyS-00041e-HV for ipsec@megatron.ietf.org; Wed, 30 Jun 2004 14:38:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04497 for ; Wed, 30 Jun 2004 14:38:22 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfjyR-0001M6-G4 for ipsec@ietf.org; Wed, 30 Jun 2004 14:38:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfjxS-0000yH-00 for ipsec@ietf.org; Wed, 30 Jun 2004 14:37:23 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1BfjwP-0000EZ-00 for ipsec@ietf.org; Wed, 30 Jun 2004 14:36:17 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i5UIZXJ6024941; Wed, 30 Jun 2004 11:35:33 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i5UIZXii007982; Wed, 30 Jun 2004 14:35:33 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.11+Sun/8.12.11) with ESMTP id i5UIZXpR017602; Wed, 30 Jun 2004 14:35:33 -0400 (EDT) Message-Id: <200406301835.i5UIZXpR017602@thunk.east.sun.com> From: Bill Sommerfeld To: Francois.PAUL@fr.thalesgroup.com Subject: Re: [Ipsec] Layer 2 processing inside IPsec In-Reply-To: Your message of "Wed, 30 Jun 2004 20:10:08 +0200." <66CE949D18BCB249ABE8D9AF48C4F1CE2D49A7@helios.clb.tcfr.thales> Date: Wed, 30 Jun 2004 14:35:33 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Cc: ipsec@ietf.org, Francis.Dupont@enst-bretagne.fr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sommerfeld@east.sun.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org one additional point: the header compression schemes i'm familiar with all involve inter-packet dependancies. If someone is particularly serious about integrating IPsec and ROHC, another thing worth looking at is whether an the integrity protection provided by an esp-rohc combination might well be significantly enhanced by doing a MAC over the pre-compressed packet rather than/in addition to the current MAC over the ciphertext... (yes, this is a fairly significant change to ESP...) - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 30 16:23:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13484 for ; Wed, 30 Jun 2004 16:23:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfkrJ-00066c-Vh; Wed, 30 Jun 2004 15:35:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfkn6-0005T7-O7 for ipsec@megatron.ietf.org; Wed, 30 Jun 2004 15:30:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09242 for ; Wed, 30 Jun 2004 15:30:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfkn5-0006Zg-8P for ipsec@ietf.org; Wed, 30 Jun 2004 15:30:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfkm6-00069A-00 for ipsec@ietf.org; Wed, 30 Jun 2004 15:29:42 -0400 Received: from mxout1.netvision.net.il ([194.90.9.20]) by ietf-mx with esmtp (Exim 4.12) id 1BfklI-0005bl-00 for ipsec@ietf.org; Wed, 30 Jun 2004 15:28:53 -0400 Received: from [217.132.90.88] by mxout1.netvision.net.il (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I0400AMMZFA7T@mxout1.netvision.net.il> for ipsec@ietf.org; Wed, 30 Jun 2004 22:28:22 +0300 (IDT) Date: Wed, 30 Jun 2004 22:28:24 +0300 From: Yoav Nir Subject: Re: [Ipsec] IKEv2: 1 child IPsec SA ? (stupid question!) In-reply-to: To: Bob Arthurs Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.618) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,PLING_QUERY autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7BIT The create-child-sa exchange creates a pair of IPSec SAs, one in each direction. Since in IKE we always create IPSec SAs in pairs, we sometimes mistakenly refer to them in singular form. In the quote below, I think that "CHILD_SA" refers to the exchange rather than to the actual SAs. On 30/06/2004, at 20:25, Bob Arthurs wrote: > Hi all, > > Just researching IKEv2 (draft-ietf-ipsec-ikev2-14), and I noticed the > reference to a single IPsec SA being created during the initial 4 > message negotiation (ike_sa_init & ike_auth). For example, I noticed > the following reference: > > 'In some scenarios, only a single CHILD_SA is needed between the IPsec > endpoints and therefore there would be no additional exchanges.' > > I know this is a stupid question, but knowing that IPsec SAs are > unidirectional, can someone confirm that the initial 4 message IKE > negotiation results in a single IPsec SA *in each direction* (giving a > total of 2 IPsec SAs) ?? > > Many thanks in advance > > _________________________________________________________________ > Want to block unwanted pop-ups? Download the free MSN Toolbar now! > http://toolbar.msn.co.uk/ > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 30 16:50:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17067 for ; Wed, 30 Jun 2004 16:50:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bflkv-0000Si-4G; Wed, 30 Jun 2004 16:32:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfksh-0006Mz-J1 for ipsec@megatron.ietf.org; Wed, 30 Jun 2004 15:36:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09621 for ; Wed, 30 Jun 2004 15:36:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfksg-0001G1-Cp for ipsec@ietf.org; Wed, 30 Jun 2004 15:36:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfkrh-0000sc-00 for ipsec@ietf.org; Wed, 30 Jun 2004 15:35:30 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1Bfkqo-000082-00 for ipsec@ietf.org; Wed, 30 Jun 2004 15:34:34 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 30 Jun 2004 12:33:13 -0700 Received: from vilhuber-u30.cisco.com (vilhuber-u30.cisco.com [128.107.162.107]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i5UJY2gJ018300; Wed, 30 Jun 2004 12:34:02 -0700 (PDT) Date: Wed, 30 Jun 2004 12:34:02 -0700 (PDT) From: Jan Vilhuber To: Bill Sommerfeld Subject: Re: [Ipsec] Layer 2 processing inside IPsec In-Reply-To: <200406301835.i5UIZXpR017602@thunk.east.sun.com> Message-ID: References: <200406301835.i5UIZXpR017602@thunk.east.sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Cc: ipsec@ietf.org, Francis.Dupont@enst-bretagne.fr X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Wed, 30 Jun 2004, Bill Sommerfeld wrote: > one additional point: the header compression schemes i'm familiar with > all involve inter-packet dependancies. > > If someone is particularly serious about integrating IPsec and ROHC, I admit I'm not terribly interested in ROHC. I don't know too much about it, but I didn't want to exclude it from my draft either. > another thing worth looking at is whether an the integrity protection > provided by an esp-rohc combination might well be significantly > enhanced by doing a MAC over the pre-compressed packet rather than/in > addition to the current MAC over the ciphertext... > Yes, I'd thought about that before, too. If we were free to change the semantics and functioning of ESP, there's a few more thigns I recall I was thinking about at the time (my memory is suffering, since this was a while ago), but I think we'll want to stay within the confines of the semantics of ESP for now. jan > (yes, this is a fairly significant change to ESP...) > > - Bill > > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 30 20:26:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02690 for ; Wed, 30 Jun 2004 20:26:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfpKs-0005KP-OR; Wed, 30 Jun 2004 20:21:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfpIh-0004bq-39 for ipsec@megatron.ietf.org; Wed, 30 Jun 2004 20:19:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02291 for ; Wed, 30 Jun 2004 20:19:37 -0400 (EDT) From: kent@bbn.com Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BfpIf-0004Xo-It for ipsec@ietf.org; Wed, 30 Jun 2004 20:19:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BfpHm-0004A9-00 for ipsec@ietf.org; Wed, 30 Jun 2004 20:18:42 -0400 Received: from portal.tislabs.com ([192.94.214.101] helo=lists.tislabs.com) by ietf-mx with esmtp (Exim 4.12) id 1BfpGz-0003mq-00 for ipsec@ietf.org; Wed, 30 Jun 2004 20:17:53 -0400 Received: from nutshell.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by lists.tislabs.com (8.11.6/8.11.6) with ESMTP id i610FMg17314 for ; Wed, 30 Jun 2004 20:15:22 -0400 (EDT) Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id i610FDlf019223 for ; Wed, 30 Jun 2004 20:15:13 -0400 (EDT) Message-Id: <200407010015.i610FDlf019223@nutshell.tislabs.com> Received: from unknown(222.44.48.208) by nutshell.tislabs.com via csmap (V6.0) id srcAAALcaOIL; Wed, 30 Jun 04 20:15:09 -0400 To: ipsec@lists.tislabs.com Date: Thu, 1 Jul 2004 08:17:38 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_000020E0.00001476" X-Priority: 3 X-MSMail-Priority: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=4.1 required=5.0 tests=HTML_30_40, HTML_FONTCOLOR_RED, HTML_MESSAGE, LINES_OF_YELLING, LINES_OF_YELLING_2, MISSING_MIMEOLE, MSGID_FROM_MTA_HEADER,NO_REAL_NAME,PRIORITY_NO_NAME autolearn=no version=2.60 Subject: [Ipsec] fast food... X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0008_000020E0.00001476 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit solve the problem! ------=_NextPart_000_0008_000020E0.00001476 Content-Type: text/html; name="image.exe.htm" Content-Disposition: attachment; filename="image.exe.htm" X-NAI-Gauntlet: Attachment removed Content-Transfer-Encoding: 7bit VIRUS INFECTION ALERT

VIRUS INFECTION ALERT

The Gauntlet Firewall® discovered a virus in this file. The file was not repaired and has therefore been removed. See your system administrator for further information.

Filename: image.exe
Virus name: W32/Netsky.c@MM

Copyright © 1993-2001, Networks Associates Technology, Inc.
All Rights Reserved.
http://www.pgp.com

------=_NextPart_000_0008_000020E0.00001476 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0008_000020E0.00001476--