From owner-ipsec@lists.tislabs.com Tue Jul 1 00:39:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h617dEFK015515; Tue, 1 Jul 2003 00:39:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA15825 Tue, 1 Jul 2003 02:57:50 -0400 (EDT) From: "Jesse Alpert" To: "'Tero Kivinen'" Cc: Subject: RE: IKEv2: active user identity protection Date: Tue, 1 Jul 2003 10:04:30 +0300 Message-ID: <002c01c33f9f$04f76d20$7b2e1dc2@jesse> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <16128.36965.119302.171670@ryijy.hel.fi.ssh.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, >From an implementers point of view it seems to me there are a lot of (overlooked ?) problems in this ID_KEY_ID protocol. - How does the SGW know the random ID_KEY_ID the first time? - Does the SGW have to maintain it's own ID_KEY_ID to user database (apart from a RADIUS server etc. it may be using)? - When does the SGW flush this data to the database - it can't be done for every exchange for performance reasons. On the other hand, if the SGW sends N(UPDATE-CONFIRMED) before the data is flushed it may go down before storing this data causing synchronization problems. - Does the user always need to connect from the same machine? Otherwise how is the ID_KEY_ID transported between the machines? What if the user is connecting from an internet-cafe? I know all of these questions probably have solutions, but this certainly does not look like "very minor changes to those implementations that actually require this" BTW doesn't the fact that the server and the client share a random secret number (ID_KEY_ID) already prove the client's identity? Again current solutions, used by many customers today (such as Hybrid+XAUTH) do provide this protection. (Usually the first part of the exchange requires the server to authenticate using a certificate, only then the client authenticates). If you look in the follow-ups section of the references you attached you will notice that some implementers (admittedly less than I remember) answered Hugo and voted for the change. Jesse -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Tero Kivinen Sent: Monday, June 30, 2003 10:33 PM To: Scott G. Kelly Cc: Jesse Alpert; ipsec@lists.tislabs.com Subject: Re: IKEv2: active user identity protection Scott G. Kelly writes: > | Anyways you can still use the ID_KEY_ID (changing every time) as a > | identity in those EAP cases, and have very small program in the sgw > | end that will convert that ID_KEY_ID to the real EAP identity. This > | will offer completele protection to the initiators identity, without > | any change to the IKEv2 protocol, and with very minor changes to those > | implementations that actually require this. > This might meet some user's needs, but it does not scale well. It > requires synchronization between the sgw and the remote access clients, > and new lists of IDs must be provided to both on an ongoing basis. It is > not a good general solution. I would more likely think about protocol like this: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi(ID_KEY_ID=, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP, [AUTH], N(UPDATE-ID-KEY-ID=) } --> <-- HDR, SK {EAP, [AUTH], SAr2, TSi, TSr, N(UPDATE-CONFIRMED)} And then next time the client will use as ID_KEY_ID. If the connection breaks down before the client gets UPDATE-CONFIRMED notification it will use the old ID_KEY_ID next time too, and responder would need to keep two ID's, i.e the old and the new (the client will use the old, if it didn't get the last UPDATE-CONFIRMED message, or new if it did actually get the message). When ever server sees the as ID_KEY_ID it can move the to be old, and it will get new random very soon... I think this can be solved as separate extension to IKEv2, there is no need to put it in the IKEv2 base document. We MUST say "no more features" to IKEv2 some day, and that day has already gone. Also as this issue was already discussed earlier on the mailing list and the decision about was made that this will not make the IKEv2 document, I do not think it is usefull to continue this discussion on this issue now. The original discussion and decision about this can be found from: Hugo's original email: http://www.vpnc.org/ietf-ipsec/mail-archive/msg03639.html Area Directors comments: http://www.vpnc.org/ietf-ipsec/mail-archive/msg03653.html Working group chairs comments: http://www.vpnc.org/ietf-ipsec/mail-archive/msg03809.html -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jul 1 02:28:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h619SmFK032311; Tue, 1 Jul 2003 02:28:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA16754 Tue, 1 Jul 2003 04:35:01 -0400 (EDT) Message-Id: <200307010840.h618exof089503@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Angelos D. Keromytis" cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 and SCTP support In-reply-to: Your message of Mon, 30 Jun 2003 17:56:42 EDT. <200306302156.h5ULugcJ000553@coredump.cs.columbia.edu> Date: Tue, 01 Jul 2003 10:40:59 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: IKEv2 does not seem to currently support SCTP along the lines of the soon-to-be-issued RFC 3554 (which describes how to do SCTP support in IKEv1). => I agree but is it important to fix this now or can we postpone this with the mobility stuff (in fact, SCTP/multi-homing and mobility share a lot of things)? Briefly, there are two issues: a) The traffic selectors must allow for a list of addresses to be associated with each endpoint. This is in fact supported by IKEv2. => yes, this is already handled by the IKEv2 "TS_LIST" feature. b) The IKE and IPsec SAs must be linked to all of the peer's remote addresses. This means that IKEv2 cannot just use the peer's IP address, but has to either extract all the addresses from the Traffic Selector or be told explicitly via the ID payload. => there is a third way: add an explicit management of peer address set as I suggested in my draft. IKEv1/SCTP used the latter approach, specifying the ID_LIST payload for including a list of IP addresses associated with the peer. => this is another overloading of the ID payload. IMHO we can do better, so the question is postpone or delay? I recommend that said payload be included in the IKEv2 draft, and the relevant language be copied from RFC 3554. => argh! I am afraid that you missed a small detail: the ID_LIST is specified for the phase 2 so if you'd like to change the ID payload of IKEv2 which is *only* for phase 1 it is not so simple. Furthermore, per soon-to-be-issued RFC 3554, the receiver must verify that the peer actually owns the relevant addresses in the TS payload. This typically means that these addresses must be contained in the certificate contained in the CERT payload, or some policy/configuration mechanism be consulted. => this too shows that the ID payload way is not the right one because we remove this kind of constraints in the standard case. Of course, something should be done, and it will be nice to support changes in the peer address set... Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Jul 1 03:06:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61A6TFK035203; Tue, 1 Jul 2003 03:06:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA17233 Tue, 1 Jul 2003 05:30:59 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16129.22023.290967.906616@ryijy.hel.fi.ssh.com> Date: Tue, 1 Jul 2003 12:36:07 +0300 From: Tero Kivinen To: Stephen Kent Cc: "jpickering@creeksidenet.com" , ipsec@lists.tislabs.com Subject: Re: QoS selectors (was LAST CALL: IKE) In-Reply-To: References: <5.2.0.9.0.20030626101831.00a96bb0@email> <3F00526A.3060705@creeksidenet.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 21 min X-Total-Time: 20 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >In order to support simultaneous rekey tie-breaking as currently > >defined, one needs to be able to be able to determine > >if the attempt to create a child is a rekey and if so, which SA is > >being rekeyed. The only way to do this per current > >version is to examine the traffic selectors which presumes no redundant SAs. > Any suggestions on how to avoid messing up the rekey heuristic and > not negotiating the DiffServ values for SAs? One proposal that was made earlier, was to create traffic selector type of SPI, i.e say that this is going to replace that SPI and copy all traffic selector data from that SPI. This was not accepted by the WG, and it is too late to add this kind of new features to the IKEv2. The real problem can be solved if the end that does the rekey actually makes sure that it also deletes the old SA almost immediately, before it rekeys any other SA. I.e Host A and B have no SAs in the beginning. The Host A decides to send packet using TOS 0x01. It creates SA pair SPI-0x0001 (inbound) and SPI-0x8001 (outbound). It sends the packet with TOS 0x01 to SPI-0x8001, and associates that SA to be with TOS 0x01. The host A then receives another packet with different TOS 0x02. Host A notices that it cannot put that packet to any of the existing SAs, thus it creates another SA pair SPI-0x0002 (inboud) and SPI-0x8002 (outbound). Now the host A sends that packet to SPI-0x8002 and marks it to be outbound traffic for TOS 0x02. Host A continues to do that, and it creates new SA for each TOS value that the policy specifies that it needs to use separate SA. There is no need to communicate this information to B, because there is no use for B to verify that packets come from the right SA, as when the packets arrive to the B the possible damage of messing up QoS is already done. There will not be reordering problems because each SA contains only one (or multiple if specified by policy) TOS values. When host B decides to send back packet with TOS 0x02, it notices that it have 2 SA pairs up, and neither one of those is associated with any TOS value. It selects any one of those SAs and associates it with TOS value of 0x02. Lets say it took SPI-0x0001. For the next packet with different TOS it tooks the next one (SPI-0x0002). If it have more packets with different TOS, it needs to create more SA pairs. Now, when the host A is rekeying the SA pair SPI-0x0001, SPI-0x8001, it will first create new SA pair SPI-0x0003, SPI-0x8003, and then associate the SPI-0x8003 to TOS 0x01 because that was associated with the SA it is rekeying. After that host A sends delete notification for the SPI-0x0001. Host B sees that delete notification, and deletes the SA pair SPI-0x0001, SPI-0x8001, and replies with delete notification to SPI-0x8001. Next time host B tries to send packet with TOS 0x02 it notices, that it does not have SA associated to that TOS value, thus it takes the next non associated SA and assings it to TOS 0x02. Note, that this style option described here, can be made completely optional, i.e if the other end does not support it it will simply see multiple SAs and only use one of them (or all based on the implementation), and the other end can send packets to separate SAs to make sure them all arrive with proper QoS levels to other end. As you can see from the above example it can be made work without any need for actual negotiation of the TOS values in the IKEv2 level. We do need the selector capability in the IPsec engine and architecture, as we need to associate the TOS to some SAs. The selection of the right outbound SA based on the TOS can be left to the local implementation. I do not think we actually gain anything by doing the checks for the inbound traffic (damage is already done when we see the packet). I do not know if adding TOS to IKEv2 (and explicitly associate them to SA pair) is better than this kind of decide on the fly style, but I simply wanted to explain how I see, how this could be done. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jul 1 03:12:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61ACHFK035634; Tue, 1 Jul 2003 03:12:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA17308 Tue, 1 Jul 2003 05:37:44 -0400 (EDT) Message-Id: <200307010943.h619hYof090095@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charles Lynn cc: ipsec@lists.tislabs.com, ipsec-policy@vpnc.org Subject: Re: IKEv2 selectors for IPsec? In-reply-to: Your message of Thu, 26 Jun 2003 10:38:06 EDT. <20030626143806.880D316484@wolfe.bbn.com> Date: Tue, 01 Jul 2003 11:43:34 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: What do folks think of making the IPsec (AH/ESP) protocol and SPI an IKEv2 selector? => I object for AH because it is an extension header. I agree about ESP when the node is not the source or the destination, i.e., ESP packets are "in transit"., cf. the "intermediate security gateways" in the original message. The SPI is the natural selector for (AH and) ESP. Its use gets into the area of dynamically created policy, e.g., when an end-to-end SA has to traverse intermediate security gateways. The question might be more appropriate for the IP Security Policy WG (is there any progress there or have folks lost interest?). => in this context ESP in a selector makes sense. A catch-22 might be that AH is not currently treated as an "upper layer protocol", so the processing model might need to be extended a bit. => AH is *not* an upper layer protocol so this is at least very problematic. That in turn leads to the question of whether folks see any advantage to having IPv6 extension headers -- fragmentation header, routing header, jumbogram, destination options (and maybe Option Type), be selectors. => I'll send a message to clarify these issues before we fall into a two year discussion like the piggy-backing for Mobile IPv6 (on exactly this issue BTW) one. One might argue that they are useful for filtering (access control) but not not useful as items that would select a policy action -- i.e., IPsec should use them but there is no need for IKEv2 negotiation. => IMHO we should *not* ask IPsec to perform the same kind of complex things than a firewall. More in another message. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Jul 1 03:30:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61AUIFK038243; Tue, 1 Jul 2003 03:30:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA17463 Tue, 1 Jul 2003 05:54:36 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16129.23441.423801.960924@ryijy.hel.fi.ssh.com> Date: Tue, 1 Jul 2003 12:59:45 +0300 From: Tero Kivinen To: "Jesse Alpert" Cc: Subject: ID_KEY_ID style user identity protection In-Reply-To: <002c01c33f9f$04f76d20$7b2e1dc2@jesse> References: <16128.36965.119302.171670@ryijy.hel.fi.ssh.com> <002c01c33f9f$04f76d20$7b2e1dc2@jesse> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 18 min X-Total-Time: 18 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jesse Alpert writes: > From an implementers point of view it seems to me there are a lot of > (overlooked ?) problems in this ID_KEY_ID protocol. > - How does the SGW know the random ID_KEY_ID the first time? Same way than it knows about the username and password, i.e by configuration. > - Does the SGW have to maintain it's own ID_KEY_ID to user database > (apart from a RADIUS server etc. it may be using)? Depends on the implementation. If it is using RADIUS, it propably needs to convert the ID_KEY_ID to username before sending it to RADIUS, if it uses LDAP or similar, it can actually store the information to LDAP etc. On the other hand if we modify the protocol so that the server sends the next ID_KEY_ID, then it can actually use symmetric crypto and send SK{random-salt | username | counter-or-timestamp) to the client and when it receives it back it can simply decrypt that and see the username from there. There are multiple ways to do the protocol, my example was simply one of those. > - When does the SGW flush this data to the database - it can't be done > for every exchange for performance reasons. On the other hand, if the Compared to the Diffie-Hellman I do not think it will be very costly to flush the data to database. On the other hand if you use the encrypted username scheme, there is no need to update anything, as it can see the username from the message and the it is clients problem if client uses the same ID_KEY_ID multiple times (attacker does not gain anything by using it again). > SGW sends N(UPDATE-CONFIRMED) before the data is flushed it may go down > before storing this data causing synchronization problems. > - Does the user always need to connect from the same machine? Otherwise how > is the ID_KEY_ID transported between the machines? What if the user is > connecting from an internet-cafe? Propably yes, unless he have some kind of token or something that actually can store the ID_KEY_ID also. If person is concerned about the security of his identity, is he really going to use machine from internet-cafe? When he walked in to the internet-cafe, there already propably was one web-cam or similar taking picture of him, and the machine there is most likely going to have data logger storing all keypresses anyways (i.e it will store the username anyways)... At least it is much easier to install those to all internet-cafe machines than to do active attack to get the identity. I never use any of those machines in the internet-cafe, even if I am not concerned about my identity leaking, but I do not trust those machines in general at all. If I need to login from wierd places, I will use my own laptop or if it is not possible, then I do not login. > If you look in the follow-ups section of the references you attached > you will notice that some implementers (admittedly less than I > remember) answered Hugo and voted for the change. I actually did read those complete threads through before sending the email. This issue was also bring up even earlier, and I think some of the people simply ignored the discussion as it was already repeated issue at that point. I think quite a lot of the implementators actually do care about this issue, but they do not want to start modifying the IKEv2 now. We do need something we can use now. Also as I said I think this can be done later by using ID_KEY_ID, thus we can attack this problem after IKEv2 is out. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jul 1 06:24:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61DODFK054078; Tue, 1 Jul 2003 06:24:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19196 Tue, 1 Jul 2003 08:46:30 -0400 (EDT) Message-ID: <3F01872C.5060007@creeksidenet.com> Date: Tue, 01 Jul 2003 09:05:48 -0400 From: "jpickering@creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: QoS selectors (was LAST CALL: IKE) References: <5.2.0.9.0.20030626101831.00a96bb0@email> <3F00526A.3060705@creeksidenet.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The only thing that comes to mind is to add a notify payload when rekeying that identifies the SPI of the SA being rekeyed. But this is a bits on wire change.... I guess this is why Radia decided to just drop the diffserv issue in SF. - Jeff Stephen Kent wrote: > At 11:08 AM -0400 6/30/03, jpickering@creeksidenet.com wrote: > >> Re: multiple "redundant" SAs: >> In order to support simultaneous rekey tie-breaking as currently >> defined, one needs to be able to be able to determine >> if the attempt to create a child is a rekey and if so, which SA is >> being rekeyed. The only way to do this per current >> version is to examine the traffic selectors which presumes no >> redundant SAs. >> >> - Jeff >> > > Whoops! > > Any suggestions on how to avoid messing up the rekey heuristic and not > negotiating the DiffServ values for SAs? > > Steve > > > From owner-ipsec@lists.tislabs.com Tue Jul 1 06:28:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61DSuFK054254; Tue, 1 Jul 2003 06:28:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19257 Tue, 1 Jul 2003 08:53:50 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16129.34195.406799.809148@ryijy.hel.fi.ssh.com> Date: Tue, 1 Jul 2003 15:58:59 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Issue5 and ECN X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 7 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk When checking issue 5 "ECN text in USE_TRANSPORT_MODE" I read the section "2.24 ECN Notification". While reading it, I noticed that the section DOES NOT have anything to do with IKEv2, it only modifies some other documents (RFC2401 and RFC3168). I think that whole section should be removed, and moved to the RFC2401bis instead. Earlier it was little bit different because the support for ECN was negotiated in the IKEv1, but now it is on by default, so I do not think we need anything more in IKEv2 document than the text saying that the ECN support should be done as defined in the RFC2401bis. It makes quite hard for implementators if they have to read unrelated documents (IKEv2) to see how to process ECN modifiers instead of reading how to handle them from the IPsec architecture document or the document which describes the ECN. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jul 1 06:34:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61DYBFK054386; Tue, 1 Jul 2003 06:34:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19313 Tue, 1 Jul 2003 08:56:44 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16129.34370.145683.389391@ryijy.hel.fi.ssh.com> Date: Tue, 1 Jul 2003 16:01:54 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: New item for 2401bis X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 2 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We should include the ECN support for the RFC2401bis. The text about this is already in the IKEv2 document (where it does not belong) and it should be moved to the RFC2401bis instead (from draft-ietf-ipsec-ikev2-08.txt): ---------------------------------------------------------------------- 2.24 ECN Notification Sections 5.1.2.1 and 5.1.2.2 of [RFC 2401] specify that the IPv4 TOS octet and IPv6 traffic class octet are to be copied from the inner header to the outer header by the encapsulator and that the outer header is to be discarded (no change to inner header) by the decapsulator. If ECN (see [RFC 3168]) is in use, ECT codepoints will be copied to the outer header, but if a router within the tunnel changes an ECT codepoint to a CE codepoint to indicate congestion, that indication will be discarded by the decapsulator. This behavior is highly undesirable, and Section 9.2 of [RFC 3168] specifies changes to IPsec to avoid it. These changes include two ECN operating modes and negotiation support to detect and cope with IPsec decapsulators that discard ECN congestion indications; use of ECN in the outer IP header of IPsec tunnels is not permitted when such discarding is a possibility. In order to avoid multiple ECN operating modes and negotiation, tunnel decapsulators for tunnel-mode Security Associations (SAs) created by IKEv2 MUST implement the following modifications to prevent discarding of ECN congestion indications. IKEv2 tunnel-mode SA negotiation is handled by the USE_TRANSPORT_MODE Notify message type (see Section 3.10.1). The following modifications *replace* Section 9.2 of RFC 3168 and *update* Sections 5.1.2.1 and 5.1.2.2 of RFC 2401. Encapsulation and Decapsulation of packets for a tunnel-mode SA created by IKEv2 MUST NOT follow the modifications specified by Section 9.2 of RFC 3168 and its subsections. Instead, the following modifications to encapsulation and decapsulation in Sections 5.1.2.1 and 5.1.2.2 of RFC 2401 MUST be performed: Outer Hdr at Inner Hdr at IPv4 Encapsulator Decapsulator Header fields: -------------------- ------------ DS Field copied from inner hdr (5) no change ECN Field copied from inner hdr constructed (7) IPv6 Header fields: DS Field copied from inner hdr (6) no change ECN Field copied from inner hdr constructed (7) (5)(6) If the packet will immediately enter a domain for which the DSCP value in the outer header is not appropriate, that value MUST be mapped to an appropriate value for the domain [RFC 2474]. Also see [RFC 2475] for further information. (7) If the ECN field in the inner header is set to ECT(0) or ECT(1) and the ECN field in the outer header is set to CE, then set the ECN field in the inner header to CE, otherwise make no change to the ECN field in the inner header. (5) and (6) are identical to match usage in [RFC2401], although they are different in [RFC2401]. These actions are not related to ECN, but are required for Differentiated Services support. They are carried over to this document from RFC 3168 so that all of RFC 3168's changes to IPsec can be made non-applicable to SAs created by IKEv2. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jul 1 07:18:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61EIKFK056216; Tue, 1 Jul 2003 07:18:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA19870 Tue, 1 Jul 2003 09:39:28 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16129.36933.539947.2546@ryijy.hel.fi.ssh.com> Date: Tue, 1 Jul 2003 16:44:37 +0300 From: Tero Kivinen To: "jpickering@creeksidenet.com" Cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: QoS selectors (was LAST CALL: IKE) In-Reply-To: <3F0189C2.1070000@creeksidenet.com> References: <5.2.0.9.0.20030626101831.00a96bb0@email> <3F00526A.3060705@creeksidenet.com> <16129.22023.290967.906616@ryijy.hel.fi.ssh.com> <3F0189C2.1070000@creeksidenet.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 3 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk jpickering@creeksidenet.com writes: > Simul rekey tiebreaking from IKE's protocol perspective, requires that > the responder be able to > determine at this point if the attempt to create this new SA is a rekey > or different SA. If there is nothing in > the traffic spec (eg a uniqueifier) or elsewhere (eg a new notify > payload) to differentiate, tiebreaking > does not work. I do not think there is need for tiebraking in those cases. If host A and B are going to have several SAs up anyways, and they both happen to rekey one pair simultaneously, they create one extra SA pair, which they can use next time they need SA which is not tied to any TOS (i.e when they start rekying next SA, they notice that they already have new unused SA ready, thus use it instead and simply delete the old one). I myself do not consider those extra SAs as a problem in general. Just make sure that they are not all rekeyed next time, so the number of SAs does not multiply every rekey. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jul 1 07:31:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61EVRFK057342; Tue, 1 Jul 2003 07:31:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20100 Tue, 1 Jul 2003 09:54:30 -0400 (EDT) Message-Id: <200307011340.h61DeccJ021943@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 and SCTP support In-reply-to: Your message of "Tue, 01 Jul 2003 10:40:59 +0200." <200307010840.h618exof089503@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Jul 2003 09:40:38 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <200307010840.h618exof089503@givry.rennes.enst-bretagne.fr>, Francis Dupont writes: > >=> I agree but is it important to fix this now or can we postpone this >with the mobility stuff (in fact, SCTP/multi-homing and mobility share >a lot of things)? Well, SCTP without mobility is simple to fix. I don't claim to understand all the issues wrt mobility... >=> there is a third way: add an explicit management of peer address set >as I suggested in my draft. The drawback is that there is an extra message etc. Also, as we discuss in RFC 3554, it is unlikely that you will be getting a new address extremely frequently (e.g., every minute), so you might as well do a full IKE exchange when you do. >=> this is another overloading of the ID payload. IMHO we can do better, >so the question is postpone or delay? Except that we have already taken this approach for IKEv1, and the text can be copied directly, so the third option is "integrate" :-) >=> argh! I am afraid that you missed a small detail: the ID_LIST is >specified for the phase 2 so if you'd like to change the ID payload >of IKEv2 which is *only* for phase 1 it is not so simple. That's incorrect. ID_LIST can be sent in "phase 1" as well. > Furthermore, per soon-to-be-issued RFC 3554, the receiver must > verify that the peer actually owns the relevant addresses in the TS > payload. This typically means that these addresses must be > contained in the certificate contained in the CERT payload, or some > policy/configuration mechanism be consulted. > >=> this too shows that the ID payload way is not the right one because >we remove this kind of constraints in the standard case. Of course, >something should be done, and it will be nice to support changes >in the peer address set... PKIX certificates already support this type of encoding, and matching against it is trivial. Again, the changes I recommend are purely textual, as opposed to adding a new message or exchange. -Angelos From owner-ipsec@lists.tislabs.com Tue Jul 1 08:20:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FKuFK059936; Tue, 1 Jul 2003 08:20:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21200 Tue, 1 Jul 2003 10:46:17 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F01872C.5060007@creeksidenet.com> References: <5.2.0.9.0.20030626101831.00a96bb0@email> <3F00526A.3060705@creeksidenet.com> <3F01872C.5060007@creeksidenet.com> Date: Tue, 1 Jul 2003 10:51:10 -0400 To: "jpickering@creeksidenet.com" From: Stephen Kent Subject: Re: QoS selectors (was LAST CALL: IKE) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:05 AM -0400 7/1/03, jpickering@creeksidenet.com wrote: >The only thing that comes to mind is to add a notify payload when >rekeying that identifies the SPI of >the SA being rekeyed. But this is a bits on wire change.... I guess >this is why Radia decided to just drop >the diffserv issue in SF. > >- Jeff That's the sort of thing I would suggest too, but wanted to hear what others would say. Using the SPI to identify an SA being rekeyed avoids ambiguity, no matter what the source, and that seems worthwhile. Steve From owner-ipsec@lists.tislabs.com Tue Jul 1 08:21:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FL0FK059941; Tue, 1 Jul 2003 08:21:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21049 Tue, 1 Jul 2003 10:35:17 -0400 (EDT) Message-Id: <200307011441.h61Ef6of090764@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charles Lynn cc: ipsec@lists.tislabs.com, ipsec-policy@vpnc.org Subject: Re: IKEv2 selectors for IPsec? In-reply-to: Your message of Thu, 26 Jun 2003 10:38:06 EDT. <20030626143806.880D316484@wolfe.bbn.com> Date: Tue, 01 Jul 2003 16:41:06 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IPv6 uses header chaining for extensions, IPv4 protocols are named "next header types". Filtering is used for QoS classification, firewall and IPsec. Standard filtering is done on the 5-tuple, i.e., source and destination addresses, "upper layer/transport" protocol, source and destination ports. This raises a lot of issues: - what is a "upper layer/transport" protocol? - protocol specific selectors (in place of ports)? - how to get the tuple for packets in transit? In IPv6, next header types are divided into 3 classes: - final protocols, i.e., protocols which don't include a next header field and are always at the end of the extension header chain. Note this is the default, i.e., an unknown protocol is considered as final. Examples are UDP, TCP, OSPF, no-next-header (59), mobility header, etc. - extension header protocols which are always in a middle of the extension header chain and which have a next header field which gives the type of the following header. Predefined extension header protocols are hop-by-hop options header (0!), destination options header, routing header, fragment header, AH, ESP and IPCOMP. - encapsulation protocols which are at the end of the extension header chain but with a payload which is an IP packet. Examples are 4 (IPv4 over IP), 41 (IPv6 over IP), GRE, 94, etc. Some protocols like ICMP can carry an IP packet in some cases (ICMP errors, ICMP redirect) but usually they are considered as final for simple filtering, i.e., by everything at the exception of some firewalls. All final and considered as final protocols are "upper layer/transport" protocols. The second issue, protocol specific selectors, has to be solved per protocols. Current transport protocols use ports. ICMP, IGMP, ICMPv6 can use the type/code pair which fits perfectly. The mobility header of Mobile IPv6 can use the message type (consider this as an official request). Fragmentation, ESP or IPCOMP can hide the 5-tuple, to be more accurate: - the "upper layer/transport" header can be in another fragment than the first one, for instance this sequence is legal: 1: , , 2: , , , For an intermediate node, there are only three kinds of fragments, first, last and intermediate. - even if ESP can use the null cipher, an intermediate node has no way to know this, so the only visible thing in ESP is the SPI. We have to distinguish between intermediate nodes, which are not supposed to perform reassembly or to be able to look inside ESP payloads, and end-nodes (original source or final destination), which have access to the whole clear packet. Of course, an intermediate node which is collocated with a firewall can get a part or all of end-node properties. So when an extension header protocol is transparent (fragment, ESP and IPCOMP for end-nodes, all others in any context) it should *not* be considered as an "upper layer/transport" protocol just because there is always another one in packets, and filtering over more than one protocol is not simple. So AH and an extension header version of the mobile header should not be considered as valid "upper layer / transport" protocols. The last case is encapsulation, including the hidden encapsulation used by mobile IPv6 with the home address option and the routing header of type 2 (cf. draft-deering-ipv6-encap-addr-deletion-00.txt). Again the context, i.e., intermediate node or end node, is very important: usually an encapsulation protocol is considered as final but in an end node it can be associated with a virtual interface and filtering can be applied to the outer header or to the inner header. For instance in Mobile IPv6 the mobility entities work with inner headers, i.e., home addresses, and not with outer headers, i.e., care-of addresses. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Jul 1 08:35:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FZaFK062475; Tue, 1 Jul 2003 08:35:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21312 Tue, 1 Jul 2003 10:55:56 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200306302216.h5UMGWb9004806@burp.tkv.asdf.org> References: <16122.55806.305977.986255@ryijy.hel.fi.ssh.com> <16128.25732.675945.766298@ryijy.hel.fi.ssh.com> <200306301913.h5UJD88P003320@burp.tkv.asdf.org> <200306302139.h5ULddZx004355@burp.tkv.asdf.org> <200306302216.h5UMGWb9004806@burp.tkv.asdf.org> Date: Tue, 1 Jul 2003 10:56:40 -0400 To: Markku Savela From: Stephen Kent Subject: Re: IKE negotiation for fragmentation controls in IPsec Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:16 AM +0300 7/1/03, Markku Savela wrote: > > From: Stephen Kent >> >> if we fragment after IPsec encapsulation, then ANYONE can send >> fragments that could cause the IPsec implementation trouble, > >You probably don't mean "trouble", such as crashing. Injecting a fake >"fragment" would just make IPsec on the assembled packet fail the >checks. This is the trouble you mean? yes, I do mean trouble as in running out of buffer space due to getting lots of bogus, non-initial fragments, and behaving badly as a result :-) >Yes, that is a danger, fragmenting after IPsec makes it easier for the >attacker to cause packets to be lost (dropped by IPsec). I Not just lost, but to deluge the receiver with bogus, non-initial fragments > >> if we fragment before encapsulation (but after doing the SPD checks), >> then we expose the stack behind the implementation to attacks, but > >Ugh.. fragmenting before IPsec would be somewhat akward with "bump in >stack" implementation (at least for me it would be rather major >architectural change). However, as implementation never fragments TCP >packets, only issue is with large UDP packets. Oh well.. Yes, we have to live with the potential for large UDP packets too. Even IPv6 does not preclude a host from sending fragments "natively" so we have to deal with this issue in some way. Steve From owner-ipsec@lists.tislabs.com Tue Jul 1 08:35:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FZbFK062477; Tue, 1 Jul 2003 08:35:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA21318 Tue, 1 Jul 2003 10:55:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564CE65@corpmx14.us.dg.com> References: <277DD60FB639D511AC0400B0D068B71E0564CE65@corpmx14.us.dg.com> Date: Tue, 1 Jul 2003 10:58:46 -0400 To: Black_David@emc.com From: Stephen Kent Subject: RE: QoS selectors (was LAST CALL: IKE) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:57 PM -0400 6/30/03, Black_David@emc.com wrote: >Steve, > >> At 11:08 AM -0400 6/30/03, jpickering@creeksidenet.com wrote: >> >Re: multiple "redundant" SAs: >> >In order to support simultaneous rekey tie-breaking as currently >> >defined, one needs to be able to be able to determine >> >if the attempt to create a child is a rekey and if so, which SA is >> >being rekeyed. The only way to do this per current >> >version is to examine the traffic selectors which presumes >> no redundant SAs. >> >> Whoops! >> >> Any suggestions on how to avoid messing up the rekey heuristic and >> not negotiating the DiffServ values for SAs? > >We've already concluded that the DiffServ values are functionally >opaque to the other side from a traffic classification standpoint. >OTOH, I'm concerned that if we pass them across IKE, someone's going >to try to use them in a way that s/he shouldn't. So, let's go back >to an old proposal from Radia: > > So I'd propose one more field in the traffic > elector for "uniquifier". Alice can create > ultiple child-SAs to Bob with the same > raffic selectors, as long as they have different > niquifiers. > >The uniquifier could be some sort of internal index or pointer; >even a simple counter works. > >Another possibility if rekeying is really the only problem, >would be to pass the other side's SPI as the "uniquifier" indicating >exactly which SA is being rekeyed. If this is always done, the >rekeying "heuristic" turns into a rule - when the "old SPI" >is passed, this is a rekey of that SPI, otherwise it's a new >SA creation. A minor downside is that if one fails to pass the >"old SPI" on rekey, SAs that are no longer useful may accumulate >on the peer, but the peer is already free to garbage collect SAs, >and these will be good candidates as they will carry no further >traffic. > >Thanks, >--David As you note, we already SPIs as locally unique ways to refer to SAs between consenting IPsec implementations. I don't see a need to add an arbitrary, new selector for address this problem. Steve From owner-ipsec@lists.tislabs.com Tue Jul 1 08:44:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FiDFK063991; Tue, 1 Jul 2003 08:44:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21506 Tue, 1 Jul 2003 11:05:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16129.22023.290967.906616@ryijy.hel.fi.ssh.com> References: <5.2.0.9.0.20030626101831.00a96bb0@email> <3F00526A.3060705@creeksidenet.com> <16129.22023.290967.906616@ryijy.hel.fi.ssh.com> Date: Tue, 1 Jul 2003 11:05:03 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: QoS selectors (was LAST CALL: IKE) Cc: "jpickering@creeksidenet.com" , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:36 PM +0300 7/1/03, Tero Kivinen wrote: >Stephen Kent writes: >> >In order to support simultaneous rekey tie-breaking as currently >> >defined, one needs to be able to be able to determine >> >if the attempt to create a child is a rekey and if so, which SA is >> >being rekeyed. The only way to do this per current >> >version is to examine the traffic selectors which presumes no >>redundant SAs. >> Any suggestions on how to avoid messing up the rekey heuristic and >> not negotiating the DiffServ values for SAs? > >One proposal that was made earlier, was to create traffic selector >type of SPI, i.e say that this is going to replace that SPI and copy >all traffic selector data from that SPI. This was not accepted by the >WG, and it is too late to add this kind of new features to the IKEv2. I agree that we ought not add a traffic selector to solve this problem. But use of the SPI does seem reasonable. > >The real problem can be solved if the end that does the rekey actually >makes sure that it also deletes the old SA almost immediately, before >it rekeys any other SA. You don't want to kill off the old SA until traffic has migrated to the new SA, to minimize disruption, right? > >I.e > >Host A and B have no SAs in the beginning. The Host A decides to send >packet using TOS 0x01. It creates SA pair SPI-0x0001 (inbound) and >SPI-0x8001 (outbound). It sends the packet with TOS 0x01 to >SPI-0x8001, and associates that SA to be with TOS 0x01. > >The host A then receives another packet with different TOS 0x02. Host >A notices that it cannot put that packet to any of the existing SAs, >thus it creates another SA pair SPI-0x0002 (inboud) and SPI-0x8002 >(outbound). Now the host A sends that packet to SPI-0x8002 and marks >it to be outbound traffic for TOS 0x02. > >Host A continues to do that, and it creates new SA for each TOS value >that the policy specifies that it needs to use separate SA. There is >no need to communicate this information to B, because there is no use >for B to verify that packets come from the right SA, as when the >packets arrive to the B the possible damage of messing up QoS is >already done. There will not be reordering problems because each SA >contains only one (or multiple if specified by policy) TOS values. > >When host B decides to send back packet with TOS 0x02, it notices that >it have 2 SA pairs up, and neither one of those is associated with any >TOS value. It selects any one of those SAs and associates it with TOS >value of 0x02. Lets say it took SPI-0x0001. For the next packet with >different TOS it tooks the next one (SPI-0x0002). If it have more >packets with different TOS, it needs to create more SA pairs. > >Now, when the host A is rekeying the SA pair SPI-0x0001, SPI-0x8001, >it will first create new SA pair SPI-0x0003, SPI-0x8003, and then >associate the SPI-0x8003 to TOS 0x01 because that was associated with >the SA it is rekeying. After that host A sends delete notification for >the SPI-0x0001. Host B sees that delete notification, and deletes the >SA pair SPI-0x0001, SPI-0x8001, and replies with delete notification >to SPI-0x8001. Next time host B tries to send packet with TOS 0x02 it >notices, that it does not have SA associated to that TOS value, thus >it takes the next non associated SA and assings it to TOS 0x02. > >Note, that this style option described here, can be made completely >optional, i.e if the other end does not support it it will simply see >multiple SAs and only use one of them (or all based on the >implementation), and the other end can send packets to separate SAs to >make sure them all arrive with proper QoS levels to other end. > > >As you can see from the above example it can be made work without any >need for actual negotiation of the TOS values in the IKEv2 level. We >do need the selector capability in the IPsec engine and architecture, >as we need to associate the TOS to some SAs. The selection of the >right outbound SA based on the TOS can be left to the local >implementation. I do not think we actually gain anything by doing the >checks for the inbound traffic (damage is already done when we see the >packet). > >I do not know if adding TOS to IKEv2 (and explicitly associate them to >SA pair) is better than this kind of decide on the fly style, but I >simply wanted to explain how I see, how this could be done. >-- >kivinen@ssh.fi >SSH Communications Security http://www.ssh.fi/ >SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jul 1 08:49:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61FndFK065063; Tue, 1 Jul 2003 08:49:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21673 Tue, 1 Jul 2003 11:13:52 -0400 (EDT) Date: Tue, 1 Jul 2003 11:19:46 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: QoS selectors (was LAST CALL: IKE) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 1 Jul 2003, Stephen Kent wrote: > >The only thing that comes to mind is to add a notify payload when > >rekeying that identifies the SPI of > >the SA being rekeyed. But this is a bits on wire change... > > ...Using the SPI to identify an SA being rekeyed avoids ambiguity, no > matter what the source, and that seems worthwhile. This sounds like an excellent idea. One substantial headache with IKEv1 was the extent to which the responding end had to *guess* what the initiating end was really trying to do. The fewer such ambiguities there are, the better. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jul 1 09:08:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61G8GFK066729; Tue, 1 Jul 2003 09:08:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21875 Tue, 1 Jul 2003 11:29:46 -0400 (EDT) Message-Id: <200307011531.h61FVUcJ010214@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: draft-ietf-ipsec-ikev2-algorithms: Remove DES, RC4, Blowfish, IDEA Cc: jis@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Jul 2003 11:31:30 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk There are several (4) tickets suggesting removing these algorithms from the ikev2-algorithms draft, or at least making them MAYs. There has been some discussion on the list, and the management group decided that we should remove them from the document but leave the code points defined in the IANA registry (just to have them allocated). -Angelos From owner-ipsec@lists.tislabs.com Tue Jul 1 09:51:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61Gp1FK068287; Tue, 1 Jul 2003 09:51:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22426 Tue, 1 Jul 2003 12:13:02 -0400 (EDT) Message-Id: <200307011614.h61GEccJ007082@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Francis Dupont Cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 and SCTP support In-reply-to: Your message of "Tue, 01 Jul 2003 18:15:07 +0200." <200307011615.h61GF7of091437@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 01 Jul 2003 12:14:38 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK, I see your points. What I'd like to hear (from others) is how important they feel SCTP support in IKEv2 is: does it have to happen *now*, or can it wait for a future document ? -Angelos In message <200307011615.h61GF7of091437@givry.rennes.enst-bretagne.fr>, Francis Dupont writes: > In your previous mail you wrote: > > In message <200307010840.h618exof089503@givry.rennes.enst-bretagne.fr>, > Francis Dupont writes: > > >=> I agree but is it important to fix this now or can we postpone this > >with the mobility stuff (in fact, SCTP/multi-homing and mobility share > >a lot of things)? > > Well, SCTP without mobility is simple to fix. > >=> I disagree: IKEv2 and the SCTP document changed the IKEv1 ID mess in >very different ways. > > >=> there is a third way: add an explicit management of peer address set > >as I suggested in my draft. > > The drawback is that there is an extra message etc. > >=> extra message? No, there is no extra message for the SCTP part. > > Also, as we discuss in RFC > 3554, it is unlikely that you will be getting a new address extremely > frequently (e.g., every minute), so you might as well do a full IKE exchang >e > when you do. > >=> this is an argument against the inclusion of a peer address update >payload for SCTP in the current IKEv2 draft. It seems we already agree >to postpone this. My proposal for SCTP is more about a peer address set >management which comes before a SA update mechanism. > > >=> this is another overloading of the ID payload. IMHO we can do better, > >so the question is postpone or delay? > > Except that we have already taken this approach for IKEv1, and the text > can be copied directly, so the third option is "integrate" :-) > >=> but this implies to go backward on everything about phase 1 IDs >in IKEv2. I don't believe we can reach a consensus about this: I am >afraid that the common answer will be "please wait". > > >=> argh! I am afraid that you missed a small detail: the ID_LIST is > >specified for the phase 2 so if you'd like to change the ID payload > >of IKEv2 which is *only* for phase 1 it is not so simple. > > That's incorrect. ID_LIST can be sent in "phase 1" as well. > >=> this is not what it is written in draft-ietf-ipsec-sctp-06.txt. >The ID_LIST is defined for phase 2 and the phase 1 text begins >by "Specify multiple Phase 1 IDs". But the problem is not there. > > > Furthermore, per soon-to-be-issued RFC 3554, the receiver must > > verify that the peer actually owns the relevant addresses in the TS > > payload. This typically means that these addresses must be > > contained in the certificate contained in the CERT payload, or some > > policy/configuration mechanism be consulted. > > > >=> this too shows that the ID payload way is not the right one because > >we remove this kind of constraints in the standard case. Of course, > >something should be done, and it will be nice to support changes > >in the peer address set... > > PKIX certificates already support this type of encoding, and > matching against it is trivial. Again, the changes I recommend are > purely textual, as opposed to adding a new message or exchange. > >=> my concern is not that this is difficult to implement (of course >it is not) but this is based on a specific semantics of phase 1 IDs: > > ... Currently, IKE can directly accommodate the simple case of two > machines talking to each other, by using Phase 1 IDs corresponding > to their IP addresses, and encoding those same addresses in the > SubjAltName of the certificates used to authenticate the Phase 1 > exchange. > >when IKEv2 just does the opposite: > > The Identification Payloads, denoted IDi and IDr in this memo, allow > peers to assert an identity to one another. This identity may be used > for policy lookup, but does not necessarily have to match anything in > the CERT payload; both fields may be used by an implementation to > perform access control decisions. > >IMHO we had enough problems with the overloading of IKEv1 IDs: please >don't add anything on the shoulders of IKEv2 IDs! Don't forget some >of us proposed to remove the ID payload... (ultimate cleanup :-) > >Thanks > >Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Jul 1 09:53:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61Gr6FK068360; Tue, 1 Jul 2003 09:53:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22378 Tue, 1 Jul 2003 12:09:09 -0400 (EDT) Message-Id: <200307011615.h61GF7of091437@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Angelos D. Keromytis" cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 and SCTP support In-reply-to: Your message of Tue, 01 Jul 2003 09:40:38 EDT. <200307011340.h61DeccJ021943@coredump.cs.columbia.edu> Date: Tue, 01 Jul 2003 18:15:07 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: In message <200307010840.h618exof089503@givry.rennes.enst-bretagne.fr>, Francis Dupont writes: >=> I agree but is it important to fix this now or can we postpone this >with the mobility stuff (in fact, SCTP/multi-homing and mobility share >a lot of things)? Well, SCTP without mobility is simple to fix. => I disagree: IKEv2 and the SCTP document changed the IKEv1 ID mess in very different ways. >=> there is a third way: add an explicit management of peer address set >as I suggested in my draft. The drawback is that there is an extra message etc. => extra message? No, there is no extra message for the SCTP part. Also, as we discuss in RFC 3554, it is unlikely that you will be getting a new address extremely frequently (e.g., every minute), so you might as well do a full IKE exchange when you do. => this is an argument against the inclusion of a peer address update payload for SCTP in the current IKEv2 draft. It seems we already agree to postpone this. My proposal for SCTP is more about a peer address set management which comes before a SA update mechanism. >=> this is another overloading of the ID payload. IMHO we can do better, >so the question is postpone or delay? Except that we have already taken this approach for IKEv1, and the text can be copied directly, so the third option is "integrate" :-) => but this implies to go backward on everything about phase 1 IDs in IKEv2. I don't believe we can reach a consensus about this: I am afraid that the common answer will be "please wait". >=> argh! I am afraid that you missed a small detail: the ID_LIST is >specified for the phase 2 so if you'd like to change the ID payload >of IKEv2 which is *only* for phase 1 it is not so simple. That's incorrect. ID_LIST can be sent in "phase 1" as well. => this is not what it is written in draft-ietf-ipsec-sctp-06.txt. The ID_LIST is defined for phase 2 and the phase 1 text begins by "Specify multiple Phase 1 IDs". But the problem is not there. > Furthermore, per soon-to-be-issued RFC 3554, the receiver must > verify that the peer actually owns the relevant addresses in the TS > payload. This typically means that these addresses must be > contained in the certificate contained in the CERT payload, or some > policy/configuration mechanism be consulted. > >=> this too shows that the ID payload way is not the right one because >we remove this kind of constraints in the standard case. Of course, >something should be done, and it will be nice to support changes >in the peer address set... PKIX certificates already support this type of encoding, and matching against it is trivial. Again, the changes I recommend are purely textual, as opposed to adding a new message or exchange. => my concern is not that this is difficult to implement (of course it is not) but this is based on a specific semantics of phase 1 IDs: ... Currently, IKE can directly accommodate the simple case of two machines talking to each other, by using Phase 1 IDs corresponding to their IP addresses, and encoding those same addresses in the SubjAltName of the certificates used to authenticate the Phase 1 exchange. when IKEv2 just does the opposite: The Identification Payloads, denoted IDi and IDr in this memo, allow peers to assert an identity to one another. This identity may be used for policy lookup, but does not necessarily have to match anything in the CERT payload; both fields may be used by an implementation to perform access control decisions. IMHO we had enough problems with the overloading of IKEv1 IDs: please don't add anything on the shoulders of IKEv2 IDs! Don't forget some of us proposed to remove the ID payload... (ultimate cleanup :-) Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Jul 1 10:13:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61HD2FK069107; Tue, 1 Jul 2003 10:13:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA22804 Tue, 1 Jul 2003 12:36:56 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CE70@corpmx14.us.dg.com> To: kivinen@ssh.fi, ipsec@lists.tislabs.com Subject: RE: Issue5 and ECN Date: Tue, 1 Jul 2003 12:33:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, > When checking issue 5 "ECN text in USE_TRANSPORT_MODE" I read > the section "2.24 ECN Notification". While reading it, I > noticed that the section DOES NOT have anything to do with > IKEv2, it only modifies some other documents (RFC2401 and RFC3168). Actually it does. IKEv1 had to negotiate ECN usage because one couldn't know whether the other end of the tunnel handled ECN correctly. For IKEv2 that negotiation is avoided by equating "other end of tunnel handles ECN correctly" with "other end of tunnel uses IKEv2 to create tunnel SA" (i.e., use of IKEv2 promises correct ECN handling). > I think that whole section should be removed, and moved to > the RFC2401bis instead. Earlier it was little bit different > because the support for ECN was negotiated in the IKEv1, but > now it is on by default, so I do not think we need anything > more in IKEv2 document than the text saying that the ECN > support should be done as defined in the RFC2401bis. That's ok if the WG can tolerate a normative reference from IKEv2 to 2401bis (i.e., can't publish IKEv2 RFC until 2401bis RFC is published). Avoiding this was the primary reason that the ECN text was pulled into IKEv2. > It makes quite hard for implementators if they have to read > unrelated documents (IKEv2) to see how to process ECN > modifiers instead of reading how to handle them from the > IPsec architecture document or the document which describes the ECN. I believe the intent is to put the ECN text into 2401bis regardless (so I agree with your new item for 2401bis). The ECN text is currently also in IKEv2 for the above timing/normative reference reasons. I have no issue with putting the ECN text solely in 2401bis if the normative reference from IKEv2 to 2401bis is acceptable. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Tue Jul 1 11:05:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61I5xFK073077; Tue, 1 Jul 2003 11:05:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23495 Tue, 1 Jul 2003 13:21:54 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16129.50279.783253.543846@ryijy.hel.fi.ssh.com> Date: Tue, 1 Jul 2003 20:27:03 +0300 From: Tero Kivinen To: Black_David@emc.com Cc: ipsec@lists.tislabs.com Subject: RE: Issue5 and ECN In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564CE70@corpmx14.us.dg.com> References: <277DD60FB639D511AC0400B0D068B71E0564CE70@corpmx14.us.dg.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Black_David@emc.com writes: > I believe the intent is to put the ECN text into 2401bis regardless > (so I agree with your new item for 2401bis). The ECN text is > currently also in IKEv2 for the above timing/normative reference > reasons. I have no issue with putting the ECN text solely in 2401bis > if the normative reference from IKEv2 to 2401bis is acceptable. I think there is no other choice than to put normative reference to 2401bis from IKEv2. The TOS traffic selectors, red-side fragmentation, all selectors being ranges etc are all of RFC2401bis changes that are also changes to IKEv2 too. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jul 1 11:19:56 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61IJtFK074285; Tue, 1 Jul 2003 11:19:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA23679 Tue, 1 Jul 2003 13:39:04 -0400 (EDT) Message-ID: <006401c33ff7$2bba2f80$2d05010a@trinc.com> From: "Arun" To: Subject: interoperability issue with 'lifekbytes' Date: Tue, 1 Jul 2003 10:35:31 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01C33FBC.7F3224A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0061_01C33FBC.7F3224A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We are frequently encountering interoperability problems with 'lifekbytes' configuration. Different vendors accept/implement different ways. Having consistent method mentioned in the standards will help eliminating/reducing the mis-interpretation. Any feedback on following interoperability issue from WG is appreciated. Security Gateway1--------------------Security Gateway2 Admin at SG1 configured the IPSEC security policy=20 indicating that 'lifekbytes' is not expected.=20 SG2 sends QM SA payload with lifekbytes attribute with some value. Should SG1 accept the SA payload OR should it deny the SA payload. We feel that, since local admin made a choice that lifekbytes is not required/expected, it should deny the SA negotiation. What is the right thing to do? Also, we feel that by having consistent configuration on both ends will eliminate the=20 confusion.=20 Related question: What happens when SG1 starts the quick mode? Should SG2 deny the negotiation as it expected lifekbytes=20 attribute, but there is no 'lifekbytes' attribute coming from SG1? We feel that, for both cases to work, it is better to have same configuration on both ends so that it works consistently and give choice to the administrators. Thanks in advance, Arun ------=_NextPart_000_0061_01C33FBC.7F3224A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We are frequently encountering interoperability = problems =20 with 'lifekbytes' configuration. Different vendors = accept/implement =20 different ways. Having consistent method mentioned in the = standards=20 will help eliminating/reducing the mis-interpretation. Any = feedback on=20 following interoperability issue from WG is appreciated. Security Gateway1--------------------Security = Gateway2 Admin at SG1 configured the IPSEC security policy = indicating that 'lifekbytes' is not expected. SG2 sends QM SA = payload=20 with lifekbytes attribute with some value. Should SG1 accept = the SA=20 payload OR should it deny the SA payload. We feel that, since local admin made a choice that=20 lifekbytes is not required/expected, it should deny the SA=20 negotiation. What is the right thing to do? Also, we feel that = by=20 having consistent configuration on both ends will eliminate = the=20 confusion. Related question: What happens when SG1 starts the = quick=20 mode? Should SG2 deny the negotiation as it expected = lifekbytes=20 attribute, but there is no 'lifekbytes' attribute coming from = SG1? We feel that, for both cases to work, it is better to = have =20 same configuration on both ends so that it works consistently = and give=20 choice to the administrators. Thanks in advance, Arun ------=_NextPart_000_0061_01C33FBC.7F3224A0-- From owner-ipsec@lists.tislabs.com Tue Jul 1 12:37:28 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61JbRFK080472; Tue, 1 Jul 2003 12:37:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA24422 Tue, 1 Jul 2003 14:55:26 -0400 (EDT) Date: Tue, 1 Jul 2003 12:08:14 -0700 (PDT) From: Arun Kumar To: ipsec@lists.tislabs.com Subject: interoperability issue with 'lifekbytes' Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Sorry, my previous message format was bad. I'm resending it with proper format. We are frequently encountering interoperability problems with 'lifekbytes' configuration. Different vendors accept/implement different ways. Having consistent method mentioned in the standards will help eliminating/reducing the mis-interpretation. Any feedback on following interoperability issue from WG is appreciated. Security Gateway1--------------------Security Gateway2 Admin at SG1 configured the IPSEC security policy indicating that 'lifekbytes' is not expected. SG2 sends QM SA payload with lifekbytes attribute with some value. Should SG1 accept the SA payload OR should it deny the SA payload. We feel that, since local admin made a choice that lifekbytes is not required/expected, it should deny the SA negotiation. What is the right thing to do? Also, we feel that by having consistent configuration on both ends will eliminate the confusion. Related question: What happens when SG1 starts the quick mode? Should SG2 deny the negotiation as it expected lifekbytes attribute, but there is no 'lifekbytes' attribute coming from SG1? We feel that, for both cases to work, it is better to have same configuration on both ends so that it works consistently and give choice to the administrators. Thanks in advance, Arun From owner-ipsec@lists.tislabs.com Tue Jul 1 13:36:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61KaHFK083647; Tue, 1 Jul 2003 13:36:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA24917 Tue, 1 Jul 2003 15:58:21 -0400 (EDT) Date: Tue, 1 Jul 2003 23:05:13 +0300 (IDT) From: Hugo Krawczyk To: Tero Kivinen cc: IPsec WG Subject: RE: IKEv2: active user identity protection In-Reply-To: <16125.18207.934384.924599@ryijy.hel.fi.ssh.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero, you can say that it is too late for changes, or that the discussions in Feb/March (and even before) on this issue (roughly) showed that not enough people cared about the subject's issue, but please do not represent this as anything that was rejected on clear technical grounds or because ikev1 did not do it right, or because post-ikev2 solutions will work as fine. The (candidate) solutions in the setting of ikev2 are simple, they do not add (contrary to what you say below) any new mode of authentication (they slightly modify the EAP mode whichby itself is new and not implemented). I agree that a "pseudonym" solution as you suggest is better than nothing given the fact that ikev2 did not include this privacy defense. But it adds much more complexity than any of the solutions that we could accomdate in ikev2, and achieves significantly less; for example it ties your login to a single machine, something I doubt it is the desire of most organizations. I can certainly see much stronger arguments against the psedonym approach than arguments in favor of avoiding polling attacks on remote-access servers... But until someone appeals to a higher instance (God?) to the decision-making process in ikev2's last call I see this issue as closed. Hugo On Sat, 28 Jun 2003, Tero Kivinen wrote: > jknowles@SonicWALL.com writes: > > I also support Hugo's suggested changes to provide this > > protection. I think many end-user scenarios demand it. > > Aggressive mode failed to protect identities and is > > criticized for this (I heard today this exact criticism > > from a customer). We still have a chance to fix this > > without unnecessary delay. > > The IKEv2 will protect the identities for passive attacks. In the > IKEv1 aggressive mode there was no protection for the passive attacks > at all (execpt in RSA encryption mode, and there you also needed to > send the certificate to be used, so actually you always gave out your > identity...). Also note, that IKEv1 DID NOT protect initiators > identity in the main mode from the active attacks when using > signatures either. Also the preshared keys in main mode didn't offer > any real protection of the identity, because the responder needed to > know before decrypting the packet which key to use (i.e it needed to > know the who the other end based on the IP address). > > To make it simple list: > > 1) Current draft do protect identities from the passive attacks > always. > > 2) For the active attacks there is no way to protect both ends for > the identity (either one of them must first proof who they are). > (Ok, you could use one time identities stuff exchange inside the > encrypted exchange, and you actually can already use them in the > EAP cases without any changes to the protocol if you want to). > > 3) The question is who proofs the identity first, in the IKEv1 it > was always the initiator, for IKEv2 it is always the initiator > (i.e no change here). > > 4) Hugos proposal was to add new mode that would change the > protocol so that the responder would proof its identity first in > case of EAP is used, this opens attack called polling attack, > which allows active attacker to get proof who everybody is in > the internet if the other end is willing to talk EAP. > > 5) The current draft protects the identities better in real cases > than IKEv1 (in the IKEv1 in RSA encryption mode and in the > preshared keys active attacker couldn't go spoof the other end, > but on the other hand the real responder couldn't either go > forward before it know who the other end already was (i.e from > the IP address or if there was only one client). If the real > responder needed to know this based on the IP then the attacker > would learn that also quite quickly). > > So, I suggest that those who really have requirement that the > initiators identity must be protected against active attack use one > time identities (ID_KEY_ID), i.e the server have list of identities > for each client, and every time the client connects the client uses > the next one on the list. I.e the client never uses same identity, > thus giving the identity protection on the initiator even for active > attacks. > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ > From owner-ipsec@lists.tislabs.com Wed Jul 2 04:04:19 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62B4IFK051604; Wed, 2 Jul 2003 04:04:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00420 Wed, 2 Jul 2003 05:24:56 -0400 (EDT) Message-ID: <3F02A059.2080806@roc.co.in> Date: Wed, 02 Jul 2003 14:35:29 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arun Kumar CC: ipsec@lists.tislabs.com Subject: Re: interoperability issue with 'lifekbytes' References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Arun, If 'lifekbytes' is expected and if this attribute does not come from the peer,I feel, the SA coming from peer should be rejected. If 'lifekbytes' attribute comes in, but it is not expected, then it seems OK to accept 'lifekbytes' as it is more secure. But, at any time, we don't know which node initiates the quick mode negotiation. If one side negotiates, it succeeds and if other negotiates it does not succeed. So, it is better to have same configuration on both ends and deny the negotiation if it does not match the local configuration. Thereby, there is no confusion. Note that this configuration is supposed to be agreed upon by both administrators of the SGs and along with other parameters, this also can be agreed upon and configure same thing on both ends. I feel, there is no problem in expecting the configuration to be same on both ends. Regards Ravi Arun Kumar wrote: > Hi, > > Sorry, my previous message format was bad. I'm resending it with proper > format. > > We are frequently encountering interoperability problems > with 'lifekbytes' configuration. Different vendors accept/implement > different ways. Having consistent method mentioned in the > standards will help eliminating/reducing the mis-interpretation. > Any feedback on following interoperability issue from WG > is appreciated. > > Security Gateway1--------------------Security Gateway2 > > Admin at SG1 configured the IPSEC security policy > indicating that 'lifekbytes' is not expected. > SG2 sends QM SA payload with lifekbytes attribute with some > value. Should SG1 accept the SA payload OR should it deny > the SA payload. > > We feel that, since local admin made a choice that lifekbytes > is not required/expected, it should deny the SA negotiation. > What is the right thing to do? Also, we feel that by having > consistent configuration on both ends will eliminate the > confusion. > > Related question: > What happens when SG1 starts the quick mode? > Should SG2 deny the negotiation as it expected lifekbytes > attribute, but there is no 'lifekbytes' attribute coming from SG1? > > We feel that, for both cases to work, it is better to have > same configuration on both ends so that it works consistently > and give choice to the administrators. > > Thanks in advance, > Arun > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Wed Jul 2 07:14:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62EEuFK058476; Wed, 2 Jul 2003 07:14:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02361 Wed, 2 Jul 2003 09:38:27 -0400 (EDT) Message-Id: <200307021055.GAA02547@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-pki-profile-03.txt Date: Wed, 02 Jul 2003 06:55:07 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --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 : The Internet IP Security PKI Profile of ISAKMP and PKIX Author(s) : B. Korver, E. Rescorla Filename : draft-ietf-ipsec-pki-profile-03.txt Pages : 35 Date : 2003-7-1 ISAKMP and PKIX both provide frameworks that must be profiled for use in a given application. This document provides a profile of ISAKMP and PKIX that defines the requirements for using PKI technology in the context of IPsec. The document compliments protocol specifications such as IKE, which assume the existence of public key certificates and related keying materials, but which do not address PKI issues explicitly. This document addresses those issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-profile-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-pki-profile-03.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-pki-profile-03.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: <2003-7-1134508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-pki-profile-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-pki-profile-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1134508.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jul 2 07:28:30 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62ESTFK060475; Wed, 2 Jul 2003 07:28:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02499 Wed, 2 Jul 2003 09:51:26 -0400 (EDT) Message-ID: <003301c340a0$f88310f0$b64f728c@timl> From: "Yi-Wen Liu" To: Subject: IPsec VPN Gateway Date: Wed, 2 Jul 2003 21:51:00 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01C340E4.0695AF20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C340E4.0695AF20 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi folks: I have a question of VPN gateway. If a user's IP is assigned by DHCP = on external network,=20 can he communicate with Intranet through the VPN gateway? Anybody knows? Please help me. Thanks a lot! Best Regards, Tim Liu ------=_NextPart_000_0030_01C340E4.0695AF20 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable Hi folks: I have a question of VPN gateway. If a user's IP = is=20 assigned by DHCP on external network, can he communicate with Intranet through the VPN gateway? Anybody knows? Please help me. Thanks a lot! Best Regards, Tim Liu ------=_NextPart_000_0030_01C340E4.0695AF20-- From owner-ipsec@lists.tislabs.com Wed Jul 2 11:56:36 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62IuZFK078124; Wed, 2 Jul 2003 11:56:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04159 Wed, 2 Jul 2003 14:08:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20030702104352.03501ee8@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 02 Jul 2003 10:58:07 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: Issue 9: Identity Protection Closed Cc: byfraser@cisco.com, tytso@mit.edu, angelos@cs.columbia.edu, Tero Kivinen In-Reply-To: <200306302137.h5ULbmcJ004413@coredump.cs.columbia.edu> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5417059==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_5417059==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi folks, Ted and I would like to officially state that the issue of addressing identity protection against active attacks is not going to be included in the base IKEv2 document. This decision was made months ago. There are ways to address this outside the IKEv2 base specification, should folks want to start up a new working group. Thanks, Barb and Ted --=====================_5417059==_.ALT Content-Type: text/html; charset="us-ascii" Hi folks, Ted and I would like to officially state that the issue of addressing identity protection against active attacks is not going to be included in the base IKEv2 document. This decision was made months ago. There are ways to address this outside the IKEv2 base specification, should folks want to start up a new working group. Thanks, Barb and Ted --=====================_5417059==_.ALT-- From owner-ipsec@lists.tislabs.com Wed Jul 2 14:53:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h62LreFK087443; Wed, 2 Jul 2003 14:53:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA04942 Wed, 2 Jul 2003 17:16:06 -0400 (EDT) Date: Wed, 2 Jul 2003 14:21:22 -0700 To: Barbara Fraser Cc: ipsec@lists.tislabs.com, tytso@mit.edu, angelos@cs.columbia.edu, Tero Kivinen Subject: Re: Issue 9: Identity Protection Closed Message-ID: <20030702212122.GB20444@steelhead> References: <3F009E0C.5010109@airespace.com> <4.3.2.7.2.20030702104352.03501ee8@mira-sjc5-4.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030702104352.03501ee8@mira-sjc5-4.cisco.com> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 54 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I'm working mainly in PANA WG and EAP WG and I recently joined this list. Please allow me to send this email after only rough reading of the thread on this issue. First of all, I agree that there is no need to change IKEv2 protocol behavior to support identity protection from active attacks. One way to address this is to use an anononymous identifier in IKEv2 ID payload sent by initiator and use a real identifier in an EAP-Identity exchange (or an identity exchange that may be defined in a particular EAP authentication method in IKE_AUTH exchange). If fact, a similar approach already exists. For example, some EAP-TTLS implementation allows an EAP peer to use an anonymous identity (e.g, anonymous@foo.bar.com) in the EAP-Identity request/response carried outside the TLS tunnel, and use a real identity (realname@foo.bar.com) in the EAP-Identity request/response performed inside the TLS tunnel. On the other hand, the following sentence in section 3.16 of the ikev2-08 draft seems to be a bit restrictive (if the above solution is valid) "Note that since IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be used." So, I'd like to suggest either removing the sentense or revising the sentense to: "Note that since IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be used if the initiator identity passed from IKE is used as the EAP peer identity." Regards, Yoshihiro Ohba On Wed, Jul 02, 2003 at 10:58:07AM -0700, Barbara Fraser wrote: > Hi folks, > > Ted and I would like to officially state that the issue of addressing > identity protection against active attacks is not going to be included in > the base IKEv2 document. This decision was made months ago. There are ways > to address this outside the IKEv2 base specification, should folks want to > start up a new working group. > > Thanks, > Barb and Ted From owner-ipsec@lists.tislabs.com Wed Jul 2 22:12:27 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h635CRFK003496; Wed, 2 Jul 2003 22:12:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA07696 Thu, 3 Jul 2003 00:30:26 -0400 (EDT) Message-ID: <3F03B398.7050600@roc.co.in> Date: Thu, 03 Jul 2003 10:09:52 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yi-Wen Liu CC: ipsec@lists.tislabs.com Subject: Re: IPsec VPN Gateway References: <003301c340a0$f88310f0$b64f728c@timl> Content-Type: text/plain; charset=Big5 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes. Remote Access is very common scenario. IPSEC implementations (we do this, not sure of others) do this in two ways. A. VPN gateway on the corporate edge should be configurable in 'responder-only' mode. It is expected that VPN client always initiates the connection. There could be multiple responder-only mode IKE policies. The way to select the right IKE policy is based on remote user identification. This is possible only if Aggressive mode is used OR main mode with certificates are used. Main mode with preshared keys can't be used. B. If your VPN client software has dynamic DNS capability, then you can create user based FQDN for each user. VPN gateway can be configured to have domain name in place peer security gateway IP address. Ravi Yi-Wen Liu wrote: > Hi folks: I have a question of VPN gateway. If a user's IP = is assigned > by DHCP on external network, can he communicate with Intranet through > the VPN gateway? Anybody knows? Please help me. Thanks a lot! Best > Regards, Tim Liu -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Wed Jul 2 22:39:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h635dIFK004225; Wed, 2 Jul 2003 22:39:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA07963 Thu, 3 Jul 2003 01:05:03 -0400 (EDT) Message-ID: <3F03BBAA.6090306@roc.co.in> Date: Thu, 03 Jul 2003 10:44:18 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: ipsec@lists.tislabs.com Subject: Re: IKE negotiation for fragmentation controls in IPsec References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Umm... The routers in between Security gateways can fragment the packets and how does the receiving SG behave? One way to ensure that the routers in between don't fragment is by attaching DF bit by transmitting SG and handling of ICMP PMTU messages. You seem to be suggesting that there could be active IP ID hijacking and confuse the receiving router and make SG to discard valid packets. Isn't this problem such a big problem? If so, majority of applications should fail. Also, if a hijacker can do this, why can't he/she spoof ICMP PMTU message to confuse the sender. Only other solution I could think of: Send the IP packet of length which is acceptable by all routers, I think it is around 570 bytes or so. But performance is going to be very bad and I don't think it is acceptable. If this feature to be implemented, there should be a way to find out the maximum path MTU using some other method. One way I could think on top of my head is: Sending SG finds out the path MTU periodically by starting with 1500 byte packet and reducing the packet size until the receiver receives it successfully. Receiver once receives the packet should ACK it. Sender should wait for some time before it reduces the packet size. Even this protocol also should be protected from hijacker in the middle. Thanks Ravi Stephen Kent wrote: > > A few folks have observed that the current processing requirements for > AH and ESP mandate ciphertext (post IPsec encapsulation) fragmentation > and that this poses DoS vulnerabilities for receivers. (An attacker can > create what appear to be legitimate, non-initial fragments and cause > reassembly problems for the receiver). > > As we revise 2401, we may choose to allow (or even recommend) plaintext > (pre-IPsec encapsulation) fragmentation. If so, we need to be able to > negotiate use of this capability on a per-SA basis, and to notify the > receiver that NO ciphertext fragments should be accepted for this SA, > because none will be sent by this transmitter. So, I suggest that we add > a paylod to IKE to allow an initiator to indicate the intent to never > send ciphertext fragments. The responder can take advantage of this info > to better protect itself, or it can ignore the info, but it needs to be > told to be able to take advantage of the capability. I would also like > to see the responder be able to notify the initiator of its intent re > the companion (reverse) SA, if appropriate. > > A logical (but admittedly separable) companion to this feature is to > allow the initiator to request the responder to accept fragments on an > SA where port fields are used as selectors. The issue here is that a > host may send fragments to an IPsec device that requires port field > examination for the SA to which the fragments will be mapped. It seems > reasonably safe to allow fragments (with a suitable, minimum offset) to > pass through such as SA, with only the initial fragment having the port > fields examined. This is a separate negotiation because the fragments > arise from hosts behind the IPsec device, but it is related, because if > one fragments at the sending IPsec device, it would be nice to be able > to use this feature to allow the receiver to pass on fragments, not > reassemble them (in the case of a SG). > > > Steve > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Wed Jul 2 23:18:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h636IAFK010487; Wed, 2 Jul 2003 23:18:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA08206 Thu, 3 Jul 2003 01:43:35 -0400 (EDT) From: "Yoav Nir" To: "'Yoshihiro Ohba'" , "'Barbara Fraser'" Cc: , , , "'Tero Kivinen'" Subject: RE: Issue 9: Identity Protection Closed Date: Thu, 3 Jul 2003 08:47:39 +0200 Message-ID: <00d501c3412e$ff3573a0$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: <20030702212122.GB20444@steelhead> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It is possible to have some convention, like sending an empty ID_KEY_ID from the client, or even adding a new ID type ID_ANON_USER. In this case, the gateway will do a full EAP, including the EAP-Identity request/response. If the user sends its ID in some other form, the gateway will only do the short version of EAP (less two packets). This will give users a trade-off between speed and identity protection, and it does not require a change to the IKEv2 draft. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Yoshihiro Ohba Sent: Wednesday, July 02, 2003 11:21 PM To: Barbara Fraser Cc: ipsec@lists.tislabs.com; tytso@mit.edu; angelos@cs.columbia.edu; Tero Kivinen Subject: Re: Issue 9: Identity Protection Closed Hi, I'm working mainly in PANA WG and EAP WG and I recently joined this list. Please allow me to send this email after only rough reading of the thread on this issue. First of all, I agree that there is no need to change IKEv2 protocol behavior to support identity protection from active attacks. One way to address this is to use an anononymous identifier in IKEv2 ID payload sent by initiator and use a real identifier in an EAP-Identity exchange (or an identity exchange that may be defined in a particular EAP authentication method in IKE_AUTH exchange). If fact, a similar approach already exists. For example, some EAP-TTLS implementation allows an EAP peer to use an anonymous identity (e.g, anonymous@foo.bar.com) in the EAP-Identity request/response carried outside the TLS tunnel, and use a real identity (realname@foo.bar.com) in the EAP-Identity request/response performed inside the TLS tunnel. On the other hand, the following sentence in section 3.16 of the ikev2-08 draft seems to be a bit restrictive (if the above solution is valid) "Note that since IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be used." So, I'd like to suggest either removing the sentense or revising the sentense to: "Note that since IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be used if the initiator identity passed from IKE is used as the EAP peer identity." Regards, Yoshihiro Ohba On Wed, Jul 02, 2003 at 10:58:07AM -0700, Barbara Fraser wrote: > Hi folks, > > Ted and I would like to officially state that the issue of addressing > identity protection against active attacks is not going to be included in > the base IKEv2 document. This decision was made months ago. There are ways > to address this outside the IKEv2 base specification, should folks want to > start up a new working group. > > Thanks, > Barb and Ted From owner-ipsec@lists.tislabs.com Thu Jul 3 02:23:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h639NIFK040583; Thu, 3 Jul 2003 02:23:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA09482 Thu, 3 Jul 2003 04:44:16 -0400 (EDT) From: "Yoav Nir" To: "'Tschofenig Hannes'" , "'Yoshihiro Ohba'" , "'Barbara Fraser'" Cc: , , , "'Tero Kivinen'" Subject: RE: Issue 9: Identity Protection Closed Date: Thu, 3 Jul 2003 11:48:40 +0200 Message-ID: <000001c34148$48889ff0$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BBFF6A@mchp905a.mch.sbs.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree. This should either be omitted or else rephrased: "Note that if IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity MAY be omitted." Can we agree on this phrasing? -----Original Message----- From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] Sent: Thursday, July 03, 2003 10:45 AM To: 'Yoav Nir'; 'Yoshihiro Ohba'; 'Barbara Fraser' Cc: ipsec@lists.tislabs.com; tytso@mit.edu; angelos@cs.columbia.edu; 'Tero Kivinen' Subject: RE: Issue 9: Identity Protection Closed hi yoav, i initially requested to drop the following sentence from section 3.16 of ikev2-v8: "Note that since IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be used." if you allow to eap as it is (with the eap identity exchange) then everything is fine. to me it seems that the SHOULD NOT prevents you from performing an eap identity exchange and you have to use the identity provided with message (3) from the initiator. ciao hannes > -----Original Message----- > From: Yoav Nir [mailto:ynir@CheckPoint.com] > Sent: Thursday, July 03, 2003 8:48 AM > To: 'Yoshihiro Ohba'; 'Barbara Fraser' > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; angelos@cs.columbia.edu; > 'Tero Kivinen' > Subject: RE: Issue 9: Identity Protection Closed > > > It is possible to have some convention, like sending an empty > ID_KEY_ID from > the client, or even adding a new ID type ID_ANON_USER. In > this case, the > gateway will do a full EAP, including the EAP-Identity > request/response. If > the user sends its ID in some other form, the gateway will > only do the short > version of EAP (less two packets). > > This will give users a trade-off between speed and identity > protection, and > it does not require a change to the IKEv2 draft. > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On > Behalf Of Yoshihiro Ohba > Sent: Wednesday, July 02, 2003 11:21 PM > To: Barbara Fraser > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; > angelos@cs.columbia.edu; Tero > Kivinen > Subject: Re: Issue 9: Identity Protection Closed > > > Hi, > > I'm working mainly in PANA WG and EAP WG and I recently joined this > list. Please allow me to send this email after only rough reading of > the thread on this issue. > > First of all, I agree that there is no need to change IKEv2 protocol > behavior to support identity protection from active attacks. > > One way to address this is to use an anononymous identifier in IKEv2 > ID payload sent by initiator and use a real identifier in an > EAP-Identity exchange (or an identity exchange that may be defined in > a particular EAP authentication method in IKE_AUTH exchange). > > If fact, a similar approach already exists. For example, some > EAP-TTLS implementation allows an EAP peer to use an anonymous > identity (e.g, anonymous@foo.bar.com) in the EAP-Identity > request/response carried outside the TLS tunnel, and use a real > identity (realname@foo.bar.com) in the EAP-Identity request/response > performed inside the TLS tunnel. > > On the other hand, the following sentence in section 3.16 of the > ikev2-08 draft seems to be a bit restrictive (if the above solution is > valid) > > "Note that since IKE passes an indication of initiator identity in > message 3 of the protocol, EAP based prompts for Identity > SHOULD NOT > be used." > > So, I'd like to suggest either removing the sentense or revising the > sentense to: > > "Note that since IKE passes an indication of initiator identity in > message 3 of the protocol, EAP based prompts for Identity > SHOULD NOT > be used if the initiator identity passed from IKE is used as the > EAP peer identity." > > > Regards, > Yoshihiro Ohba > > > > On Wed, Jul 02, 2003 at 10:58:07AM -0700, Barbara Fraser wrote: > > Hi folks, > > > > Ted and I would like to officially state that the issue of > addressing > > identity protection against active attacks is not going to > be included in > > the base IKEv2 document. This decision was made months ago. > There are ways > > to address this outside the IKEv2 base specification, > should folks want to > > start up a new working group. > > > > Thanks, > > Barb and Ted > From owner-ipsec@lists.tislabs.com Thu Jul 3 05:47:44 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63ClhFK056720; Thu, 3 Jul 2003 05:47:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA10958 Thu, 3 Jul 2003 08:05:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F03BBAA.6090306@roc.co.in> References: <3F03BBAA.6090306@roc.co.in> Date: Thu, 3 Jul 2003 08:08:47 -0400 To: Ravi From: Stephen Kent Subject: Re: IKE negotiation for fragmentation controls in IPsec Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:44 +0530 7/3/03, Ravi wrote: >Umm... The routers in between Security gateways can fragment > the packets and how does the receiving SG behave? One way > to ensure that the routers in between don't fragment is by attaching > DF bit by transmitting SG and handling of ICMP PMTU messages. > > You seem to be suggesting that there could be active IP ID hijacking > and confuse the receiving router and make SG to discard valid > packets. Isn't this problem such a big problem? If so, majority of > applications should fail. > > Also, if a hijacker can do this, why can't he/she spoof ICMP > PMTU message to confuse the sender. > > Only other solution I could think of: Send the IP packet of length > which is acceptable by all routers, I think it is around >570 bytes or so. > But performance is going to be very bad and I don't think it >is acceptable. > > If this feature to be implemented, there should be a way to find out > the maximum path MTU using some other method. One way I could > think on top of my head is: > Sending SG finds out the path MTU periodically by starting with > 1500 byte packet and reducing the packet size until the receiver > receives it successfully. Receiver once receives the packet should > ACK it. Sender should wait for some time before it reduces the packet > size. Even this protocol also should be protected from >hijacker in the middle. > > Thanks > Ravi > Ravi, I can't understand what you are trying to say above. the wording is just too confusing. try again. Steve From owner-ipsec@lists.tislabs.com Thu Jul 3 06:29:23 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63DTMFK058001; Thu, 3 Jul 2003 06:29:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11336 Thu, 3 Jul 2003 08:51:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 2 Jul 2003 15:03:46 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / IMC Subject: Fwd: I-D ACTION:draft-ietf-bmwg-ipsec-term-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The authors have made many revisions to the draft, and it should still be of interest to all IPsec implementers. --Paul Hoffman >To: IETF-Announce: ; >Cc: bmwg@ietf.org >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-bmwg-ipsec-term-01.txt >Date: Tue, 01 Jul 2003 07:21:15 -0400 >Sender: owner-ietf-announce@ietf.org > > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Benchmarking Methodology Working >Group of the IETF. > > Title : Terminology for Benchmarking IPsec Devices > Author(s) : M. Bustos et al. > Filename : draft-ietf-bmwg-ipsec-term-01.txt > Pages : 53 > Date : 2003-6-30 > >This purpose of this document is to define terminology specific to >measuring the performance of IPsec devices. It builds upon the >tenets set forth in RFC 1242, RFC 2544, RFC 2285 and other IETF >Benchmarking Methodology Working Group (BMWG) documents used for >benchmarking routers and switches. This document seeks to extend >these efforts specific to the IPsec paradigm. The BMWG produces >two major classes of documents: Benchmarking Terminology documents >and Benchmarking Methodology documents. The Terminology documents >present the benchmarks and other related terms. The Methodology >documents define the procedures required to collect the benchmarks >cited in the corresponding Terminology documents. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipsec-term-01.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >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-bmwg-ipsec-term-01.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-bmwg-ipsec-term-01.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. > > >[The following attachment must be fetched by mail. Command-click the >URL below and send the resulting message to get the attachment.] > >[The following attachment must be fetched by ftp. Command-click the >URL below to ask your ftp client to fetch it.] > From owner-ipsec@lists.tislabs.com Thu Jul 3 07:14:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EEnFK059465; Thu, 3 Jul 2003 07:14:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11742 Thu, 3 Jul 2003 09:38:03 -0400 (EDT) Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFF6A@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Yoav Nir'" , "'Yoshihiro Ohba'" , "'Barbara Fraser'" Cc: ipsec@lists.tislabs.com, tytso@mit.edu, angelos@cs.columbia.edu, "'Tero Kivinen'" Subject: RE: Issue 9: Identity Protection Closed Date: Thu, 3 Jul 2003 10:45:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi yoav, i initially requested to drop the following sentence from section 3.16 of ikev2-v8: "Note that since IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be used." if you allow to eap as it is (with the eap identity exchange) then everything is fine. to me it seems that the SHOULD NOT prevents you from performing an eap identity exchange and you have to use the identity provided with message (3) from the initiator. ciao hannes > -----Original Message----- > From: Yoav Nir [mailto:ynir@CheckPoint.com] > Sent: Thursday, July 03, 2003 8:48 AM > To: 'Yoshihiro Ohba'; 'Barbara Fraser' > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; angelos@cs.columbia.edu; > 'Tero Kivinen' > Subject: RE: Issue 9: Identity Protection Closed > > > It is possible to have some convention, like sending an empty > ID_KEY_ID from > the client, or even adding a new ID type ID_ANON_USER. In > this case, the > gateway will do a full EAP, including the EAP-Identity > request/response. If > the user sends its ID in some other form, the gateway will > only do the short > version of EAP (less two packets). > > This will give users a trade-off between speed and identity > protection, and > it does not require a change to the IKEv2 draft. > > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On > Behalf Of Yoshihiro Ohba > Sent: Wednesday, July 02, 2003 11:21 PM > To: Barbara Fraser > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; > angelos@cs.columbia.edu; Tero > Kivinen > Subject: Re: Issue 9: Identity Protection Closed > > > Hi, > > I'm working mainly in PANA WG and EAP WG and I recently joined this > list. Please allow me to send this email after only rough reading of > the thread on this issue. > > First of all, I agree that there is no need to change IKEv2 protocol > behavior to support identity protection from active attacks. > > One way to address this is to use an anononymous identifier in IKEv2 > ID payload sent by initiator and use a real identifier in an > EAP-Identity exchange (or an identity exchange that may be defined in > a particular EAP authentication method in IKE_AUTH exchange). > > If fact, a similar approach already exists. For example, some > EAP-TTLS implementation allows an EAP peer to use an anonymous > identity (e.g, anonymous@foo.bar.com) in the EAP-Identity > request/response carried outside the TLS tunnel, and use a real > identity (realname@foo.bar.com) in the EAP-Identity request/response > performed inside the TLS tunnel. > > On the other hand, the following sentence in section 3.16 of the > ikev2-08 draft seems to be a bit restrictive (if the above solution is > valid) > > "Note that since IKE passes an indication of initiator identity in > message 3 of the protocol, EAP based prompts for Identity > SHOULD NOT > be used." > > So, I'd like to suggest either removing the sentense or revising the > sentense to: > > "Note that since IKE passes an indication of initiator identity in > message 3 of the protocol, EAP based prompts for Identity > SHOULD NOT > be used if the initiator identity passed from IKE is used as the > EAP peer identity." > > > Regards, > Yoshihiro Ohba > > > > On Wed, Jul 02, 2003 at 10:58:07AM -0700, Barbara Fraser wrote: > > Hi folks, > > > > Ted and I would like to officially state that the issue of > addressing > > identity protection against active attacks is not going to > be included in > > the base IKEv2 document. This decision was made months ago. > There are ways > > to address this outside the IKEv2 base specification, > should folks want to > > start up a new working group. > > > > Thanks, > > Barb and Ted > From owner-ipsec@lists.tislabs.com Thu Jul 3 07:14:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EEqFK059473; Thu, 3 Jul 2003 07:14:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11773 Thu, 3 Jul 2003 09:39:21 -0400 (EDT) Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFF6C@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Yoav Nir'" , "'Yoshihiro Ohba'" , "'Barbara Fraser'" Cc: ipsec@lists.tislabs.com, tytso@mit.edu, angelos@cs.columbia.edu, "'Tero Kivinen'" Subject: RE: Issue 9: Identity Protection Closed Date: Thu, 3 Jul 2003 12:50:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk sounds good to me. > -----Original Message----- > From: Yoav Nir [mailto:ynir@CheckPoint.com] > Sent: Thursday, July 03, 2003 11:49 AM > To: Tschofenig Hannes; 'Yoshihiro Ohba'; 'Barbara Fraser' > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; angelos@cs.columbia.edu; > 'Tero Kivinen' > Subject: RE: Issue 9: Identity Protection Closed > > > I agree. This should either be omitted or else rephrased: > > "Note that if IKE passes an indication of initiator identity > in message 3 of > the protocol, EAP based prompts for Identity MAY be omitted." > > Can we agree on this phrasing? > > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, July 03, 2003 10:45 AM > To: 'Yoav Nir'; 'Yoshihiro Ohba'; 'Barbara Fraser' > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; angelos@cs.columbia.edu; > 'Tero Kivinen' > Subject: RE: Issue 9: Identity Protection Closed > > > hi yoav, > > i initially requested to drop the following sentence from > section 3.16 of > ikev2-v8: > > "Note that since IKE passes an indication of initiator > identity in message 3 > of the protocol, EAP based prompts for Identity SHOULD NOT be used." > > if you allow to eap as it is (with the eap identity exchange) then > everything is fine. to me it seems that the SHOULD NOT > prevents you from > performing an eap identity exchange and you have to use the identity > provided with message (3) from the initiator. > > ciao > hannes > > > > -----Original Message----- > > From: Yoav Nir [mailto:ynir@CheckPoint.com] > > Sent: Thursday, July 03, 2003 8:48 AM > > To: 'Yoshihiro Ohba'; 'Barbara Fraser' > > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; angelos@cs.columbia.edu; > > 'Tero Kivinen' > > Subject: RE: Issue 9: Identity Protection Closed > > > > > > It is possible to have some convention, like sending an empty > > ID_KEY_ID from > > the client, or even adding a new ID type ID_ANON_USER. In > > this case, the > > gateway will do a full EAP, including the EAP-Identity > > request/response. If > > the user sends its ID in some other form, the gateway will > > only do the short > > version of EAP (less two packets). > > > > This will give users a trade-off between speed and identity > > protection, and > > it does not require a change to the IKEv2 draft. > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On > > Behalf Of Yoshihiro Ohba > > Sent: Wednesday, July 02, 2003 11:21 PM > > To: Barbara Fraser > > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; > > angelos@cs.columbia.edu; Tero > > Kivinen > > Subject: Re: Issue 9: Identity Protection Closed > > > > > > Hi, > > > > I'm working mainly in PANA WG and EAP WG and I recently joined this > > list. Please allow me to send this email after only rough > reading of > > the thread on this issue. > > > > First of all, I agree that there is no need to change IKEv2 protocol > > behavior to support identity protection from active attacks. > > > > One way to address this is to use an anononymous identifier in IKEv2 > > ID payload sent by initiator and use a real identifier in an > > EAP-Identity exchange (or an identity exchange that may be > defined in > > a particular EAP authentication method in IKE_AUTH exchange). > > > > If fact, a similar approach already exists. For example, some > > EAP-TTLS implementation allows an EAP peer to use an anonymous > > identity (e.g, anonymous@foo.bar.com) in the EAP-Identity > > request/response carried outside the TLS tunnel, and use a real > > identity (realname@foo.bar.com) in the EAP-Identity request/response > > performed inside the TLS tunnel. > > > > On the other hand, the following sentence in section 3.16 of the > > ikev2-08 draft seems to be a bit restrictive (if the above > solution is > > valid) > > > > "Note that since IKE passes an indication of initiator > identity in > > message 3 of the protocol, EAP based prompts for Identity > > SHOULD NOT > > be used." > > > > So, I'd like to suggest either removing the sentense or revising the > > sentense to: > > > > "Note that since IKE passes an indication of initiator > identity in > > message 3 of the protocol, EAP based prompts for Identity > > SHOULD NOT > > be used if the initiator identity passed from IKE is used as the > > EAP peer identity." > > > > > > Regards, > > Yoshihiro Ohba > > > > > > > > On Wed, Jul 02, 2003 at 10:58:07AM -0700, Barbara Fraser wrote: > > > Hi folks, > > > > > > Ted and I would like to officially state that the issue of > > addressing > > > identity protection against active attacks is not going to > > be included in > > > the base IKEv2 document. This decision was made months ago. > > There are ways > > > to address this outside the IKEv2 base specification, > > should folks want to > > > start up a new working group. > > > > > > Thanks, > > > Barb and Ted > > > From owner-ipsec@lists.tislabs.com Thu Jul 3 07:15:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EFnFK059538; Thu, 3 Jul 2003 07:15:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA11760 Thu, 3 Jul 2003 09:38:41 -0400 (EDT) Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501ED5F43@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ipsec@lists.tislabs.com Cc: "Bert Wijnen (E-mail)" , StuartP.Brookes@gbr.xerox.com Subject: FW: FW: Implementing IPsec and SSL MIBS? How.... Date: Thu, 3 Jul 2003 11:22:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It seems to me that this question may be best posted to the IPsec WG mailing list (which I am doing now). Thanks, Bert >-----Original Message----- >From: Brookes, Stuart P [mailto:StuartP.Brookes@gbr.xerox.com] >Sent: vrijdag 13 juni 2003 11:40 >To: 'ietf@IETF.ORG' >Subject: Implementing IPsec and SSL MIBS? How.... > > >Hi, > >I am new to SNMP/MIBs, so am trying to keep my head above water at the >moment. > >I would like to implement three simple MIB objects to monitor the following; > >SSL enabled/disabled (read only MIB object) >SSL port number (read only) >IPsec enabled/disabled (read only) > >There does not appear to be any RFCs for either SSL (Secure Socket Layer) or >IPsec, only draft documents. > >I have found a high level IPsec Flow Monitoring MIB draft document. I can't >find any sort of 'IPsec enabled/disabled' MIB object? Similarly, would we be >required to implement all the mandatory MIB objects or not? > >With regards to SSL, I have looked at the draft document for this but it I >am struggling to understand the descriptions of the MIB objects, as they >don't seem to be laid out as they are in RFCs... Also, I am specifically >after SSL and not TLS. > >If anybody can help I'd be much obliged? > >Regards >Stuart > > > >_______________________________________________ >This message was passed through ietf_censored@carmen.ipv6.cselt.it, which is a > sublist of ietf@ietf.org. Not all messages are passed. Decisions on what to p >ass are made solely by Raffaele D'Albenzio. > --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) From owner-ipsec@lists.tislabs.com Thu Jul 3 07:39:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EdZFK060519; Thu, 3 Jul 2003 07:39:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12066 Thu, 3 Jul 2003 10:02:22 -0400 (EDT) Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFF77@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: ipsec@lists.tislabs.com Subject: IPv6 Flow Label as a Traffic Selector Date: Thu, 3 Jul 2003 15:40:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi all, the ipv6 flow label is a 3-tuple () (see [draft-ietf-ipv6-flow-label-07.txt]). for multiple tunnels with different qos properties it is better to use the ipv6 flow label instead of udp encapsulation. in case of rsvp the need for udp encapsulation is described in [rfc2746] (RSVP Operation Over IP Tunnels) and in [rfc3175] (Aggregation of RSVP for IPv4 and IPv6 Reservations ) for the case of different tunnel sessions. is there a possibility to support the above-mentioned 3-tuple as a traffic selector within ikev2? ciao hannes From owner-ipsec@lists.tislabs.com Thu Jul 3 07:41:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63EfOFK060609; Thu, 3 Jul 2003 07:41:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12126 Thu, 3 Jul 2003 10:09:03 -0400 (EDT) Date: Wed, 2 Jul 2003 20:12:39 -0700 To: Yoav Nir Cc: "'Tschofenig Hannes'" , "'Yoshihiro Ohba'" , "'Barbara Fraser'" , ipsec@lists.tislabs.com, tytso@mit.edu, angelos@cs.columbia.edu, "'Tero Kivinen'" Subject: Re: Issue 9: Identity Protection Closed Message-ID: <20030703031239.GA853@steelhead> References: <2A8DB02E3018D411901B009027FD3A3F03BBFF6A@mchp905a.mch.sbs.de> <000001c34148$48889ff0$292e1dc2@YnirNew> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <000001c34148$48889ff0$292e1dc2@YnirNew> User-Agent: Mutt/1.5.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20030601(IM145) Lines: 139 X-RAVMilter-Version: 8.4.2(snapshot 20021217) (thumper) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree on the new text. Thanks for the consideration. Yoshihiro Ohba On Thu, Jul 03, 2003 at 11:48:40AM +0200, Yoav Nir wrote: > I agree. This should either be omitted or else rephrased: > > "Note that if IKE passes an indication of initiator identity in message 3 of > the protocol, EAP based prompts for Identity MAY be omitted." > > Can we agree on this phrasing? > > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, July 03, 2003 10:45 AM > To: 'Yoav Nir'; 'Yoshihiro Ohba'; 'Barbara Fraser' > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; angelos@cs.columbia.edu; > 'Tero Kivinen' > Subject: RE: Issue 9: Identity Protection Closed > > > hi yoav, > > i initially requested to drop the following sentence from section 3.16 of > ikev2-v8: > > "Note that since IKE passes an indication of initiator identity in message 3 > of the protocol, EAP based prompts for Identity SHOULD NOT be used." > > if you allow to eap as it is (with the eap identity exchange) then > everything is fine. to me it seems that the SHOULD NOT prevents you from > performing an eap identity exchange and you have to use the identity > provided with message (3) from the initiator. > > ciao > hannes > > > > -----Original Message----- > > From: Yoav Nir [mailto:ynir@CheckPoint.com] > > Sent: Thursday, July 03, 2003 8:48 AM > > To: 'Yoshihiro Ohba'; 'Barbara Fraser' > > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; angelos@cs.columbia.edu; > > 'Tero Kivinen' > > Subject: RE: Issue 9: Identity Protection Closed > > > > > > It is possible to have some convention, like sending an empty > > ID_KEY_ID from > > the client, or even adding a new ID type ID_ANON_USER. In > > this case, the > > gateway will do a full EAP, including the EAP-Identity > > request/response. If > > the user sends its ID in some other form, the gateway will > > only do the short > > version of EAP (less two packets). > > > > This will give users a trade-off between speed and identity > > protection, and > > it does not require a change to the IKEv2 draft. > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On > > Behalf Of Yoshihiro Ohba > > Sent: Wednesday, July 02, 2003 11:21 PM > > To: Barbara Fraser > > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; > > angelos@cs.columbia.edu; Tero > > Kivinen > > Subject: Re: Issue 9: Identity Protection Closed > > > > > > Hi, > > > > I'm working mainly in PANA WG and EAP WG and I recently joined this > > list. Please allow me to send this email after only rough reading of > > the thread on this issue. > > > > First of all, I agree that there is no need to change IKEv2 protocol > > behavior to support identity protection from active attacks. > > > > One way to address this is to use an anononymous identifier in IKEv2 > > ID payload sent by initiator and use a real identifier in an > > EAP-Identity exchange (or an identity exchange that may be defined in > > a particular EAP authentication method in IKE_AUTH exchange). > > > > If fact, a similar approach already exists. For example, some > > EAP-TTLS implementation allows an EAP peer to use an anonymous > > identity (e.g, anonymous@foo.bar.com) in the EAP-Identity > > request/response carried outside the TLS tunnel, and use a real > > identity (realname@foo.bar.com) in the EAP-Identity request/response > > performed inside the TLS tunnel. > > > > On the other hand, the following sentence in section 3.16 of the > > ikev2-08 draft seems to be a bit restrictive (if the above solution is > > valid) > > > > "Note that since IKE passes an indication of initiator identity in > > message 3 of the protocol, EAP based prompts for Identity > > SHOULD NOT > > be used." > > > > So, I'd like to suggest either removing the sentense or revising the > > sentense to: > > > > "Note that since IKE passes an indication of initiator identity in > > message 3 of the protocol, EAP based prompts for Identity > > SHOULD NOT > > be used if the initiator identity passed from IKE is used as the > > EAP peer identity." > > > > > > Regards, > > Yoshihiro Ohba > > > > > > > > On Wed, Jul 02, 2003 at 10:58:07AM -0700, Barbara Fraser wrote: > > > Hi folks, > > > > > > Ted and I would like to officially state that the issue of > > addressing > > > identity protection against active attacks is not going to > > be included in > > > the base IKEv2 document. This decision was made months ago. > > There are ways > > > to address this outside the IKEv2 base specification, > > should folks want to > > > start up a new working group. > > > > > > Thanks, > > > Barb and Ted > > > > From owner-ipsec@lists.tislabs.com Thu Jul 3 08:27:22 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FRLFK065549; Thu, 3 Jul 2003 08:27:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12384 Thu, 3 Jul 2003 10:40:28 -0400 (EDT) From: ravivsn@roc.co.in X-Authentication-Warning: mail.roc.co.in: apache set sender to ravivsn@roc.co.in using -f Message-ID: <62692.12.234.153.99.1057244019.squirrel@mail.roc.co.in> Date: Thu, 3 Jul 2003 20:23:39 +0530 (IST) Subject: Re: IKE negotiation for fragmentation controls in IPsec To: X-Priority: 3 Importance: Normal Cc: X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Look like, as thoughts came to my mind, I have typed it. Sorry for that.. Here it is. You are trying to solve following problem: A person with malicious intention can confuse the receiver's IP reassembly logic by sending fragments with same IP identification field. IP reassembly logic can't distinguish packets coming from intended transmitter OR coming from hijacker and thereby IP reassembly logic might discard packets coming from the intended transmitter. Certainly, this is good thing to do. Today firewalls, can detect many of IP header integrity problems, but they can't do active hijacking as described above. Your suggestion to this problem is: IPSEC routers fragment the packets before applying IPSEC security, so that there is no fragmentation required on secured packets. On the receiving side, IPSEC router can discard the secured packets, if there is any fragmentation on them. Above solution works well, if intermediate routers don't fragment the packets. This can't be guaranteed. With existing technology, IPSEC routers can force the intermediate routers to send ICMP PMTU message, by setting the DF bit on outgoing secured packets. If Intermediate router finds that the packet size is more than the interface MTU, it sends the ICMP PMTU message with MTU size of its interface. Then onwards, sending IPSEC router can fragment the packets based on this. I think,above solution has problems: - Routers may not generate ICMP PMTU error messages. - Sending IPSEC router may not get these messages either due to Firewalls in between. - Hijacker also can send ICMP PMTU messages and make the MTU to such a small value and it can overload the sender. Sending IPSEC router does not have any way to find out whether the ICMP error message is genuine (generated by intermediate routers) or spoofed. Due to above problems, depending on ICMP error message would be disastrous and will not work. One solution which I could think of ( It is not optimum solution, but might work): IPSEC transmitter should find out the path MTU using Security association. Small lightweight protocol, that determines the Path MTU on continuous basis. It could be client and server protocol. Client starts sending message with 1500 bytes first with DF bit on. If server receives it, it sends ACK message. If Client does not receive ACK message for three attempts, then it should reduce the message size by 64 bytes and tries the same procedure again, until ACK is received. This message size can be considered as path MTU. In this, there is no assumption of intermediate routers/firewalls behavior and it is secured way to find out the PATH MTU. Regards Ravi From owner-ipsec@lists.tislabs.com Thu Jul 3 08:55:28 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63FtRqt001433; Thu, 3 Jul 2003 08:55:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12714 Thu, 3 Jul 2003 11:16:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <62692.12.234.153.99.1057244019.squirrel@mail.roc.co.in> References: <62692.12.234.153.99.1057244019.squirrel@mail.roc.co.in> Date: Thu, 3 Jul 2003 11:19:14 -0400 To: From: Stephen Kent Subject: Re: IKE negotiation for fragmentation controls in IPsec Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ravi, Thanks for taking the time to restate your comments. >Look like, as thoughts came to my mind, I have typed it. >Sorry for that.. Here it is. > >You are trying to solve following problem: > A person with malicious intention can confuse the receiver's IP > reassembly logic by sending fragments with same IP identification field. > IP reassembly logic can't distinguish packets coming from intended > transmitter OR coming from hijacker and thereby IP reassembly logic > might discard packets coming from the intended transmitter. Almost a correct description. the attacker can flood the receiver with non-initial fragments. whether they have the the same IP ID or not merely determines how they may be linked together by the receiver. also, the attacker is not a "hijacker" per se. >Certainly, this is good thing to do. Today firewalls, can detect many of >IP header integrity problems, but they can't do active hijacking as >described above. When you say "can't do active hijacking" do you mean cannot protect against this sort of attack? It is not a connection hijacking attack, since it does not require access to connection state data. >Your suggestion to this problem is: IPSEC routers fragment the packets >before applying IPSEC security, so that there is no fragmentation required >on secured packets. On the receiving side, IPSEC router can discard >the secured packets, if there is any fragmentation on them. Right, except that this can be done by IPsec end systems as well as security gateways. >Above solution works well, if intermediate routers don't fragment >the packets. This can't be guaranteed. right, by asserting the DF bit. >With existing technology, IPSEC routers can force the intermediate routers >to send ICMP PMTU message, by setting the DF bit on outgoing secured >packets. If Intermediate router finds that the packet size is more than the >interface MTU, it sends the ICMP PMTU message with MTU size of its >interface. Then onwards, sending IPSEC router can fragment the packets >based on this. yes, if the intermediate systems behave as the RFcs say, this would work. > >I think,above solution has problems: > - Routers may not generate ICMP PMTU error messages. true, which is why I suggested that we might want the IPsec peers to engage in a PMTU discovery within a tunnel. > - Sending IPSEC router may not get these messages either due to > Firewalls in between. same solution as above. > - Hijacker also can send ICMP PMTU messages and make the MTU to such a > small value and it can overload the sender. Sending IPSEC router > does not have any way to find out whether the ICMP error message is > genuine (generated by intermediate routers) or spoofed. irrespective of the proposed fragmentation approach, this attack could occur. again, engaging in PMTU discovery within the tunnel avoids this problem. >Due to above problems, depending on ICMP error message would be disastrous > and will not work. in some instances yes, but not not in all. and, as I noted above 3 times, use of PMTU discovery ( within the tunnel) between the IPsec peers avoids these concerns. >One solution which I could think of > ( It is not optimum solution, but might work): > IPSEC transmitter should find out the path MTU using Security association. > Small lightweight protocol, that determines the Path MTU on continuous > basis. It could be client and server protocol. Client starts sending > message with 1500 bytes first with DF bit on. If server receives it, it > sends ACK > message. If Client does not receive ACK message for three attempts, then > it should reduce the message size by 64 bytes and tries the same procedure > again, until ACK is received. This message size can be considered as > path MTU. > > In this, there is no assumption of intermediate routers/firewalls behavior > and it is secured way to find out the PATH MTU. Your solution appears to be an example of what I referred to earlier, and reiterated above. I leave it to others to suggest the specific mans of doing PMTU discovery, within a tunnel, between two IPsec peers. I disagree that the potential problems you cite above make the notion infeasible in the absence of such a facility, but I agree that it would be preferable to have a form of IPsec-to-IPsec PMTU discovery. Steve From owner-ipsec@lists.tislabs.com Fri Jul 4 12:51:59 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64Jpwqt014231; Fri, 4 Jul 2003 12:51:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA21932 Fri, 4 Jul 2003 14:55:15 -0400 (EDT) Message-ID: <3F05CB04.3020304@mit.edu> Date: Fri, 04 Jul 2003 14:44:20 -0400 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPSEC Mailing List Subject: Issues 31,34,36: New Version of draft-ietf-ipsec-ikev2 attached X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDA0002951A0C289729C40A8D" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDA0002951A0C289729C40A8D Content-Type: multipart/mixed; boundary="------------080400070002060405060102" This is a multi-part message in MIME format. --------------080400070002060405060102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit This hasn't been submitted to the I-D Directory due to it being closed. This version will likely have more edits before it does get submitted! Its attached as a PDF so I could highlight the changes (and it also saves me the step of converting it from a PDF to text. The source is in OpenOffice). -Jeff --------------080400070002060405060102 Content-Type: application/pdf; name="draft-ietf-ipsec-ikev2-03.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="draft-ietf-ipsec-ikev2-03.pdf" JVBERi0xLjIKJcfsj6IKNiAwIG9iago8PC9MZW5ndGggNyAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nI1XXW8iNxR951dYeWkiBRcGwodUVU0Tsk23Xe0mtPuw6YOZMeBm ZszaHgj763vunS8gqbSKFJKx7/c55w492Rc9+qk+46zztfPjw1CsfOer6PNR/RFn4tc5Dvv0 RPYmYr7slFZ9MZnKaCLG0VhGYp51zu8/Ps5uxGfrnk2+Eu+cLTYX8387g/6Y7vXEPOmc/66X S6f34l6Kx3ht0lQ7utOtLnWncjKYTqd89/7DfPbwYTbv3j5c383pWnP6R+c8cWoZukaHZdds vI675llvo65KV9aZsM58tzeQ4SVc/NAZjMdyPKozKNK9iHq9AceNxlM5Et1oKKMhH9+4/SbY lVObtYnFdeNNLK0ThdfC5CKsNRnD4jjfPGiX6yDeo8DZS7xW+UqLv7XzxuYiKuscUDi08mrE Nj99bxk/k/mYR9CNenIyYfPHoELhhV0iJ+PFnzqzHKZ/NZEjpNefymnEN+d0nti4yHQeBP5W wheLzHhObrGnosQbEyx9c71tgbN8ZXKtHd2aK/8s7qyLtXg6v5/N754upBA3NqNAXvi1LdJE LHQZLgSdYCLnwXJALvmX1PjgZTA+VQsvY5uJTJmUnNOJxH3UMZrw2G/xxJlFESjtuu4MdVNN RZ4axNAJ2bxRci6aEm6p73iS0AFmuizSVMQ2x5gzlaOYHbovVJrCE4Y87PWGHH/j7NZQz7jr jzrmREAP/PdwdxP1opGASQQ8j2rQf6kO/qEuXjHUygN5kg9SdLrCZZ8mV+GrhOaumktdUjV3 Lb53LpfCBM+TRBjlL7n82uuKpu2l+GCDhlcVhIVvVz3HRPbohrciqQegqcevc1L+tKjjAb5R sWASHPjYqtQkzDiFwC8mKzKq1ZsXkdk8rH05lLIz8El1UIJAWbFJFABwKZzepCqmv+DGLrxN NZ4T0su6DjImHOwZlSbTmEkoMaE2GPbGGUUNsUz+V8l7xFlqpwkxGS7iNiHmHDFhEhvupc6q mGhrTjZn1DZCHQKsnPZenh31aG5FqpVjpRFx4RwB2DdcR7YnmVyKDQyQYLzW8TMT9rhDZ32T dMGu4FRMXHsJZ0wumh1QHxRwk1Ta9qrKx7VK7I7KujUOiIcyaSQC0oSNNMRY+U0BZddLZ2JF OMtNLHPrkkKSm6fzWYFOapyQk6zIc+WMtN+kKsisoLRSw5aJl4bDkwe2/etRzJQPkBT8pivW kZcytpE6KcpLn3V7iSA36Nft7DMCr2S9Aq6rPlRSyQvgqhVK1kEdC6/LOpc0pmBjmxINnvGI oIDHW1RhMZL4cGec7qlWyam96IlmaLCOJFBFjfmasKdoWxNrMHB+OALsEqq2WSfg8vsZKcxk KIdHAjPsTV8JDDMcBttI0NFodGDDj9liGLUWTxdNauCepqjGZ8i4lKXhWA5P1l6uVzYwSXYo nzSzKbgVf3SM4UXQ1VtNLPA2hhXUU7Ik/WZ3OODe6NwXjjYtegDYOLXANghE77DTsIUEbZSj iCYD7onF7AgdpnV/DvbmGq30yu3Jn9/o2Cz3tPLQUQwOCg+VsOVp4+Mwc9QLR1UiEAhiF0xz 3V4qRRIb4lUWO7zXiLXaskKqLXaZWqSaBnu4kBK9BOn8Mcdf58cFvZVi/UKC++WEISw7jcj4 rComdrcWrHCUczuWxjEpo44V+UM+e2QAAOACsJBZOkWjmqy4LLixmcbeDNQiVs4j0kUnpAOi nU0K3pfHxBtNWuK9+QpV069GZlk79a3GXvkyUFEPu7rPKRzx8rB1NZAWkGWgLREba6p9qk7Y TKUeQFXcmiXrfXg1dZoD60bFOd5IVcbkJmks20ykaGBP1WNLAxYeIuv/F13kqhogQaycwk6V UG4YE2q4Of21aP3x5RJkXNlhSyrQGAybVtTbHDldVDQDxQhA+Qed29MK5ZC53h1JQuGWWMu8 dExeQD7TfbOrps021y/VcjowpTeFQzPwMqj4GW974jpvL1KC5VcV+Fro1KC/jF8qERiE02AT ta/fGBK8POa0EEJzbacVliiQ75zdyZP03hnSL3rvvCy5u7bQ7e+RlZZ4ZY6DqIQpwkP8MV4e J3Wf2GZyvMt+Yz5iVT+jkLW1CcUxAS7KzZ0RQY3nl2p8txiMyncs1oPrQ+YPJoP2O9CXjwq0 4i9no1b6+7wiqn94Mczm4lPnU+c/OTWb8GVuZHN0cmVhbQplbmRvYmoKNyAwIG9iagoxNjMx CmVuZG9iagoxMSAwIG9iago8PC9SNAo0IDAgUj4+CmVuZG9iagoxMiAwIG9iago8PC9SMTAK MTAgMCBSPj4KZW5kb2JqCjE3IDAgb2JqCjw8L0xlbmd0aCAxOCAwIFIvRmlsdGVyIC9GbGF0 ZURlY29kZT4+CnN0cmVhbQp4nI1WwXLbNhC96yswvlSZmqxIyrbUm+M4YzdJk9jKoZP0AJFL CTEJMAAkRf367i5AUXbiTiczEU0CD2/fvt3FJM3EhP7F37IdfRt9Exm/63/KVrxcjH67y87w TTqZiUU9CsszMZ+IiyxLZ1OxaEfjV1bWPlHg60R1DspEPcA2T2SzMlb5deuSSZH67/7F4uuo uLhIL84RZFGNxn9smr3IJ5OCviTxU5LP03zG379tVPnQ7FOxWJvNau2Fw9+mErJxRixBrNQW tPBGdGBrY1upSxCl0U5VYKVX+CSkI3Aki9CLt6MxLtqLjQMnTC1uP9xDKXaqaQhOaQF6q6zR LWjvxG4NFh5hK8R78ctojGeUYHWKz3mWZjkjv1ZaNhjQDoQGqIiXhdKstPoHhF9Lj/+BQKBK emP39F21XQN0GALN01kxn88Z6iDdl7H78gL37A+Q5VrqFQizBSu8aoHeyUp2nh7oAF6g9Ip4 7oxtqlS8Nrh2jeQtSGc0L3PQQEkSkQ7PkhqYoBySAFo8uRK1NW0MB1W7fXO9zYXroFS1Kll4 gYiia2SJi5UmJCZQmXJD0Km4dJGtUSgscjicFEN0p8JolPPRPgKKJugFwcRtOmQPFaUjm6fn M9bwtgJOx/OiHx2J53vTGmvNbjAZqlXtQ2amk8mUUfE0uZWqkcuGDdMa5wfE6LmDs5bheM6T 8mSfVlZAQRwYobmNqGWpGoXbIYSLFmJTSu+hDalFS2uvagI0Dp6k5suY/SXRrg/a7KgmKrlH 5ygtnui+YFPjK20IZLWRVmoPRw49TjmgvI2CLQREduLyWE8+gOnUG7+xkTe+xZA8Li0Nhu4M 5pvCGZCPaDJtt1l+RT+yUdDkdt95s7KyW6uSVJDlwylbKhJYWvMAXH9Fls5D/RWc/7O07y53 gP3DQqjlBdhWadOY1Z6bDa9L8jN2Cy5+A3sslsqJk3ef7hcnp+FX/Pmen++uP366vbt+Rc/3 N+8/vT164jXEjXBDEQernLy7/OskyCq7DqT9IRscebCwwhzYzgLaGFuWqMCVVi2hIkFwG0U2 i3F9vnt9lWfZ/G868Gya5tP4IeXILnJ6k8RCwNe3WIxVpbgqe2NVUCtNicHs9B9lI5AD5oYc 8jthnafz88kkQ53ytMgZLMT8K/fUyTSd9aQWFBdtFy1IHWrbSUJ3IuxJxY3ZAbUtrgRCGDc4 KbhESSN9VI+ttA9BiXhg36RJjw6bj2GhfIggWq9vh1SjgtKHi5PIkhJenB+FkDwfgvsfMUjN ATzPOOmtWgGmtaT+xK2aAkBjkBdkTxwBXezEj6v15wFQaP9B/yfsacfAHU0A3zuqNg4hitgZ 9GDfBWjQHUJj6bURjcG2bGMSgsKPwjhq7o3niY2pdsJhX9s4cnC4RmBp9BO3As91GXIpRYMy hbF2Gl3yeC6G+cW9F7UMQQTKqh54WNiqXk/We6i3BvGjNMyKl3AkyRAwnc3Tk1hiA6ERh0c0 eDiRjGWPM7V/TkKiwo0oKaZ9sUy5Io9a0uVB0/t+/B53o3Cj4o0Zb80vDlvDjH0OgBc+AQgQ BU2viHGtubGi2h/kvjGyGvBcuILNQwRZ3ztwWsTp/uNeG/qrE0vj16gFXorqMKUkzrL9oGew GTZvLHHqcyv76HNs27PQNemucvUEqXh1fZ9cvbzi+1f03TDEEfgSv2f57LDmiW1iDwkXoYHB zbvLq+T+5jL7GS6xmmZpHPtP1CdfFrNiuMl+/iDxUsZ6nw8NOecmGv/gdn29EB9HH0f/AmZ3 mqVlbmRzdHJlYW0KZW5kb2JqCjE4IDAgb2JqCjEzMzUKZW5kb2JqCjE5IDAgb2JqCjw8L1Ix NQoxNSAwIFI+PgplbmRvYmoKMjQgMCBvYmoKPDwvTGVuZ3RoIDI1IDAgUi9GaWx0ZXIgL0Zs YXRlRGVjb2RlPj4Kc3RyZWFtCnicrVdtU9s4EP7uX6FvpXNjn94tfwxJenAHtA1pbzotw5hE Ad8lDrUdKP/+VlIcO5YzAxzDkMDu6lnp2TcJRwRh87P9nq2Cn8FPRKys/pqt0PE0+H1CKUgi rNB0EThzghKMYkIixdF0FRyNinRRhZmuFmF2X+pZmP2rH2iYLm/XRVbdrcoQs6j6Vb2f/hOw OI5iCSDTeXD052b5hCjGzGhCo8IchVRFyqp5RCIa2VWJ8eUWjbLFItPhiV4uV2mO/ijWm/vS AnAcCYlCRiLpAKZ3utAohd9SP+giXaLzj6NP6NYuQdVdWlnlXC+yXM/RYl2gTalRlqPTv8YP NEIA8GSgwT1LkgRNz4Kj9gqwvFlXdwCl3RJ0kwLAfD3brHQO6Lm1MWrrWf+qdF5m67x8/y4A Vhm1kLW9c2j3BPrxFH3eMl7cvig8FIuIIglEUBugQi+AiHymLU8WF0wIWDD4wBIpBC4XL/Mh haG5cZLN4QQZhGbeOJEQD0khW1pOMHrZYRiVEZEtR+jmyYUQ5ZvVjS6inb9XkcVpEpE2W2iQ P9U5kq+rHToYEneaBBBeQZnhgSQRd1WzzMoKUmiXojPICuCwAFlaovPBN5St7pfa5sVuDwqS UJKYAv0SAF/HKKESCcUjpexGbAWhC8ulcUQge1hdosdZhc50flvdWRWjEVdb1WWVVhubURKk dXW6ynAFjXFEoaAJjRJptdTDJ5hyD/n8y+W0g/t98mFIOU6uusjAhdELH1kw6e/55OOXs9EL sQn3wCkGSFvSlr0Dfn7rccQElVtHTFpHjBncuuExr+G5xjIt0ryEDrVC06d7DVEc7NqrQ7Mr Qirq5ueWuXiUuwZ4vy7L7GYJKbdbbvueg9fFFn3b9DiGhmw61I8jaB/F030FvevHe9unSr3X PG/0cv2IHjPXDbOiyd7ULEKly5Z3MAGgzkJKTa82+7xIV9ryR5QRuTM32chlI90mFzrNLbGx OWo3F0MKcVAQPlGzOhlfjidfxyPPCbb2W1FrwfhiOLkejS+vT79K7q0i3V2ZqBJF4ytvUzYJ wv5d1U48fNqHD+kpXoHP+hywfgeCeA7qOjyAPhkKD5w/H3zwrYPdgj4djQcetvgf2O19Dwfu WHvg8o3Aj88+/v3h9PLEcxC/kQPWy416I3SX9ox6DhIn4aZlPQdoMuwpHfwMkBbGxZezMx+k twApJ/gZRzU31hp94Grj9TcHEosogVEseORG+jWhqoGMRQI6yRDs7bWXH7gcm8tPy8XweGjP b4jCMHAwxsLxQj1yW1Nox4G9fr89B9DVCT1EAoObzxuQ0PIxnE4OsMAOsOBIiDHMWzt263nL nzdv6eF5m7hbwv4EbdvbOQkPo818HYLRfL1Ci00+M2OxNA+OOarW6FbnMKAr3X1ubBc8pMsN jPHHO52jXOu5nkdmlgoTTTNMGd0bpokytztvljIYvX2jNMZR3ySFK5BqF2V7krY9uEHqJK0+ 8Gny4frkfDC8Ph+J7hLS2Y+tYYL5VWc7uxLmKpLmsmRuD02U9oPCFGsel98/pbfwjjJi2SSD TY/a5KrJU2iVcCcmAjHJMGIuUSmFIAgOjySGBKSeFTJJmRPyRsgpjz2hA5Vw5jaokwrRI+UC rltw/1SA4jZgECkjZgOUCbyVqoT7UiZi5ksdLoPHnsXd80aSeM+bk2LOfVumoIR9acz6bIXC Pi7jNO6xpbBp35bQHm80kbJHqkifrXl5eriQRN39Ar+EqRjASdKEHf4mOI5hMZd1KCTfClkj ZEz4lg7UfLRBXdg7ueSECcd7ucBVTA4kk13fTZsDQZcmxVqH5RT0/bZO6hHTOa0TCqb2DsYJ pH6/qRFa01qKssC8hh4DxaBrw5sbWgJHq/pfqkzhL4PLfcFOT6RpGI2eSvtV66kwDaut5wJu A42eAdFG+zn4D4YXblVlbmRzdHJlYW0KZW5kb2JqCjI1IDAgb2JqCjE0NTMKZW5kb2JqCjI2 IDAgb2JqCjw8L1IyMgoyMiAwIFI+PgplbmRvYmoKMzEgMCBvYmoKPDwvTGVuZ3RoIDMyIDAg Ui9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicrVdtb9s2EP7uX3HIl6ZYpEki9QYM A9wkXbw0aZo4e0FbBLRM21plyRXpJP73uyNlW5adrR2GBLB0JJ+7e/jcifRcHzz6a36zee9r 7yv4xrb+yebwZtj78TZI0eJ6CQwnPTvdh9SD2PfdhMNw3js+q8VEO7nUEydfKJk5+Rf5GDii mFZ1rmdz5XjM1c/69fCvHotjN44QZDjuHf+6LFYQeB6jEYfxABzmu1FiBq/FXJI9TdwkaRZc L+cjWZOVMzdojGdykpdyDIOSBmLPXc++00IvlcEO/IBQHD90WWQGb27fPlxc9U8f7i76ftdP 0HHx8fbtaeB7/HPHw9X93fDf8IeDX85vuw7Ytzro//kP+P3zOz9IHk7fnHbxeRf/dHBz4eD8 rQPHc3niebi9hquL9/fvzmjwfAgfmo2up9+lChZziiBizI2MMH7Y4OEQDfgcIh8SqCVMeh58 HzyKLkzjBpq7vhu6RlEp6dCmObg8fwxgWItSTap6DsPVQgKD/kaJVmhmhROEa6nZBbLenw8C Qx2UWk7xfQVbScNSoeR0BYu60jIz2kZYlqbI57ve8VhoAWIq8lJp0GK+kHVeTt3Xr3ospAJw gsANox2h+37k8j2hR4nrRweVnoQu5wekHnttnVy/vz7vontmorXYqZ5vBvr3wwur2quz8CGN ugv9bkRGt9xjn7sBbYS7G83WAZXdAQ/BCx74vodN7R1wcXZ+94Beuuim7PyQ9Hk4zBbE5c3Z JdHQxeCHIvSTIPouDrAUH/7Awj1AQbgNkmo0TtPkfytRzgLgPHIj3ilQzvwUR7gp0PQ/FyhH I7YAwrbVaThtNCqzpami06pU+VjWQuf4ZLVI09oVOZOg1vOrCWT1aqGraS0WszyDkaDiUyul JVbiWC5kOVZQlTCq9Az0THarUelallMcQygc7sC1qjqbVUqWJ2ZSZxGWbpMxAn6Rq6YFPOXG JS5r44hybDAQACvW1P7aNzWMKqsKxGuHaMBGK+vZZEbdRZZqiXuhZ0LTCD5SQyor/C+d3Sye xEoh5jGuGq0WQikL1SKR3qtH5L0oGhfUj/zUkP6OSM+RzSpbzmWpIavKTNalglwrWUzWiRJk gQ0Pt25vY2xK3KNugngtPrAbm7WYJa0yffoE1EJm+STPMKDVYXxK6OgK2RS6qlfEyGC+KCQF eNTi2wUSTMsfyqvUCI2c5iWi5oaaTW5CAbUPyNdggPHZ+mrZLNUavpTVU0m+RySC41FdfZEl 2B0BpLemyTqfS7Ptu7tSSyVFnc1AVTARNRRSjEk5652SRS4ftxtMNODuFHiCQkpqOccPiN1D iYngAnKJZCKqFKPCxDNZahx24aJ6Qqj6xKQLuSpfaShlJpUSdY5otAzHXfhdwlO1LMZWUWQm GPmMu6FtJKV8QuePuaICtdJpS8PEOMKIlFoiw5O6mtv8dWXyMo+Eg+iFBd0SNZL4RVzUArc4 k+vdIa4FqTGwp0pUT2TEuW0fg/51/9taRzvUcSWV2cSx+XbiDq2a7KY5FnhuRmuQdsuRtrLp HRsVy2ecSPW7XeLCb6JY4tJp/ohKMHVJCn9Eoqul2mkEllwsx3xaWjVWRPsmQtsrkCgEwYIb b9GwABE9JyvNIZisEFTMu0TFHaKu8eSD/KCqbteoDVOcPlpEGK3cPxUyorDp1S68xUMRqvAE 8PlSFoVcncCtC78UssQGeUQFhyvhNF9QOpsjU5c+yg47CNxj5ZsSH9AVAX4ady8NGQI5Qion GymHkvVCujT8fHRirwiveo6N0ME2jJ8xk4BpJHvRn2LEYjmZCwqUTm91KTUmsYLz52wmyqmE T/as+Ok13DT9eB2SoSoOXR9vI0HcnAjswXL3HMkStr3KfLwRiGrMkRvsnhWal8/bT3fAfIhi PP8FKX52mf3cBgE+RwFC4keYxY0x4o2RbY2MhfszLWjkBTug1srx9G2svGUNGUKzMAzX1oCl dDrwCNb3Pa9x5pGfPWuKCMbKWlaL66eRxW3HEHp4vduz8gRPC+0YrDVm4YG5YZzuW7vcWGPq pTsJc5/HL0wl4x5jL2QWemwnAh4n7IW51tqOFvJegIe8p17C8FiHmxLQ63z9yjy8PUHRu2sM PAzxzrcZ5xwvDoEZ/9D7G8y0SallbmRzdHJlYW0KZW5kb2JqCjMyIDAgb2JqCjE2MDkKZW5k b2JqCjMzIDAgb2JqCjw8L1IyOQoyOSAwIFI+PgplbmRvYmoKMzggMCBvYmoKPDwvTGVuZ3Ro IDM5IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnicjVZNc9s2EL3rV+z4Unkq sqS+mUOnsuxWjq3UsZX2EPcAk5CIhCQYgJSi/Pq+Belvx8l4xpII8O3bt4u3CPyQAv5rP+O8 86XzhUL37PYjzulo1fntcjDGEz+Y0mrdabaHFAU0CUN/OqRV3ukeG7GuPCWrtadKK2NPfZbb vieyjTaqSnPrBQO/+lodrj51BpOJPxkDZJV0um/rbE/9IBjwijcI+v54SF4/8vtTt/4MMhgz zu8HPXJvTAb+eEoemACSX/h4+ec8nPbH//Fys9pEuvRpVn1WhdVFjw5OL2hWV6ksKhWLSumC FlIk0gA3jKLRE+yWTIs9eQ3bb8BPiliUts6AXWzoSsY1dNjThdhnWiR03T25urg+POgxUuRP B1EU0eq803XBf7mLfbfURu8HL2R25dOREUkhDWK3m2iVSjotKmkKWdFVJYpEmMTShdGxtJY8 j1G6l3KrLGc/aBIfvxY7DIbPYi98OjNiF3/bf+7R0ic6klkmjOwRNJkLBK8UWC2Ws/kbOpN7 mXgLYVOI4uKvtaEl+IiNfFKPhs/kVT5h9GMtsInj0k5z+hyvtpJUQVi0VGmIlHBI2erxpVZG 5uBB53IrM+u/SGQYBMN7IsNg8IzI3KelSFyzQYm/Mllw23FVPiC+XhNL4i2PR140ph3OCCih JwiFckxmiybw9PXAzyvyc4GvFjMvfBzahUV4+k7ox+IPg9Frod+hFY61EXYn8r3fEuD8jk+u vPnRnOaqTKVpUr11CfoX/+nka5mpWFV0+s/3eDyS4HkTLIThw9ijY0SeC2Nk1nznjiB+5fHx QH8wROtxOIUnX+NUFOjJ6+7p2Qmf0x/rEQYv2UKrP9ryDD3V6vDuw/k5O4TZl8567gVg+U8r 27pCU2zw4co5bU4v4IQ/o8oofInNhTRSGeE6Y5aI3D4oDIriLXUi28rck7KNS3V/oMBg9II1 rZC32qpCFs4dzvQnzWVYaiMJweCPhuutCz74IoPey7+PYYwu4LFar5X0FnCUXBS0MboumyP8 sHL0vFhg2XUzhdmO/LBP3iBkUkxp6rtaj/zbEcS+o42luS4qEaPtCoTInQm5MeC2ev3RLcBb uV4bxD316SpOVZa1bbwU8LE4hb1UlQWKrVRVV+7IrWScFjrTmz1Tu9QarR71vTAK+PdkQo/f nW1lUUtemov8xqhkAz9dzijoh4PIGw4CdqPuh6sZPsLI8UKTXKSQ8Q39GkKIcTi5PqT+aOAF 4TjEtocz5sTLhcre0Cdl/8hV5cukxo5WIaxHPuPeC/RnnWVQp9wbtUndMKmcQ76ozsH9xuvu HCQeDyIdY6LvscT1uT5EGwL7krdbupRWmq1MmgJFftR3dFapspTouHauzCekMqKwmauQZXnh FbnY042kWJdKJm7TujaFsil+VfqJABqDxqD3eRtmvtoCait5RHzGSEhFBZzcRcPhRLu5/TuF QyjhTQJ2iYjacBFQN2Urco8sqbzMnDTNlaIlVRpZYiQmvZZej8r6Jmu4sd0DJgGIUTdoF6wC bJfqTHJofMe7MA72aV1XZCTvjB0+UhfFnuB1iev50uitSjhjzgGkSdzorVOlLUmhMV9lIyLL CmyxMaJMCQQZQhVxVjME4AVKY+s4bWjbF+XyaaF3GJQYtwzocrktFRSR2dqpgLisRK4TteYC IS1mvhP7XhNCWLrZI7kcGeDCBO4M9Yw4FDFyDRcrcIvh6V291F23JWOIu0VtNqJQ35qu6aGS sSwrjltIyQmzrzBaWZtSN5My4RsAcsdl5SGSvbtNuUopVkjgDfc236+SGlVygHcJoIPlGj6Y NCI/4X0HWLbXs7y2TrC1zjLoi6YAGLia5n7S9nT39iBIbkhVQI8MTljjNmUbBbgTMNyLDbeb 39jF3bGSlCmcf6CV0uTKWnee0A4FP2taB23Bq6Wsatgzd8AOjtfWE3j9sd+MKFjvtv9gaLCj TAf3F/2PF3zHc/f/sd8ftk/dRft2i5seJyt633nf+R875bTPZW5kc3RyZWFtCmVuZG9iagoz OSAwIG9iagoxNTExCmVuZG9iago0MCAwIG9iago8PC9SMzYKMzYgMCBSPj4KZW5kb2JqCjQ1 IDAgb2JqCjw8L0xlbmd0aCA0NiAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nFWST2/iMBDF7/kUo16WSo03JBTI0QQD3oYktY26aLWHNBjwtiRtbFD59munsH+UgzXzxr/3 5EyA+hC473JWB+/de4d+17se1QEmwvvKBpHtoGAMYut9jvchDmDU76PxAMTB603bcmt8Jc3W V29aVr56kafQL193TavM/qD9IELmw9yKX140GqHR0ELExut9O76eIQyCyCn+RfLDGIXjTm/l qXmRG3g+g9lLoLWRbS0N8KaybmdoWlBGgz5WldS6abXrlFqrXa2RY4YRCmzG1OuJvdKwaarj QdYGynrTEVW9bdpDaVRTQ9XUplS1tdvLVqoa7IW3tjmpjW1Zvaxvv3gxGkdxHHfIG8yB8ht4 LrUddUixIEAzQVhGBPA8oUSsAWfT/wWSzWlGCKPZ3BJ7AvMHmOUsITClPEkxXXLAaQpPmDGc CUr4HZDvBSOcQ86ALouUkumdBSbpamopMFkJR8pyASldUkGsY26N11fG2ibAooux4gTy2SWR tV1iQfMMFoQRmsETTdMrysouI+lAjM4XovN31SXDPxEdc0lYsrAlntCUWs+cOdSMisxFn7m7 UGAmaLJKMYNixYqcE3Rjp+6jezT4/FP0gZxCwH+Wx6rROPq7ND+Kcieh26UhCgeX7tA1riM/ XWFf+tF79H4DrY3Lv2VuZHN0cmVhbQplbmRvYmoKNDYgMCBvYmoKNTAwCmVuZG9iago0NyAw IG9iago8PC9SNDMKNDMgMCBSPj4KZW5kb2JqCjUgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlh Qm94IFswIDAgNjEyIDc5Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwv UHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDExIDAgUgovRm9udCAxMiAwIFIKPj4K L0NvbnRlbnRzIDYgMCBSCj4+CmVuZG9iagoxNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFC b3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDE5IDAgUgo+PgovQ29udGVudHMgMTcgMCBSCj4+ CmVuZG9iagoyMyAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQov Um90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9Gb250IDI2IDAgUgo+PgovQ29udGVudHMgMjQgMCBSCj4+CmVuZG9iagozMCAwIG9iago8 PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMg MCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDMzIDAgUgo+Pgov Q29udGVudHMgMzEgMCBSCj4+CmVuZG9iagozNyAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFC b3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDQwIDAgUgo+PgovQ29udGVudHMgMzggMCBSCj4+ CmVuZG9iago0NCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQov Um90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9Gb250IDQ3IDAgUgo+PgovQ29udGVudHMgNDUgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8 IC9UeXBlIC9QYWdlcyAvS2lkcyBbCjUgMCBSCjE2IDAgUgoyMyAwIFIKMzAgMCBSCjM3IDAg Ugo0NCAwIFIKXSAvQ291bnQgNgo+PgplbmRvYmoKMSAwIG9iago8PC9UeXBlIC9DYXRhbG9n IC9QYWdlcyAzIDAgUgo+PgplbmRvYmoKNCAwIG9iago8PC9UeXBlL0V4dEdTdGF0ZS9OYW1l L1I0L1RSL0lkZW50aXR5Pj4KZW5kb2JqCjQyIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0 b3IvRm9udE5hbWUvRllGT1VZK0NvdXJpZXItQm9sZH4yYS9Gb250QkJveFstNDggLTI4OCA3 NDYgODQ3XS9GbGFncyA1Ci9Bc2NlbnQgODM5Ci9DYXBIZWlnaHQgODM5Ci9EZXNjZW50IC0y ODgKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDExMQovQXZnV2lkdGggNjAwCi9NYXhXaWR0aCA2 MDAKL01pc3NpbmdXaWR0aCA2MDAKL0NoYXJTZXQoL3NwYWNlL3F1b3RlZGJsL2NvbW1hL2h5 cGhlbi9wZXJpb2QvemVyby90d28vdGhyZWUvc2l4L0EvQi9DL0QvRS9GL0cvSC9JL0ovSy9M L00vTi9PL1AvUi9TL1QvVS9XL1gvWS9icmFja2V0bGVmdC9icmFja2V0cmlnaHQvYS9iL2Mv ZC9lL2YvZy9oL2kvay9sL20vbi9vL3Avci9zL3QvdS92L3gveSkKL0ZvbnRGaWxlMyA0MSAw IFI+PgplbmRvYmoKNDEgMCBvYmoKPDwvTGVuZ3RoIDQ4IDAgUi9TdWJ0eXBlL1R5cGUxQy9M ZW5ndGgxIDUwMTQ+PnN0cmVhbQoBAAQCAAEBARdGWUZPVVkrQ291cmllci1Cb2xkfjJhAAEB ASb4GwH4HAL4HQNb+7T5fvnjBR0ABAZsDaccE3gS+AYR95UP91QQAAMBAVxob0NvcHlyaWdo dCAoYykgSUJNIENvcnBvcmF0aW9uIDE5OTAsMTk5MS4gSUJNIENvdXJpZXIgaXMgYSBUcmFk ZW1hcmsgb2YgdGhlIElCTSBDb3Jwb3JhdGlvbi5Db3VyaWVyIEJvbGRDb3VyaWVyAACAOExB eW5jWE1Cb2RZTkNwZU9EZlBFcmdGc2hSR3RpU0h1VEl2a1VKbGFLeG1iVzIzWzYgLF0tIi4w AqAAAa0ADgAALQAiAFoATwBEADkALgAjAFAARQA6AC8AJABRAEYAMAAlAEcAMQAmAFMASAAn AFQASQAzACgAVQBKADQAKQBWADUAKgBXAEwANgArAE0AQgAsAFkATgBDADgAEwAUADwAFwAB AA0APgAOAAMADwARADkCAAEABAA1AHwAvQELAXQB2AI1Ap4C5QNKA5MD0wQ5BJ8E/AVJBZ8F 6wZKBqoG8QdfB6gITwiaCPsJcgnCCfcKmArVCygLawuPC8UMGwxnDLwM5g1ZDaUOAw50Ds0P Hg+AD+0QCxB/EIIQnhC8ENERGRFBEZD47A747Ivd+DfdAevi/wDygADgA7v42xU56/w3Kzn4 jAeY96wFNgZ++1oF+4D4N/cM3QYO+OyL3e3d94PdAYv3gfcS94ED7/jbFTn3FQf7P/w3BVE5 94HdMgay7QX3dQayKQUzOfeB3VMG+1/4iQWy+9UV+zMG2vdTBQ747Pso3fhJ3QGL92/3Kvdr A5n4WRU5zQf3PvvYSfsFBfsvOffe3UAG94/4SQXK3ftrOb8G+xr7fvsO934Fwd0GDvjsi933 td1D4RLe4vdy4hcT2KL4WRU53Pu1ODn3it0/BxO493sHtqq7sMOLCLylX1Uf+103OfeQ3Tr3 YQf0S9YnHkqLXGpqdAgT2LUHDvjsfeH3yeGDdxKL5/8BKoAA/wBMgAAXE9j4WvhnFYJUWLZi l1mLGfsyNfsQ+wn7G/Ei9yX3CuvUr7ofW89RYkFZPosZ+whg4s+2o/cD9yL3BpNQTZQf35YF E7iIooilshqLr46wjqYIDvjsi933RHb3nN0Si/eJ+3b3dtf3bPts938XE+y0+NsVOcgH9yf7 WAUT8vs8+3MFUDn3id05BvcI9y/3AvsvBUc593/dTwb7OvdzBRPs9yj3WAXG3ftsOcAGLPsW LvcWBcbdBg747Ivd0/cb92jdAcj/AFOAAPfG/wBTgAAD97r3tRUo97oF+1Q5ywaF/DcFUTn3 i90iBpD3+AWXBun7sAXjBur3sAWXBpD7+AUiOfeL3VEGhfg3Bcnd+1QGL/u6BQ747Ivd90jd 9zHdEtzi93rkVOUXE/St+NsVOdz8Nzo596cH1vdAi/c/50uscpgfE/jBtIvDnBqLvHaza6dt pWScOosIiTkVo+eLQjg6imMf+wH3MQbw+4MVE/S79weJLT5JhC4fIvdIBg747H3h99DhAYvn 9+LnA7T3ehX7EeX7C/c990Lg9xD3DPcSMPcK+zz7Nir7BPsYHucW3cTX9wL3BcE7PT1VO/sF +wJS2NweDvjsgeE/3fe14fc+d7R3Eovn97PiFxO+96P5BxWCNvc1lwX7KQdgrVOdWosI+wj7 By77IPsR8PsB9xinypC6wh8TbmH3PN06+MoHMvw9FROuNUdOQD5KyeLkzsTWHhNu67o4Sh8O +OyL3fg33RKL93mT4ZP3dxcT8KD42xU50QcT0Pc7+6kF+yL7CDn30N37BvciBxP49zn3qQXR 3ft3OccG+wH7TfsD900Fxd0GDvjsf/c2+yrd+DfdEtnb97DbFxN4kPjbFTnZ/Dc9OfeX3Sb3 7p0HE7j3g/xMBfb4lc7d+4s57/vzegb7fvhFBQ747Hvh+FDhhHcSi+f30twXE9j4vfdGFWFk P0Ykiwj7F1L3BvcH9yDj1uv3C5gySpUf3pYFE7iGrYatxBqLs46rjaQIOAYT2IVTaKplq0OL GfsM+yIg+1f7QfP7IfdF9yPv662uHw747Pss3crh97jdQ+ES2uL3t+cXE+yV+FkVOdr8TTw5 98rd+yT3CgfBXcyCqosI9wb3C+v3Ix8T3PcLL/cI+yIeeItGi05XCBPssQeH+28VE9zay8/k 7Lg8RTNJSj4eE+xJNcDxHw747H3h9w7d9OEBi+f3w+cD+Kz3JBVVazdjOIv7Fot04YKvCPgc BoyUjaiLogjtO/cG+zL7Liz7BvsV+xLj+wT3PB7Zi+ao5b8I/DX3ZRWVpqrZ9wOLp4vliaYk CA747Hvh+FDhAYvn9/TnA6v3txX7Pvb7Hfc19zb19x73Pvc9Ivcf+zf7NyL7IPs9HueMFfcI zPX3A/cGyfsC+wT7Ckoj+wP7Akn09wkeDvjsi934N90B2OL3rucDovjbFTnY/Dc+OfeWB7GL 6IrLybW0tteL9w+LsYjkT9ZQ1UWRNosIjDkV0ouyhq5YomqbXItKizdzT2pqYmJRi2uLCC34 NwYO+OyL3fer3fcG4Yt3EvDiFxPo3/hPFTnw+6smOfge3fti96v3Yt37Yq0HwImm1h6hi7uJ 0nwIE9iu4QUT6JBtRpdJG/s4hC5DH2gHDvjsi933F933Yt0B2OL3eecD3PjbFTnY/Dc+OffG 3fsi9xeuB/cJi6+Nwaq5pazKi8aLzWTLVKpkoWGRRIsIjDkVzYufhZ+Ao36iaotii2BybXyD c350gyGLCGf3YgYO+OyL3fcFobzdnsDc3RLe4vcK3v8ALIAA4D3/AFWAABcT7oC4+NsVOd78 Nzg5+JD3bTgHhvsbBfuO90z3CkTeBhP+gPd1OAcT7wBD+wr3LfeFBxP/AJT7GgXeBob3bAUO +OyL3fe13UPhEvcM4hcT0NL4WRU59wP7tfsMOfgc3ftN908HE7CTk+bzzButi55zlnjkzxh1 oWWyP4s1i1ZbYWMIE9DVBw747Pss3dnh96ndOeESi+f3ouIXE+z4IvhZFRPcYAdgrVSYZYsI +wr7ACz7FvsN7ST3E9i2rpmcH4tXi19Ud3WDc4j7G4sIOfMH9xPnr/c1HxPs99ra3Qf7Ovty FURUSTxATsnY3M7E0dHKUjgeDvjsi933TN2fv9zdEtfi9wreuN8XE97J+NsVOdf8Nz8597bd +xP3TPcKRN4HE/73dTgHE95D+wr3LfeEBxP+l/sZBdwGhfdrBQ747H3hTnb4G+GHd6x3Eovl 95DlFxOO+DT4cBUTpn5TdpthqkWLGUD7AWIpXadhsXUfrHisg+SF2Ya2iYtjCGFXc0IeK4tu uYDBPYIYE2aQdpB5ZBqLYYVuh3MIE6bZhpe/pnWtbtqLGfcJ3c3fqH60aKUfZ6ZdjTORVI9G jou+CLvNk7IenIvii51Xk3QYjIeOhIyJ2ZYYE5aGn4afqxqLqpCqkKQIDvjsi933v+Hh6gHs 4vdy4gOX+Q4VkjflkQX8bjg594rdP/d7B9rGtJSmiwjAoVtaH/teNzn3kN0692IH9ErVKB5J i1tpbHUI94EHDvjsi933O933Pt0B2eL3b+cDrvjbFTnZ/Dc9OfeQ3TT3O74Hq4uXf7VMjYjD NbI2CPcu3S0GR/cHd6hzrPcUsYzxi5+LwHDBZKZjp2KNTYsIOQTTuH5JKvsDkWkfQfc+Bg74 7Hvh9xLd94DhhHcSi+f30tpD4hcT3PhW+OUVE+yFVFzAUJRrixn7JfsQ+xT7S/sr5Psu91kf E+roi9ytt54I9zO63fuqOfckKAdGcVmKgIsI+xhM6vcR9x7b4fL3DpgqUpIfE9zfloakhK6L yxmLtI2rjaQIDvjsfeH3td0593ISzeIXE7D3M/jbFRPQ+yBJOc37PAeLT4xQtGCpbMR9t4vc i+Ozv6Nq2hhrflFzXHdQixk8jL/QH/c893jd+3gHE7D3IAcO+OyL3fe13eL3GBL3K/U04hcT 6PcH+FkVOfcj+7X7Pjn4PN37O/gHBxMwIeIVEwD19xghBg747Hvh+FDhhHcSi+U63feT2z/l FxOy+Ef45RUT0oNTfJtiujuLGSggPSD7KPc2e9GEH8iFxH+LTQhGQXJQHhPKKotryoTWCDsG jmuQSItOi2qKfYl3CNwGk8ejcals3IsZ9wno2vLMaLVnoh9jpWOOSJMIE9RgkDKU0Rq1sMLn HvcJi5cnklXalhiLjoqdio4IE7SJo4e5tRqLro2ojaEIDvjsi933Rt33M90B1OL3dOIDp/jb FTnU/DdCOfd83UP3Rvd0+0ZDOfd83UL4N9Td+3w50/sz+3T3M9PdBw747H3hQ933td0S2eL3 auIXE3ih+FkVOdn7VAcTuItAm2qkbKZqv3a9i6mLvpS9rwgTeGz3Od09+Af7PTndBxO4+3UH ZmZpZk6LCEGD0LEf96YHDvjsi934N90B/wAJgADe/wCFgADi/wCFgADeA7342xV4+5zhf5j3 VgX3E/w3+wg599Xd+wr4N/cTBpj7VuGXePecBQ747Ivd+DfdAfc94gPj+NsVOfc9/Df7PTn4 Pd37Pfg39z3dBw747KB2+AfdAYv3ie33fwOW+FkVOdoH90P8BwXSBvdD+AcF2d37fznMBvsI +437BveNBc7dBg747Ivd97Xd7usS7eLc94v7X/eDFxP0o/kMFZM35ZMF/G47Ofc7908HrKSh d9dAqmgZZjn3g90wBjbuVMNspQgT+Pc09wAFzd37izm4iQb7Ej0F9/kHDvjse+H4Q90B0OL3 luIDmvjbFTnQ+5MHi2GLOK9Wt0raeMSL5ou3nbjNscKJ3Iu1CPeT0N37kjnt+5MHNogw+xL7 Eojm4B73k+3dBw747Hvh+EPdAZD/AFOAAP8A84AA4gP3UfjbFTn3UvuwBzmJSigebotlkW2c aZ6Eoom5hvcFGDUGlfuJ8FXTgL6LGZ+L44250Km4jMuLwAj3sPcQ3QcO+OyL3fhr6ot3Evc8 4hcTsOf5CxUT0JM49zCVBfxw+zw5+Dvd+zz4ygcO+Ox94UPd9yPd3OESi+X3juIXE3z4b/fH FfJTy/sUHjqLR3BOcq07GLCbz6nRiwjuilVoH2ePao9eiwj7RFkjTh8TvD3QPfUe24u/sayj CBN8W/dB3TUHE7w02xU+NUaHd4sIYGKrsJeQ0/chsqmFhq4fDvjsi934N90B3eL3Efd4A7v4 2xU53fw3OTn3j9059xQHvrvTYL8zvPsTGfcx3SsGXulh4zbB9033SxjC3ft4OccG+037SAX3 SN3dBw747Ivd90R29xrdEov3e/ts93zW93P7Z/eAFxPsqfhZFTnPB/ch+xoFE/L7LPsvBUM5 93vdXQbt6+wrBV0594DdRwb7NPcvBRPs9x33GgXN3ftzObgGN0A91gW13QYO+OyL3fe13UPh EsTi9wri9wriFxPc+FkEOcT7tVI592ndRgcTvPeUB6KhoqCniwi3i1FmH/uy9ybdUPeLB56i oKitiwi3i2JRH/uu9xndXfdcB7+K9xn7Eh5Yi2tvdHiDlnSvWItci2trenwIE9ysBw747IHh P933teHt6BLe4ve45xcTfPkSBJE22I8F/G8+Ofc4BxO8twfKWcWHqYsI9x7q9wj3CfcVIPT7 FlNceGdfH/eKB/w8BNnN0N7cyUg6PFFHNzZK0NoeDvjsoHb4YHfI3QGL93r3Ivd4A/jbBDm7 B8f8iQXaBvcA98cFjQb3BPvHBdoGzPiJBbrd+3g57AZn+8UFiQYo95wFTwYl+5wFiQZp98UF 690GDvjsi934aeMSnuP3b+Y23xcT6Pgm90gVKftaB+zjBRPw9xz3EL2+6hr3AjHk+wQebIsz hj4tCDTlB4qQipWLkQjL1Ziq07VaUB6LZIFtYWE5Ofsh+xFYYAg5BxPo+DT3SAYO+Ox94Pdv 3PdJ4hL3vORQ5BcT6PWmFb52unfKiwj3CezY9w7KbMhTqx8T8KCgr67VGvMvyy8eQotUaExh t0MY1bmmm7iLCLXBdE0tLYpZih84B6mNnYuPiwgT6Na6ZEg9S2hRTUupoV8faTsFDvjsMOL4 3+QBi+ID97b5NBX9j/dk4vsN+N/3DeQHDvjsfOL3gOL3MeKIdxKL6Pdv5xcT3PiJ+RAVE+yM dm6NcRtmi/sKiz4+MTF9+x2LSQj7bvcTSeL3Adzo9wL3BDrq+wAef4tYi1dlqfdX9yOLyIuS i6eLtokI+9P73xWr28+UoosIxbFRTUNeX1VbSrP2hB8O+OwO+Owh96YBi/d7A/eF9zwVNPum BfcABvcP96YFDvjsMOL43+QB9w3iA/fKMBX5j/tkMvcN/N/7DTQHDvjs95HnAYv3cgP3Ufft FS/3cucHDvjs96T3y4t3Eov3GPsS/wB4gAD/ADmAAPcY+xL/AHiAABcToPci+NsVEwCX+8sF 9wEGlvfLBROIvxYTAJf7ywX3AQaW98sFDvjse/c++yl2Eov3UBcToPfA9y4VEwBeWmtWVbxs uLm7q8DBWKpgHw747H3e+HveAYvm93TmA/fA+RMV+0Zy+2D7DvsMo/tj90f3SKL3Y/cM9w1z 92H7Rx84BPGV+zU5QIP7PSMnf/cz4OGb36OtH6Wuq4+ZiwgOcqT426T7L6T3J6QG94KT34v7 Y6QH4QriC4wMDgAACmVuZHN0cmVhbQplbmRvYmoKNDggMCBvYmoKNTAxNQplbmRvYmoKMzUg MCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9JQlNYV0orQ291cmllci1C b2xkfjIzL0ZvbnRCQm94Wy00OCAtMjg4IDc0NiA4NDddL0ZsYWdzIDUKL0FzY2VudCA4MzkK L0NhcEhlaWdodCA4MzkKL0Rlc2NlbnQgLTI4OAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTEx Ci9BdmdXaWR0aCA2MDAKL01heFdpZHRoIDYwMAovTWlzc2luZ1dpZHRoIDYwMAovQ2hhclNl dCgvc3BhY2UvcXVvdGVkYmwvcGFyZW5sZWZ0L3BhcmVucmlnaHQvcGx1cy9jb21tYS9oeXBo ZW4vcGVyaW9kL3plcm8vb25lL3R3by90aHJlZS9mb3VyL2ZpdmUvc2l4L3NldmVuL2VpZ2h0 L25pbmUvY29sb24vZ3JlYXRlci9hdC9BL0IvQy9EL0UvRi9HL0gvSS9KL0svTC9NL04vTy9Q L1IvUy9UL1UvVi9XL2JyYWNrZXRsZWZ0L2JyYWNrZXRyaWdodC9hL2IvYy9kL2UvZi9nL2gv aS9qL2svbC9tL24vby9wL3Evci9zL3QvdS92L3cveC95L3opCi9Gb250RmlsZTMgMzQgMCBS Pj4KZW5kb2JqCjM0IDAgb2JqCjw8L0xlbmd0aCA0OSAwIFIvU3VidHlwZS9UeXBlMUMvTGVu Z3RoMSA2MTY1Pj5zdHJlYW0KAQAEAgABAQEXSUJTWFdKK0NvdXJpZXItQm9sZH4yMwABAQEm +BsB+BwC+B0DW/u0+X754wUdAAQGbA2nHBf3EvgzEfekD/dUEAADAQFcaG9Db3B5cmlnaHQg KGMpIElCTSBDb3Jwb3JhdGlvbiAxOTkwLDE5OTEuIElCTSBDb3VyaWVyIGlzIGEgVHJhZGVt YXJrIG9mIHRoZSBJQk0gQ29ycG9yYXRpb24uQ291cmllciBCb2xkQ291cmllcgAAgEdMQXlu Y01Cem9kTkNwZU9EcWZQRXJnRnNoUkd0aVNIdWpUSXZrVUp3bGFWS3htYlcxMj4zKDQpQDVb NisgNyxdOC0iOS46MAKgAAGtAA4AAC0AIgBaAE8ARAAuACMAWwBQAEUALwAkAFEARgAwACUA UgBHADEAJgBTAEgAJwBUAEkAMwAoAFUASgA0ACkAVgBLADUAKgBXAEwANgArAFgATQBCADcA LABZAE4AQwA4ABIAEwAfABQACQAVAAoAIQAWADwAFwAMAAEAGAANAD4AGQAOAAMAGgAPABsA EQBIAgABAAQANQB8AL0BCwF0AdECOgJqArEDFgNWA7wEIgR/BMwFIgWHBdMGMgaSBtkHRweQ CDcIggjjCVoJqgnfCoAKvQsQC1wLnwvDC/kMTwybDPANRQ1vDeIOHQ5pDscPOA+RD+IQBxBp EIkQ9hE6EXIRtRJQEqoSyBM8E2ATYxOIE6QTwhRAFFUUnRUJFTEVdRXE+OwO+OyL3fg33QHr 4v8A8oAA4AO7+NsVOev8Nys5+IwHmPesBTYGfvtaBfuA+Df3DN0GDvjsi93t3feD3QGL94H3 EveBA+/42xU59xUH+z/8NwVROfeB3TIGsu0F93UGsikFMzn3gd1TBvtf+IkFsvvVFfszBtr3 UwUO+Oz7KN34Sd0Bi/dv9yr3awOZ+FkVOc0H9z772En7BQX7Lzn33t1ABveP+EkFyt37azm/ Bvsa+377Dvd+BcHdBg747Ivd97XdQ+ES3uL3cuIXE9ii+FkVOdz7tTg594rdPwcTuPd7B7aq u7DDiwi8pV9VH/tdNzn3kN0692EH9EvWJx5Ki1xqanQIE9i1Bw747H3h98nhg3cSi+f/ASqA AP8ATIAAFxPY+Fr4ZxWCVFi2YpdZixn7MjX7EPsJ+xvxIvcl9wrr1K+6H1vPUWJBWT6LGfsI YOLPtqP3A/ci9waTUE2UH9+WBRO4iKKIpbIai6+OsI6mCA747Ivd0/cb92jdAcj/AFOAAPfG /wBTgAAD97r3tRUo97oF+1Q5ywaF/DcFUTn3i90iBpD3+AWXBun7sAXjBur3sAWXBpD7+AUi OfeL3VEGhfg3Bcnd+1QGL/u6BQ747Ivd90jd9zHdEtzi93rkVOUXE/St+NsVOdz8Nzo596cH 1vdAi/c/50uscpgfE/jBtIvDnBqLvHaza6dtpWScOosIiTkVo+eLQjg6imMf+wH3MQbw+4MV E/S79weJLT5JhC4fIvdIBg747Ivd97XdAZXi937iA/D4WRX7PeLi908H+7D7vwVD+Db3QjQv +1wH97P3xAXOBw747H3h99DhAYvn9+LnA7T3ehX7EeX7C/c990Lg9xD3DPcSMPcK+zz7Nir7 BPsYHucW3cTX9wL3BcE7PT1VO/sF+wJS2NweDvjsgeE/3fe14fc+d7R3Eovn97PiFxO+96P5 BxWCNvc1lwX7KQdgrVOdWosI+wj7By77IPsR8PsB9xinypC6wh8TbmH3PN06+MoHMvw9FROu NUdOQD5KyeLkzsTWHhNu67o4Sh8O+Ox/9zb7Kt34N90S2dv3sNsXE3iQ+NsVOdn8Nz0595fd JvfunQcTuPeD/EwF9viVzt37iznv+/N6Bvt++EUFDvjse+H4UOGEdxKL5/fS3BcT2Pi990YV YWQ/RiSLCPsXUvcG9wf3IOPW6/cLmDJKlR/elgUTuIathq3EGouzjquNpAg4BhPYhVNoqmWr Q4sZ+wz7IiD7V/tB8/sh90X3I+/rra4fDvjs+yzdyuH3uN1D4RLa4ve35xcT7JX4WRU52vxN PDn3yt37JPcKB8FdzIKqiwj3BvcL6/cjHxPc9wsv9wj7Ih54i0aLTlcIE+yxB4f7bxUT3NrL z+TsuDxFM0lKPh4T7Ek1wPEfDvjsfeH3Dt304QGL5/fD5wP4rPckFVVrN2M4i/sWi3Thgq8I +BwGjJSNqIuiCO079wb7MvsuLPsG+xX7EuP7BPc8HtmL5qjlvwj8NfdlFZWmqtn3A4uni+WJ piQIDvjse+H4UOEBi+f39OcDq/e3Ffs+9vsd9zX3NvX3Hvc+9z0i9x/7N/s3Ivsg+z0e54wV 9wjM9fcD9wbJ+wL7BPsKSiP7A/sCSfT3CR4O+OyL3fg33QHY4veu5wOi+NsVOdj8Nz4595YH sYvoisvJtbS214v3D4uxiORP1lDVRZE2iwiMORXSi7KGrliiaptci0qLN3NPampiYlGLa4sI Lfg3Bg747Pss3crh97jdQ+ESi+f3t+IXE+z44/hZFfs6BhPcZQdOv0aLeIsI+yIv+wj7C/sj 9wsr9waqzJS5wR/7CvskOffK3TwHE+z4TdoHE9z7NvsdFSU1Vkk+Sczj0bja7OTLRzweDvjs i933q933BuGLdxLw4hcT6N/4TxU58PurJjn4Ht37Yver92Ld+2KtB8CJptYeoYu7idJ8CBPY ruEFE+iQbUaXSRv7OIQuQx9oBw747Ivd9xfd92LdAdji93nnA9z42xU52Pw3Pjn3xt37IvcX rgf3CYuvjcGquaWsyovGi81ky1SqZKFhkUSLCIw5Fc2Ln4WfgKN+omqLYotgcm18g3N+dIMh iwhn92IGDvjsi933BaG83Z7A3N0S3uL3Ct7/ACyAAOA9/wBVgAAXE+6AuPjbFTne/Dc4OfiQ 9204B4b7GwX7jvdM9wpE3gYT/oD3dTgHE+8AQ/sK9y33hQcT/wCU+xoF3gaG92wFDvjsi933 td1D4RL3DOIXE9DS+FkVOfcD+7X7DDn4HN37TfdPBxOwk5Pm88wbrYuec5Z45M8YdaFlsj+L NYtWW2FjCBPQ1QcO+Oz7LN3Z4fep3TnhEovn96LiFxPs+CL4WRUT3GAHYK1UmGWLCPsK+wAs +xb7De0k9xPYtq6ZnB+LV4tfVHd1g3OI+xuLCDnzB/cT56/3NR8T7Pfa2t0H+zr7chVEVEk8 QE7J2NzOxNHRylI4Hg747Ivd90zdn7/c3RLX4vcK3rjfFxPeyfjbFTnX/Dc/Ofe23fsT90z3 CkTeBxP+93U4BxPeQ/sK9y33hAcT/pf7GQXcBoX3awUO+Ox94U52+Bvhh3esdxKL5feQ5RcT jvg0+HAVE6Z+U3abYapFixlA+wFiKV2nYbF1H6x4rIPkhdmGtomLYwhhV3NCHiuLbrmAwT2C GBNmkHaQeWQai2GFbodzCBOm2YaXv6Z1rW7aixn3Cd3N36h+tGilH2emXY0zkVSPRo6Lvgi7 zZOyHpyL4oudV5N0GIyHjoSMidmWGBOWhp+Gn6sai6qQqpCkCA747Ivd97/h4eoB7OL3cuID l/kOFZI35ZEF/G44OfeK3T/3ewfaxrSUposIwKFbWh/7Xjc595DdOvdiB/RK1SgeSYtbaWx1 CPeBBw747Ivd9zvd9z7dAdni92/nA6742xU52fw3PTn3kN009zu+B6uLl3+1TI2IwzWyNgj3 Lt0tBkf3B3eoc6z3FLGM8Yufi8BwwWSmY6dijU2LCDkE07h+SSr7A5FpH0H3PgYO+Ox74fcS 3feA4YR3Eovn99LaQ+IXE9z4VvjlFRPshVRcwFCUa4sZ+yX7EPsU+0v7K+T7LvdZHxPq6Ivc rbeeCPczut37qjn3JCgHRnFZioCLCPsYTOr3Efce2+Hy9w6YKlKSHxPc35aGpISui8sZi7SN q42kCA747H3h97XdOfdyEs3iFxOw9zP42xUT0PsgSTnN+zwHi0+MULRgqWzEfbeL3Ivjs7+j atoYa35Rc1x3UIsZPIy/0B/3PPd43ft4BxOw9yAHDvjsi933td3i9xgS9yv1NOIXE+j3B/hZ FTn3I/u1+z45+Dzd+zv4BwcTMCHiFRMA9fcYIQYO+Ox74fhQ4YR3EovlOt33k9s/5RcTsvhH +OUVE9KDU3ybYro7ixkoID0g+yj3NnvRhB/IhcR/i00IRkFyUB4TyiqLa8qE1gg7Bo5rkEiL Totqin2JdwjcBpPHo3GpbNyLGfcJ6NryzGi1Z6IfY6VjjkiTCBPUYJAylNEatbDC5x73CYuX J5JV2pYYi46KnYqOCBO0iaOHubUai66NqI2hCA747Ivd90bd9zPdAdTi93TiA6f42xU51Pw3 Qjn3fN1D90b3dPtGQzn3fN1C+DfU3ft8OdP7M/t09zPT3QcO+Ox94UPd97XdEtni92riFxN4 ofhZFTnZ+1QHE7iLQJtqpGymar92vYupi76Uva8IE3hs9zndPfgH+z053QcTuPt1B2ZmaWZO iwhBg9CxH/emBw747Psm4fhD3eL3GBL3evVH4hcT6NP4WRU594z7yAdTiUj7Ah5ai12WYpN3 Nxi1gsB/x4sI91yL9y+9H/geBxMw+xHiFRMA9fcYIQYO+OyL3fg33QH/AAmAAN7/AIWAAOL/ AIWAAN4DvfjbFXj7nOF/mPdWBfcT/Df7CDn31d37Cvg39xMGmPtW4Zd495wFDvjsi934N90B 9z3iA+P42xU59z38N/s9Ofg93fs9+Df3Pd0HDvjsoHb4B90Bi/eJ7fd/A5b4WRU52gf3Q/wH BdIG90P4BwXZ3ft/OcwG+wj7jfsG940Fzt0GDvjsi933td3u6xLt4tz3i/tf94MXE/Sj+QwV kzflkwX8bjs59zv3TwespKF310CqaBlmOfeD3TAGNu5Uw2ylCBP49zT3AAXN3fuLObiJBvsS PQX3+QcO+Ox74fhD3QHQ4veW4gOa+NsVOdD7kweLYYs4r1a3Stp4xIvmi7eduM2xwonci7UI 95PQ3fuSOe37kwc2iDD7EvsSiObgHveT7d0HDvjse+H4Q90BkP8AU4AA/wDzgADiA/dR+NsV OfdS+7AHOYlKKB5ui2WRbZxpnoSiibmG9wUYNQaV+4nwVdOAvosZn4vjjbnQqbiMy4vACPew 9xDdBw747Iv3M/sedvgH3RKL92j3TfdfFxN4+FkEObkH8fwHBdcG1vduBY0G2PtuBdoG8PgH BbXd+1851gYTuFP7aAWJBjv3aAVOBj37aAWJBlT3aAXV3QYO+OyL3fhr6ot3Evc84hcTsOf5 CxUT0JM49zCVBfxw+zw5+Dvd+zz4ygcO+Ox94UPd9yPd3OESi+X3juIXE3z4b/fHFfJTy/sU HjqLR3BOcq07GLCbz6nRiwjuilVoH2ePao9eiwj7RFkjTh8TvD3QPfUe24u/sayjCBN8W/dB 3TUHE7w02xU+NUaHd4sIYGKrsJeQ0/chsqmFhq4fDvjsoHb4id0Si/eK+4r47PuJ94kXE+j3 w/cQFfsf+A0F3d37ijnTBvdP/IkF4Qb3UfiJBc3d+4k55QYO+OyL3fg33QHd4vcR93gDu/jb FTnd/Dc5OfeP3Tn3FAe+u9NgvzO8+xMZ9zHdKwZe6WHjNsH3TfdLGMLd+3g5xwb7TftIBfdI 3d0HDvjsi933RHb3Gt0Si/d7+2z3fNb3c/tn94AXE+yp+FkVOc8H9yH7GgUT8vss+y8FQzn3 e91dBu3r7CsFXTn3gN1HBvs09y8FE+z3HfcaBc3d+3M5uAY3QD3WBbXdBg747Ivd97XdQ+ES xOL3CuL3CuIXE9z4WQQ5xPu1Ujn3ad1GBxO895QHoqGioKeLCLeLUWYf+7L3Jt1Q94sHnqKg qK2LCLeLYlEf+673Gd1d91wHv4r3GfsSHliLa290eIOWdK9Yi1yLa2t6fAgT3KwHDvjsgeE/ 3fe14e3oEt7i97jnFxN8+RIEkTbYjwX8bz459zgHE7y3B8pZxYepiwj3Hur3CPcJ9xUg9PsW U1x4Z18f94oH/DwE2c3Q3tzJSDo8UUc3NkrQ2h4O+Oygdvhgd8jdAYv3evci93gD+NsEObsH x/yJBdoG9wD3xwWNBvcE+8cF2gbM+IkFut37eDnsBmf7xQWJBij3nAVPBiX7nAWJBmn3xQXr 3QYO+OyL3fjBdwH3SOID4Pi0Fa499yXMBfxV+zw5+Dnd+zr4wVUHDvjsi934aeMSnuP3b+Y2 3xcT6Pgm90gVKftaB+zjBRPw9xz3EL2+6hr3AjHk+wQebIszhj4tCDTlB4qQipWLkQjL1Ziq 07VaUB6LZIFtYWE5Ofsh+xFYYAg5BxPo+DT3SAYO+Oz4cXcBi/i4A9D4wBVmPPfw+zP77/s3 rjv4lPeIBQ747H3g92/c90niEve85FDkFxPo9aYVvna6d8qLCPcJ7Nj3DspsyFOrHxPwoKCv rtUa8y/LLx5Ci1RoTGG3QxjVuaabuIsItcF0TS0tilmKHzgHqY2di4+LCBPo1rpkSD1LaFFN S6mhXx9pOwUO+Owu+YsBi+wD+CL5LhWIh4mIg3+JiRldRUb7Lov7Gov7Br77KdMgj4aLio6H COcGTfcKTPcLi/cji/cjzvcSxfcCCA747Ivd3uD3ytoB96jiA/gr+RMV+w0G+4b8HgU796g4 +xY5983dK97r4CsH+6cW9073ygWN+8oGDvjsLvmLAfcR7AP3Xy4VpLOep6bJrNik5ovdi8x4 9yUg9zkIiomOjB8uBsz7EMf7Bov7IYv7JEf7FFktiomGgoqICA747H/P18/3SNHXzQGL0c/S 96nQA/iY9xIVSGhJaDCLCPtEc/cz0eSy9yz3RPTrUvsXP2ZNX3V+nZeXk6iNkB+59z0FQgaG dn6YfphvixkzR/sHLTXEcaqVs4y4th+qYLeLlIsI19fQ9xj3NfsG7fsu+xf7MEH7gftP9wMh 9y/n46q62h/7uvcZFXmHqZTGuN6ul5h8clNhNmIfDvjsfeL3kt73FeEBst73bOcD9wT5BRX7 2Ae5caahsqnIixnYvFNDV3FB+wJIT6aaaB+KjIWNiYxsOhjea7131YsI9zrE9xPk9wg25/sS W2d+hn4f9yf3q+EHDvjsMOL43+QBi+ID97b5NBX9j/dk4vsN+N/3DeQHDvjsfOL3gOL3MeKI dxKL6Pdv5xcT3PiJ+RAVE+yMdm6NcRtmi/sKiz4+MTF9+x2LSQj7bvcTSeL3Adzo9wL3BDrq +wAef4tYi1dlqfdX9yOLyIuSi6eLtokI+9P73xWr28+UoosIxbFRTUNeX1VbSrP2hB8O+Oz3 oOMB917jA/eU+L0V+1n7XjP3XvtZ4/dZ917j+173WQcO+OwO+Oygdviw4AGL4QPl+QUV+0Dh 4veAB/tW/LAF7Ab3VfjBBc8HDvjsIfemAYv3ewP3hfc8FTT7pgX3AAb3D/emBQ747DDi+N/k AfcN4gP3yjAV+Y/7ZDL3Dfzf+w00Bw747H3e91/i91fgEovlPOX3ZuU85RcT7PdC99QVE/JZ aW1QVBo30SX3HPcd0PHgHou5dchRswgT7MG2msO1GvAz2CD7ADQ9Jx4T7ItukU7KWAj3Evd+ FcO8aFBRWGBVVFm4w8S7sMQfE/L7rgTVtVdZVVlcSUlZu8C7ssHYHw747PeR5wGL93ID91H3 7RUv93LnBw747Pek98uLdxKL9xj7Ev8AeIAA/wA5gAD3GPsS/wB4gAAXE6D3IvjbFRMAl/vL BfcBBpb3ywUTiL8WEwCX+8sF9wEGlvfLBQ747Hzi9zHi94DiAZPn92/oA85/FaCKqImli7CL 9wqL2Njl5Zn3HYvNCPdu+xPNNPsBOi77AvsE3Cz3AB6Xi76Lv7Ft+1f7I4tOi4SLdYtgjQj3 zfffFWs7R4J0iwhRZcXJ07i3wbvMYyCSHw747Hv3PvspdhKL91AXE6D3wPcuFRMAXlprVlW8 bLi5u6vAwViqYB8O+Ox79z77KXb3mvc+Eov3UBcTMPfA+DQVEwBaXmhZVrxruLe9q8C+Xa1b HxOQ+5oEEwBhV21UVb1st7i8qsHCWKlgHw747H3e+HveAYvm93TmA/fA+RMV+0Zy+2D7DvsM o/tj90f3SKL3Y/cM9w1z92H7Rx84BPGV+zU5QIP7PSMnf/cz4OGb36OtH6Wuq4+ZiwgOcqT4 26T7L6T3J6QG94KT34v7Y6QH4QriC4wMDgAACmVuZHN0cmVhbQplbmRvYmoKNDkgMCBvYmoK NjE2NgplbmRvYmoKMjggMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9Q R1NQTVgrQ291cmllci1Cb2xkfjFjL0ZvbnRCQm94Wy00OCAtMjg4IDc0NiA4NDddL0ZsYWdz IDUKL0FzY2VudCA4MzkKL0NhcEhlaWdodCA4MzkKL0Rlc2NlbnQgLTI4OAovSXRhbGljQW5n bGUgMAovU3RlbVYgMTExCi9BdmdXaWR0aCA2MDAKL01heFdpZHRoIDYwMAovTWlzc2luZ1dp ZHRoIDYwMAovQ2hhclNldCgvc3BhY2UvcXVvdGVkYmwvcXVvdGVzaW5nbGUvcGFyZW5sZWZ0 L3BhcmVucmlnaHQvcGx1cy9jb21tYS9oeXBoZW4vcGVyaW9kL3plcm8vb25lL3R3by90aHJl ZS9mb3VyL2ZpdmUvc2l4L3NldmVuL2VpZ2h0L25pbmUvbGVzcy9ncmVhdGVyL0EvQi9DL0Qv RS9GL0cvSC9JL0ovSy9ML00vTi9PL1AvUi9TL1QvVS9WL1cvWC9ZL2JyYWNrZXRsZWZ0L2Jy YWNrZXRyaWdodC91bmRlcnNjb3JlL2EvYi9jL2QvZS9mL2cvaC9pL2svbC9tL24vby9wL3Iv cy90L3Uvdi93L3gveSkKL0ZvbnRGaWxlMyAyNyAwIFI+PgplbmRvYmoKMjcgMCBvYmoKPDwv TGVuZ3RoIDUwIDAgUi9TdWJ0eXBlL1R5cGUxQy9MZW5ndGgxIDU5Nzg+PnN0cmVhbQoBAAQC AAEBARdQR1NQTVgrQ291cmllci1Cb2xkfjFjAAEBASb4GwH4HAL4HQNb+7T5fvnjBR0ABAZs DaccFzwS+DMR96QP91QQAAMBAVxob0NvcHlyaWdodCAoYykgSUJNIENvcnBvcmF0aW9uIDE5 OTAsMTk5MS4gSUJNIENvdXJpZXIgaXMgYSBUcmFkZW1hcmsgb2YgdGhlIElCTSBDb3Jwb3Jh dGlvbi5Db3VyaWVyIEJvbGRDb3VyaWVyAACAR0xBeW5jWE1Cb2RZTkNwZU9EZlBFcmdGc2hS R3RpU0h1VEl2a1VKd2xhVkt4bWJXPDEnMj4zKDQpNVs2KyA3LF04LSI5Ll8wAqAAAa0ADgAA LQAiAFoATwBEADkALgAjAFAARQA6AC8AJABRAEYAMAAlAEcAMQAmAFMASAAnAFQASQAzACgA VQBKADQAKQBWADUAKgBXAEwANgArAFgATQBCADcALABZAE4AQwA4AB0AEgBoABMAHwAUAAkA FQAKABYAPAAXAAwAAQAYAA0APgAZAA4AAwAaAA8AQAARAEgCAAEABAA1AHwAvQELAXQB2AI1 Ap4C5QNKA5MD0wQ5BJ8E/AVJBZ8F6wZKBqoG8QdfB6gITwiaCPsJcgnCCfcKmArVCygLawuP C8UMGwxnDLwNEQ07Da4N6Q41DpMPBA9dD64P0Q/2EBgQehCaEQcRSxGDEcYSIBI+ErIS1hLZ Ev4TGhM4E7YTyxQTFH8UpxS6FQn47A747Ivd+DfdAevi/wDygADgA7v42xU56/w3Kzn4jAeY 96wFNgZ++1oF+4D4N/cM3QYO+OyL3e3d94PdAYv3gfcS94ED7/jbFTn3FQf7P/w3BVE594Hd Mgay7QX3dQayKQUzOfeB3VMG+1/4iQWy+9UV+zMG2vdTBQ747Pso3fhJ3QGL92/3KvdrA5n4 WRU5zQf3PvvYSfsFBfsvOffe3UAG94/4SQXK3ftrOb8G+xr7fvsO934Fwd0GDvjsi933td1D 4RLe4vdy4hcT2KL4WRU53Pu1ODn3it0/BxO493sHtqq7sMOLCLylX1Uf+103OfeQ3Tr3YQf0 S9YnHkqLXGpqdAgT2LUHDvjsfeH3yeGDdxKL5/8BKoAA/wBMgAAXE9j4WvhnFYJUWLZil1mL GfsyNfsQ+wn7G/Ei9yX3CuvUr7ofW89RYkFZPosZ+whg4s+2o/cD9yL3BpNQTZQf35YFE7iI ooilshqLr46wjqYIDvjsi933RHb3nN0Si/eJ+3b3dtf3bPts938XE+y0+NsVOcgH9yf7WAUT 8vs8+3MFUDn3id05BvcI9y/3AvsvBUc593/dTwb7OvdzBRPs9yj3WAXG3ftsOcAGLPsWLvcW BcbdBg747Ivd0/cb92jdAcj/AFOAAPfG/wBTgAAD97r3tRUo97oF+1Q5ywaF/DcFUTn3i90i BpD3+AWXBun7sAXjBur3sAWXBpD7+AUiOfeL3VEGhfg3Bcnd+1QGL/u6BQ747Ivd90jd9zHd Etzi93rkVOUXE/St+NsVOdz8Nzo596cH1vdAi/c/50uscpgfE/jBtIvDnBqLvHaza6dtpWSc OosIiTkVo+eLQjg6imMf+wH3MQbw+4MVE/S79weJLT5JhC4fIvdIBg747H3h99DhAYvn9+Ln A7T3ehX7EeX7C/c990Lg9xD3DPcSMPcK+zz7Nir7BPsYHucW3cTX9wL3BcE7PT1VO/sF+wJS 2NweDvjsgeE/3fe14fc+d7R3Eovn97PiFxO+96P5BxWCNvc1lwX7KQdgrVOdWosI+wj7By77 IPsR8PsB9xinypC6wh8TbmH3PN06+MoHMvw9FROuNUdOQD5KyeLkzsTWHhNu67o4Sh8O+OyL 3fg33RKL93mT4ZP3dxcT8KD42xU50QcT0Pc7+6kF+yL7CDn30N37BvciBxP49zn3qQXR3ft3 OccG+wH7TfsD900Fxd0GDvjsf/c2+yrd+DfdEtnb97DbFxN4kPjbFTnZ/Dc9OfeX3Sb37p0H E7j3g/xMBfb4lc7d+4s57/vzegb7fvhFBQ747Hvh+FDhhHcSi+f30twXE9j4vfdGFWFkP0Yk iwj7F1L3BvcH9yDj1uv3C5gySpUf3pYFE7iGrYatxBqLs46rjaQIOAYT2IVTaKplq0OLGfsM +yIg+1f7QfP7IfdF9yPv662uHw747Pss3crh97jdQ+ES2uL3t+cXE+yV+FkVOdr8TTw598rd +yT3CgfBXcyCqosI9wb3C+v3Ix8T3PcLL/cI+yIeeItGi05XCBPssQeH+28VE9zay8/k7Lg8 RTNJSj4eE+xJNcDxHw747H3h9w7d9OEBi+f3w+cD+Kz3JBVVazdjOIv7Fot04YKvCPgcBoyU jaiLogjtO/cG+zL7Liz7BvsV+xLj+wT3PB7Zi+ao5b8I/DX3ZRWVpqrZ9wOLp4vliaYkCA74 7Hvh+FDhAYvn9/TnA6v3txX7Pvb7Hfc19zb19x73Pvc9Ivcf+zf7NyL7IPs9HueMFfcIzPX3 A/cGyfsC+wT7Ckoj+wP7Akn09wkeDvjsi934N90B2OL3rucDovjbFTnY/Dc+OfeWB7GL6IrL ybW0tteL9w+LsYjkT9ZQ1UWRNosIjDkV0ouyhq5YomqbXItKizdzT2pqYmJRi2uLCC34NwYO +OyL3fer3fcG4Yt3EvDiFxPo3/hPFTnw+6smOfge3fti96v3Yt37Yq0HwImm1h6hi7uJ0nwI E9iu4QUT6JBtRpdJG/s4hC5DH2gHDvjsi933F933Yt0B2OL3eecD3PjbFTnY/Dc+OffG3fsi 9xeuB/cJi6+Nwaq5pazKi8aLzWTLVKpkoWGRRIsIjDkVzYufhZ+Ao36iaotii2BybXyDc350 gyGLCGf3YgYO+OyL3fcFobzdnsDc3RLe4vcK3v8ALIAA4D3/AFWAABcT7oC4+NsVOd78Nzg5 +JD3bTgHhvsbBfuO90z3CkTeBhP+gPd1OAcT7wBD+wr3LfeFBxP/AJT7GgXeBob3bAUO+OyL 3fe13UPhEvcM4hcT0NL4WRU59wP7tfsMOfgc3ftN908HE7CTk+bzzButi55zlnjkzxh1oWWy P4s1i1ZbYWMIE9DVBw747Pss3dnh96ndOeESi+f3ouIXE+z4IvhZFRPcYAdgrVSYZYsI+wr7 ACz7FvsN7ST3E9i2rpmcH4tXi19Ud3WDc4j7G4sIOfMH9xPnr/c1HxPs99ra3Qf7OvtyFURU STxATsnY3M7E0dHKUjgeDvjsi933TN2fv9zdEtfi9wreuN8XE97J+NsVOdf8Nz8597bd+xP3 TPcKRN4HE/73dTgHE95D+wr3LfeEBxP+l/sZBdwGhfdrBQ747H3hTnb4G+GHd6x3Eovl95Dl FxOO+DT4cBUTpn5TdpthqkWLGUD7AWIpXadhsXUfrHisg+SF2Ya2iYtjCGFXc0IeK4tuuYDB PYIYE2aQdpB5ZBqLYYVuh3MIE6bZhpe/pnWtbtqLGfcJ3c3fqH60aKUfZ6ZdjTORVI9Gjou+ CLvNk7IenIvii51Xk3QYjIeOhIyJ2ZYYE5aGn4afqxqLqpCqkKQIDvjsi933v+Hh6gHs4vdy 4gOX+Q4VkjflkQX8bjg594rdP/d7B9rGtJSmiwjAoVtaH/teNzn3kN0692IH9ErVKB5Ji1tp bHUI94EHDvjsi933O933Pt0B2eL3b+cDrvjbFTnZ/Dc9OfeQ3TT3O74Hq4uXf7VMjYjDNbI2 CPcu3S0GR/cHd6hzrPcUsYzxi5+LwHDBZKZjp2KNTYsIOQTTuH5JKvsDkWkfQfc+Bg747Hvh 9xLd94DhhHcSi+f30tpD4hcT3PhW+OUVE+yFVFzAUJRrixn7JfsQ+xT7S/sr5Psu91kfE+ro i9ytt54I9zO63fuqOfckKAdGcVmKgIsI+xhM6vcR9x7b4fL3DpgqUpIfE9zfloakhK6LyxmL tI2rjaQIDvjsfeH3td0593ISzeIXE7D3M/jbFRPQ+yBJOc37PAeLT4xQtGCpbMR9t4vci+Oz v6Nq2hhrflFzXHdQixk8jL/QH/c893jd+3gHE7D3IAcO+OyL3fe13eL3GBL3K/U04hcT6PcH +FkVOfcj+7X7Pjn4PN37O/gHBxMwIeIVEwD19xghBg747Hvh+FDhhHcSi+U63feT2z/lFxOy +Ef45RUT0oNTfJtiujuLGSggPSD7KPc2e9GEH8iFxH+LTQhGQXJQHhPKKotryoTWCDsGjmuQ SItOi2qKfYl3CNwGk8ejcals3IsZ9wno2vLMaLVnoh9jpWOOSJMIE9RgkDKU0Rq1sMLnHvcJ i5cnklXalhiLjoqdio4IE7SJo4e5tRqLro2ojaEIDvjsi933Rt33M90B1OL3dOIDp/jbFTnU /DdCOfd83UP3Rvd0+0ZDOfd83UL4N9Td+3w50/sz+3T3M9PdBw747H3hQ933td0S2eL3auIX E3ih+FkVOdn7VAcTuItAm2qkbKZqv3a9i6mLvpS9rwgTeGz3Od09+Af7PTndBxO4+3UHZmZp Zk6LCEGD0LEf96YHDvjsi934N90B/wAJgADe/wCFgADi/wCFgADeA7342xV4+5zhf5j3VgX3 E/w3+wg599Xd+wr4N/cTBpj7VuGXePecBQ747Ivd+DfdAfc94gPj+NsVOfc9/Df7PTn4Pd37 Pfg39z3dBw747KB2+AfdAYv3ie33fwOW+FkVOdoH90P8BwXSBvdD+AcF2d37fznMBvsI+437 BveNBc7dBg747Ivd97Xd7usS7eLc94v7X/eDFxP0o/kMFZM35ZMF/G47Ofc7908HrKShd9dA qmgZZjn3g90wBjbuVMNspQgT+Pc09wAFzd37izm4iQb7Ej0F9/kHDvjse+H4Q90B0OL3luID mvjbFTnQ+5MHi2GLOK9Wt0raeMSL5ou3nbjNscKJ3Iu1CPeT0N37kjnt+5MHNogw+xL7Eojm 4B73k+3dBw747Hvh+EPdAZD/AFOAAP8A84AA4gP3UfjbFTn3UvuwBzmJSigebotlkW2caZ6E oom5hvcFGDUGlfuJ8FXTgL6LGZ+L44250Km4jMuLwAj3sPcQ3QcO+OyL9zP7Hnb4B90Si/do 9033XxcTePhZBDm5B/H8BwXXBtb3bgWNBtj7bgXaBvD4BwW13ftfOdYGE7hT+2gFiQY792gF TgY9+2gFiQZU92gF1d0GDvjsi934a+qLdxL3POIXE7Dn+QsVE9CTOPcwlQX8cPs8Ofg73fs8 +MoHDvjsfeFD3fcj3dzhEovl947iFxN8+G/3xxXyU8v7FB46i0dwTnKtOxiwm8+p0YsI7opV aB9nj2qPXosI+0RZI04fE7w90D31HtuLv7GsowgTfFv3Qd01BxO8NNsVPjVGh3eLCGBiq7CX kNP3IbKphYauHw747KB2+IndEov3ivuK+Oz7ifeJFxPo98P3EBX7H/gNBd3d+4o50wb3T/yJ BeEG91H4iQXN3fuJOeUGDvjsi934N90B3eL3Efd4A7v42xU53fw3OTn3j9059xQHvrvTYL8z vPsTGfcx3SsGXulh4zbB9033SxjC3ft4OccG+037SAX3SN3dBw747Ivd90R29xrdEov3e/ts 93zW93P7Z/eAFxPsqfhZFTnPB/ch+xoFE/L7LPsvBUM593vdXQbt6+wrBV0594DdRwb7NPcv BRPs9x33GgXN3ftzObgGN0A91gW13QYO+OyL3fe13UPhEsTi9wri9wriFxPc+FkEOcT7tVI5 92ndRgcTvPeUB6KhoqCniwi3i1FmH/uy9ybdUPeLB56ioKitiwi3i2JRH/uu9xndXfdcB7+K 9xn7Eh5Yi2tvdHiDlnSvWItci2trenwIE9ysBw747IHhP933teHt6BLe4ve45xcTfPkSBJE2 2I8F/G8+Ofc4BxO8twfKWcWHqYsI9x7q9wj3CfcVIPT7FlNceGdfH/eKB/w8BNnN0N7cyUg6 PFFHNzZK0NoeDvjsoHb4YHfI3QGL93r3Ivd4A/jbBDm7B8f8iQXaBvcA98cFjQb3BPvHBdoG zPiJBbrd+3g57AZn+8UFiQYo95wFTwYl+5wFiQZp98UF690GDvjs1vh1AYv4uAP4mPjAFfyT +4H4k/uIr9v78Pc39/H3MwUO+OyL3fjBdwH3SOID4Pi0Fa499yXMBfxV+zw5+Dnd+zr4wVUH Dvjs96T3y4t3Eov3LBcToPd0+NsVEwCh+8sF9wAGoffLBQ747Ivd+GnjEp7j92/mNt8XE+j4 JvdIFSn7Wgfs4wUT8Pcc9xC9vuoa9wIx5PsEHmyLM4Y+LQg05QeKkIqVi5EIy9WYqtO1WlAe i2SBbWFhOTn7IfsRWGAIOQcT6Pg090gGDvjs+HF3AYv4uAPQ+MAVZjz38Psz++/7N647+JT3 iAUO+Ox94Pdv3PdJ4hL3vORQ5BcT6PWmFb52unfKiwj3CezY9w7KbMhTqx8T8KCgr67VGvMv yy8eQotUaExht0MY1bmmm7iLCLXBdE0tLYpZih84B6mNnYuPiwgT6Na6ZEg9S2hRTUupoV8f aTsFDvjsLvmLAYvsA/gi+S4ViIeJiIN/iYkZXUVG+y6L+xqL+wa++ynTII+Gi4qOhwjnBk33 Ckz3C4v3I4v3I873EsX3AggO+OyL3d7g98raAfeo4gP4K/kTFfsNBvuG/B4FO/eoOPsWOffN 3Sve6+ArB/unFvdO98oFjfvKBg747C75iwH3EewD918uFaSznqemyazYpOaL3YvMePclIPc5 CIqJjowfLgbM+xDH+waL+yGL+yRH+xRZLYqJhoKKiAgO+Ox94veS3vcV4QGy3vds5wP3BPkF FfvYB7lxpqGyqciLGdi8U0NXcUH7AkhPpppoH4qMhY2JjGw6GN5rvXfViwj3OsT3E+T3CDbn +xJbZ36Gfh/3J/er4QcO+Oww4vjf5AGL4gP3tvk0Ff2P92Ti+w343/cN5AcO+Ox84veA4vcx 4oh3Eovo92/nFxPc+In5EBUT7Ix2bo1xG2aL+wqLPj4xMX37HYtJCPtu9xNJ4vcB3Oj3AvcE Our7AB5/i1iLV2Wp91f3I4vIi5KLp4u2iQj70/vfFavbz5SiiwjFsVFNQ15fVVtKs/aEHw74 7Peg4wH3XuMD95T4vRX7WfteM/de+1nj91n3XuP7XvdZBw747A747KB2+LDgAYvhA+X5BRX7 QOHi94AH+1b8sAXsBvdV+MEFzwcO+Owh96YBi/d7A/eF9zwVNPumBfcABvcP96YFDvjsMOL4 3+QB9w3iA/fKMBX5j/tkMvcN/N/7DTQHDvjsfd73X+L3V+ASi+U85fdm5TzlFxPs90L31BUT 8llpbVBUGjfRJfcc9x3Q8eAei7l1yFGzCBPswbaaw7Ua8DPYIPsAND0nHhPsi26RTspYCPcS 934Vw7xoUFFYYFVUWbjDxLuwxB8T8vuuBNW1V1lVWVxJSVm7wLuywdgfDvjs95HnAYv3cgP3 UfftFS/3cucHDvjs96T3y4t3Eov3GPsS/wB4gAD/ADmAAPcY+xL/AHiAABcToPci+NsVEwCX +8sF9wEGlvfLBROIvxYTAJf7ywX3AQaW98sFDvjsfOL3MeL3gOIBk+f3b+gDzn8VoIqoiaWL sIv3CovY2OXlmfcdi80I9277E800+wE6LvsC+wTcLPcAHpeLvou/sW37V/sji06LhIt1i2CN CPfN998VaztHgnSLCFFlxcnTuLfBu8xjIJIfDvjse/c++yl2Eov3UBcToPfA9y4VEwBeWmtW VbxsuLm7q8DBWKpgHw747PsRvQGL+UwDW0AVWflMvQcO+Ox93vh73gGL5vd05gP3wPkTFftG cvtg+w77DKP7Y/dH90ii92P3DPcNc/dh+0cfOATxlfs1OUCD+z0jJ3/3M+Dhm9+jrR+lrquP mYsIDnKk+Nuk+y+k9yekBveCk9+L+2OkB+EK4guMDA4AAAplbmRzdHJlYW0KZW5kb2JqCjUw IDAgb2JqCjU5NzkKZW5kb2JqCjIxIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9u dE5hbWUvU0pFWk9JK0NvdXJpZXItQm9sZH4xNS9Gb250QkJveFstNDggLTI4OCA3NDYgODQ3 XS9GbGFncyA1Ci9Bc2NlbnQgODM5Ci9DYXBIZWlnaHQgODM5Ci9EZXNjZW50IC0yODgKL0l0 YWxpY0FuZ2xlIDAKL1N0ZW1WIDExMQovQXZnV2lkdGggNjAwCi9NYXhXaWR0aCA2MDAKL01p c3NpbmdXaWR0aCA2MDAKL0NoYXJTZXQoL3NwYWNlL3BhcmVubGVmdC9wYXJlbnJpZ2h0L3Bs dXMvaHlwaGVuL3BlcmlvZC96ZXJvL29uZS90d28vdGhyZWUvZm91ci9maXZlL3NpeC9zZXZl bi9laWdodC9uaW5lL0EvQi9DL0QvRS9GL0cvSC9JL0ovSy9ML00vTi9PL1AvUi9TL1QvVS9W L1cvWS9icmFja2V0bGVmdC9icmFja2V0cmlnaHQvdW5kZXJzY29yZS9hL2IvYy9kL2UvZi9n L2gvaS9rL2wvbS9uL28vcC9yL3MvdC91L3Yvdy94L3kpCi9Gb250RmlsZTMgMjAgMCBSPj4K ZW5kb2JqCjIwIDAgb2JqCjw8L0xlbmd0aCA1MSAwIFIvU3VidHlwZS9UeXBlMUMvTGVuZ3Ro MSA1NjQ3Pj5zdHJlYW0KAQAEAgABAQEXU0pFWk9JK0NvdXJpZXItQm9sZH4xNQABAQEm+BsB +BwC+B0DW/u0+X754wUdAAQGbA2nHBXxEvghEfeeD/dUEAADAQFcaG9Db3B5cmlnaHQgKGMp IElCTSBDb3Jwb3JhdGlvbiAxOTkwLDE5OTEuIElCTSBDb3VyaWVyIGlzIGEgVHJhZGVtYXJr IG9mIHRoZSBJQk0gQ29ycG9yYXRpb24uQ291cmllciBCb2xkQ291cmllcgAAgEFMQXluY01C b2RZTkNwZU9EZlBFcmdGc2hSR3RpU0h1VEl2a1VKd2xhVkt4bWJXMTIzKDQpNVs2KyA3XTgt OS5fMAKgAAGtAA4AAC0AIgBaAE8ARAAuACMAUABFADoALwAkAFEARgAwACUARwAxACYAUwBI ACcAVABJADMAKABVAEoANAApAFYANQAqAFcATAA2ACsAWABNAEIANwAsAFkATgBDADgAEgAT ABQACQAVAAoAFgA8ABcADAABABgAPgAZAA4AGgAPAEAAEQBCAgABAAQANQB8AL0BCwF0AdEC OgKBAuYDLwNvA9UEOwSYBOUFOwWHBeYGRgaNBvsHRAfrCDYIlwkOCV4Jkwo0CnEKxAsHCysL YQu3DAMMWAytDNcNSg2FDdEOLw6gDvkPSg9vD9EQPhCCELoQ/RFXEXUR6RINEhASNRJTEtES 5hNSE3oTjRPc+OwO+OyL3fg33QHr4v8A8oAA4AO7+NsVOev8Nys5+IwHmPesBTYGfvtaBfuA +Df3DN0GDvjsi93t3feD3QGL94H3EveBA+/42xU59xUH+z/8NwVROfeB3TIGsu0F93UGsikF Mzn3gd1TBvtf+IkFsvvVFfszBtr3UwUO+Oz7KN34Sd0Bi/dv9yr3awOZ+FkVOc0H9z772En7 BQX7Lzn33t1ABveP+EkFyt37azm/Bvsa+377Dvd+BcHdBg747Ivd97XdQ+ES3uL3cuIXE9ii +FkVOdz7tTg594rdPwcTuPd7B7aqu7DDiwi8pV9VH/tdNzn3kN0692EH9EvWJx5Ki1xqanQI E9i1Bw747H3h98nhg3cSi+f/ASqAAP8ATIAAFxPY+Fr4ZxWCVFi2YpdZixn7MjX7EPsJ+xvx Ivcl9wrr1K+6H1vPUWJBWT6LGfsIYOLPtqP3A/ci9waTUE2UH9+WBRO4iKKIpbIai6+OsI6m CA747Ivd0/cb92jdAcj/AFOAAPfG/wBTgAAD97r3tRUo97oF+1Q5ywaF/DcFUTn3i90iBpD3 +AWXBun7sAXjBur3sAWXBpD7+AUiOfeL3VEGhfg3Bcnd+1QGL/u6BQ747Ivd90jd9zHdEtzi 93rkVOUXE/St+NsVOdz8Nzo596cH1vdAi/c/50uscpgfE/jBtIvDnBqLvHaza6dtpWScOosI iTkVo+eLQjg6imMf+wH3MQbw+4MVE/S79weJLT5JhC4fIvdIBg747H3h99DhAYvn9+LnA7T3 ehX7EeX7C/c990Lg9xD3DPcSMPcK+zz7Nir7BPsYHucW3cTX9wL3BcE7PT1VO/sF+wJS2Nwe DvjsgeE/3fe14fc+d7R3Eovn97PiFxO+96P5BxWCNvc1lwX7KQdgrVOdWosI+wj7By77IPsR 8PsB9xinypC6wh8TbmH3PN06+MoHMvw9FROuNUdOQD5KyeLkzsTWHhNu67o4Sh8O+OyL3fg3 3RKL93mT4ZP3dxcT8KD42xU50QcT0Pc7+6kF+yL7CDn30N37BvciBxP49zn3qQXR3ft3OccG +wH7TfsD900Fxd0GDvjsf/c2+yrd+DfdEtnb97DbFxN4kPjbFTnZ/Dc9OfeX3Sb37p0HE7j3 g/xMBfb4lc7d+4s57/vzegb7fvhFBQ747Hvh+FDhhHcSi+f30twXE9j4vfdGFWFkP0Ykiwj7 F1L3BvcH9yDj1uv3C5gySpUf3pYFE7iGrYatxBqLs46rjaQIOAYT2IVTaKplq0OLGfsM+yIg +1f7QfP7IfdF9yPv662uHw747Pss3crh97jdQ+ES2uL3t+cXE+yV+FkVOdr8TTw598rd+yT3 CgfBXcyCqosI9wb3C+v3Ix8T3PcLL/cI+yIeeItGi05XCBPssQeH+28VE9zay8/k7Lg8RTNJ Sj4eE+xJNcDxHw747H3h9w7d9OEBi+f3w+cD+Kz3JBVVazdjOIv7Fot04YKvCPgcBoyUjaiL ogjtO/cG+zL7Liz7BvsV+xLj+wT3PB7Zi+ao5b8I/DX3ZRWVpqrZ9wOLp4vliaYkCA747Hvh +FDhAYvn9/TnA6v3txX7Pvb7Hfc19zb19x73Pvc9Ivcf+zf7NyL7IPs9HueMFfcIzPX3A/cG yfsC+wT7Ckoj+wP7Akn09wkeDvjsi934N90B2OL3rucDovjbFTnY/Dc+OfeWB7GL6IrLybW0 tteL9w+LsYjkT9ZQ1UWRNosIjDkV0ouyhq5YomqbXItKizdzT2pqYmJRi2uLCC34NwYO+OyL 3fer3fcG4Yt3EvDiFxPo3/hPFTnw+6smOfge3fti96v3Yt37Yq0HwImm1h6hi7uJ0nwIE9iu 4QUT6JBtRpdJG/s4hC5DH2gHDvjsi933F933Yt0B2OL3eecD3PjbFTnY/Dc+OffG3fsi9xeu B/cJi6+Nwaq5pazKi8aLzWTLVKpkoWGRRIsIjDkVzYufhZ+Ao36iaotii2BybXyDc350gyGL CGf3YgYO+OyL3fcFobzdnsDc3RLe4vcK3v8ALIAA4D3/AFWAABcT7oC4+NsVOd78Nzg5+JD3 bTgHhvsbBfuO90z3CkTeBhP+gPd1OAcT7wBD+wr3LfeFBxP/AJT7GgXeBob3bAUO+OyL3fe1 3UPhEvcM4hcT0NL4WRU59wP7tfsMOfgc3ftN908HE7CTk+bzzButi55zlnjkzxh1oWWyP4s1 i1ZbYWMIE9DVBw747Pss3dnh96ndOeESi+f3ouIXE+z4IvhZFRPcYAdgrVSYZYsI+wr7ACz7 FvsN7ST3E9i2rpmcH4tXi19Ud3WDc4j7G4sIOfMH9xPnr/c1HxPs99ra3Qf7OvtyFURUSTxA TsnY3M7E0dHKUjgeDvjsi933TN2fv9zdEtfi9wreuN8XE97J+NsVOdf8Nz8597bd+xP3TPcK RN4HE/73dTgHE95D+wr3LfeEBxP+l/sZBdwGhfdrBQ747H3hTnb4G+GHd6x3Eovl95DlFxOO +DT4cBUTpn5TdpthqkWLGUD7AWIpXadhsXUfrHisg+SF2Ya2iYtjCGFXc0IeK4tuuYDBPYIY E2aQdpB5ZBqLYYVuh3MIE6bZhpe/pnWtbtqLGfcJ3c3fqH60aKUfZ6ZdjTORVI9Gjou+CLvN k7IenIvii51Xk3QYjIeOhIyJ2ZYYE5aGn4afqxqLqpCqkKQIDvjsi933v+Hh6gHs4vdy4gOX +Q4VkjflkQX8bjg594rdP/d7B9rGtJSmiwjAoVtaH/teNzn3kN0692IH9ErVKB5Ji1tpbHUI 94EHDvjsi933O933Pt0B2eL3b+cDrvjbFTnZ/Dc9OfeQ3TT3O74Hq4uXf7VMjYjDNbI2CPcu 3S0GR/cHd6hzrPcUsYzxi5+LwHDBZKZjp2KNTYsIOQTTuH5JKvsDkWkfQfc+Bg747Hvh9xLd 94DhhHcSi+f30tpD4hcT3PhW+OUVE+yFVFzAUJRrixn7JfsQ+xT7S/sr5Psu91kfE+roi9yt t54I9zO63fuqOfckKAdGcVmKgIsI+xhM6vcR9x7b4fL3DpgqUpIfE9zfloakhK6LyxmLtI2r jaQIDvjsfeH3td0593ISzeIXE7D3M/jbFRPQ+yBJOc37PAeLT4xQtGCpbMR9t4vci+Ozv6Nq 2hhrflFzXHdQixk8jL/QH/c893jd+3gHE7D3IAcO+OyL3fe13eL3GBL3K/U04hcT6PcH+FkV Ofcj+7X7Pjn4PN37O/gHBxMwIeIVEwD19xghBg747Hvh+FDhhHcSi+U63feT2z/lFxOy+Ef4 5RUT0oNTfJtiujuLGSggPSD7KPc2e9GEH8iFxH+LTQhGQXJQHhPKKotryoTWCDsGjmuQSItO i2qKfYl3CNwGk8ejcals3IsZ9wno2vLMaLVnoh9jpWOOSJMIE9RgkDKU0Rq1sMLnHvcJi5cn klXalhiLjoqdio4IE7SJo4e5tRqLro2ojaEIDvjsi933Rt33M90B1OL3dOIDp/jbFTnU/DdC Ofd83UP3Rvd0+0ZDOfd83UL4N9Td+3w50/sz+3T3M9PdBw747H3hQ933td0S2eL3auIXE3ih +FkVOdn7VAcTuItAm2qkbKZqv3a9i6mLvpS9rwgTeGz3Od09+Af7PTndBxO4+3UHZmZpZk6L CEGD0LEf96YHDvjsi934N90B/wAJgADe/wCFgADi/wCFgADeA7342xV4+5zhf5j3VgX3E/w3 +wg599Xd+wr4N/cTBpj7VuGXePecBQ747Ivd+DfdAfc94gPj+NsVOfc9/Df7PTn4Pd37Pfg3 9z3dBw747KB2+AfdAYv3ie33fwOW+FkVOdoH90P8BwXSBvdD+AcF2d37fznMBvsI+437BveN Bc7dBg747Ivd97Xd7usS7eLc94v7X/eDFxP0o/kMFZM35ZMF/G47Ofc7908HrKShd9dAqmgZ Zjn3g90wBjbuVMNspQgT+Pc09wAFzd37izm4iQb7Ej0F9/kHDvjse+H4Q90B0OL3luIDmvjb FTnQ+5MHi2GLOK9Wt0raeMSL5ou3nbjNscKJ3Iu1CPeT0N37kjnt+5MHNogw+xL7Eojm4B73 k+3dBw747Hvh+EPdAZD/AFOAAP8A84AA4gP3UfjbFTn3UvuwBzmJSigebotlkW2caZ6Eoom5 hvcFGDUGlfuJ8FXTgL6LGZ+L44250Km4jMuLwAj3sPcQ3QcO+OyL9zP7Hnb4B90Si/do9033 XxcTePhZBDm5B/H8BwXXBtb3bgWNBtj7bgXaBvD4BwW13ftfOdYGE7hT+2gFiQY792gFTgY9 +2gFiQZU92gF1d0GDvjsi934a+qLdxL3POIXE7Dn+QsVE9CTOPcwlQX8cPs8Ofg73fs8+MoH DvjsfeFD3fcj3dzhEovl947iFxN8+G/3xxXyU8v7FB46i0dwTnKtOxiwm8+p0YsI7opVaB9n j2qPXosI+0RZI04fE7w90D31HtuLv7GsowgTfFv3Qd01BxO8NNsVPjVGh3eLCGBiq7CXkNP3 IbKphYauHw747KB2+IndEov3ivuK+Oz7ifeJFxPo98P3EBX7H/gNBd3d+4o50wb3T/yJBeEG 91H4iQXN3fuJOeUGDvjsi934N90B3eL3Efd4A7v42xU53fw3OTn3j9059xQHvrvTYL8zvPsT Gfcx3SsGXulh4zbB9033SxjC3ft4OccG+037SAX3SN3dBw747Ivd90R29xrdEov3e/ts93zW 93P7Z/eAFxPsqfhZFTnPB/ch+xoFE/L7LPsvBUM593vdXQbt6+wrBV0594DdRwb7NPcvBRPs 9x33GgXN3ftzObgGN0A91gW13QYO+OyL3fe13UPhEsTi9wri9wriFxPc+FkEOcT7tVI592nd RgcTvPeUB6KhoqCniwi3i1FmH/uy9ybdUPeLB56ioKitiwi3i2JRH/uu9xndXfdcB7+K9xn7 Eh5Yi2tvdHiDlnSvWItci2trenwIE9ysBw747IHhP933teHt6BLe4ve45xcTfPkSBJE22I8F /G8+Ofc4BxO8twfKWcWHqYsI9x7q9wj3CfcVIPT7FlNceGdfH/eKB/w8BNnN0N7cyUg6PFFH NzZK0NoeDvjsoHb4YHfI3QGL93r3Ivd4A/jbBDm7B8f8iQXaBvcA98cFjQb3BPvHBdoGzPiJ Bbrd+3g57AZn+8UFiQYo95wFTwYl+5wFiQZp98UF690GDvjsi934wXcB90jiA+D4tBWuPfcl zAX8Vfs8Ofg53fs6+MFVBw747Ivd+GnjEp7j92/mNt8XE+j4JvdIFSn7Wgfs4wUT8Pcc9xC9 vuoa9wIx5PsEHmyLM4Y+LQg05QeKkIqVi5EIy9WYqtO1WlAei2SBbWFhOTn7IfsRWGAIOQcT 6Pg090gGDvjsfeD3b9z3SeIS97zkUOQXE+j1phW+drp3yosI9wns2PcOymzIU6sfE/CgoK+u 1RrzL8svHkKLVGhMYbdDGNW5ppu4iwi1wXRNLS2KWYofOAepjZ2Lj4sIE+jWumRIPUtoUU1L qaFfH2k7BQ747C75iwGL7AP4IvkuFYiHiYiDf4mJGV1FRvsui/sai/sGvvsp0yCPhouKjocI 5wZN9wpM9wuL9yOL9yPO9xLF9wIIDvjsi93e4PfK2gH3qOID+Cv5ExX7DQb7hvweBTv3qDj7 Fjn3zd0r3uvgKwf7pxb3TvfKBY37ygYO+Owu+YsB9xHsA/dfLhWks56npsms2KTmi92LzHj3 JSD3OQiKiY6MHy4GzPsQx/sGi/shi/skR/sUWS2KiYaCiogIDvjsfeL3kt73FeEBst73bOcD 9wT5BRX72Ae5caahsqnIixnYvFNDV3FB+wJIT6aaaB+KjIWNiYxsOhjea7131YsI9zrE9xPk 9wg25/sSW2d+hn4f9yf3q+EHDvjsMOL43+QBi+ID97b5NBX9j/dk4vsN+N/3DeQHDvjsfOL3 gOL3MeKIdxKL6Pdv5xcT3PiJ+RAVE+yMdm6NcRtmi/sKiz4+MTF9+x2LSQj7bvcTSeL3Adzo 9wL3BDrq+wAef4tYi1dlqfdX9yOLyIuSi6eLtokI+9P73xWr28+UoosIxbFRTUNeX1VbSrP2 hB8O+Oz3oOMB917jA/eU+L0V+1n7XjP3XvtZ4/dZ917j+173WQcO+OwO+Oygdviw4AGL4QPl +QUV+0Dh4veAB/tW/LAF7Ab3VfjBBc8HDvjsMOL43+QB9w3iA/fKMBX5j/tkMvcN/N/7DTQH Dvjsfd73X+L3V+ASi+U85fdm5TzlFxPs90L31BUT8llpbVBUGjfRJfcc9x3Q8eAei7l1yFGz CBPswbaaw7Ua8DPYIPsAND0nHhPsi26RTspYCPcS934Vw7xoUFFYYFVUWbjDxLuwxB8T8vuu BNW1V1lVWVxJSVm7wLuywdgfDvjs95HnAYv3cgP3UfftFS/3cucHDvjsfOL3MeL3gOIBk+f3 b+gDzn8VoIqoiaWLsIv3CovY2OXlmfcdi80I9277E800+wE6LvsC+wTcLPcAHpeLvou/sW37 V/sji06LhIt1i2CNCPfN998VaztHgnSLCFFlxcnTuLfBu8xjIJIfDvjse/c++yl2Eov3UBcT oPfA9y4VEwBeWmtWVbxsuLm7q8DBWKpgHw747PsRvQGL+UwDW0AVWflMvQcO+Ox93vh73gGL 5vd05gP3wPkTFftGcvtg+w77DKP7Y/dH90ii92P3DPcNc/dh+0cfOATxlfs1OUCD+z0jJ3/3 M+Dhm9+jrR+lrquPmYsIDnKk+Nuk+y+k9yekBveCk9+L+2OkB+EK4guMDA4AAAplbmRzdHJl YW0KZW5kb2JqCjUxIDAgb2JqCjU2NDgKZW5kb2JqCjE0IDAgb2JqCjw8L1R5cGUvRm9udERl c2NyaXB0b3IvRm9udE5hbWUvVk1RSVJUK0NvdXJpZXItQm9sZH5lL0ZvbnRCQm94Wy00OCAt Mjg4IDc0NiA4NDddL0ZsYWdzIDUKL0FzY2VudCA4MzkKL0NhcEhlaWdodCA4MzkKL0Rlc2Nl bnQgLTI4OAovSXRhbGljQW5nbGUgMAovU3RlbVYgMTExCi9BdmdXaWR0aCA2MDAKL01heFdp ZHRoIDYwMAovTWlzc2luZ1dpZHRoIDYwMAovQ2hhclNldCgvc3BhY2UvcXVvdGVkYmwvcGFy ZW5sZWZ0L3BhcmVucmlnaHQvcGx1cy9jb21tYS9oeXBoZW4vcGVyaW9kL3plcm8vb25lL3R3 by90aHJlZS9mb3VyL2VpZ2h0L25pbmUvY29sb24vQS9CL0MvRC9FL0YvSC9JL0ovSy9ML00v Ti9PL1AvUS9SL1MvVC9VL1kvYnJhY2tldGxlZnQvYnJhY2tldHJpZ2h0L2EvYi9jL2QvZS9m L2cvaC9pL2ovay9sL20vbi9vL3AvcS9yL3MvdC91L3Yvdy94L3kveikKL0ZvbnRGaWxlMyAx MyAwIFI+PgplbmRvYmoKMTMgMCBvYmoKPDwvTGVuZ3RoIDUyIDAgUi9TdWJ0eXBlL1R5cGUx Qy9MZW5ndGgxIDU2ODM+PnN0cmVhbQoBAAQCAAEBARZWTVFJUlQrQ291cmllci1Cb2xkfmUA AQEBJvgbAfgcAvgdA1v7tPl++eMFHQAEBmwNpxwWFRL4IBH3nQ/3UxAAAwEBXGhvQ29weXJp Z2h0IChjKSBJQk0gQ29ycG9yYXRpb24gMTk5MCwxOTkxLiBJQk0gQ291cmllciBpcyBhIFRy YWRlbWFyayBvZiB0aGUgSUJNIENvcnBvcmF0aW9uLkNvdXJpZXIgQm9sZENvdXJpZXIAAIBB TEF5bmNNQnpvZFlOQ3BlT0RxZlBFcmdRRnNoUnRpU0h1alRJdmtVSndsYUt4bWIxMjMoNClb KyAsXTgtIjkuOjACoAABrQAOAAAtACIAWgBPAEQALgAjAFsAUABFADoALwAkAFEARgAwACUA UgBHADEAJgBTAEgAMgAnAFQASQAzAFUASgA0ACkAVgBLADUAKgBXAEwANgArAFgATQBCACwA WQBOAEMAEgATABQACQAVAAoAPAAMAAEADQA+ABkADgADABoADwAbABEAQgIAAQAEADUAfAC9 AQsBdAHRAjoCagKxAxYDXwOfBAUEawTIBRUFawXQBhwGewbbByIHkAg1CH4JJQlwCdEKIQpW CvcLNAuHC9MMFgw6DHAMxg0SDWcNvA3mDlkOpQ8DD3QPzQ/yEFQQwREFET0RgBGeEcIRxRHh Ef8SfRKSEtoTRhNuE7IUAfjsDvjsi934N90B6+L/APKAAOADu/jbFTnr/DcrOfiMB5j3rAU2 Bn77WgX7gPg39wzdBg747Ivd7d33g90Bi/eB9xL3gQPv+NsVOfcVB/s//DcFUTn3gd0yBrLt Bfd1BrIpBTM594HdUwb7X/iJBbL71RX7Mwba91MFDvjs+yjd+EndAYv3b/cq92sDmfhZFTnN B/c++9hJ+wUF+y85997dQAb3j/hJBcrd+2s5vwb7Gvt++w73fgXB3QYO+OyL3fe13UPhEt7i 93LiFxPYovhZFTnc+7U4OfeK3T8HE7j3ewe2qruww4sIvKVfVR/7XTc595DdOvdhB/RL1ice Sotcamp0CBPYtQcO+Ox94ffJ4YN3Eovn/wEqgAD/AEyAABcT2Pha+GcVglRYtmKXWYsZ+zI1 +xD7Cfsb8SL3JfcK69Svuh9bz1FiQVk+ixn7CGDiz7aj9wP3IvcGk1BNlB/flgUTuIiiiKWy GouvjrCOpggO+OyL3dP3G/do3QHI/wBTgAD3xv8AU4AAA/e697UVKPe6BftUOcsGhfw3BVE5 94vdIgaQ9/gFlwbp+7AF4wbq97AFlwaQ+/gFIjn3i91RBoX4NwXJ3ftUBi/7ugUO+OyL3fdI 3fcx3RLc4vd65FTlFxP0rfjbFTnc/Dc6OfenB9b3QIv3P+dLrHKYHxP4wbSLw5wai7x2s2un baVknDqLCIk5FaPni0I4OopjH/sB9zEG8PuDFRP0u/cHiS0+SYQuHyL3SAYO+OyL3fe13QGV 4vd+4gPw+FkV+z3i4vdPB/uw+78FQ/g290I0L/tcB/ez98QFzgcO+Ox94ffQ4QGL5/fi5wO0 93oV+xHl+wv3PfdC4PcQ9wz3EjD3Cvs8+zYq+wT7GB7nFt3E1/cC9wXBOz09VTv7BfsCUtjc Hg747IHhP933teH3Pne0dxKL5/ez4hcTvvej+QcVgjb3NZcF+ykHYK1TnVqLCPsI+wcu+yD7 EfD7AfcYp8qQusIfE25h9zzdOvjKBzL8PRUTrjVHTkA+Ssni5M7E1h4Tbuu6OEofDvjsi934 N90Si/d5k+GT93cXE/Cg+NsVOdEHE9D3O/upBfsi+wg599Dd+wb3IgcT+Pc596kF0d37dznH BvsB+037A/dNBcXdBg747H/3Nvsq3fg33RLZ2/ew2xcTeJD42xU52fw3PTn3l90m9+6dBxO4 94P8TAX2+JXO3fuLOe/783oG+374RQUO+Ox74fhQ4YR3Eovn99LcFxPY+L33RhVhZD9GJIsI +xdS9wb3B/cg49br9wuYMkqVH96WBRO4hq2GrcQai7OOq42kCDgGE9iFU2iqZatDixn7DPsi IPtX+0Hz+yH3Rfcj7+utrh8O+Oz7LN3K4fe43UPhEtri97fnFxPslfhZFTna/E08OffK3fsk 9woHwV3MgqqLCPcG9wvr9yMfE9z3Cy/3CPsiHniLRotOVwgT7LEHh/tvFRPc2svP5Oy4PEUz SUo+HhPsSTXA8R8O+Ox94fcO3fThAYvn98PnA/is9yQVVWs3YziL+xaLdOGCrwj4HAaMlI2o i6II7Tv3Bvsy+y4s+wb7FfsS4/sE9zwe2YvmqOW/CPw192UVlaaq2fcDi6eL5YmmJAgO+Ox7 4fhQ4QGL5/f05wOr97cV+z72+x33Nfc29fce9z73PSL3H/s3+zci+yD7PR7njBX3CMz19wP3 Bsn7AvsE+wpKI/sD+wJJ9PcJHg747Ivd+DfdAdji967nA6L42xU52Pw3Pjn3lgexi+iKy8m1 tLbXi/cPi7GI5E/WUNVFkTaLCIw5FdKLsoauWKJqm1yLSos3c09qamJiUYtriwgt+DcGDvjs +yzdyuH3uN1D4RKL5/e34hcT7Pjj+FkV+zoGE9xlB06/Rot4iwj7Ii/7CPsL+yP3Cyv3BqrM lLnBH/sK+yQ598rdPAcT7PhN2gcT3Ps2+x0VJTVWST5JzOPRuNrs5MtHPB4O+OyL3fer3fcG 4Yt3EvDiFxPo3/hPFTnw+6smOfge3fti96v3Yt37Yq0HwImm1h6hi7uJ0nwIE9iu4QUT6JBt RpdJG/s4hC5DH2gHDvjsi933F933Yt0B2OL3eecD3PjbFTnY/Dc+OffG3fsi9xeuB/cJi6+N waq5pazKi8aLzWTLVKpkoWGRRIsIjDkVzYufhZ+Ao36iaotii2BybXyDc350gyGLCGf3YgYO +OyL3fcFobzdnsDc3RLe4vcK3v8ALIAA4D3/AFWAABcT7oC4+NsVOd78Nzg5+JD3bTgHhvsb BfuO90z3CkTeBhP+gPd1OAcT7wBD+wr3LfeFBxP/AJT7GgXeBob3bAUO+OyL3fe13UPhEvcM 4hcT0NL4WRU59wP7tfsMOfgc3ftN908HE7CTk+bzzButi55zlnjkzxh1oWWyP4s1i1ZbYWMI E9DVBw747Pss3dnh96ndOeESi+f3ouIXE+z4IvhZFRPcYAdgrVSYZYsI+wr7ACz7FvsN7ST3 E9i2rpmcH4tXi19Ud3WDc4j7G4sIOfMH9xPnr/c1HxPs99ra3Qf7OvtyFURUSTxATsnY3M7E 0dHKUjgeDvjs+wvcY/crPthTdvia4RKL5/fy5xcTnviXiBVzeW96c4sIE050i2SYdJ4IE55+ jQa4jfdJt4v3jQj3VvsP9wf7Jfsg+xL7A/tWHotDmzzBSAgTTqxiqn2pfWlng4Zpd7VDGIyM kY6MjMGqn5ayi5+LmoirfQgTrnytooKtG72LrKOsoZSRGPuj9yAVMjnP9y73RfcHtca69xVu +1f7aPsrhm8fDvjsi933TN2fv9zdEtfi9wreuN8XE97J+NsVOdf8Nz8597bd+xP3TPcKRN4H E/73dTgHE95D+wr3LfeEBxP+l/sZBdwGhfdrBQ747H3hTnb4G+GHd6x3Eovl95DlFxOO+DT4 cBUTpn5TdpthqkWLGUD7AWIpXadhsXUfrHisg+SF2Ya2iYtjCGFXc0IeK4tuuYDBPYIYE2aQ dpB5ZBqLYYVuh3MIE6bZhpe/pnWtbtqLGfcJ3c3fqH60aKUfZ6ZdjTORVI9Gjou+CLvNk7Ie nIvii51Xk3QYjIeOhIyJ2ZYYE5aGn4afqxqLqpCqkKQIDvjsi933v+Hh6gHs4vdy4gOX+Q4V kjflkQX8bjg594rdP/d7B9rGtJSmiwjAoVtaH/teNzn3kN0692IH9ErVKB5Ji1tpbHUI94EH Dvjsi933O933Pt0B2eL3b+cDrvjbFTnZ/Dc9OfeQ3TT3O74Hq4uXf7VMjYjDNbI2CPcu3S0G R/cHd6hzrPcUsYzxi5+LwHDBZKZjp2KNTYsIOQTTuH5JKvsDkWkfQfc+Bg747H3h97XdOfdy Es3iFxOw9zP42xUT0PsgSTnN+zwHi0+MULRgqWzEfbeL3Ivjs7+jatoYa35Rc1x3UIsZPIy/ 0B/3PPd43ft4BxOw9yAHDvjsi933td3i9xgS9yv1NOIXE+j3B/hZFTn3I/u1+z45+Dzd+zv4 BwcTMCHiFRMA9fcYIQYO+Ox74fhQ4YR3EovlOt33k9s/5RcTsvhH+OUVE9KDU3ybYro7ixko ID0g+yj3NnvRhB/IhcR/i00IRkFyUB4TyiqLa8qE1gg7Bo5rkEiLTotqin2JdwjcBpPHo3Gp bNyLGfcJ6NryzGi1Z6IfY6VjjkiTCBPUYJAylNEatbDC5x73CYuXJ5JV2pYYi46KnYqOCBO0 iaOHubUai66NqI2hCA747Ivd90bd9zPdAdTi93TiA6f42xU51Pw3Qjn3fN1D90b3dPtGQzn3 fN1C+DfU3ft8OdP7M/t09zPT3QcO+Ox94UPd97XdEtni92riFxN4ofhZFTnZ+1QHE7iLQJtq pGymar92vYupi76Uva8IE3hs9zndPfgH+z053QcTuPt1B2ZmaWZOiwhBg9CxH/emBw747Psm 4fhD3eL3GBL3evVH4hcT6NP4WRU594z7yAdTiUj7Ah5ai12WYpN3Nxi1gsB/x4sI91yL9y+9 H/geBxMw+xHiFRMA9fcYIQYO+OyL3fg33QH/AAmAAN7/AIWAAOL/AIWAAN4DvfjbFXj7nOF/ mPdWBfcT/Df7CDn31d37Cvg39xMGmPtW4Zd495wFDvjsi934N90B9z3iA+P42xU59z38N/s9 Ofg93fs9+Df3Pd0HDvjsoHb4B90Bi/eJ7fd/A5b4WRU52gf3Q/wHBdIG90P4BwXZ3ft/OcwG +wj7jfsG940Fzt0GDvjsi933td3u6xLt4tz3i/tf94MXE/Sj+QwVkzflkwX8bjs59zv3Twes pKF310CqaBlmOfeD3TAGNu5Uw2ylCBP49zT3AAXN3fuLObiJBvsSPQX3+QcO+Ox74fhD3QHQ 4veW4gOa+NsVOdD7kweLYYs4r1a3Stp4xIvmi7eduM2xwonci7UI95PQ3fuSOe37kwc2iDD7 EvsSiObgHveT7d0HDvjse+H4Q90BkP8AU4AA/wDzgADiA/dR+NsVOfdS+7AHOYlKKB5ui2WR bZxpnoSiibmG9wUYNQaV+4nwVdOAvosZn4vjjbnQqbiMy4vACPew9xDdBw747Iv3M/sedvgH 3RKL92j3TfdfFxN4+FkEObkH8fwHBdcG1vduBY0G2PtuBdoG8PgHBbXd+1851gYTuFP7aAWJ Bjv3aAVOBj37aAWJBlT3aAXV3QYO+OyL3fhr6ot3Evc84hcTsOf5CxUT0JM49zCVBfxw+zw5 +Dvd+zz4ygcO+Ox94UPd9yPd3OESi+X3juIXE3z4b/fHFfJTy/sUHjqLR3BOcq07GLCbz6nR iwjuilVoH2ePao9eiwj7RFkjTh8TvD3QPfUe24u/sayjCBN8W/dB3TUHE7w02xU+NUaHd4sI YGKrsJeQ0/chsqmFhq4fDvjsi934N90B3eL3Efd4A7v42xU53fw3OTn3j9059xQHvrvTYL8z vPsTGfcx3SsGXulh4zbB9033SxjC3ft4OccG+037SAX3SN3dBw747Ivd90R29xrdEov3e/ts 93zW93P7Z/eAFxPsqfhZFTnPB/ch+xoFE/L7LPsvBUM593vdXQbt6+wrBV0594DdRwb7NPcv BRPs9x33GgXN3ftzObgGN0A91gW13QYO+OyL3fe13UPhEsTi9wri9wriFxPc+FkEOcT7tVI5 92ndRgcTvPeUB6KhoqCniwi3i1FmH/uy9ybdUPeLB56ioKitiwi3i2JRH/uu9xndXfdcB7+K 9xn7Eh5Yi2tvdHiDlnSvWItci2trenwIE9ysBw747IHhP933teHt6BLe4ve45xcTfPkSBJE2 2I8F/G8+Ofc4BxO8twfKWcWHqYsI9x7q9wj3CfcVIPT7FlNceGdfH/eKB/w8BNnN0N7cyUg6 PFFHNzZK0NoeDvjsi934wXcB90jiA+D4tBWuPfclzAX8Vfs8Ofg53fs6+MFVBw747Ivd+Gnj Ep7j92/mNt8XE+j4JvdIFSn7Wgfs4wUT8Pcc9xC9vuoa9wIx5PsEHmyLM4Y+LQg05QeKkIqV i5EIy9WYqtO1WlAei2SBbWFhOTn7IfsRWGAIOQcT6Pg090gGDvjsfeD3b9z3SeIS97zkUOQX E+j1phW+drp3yosI9wns2PcOymzIU6sfE/CgoK+u1RrzL8svHkKLVGhMYbdDGNW5ppu4iwi1 wXRNLS2KWYofOAepjZ2Lj4sIE+jWumRIPUtoUU1LqaFfH2k7BQ747C75iwGL7AP4IvkuFYiH iYiDf4mJGV1FRvsui/sai/sGvvsp0yCPhouKjocI5wZN9wpM9wuL9yOL9yPO9xLF9wIIDvjs i93e4PfK2gH3qOID+Cv5ExX7DQb7hvweBTv3qDj7Fjn3zd0r3uvgKwf7pxb3TvfKBY37ygYO +Owu+YsB9xHsA/dfLhWks56npsms2KTmi92LzHj3JSD3OQiKiY6MHy4GzPsQx/sGi/shi/sk R/sUWS2KiYaCiogIDvjsMOL43+QBi+ID97b5NBX9j/dk4vsN+N/3DeQHDvjs96DjAfde4wP3 lPi9FftZ+14z9177WeP3Wfde4/te91kHDvjsDvjsIfemAYv3ewP3hfc8FTT7pgX3AAb3D/em BQ747DDi+N/kAfcN4gP3yjAV+Y/7ZDL3Dfzf+w00Bw747H3e91/i91fgEovlPOX3ZuU85RcT 7PdC99QVE/JZaW1QVBo30SX3HPcd0PHgHou5dchRswgT7MG2msO1GvAz2CD7ADQ9Jx4T7Itu kU7KWAj3Evd+FcO8aFBRWGBVVFm4w8S7sMQfE/L7rgTVtVdZVVlcSUlZu8C7ssHYHw747PeR 5wGL93ID91H37RUv93LnBw747Pek98uLdxKL9xj7Ev8AeIAA/wA5gAD3GPsS/wB4gAAXE6D3 IvjbFRMAl/vLBfcBBpb3ywUTiL8WEwCX+8sF9wEGlvfLBQ747Hzi9zHi94DiAZPn92/oA85/ FaCKqImli7CL9wqL2Njl5Zn3HYvNCPdu+xPNNPsBOi77AvsE3Cz3AB6Xi76Lv7Ft+1f7I4tO i4SLdYtgjQj3zfffFWs7R4J0iwhRZcXJ07i3wbvMYyCSHw747Hv3PvspdhKL91AXE6D3wPcu FRMAXlprVlW8bLi5u6vAwViqYB8O+Ox79z77KXb3mvc+Eov3UBcTMPfA+DQVEwBaXmhZVrxr uLe9q8C+Xa1bHxOQ+5oEEwBhV21UVb1st7i8qsHCWKlgHw747H3e+HveAYvm93TmA/fA+RMV +0Zy+2D7DvsMo/tj90f3SKL3Y/cM9w1z92H7Rx84BPGV+zU5QIP7PSMnf/cz4OGb36OtH6Wu q4+ZiwgOcqT426T7L6T3J6QG94KT34v7Y6QH4QriC4wMDgAACmVuZHN0cmVhbQplbmRvYmoK NTIgMCBvYmoKNTY4NAplbmRvYmoKOSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0Zv bnROYW1lL0tYSVBOUitDb3VyaWVyLUJvbGQvRm9udEJCb3hbLTQ4IC0yODggNzQ2IDg0N10v RmxhZ3MgNQovQXNjZW50IDgzOQovQ2FwSGVpZ2h0IDgzOQovRGVzY2VudCAtMjg4Ci9JdGFs aWNBbmdsZSAwCi9TdGVtViAxMTEKL0F2Z1dpZHRoIDYwMAovTWF4V2lkdGggNjAwCi9NaXNz aW5nV2lkdGggNjAwCi9DaGFyU2V0KC9zcGFjZS9xdW90ZWRibC9wYXJlbmxlZnQvcGFyZW5y aWdodC9jb21tYS9oeXBoZW4vcGVyaW9kL3plcm8vb25lL3R3by90aHJlZS9mb3VyL3NpeC9u aW5lL2xlc3MvZ3JlYXRlci9hdC9BL0MvRC9FL0YvRy9IL0kvSi9LL00vTi9QL1IvUy9UL1Uv Vi9XL2JyYWNrZXRsZWZ0L2JyYWNrZXRyaWdodC9hL2IvYy9kL2UvZi9nL2gvaS9rL2wvbS9u L28vcC9xL3Ivcy90L3Uvdi93L3gveS96KQovRm9udEZpbGUzIDggMCBSPj4KZW5kb2JqCjgg MCBvYmoKPDwvTGVuZ3RoIDUzIDAgUi9TdWJ0eXBlL1R5cGUxQy9MZW5ndGgxIDU0OTM+PnN0 cmVhbQoBAAQCAAEBARRLWElQTlIrQ291cmllci1Cb2xkAAEBASb4GwH4HAL4HQNb+7T5fvnj BR0ABAZsDaccFVcS+BgR95kP91EQAAMBAVxob0NvcHlyaWdodCAoYykgSUJNIENvcnBvcmF0 aW9uIDE5OTAsMTk5MS4gSUJNIENvdXJpZXIgaXMgYSBUcmFkZW1hcmsgb2YgdGhlIElCTSBD b3Jwb3JhdGlvbi5Db3VyaWVyIEJvbGRDb3VyaWVyAACAP0F5bmNNem9kTkNwZURxZlBFcmdG c2hSR3RpU0h1VEl2a1VKd2xhVkt4bWJXPDEyPjMoNClAWzYgLF0tIjkuMAKgAAGtAA4AACIA WgBPAEQALgBbAFAARQAvACQAUQBGACUAUgBHADEAJgBTAEgAJwBUAEkAMwAoAFUASgA0ACkA VgA1ACoAVwBMADYAKwBYAE0AQgA3ACwAWQBOAEMAOAAdABIAEwAfABQACQAVAAoAIQA8ABcA AQANAD4ADgADABoADwARAEACAAEABABLAIwA2gFDAaAB0AIXAnwCvAMiA4gD5QQ7BKAE7AVL BasF8gZgBqkHUAebB/wIcwjDCPgJmQnWCikKbAqQCsYLHAtoC70MEgw8DK8M6g02DZQOBQ5e Dq8O0g73D1kPeQ/mECoQYhClEUARXhHSEdUR8RIPEiQSbBLYEwATT/jsDvjsi93t3feD3QGL 94H3EveBA+/42xU59xUH+z/8NwVROfeB3TIGsu0F93UGsikFMzn3gd1TBvtf+IkFsvvVFfsz Btr3UwUO+Oz7KN34Sd0Bi/dv9yr3awOZ+FkVOc0H9z772En7BQX7Lzn33t1ABveP+EkFyt37 azm/Bvsa+377Dvd+BcHdBg747Ivd97XdQ+ES3uL3cuIXE9ii+FkVOdz7tTg594rdPwcTuPd7 B7aqu7DDiwi8pV9VH/tdNzn3kN0692EH9EvWJx5Ki1xqanQIE9i1Bw747H3h98nhg3cSi+f/ ASqAAP8ATIAAFxPY+Fr4ZxWCVFi2YpdZixn7MjX7EPsJ+xvxIvcl9wrr1K+6H1vPUWJBWT6L GfsIYOLPtqP3A/ci9waTUE2UH9+WBRO4iKKIpbIai6+OsI6mCA747Ivd0/cb92jdAcj/AFOA APfG/wBTgAAD97r3tRUo97oF+1Q5ywaF/DcFUTn3i90iBpD3+AWXBun7sAXjBur3sAWXBpD7 +AUiOfeL3VEGhfg3Bcnd+1QGL/u6BQ747Ivd97XdAZXi937iA/D4WRX7PeLi908H+7D7vwVD +Db3QjQv+1wH97P3xAXOBw747H3h99DhAYvn9+LnA7T3ehX7EeX7C/c990Lg9xD3DPcSMPcK +zz7Nir7BPsYHucW3cTX9wL3BcE7PT1VO/sF+wJS2NweDvjsgeE/3fe14fc+d7R3Eovn97Pi FxO+96P5BxWCNvc1lwX7KQdgrVOdWosI+wj7By77IPsR8PsB9xinypC6wh8TbmH3PN06+MoH Mvw9FROuNUdOQD5KyeLkzsTWHhNu67o4Sh8O+Ox/9zb7Kt34N90S2dv3sNsXE3iQ+NsVOdn8 Nz0595fdJvfunQcTuPeD/EwF9viVzt37iznv+/N6Bvt++EUFDvjse+H4UOGEdxKL5/fS3BcT 2Pi990YVYWQ/RiSLCPsXUvcG9wf3IOPW6/cLmDJKlR/elgUTuIathq3EGouzjquNpAg4BhPY hVNoqmWrQ4sZ+wz7IiD7V/tB8/sh90X3I+/rra4fDvjs+yzdyuH3uN1D4RLa4ve35xcT7JX4 WRU52vxNPDn3yt37JPcKB8FdzIKqiwj3BvcL6/cjHxPc9wsv9wj7Ih54i0aLTlcIE+yxB4f7 bxUT3NrLz+TsuDxFM0lKPh4T7Ek1wPEfDvjsfeH3Dt304QGL5/fD5wP4rPckFVVrN2M4i/sW i3Thgq8I+BwGjJSNqIuiCO079wb7MvsuLPsG+xX7EuP7BPc8HtmL5qjlvwj8NfdlFZWmqtn3 A4uni+WJpiQIDvjsi934N90B2OL3rucDovjbFTnY/Dc+OfeWB7GL6IrLybW0tteL9w+LsYjk T9ZQ1UWRNosIjDkV0ouyhq5YomqbXItKizdzT2pqYmJRi2uLCC34NwYO+Oz7LN3K4fe43UPh Eovn97fiFxPs+OP4WRX7OgYT3GUHTr9Gi3iLCPsiL/sI+wv7I/cLK/cGqsyUucEf+wr7JDn3 yt08BxPs+E3aBxPc+zb7HRUlNVZJPknM49G42uzky0c8Hg747Ivd96vd9wbhi3cS8OIXE+jf +E8VOfD7qyY5+B7d+2L3q/di3ftirQfAiabWHqGLu4nSfAgT2K7hBRPokG1Gl0kb+ziELkMf aAcO+OyL3fcX3fdi3QHY4vd55wPc+NsVOdj8Nz4598bd+yL3F64H9wmLr43BqrmlrMqLxovN ZMtUqmShYZFEiwiMORXNi5+Fn4CjfqJqi2KLYHJtfINzfnSDIYsIZ/diBg747Ivd9wWhvN2e wNzdEt7i9wre/wAsgADgPf8AVYAAFxPugLj42xU53vw3ODn4kPdtOAeG+xsF+473TPcKRN4G E/6A93U4BxPvAEP7Cvct94UHE/8AlPsaBd4GhvdsBQ747Ivd97XdQ+ES9wziFxPQ0vhZFTn3 A/u1+ww5+Bzd+033TwcTsJOT5vPMG62LnnOWeOTPGHWhZbI/izWLVlthYwgT0NUHDvjs+yzd 2eH3qd054RKL5/ei4hcT7Pgi+FkVE9xgB2CtVJhliwj7CvsALPsW+w3tJPcT2LaumZwfi1eL X1R3dYNziPsbiwg58wf3E+ev9zUfE+z32trdB/s6+3IVRFRJPEBOydjczsTR0cpSOB4O+OyL 3fdM3Z+/3N0S1+L3Ct643xcT3sn42xU51/w3Pzn3tt37E/dM9wpE3gcT/vd1OAcT3kP7Cvct 94QHE/6X+xkF3AaF92sFDvjsfeFOdvgb4Yd3rHcSi+X3kOUXE474NPhwFROmflN2m2GqRYsZ QPsBYildp2GxdR+seKyD5IXZhraJi2MIYVdzQh4ri265gME9ghgTZpB2kHlkGothhW6HcwgT ptmGl7+mda1u2osZ9wndzd+ofrRopR9npl2NM5FUj0aOi74Iu82Tsh6ci+KLnVeTdBiMh46E jInZlhgTloafhp+rGouqkKqQpAgO+OyL3fe/4eHqAezi93LiA5f5DhWSN+WRBfxuODn3it0/ 93sH2sa0lKaLCMChW1of+143OfeQ3Tr3Ygf0StUoHkmLW2lsdQj3gQcO+OyL3fc73fc+3QHZ 4vdv5wOu+NsVOdn8Nz0595DdNPc7vgeri5d/tUyNiMM1sjYI9y7dLQZH9wd3qHOs9xSxjPGL n4vAcMFkpmOnYo1Niwg5BNO4fkkq+wORaR9B9z4GDvjse+H3Et33gOGEdxKL5/fS2kPiFxPc +Fb45RUT7IVUXMBQlGuLGfsl+xD7FPtL+yvk+y73WR8T6uiL3K23ngj3M7rd+6o59yQoB0Zx WYqAiwj7GEzq9xH3Htvh8vcOmCpSkh8T3N+WhqSErovLGYu0jauNpAgO+Ox94fe13Tn3chLN 4hcTsPcz+NsVE9D7IEk5zfs8B4tPjFC0YKlsxH23i9yL47O/o2raGGt+UXNcd1CLGTyMv9Af 9zz3eN37eAcTsPcgBw747Ivd97Xd4vcYEvcr9TTiFxPo9wf4WRU59yP7tfs+Ofg83fs7+AcH EzAh4hUTAPX3GCEGDvjse+H4UOGEdxKL5Trd95PbP+UXE7L4R/jlFRPSg1N8m2K6O4sZKCA9 IPso9zZ70YQfyIXEf4tNCEZBclAeE8oqi2vKhNYIOwaOa5BIi06Laop9iXcI3AaTx6NxqWzc ixn3Ceja8sxotWeiH2OlY45IkwgT1GCQMpTRGrWwwuce9wmLlyeSVdqWGIuOip2KjggTtImj h7m1GouujaiNoQgO+OyL3fdG3fcz3QHU4vd04gOn+NsVOdT8N0I593zdQ/dG93T7RkM593zd Qvg31N37fDnT+zP7dPcz090HDvjsfeFD3fe13RLZ4vdq4hcTeKH4WRU52ftUBxO4i0CbaqRs pmq/dr2LqYu+lL2vCBN4bPc53T34B/s9Od0HE7j7dQdmZmlmTosIQYPQsR/3pgcO+OyL3fg3 3QH/AAmAAN7/AIWAAOL/AIWAAN4DvfjbFXj7nOF/mPdWBfcT/Df7CDn31d37Cvg39xMGmPtW 4Zd495wFDvjsi934N90B9z3iA+P42xU59z38N/s9Ofg93fs9+Df3Pd0HDvjsoHb4B90Bi/eJ 7fd/A5b4WRU52gf3Q/wHBdIG90P4BwXZ3ft/OcwG+wj7jfsG940Fzt0GDvjsi933td3u6xLt 4tz3i/tf94MXE/Sj+QwVkzflkwX8bjs59zv3TwespKF310CqaBlmOfeD3TAGNu5Uw2ylCBP4 9zT3AAXN3fuLObiJBvsSPQX3+QcO+Ox74fhD3QHQ4veW4gOa+NsVOdD7kweLYYs4r1a3Stp4 xIvmi7eduM2xwonci7UI95PQ3fuSOe37kwc2iDD7EvsSiObgHveT7d0HDvjse+H4Q90BkP8A U4AA/wDzgADiA/dR+NsVOfdS+7AHOYlKKB5ui2WRbZxpnoSiibmG9wUYNQaV+4nwVdOAvosZ n4vjjbnQqbiMy4vACPew9xDdBw747Iv3M/sedvgH3RKL92j3TfdfFxN4+FkEObkH8fwHBdcG 1vduBY0G2PtuBdoG8PgHBbXd+1851gYTuFP7aAWJBjv3aAVOBj37aAWJBlT3aAXV3QYO+OyL 3fhr6ot3Evc84hcTsOf5CxUT0JM49zCVBfxw+zw5+Dvd+zz4ygcO+Ox94UPd9yPd3OESi+X3 juIXE3z4b/fHFfJTy/sUHjqLR3BOcq07GLCbz6nRiwjuilVoH2ePao9eiwj7RFkjTh8TvD3Q PfUe24u/sayjCBN8W/dB3TUHE7w02xU+NUaHd4sIYGKrsJeQ0/chsqmFhq4fDvjsoHb4id0S i/eK+4r47PuJ94kXE+j3w/cQFfsf+A0F3d37ijnTBvdP/IkF4Qb3UfiJBc3d+4k55QYO+OyL 3fg33QHd4vcR93gDu/jbFTnd/Dc5OfeP3Tn3FAe+u9NgvzO8+xMZ9zHdKwZe6WHjNsH3TfdL GMLd+3g5xwb7TftIBfdI3d0HDvjsi933RHb3Gt0Si/d7+2z3fNb3c/tn94AXE+yp+FkVOc8H 9yH7GgUT8vss+y8FQzn3e91dBu3r7CsFXTn3gN1HBvs09y8FE+z3HfcaBc3d+3M5uAY3QD3W BbXdBg747Ivd97XdQ+ESxOL3CuL3CuIXE9z4WQQ5xPu1Ujn3ad1GBxO895QHoqGioKeLCLeL UWYf+7L3Jt1Q94sHnqKgqK2LCLeLYlEf+673Gd1d91wHv4r3GfsSHliLa290eIOWdK9Yi1yL a2t6fAgT3KwHDvjsgeE/3fe14e3oEt7i97jnFxN8+RIEkTbYjwX8bz459zgHE7y3B8pZxYep iwj3Hur3CPcJ9xUg9PsWU1x4Z18f94oH/DwE2c3Q3tzJSDo8UUc3NkrQ2h4O+Oygdvhgd8jd AYv3evci93gD+NsEObsHx/yJBdoG9wD3xwWNBvcE+8cF2gbM+IkFut37eDnsBmf7xQWJBij3 nAVPBiX7nAWJBmn3xQXr3QYO+OzW+HUBi/i4A/iY+MAV/JP7gfiT+4iv2/vw9zf38fczBQ74 7Ivd+MF3AfdI4gPg+LQVrj33JcwF/FX7PDn4Od37OvjBVQcO+OyL3fhp4xKe4/dv5jbfFxPo +Cb3SBUp+1oH7OMFE/D3HPcQvb7qGvcCMeT7BB5sizOGPi0INOUHipCKlYuRCMvVmKrTtVpQ HotkgW1hYTk5+yH7EVhgCDkHE+j4NPdIBg747PhxdwGL+LgD0PjAFWY89/D7M/vv+zeuO/iU 94gFDvjsfeD3b9z3SeIS97zkUOQXE+j1phW+drp3yosI9wns2PcOymzIU6sfE/CgoK+u1Rrz L8svHkKLVGhMYbdDGNW5ppu4iwi1wXRNLS2KWYofOAepjZ2Lj4sIE+jWumRIPUtoUU1LqaFf H2k7BQ747C75iwGL7AP4IvkuFYiHiYiDf4mJGV1FRvsui/sai/sGvvsp0yCPhouKjocI5wZN 9wpM9wuL9yOL9yPO9xLF9wIIDvjsi93e4PfK2gH3qOID+Cv5ExX7DQb7hvweBTv3qDj7Fjn3 zd0r3uvgKwf7pxb3TvfKBY37ygYO+Owu+YsB9xHsA/dfLhWks56npsms2KTmi92LzHj3JSD3 OQiKiY6MHy4GzPsQx/sGi/shi/skR/sUWS2KiYaCiogIDvjsf8/Xz/dI0dfNAYvRz9L3qdAD +Jj3EhVIaEloMIsI+0Rz9zPR5LL3LPdE9OtS+xc/Zk1fdX6dl5eTqI2QH7n3PQVCBoZ2fph+ mG+LGTNH+wctNcRxqpWzjLi2H6pgt4uUiwjX19D3GPc1+wbt+y77F/swQfuB+0/3AyH3L+fj qrraH/u69xkVeYeplMa43q6XmHxyU2E2Yh8O+Oww4vjf5AGL4gP3tvk0Ff2P92Ti+w343/cN 5AcO+Ox84veA4vcx4oh3Eovo92/nFxPc+In5EBUT7Ix2bo1xG2aL+wqLPj4xMX37HYtJCPtu 9xNJ4vcB3Oj3AvcEOur7AB5/i1iLV2Wp91f3I4vIi5KLp4u2iQj70/vfFavbz5SiiwjFsVFN Q15fVVtKs/aEHw747A747CH3pgGL93sD94X3PBU0+6YF9wAG9w/3pgUO+Oww4vjf5AH3DeID 98owFfmP+2Qy9w383/sNNAcO+Oz3kecBi/dyA/dR9+0VL/dy5wcO+Oz3pPfLi3cSi/cY+xL/ AHiAAP8AOYAA9xj7Ev8AeIAAFxOg9yL42xUTAJf7ywX3AQaW98sFE4i/FhMAl/vLBfcBBpb3 ywUO+Ox84vcx4veA4gGT5/dv6APOfxWgiqiJpYuwi/cKi9jY5eWZ9x2LzQj3bvsTzTT7ATou +wL7BNws9wAel4u+i7+xbftX+yOLTouEi3WLYI0I98333xVrO0eCdIsIUWXFydO4t8G7zGMg kh8O+Ox79z77KXYSi/dQFxOg98D3LhUTAF5aa1ZVvGy4uburwMFYqmAfDvjsfd74e94Bi+b3 dOYD98D5ExX7RnL7YPsO+wyj+2P3R/dIovdj9wz3DXP3YftHHzgE8ZX7NTlAg/s9Iyd/9zPg 4Zvfo60fpa6rj5mLCA5ypPjbpPsvpPcnpAb3gpPfi/tjpAfhCuILjAwOAAAKZW5kc3RyZWFt CmVuZG9iago1MyAwIG9iago1NDk0CmVuZG9iagoxNSAwIG9iago8PC9TdWJ0eXBlL1R5cGUx L0Jhc2VGb250L1ZNUUlSVCtDb3VyaWVyLUJvbGR+ZS9UeXBlL0ZvbnQvTmFtZS9SMTUvRm9u dERlc2NyaXB0b3IgMTQgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAyNTUvV2lkdGhzWwo2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw CjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwXQo+PgplbmRvYmoKMjIgMCBvYmoKPDwv U3VidHlwZS9UeXBlMS9CYXNlRm9udC9TSkVaT0krQ291cmllci1Cb2xkfjE1L1R5cGUvRm9u dC9OYW1lL1IyMi9Gb250RGVzY3JpcHRvciAyMSAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFy IDI1NS9XaWR0aHNbCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDBdCj4+CmVuZG9i agoyOSAwIG9iago8PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L1BHU1BNWCtDb3VyaWVyLUJv bGR+MWMvVHlwZS9Gb250L05hbWUvUjI5L0ZvbnREZXNjcmlwdG9yIDI4IDAgUi9GaXJzdENo YXIgMzIvTGFzdENoYXIgMjU1L1dpZHRoc1sKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMF0KPj4KZW5kb2JqCjM2IDAgb2JqCjw8L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvSUJT WFdKK0NvdXJpZXItQm9sZH4yMy9UeXBlL0ZvbnQvTmFtZS9SMzYvRm9udERlc2NyaXB0b3Ig MzUgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAyNTUvV2lkdGhzWwo2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwXQo+PgplbmRvYmoKNDMgMCBvYmoKPDwvU3VidHlwZS9UeXBl MS9CYXNlRm9udC9GWUZPVVkrQ291cmllci1Cb2xkfjJhL1R5cGUvRm9udC9OYW1lL1I0My9G b250RGVzY3JpcHRvciA0MiAwIFIvRmlyc3RDaGFyIDMyL0xhc3RDaGFyIDI1NS9XaWR0aHNb CjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDBdCj4+CmVuZG9iagoxMCAwIG9iago8 PC9TdWJ0eXBlL1R5cGUxL0Jhc2VGb250L0tYSVBOUitDb3VyaWVyLUJvbGQvVHlwZS9Gb250 L05hbWUvUjEwL0ZvbnREZXNjcmlwdG9yIDkgMCBSL0ZpcnN0Q2hhciAzMi9MYXN0Q2hhciAy NTUvV2lkdGhzWwo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwCjYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAw IDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2 MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwXQo+PgplbmRvYmoK MiAwIG9iago8PC9Qcm9kdWNlciAoR05VIEdob3N0c2NyaXB0IDYuNTEpCj4+ZW5kb2JqCnhy ZWYKMCA1NAowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwMDk4MDQgMDAwMDAgbiAKMDAwMDA1 MzU2OCAwMDAwMCBuIAowMDAwMDA5NzEwIDAwMDAwIG4gCjAwMDAwMDk4NTIgMDAwMDAgbiAK MDAwMDAwODgzMCAwMDAwMCBuIAowMDAwMDAwMDE1IDAwMDAwIG4gCjAwMDAwMDE3MTYgMDAw MDAgbiAKMDAwMDA0MTc0MCAwMDAwMCBuIAowMDAwMDQxMjc3IDAwMDAwIG4gCjAwMDAwNTI1 MzIgMDAwMDAgbiAKMDAwMDAwMTczNiAwMDAwMCBuIAowMDAwMDAxNzY2IDAwMDAwIG4gCjAw MDAwMzU0OTMgMDAwMDAgbiAKMDAwMDAzNTAyMyAwMDAwMCBuIAowMDAwMDQ3MzMzIDAwMDAw IG4gCjAwMDAwMDg5OTAgMDAwMDAgbiAKMDAwMDAwMTc5OCAwMDAwMCBuIAowMDAwMDAzMjA1 IDAwMDAwIG4gCjAwMDAwMDMyMjYgMDAwMDAgbiAKMDAwMDAyOTI3NSAwMDAwMCBuIAowMDAw MDI4ODAxIDAwMDAwIG4gCjAwMDAwNDgzNzIgMDAwMDAgbiAKMDAwMDAwOTEzNCAwMDAwMCBu IAowMDAwMDAzMjU4IDAwMDAwIG4gCjAwMDAwMDQ3ODMgMDAwMDAgbiAKMDAwMDAwNDgwNCAw MDAwMCBuIAowMDAwMDIyNzIyIDAwMDAwIG4gCjAwMDAwMjIyMDYgMDAwMDAgbiAKMDAwMDA0 OTQxMiAwMDAwMCBuIAowMDAwMDA5Mjc4IDAwMDAwIG4gCjAwMDAwMDQ4MzYgMDAwMDAgbiAK MDAwMDAwNjUxNyAwMDAwMCBuIAowMDAwMDA2NTM4IDAwMDAwIG4gCjAwMDAwMTU5NDAgMDAw MDAgbiAKMDAwMDAxNTQ0MSAwMDAwMCBuIAowMDAwMDUwNDUyIDAwMDAwIG4gCjAwMDAwMDk0 MjIgMDAwMDAgbiAKMDAwMDAwNjU3MCAwMDAwMCBuIAowMDAwMDA4MTUzIDAwMDAwIG4gCjAw MDAwMDgxNzQgMDAwMDAgbiAKMDAwMDAxMDMyNiAwMDAwMCBuIAowMDAwMDA5OTA3IDAwMDAw IG4gCjAwMDAwNTE0OTIgMDAwMDAgbiAKMDAwMDAwOTU2NiAwMDAwMCBuIAowMDAwMDA4MjA2 IDAwMDAwIG4gCjAwMDAwMDg3NzggMDAwMDAgbiAKMDAwMDAwODc5OCAwMDAwMCBuIAowMDAw MDE1NDIwIDAwMDAwIG4gCjAwMDAwMjIxODUgMDAwMDAgbiAKMDAwMDAyODc4MCAwMDAwMCBu IAowMDAwMDM1MDAyIDAwMDAwIG4gCjAwMDAwNDEyNTYgMDAwMDAgbiAKMDAwMDA0NzMxMiAw MDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDU0IC9Sb290IDEgMCBSIC9JbmZvIDIgMCBSCj4+ CnN0YXJ0eHJlZgo1MzYyMAolJUVPRgo= --------------080400070002060405060102-- --------------enigDA0002951A0C289729C40A8D Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/BcsL8CBzV/QUlSsRAumLAJ0YU5Gt1GbI+M8CQkDf12ssV7vf/QCgtM7T 4NQlDcsz/J7whq7Zjpvy07I= =AlDA -----END PGP SIGNATURE----- --------------enigDA0002951A0C289729C40A8D-- From owner-ipsec@lists.tislabs.com Sat Jul 5 03:15:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h65AFLqt067225; Sat, 5 Jul 2003 03:15:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA25306 Sat, 5 Jul 2003 05:32:05 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16134.40013.810651.166875@ryijy.hel.fi.ssh.com> Date: Sat, 5 Jul 2003 12:37:17 +0300 From: Tero Kivinen To: "Jeffrey I. Schiller" Cc: IPSEC Mailing List Subject: Issues 31,34,36: New Version of draft-ietf-ipsec-ikev2 attached In-Reply-To: <3F05CB04.3020304@mit.edu> References: <3F05CB04.3020304@mit.edu> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jeffrey I. Schiller writes: > This hasn't been submitted to the I-D Directory due to it being closed. > This version will likely have more edits before it does get submitted! > Its attached as a PDF so I could highlight the changes (and it also > saves me the step of converting it from a PDF to text. The source is in > OpenOffice). Group 5 is not defined in the RFC2409, it is currently defined only in the RFC3526, so the reference in the section 4.1.2 should be changed accordingly. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sun Jul 6 08:39:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h66FdZqt069704; Sun, 6 Jul 2003 08:39:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA01256 Sun, 6 Jul 2003 10:56:58 -0400 (EDT) Message-ID: <3F083A40.7040504@mit.edu> Date: Sun, 06 Jul 2003 11:03:28 -0400 From: "Jeffrey I. Schiller" Organization: Massachusetts Institute of Technology User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen CC: IPSEC Mailing List Subject: Re: Issues 31,34,36: New Version of draft-ietf-ipsec-ikev2 attached References: <3F05CB04.3020304@mit.edu> <16134.40013.810651.166875@ryijy.hel.fi.ssh.com> X-Enigmail-Version: 0.63.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Oops. I meant to fix that! I just fixed it in my working copy, but I won't bother the list with another copy of the whole document! -Jeff Tero Kivinen wrote: > Jeffrey I. Schiller writes: > >>This hasn't been submitted to the I-D Directory due to it being closed. >>This version will likely have more edits before it does get submitted! >>Its attached as a PDF so I could highlight the changes (and it also >>saves me the step of converting it from a PDF to text. The source is in >>OpenOffice). > > > Group 5 is not defined in the RFC2409, it is currently defined only in > the RFC3526, so the reference in the section 4.1.2 should be changed > accordingly. From owner-ipsec@lists.tislabs.com Sun Jul 6 16:51:27 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h66NpQqt099527; Sun, 6 Jul 2003 16:51:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02608 Sun, 6 Jul 2003 19:08:54 -0400 (EDT) To: IPsec WG Subject: Hui-Lan Lu: Access Link Intermediaries Assisting Services (alias) BOF announcement Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sun, 06 Jul 2003 19:15:14 -0400 Message-ID: <31902.1057533314@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Content-Transfer-Encoding: 7bit Date: Thu, 26 Jun 2003 22:03:47 -0400 From: Hui-Lan Lu To: trigtran@ietf.org, intersec@psg.com CC: mankin@psg.com, kfall@eecs.berkeley.edu, jon.peterson@neustar.biz Subject: Access Link Intermediaries Assisting Services (alias) BOF announcement X-Spam-Status: No, hits=-1.6 required=5.0 tests=BAYES_30 version=2.53 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.53 (1.174.2.15-2003-03-30-exp) Sender: owner-intersec@psg.com Precedence: bulk Access Link Intermediaries Assisting Services (alias) BOF Tuesday, July 15 at 1545-1645 ============================== CHAIRS: Kevin Fall (kfall@eecs.berkeley.edu), Hui-Lan Lu (huilanlu@lucent.com) AGENDA: + Agenda bashing + A brief history, Area Directors, 5 min. + INTERSEC perspective, T. Woo, 15 min. http://www.ietf.org/internet-drafts/draft-blumenthal-intermediary-transport-00.txt + TRIGTRAN perspective, S. Dawkins, 15 min. http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-framework-00.txt http://www.ietf.org/internet-drafts/draft-dawkins-trigtran-probstmt-01.txt + Tentative charter + Wrapping up MAILING LIST: alias@mailman.berkeley.intel-research.net TO JOIN: http://mailman.berkeley.intel-research.net/mailman/listinfo/alias PROPOSED CHARTER: Several types of access links in widespread use for Internet connectivity today have characteristics that affect the operation Internet protocols and services. Low-bandwidth, high latency links patched over telephone lines via modems are one common example. Radio links in wireless networks (such as GSM, IS-95, GPRS and 802.11) are another example. These links often have undesirable characteristics such as high loss, high delay and low reliability. Transport intermediaries have been used to enhance the performance of problematic links in the past (see RFC 3135). This BoF investigates further work in support of transport intermediaries that provide assistance to access links, including (but not exclusively) wireless links, primarily in the areas of security protocol interaction with transport intermediaries and response to changing link conditions. In particular, existing intermediaries used for these purposes interfere with IPSec and may weaken overall end-to-end security - work is therefore necessary to determine how to request, authenticate and authorize the services of intermediaries, and when possible to mitigate the interference of intermediaries in security. This work focuses on support for TCP initially but does not preclude consideration of other transport-layer protocols. The relationship of transport intermediaries to devices constrained by OPES and UNSAF is also critical to the architectural framework. From owner-ipsec@lists.tislabs.com Tue Jul 8 13:44:01 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68Ki0qt007957; Tue, 8 Jul 2003 13:44:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16058 Tue, 8 Jul 2003 15:52:29 -0400 (EDT) Message-Id: <200307081953.h68Jr6cJ016060@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com, kivinen@ssh.fi, housley@vigilsec.com Subject: draft-ietf-ipsec-ikev2-algorithms draft Cc: byfraser@cisco.com, tytso@mit.edu, jis@mit.edu, smb@research.att.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 08 Jul 2003 15:53:06 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk FYI, All the tickets related to this document have been marked as closed, since Jeff took care of all the issues in his latest draft, which he is about to send to the I-D editor. Cheers, -Angelos From owner-ipsec@lists.tislabs.com Tue Jul 8 15:51:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h68Mpjqt016197; Tue, 8 Jul 2003 15:51:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA16592 Tue, 8 Jul 2003 18:16:02 -0400 (EDT) Date: Tue, 8 Jul 2003 15:22:41 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Q: EAP Message Format From: Ricky Charlet To: ipsec mailingList Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, So, as currently specified in draft-08, the length field of the EAP message format may be either 2 or 4 bytes depending upon the type. If the message does indeed have a 4 byte length and no type/type-data fields, then what does it look like? Perhaps the following? 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Code ! Identifier ! Reserved ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: EAP Message Format --- Ricky Charlet rcharlet@alumni.calpoly.edu 510.324.3163 From owner-ipsec@lists.tislabs.com Tue Jul 8 22:25:21 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h695PKqt034945; Tue, 8 Jul 2003 22:25:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA18630 Wed, 9 Jul 2003 00:39:34 -0400 (EDT) From: "Yoav Nir" To: "'Ricky Charlet'" , "'ipsec mailingList'" Subject: RE: EAP Message Format Date: Wed, 9 Jul 2003 07:44:14 +0200 Message-ID: <003b01c345dd$223232f0$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm confused. Where did you get this 4-byte length field? Current technology does not allow 65536-byte frames, so what authentication type would need a 4-byte length field? To quote from -08: o Length (two octets) is the length of the EAP message and MUST be four less than the Payload Length of the encapsulating payload. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Ricky Charlet Sent: Wednesday, July 09, 2003 12:23 AM To: ipsec mailingList Subject: Q: EAP Message Format Howdy, So, as currently specified in draft-08, the length field of the EAP message format may be either 2 or 4 bytes depending upon the type. If the message does indeed have a 4 byte length and no type/type-data fields, then what does it look like? Perhaps the following? 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Code ! Identifier ! Reserved ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: EAP Message Format --- Ricky Charlet rcharlet@alumni.calpoly.edu 510.324.3163 From owner-ipsec@lists.tislabs.com Wed Jul 9 01:50:17 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h698oGqt073305; Wed, 9 Jul 2003 01:50:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA21888 Wed, 9 Jul 2003 04:07:09 -0400 (EDT) Message-Id: <200307090812.h698Cbof020794@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ricky Charlet cc: ipsec mailingList Subject: Re: Q: EAP Message Format In-reply-to: Your message of Tue, 08 Jul 2003 15:22:41 PDT. Date: Wed, 09 Jul 2003 10:12:37 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: So, as currently specified in draft-08, the length field of the EAP message format may be either 2 or 4 bytes depending upon the type. => no, the text in the draft is buggy but is simpler than your proposal. Current text is: o Type (one octet) is present only if the Code field is Request (1) or Response (2). For other types, the EAP message length MUST be four octets and the Type and Type_Data fields MUST NOT be present. ... The fixed text should be: o Type (one octet) is present only if the Code field is Request (1) or Response (2). For other codes, the EAP message length ^^^^^ MUST be four octets and the Type and Type_Data fields MUST NOT be present. ... So if the code is not Request or Response the length field *value* is 4 and there is nothing after the length field. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Jul 9 07:52:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h69EqOqt000443; Wed, 9 Jul 2003 07:52:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24162 Wed, 9 Jul 2003 10:02:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Wed, 9 Jul 2003 10:10:27 -0400 To: ipsec@lists.tislabs.com From: Karen Seo Subject: WG Last Call for IPsec AH, ESP, ESN addendum for ISAKMP DOI Cc: kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, We've made changes to address the concerns expressed by the folks listed below and sent them the proposed edits. Once they've had a chance to review/approve the changes, we'll submit the revised drafts to the IETF internet drafts publisher. AH Pekka Nikander David Black Russ Housley ESP Russ Housley ESN Addendum David Black Russ Housley We believe this is a complete list, but if we missed your feedback, please accept our apologies and resend your comments. Thank you, Karen From owner-ipsec@lists.tislabs.com Wed Jul 9 17:20:06 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6A0K6qt030176; Wed, 9 Jul 2003 17:20:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26325 Wed, 9 Jul 2003 19:29:11 -0400 (EDT) From: "George Hadjichristofi" To: "Ipsec" Cc: "George Hadjichristofi" Subject: IKE key question Date: Wed, 9 Jul 2003 19:35:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a few questions with regards to the usage of keys. After an IKE negotiation, what key is used to encrypt data between two communicating entities? Is it the SKEYID_e key derived during the IKE negotiation or is it the shared/public key? Thank you George *********************************************************** George C. Hadjichristofi Graduate Student Bradley Department of Electrical and Computer Engineering Virginia Tech,Blacksburg,VA 24061,U.S.A TEL:(540)-951-8936 *********************************************************** From owner-ipsec@lists.tislabs.com Wed Jul 9 17:43:55 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6A0hsqt030648; Wed, 9 Jul 2003 17:43:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA26531 Wed, 9 Jul 2003 20:08:43 -0400 (EDT) Message-Id: <200307082338.h68Nc1L11808@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3554 on On the Use of Stream Control Transmission Protocol (SCTP) with IPsec Cc: rfc-editor@rfc-editor.org, ipsec@lists.tislabs.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Tue, 08 Jul 2003 16:38:01 -0700 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3554 Title: On the Use of Stream Control Transmission Protocol (SCTP) with IPsec Author(s): S. Bellovin, J. Ioannidis, A. Keromytis, R. Stewart Status: Standards Track Date: July 2003 Mailbox: smb@research.att.com, ji@research.att.com, angelos@cs.columbia.edu, rrs@cisco.com Pages: 9 Characters: 20102 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsec-sctp-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3554.txt This document describes functional requirements for IPsec (RFC 2401) and Internet Key Exchange (IKE) (RFC 2409) to facilitate their use in securing SCTP (RFC 2960) traffic. This document is a product of the IP Security Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030708163620.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3554 --OtherAccess Content-Type: Message/External-body; name="rfc3554.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030708163620.RFC@RFC-EDITOR.ORG> --OtherAcces s-- --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jul 9 17:46:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6A0ktqt030700; Wed, 9 Jul 2003 17:46:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA26553 Wed, 9 Jul 2003 20:12:59 -0400 (EDT) Message-ID: <2F8E7538CA01D711BC5900B0D079E71023321A@zin03exm01.corp.mot.com> From: Mittal Harshwardhan-A18990 To: ipsec@lists.tislabs.com Subject: Securid authentication for IKE client Date: Wed, 9 Jul 2003 09:52:28 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I am currently working on a VPN client and wants to get the client authenticated using RSA Securid ACE card. I have all required information ( userid, passcode, acecard value). IKE phase 1 is complete with some default group-id and password. I am using Cisco 5000 series concentrator as a server which is not under my conrol, but I have my ace-card and laptop (windows and linux) client (provided by Cisco) configured for the server, and I am able to estblish VPN session both from linux and windows. My question is what is the packet format in which I can send my ace-card credentials to the cisco server to get my client authenticated. What is the protocol, I think Cisco client is sending this info in form of IKE informational exchange. but as the packet is encrypted using ISAKMPD SA I am unable to find out the packet format. thanks in anticipation Regards, Harsh From owner-ipsec@lists.tislabs.com Wed Jul 9 21:49:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6A4nCqt035386; Wed, 9 Jul 2003 21:49:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA28001 Thu, 10 Jul 2003 00:03:02 -0400 (EDT) Message-ID: <3F0CE999.2020502@roc.co.in> Date: Thu, 10 Jul 2003 09:50:41 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mittal Harshwardhan-A18990 CC: ipsec@lists.tislabs.com Subject: Re: Securid authentication for IKE client References: <2F8E7538CA01D711BC5900B0D079E71023321A@zin03exm01.corp.mot.com> In-Reply-To: <2F8E7538CA01D711BC5900B0D079E71023321A@zin03exm01.corp.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am not sure whether CISCO5000 supports this or not. But, you should have X-Auth support for this to work. Also, make sure that X-Auth implementation supports RSA SecureID transactions by both VPN client and CISCO 5000 servers. Regards Ravi Mittal Harshwardhan-A18990 wrote: > Hi all, > > I am currently working on a VPN client and wants to get the client authenticated using RSA Securid ACE card. > I have all required information ( userid, passcode, acecard value). > > IKE phase 1 is complete with some default group-id and password. > > I am using Cisco 5000 series concentrator as a server which is not under my conrol, > but I have my ace-card and laptop (windows and linux) client (provided by Cisco) configured for the server, > and I am able to estblish VPN session both from linux and windows. > > My question is what is the packet format in which I can send my ace-card credentials to the cisco server > to get my client authenticated. > What is the protocol, I think Cisco client is sending this info in form of IKE informational exchange. > but as the packet is encrypted using ISAKMPD SA I am unable to find out the packet format. > > thanks in anticipation > > Regards, > Harsh > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Wed Jul 9 21:49:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6A4nDqt035387; Wed, 9 Jul 2003 21:49:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA27985 Wed, 9 Jul 2003 23:58:48 -0400 (EDT) Message-ID: <3F0C28B3.8080903@roc.co.in> Date: Wed, 09 Jul 2003 20:07:39 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mittal Harshwardhan-A18990 CC: ipsec@lists.tislabs.com Subject: Re: Securid authentication for IKE client References: <2F8E7538CA01D711BC5900B0D079E71023321A@zin03exm01.corp.mot.com> In-Reply-To: <2F8E7538CA01D711BC5900B0D079E71023321A@zin03exm01.corp.mot.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am not sure whether CISCO5000 supports this or not. But, you should have X-Auth support for this to work. Also, make sure that X-Auth implementation supports RSA SecureID transactions by both VPN client and CISCO 5000 servers. Regards Ravi Mittal Harshwardhan-A18990 wrote: > Hi all, > > I am currently working on a VPN client and wants to get the client authenticated using RSA Securid ACE card. > I have all required information ( userid, passcode, acecard value). > > IKE phase 1 is complete with some default group-id and password. > > I am using Cisco 5000 series concentrator as a server which is not under my conrol, > but I have my ace-card and laptop (windows and linux) client (provided by Cisco) configured for the server, > and I am able to estblish VPN session both from linux and windows. > > My question is what is the packet format in which I can send my ace-card credentials to the cisco server > to get my client authenticated. > What is the protocol, I think Cisco client is sending this info in form of IKE informational exchange. > but as the packet is encrypted using ISAKMPD SA I am unable to find out the packet format. > > thanks in anticipation > > Regards, > Harsh > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Sat Jul 12 10:09:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6CH9cqt002272; Sat, 12 Jul 2003 10:09:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13658 Sat, 12 Jul 2003 12:18:38 -0400 (EDT) Message-Id: <5.2.0.9.2.20030711212509.03a0b3b8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 11 Jul 2003 21:27:21 -0400 To: Tero Kivinen , ipsec@lists.tislabs.com From: Russ Housley Subject: Re: Comments to draft-ietf-ipsec-ciph-aes-ccm-03.txt In-Reply-To: <16119.17412.231940.346484@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero: Good catch. I will post an update as soon as the Internet-Draft repository opens after the IETF meeting in Vienna. I will point to [CCM] for test vectors. I think this will be sufficient for implementors. Russ At 09:16 PM 6/23/2003 +0300, Tero Kivinen wrote: >The document draft-ietf-ipsec-ciph-aes-ccm-03 talks about generating >keying material in section 5.1, which only is valid to IKEv2 and Phase >1 SA creation. This should be change to apply to both IKEv1 and IKEv2 >keying material generation. > >The current text: >---------------------------------------------------------------------- >7.1. Keying Material and Salt Values > > As previously described, implementations MUST use fresh keys with > AES-CCM. IKE can be used to establish fresh keys. This section > describes the conventions for obtaining the unpredictable salt value > for use in the nonce from IKE. Note that this convention provides a > salt value that is secret as well as unpredictable. > > IKE makes use of a pseudo-random function (PRF) to derive keying > material. The PRF is used iteratively to derive keying material of > arbitrary size. Keying material is extracted from the output string > without regard to boundaries. > > IKE uses the PRF to generate an output stream that parsed into five > keys: SK_d, SK_ai, SK_ar, SK_ei, and SK_er. SK_d is used to derive > new keys for the child security associations. SK_ai and SK_ar are > the authentication keys for the initiator and the responder, > respectively. SK_ei and SK_er are the encryption keys for the > initiator and the responder, respectively. > > SK_ai and SK_ei are used to protect traffic from the initiator to the > responder. SK_ar and SK_er are used to protect traffic from the > responder to the initiator. > > The size of SK_ei and SK_er are each three octets longer than is > needed by the associated AES key. The keying material is used as > follows: > > AES-CCM with a 128 bit key > SK_ei and SK_er are each 19 octets. The first 16 octets are > the 128-bit AES key, and the remaining three octets are used as > the salt value in the counter block. > > AES-CCM with a 192 bit key > SK_ei and SK_er are each 27 octets. The first 24 octets are > the 192-bit AES key, and the remaining three octets are used as > the salt value in the counter block. > > AES-CCM with a 256 bit key > SK_ei and SK_er are each 35 octets. The first 32 octets are > the 256-bit AES key, and the remaining three octets are used as > the salt value in the counter block. >---------------------------------------------------------------------- > >In my previous mail about the aes-ctr I already cut & pasted the >relevant pieces from the IKEv2 draft and RFC2409, so I do not repeat >them here. > >The proposed replacement text is: >----------------------------------------------------------------------7.1. >Keying Material and Salt Values > > As previously described, implementations MUST use fresh keys with > AES-CCM. IKE can be used to establish fresh keys. This section > describes the conventions for obtaining the unpredictable salt value > for use in the nonce from IKE. Note that this convention provides a > salt value that is secret as well as unpredictable. > > IKE makes use of a pseudo-random function (PRF) to derive keying > material. The PRF is used iteratively to derive keying material > "KEYMAT" of arbitrary size. Keying material is extracted from the > output string without regard to boundaries. > > The size of KEYMAT needed for each AES-CTR key is each three octets > longer than is needed by the associated AES key. The keying > material is used as follows: > > AES-CCM with a 128 bit key > KEYMAT requested for each AES-CCM key are each 19 octets. > The first 16 octets are the 128-bit AES key, and the > remaining three octets are used as the salt value in the > counter block. > > AES-CCM with a 192 bit key > KEYMAT requested for each AES-CCM key are each 27 octets. > The first 24 octets are the 192-bit AES key, and the > remaining three octets are used as the salt value in the > counter block. > > AES-CCM with a 256 bit key > KEYMAT requested for each AES-CCM key are each 35 octets. > The first 32 octets are the 256-bit AES key, and the > remaining three octets are used as the salt value in the > counter block. >---------------------------------------------------------------------- > >Also the draft-ietf-ipsec-ciph-aes-ccm-03.txt is missing section "8. >Test Vectors"... >-- >kivinen@ssh.fi >SSH Communications Security http://www.ssh.fi/ >SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Sat Jul 12 10:11:46 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6CHBkqt002342; Sat, 12 Jul 2003 10:11:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13657 Sat, 12 Jul 2003 12:18:36 -0400 (EDT) Message-Id: <5.2.0.9.2.20030711170733.03945ce8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 11 Jul 2003 17:08:35 -0400 To: Tero Kivinen , ipsec@lists.tislabs.com From: Russ Housley Subject: Re: Comments to draft-ietf-ipsec-ciph-aes-ctr-04.txt In-Reply-To: <16119.5371.22150.897999@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tero: Good catch. I made the changes, and I will post the updated draft as soon as the repository opens after the Vienna IETF. Russ At 05:55 PM 6/23/2003 +0300, Tero Kivinen wrote: >The document draft-ietf-ipsec-ciph-aes-ctr-04 talks about generating >keying material in section 5.1, which only is valid to IKEv2 and Phase >1 SA creation. This should be change to apply to both IKEv1 and IKEv2 >keying material generation. > >The current text: >---------------------------------------------------------------------- >5.1. Keying Material and Nonces > > As described in section 2.1, implementations MUST use fresh keys > with AES-CTR. IKE can be used to establish fresh keys. This section > describes the conventions for obtaining the unpredictable nonce > value from IKE. Note that this convention provides a nonce value > that is secret as well as unpredictable. > > IKE makes use of a pseudo-random function (PRF) to derive keying > material. The PRF is used iteratively to derive keying material of > arbitrary size. Keying material is extracted from the output string > without regard to boundaries. > > IKE uses the PRF to generate an output stream that parsed into five > keys: SK_d, SK_ai, SK_ar, SK_ei, and SK_er. SK_d is used to derive > new keys for the child security associations. SK_ai and SK_ar are > the authentication keys for the initiator and the responder, > respectively. SK_ei and SK_er are the encryption keys for the > initiator and the responder, respectively. > > SK_ai and SK_ei are used to protect traffic from the initiator to > the responder. SK_ar and SK_er are used to protect traffic from the > responder to the initiator. > > The size of SK_ei and SK_er are each four octets longer than is > needed by the associated AES key. The keying material is used as > follows: > > AES-CTR with a 128 bit key > SK_ei and SK_er are each 20 octets. The first 16 octets are > the 128-bit AES key, and the remaining four octets are used > as the nonce value in the counter block. > > AES-CTR with a 192 bit key > SK_ei and SK_er are each 28 octets. The first 24 octets are > the 192-bit AES key, and the remaining four octets are used > as the nonce value in the counter block. > > AES-CTR with a 256 bit key > SK_ei and SK_er are each 36 octets. The first 32 octets are > the 256-bit AES key, and the remaining four octets are used > as the nonce value in the counter block. >---------------------------------------------------------------------- > >The SK_ai, SK_ar, SK_ei, SK_er are only used in the IKEv2 SA packet >encryption and authentication. The IPsec keys are generated from the >KEYMAT generated from the SK_d. I.e the IKEv2 draft says: > >---------------------------------------------------------------------- > For CREATE_CHILD_SA exchanges with PFS the keying material is > defined as: > > KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) ... >---------------------------------------------------------------------- > >and the IKEv1 RFC 2409 says: > >---------------------------------------------------------------------- > If PFS is not needed, and KE payloads are not exchanged, the new > keying material is defined as > > KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b). > > If PFS is desired and KE payloads were exchanged, the new keying > material is defined as > > KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b) >... >---------------------------------------------------------------------- > >They both define how to expand the KEYMAT if needed. > >So the proposed replacement text is: >---------------------------------------------------------------------- >5.1. Keying Material and Nonces > > As described in section 2.1, implementations MUST use fresh keys > with AES-CTR. IKE can be used to establish fresh keys. This section > describes the conventions for obtaining the unpredictable nonce > value from IKE. Note that this convention provides a nonce value > that is secret as well as unpredictable. > > IKE makes use of a pseudo-random function (PRF) to derive keying > material. The PRF is used iteratively to derive keying material > KEYMAT of arbitrary size. Keying material is extracted from the > output string without regard to boundaries. > > The size of KEYMAT requested is four octets longer than is needed > by the associated AES key. The keying material is used as follows: > > AES-CTR with a 128 bit key > KEYMAT requested for each AES-CTR key are each 20 octets. The > first 16 octets are the 128-bit AES key, and the remaining > four octets are used as the nonce value in the counter block. > > AES-CTR with a 192 bit key > KEYMAT requested for each AES-CTR key are each 28 octets. The > first 24 octets are the 192-bit AES key, and the remaining > four octets are used as the nonce value in the counter block. > > AES-CTR with a 256 bit key > KEYMAT requested for each AES-CTR key are each 36 octets. The > first 32 octets are the 256-bit AES key, and the remaining > four octets are used as the nonce value in the counter block. >---------------------------------------------------------------------- > >The wording is like that, because in the IKEv1 the KEYMAT is generated >for each SPI separetely, i.e inbound/outbound etc AH/ESP have separete >KEYMAT. For the IKEv2 the keying material is generated from one call >to the KEYMAT. >-- >kivinen@ssh.fi >SSH Communications Security http://www.ssh.fi/ >SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jul 14 02:43:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E9hQqt056018; Mon, 14 Jul 2003 02:43:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA21194 Mon, 14 Jul 2003 04:55:08 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA87E67017@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "'Ravi '" , "'Mittal Harshwardhan-A18990 '" Cc: "'ipsec@lists.tislabs.com '" Subject: RE: Securid authentication for IKE client Date: Mon, 14 Jul 2003 02:00:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Make sure to define your policy for Xauth support. Xauth is the only way to get the securID info passed to the gateway. Also, any gateway you use MUST have specific support for ACE server features within the Xauth exchange in order to work as customers want. "Ace advanced features" are things like new-pin or next-key, which are ACE proprietary equivalents to RADIUS access-challenge. Gregory. -----Original Message----- From: Ravi To: Mittal Harshwardhan-A18990 Cc: ipsec@lists.tislabs.com Sent: 7/9/03 9:20 PM Subject: Re: Securid authentication for IKE client Hi, I am not sure whether CISCO5000 supports this or not. But, you should have X-Auth support for this to work. Also, make sure that X-Auth implementation supports RSA SecureID transactions by both VPN client and CISCO 5000 servers. Regards Ravi Mittal Harshwardhan-A18990 wrote: > Hi all, > > I am currently working on a VPN client and wants to get the client authenticated using RSA Securid ACE card. > I have all required information ( userid, passcode, acecard value). > > IKE phase 1 is complete with some default group-id and password. > > I am using Cisco 5000 series concentrator as a server which is not under my conrol, > but I have my ace-card and laptop (windows and linux) client (provided by Cisco) configured for the server, > and I am able to estblish VPN session both from linux and windows. > > My question is what is the packet format in which I can send my ace-card credentials to the cisco server > to get my client authenticated. > What is the protocol, I think Cisco client is sending this info in form of IKE informational exchange. > but as the packet is encrypted using ISAKMPD SA I am unable to find out the packet format. > > thanks in anticipation > > Regards, > Harsh > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Mon Jul 14 12:48:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EJmaqt098673; Mon, 14 Jul 2003 12:48:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23231 Mon, 14 Jul 2003 15:07:59 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA8701EA9326@SARATOGA.netscreen.com> From: Gregory Lebovitz To: Yoav Nir , "'Tschofenig Hannes'" , "'Yoshihiro Ohba'" , "'Barbara Fraser'" Cc: ipsec@lists.tislabs.com, tytso@mit.edu, angelos@cs.columbia.edu, "'Tero Kivinen'" Subject: RE: Issue 9: Identity Protection Closed Date: Mon, 14 Jul 2003 12:13:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I also agree to the proposed text changes. Our v1 solutions can currently use IDs that represent groups, and differentiate users by actual CP interaction to back-end AAA servers. this makes device config much easier on admins. I know several other vendors who do the same, so such a case must be permissable. Gregory. > -----Original Message----- > From: Yoav Nir [mailto:ynir@CheckPoint.com] > Sent: Thursday, July 03, 2003 2:49 AM > To: 'Tschofenig Hannes'; 'Yoshihiro Ohba'; 'Barbara Fraser' > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; angelos@cs.columbia.edu; > 'Tero Kivinen' > Subject: RE: Issue 9: Identity Protection Closed > > > I agree. This should either be omitted or else rephrased: > > "Note that if IKE passes an indication of initiator identity > in message 3 of > the protocol, EAP based prompts for Identity MAY be omitted." > > Can we agree on this phrasing? > > -----Original Message----- > From: Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, July 03, 2003 10:45 AM > To: 'Yoav Nir'; 'Yoshihiro Ohba'; 'Barbara Fraser' > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; angelos@cs.columbia.edu; > 'Tero Kivinen' > Subject: RE: Issue 9: Identity Protection Closed > > > hi yoav, > > i initially requested to drop the following sentence from > section 3.16 of > ikev2-v8: > > "Note that since IKE passes an indication of initiator > identity in message 3 > of the protocol, EAP based prompts for Identity SHOULD NOT be used." > > if you allow to eap as it is (with the eap identity exchange) then > everything is fine. to me it seems that the SHOULD NOT > prevents you from > performing an eap identity exchange and you have to use the identity > provided with message (3) from the initiator. > > ciao > hannes > > > > -----Original Message----- > > From: Yoav Nir [mailto:ynir@CheckPoint.com] > > Sent: Thursday, July 03, 2003 8:48 AM > > To: 'Yoshihiro Ohba'; 'Barbara Fraser' > > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; angelos@cs.columbia.edu; > > 'Tero Kivinen' > > Subject: RE: Issue 9: Identity Protection Closed > > > > > > It is possible to have some convention, like sending an empty > > ID_KEY_ID from > > the client, or even adding a new ID type ID_ANON_USER. In > > this case, the > > gateway will do a full EAP, including the EAP-Identity > > request/response. If > > the user sends its ID in some other form, the gateway will > > only do the short > > version of EAP (less two packets). > > > > This will give users a trade-off between speed and identity > > protection, and > > it does not require a change to the IKEv2 draft. > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > > [mailto:owner-ipsec@lists.tislabs.com]On > > Behalf Of Yoshihiro Ohba > > Sent: Wednesday, July 02, 2003 11:21 PM > > To: Barbara Fraser > > Cc: ipsec@lists.tislabs.com; tytso@mit.edu; > > angelos@cs.columbia.edu; Tero > > Kivinen > > Subject: Re: Issue 9: Identity Protection Closed > > > > > > Hi, > > > > I'm working mainly in PANA WG and EAP WG and I recently joined this > > list. Please allow me to send this email after only rough > reading of > > the thread on this issue. > > > > First of all, I agree that there is no need to change IKEv2 protocol > > behavior to support identity protection from active attacks. > > > > One way to address this is to use an anononymous identifier in IKEv2 > > ID payload sent by initiator and use a real identifier in an > > EAP-Identity exchange (or an identity exchange that may be > defined in > > a particular EAP authentication method in IKE_AUTH exchange). > > > > If fact, a similar approach already exists. For example, some > > EAP-TTLS implementation allows an EAP peer to use an anonymous > > identity (e.g, anonymous@foo.bar.com) in the EAP-Identity > > request/response carried outside the TLS tunnel, and use a real > > identity (realname@foo.bar.com) in the EAP-Identity request/response > > performed inside the TLS tunnel. > > > > On the other hand, the following sentence in section 3.16 of the > > ikev2-08 draft seems to be a bit restrictive (if the above > solution is > > valid) > > > > "Note that since IKE passes an indication of initiator > identity in > > message 3 of the protocol, EAP based prompts for Identity > > SHOULD NOT > > be used." > > > > So, I'd like to suggest either removing the sentense or revising the > > sentense to: > > > > "Note that since IKE passes an indication of initiator > identity in > > message 3 of the protocol, EAP based prompts for Identity > > SHOULD NOT > > be used if the initiator identity passed from IKE is used as the > > EAP peer identity." > > > > > > Regards, > > Yoshihiro Ohba > > > > > > > > On Wed, Jul 02, 2003 at 10:58:07AM -0700, Barbara Fraser wrote: > > > Hi folks, > > > > > > Ted and I would like to officially state that the issue of > > addressing > > > identity protection against active attacks is not going to > > be included in > > > the base IKEv2 document. This decision was made months ago. > > There are ways > > > to address this outside the IKEv2 base specification, > > should folks want to > > > start up a new working group. > > > > > > Thanks, > > > Barb and Ted > > > From owner-ipsec@lists.tislabs.com Mon Jul 14 12:48:37 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EJmaqt098672; Mon, 14 Jul 2003 12:48:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA23226 Mon, 14 Jul 2003 15:07:41 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA8701EA9325@SARATOGA.netscreen.com> From: Gregory Lebovitz To: Francis Dupont , Charlie_Kaufman@notesdev.ibm.com Cc: ipsec mailingList Subject: RE: Q: EAP Message Format Date: Mon, 14 Jul 2003 12:13:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk so, Francis and Charlie, will your suggested change to the text be made in the -09? > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Wednesday, July 09, 2003 1:13 AM > To: Ricky Charlet > Cc: ipsec mailingList > Subject: Re: Q: EAP Message Format > > > In your previous mail you wrote: > > So, as currently specified in draft-08, the length > field of the EAP > message format may be either 2 or 4 bytes depending upon the type. > > => no, the text in the draft is buggy but is simpler than > your proposal. > Current text is: > > o Type (one octet) is present only if the Code field is Request > (1) or Response (2). For other types, the EAP message length > MUST be four octets and the Type and Type_Data fields MUST NOT > be present. ... > > The fixed text should be: > > o Type (one octet) is present only if the Code field is Request > (1) or Response (2). For other codes, the EAP message length > ^^^^^ > MUST be four octets and the Type and Type_Data fields MUST NOT > be present. ... > > So if the code is not Request or Response the length field > *value* is 4 > and there is nothing after the length field. > > Regards > > Francis.Dupont@enst-bretagne.fr > From owner-ipsec@lists.tislabs.com Mon Jul 14 14:20:19 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ELKJqt003892; Mon, 14 Jul 2003 14:20:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA23594 Mon, 14 Jul 2003 16:41:58 -0400 (EDT) Message-Id: <200307142046.h6EKkxof039625@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Gregory Lebovitz cc: Charlie_Kaufman@notesdev.ibm.com, ipsec mailingList Subject: Re: Q: EAP Message Format In-reply-to: Your message of Mon, 14 Jul 2003 12:13:41 PDT. <541402FFDC56DA499E7E13329ABFEA8701EA9325@SARATOGA.netscreen.com> Date: Mon, 14 Jul 2003 22:46:59 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: o Type (one octet) is present only if the Code field is Request (1) or Response (2). For other types, the EAP message length => please change "types" for "codes". MUST be four octets and the Type and Type_Data fields MUST NOT be present. ... => IMHO it is not necessary to add that the message length is the value of the length field and not its length. If we'd like to add something in the document or its companion, I suggest more an example. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Jul 15 02:14:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F9Efqt052602; Tue, 15 Jul 2003 02:14:41 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA26020 Tue, 15 Jul 2003 04:38:25 -0400 (EDT) To: Arun Kumar cc: ipsec@lists.tislabs.com Subject: Re: interoperability issue with 'lifekbytes' In-reply-to: Your message of "Tue, 01 Jul 2003 12:08:14 PDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 15 Jul 2003 10:45:08 +0200 Message-ID: <4805.1058258708@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Arun" == Arun Kumar writes: Arun> We are frequently encountering interoperability problems Arun> with 'lifekbytes' configuration. Different vendors accept/implement Arun> different ways. Having consistent method mentioned in the Arun> standards will help eliminating/reducing the mis-interpretation. Arun> Any feedback on following interoperability issue from WG Arun> is appreciated. Arun> Security Gateway1--------------------Security Gateway2 Arun> Admin at SG1 configured the IPSEC security policy Arun> indicating that 'lifekbytes' is not expected. Arun> SG2 sends QM SA payload with lifekbytes attribute with some Arun> value. Should SG1 accept the SA payload OR should it deny Arun> the SA payload. The general feeling is that lifetime values are advice only. SG2 doesn't like what SG1 proposes (usually, a value too large), then it should just rekey the SA more often. The advice only tells SG2 how long it ought to keep the keys around, when the channel is otherwise idle. Arun> We feel that, since local admin made a choice that lifekbytes Arun> is not required/expected, it should deny the SA negotiation. I do not think that a lifekbytes of zero should be sent, but if received, it should be essentially ignored. It is meaningless. It should be ignored, since at most, it was advice only. Arun> What is the right thing to do? Also, we feel that by having Arun> consistent configuration on both ends will eliminate the Arun> confusion. No, you can not assume *identical* configuration. a) this is why we have a protocol that has multiple options. b) this is often hard when multiple products are involved - they may have compatible options, but not identical, and may not all offer the same knobs - or worse - they do, but name them differently. Hey, $LANG=en vs $LANG=cn would be enough to confuse the admins enough such that they can't even find the options! c) okay, so you get the configuration identical with great effort. Now you want to change it. Do you turn off the entire enterprise VPN, fly someone around the world to reconfigure everything and then turn it back on? clearly, not. So, you must deal with changes to the configuration as you evolve your settings, slowly. Arun> Related question: Arun> What happens when SG1 starts the quick mode? Arun> Should SG2 deny the negotiation as it expected lifekbytes Arun> attribute, but there is no 'lifekbytes' attribute coming from SG1? No. Arun> We feel that, for both cases to work, it is better to have Arun> same configuration on both ends so that it works consistently Arun> and give choice to the administrators. Arun> Thanks in advance, Arun> Arun ] At IETF57 in Wien, Austria | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPxO/EoqHRg3pndX9AQF4xgQAraGF0R4rEejqH/w4BxY9zcdlJbX6jw6D Tyn0H+NFhsexz0uuyqo//k9bWndPA73OxO91nRECzKunZBMZaKJOimCfO/OaagKM gHn63NsEZpR8eW7T1eO6d+JpZC6hnmzhesxGjJ6RZnNgOd0ybSCGfCSOoWI4CaqE P0Aome2JPAQ= =0bfo -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jul 15 02:17:46 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F9Hjqt053081; Tue, 15 Jul 2003 02:17:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA26059 Tue, 15 Jul 2003 04:46:11 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 15 Jul 2003 10:53:16 +0200 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: IPsec Bar BOF in Vienna, Wednesday during dinnertime Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. Some of the VPN developers in Vienna wanted to get together to talk about the remaining steps in the IPsec WG. There are some points in IKEv2 and the last IKEv1 documents that IPsec developers with real customers probably want to hash out, although all IPsec folks are of course welcome. We'll gather 1745 in the large sitting area on the entrance level opposite from the entrance doors. (Walk from the IETF registration area straight past the terminal room a little further.) The gathering will probably be about an hour, so we'll finish before the IAB Open Plenary. There won't be food or drink, but there should be enough time before and after the Bar BOF to get a sandwich from the coffee bar in the registration area. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jul 16 03:20:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GAKvqt063087; Wed, 16 Jul 2003 03:20:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA00874 Wed, 16 Jul 2003 05:30:32 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA8701EA94CF@SARATOGA.netscreen.com> From: Gregory Lebovitz To: Michael Richardson , Arun Kumar Cc: ipsec@lists.tislabs.com Subject: RE: interoperability issue with 'lifekbytes' Date: Wed, 16 Jul 2003 02:36:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >>>>> "Arun" == Arun Kumar writes: > Arun> We are frequently encountering interoperability problems > Arun> with 'lifekbytes' configuration. Different > vendors accept/implement > Arun> different ways. Having consistent method mentioned in the > Arun> standards will help eliminating/reducing the > mis-interpretation. > Arun> Any feedback on following interoperability issue from WG > Arun> is appreciated. > > Arun> Security Gateway1--------------------Security Gateway2 > > Arun> Admin at SG1 configured the IPSEC security policy > Arun> indicating that 'lifekbytes' is not expected. > Arun> SG2 sends QM SA payload with lifekbytes attribute > with some Let me ask a question in your example: was lifetime expected, but instead lifekbytes received? Is this what you mean? Or is it more convoluted than that? > Arun> value. Should SG1 accept the SA payload OR should it deny > Arun> the SA payload. > > The general feeling is that lifetime values are advice only. > > SG2 doesn't like what SG1 proposes (usually, a value too > large), then > it should just rekey the SA more often. The advice only tells > SG2 how long > it ought to keep the keys around, when the channel is otherwise idle. > > Arun> We feel that, since local admin made a choice > that lifekbytes > Arun> is not required/expected, it should deny the SA > negotiation. > > I do not think that a lifekbytes of zero should be sent, > but if received, > it should be essentially ignored. It is meaningless. It > should be ignored, > since at most, it was advice only. I would have interpreted it as "I don't care," or "you rekey when you want to; I won't be initiating a rekey with you". But I would say that we should explicitly specify IF zero may be sent, and if so, what it means / how receiver interprets it. Just as a strawman, I would propose the following text: Zero is a valid proposal, and means the sender will not be initiating a rekey, but will instead rely on the receiver to initiate the rekey at their desired interval. > Arun> What is the right thing to do? Also, we feel that > by having > Arun> consistent configuration on both ends will eliminate the > Arun> confusion. > > No, you can not assume *identical* configuration. > a) this is why we have a protocol that has multiple options. > > b) this is often hard when multiple products are involved - > they may > have compatible options, but not identical, and may not all offer > the same knobs - or worse - they do, but name them differently. - and worse yet - they do and interpret/handle them differently. This is why I keep harshing on explicit specification whenever possible, hoping to avoid the painful interop marathon we are STILL having in v1. > Hey, $LANG=en vs $LANG=cn would be enough to confuse the admins > enough such that they can't even find the options! > > c) okay, so you get the configuration identical with great effort. > Now you want to change it. > Do you turn off the entire enterprise VPN, fly someone around the > world to reconfigure everything and then turn it back on? > clearly, not. > So, you must deal with changes to the configuration as you evolve > your settings, slowly. > > Arun> Related question: > Arun> What happens when SG1 starts the quick mode? > Arun> Should SG2 deny the negotiation as it expected lifekbytes > Arun> attribute, but there is no 'lifekbytes' attribute > coming from SG1? > > No. to clarify, for better interop, if your peer initiates rekey before you expected it, go with it. Gregory. From owner-ipsec@lists.tislabs.com Wed Jul 16 10:33:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GHXKqt094153; Wed, 16 Jul 2003 10:33:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02585 Wed, 16 Jul 2003 12:51:15 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: To: "George Hadjichristofi" Cc: "Ipsec" Subject: Re: IKE key question MIME-Version: 1.0 X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Mon, 14 Jul 2003 16:10:47 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 07/14/2003 04:06:31 PM, Serialize complete at 07/14/2003 04:06:31 PM Content-Type: multipart/alternative; boundary="=_alternative 003F75FF85256D63_=" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 003F75FF85256D63_= Content-Type: text/plain; charset="US-ASCII" "George Hadjichristofi" Hi, > > I have a few questions with regards to the usage of keys. > > After an IKE negotiation, what key is used to encrypt data between two > communicating entities? > > Is it the SKEYID_e key derived during the IKE negotiation or is it the > shared/public key? SKEYID_e is used to encrypt subsequent data that is encoded using IKE. Data encoded using ESP is encrypted using a key derived from SKEYID_d and data from the quick mode exchange. The long term shared/public keys are only used with a small amount of data at the beginning of the IKE negotiation. --Charlie Kaufman --=_alternative 003F75FF85256D63_= Content-Type: text/html; charset="US-ASCII"

"George Hadjichristofi" <ghadjich@vt.edu  wrote on 07/09/2003 07:35:37 PM:
> Hi,
>
> I have a few questions with regards to the usage of keys.
>
> After an IKE negotiation, what key is used to encrypt data between two
> communicating entities?
>
> Is it the SKEYID_e key derived during the IKE negotiation or is it the
> shared/public key?

SKEYID_e is used to encrypt subsequent data that is encoded using IKE.
Data encoded using ESP is encrypted using a key derived from SKEYID_d and
data from the quick mode exchange. The long term shared/public keys are
only used with a small amount of data at the beginning of the IKE
negotiation.

        --Charlie Kaufman
 
--=_alternative 003F75FF85256D63_=-- From owner-ipsec@lists.tislabs.com Wed Jul 16 10:48:13 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GHmCqt095346; Wed, 16 Jul 2003 10:48:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02636 Wed, 16 Jul 2003 13:14:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Wed, 16 Jul 2003 11:28:59 -0400 To: ipsec@lists.tislabs.com From: Karen Seo Subject: Fwd: IPsec ESN addendum -- Last Call revisions Content-Type: multipart/alternative; boundary="============_-1153753156==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1153753156==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >X-Sender: kseo@po2.bbn.com >Date: Tue, 15 Jul 2003 18:45:19 -0400 >To: "Angelos D. Keromytis" >From: Karen Seo >Subject: IPsec ESN addendum -- Last Call revisions >Cc: Barbara Fraser , tytso@mit.edu, skent@bbn.com, > clynn@bbn.com, kseo@bbn.com >X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) >Status: > >Angelos, > >Here are the comments and their status for the ESN addendum .... >Revisions have been made to address the comments and the changes >have been approved by the commenter. These cover all the tickets >for the ESN addendum. > >Should I go ahead and submit the revised draft to the IETF? > >Karen > >=============================================================================== > >Commenter: Russ Housley >Date: 6/12/03 and 7/9/03 >Status: I believe that since we've made the change Russ > requested on 7/9/03 to remove the sentence that > referred the reader to AH/ESP, that this has been > approved by Russ on 7/9/03 > >>I propose an alternative Abstract. >> >> The IP Security Authentication Header (AH) and Encapsulating >> Security Payload (ESP) protocols use a sequence number >> to detect replay. This document describes extensions to the >> Internet IP Security Domain of Interpretation (DOI) for >> Internet Security Association and Key Management Protocol >> (ISAKMP) to negotiate the use of traditional 32-bit sequence >> numbers or extended 64-bit sequence numbers for a >> particular AH or ESP security association. > > We proposed the above paragraph and left in a sentence > that referred the reader to AH and ESP for a description of > ESN. Russ replied on 7/9/03: > >>I do not think you can have references in the Abstract. I suggest >>dropping the final sentence. > > So we've changed the abstract as follows: > > From: > This document describes extensions to the Internet IP Security > Domain of Interpretation for ISAKMP [DOI] that are needed to > support negotiation of whether or not a Security Association > will use Extended (64-bit) Sequence Numbers. (See [AH] and > [ESP] for a description of Extended Sequence Numbers.) > > To: > The IP Security Authentication Header (AH) and Encapsulating > Security Payload (ESP) protocols use a sequence number to > detect replay. This document describes extensions to the > Internet IP Security Domain of Interpretation (DOI) for the > Internet Security Association and Key Management Protocol > (ISAKMP). These extensions support negotiation of the use of > traditional 32-bit sequence numbers or extended 64-bit sequence > numbers for a particular AH or ESP security association. > >=============================================================================== > >Commenter: Russ Housley and David Black >Date: 6/12/03 and 7/9/03 >Status: change approved by Russ on 7/9/03 > >[Russ Housley 6/12/03 > >>It would be helpful if the IANA Considerations section indicated >>the portion of the registry where the TBD value needs to be >>assigned. > >[David Black 6/16/03 > >>In draft-ietf-ipsec-esn-addendum-01.txt, the IANA >>Considerations section needs to be replaced by text >>asking IANA to allocate an "IPSEC Security Association >>Attributes" value and using that number to replace >>the TBD under the "value" heading in Section 2. It >>may be necessary to include text in the IANA >>Considerations section saying that this value "is >>assigned by the standards action of this RFC" or >>something like that. > > > We've changed the IANA Considerations section: > > From: > This document contains "magic" numbers to be > maintained by the IANA. No additional values will be > assigned. > > To: > > This document contains a "magic" number to be maintained by > the IANA. No additional class values will be assigned for > this attribute. Upon approval of this draft for publication > as an RFC, IANA is to allocate an IPsec Security Attribute > value for "Attribute Type". This value is to replace the TBD > under the heading "value" in the table in Section 2. > >=============================================================================== --============_-1153753156==_ma============ Content-Type: text/html; charset="us-ascii" Fwd: IPsec ESN addendum -- Last Call revisions
X-Sender: kseo@po2.bbn.com
Date: Tue, 15 Jul 2003 18:45:19 -0400
To: "Angelos D. Keromytis" <angelos@cs.columbia.edu>
From: Karen Seo <kseo@bbn.com>
Subject: IPsec ESN addendum -- Last Call revisions
Cc: Barbara Fraser <byfraser@cisco.com>, tytso@mit.edu, skent@bbn.com,
   clynn@bbn.com, kseo@bbn.com
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Status:  
Angelos,

Here are the comments and their status for the ESN addendum ....  Revisions have been made to address the comments and the changes have been approved by the commenter.  These cover all the tickets for the ESN addendum.

Should I go ahead and submit the revised draft to the IETF?

Karen

===============================================================================

Commenter:      Russ Housley
Date:           6/12/03 and 7/9/03
Status:         I believe that since we've made the change Russ
                requested on 7/9/03 to remove the sentence that
                referred the reader to AH/ESP, that this has been
                approved by Russ on 7/9/03

I propose an alternative Abstract.

   The IP Security Authentication Header (AH) and Encapsulating
   Security Payload (ESP) protocols use a sequence number
   to detect replay.  This document describes extensions to the
   Internet IP Security Domain of Interpretation (DOI) for
   Internet Security Association and Key Management Protocol
   (ISAKMP) to negotiate the use of traditional 32-bit sequence
   numbers or extended 64-bit sequence numbers for a
   particular AH or ESP security association.

        We proposed the above paragraph and left in a sentence
        that referred the reader to AH and ESP for a description of
        ESN.  Russ replied on 7/9/03:

I do not think you can have references in the Abstract.  I suggest dropping the final sentence.

   So we've changed the abstract as follows:

  From:
        This document describes extensions to the Internet IP Security
        Domain of Interpretation for ISAKMP [DOI] that are needed to
        support negotiation of whether or not a Security Association
        will use Extended (64-bit) Sequence Numbers. (See [AH] and
        [ESP] for a description of Extended Sequence Numbers.)

   To:
        The IP Security Authentication Header (AH) and Encapsulating
        Security Payload (ESP) protocols use a sequence number to
        detect replay.  This document describes extensions to the
        Internet IP Security Domain of Interpretation (DOI) for the
        Internet Security Association and Key Management Protocol
        (ISAKMP).  These extensions support negotiation of the use of
        traditional 32-bit sequence numbers or extended 64-bit sequence
        numbers for a particular AH or ESP security association.

===============================================================================

Commenter:      Russ Housley and David Black
Date:           6/12/03 and 7/9/03
Status:         change approved by Russ on 7/9/03

[Russ Housley 6/12/03

It would be helpful if the IANA Considerations section indicated the portion of the registry where the TBD value needs to be assigned.

[David Black 6/16/03

In draft-ietf-ipsec-esn-addendum-01.txt, the IANA
Considerations section needs to be replaced by text
asking IANA to allocate an "IPSEC Security Association
Attributes" value and using that number to replace
the TBD under the "value" heading in Section 2.  It
may be necessary to include text in the IANA
Considerations section saying that this value "is
assigned by the standards action of this RFC" or
something like that.


   We've changed the IANA Considerations section:

   From:
        This document contains "magic" numbers to be
        maintained by the IANA. No additional values will be
        assigned.

   To:
       
        This document contains a "magic" number to be maintained by
        the IANA.  No additional class values will be assigned for
        this attribute.  Upon approval of this draft for publication
        as an RFC, IANA is to allocate an IPsec Security Attribute
        value for "Attribute Type".  This value is to replace the TBD
        under the heading "value" in the table in Section 2.

===============================================================================

--============_-1153753156==_ma============-- From owner-ipsec@lists.tislabs.com Wed Jul 16 10:48:44 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GHmhqt095415; Wed, 16 Jul 2003 10:48:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02642 Wed, 16 Jul 2003 13:14:45 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Wed, 16 Jul 2003 11:29:02 -0400 To: ipsec@lists.tislabs.com From: Karen Seo Subject: Fwd: Re: IPsec ESP-bis -- Last Call revisions Content-Type: multipart/alternative; boundary="============_-1153753153==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1153753153==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >X-Sender: kseo@po2.bbn.com >Date: Wed, 16 Jul 2003 11:20:44 -0400 >To: "Angelos D. Keromytis" >From: Karen Seo >Subject: Re: IPsec ESP-bis -- Last Call revisions >Cc: Barbara Fraser , tytso@mit.edu, skent@bbn.com, > clynn@bbn.com, kseo@bbn.com >X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) >Status: > >Angelos, > >Russ Housley just approved items 13, 14 (see below) > >Should I submit the draft to the IETF? > >Karen > > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 and 7/15/03 >Status: approved by Russ on 7/16 > >>13. I am confused by "DISCUSSION" in section 3.4.4.1. > > We asked for clarification on 7/4/03 and received the feedback > below: > >>It says: >> >> DISCUSSION: >> >> Begin by removing and saving the ICV field. Next check the >> overall length of the ESP packet minus the ICV field. If >> implicit padding is required, based on the blocksize of the >> integrity algorithm, append zero-filled bytes to the end of >> the ESP packet directly after the Next Header >> field. Perform the ICV computation and compare the result >> with the saved value, using the comparison rules defined by >> the algorithm specification. >> >>My issue is that there is no context provided. >> >>I think this would be better structured as an Implementation Note. Like: >> >> Implementation Note: Implementations can use any set of steps >> that results in the same result as the following set of steps. Begin >> by ... >> > > Changed to: > > Implementation Note: > > Implementations can use any set of steps that results in the > same result as the following set of steps. Begin by removing > and saving the ICV field. Next check the overall length of the > ESP packet minus the ICV field. If implicit padding is > required, based on the blocksize of the integrity algorithm, > append zero-filled bytes to the end of the ESP packet directly > after the Next Header field. Perform the ICV computation and > compare the result with the saved value, using the comparison > rules defined by the algorithm specification. > >=============================================================================== > >Commenter: Russ Housley >Date: 6/17/03 >Status: approved by Russ on 7/16 > >>14. The references need to be divided in to normative and informative. > > We changed the References to: > > References > > > Normative > > [Bra97] Bradner, S., "Key words for use in RFCs to > Indicate Requirement Level", BCP 14, RFC 2119, March > 1997. > > [KA98] Kent, S., and R. Atkinson, "Security > Architecture for the Internet Protocol", RFC 2401, > November 1998. > > Informative > > [Bel96] Steven M. Bellovin, "Problem Areas for the IP > Security Protocols", Proceedings of the Sixth Usenix > Unix Security Symposium, July, 1996. > > [HC03] Holbrook, H., and Cain, B., "Source Specific > Multicast for IP", Internet Draft, > draft-ietf-ssm-arch-01.txt, November 3, 2002. > > [HC98] Harkins, D., and D. Carrel, "The Internet Key > Exchange (IKE)", RFC 2409, November 1998. > > [Ken03] Kent, S., "IP Authentication Header", RFC ???, > ??? 2003. > > [Kra01] Krawczyk, H., "The Order of Encryption and > Authentication for Protecting Communications (Or: How > Secure Is SSL?)", CRYPTO' 2001. > >=============================================================================== --============_-1153753153==_ma============ Content-Type: text/html; charset="us-ascii" Fwd: Re: IPsec ESP-bis -- Last Call revisions
X-Sender: kseo@po2.bbn.com
Date: Wed, 16 Jul 2003 11:20:44 -0400
To: "Angelos D. Keromytis" <angelos@cs.columbia.edu>
From: Karen Seo <kseo@bbn.com>
Subject: Re: IPsec ESP-bis -- Last Call revisions
Cc: Barbara Fraser <byfraser@cisco.com>, tytso@mit.edu, skent@bbn.com,
   clynn@bbn.com, kseo@bbn.com
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Status:  
Angelos,

Russ Housley just approved items 13, 14 (see below)

Should I submit the draft to the IETF?

Karen


===============================================================================

Commenter:      Russ Housley
Date:           6/16/03 and 7/15/03
Status:         approved by Russ on 7/16

13. I am confused by "DISCUSSION" in section 3.4.4.1.

        We asked for clarification on 7/4/03 and received the feedback
        below:

It says:

               DISCUSSION:

               Begin by removing and saving the ICV field. Next check the
               overall length of the ESP packet minus the ICV field. If
               implicit padding is required, based on the blocksize of the
               integrity algorithm, append zero-filled bytes to the end of
               the ESP packet directly after the Next Header
               field. Perform the ICV computation and compare the result
               with the saved value, using the comparison rules defined by
               the algorithm specification.

My issue is that there is no context provided.

I think this would be better structured as an Implementation Note.  Like:

        Implementation Note:  Implementations can use any set of steps
        that results in the same result as the following set of steps.  Begin
        by ...

   Changed to:

        Implementation Note:

    Implementations can use any set of steps that results in the
    same result as the following set of steps.  Begin by removing
   and saving the ICV field. Next check the overall length of the
  ESP packet minus the ICV field. If implicit padding is
        required, based on the blocksize of the integrity algorithm,
      append zero-filled bytes to the end of the ESP packet directly
  after the Next Header field. Perform the ICV computation and
    compare the result with the saved value, using the comparison
   rules defined by the algorithm specification.

===============================================================================

Commenter:      Russ Housley
Date:           6/17/03
Status:         approved by Russ on 7/16

14.  The references need to be divided in to normative and informative.

        We changed the References to:

   References

   Normative
        [Bra97] Bradner, S., "Key words for use in RFCs to
        Indicate Requirement Level", BCP 14, RFC 2119, March
        1997.

        [KA98] Kent, S., and R. Atkinson, "Security
        Architecture for the Internet Protocol", RFC 2401,
        November 1998.
    Informative
        [Bel96] Steven M. Bellovin, "Problem Areas for the IP
        Security Protocols", Proceedings of the Sixth Usenix
        Unix Security Symposium, July, 1996.
        [HC03]  Holbrook, H., and Cain, B., "Source Specific
        Multicast for IP", Internet Draft,
        draft-ietf-ssm-arch-01.txt, November 3, 2002.

        [HC98] Harkins, D., and D. Carrel, "The Internet Key
        Exchange (IKE)", RFC 2409, November 1998.
        [Ken03] Kent, S., "IP Authentication Header", RFC ???,
        ??? 2003.

        [Kra01] Krawczyk, H., "The Order of Encryption and
        Authentication for Protecting Communications (Or: How
        Secure Is SSL?)", CRYPTO' 2001.

===============================================================================

--============_-1153753153==_ma============-- From owner-ipsec@lists.tislabs.com Wed Jul 16 10:49:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GHnnqt095504; Wed, 16 Jul 2003 10:49:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02630 Wed, 16 Jul 2003 13:12:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Wed, 16 Jul 2003 11:28:51 -0400 To: ipsec@lists.tislabs.com From: Karen Seo Subject: Fwd: IPsec AH-bis-- Last Call revisions Cc: kseo@bbn.com Content-Type: multipart/alternative; boundary="============_-1153753163==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1153753163==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >X-Sender: kseo@po2.bbn.com >Date: Tue, 15 Jul 2003 18:43:04 -0400 >To: "Angelos D. Keromytis" >From: Karen Seo >Subject: IPsec AH-bis-- Last Call revisions >Cc: Barbara Fraser , tytso@mit.edu, skent@bbn.com, > clynn@bbn.com, kseo@bbn.com >X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) >Status: > >Angelos, > >Here are the comments and their status for AH.... Revisions have >been made to address the comments and the changes have been approved >by the commenter. These cover all the tickets for AHbis that are >"Must Fix" or "Should Fix" plus some other comments not listed in >the ticket database. My impression is that the working group agreed >not to do the "MAY FIX" cases. > >Should I go ahead and submit the revised draft to the IETF? > >Karen > >=============================================================================== > >Commenter: Russ Housley >Date: 6/17/03 >Status: change approved by Russ on 7/9/03 > >>Please delete the last line of the Abstract. In my opinion, >>pointers to subsequent sections belong in the Introduction, not the >>Abstract. > > Abstract -- Moved last line of Abstract to end of Introduction > > "Section 7 provides a brief review of the differences between > this document and RFC 2402." > >=============================================================================== > >Commenter: Russ Housley >Date: 6/17/03 >Status: change approved by Russ on 7/9/03 > > >>Please move the last two paragraphs of the Introduction to the >>beginning. This will tell the reader the material that the >>expected to be understood before they get too deep, and it will >>define MAY. SHOULD, MUST, and so on before they are used. > > Introduction -- Moved the following text to the beginning of > the Introduction. These paragraphs are slightly reworded so they > fit at the beginning. > > "This document assumes that the reader is familiar with the > terms and concepts described in the "Security Architecture > for the Internet Protocol" [KA98], hereafter referred to as > the Security Architecture document. In particular, the reader > should be familiar with the definitions of security services > offered by the Encapsulating Security Payload (ESP) and the > IP Authentication Header (AH), the concept of Security > Associations, the ways in which ESP can be used in conjunction > with the Authentication Header (AH), and the different key > management options available for ESP and AH." > > "The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, > SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they > appear in this document, are to be interpreted as described > in RFC 2119 [Bra97]." > >=============================================================================== > >Commenter: Russ Housley >Date: 6/17/03 >Status: change approved by Russ on 7/9/03 > >>There is a reference to [STD-2] in the first paragraph of section >>2, but [STD-2] is not listed in the references. > > Section 2. Authentication Header Format, first paragraph, > first sentence. Fixed reference: > > From: > The protocol header (IPv4, IPv6, or IPv6 Extension) immediately > preceding the AH header SHALL contain the value 51 in its > Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2]. > > > To: > The protocol header (IPv4, IPv6, or IPv6 Extension) immediately > preceding the AH header SHALL contain the value 51 in its > Protocol (IPv4) or Next Header (IPv6, Extension) field [DH98]. > >=============================================================================== > >Commenter: Russ Housley >Date: 6/17/03 >Status: change approved by Russ on 7/9/03 > >>The references need to be divided in to normative and informative. > > References -- divided into Normative and Informative and deleted > some references that were no longer being used in the text. > > References > > Normative > > [Bra97] Bradner, S., "Key words for use in RFCs to > Indicate Requirement Level", BCP 14, RFC 2119, March > 1997. > > [DH98] Deering, S., and R. Hinden, "Internet Protocol, > Version 6 (IPv6) Specification", RFC 2460, December > 1998. > > [KA98a] Kent, S., and R. Atkinson, "Security > Architecture for the Internet Protocol", RFC 2401, > November 1998. > > Informative > > [HC03] Holbrook, H., and Cain, B., "Source Specific > Multicast for IP", Internet Draft, > draft-ietf-ssm-arch-01.txt, November 3, 2002. > > [HC98] Harkins, D., and D. Carrel, "The Internet Key > Exchange (IKE)", RFC 2409, November 1998. > > [KA98b] Kent, S., and R. Atkinson, "IP Authentication > Header (AH)", RFC 2402, November 1998. > > [Ken03] Kent, S., "IP Encapsulating Security Payload > (ESP)", RFC ???,???? 2003. > > [NBBB98] Nichols, K., Blake, S., Baker, F., Black, D., > "Definition of the Differentiated Services Field (DS > Field) in the IPv4 and IPv6 Headers", RFC 2474, > December 1998. > > [RFB01] Ramakrishnan, K., Floyd S., Black D., "The > Addition of Explicit Congestion Notification (ECN) > to IP", RFC 3168, September 2001. > >=============================================================================== > >Commenter: David Black >Date: 6/16/03 >Status: change approved by David on 7/11/03 > >>Section 3.3.3.1.1.1 describes the TOS field in the IP >>Header as mutable (that's correct) and says: >> >> TOS -- This field is excluded because some routers are known to >> change the value of this field, even though the IP specification >> does not consider TOS to be a mutable header field. >> >>That's no longer correct. The TOS field has now been >>replaced by a 6 bit DS field (contains a Diffserv >>codepoint) plus a 2 bit ECN field, and both are defined >>to be mutable. RFC 2780 and RFC 3168 should be cited >>as the basis for this, and possibly also RFC 2474. The >>same 6 bit DS + 2 bit ECN structure applies to the IPv6 >>(Traffic) Class field (section 3.3.3.1.2.1), which >>has always been mutable, as the same RFCs specify it. > >1. Added references > > [NBBB98] Nichols, K., Blake, S., Baker, F., Black, D., > "Definition of the Differentiated Services Field > (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, > December 1998. > > [RFB01] Ramakrishnan, K., Floyd S., Black D., "The > Addition of Explicit Congestion Notification (ECN) > to IP", RFC 3168, September 2001. > > >2. Section 3.3.3.1.1.1 Base Header Fields. Changed: > > From: > Mutable (zeroed prior to ICV calculation) > Type of Service (TOS) > > To: > Mutable (zeroed prior to ICV calculation) > DSCP (6 bits, see RFC2474 [NBBB98]) > ECN (2 bits, see RFC3168 [RFB01]) > >3. Section 3.3.3.1.2.1 Base Header Fields. Changed: > > From: > Mutable (zeroed prior to ICV calculation) > Class > > To: > Mutable (zeroed prior to ICV calculation) > DSCP (6 bits, see RFC2474 [NBBB98]) > ECN (2 bits, see RFC3168 [RFB01]) > > >=============================================================================== > >Commenter: Pekka Nikander >Date: 7/8/03 >Status: change approved by Pekka on 7/11/03 > >>> 2.2 Payload Length >>> >>> This 8-bit field specifies the length of AH in 32-bit words (4-byte >>> units), minus "2". (This means of expressing the length of AH was >>> selected to allow its use as an IPv6 extension header. Thus the >>> length computation is consistent with the algorithm described in RFC >>> 1883.) In the case of an integrity algorithm that yields a 96-bit >>> authentication value, plus the 3 32-bit word fixed portion, this >>> length field will be "4". See Section 2.6, "Integrity Check Value >>> (ICV)", for comments on padding of this field, and Section 3.3.3.2.1 >>> "ICV Padding". >> >>Comments: >> >> - Shouldn't the reference to RFC1883 be replaced with a reference >> to RFC2460, or better, to [DH95]? >> >> - It is probably far too late to change this, but all the other >> IPv6 extension headers define the length in 8-octet units, >> not 4-byte units. If possible, it *would* be desirable to >> update this for IPv6. However, I fully understand that such >> a change may not be possible at this late in standardization. >> (This comment may be ignored, as it most probably has been >> extensively discussed in the past by the WG.) >> >> - For IPv6, there should be a requirement that the length MUST >> be integral in 8-octet units, i.e., that the length must be >> evenly divisible by two. The requirement for that does exist >> in 3.3.3.2.1, but it would be good to briefly repeat it here. >> >> Suggestion: Insert the following text before "See Section 2.6" >> >> For IPv6, the total length of the header must be a multiple of >> 8-octet units. > >1. References -- Updated IPv6 reference... > > From: > [DH95] Deering, S., and R. Hinden, "Internet Protocol, > Version 6 (IPv6) Specification", RFC 1883, December 1995. > > To: > [DH98] Deering, S., and R. Hinden, "Internet Protocol, > Version 6 (IPv6) Specification", RFC 2460, December 1998. > > Also changed references in the text from [DH95] to [DH98]. > >2. Added sentence shown above. Such that 2.2. Payload Length now reads: > > 2.2 Payload Length > > This 8-bit field specifies the length of AH in 32-bit words (4-byte > units), minus "2". (This means of expressing the length of AH was > selected to allow its use as an IPv6 extension header. Thus the > length computation is consistent with the algorithm described in RFC > 2460 [DH98].) In the case of an integrity algorithm that yields a > 96-bit authentication value, plus the 3 32-bit word fixed portion, > this length field will be "4". For IPv6, the total length of the > header must be a multiple of 8-octet units. See Section 2.6, > "Integrity Check Value (ICV)", for comments on padding of this field, > and Section 3.3.3.2.1 "ICV Padding". > >3. Did not make any changes re: going from 4-byte units to 8-octet units. > > >=============================================================================== > >Commenter: Pekka Nikander >Date: 7/8/03 >Status: change approved by Pekka on 7/11/03 > >>> 2.3 Reserved >>> >>> This 16-bit field is reserved for future use. It MUST be set to >>> "zero." (Note that the value is included in the ICV calculation, but >>> is otherwise ignored by the recipient.) >> >>Comments: >> >> - Why is the value of the field defined as it is? The more usual >> wording seems to be 'MUST be set to "zero" by the sender, and >> SHOULD be ignored by the recipient'. The effect of the text above >> is the same, but someone may try to read it is the value must >> always be zero, and e.g. implement a firewall that drops packets >> where it is non-zero. >> >> Suggestion: Replace with the following text. >> >> This 16-bit field is reserved for future use. It MUST be set to >> "zero" by the sender, and it SHOULD be ignored by the recipient. >> (Note that the value is included in the ICV calculation, but is >> currently otherwise ignored by the recipient.) > > Section 2.3 Reserved. Changed: > > From: > This 16-bit field is reserved for future use. It MUST > be set to "zero." (Note that the value is included in > the ICV calculation, but is otherwise ignored by the > recipient.) > > To: > This 16-bit field is reserved for future use. It MUST be set to > "zero" by the sender, and it SHOULD be ignored by the recipient. > (Note that the value is included in the ICV calculation, but is > currently otherwise ignored by the recipient.) > >=============================================================================== > >Commenter: Pekka Nikander >Date: 7/8/03 >Status: change approved by Pekka on 7/11/03 > > >>> 3.3.3.1.2.1 Base Header Fields >>> >>> The IPv6 base header fields are classified as follows: >>> >>> Immutable >>> Version >>> Payload Length >>> Next Header (This should be the value for AH.) >> >>Comments: >> >> - The note in the paranthesis is both unnecessary and misleading, >> as there may well be intevening extension headers. >> Suggestion: Remove the text in paranthesis. > > Section 3.3.3.1.2.1 Base Header Fields. Changed: > > From: > The IPv6 base header fields are classified as follows: > > Immutable > Version > Payload Length > Next Header (This should be the value for AH.) > > To: > The IPv6 base header fields are classified as follows: > > Immutable > Version > Payload Length > Next Header > >=============================================================================== > >Commenter: Pekka Nikander >Date: 7/8/03 >Status: change approved by Pekka on 7/14/03 > >>> 3.3.3 Integrity Check Value Calculation >>> >>> .... >>> >>> o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence >>> Number (low order 32 bits), and the Authentication Data (which is >>> set to zero for this computation), and explicit padding bytes (if >>> any)) >> >>s/Authentication Data/Integrity Check Value/ > > Done > >=============================================================================== > >Commenter: Pekka Nikander >Date: 7/8/03 >Status: change approved by Pekka on 7/14/03 > >>> 3.3.3.1 Handling Mutable Fields >>> >>> ..... >>> calculation. The Authentication Data field is also set to zero in >> >>s/Authentication Data/Integrity Check Value/ > > Done > >=============================================================================== > >Commenter: Pekka Nikander >Date: 7/8/03 >Status: change approved by Pekka on 7/14/03 > >>> Appendix A -- Mutability of IP Options/Extension Headers >>> >>> A2. IPv6 Extension Headers >>> >>> This table shows how the IPv6 Extension Headers are classified with >>> regard to "mutability". >>> >>> Option/Extension Name Reference >>> ----------------------------------- --------- >>> MUTABLE BUT PREDICTABLE -- included in ICV calculation >>> Routing (Type 0) [RFC1883] >>> >>> BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING >>> TRANSIT) >>> Hop by Hop options [RFC1883] >>> Destination options [RFC1883] >>> >>> NOT APPLICABLE >>> Fragmentation [RFC1883] >> >>s/[RFC1883]/[DH95]/ > > Changed to DH98 > > Option/Extension Name Reference > ----------------------------------- --------- > MUTABLE BUT PREDICTABLE -- included in ICV calculation > Routing (Type 0) [DH98] > > BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING > TRANSIT) > Hop by Hop options [DH98] > Destination options [DH98] > > NOT APPLICABLE > Fragmentation [DH98] > >=============================================================================== > >Commenter: Pekka Nikander >Date: 7/8/03 >Status: change approved by Pekka on 7/14/03 > >>> Routing (Type 0) -- The IPv6 Routing Header "Type 0" will >>> rearrange the address fields within the packet during transit from >>> source to destination. However, the contents of the packet as it >>> will appear at the receiver are known to the sender and to all >>> intermediate hops. Hence, the IPv6 Routing Header "Type 0" is >>> included in the Authentication Data calculation as mutable but >>> predictable. The sender must order the field so that it appears as >>> it will at the receiver, prior to performing the ICV computation. >> >>s/Authentication Data/Integrity Check Value/ > > Done > >=============================================================================== --============_-1153753163==_ma============ Content-Type: text/html; charset="us-ascii" Fwd: IPsec AH-bis-- Last Call revisions
X-Sender: kseo@po2.bbn.com
Date: Tue, 15 Jul 2003 18:43:04 -0400
To: "Angelos D. Keromytis" <angelos@cs.columbia.edu>
From: Karen Seo <kseo@bbn.com>
Subject: IPsec AH-bis-- Last Call revisions
Cc: Barbara Fraser <byfraser@cisco.com>, tytso@mit.edu, skent@bbn.com,
   clynn@bbn.com, kseo@bbn.com
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Status:  
Angelos,

Here are the comments and their status for AH....  Revisions have been made to address the comments and the changes have been approved by the commenter.  These cover all the tickets for AHbis that are "Must Fix" or "Should Fix" plus some other comments not listed in the ticket database.  My impression is that the working group agreed not to do the "MAY FIX" cases.

Should I go ahead and submit the revised draft to the IETF?

Karen

===============================================================================

Commenter:      Russ Housley
Date:           6/17/03
Status:         change approved by Russ on 7/9/03

Please delete the last line of the Abstract.  In my opinion, pointers to subsequent sections belong in the Introduction, not the Abstract.

    Abstract -- Moved last line of Abstract to end of Introduction

        "Section 7 provides a brief review of the differences between
        this document and RFC 2402."

===============================================================================

Commenter:      Russ Housley
Date:           6/17/03
Status:         change approved by Russ on 7/9/03


Please move the last two paragraphs of the Introduction to the beginning.  This will tell the reader the material that the expected to be understood before they get too deep, and it will define MAY. SHOULD, MUST, and so on before they are used.

   Introduction -- Moved the following text to the beginning of
   the Introduction. These paragraphs are slightly reworded so they
   fit at the beginning.

        "This document assumes that the reader is familiar with the
        terms and concepts described in the "Security Architecture
        for the Internet Protocol" [KA98], hereafter referred to as
        the Security Architecture document.  In particular, the reader
        should be familiar with the definitions of security services
        offered by the Encapsulating Security Payload (ESP) and the
        IP Authentication Header (AH), the concept of Security
        Associations, the ways in which ESP can be used in conjunction
        with the Authentication Header (AH), and the different key
        management options available for ESP and AH."

        "The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
        SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they
        appear in this document, are to be interpreted as described
        in RFC 2119 [Bra97]."

===============================================================================

Commenter:      Russ Housley
Date:           6/17/03
Status:         change approved by Russ on 7/9/03

There is a reference to [STD-2] in the first paragraph of section 2, but [STD-2] is not listed in the references.

   Section 2. Authentication Header Format, first paragraph,
   first sentence.  Fixed reference:

   From:
        The protocol header (IPv4, IPv6, or IPv6 Extension) immediately
preceding the AH header SHALL contain the value 51 in its
        Protocol (IPv4) or Next Header (IPv6, Extension) field [STD-2].
       

   To:
        The protocol header (IPv4, IPv6, or IPv6 Extension) immediately
preceding the AH header SHALL contain the value 51 in its
        Protocol (IPv4) or Next Header (IPv6, Extension) field [DH98].

===============================================================================

Commenter:      Russ Housley
Date:           6/17/03
Status:         change approved by Russ on 7/9/03

The references need to be divided in to normative and informative.

   References -- divided into Normative and Informative and deleted
   some references that were no longer being used in the text.

   References

   Normative

        [Bra97] Bradner, S., "Key words for use in RFCs to
        Indicate Requirement Level", BCP 14, RFC 2119, March
        1997.

        [DH98] Deering, S., and R. Hinden, "Internet Protocol,
        Version 6 (IPv6) Specification", RFC 2460, December
        1998.
        [KA98a] Kent, S., and R. Atkinson, "Security
        Architecture for the Internet Protocol", RFC 2401,
        November 1998.
   Informative

        [HC03] Holbrook, H., and Cain, B., "Source Specific
        Multicast for IP", Internet Draft,     
        draft-ietf-ssm-arch-01.txt, November 3, 2002.
        [HC98] Harkins, D., and D. Carrel, "The Internet Key
        Exchange (IKE)", RFC 2409, November 1998.
        [KA98b] Kent, S., and R. Atkinson, "IP Authentication
        Header (AH)", RFC 2402, November 1998.
        [Ken03] Kent, S., "IP Encapsulating Security Payload
        (ESP)", RFC ???,???? 2003.
        [NBBB98] Nichols, K., Blake, S., Baker, F., Black, D.,
        "Definition of the Differentiated Services Field (DS
        Field) in the IPv4 and IPv6 Headers", RFC 2474,
        December 1998.

        [RFB01] Ramakrishnan, K., Floyd S., Black D., "The
        Addition of Explicit Congestion Notification (ECN)
        to IP", RFC 3168, September 2001.

===============================================================================

Commenter:      David Black
Date:           6/16/03
Status:         change approved by David on 7/11/03

Section 3.3.3.1.1.1 describes the TOS field in the IP
Header as mutable (that's correct) and says:

       TOS -- This field is excluded because some routers are known to
   change the value of this field, even though the IP specification
   does not consider TOS to be a mutable header field.

That's no longer correct.  The TOS field has now been
replaced by a 6 bit DS field (contains a Diffserv
codepoint) plus a 2 bit ECN field, and both are defined
to be mutable.  RFC 2780 and RFC 3168 should be cited
as the basis for this, and possibly also RFC 2474.  The
same 6 bit DS + 2 bit ECN structure applies to the IPv6
(Traffic) Class field (section 3.3.3.1.2.1), which
has always been mutable, as the same RFCs specify it.

1. Added references

        [NBBB98] Nichols, K., Blake, S., Baker, F., Black, D.,
        "Definition of the Differentiated Services Field
        (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
        December 1998.

        [RFB01] Ramakrishnan, K., Floyd S., Black D., "The
        Addition of Explicit Congestion Notification (ECN)
        to IP", RFC 3168, September 2001.


2. Section 3.3.3.1.1.1 Base Header Fields. Changed:
  
   From:
        Mutable (zeroed prior to ICV calculation)
               Type of Service (TOS)

   To:
        Mutable (zeroed prior to ICV calculation)
                DSCP (6 bits, see RFC2474 [NBBB98])
                ECN (2 bits, see RFC3168 [RFB01])

3. Section 3.3.3.1.2.1 Base Header Fields. Changed:
  
   From:
        Mutable (zeroed prior to ICV calculation)
                Class

   To:
        Mutable (zeroed prior to ICV calculation)
                DSCP (6 bits, see RFC2474 [NBBB98])
                ECN (2 bits, see RFC3168 [RFB01])


===============================================================================

Commenter:      Pekka Nikander
Date:           7/8/03
Status:         change approved by Pekka on 7/11/03

 2.2  Payload Length

    This 8-bit field specifies the length of AH in 32-bit words (4-byte
    units), minus "2".  (This means of expressing the length of AH was
    selected to allow its use as an IPv6 extension header. Thus the
    length computation is consistent with the algorithm described in RFC
    1883.)  In the case of an integrity algorithm that yields a 96-bit
    authentication value, plus the 3 32-bit word fixed portion, this
    length field will be "4". See Section 2.6, "Integrity Check Value
    (ICV)", for comments on padding of this field, and Section 3.3.3.2.1
    "ICV Padding".

Comments:

 - Shouldn't the reference to RFC1883 be replaced with a reference
   to RFC2460, or better, to [DH95]?

 - It is probably far too late to change this, but all the other
   IPv6 extension headers define the length in 8-octet units,
   not 4-byte units.  If possible, it *would* be desirable to
   update this for IPv6.  However, I fully understand that such
   a change may not be possible at this late in standardization.
   (This comment may be ignored, as it most probably has been
    extensively discussed in the past by the WG.)

 - For IPv6, there should be a requirement that the length MUST
   be integral in 8-octet units, i.e., that the length must be
   evenly divisible by two.  The requirement for that does exist
   in 3.3.3.2.1, but it would be good to briefly repeat it here.

   Suggestion:  Insert the following text before "See Section 2.6"

     For IPv6, the total length of the header must be a multiple of
     8-octet units.

1. References -- Updated IPv6 reference...
   From:
        [DH95]  Deering, S., and R. Hinden, "Internet Protocol,
        Version 6 (IPv6) Specification", RFC 1883, December 1995.
   To:
        [DH98]  Deering, S., and R. Hinden, "Internet Protocol,
        Version 6 (IPv6) Specification", RFC 2460, December 1998.

   Also changed references in the text from [DH95] to [DH98].

2. Added sentence shown above.  Such that 2.2. Payload Length now reads:

   2.2  Payload Length

   This 8-bit field specifies the length of AH in 32-bit words (4-byte
   units), minus "2".  (This means of expressing the length of AH was
   selected to allow its use as an IPv6 extension header. Thus the
   length computation is consistent with the algorithm described in RFC
   2460 [DH98].)  In the case of an integrity algorithm that yields a
   96-bit authentication value, plus the 3 32-bit word fixed portion,
   this length field will be "4". For IPv6, the total length of the
   header must be a multiple of 8-octet units. See Section 2.6,
   "Integrity Check Value (ICV)", for comments on padding of this field,
   and Section 3.3.3.2.1 "ICV Padding".

3. Did not make any changes re: going from 4-byte units to 8-octet units.


===============================================================================

Commenter:      Pekka Nikander
Date:           7/8/03
Status:         change approved by Pekka on 7/11/03

 2.3  Reserved

    This 16-bit field is reserved for future use.  It MUST be set to
    "zero." (Note that the value is included in the ICV calculation, but
    is otherwise ignored by the recipient.)

Comments:

 - Why is the value of the field defined as it is?  The more usual
   wording seems to be 'MUST be set to "zero" by the sender, and
   SHOULD be ignored by the recipient'.  The effect of the text above
   is the same, but someone may try to read it is the value must
   always be zero, and e.g. implement a firewall that drops packets
   where it is non-zero.

   Suggestion:  Replace with the following text.

     This 16-bit field is reserved for future use.  It MUST be set to
     "zero" by the sender, and it SHOULD be ignored by the recipient.
     (Note that the value is included in the ICV calculation, but is
     currently otherwise ignored by the recipient.)

   Section 2.3 Reserved.  Changed:

   From:
        This 16-bit field is reserved for future use.  It MUST
        be set to "zero." (Note that the value is included in
        the ICV calculation, but is otherwise ignored by the
        recipient.)
   To:
        This 16-bit field is reserved for future use.  It MUST be set to
        "zero" by the sender, and it SHOULD be ignored by the recipient.
        (Note that the value is included in the ICV calculation, but is
        currently otherwise ignored by the recipient.)

===============================================================================

Commenter:      Pekka Nikander
Date:           7/8/03
Status:         change approved by Pekka on 7/11/03


 3.3.3.1.2.1  Base Header Fields

    The IPv6 base header fields are classified as follows:

    Immutable
              Version
              Payload Length
              Next Header (This should be the value for AH.)

Comments:

 - The note in the paranthesis is both unnecessary and misleading,
   as there may well be intevening extension headers.
   Suggestion:  Remove the text in paranthesis.

   Section 3.3.3.1.2.1 Base Header Fields.  Changed:

   From:
        The IPv6 base header fields are classified as follows:

  Immutable
               Version
        Payload Length
          Next Header (This should be the value for AH.)

   To:
    The IPv6 base header fields are classified as follows:

  Immutable
               Version
        Payload Length
                Next Header

===============================================================================

Commenter:      Pekka Nikander
Date:           7/8/03
Status:         change approved by Pekka on 7/14/03

 3.3.3  Integrity Check Value Calculation

    ....

       o the AH header (Next Header, Payload Len, Reserved, SPI, Sequence
         Number (low order 32 bits), and the Authentication Data (which is
         set to zero for this computation), and explicit padding bytes (if
         any))

s/Authentication Data/Integrity Check Value/

        Done

===============================================================================

Commenter:      Pekka Nikander
Date:           7/8/03
Status:         change approved by Pekka on 7/14/03

 3.3.3.1  Handling Mutable Fields

    .....
    calculation.  The Authentication Data field is also set to zero in

s/Authentication Data/Integrity Check Value/

        Done

===============================================================================

Commenter:      Pekka Nikander
Date:           7/8/03
Status:         change approved by Pekka on 7/14/03

 Appendix A -- Mutability of IP Options/Extension Headers

 A2.  IPv6 Extension Headers

    This table shows how the IPv6 Extension Headers are classified with
    regard to "mutability".

        Option/Extension Name                  Reference
        -----------------------------------    ---------
        MUTABLE BUT PREDICTABLE -- included in ICV calculation
          Routing (Type 0)                    [RFC1883]

        BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING
        TRANSIT)
          Hop by Hop options                  [RFC1883]
          Destination options                 [RFC1883]

        NOT APPLICABLE
          Fragmentation                       [RFC1883]

s/[RFC1883]/[DH95]/

    Changed to DH98

    Option/Extension Name                  Reference
    -----------------------------------    ---------
    MUTABLE BUT PREDICTABLE -- included in ICV calculation
      Routing (Type 0)                    [DH98]

    BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING
    TRANSIT)
      Hop by Hop options                  [DH98]
      Destination options                 [DH98]

    NOT APPLICABLE
      Fragmentation                       [DH98]
===============================================================================

Commenter:      Pekka Nikander
Date:           7/8/03
Status:         change approved by Pekka on 7/14/03

        Routing (Type 0) -- The IPv6 Routing Header "Type 0" will
    rearrange the address fields within the packet during transit from
    source to destination.  However, the contents of the packet as it
    will appear at the receiver are known to the sender and to all
    intermediate hops.  Hence, the IPv6 Routing Header "Type 0" is
    included in the Authentication Data calculation as mutable but
    predictable.  The sender must order the field so that it appears as
    it will at the receiver, prior to performing the ICV computation.

s/Authentication Data/Integrity Check Value/

        Done

===============================================================================

--============_-1153753163==_ma============-- From owner-ipsec@lists.tislabs.com Wed Jul 16 10:58:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GHwLqt096046; Wed, 16 Jul 2003 10:58:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02679 Wed, 16 Jul 2003 13:24:21 -0400 (EDT) Message-ID: <2F8E7538CA01D711BC5900B0D079E710233229@zin03exm01.corp.mot.com> From: Mittal Harshwardhan-A18990 To: "'ipsec@lists.tislabs.com'" Subject: RE: Securid authentication for IKE client Date: Tue, 15 Jul 2003 10:19:59 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Actually server is not using Transaction Exchange as specified IKECFG, its using Informational exchange after the completion of phase 1 aggrassive mode, as quoted in http://www.cisco.com/en/US/products/hw/vpndevc/ps2301/products_tech_note09186a0080094e7a.shtml "IKE currently has no support for SecurID authentication. We perform SecurID authentication in a special informational exchange in between phase one and phase two. This exchange is fully protected by the IKE SA negotiated in phase one." There are 4 informational message exchnages happening for Securid Authentication, First message coming from server. It will be helpful if some CISCO guys can comment on it.. Regards, Harsh -----Original Message----- From: Gregory Lebovitz [mailto:Gregory@netscreen.com] Sent: Monday, July 14, 2003 2:31 PM To: 'Ravi '; Mittal Harshwardhan-A18990 Cc: ""@az33exr01.mot.com Subject: RE: Securid authentication for IKE client Make sure to define your policy for Xauth support. Xauth is the only way to get the securID info passed to the gateway. Also, any gateway you use MUST have specific support for ACE server features within the Xauth exchange in order to work as customers want. "Ace advanced features" are things like new-pin or next-key, which are ACE proprietary equivalents to RADIUS access-challenge. Gregory. -----Original Message----- From: Ravi To: Mittal Harshwardhan-A18990 Cc: ipsec@lists.tislabs.com Sent: 7/9/03 9:20 PM Subject: Re: Securid authentication for IKE client Hi, I am not sure whether CISCO5000 supports this or not. But, you should have X-Auth support for this to work. Also, make sure that X-Auth implementation supports RSA SecureID transactions by both VPN client and CISCO 5000 servers. Regards Ravi Mittal Harshwardhan-A18990 wrote: > Hi all, > > I am currently working on a VPN client and wants to get the client authenticated using RSA Securid ACE card. > I have all required information ( userid, passcode, acecard value). > > IKE phase 1 is complete with some default group-id and password. > > I am using Cisco 5000 series concentrator as a server which is not under my conrol, > but I have my ace-card and laptop (windows and linux) client (provided by Cisco) configured for the server, > and I am able to estblish VPN session both from linux and windows. > > My question is what is the packet format in which I can send my ace-card credentials to the cisco server > to get my client authenticated. > What is the protocol, I think Cisco client is sending this info in form of IKE informational exchange. > but as the packet is encrypted using ISAKMPD SA I am unable to find out the packet format. > > thanks in anticipation > > Regards, > Harsh > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Wed Jul 16 11:36:40 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GIadqt000648; Wed, 16 Jul 2003 11:36:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA02894 Wed, 16 Jul 2003 13:56:12 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA8701EA952B@SARATOGA.netscreen.com> From: Gregory Lebovitz To: Markus Friedl , ipsec@lists.tislabs.com Subject: RE: IKEv2 and NAT/T Date: Wed, 16 Jul 2003 11:02:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="WINDOWS-1252" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk per an informal bof at ietf57 -there have not been IPR statements officially presented to IETF wrt NAT-T -WG chairs queried several times over the last 2+ years the person(s) who made original comments, and have not heard back from said persons > -----Original Message----- > From: Markus Friedl [mailto:Markus.Friedl@informatik.uni-erlangen.de] > Sent: Saturday, June 07, 2003 1:28 AM > To: ipsec@lists.tislabs.com > Subject: IKEv2 and NAT/T > > > On Tue, Jun 03, 2003 at 11:14:14AM -0400, > Charlie_Kaufman@notesdev.ibm.com wrote: > > Just to let people know, I posted a revised IKEv2 draft > incorporating > > the recent comments. > > Hello, > > since IKEv2 includes support for NAT/T, I'd like to know how > IKEv2 is affected by the IPR/patent claims that exist for several > NAT traversal methods. Does anyone have pointers about the nature > of these IPR claims and what exactily is affected by these claims. > Encapsulating ESP in UDP seems very trivial, so I doubt that > this is all the patents are about. > > Any help appreciated. > thanks, -markus > From owner-ipsec@lists.tislabs.com Wed Jul 16 13:38:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GKckqt006811; Wed, 16 Jul 2003 13:38:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA03668 Wed, 16 Jul 2003 15:31:59 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16149.43336.790298.979641@ryijy.hel.fi.ssh.com> Date: Wed, 16 Jul 2003 22:36:40 +0300 From: Tero Kivinen To: Gregory Lebovitz Cc: Markus Friedl , ipsec@lists.tislabs.com Subject: RE: IKEv2 and NAT/T In-Reply-To: <541402FFDC56DA499E7E13329ABFEA8701EA952B@SARATOGA.netscreen.com> References: <541402FFDC56DA499E7E13329ABFEA8701EA952B@SARATOGA.netscreen.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 9 min X-Total-Time: 9 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Gregory Lebovitz writes: > -there have not been IPR statements officially presented to IETF wrt NAT-T Actually not true. There is two IPR statement related to the NAT-T in the IKEv2 already in the IPR page: http://www.ietf.org/ietf/IPR/SSH-NAT and http://www.ietf.org/ietf/IPR/MICROSOFT-NAT-Traversal.txt The first one considers all "implementations of an IETF standards-track specification of an IPSec NAT traversal module" identical, i.e the text covers both IKEv1 and IKEv2. The second one only allows using the NAT-T if it is implemented based on the and drafts, i.e it propably will not cover IKEv2. There is also one more Microsoft IPR claim on the page to the ikev2, but I do not know any details. > -WG chairs queried several times over the last 2+ years the person(s) who > made original comments, and have not heard back from said persons This is about the one patent claim couple of years ago. They never sent any official IPR statements, so nobody knows if they actually have anything. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Jul 16 16:08:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6GN8eqt016488; Wed, 16 Jul 2003 16:08:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA04446 Wed, 16 Jul 2003 18:29:29 -0400 (EDT) Subject: RE: IKEv2 and NAT/T From: Daniel de Young To: Gregory Lebovitz Cc: Markus Friedl , ipsec@lists.tislabs.com In-Reply-To: <541402FFDC56DA499E7E13329ABFEA8701EA952B@SARATOGA.netscreen.com> References: <541402FFDC56DA499E7E13329ABFEA8701EA952B@SARATOGA.netscreen.com> Content-Type: text/plain Message-Id: <1058394858.26955.2.camel@linux.velvetsea.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4-1.1mdk Date: 16 Jul 2003 15:34:18 -0700 Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 2003-07-16 at 11:02, Gregory Lebovitz wrote: > per an informal bof at ietf57 > > -there have not been IPR statements officially presented to IETF wrt NAT-T > -WG chairs queried several times over the last 2+ years the person(s) who > made original comments, and have not heard back from said persons Are people who make these claims required to clarify their statements before a draft is finalized? I certainly hope so... -Daniel From owner-ipsec@lists.tislabs.com Thu Jul 17 06:45:26 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HDjPqt099915; Thu, 17 Jul 2003 06:45:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA07033 Thu, 17 Jul 2003 08:56:00 -0400 (EDT) Message-Id: <200307170921.h6H9LR8Q011610@thunk.east.sun.com> From: Bill Sommerfeld To: Daniel de Young Cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 and NAT/T In-Reply-To: Your message of "16 Jul 2003 15:34:18 PDT." <1058394858.26955.2.camel@linux.velvetsea.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 17 Jul 2003 05:21:27 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Are people who make these claims required to clarify their statements > before a draft is finalized? I certainly hope so... Delaying RFC publication until the formal IPR claim appears on http://www.ietf.org/ipr.html would allow anyone with an unsubstantiated IPR claim to prevent the publication of RFC's they allege might infringe their IPR.. - Bill From owner-ipsec@lists.tislabs.com Thu Jul 17 11:35:49 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HIZmqt017557; Thu, 17 Jul 2003 11:35:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA08222 Thu, 17 Jul 2003 13:51:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Thu, 17 Jul 2003 12:23:20 -0400 To: ipsec@lists.tislabs.com From: Karen Seo Subject: Fwd: IPsec ESP-bis -- Last Call revisions Content-Type: multipart/alternative; boundary="============_-1153663494==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1153663494==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Apologies if this is a repeat -- it seems to have hit a mail snag of some sort, so I'm resending it. >X-Sender: kseo@po2.bbn.com >Date: Tue, 15 Jul 2003 18:44:37 -0400 >To: "Angelos D. Keromytis" >From: Karen Seo >Subject: IPsec ESP-bis -- Last Call revisions >Cc: Barbara Fraser , tytso@mit.edu, skent@bbn.com, > clynn@bbn.com, kseo@bbn.com >X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) >Status: > >Angelos, > >Here are the comments and their status for ESP.... Revisions have >been made to address the comments and the changes have been either >approved by the commenter (1-12) or sent to the commenter for >approval (13, 14) . These cover all the tickets for ESP-bis. > >I think 13 and 14 look likely to be approved but am going to wait >for Russ to reply before submitting the revised draft to the IETF. > >Karen > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 >Status: change approved by Russ on 7/15/03 > >>1. Please delete the last line of the Abstract. In my opinion, >>pointers to subsequent sections belong in the Introduction, not the >>Abstract. > > Moved to end of Introduction. > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 >Status: change approved by Russ on 7/15/03 > >>2. Please move the last two paragraphs of the Introduction to the >>beginning. This will tell the reader the material that the >>expected to be understood before they get too deep, and it will >>define MAY. SHOULD, MUST, and so on before they are used. > > Done. > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 >Status: change approved by Russ on 7/15/03 > >>3. The last paragraph on page 4 includes: >> >> Typically this binding is effected through the use of a shared, >> symmetric key, but an asymmetric cryptographic algorithm also may be >> employed, e.g., to sign a hash.) >> >>Digitally signing individual packets should not be encouraged. The >>performance ramifications, both computational and packet bloat, are >>extreme. I suggest dropping the second half of the sentence. Just >>do not bring it up. > > Done. > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 >Status: change approved by Russ on 7/15/03 > >>4. The first full paragraph at the top of page 5 includes: >> >> Although confidentiality and integrity can be offered independently, >> most ESP use typically will employ both services, i.e., packets will >> be protected with regard to confidentiality and integrity. >> >>s/use/uses/ > > Changed to: Although confidentiality and integrity can be > offered independently, ESP typically will employ.... > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 >Status: change approved by Russ on 7/15/03 > >>5. The following paragraph appears on the second half of page 7: >> >> When any combined mode algorithm is employed, the algorithm itself is >> expected to return both decrypted plaintext and a pass/fail >> indication for the integrity check. For combined mode algorithms, the >> ICV that would normally appear at the end of the ESP packet (when >> integrity is selected) is omitted. It is the responsibility of the >> combined mode algorithm to encode within the payload data an ICV- >> equivalent means of verifying the integrity of the packet. >> >>I consider CCM (see draft-ietf-ipsec-ciph-aes-ccm-03) to be a >>combined mode. The referenced specification makes use of the ICV >>field. Therefore, I propose two changes: >> >> - Please replace "is omitted" to "may be omitted" > > Done. > >> >> - Please change "It is the responsibility of the combined mode >>algorithm ..." to "When the ICV is omitted and integrity is >>selected, it is the responsibility of the combined mode algorithm >>..." > > Done. > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 >Status: change approved by Russ on 7/15/03 > >>6. Figure 2 include "IV (optional]. " >>s/]/)/ > > Done. > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 >Status: change approved by Russ on 7/15/03 > >>7. Below Figure 2, the following paragraph appears: >> >> If a combined algorithm mode is employed, the explicit ICV shown in >> Figures 1 and 2 is omitted (see Section 3.3.2.2 below). Since >> algorithms and modes are fixed when an SA is established, the >> detailed format of ESP packets for a given SA (including the Payload >> Data substructure) is fixed, for all traffic on the SA. >> >>s/is omitted/may be omitted/ > > Done. > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 >Status: change approved by Russ on 7/15/03 > >>8. In Table 2, the ICV row should be "O" in the "Requ'd" column. > > Changed the ICV row and added a footnote: > > What What What > # of Requ'd Encrypt Integ is > bytes [1] Covers Covers Xmtd > ------ ------ ------ ------ ------ > ICV variable O [6] plain > > [6] The algorithm spec determines whether this field is > present > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 >Status: change approved by Russ on 7/15/03 > >>9. The first sentence in section 2.2.1, has the flavor of a new >>option that is under development, rather than one that is ready to >>be finalized. I propose an alternative: >> >> To support high-speed IPsec implementations, extended sequence >> numbers SHOULD be implemented. > > Done. > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 >Status: change approved by Russ on 7/15/03 > >>10. At the beginning of section 2.4, the following sentence is >>followed by two bullets. Something is not quite right. >> >> Three factors require or motivate use of the Padding field. > > Changed to "Two primary factors require....." > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 >Status: change approved by Russ on 7/15/03 > >>11. Please reword the paragraph in section 2.8 to permit the ICV >>field to be present when a combined mode is employed, which is >>consistent with the wording used in section 3.2.3. > > Changed: > From: > The ICV field is optional; it is present only if the integrity > service is selected and a separate (not combined mode) > integrity algorithm is employed. > > To: > The ICV field is optional. It is present only if integrity > service is selected and is provided by either a separate > integrity algorithm or a combined mode algorithm that uses > an ICV. > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 >Status: change approved by Russ on 7/15/03 > >>12. Please reword the 4th bullet following the paragraph numbered 3 >>in section 3.3.2.2 to permit the ICV field to be present when a >>combined mode is employed. > > Changed: > > From: > The (explicit) ICV field is NOT part of the ESP packet > format when a combined mode algorithm is employed, > although an analogous field usually will a part of > the ciphertext payload. > > To: > The (explicit) ICV field MAY be a part of the ESP > packet format when a combined mode algorithm is > employed. If one is not used, an analogous field usually > will be a part of the ciphertext payload. > > >=============================================================================== > >Commenter: Russ Housley >Date: 6/16/03 and 7/15/03 >Status: sent following proposed change to Russ on 7/15/03 > >>13. I am confused by "DISCUSSION" in section 3.4.4.1. > > We asked for clarification on 7/4/03 and received the feedback > below: > >>It says: >> >> DISCUSSION: >> >> Begin by removing and saving the ICV field. Next check the >> overall length of the ESP packet minus the ICV field. If >> implicit padding is required, based on the blocksize of the >> integrity algorithm, append zero-filled bytes to the end of >> the ESP packet directly after the Next Header >> field. Perform the ICV computation and compare the result >> with the saved value, using the comparison rules defined by >> the algorithm specification. >> >>My issue is that there is no context provided. >> >>I think this would be better structured as an Implementation Note. Like: >> >> Implementation Note: Implementations can use any set of steps >> that results in the same result as the following set of steps. Begin >> by ... >> > > Changed to: > > Implementation Note: > > Implementations can use any set of steps that results in the > same result as the following set of steps. Begin by removing > and saving the ICV field. Next check the overall length of the > ESP packet minus the ICV field. If implicit padding is > required, based on the blocksize of the integrity algorithm, > append zero-filled bytes to the end of the ESP packet directly > after the Next Header field. Perform the ICV computation and > compare the result with the saved value, using the comparison > rules defined by the algorithm specification. > >=============================================================================== > >Commenter: Russ Housley >Date: 6/17/03 >Status: sent following proposed change to Russ on 7/15/03 > >>14. The references need to be divided in to normative and informative. > > We changed the References to: > > References > > > Normative > > [Bra97] Bradner, S., "Key words for use in RFCs to > Indicate Requirement Level", BCP 14, RFC 2119, March > 1997. > > [KA98] Kent, S., and R. Atkinson, "Security > Architecture for the Internet Protocol", RFC 2401, > November 1998. > > Informative > > [Bel96] Steven M. Bellovin, "Problem Areas for the IP > Security Protocols", Proceedings of the Sixth Usenix > Unix Security Symposium, July, 1996. > > [HC03] Holbrook, H., and Cain, B., "Source Specific > Multicast for IP", Internet Draft, > draft-ietf-ssm-arch-01.txt, November 3, 2002. > > [HC98] Harkins, D., and D. Carrel, "The Internet Key > Exchange (IKE)", RFC 2409, November 1998. > > [Ken03] Kent, S., "IP Authentication Header", RFC ???, > ??? 2003. > > [Kra01] Krawczyk, H., "The Order of Encryption and > Authentication for Protecting Communications (Or: How > Secure Is SSL?)", CRYPTO' 2001. > >=============================================================================== --============_-1153663494==_ma============ Content-Type: text/html; charset="us-ascii" Fwd: IPsec ESP-bis -- Last Call revisions
Apologies if this is a repeat -- it seems to have hit a mail snag of some sort, so I'm resending it.

X-Sender: kseo@po2.bbn.com
Date: Tue, 15 Jul 2003 18:44:37 -0400
To: "Angelos D. Keromytis" <angelos@cs.columbia.edu>
From: Karen Seo <kseo@bbn.com>
Subject: IPsec ESP-bis -- Last Call revisions
Cc: Barbara Fraser <byfraser@cisco.com>, tytso@mit.edu, skent@bbn.com,
   clynn@bbn.com, kseo@bbn.com
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Status:  
Angelos,

Here are the comments and their status for ESP....  Revisions have been made to address the comments and the changes have been either approved by the commenter (1-12) or sent to the commenter for approval (13, 14) .  These cover all the tickets for ESP-bis.

I think 13 and 14 look likely to be approved but am going to wait for Russ to reply before submitting the revised draft to the IETF.

Karen

===============================================================================

Commenter:      Russ Housley
Date:           6/16/03
Status:         change approved by Russ on 7/15/03

1.  Please delete the last line of the Abstract.  In my opinion, pointers to subsequent sections belong in the Introduction, not the Abstract.

        Moved to end of Introduction.

===============================================================================

Commenter:      Russ Housley
Date:           6/16/03
Status:         change approved by Russ on 7/15/03

2.  Please move the last two paragraphs of the Introduction to the beginning.  This will tell the reader the material that the expected to be understood before they get too deep, and it will define MAY. SHOULD, MUST, and so on before they are used.

        Done.

===============================================================================

Commenter:      Russ Housley
Date:           6/16/03
Status:         change approved by Russ on 7/15/03

3.  The last paragraph on page 4 includes:

   Typically this binding is effected through the use of a shared,
   symmetric key, but an asymmetric cryptographic algorithm also may be
   employed, e.g., to sign a hash.)

Digitally signing individual packets should not be encouraged.  The performance ramifications, both computational and packet bloat, are extreme.  I suggest dropping the second half of the sentence.  Just do not bring it up.

        Done.

===============================================================================

Commenter:      Russ Housley
Date:           6/16/03
Status:         change approved by Russ on 7/15/03

4.  The first full paragraph at the top of page 5 includes:

   Although confidentiality and integrity can be offered independently,
   most ESP use typically will employ both services, i.e., packets will
   be protected with regard to confidentiality and integrity.
s/use/uses/

        Changed to: Although confidentiality and integrity can be
        offered independently, ESP typically will employ....

===============================================================================

Commenter:      Russ Housley
Date:           6/16/03
Status:         change approved by Russ on 7/15/03

5.  The following paragraph appears on the second half of page 7:

   When any combined mode algorithm is employed, the algorithm itself is
   expected to return both decrypted plaintext and a pass/fail
   indication for the integrity check. For combined mode algorithms, the
   ICV that would normally appear at the end of the ESP packet (when
   integrity is selected) is omitted. It is the responsibility of the
   combined mode algorithm to encode within the payload data an ICV-
   equivalent means of verifying the integrity of the packet.

I consider CCM (see draft-ietf-ipsec-ciph-aes-ccm-03) to be a combined mode.  The referenced specification makes use of the ICV field.  Therefore, I propose two changes:

   - Please replace "is omitted" to "may be omitted"

        Done.

   - Please change "It is the responsibility of the combined mode algorithm ..." to "When the ICV is omitted and integrity is selected, it is the responsibility of the combined mode algorithm ..."

        Done.
===============================================================================

Commenter:      Russ Housley
Date:           6/16/03
Status:         change approved by Russ on 7/15/03

6.  Figure 2 include "IV (optional]. "
s/]/)/

        Done.
===============================================================================

Commenter:      Russ Housley
Date:           6/16/03
Status:         change approved by Russ on 7/15/03

7.  Below Figure 2, the following paragraph appears:

   If a combined algorithm mode is employed, the explicit ICV shown in
   Figures 1 and 2 is omitted (see Section 3.3.2.2 below). Since
   algorithms and modes are fixed when an SA is established, the
   detailed format of ESP packets for a given SA (including the Payload
   Data substructure) is fixed, for all traffic on the SA.

s/is omitted/may be omitted/

        Done.
===============================================================================

Commenter:      Russ Housley
Date:           6/16/03
Status:         change approved by Russ on 7/15/03

8.  In Table 2, the ICV row should be "O" in the "Requ'd" column.

        Changed the ICV row and added a footnote:

                                     What    What    What
                    # of     Requ'd  Encrypt Integ    is
                    bytes      [1]   Covers  Covers  Xmtd
                    ------   ------  ------  ------  ------
      ICV           variable   O [6]                 plain

           [6] The algorithm spec determines whether this field is
                present

===============================================================================

Commenter:      Russ Housley
Date:           6/16/03
Status:         change approved by Russ on 7/15/03

9.  The first sentence in section 2.2.1, has the flavor of a new option that is under development, rather than one that is ready to be finalized.  I propose an alternative:

   To support high-speed IPsec implementations, extended sequence
   numbers SHOULD be implemented.

        Done.
===============================================================================

Commenter:      Russ Housley
Date:           6/16/03
Status:         change approved by Russ on 7/15/03

10.  At the beginning of section 2.4, the following sentence is followed by two bullets.  Something is not quite right.

   Three factors require or motivate use of the Padding field.

        Changed to "Two primary factors require....."

===============================================================================

Commenter:      Russ Housley
Date:           6/16/03
Status:         change approved by Russ on 7/15/03

11.  Please reword the paragraph in section 2.8 to permit the ICV field to be present when a combined mode is employed, which is consistent with the wording used in section 3.2.3.

        Changed:
   From:
        The ICV field is optional; it is present only if the integrity
        service is selected and a separate (not combined mode)
        integrity algorithm is employed.

   To:
        The ICV field is optional.  It is present only if integrity
        service is selected and is provided by either a separate
        integrity algorithm or a combined mode algorithm that uses
        an ICV.
===============================================================================

Commenter:      Russ Housley
Date:           6/16/03
Status:         change approved by Russ on 7/15/03

12. Please reword the 4th bullet following the paragraph numbered 3 in section 3.3.2.2 to permit the ICV field to be present when a combined mode is employed.

        Changed:

   From:
        The (explicit) ICV field is NOT part of the ESP packet
        format when a combined mode algorithm is employed,
        although an analogous field usually will a part of
        the ciphertext payload.

   To:
        The (explicit) ICV field MAY be a part of the ESP
        packet format when a combined mode algorithm is
        employed. If one is not used, an analogous field usually
        will be a part of the ciphertext payload.


===============================================================================

Commenter:      Russ Housley
Date:           6/16/03 and 7/15/03
Status:         sent following proposed change to Russ on 7/15/03

13. I am confused by "DISCUSSION" in section 3.4.4.1.

        We asked for clarification on 7/4/03 and received the feedback
        below:

It says:

               DISCUSSION:

               Begin by removing and saving the ICV field. Next check the
               overall length of the ESP packet minus the ICV field. If
               implicit padding is required, based on the blocksize of the
               integrity algorithm, append zero-filled bytes to the end of
               the ESP packet directly after the Next Header
               field. Perform the ICV computation and compare the result
               with the saved value, using the comparison rules defined by
               the algorithm specification.

My issue is that there is no context provided.

I think this would be better structured as an Implementation Note.  Like:

        Implementation Note:  Implementations can use any set of steps
        that results in the same result as the following set of steps.  Begin
        by ...

   Changed to:

        Implementation Note:

    Implementations can use any set of steps that results in the
    same result as the following set of steps.  Begin by removing
   and saving the ICV field. Next check the overall length of the
  ESP packet minus the ICV field. If implicit padding is
        required, based on the blocksize of the integrity algorithm,
      append zero-filled bytes to the end of the ESP packet directly
  after the Next Header field. Perform the ICV computation and
    compare the result with the saved value, using the comparison
   rules defined by the algorithm specification.

===============================================================================

Commenter:      Russ Housley
Date:           6/17/03
Status:         sent following proposed change to Russ on 7/15/03

14.  The references need to be divided in to normative and informative.

        We changed the References to:

   References

   Normative
        [Bra97] Bradner, S., "Key words for use in RFCs to
        Indicate Requirement Level", BCP 14, RFC 2119, March
        1997.

        [KA98] Kent, S., and R. Atkinson, "Security
        Architecture for the Internet Protocol", RFC 2401,
        November 1998.
    Informative
        [Bel96] Steven M. Bellovin, "Problem Areas for the IP
        Security Protocols", Proceedings of the Sixth Usenix
        Unix Security Symposium, July, 1996.
        [HC03]  Holbrook, H., and Cain, B., "Source Specific
        Multicast for IP", Internet Draft,
        draft-ietf-ssm-arch-01.txt, November 3, 2002.

        [HC98] Harkins, D., and D. Carrel, "The Internet Key
        Exchange (IKE)", RFC 2409, November 1998.
        [Ken03] Kent, S., "IP Authentication Header", RFC ???,
        ??? 2003.

        [Kra01] Krawczyk, H., "The Order of Encryption and
        Authentication for Protecting Communications (Or: How
        Secure Is SSL?)", CRYPTO' 2001.

===============================================================================

--============_-1153663494==_ma============-- From owner-ipsec@lists.tislabs.com Thu Jul 17 11:55:59 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HItwqt018561; Thu, 17 Jul 2003 11:55:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08306 Thu, 17 Jul 2003 14:23:21 -0400 (EDT) Date: Thu, 17 Jul 2003 09:44:50 +0200 From: Markus Friedl To: Daniel de Young Cc: Gregory Lebovitz , ipsec@lists.tislabs.com Subject: Re: IKEv2 and NAT/T Message-ID: <20030717074450.GB15585@folly> References: <541402FFDC56DA499E7E13329ABFEA8701EA952B@SARATOGA.netscreen.com> <1058394858.26955.2.camel@linux.velvetsea.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1058394858.26955.2.camel@linux.velvetsea.com> User-Agent: Mutt/1.4.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Jul 16, 2003 at 03:34:18PM -0700, Daniel de Young wrote: > On Wed, 2003-07-16 at 11:02, Gregory Lebovitz wrote: > > per an informal bof at ietf57 > > > > -there have not been IPR statements officially presented to IETF wrt NAT-T > > -WG chairs queried several times over the last 2+ years the person(s) who > > made original comments, and have not heard back from said persons > > Are people who make these claims required to clarify their statements > before a draft is finalized? I certainly hope so... It's still very confusing. The statements fail to specify what part of the drafts if covered by the IPR claims. Just prepending an UDP header to ESP is rather trivial. And so on. -markus From owner-ipsec@lists.tislabs.com Thu Jul 17 12:14:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HJExqt019278; Thu, 17 Jul 2003 12:14:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA08384 Thu, 17 Jul 2003 14:41:23 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: Date: Thu, 17 Jul 2003 14:48:15 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: revised IPsec processing model Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here is the new, proposed processing model for IPsec. Comments welcome, of course. Steve ------ The current IPsec subscriber traffic processing model, as defined in 2401, is imprecise in several respects, and it does not accommodate some significant deployment use that have arisen, e.g., PPVPNs. Also, just as we have created the extended sequence number facility for AH and ESP to accommodate high speed (10Gb/s and beyond) implementations, there are changes one can make to the processing model to better accommodate traffic classification (for outbound traffic). Finally, there are some simplifications one can make to the mode, consistent with the overall push for implementation simplification. We first look at outbound traffic, which is where most of the proposed changes are visible, then examine inbound traffic processing. The focus here is on subscriber traffic, with some discussion of IKE traffic. Several concepts underlie the proposed model: - virtual interface: every IPsec device has at least one virtual interface, which may correspond to one physical interface (the common case). Multiple virtual interfaces may map to a single physical interface, e.g., for overlay nets, or one virtual interface may map to multiple virtual interfaces. The choice of a one-to-one, many-to-one, or one-to-many mapping for virtual to physical interfaces is a local matter, which each implementer is free to select apropos to the environment on which IPsec is implemented. Every virtual interface has an ID (VID), a purely local identifier, which is used with the forwarding function defined below, to select the virtual interface to which outbound traffic is directed. The VID is NOT technically a selector, because it does not need to appear in an SPD; rather it is used to select an appropriate SPD. - forwarding function: to provide a clear separation between forwarding (routing) and security decisions, an explicit forwarding function is added. This function can be trivial, in the case where there is only one interface (virtual or physical). It may be complex if there are multiple interfaces and if the implementation elects to offer a more sophisticated form of route selection. The spec makes no assumptions about the internal operation of the function, other than to say that the whole packet is passed to it and the output is a VID. In turn, the VID is used to select the appropriate SPD. - SPD: the SPD is largely the same as currently defined. Instead of being defined on a per interface basis, it is now per virtual interface, and is labeled with a VID, as specified above. The new SPD will differ in terms of the selectors allowed (consistent with IKEv2). Rather than referring to separate SPDs for inbound vs. outbound traffic (pre interface) we will talk in terms of entries in each SPD being directional, i.e., there are separate inbound and outbound entries for each SPD for each virtual interface. This makes sense because the inbound and outbound entries are really linked. - SPD caches: the current processing model refers to searching the SPD for each outbound packet to determine how to process it, and to check inbound traffic after IPsec processing, to ensure that traffic arriving on an SA is consistent with the selectors defined when the SA was created. This is a potentially time consuming search process, in both directions, because of the need to search the SPD entries in the order specified by the administrator or user who created them. The search process also is ambiguous as currently defined, with regard to processing inbound packets. To simplify the process, and to allow for very fast SA lookups, we introduce the notion of an outbound SPD cache (on a per virtual interface basis), and the caching of inbound SPD entries in two places. Since SPD entries may overlap, one cannot safely cache these entries in general. Simple caching might result in a match against a cache entry whereas a search of the SPD would have resulted in a match against a different entry. But, if we decorrelate the SPD, then the resulting entries can safely be cached. For outbound traffic, each cached entry maps to an SA, or indicates that matching traffic should be bypassed or discarded. For inbound traffic, the SPD cache serves as the reference for the selectors to be matched against arriving packets, or defines traffic to be bypassed or discarded. An algorithm for decorrelation was published as an ID some time ago, and I think there is at least one paper on the topic published as well. 2401bis will not mandate a specific algorithm, but will include an example in an appendix. With these concepts in mind, we can describe the revised model. First we examine outbound traffic processing. (There is no separate discussion of fragment processing for now, as we await the WG decisions of several pending proposals re fragmentation.) 1. when a packet arrives from a subscriber interface, invoke the forwarding lookup function. 2. match the packet headers against the SPD cache specified by the VID from step 1 3a. if there is a match, then process the packet as specified by the matching cache entry, i.e., bypass, discard, or apply AH or ESP in the specified mode. If IPsec processing is applied, there is a link from the SPD cache entry to the relevant SAD entry (specifying the algorithms, keys, SPI, etc.). IPsec processing is as previously defined, for tunnel or transport modes and for AH or ESP, as specified. 3b. if no match, search the SPD that corresponds to this cache. If the SPD calls for bypass or discard, create a new outbound and inbound cache entries. If the SPD entry calls for creation of an SA (pair), the key management mechanism (e.g., IKEv2) is invoked to create the SA. If SA creation succeeds, a new outbound cache entry is created, along with an SAD entry, otherwise the packet is discarded, and an error is logged, and may be signaled. (A packet that triggers an SPD lookup MAY be discarded by the implementation, or it may be buffered and then processed against the newly created cache entry, if one is created.) The SAD entry contains the inbound selector values linked to the SPD entry used to create the inbound SA, to support checking of received traffic. 4. The VID assigned to the packet in step 1 (the forwarding lookup) is used to select the interface to which the packet is directed, after the specified processing (if any) is applied in step 3. Inbound processing is somewhat different from outbound processing, largely because we use of SPIs to map IPsec traffic to SAs, vs. performing a lookup based on traffic selector values. However, we still have to perform traffic selector lookups for non-IPsec inbound traffic, to determine whether this traffic is to be discarded or bypassed. Thus an inbound IPsec cache is used to quickly process this traffic. The description below does not include reassembly processing, while we await a WG decision on the possibility of rejecting fragments for SAs from specified sources. 1. When a packet arrives, it is tagged with a VID. This ID may be directly mapped from a physical interface, or a lookup function may be invoked to assign a VID, analogous to what is offered for outbound traffic in step 1 above. Note that there is no need to tag a packet with a VID if it is an IPsec packet directed to the IPsec implementation. This is because there is only one SAD which applies to all traffic, regardless of the interface. However, because SPDs are per-interface, entries for bypass or discard traffic might be specific to the interface via which the inbound traffic is received. If there is no need to treat inbound traffic differently depending on the interface upon which it arrived, the VID may be a constant. 2. examine the header to determine if it is addressed to the IPsec implementations, and if so, if it appears to be for a key management protocol. If so, direct the packet to key management processing. 3a. If the packet is addressed to the IPsec implementation and AH or ESP is specified as the protocol, lookup the packet using the SPI in the SAD. Remember that each SAD entry now includes 2-bits to specify which fields are used to determine a match (unicast vs. multicast). If there is no match, discard the traffic, logging the error as specified by local management controls. If there is a match in the SAD, apply AH or ESP as specified, using the SAD entry selected above. Then match the packet against the inbound selectors in the SAD entry, to verify that the received packet is appropriate for the SA via which it was received. If there is a mismatch, log the error and signal it if a signaling mechamism is available and enabled. 3b. If the packet is not addressed to the implementation, or if the traffic is not AH or ESP, lookup the packet header in the inbound (discard/bypass) SPD cache for this (virtual) interface. If there is a match and the packet is to be discarded or bypassed, do so. If there is no match, lookup the packet in the inbound SPD (for the interface in question) and create an appropriate inbound and an outbound cache entry. (No SAs are created in response to receipt of a packet that requires IPsec; only bypass or discard entries can be created this way.) This processing model is simpler and less vague than the old model, and it offers the potential for higher speed processing of traffic. It does, however, remove some functionality. For example, there is no provision for SA bundles. It would be easy to include support for the simple AH+ESP combination that IKEv1 was able to negotiate, and that 2401 mandates, if that combination is still viewed as needed. However, IKEv1 was not able to negotiate any other nested protocol combinations and I don't think IKEv2 has addressed this problem either, especially the notion of adding new SAs to create an SA "bundle." So, I suggest we remove the requirement to support SA bundles, unless the WG feels strongly otherwise. There is also no provision within this processing model to support nested SAs, i.e., all IPsec processing is performed in one pass. However, after the packet is emitted, it could be redirected through the IPsec module via local, virtual interfaces and use of the forwarding lookup function, to cause more than one layer of IPsec headers to be applied or removed. Note that to accomplish this, multiple entries would have to be created, in distinct SPDs, each specifying a layer of IPsec processing to be applied. However, IKE still lacks a means to negotiate this, so I suspect that only manual configuration, or some key management mechanism not yet defined for IPsec, would be needed to take advantage of this approach. From owner-ipsec@lists.tislabs.com Thu Jul 17 22:26:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I5QSqt045968; Thu, 17 Jul 2003 22:26:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA10530 Fri, 18 Jul 2003 00:51:06 -0400 (EDT) To: Stephen Kent Cc: ipsec@lists.tislabs.com In-reply-to: kent's message of Thu, 17 Jul 2003 14:48:15 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: revised IPsec processing model From: itojun@iijlab.net Date: Fri, 18 Jul 2003 13:57:58 +0900 Message-Id: <20030718045758.B1A12A3@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Here is the new, proposed processing model for IPsec. Comments >welcome, of course. the text is a bit unclear whether it is talking about transport mode or tunnel mode. "virtual interface" is for tunnel mode only, am i right? if so, you can now remove tunnel mode from FFC2401 - there are bunch of tunnel specification available (like RFC2893, RFC1853, RFC2003) and tunnel mode will be replaced by "transport mode + tunnelling". i love to see the change. if "virtual interface" is used also for transport mode, it will be incompatible with IPv6 linklocal address (by changing inbound interface for a packet, i.e. m->m_pkthdr.rcvif in BSD, you change the scope zone). therefore i object to apply "virtual interface" concept to transport mode. itojun From owner-ipsec@lists.tislabs.com Fri Jul 18 01:00:20 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I80Kqt065907; Fri, 18 Jul 2003 01:00:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11116 Fri, 18 Jul 2003 03:21:54 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <20030718045758.B1A12A3@coconut.itojun.org> References: <20030718045758.B1A12A3@coconut.itojun.org> Date: Fri, 18 Jul 2003 03:28:12 -0400 To: itojun@iijlab.net From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 13:57 +0900 7/18/03, itojun@iijlab.net wrote: > >Here is the new, proposed processing model for IPsec. Comments >>welcome, of course. > > the text is a bit unclear whether it is talking about transport mode > or tunnel mode. > > "virtual interface" is for tunnel mode only, am i right? if so, > you can now remove tunnel mode from FFC2401 - there are bunch of > tunnel specification available (like RFC2893, RFC1853, RFC2003) > and tunnel mode will be replaced by "transport mode + tunnelling". > i love to see the change. > > if "virtual interface" is used also for transport mode, it will be > incompatible with IPv6 linklocal address (by changing inbound interface > for a packet, i.e. m->m_pkthdr.rcvif in BSD, you change the scope > zone). therefore i object to apply "virtual interface" concept > to transport mode. > >itojun There is no plan to remove tunnel mode from the spec. The plan was to apply this model for both transport and tunnle modes. Steve From owner-ipsec@lists.tislabs.com Fri Jul 18 01:02:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I82pqt066381; Fri, 18 Jul 2003 01:02:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11157 Fri, 18 Jul 2003 03:28:45 -0400 (EDT) To: Stephen Kent Cc: ipsec@lists.tislabs.com In-reply-to: kent's message of Fri, 18 Jul 2003 03:28:12 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: revised IPsec processing model From: itojun@iijlab.net Date: Fri, 18 Jul 2003 16:35:37 +0900 Message-Id: <20030718073537.074D813@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >At 13:57 +0900 7/18/03, itojun@iijlab.net wrote: >> >Here is the new, proposed processing model for IPsec. Comments >>>welcome, of course. >> >> the text is a bit unclear whether it is talking about transport mode >> or tunnel mode. >> >> "virtual interface" is for tunnel mode only, am i right? if so, >> you can now remove tunnel mode from FFC2401 - there are bunch of >> tunnel specification available (like RFC2893, RFC1853, RFC2003) >> and tunnel mode will be replaced by "transport mode + tunnelling". >> i love to see the change. >> >> if "virtual interface" is used also for transport mode, it will be >> incompatible with IPv6 linklocal address (by changing inbound interface >> for a packet, i.e. m->m_pkthdr.rcvif in BSD, you change the scope >> zone). therefore i object to apply "virtual interface" concept >> to transport mode. > >There is no plan to remove tunnel mode from the spec. The plan was to >apply this model for both transport and tunnle modes. in that case, i would like to express concern w/ IPv6 linklocal address (the latter paragraph of mine). itjoun From owner-ipsec@lists.tislabs.com Fri Jul 18 01:15:07 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I8F6qt067270; Fri, 18 Jul 2003 01:15:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA11188 Fri, 18 Jul 2003 03:41:48 -0400 (EDT) Message-Id: <5.2.0.9.2.20030718033023.041186c8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 18 Jul 2003 03:48:39 -0400 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Fwd: Certicom IP Rights Cc: iesg@ietf.org, IMcKinnon@certicom.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear IPsec Working Group: I just got this note, but I believe that it is related to US patent number 6,563,928. Certicom did give us warning that this was coming. On Monday, 20 July 1998, Paul Lambert (who was VPl, Product Management at the time) wrote to the IPsec mail list on a thread dealing with "Patent & licence for IPSec." Unfortunately, the thread was mostly about ECC, so this notice did not generate any discussion. Paul said: "Some of the pending patents for secure implementations of public key technologies may also cover implementations of the current mandatory portions of IKE in IPsec." I have asked Mr. McKinnon to post an updated IPR statement as soon as possible. Russ >Subject: Certicom IP Rights >To: housley@vigilsec.com >From: Ian McKinnon >Date: Thu, 17 Jul 2003 16:23:09 -0400 > >Dear Mr. Housley: > >Certicom has been reviewing its Intellectual Property position with >respect to the Internet Key Exchange Protocol (as specified in "Internet >Key Exchange (IKEv2) Proposal" ).We believe >that we may have certain IP rights covering some aspects of the draft. > >We are still in the process of preparing our positions with respect to our >IPR but wanted to inform you as IKEv2 is being finalized. > >Ian McKinnon >President and CEO >Certicom Corp From owner-ipsec@lists.tislabs.com Fri Jul 18 08:33:25 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IFXOqt005257; Fri, 18 Jul 2003 08:33:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA12500 Fri, 18 Jul 2003 10:37:08 -0400 (EDT) Message-Id: <5.1.1.5.2.20030718074219.079be5b0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 18 Jul 2003 07:43:30 -0700 To: Stephen Kent From: Mark Baugher Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com In-Reply-To: References: <20030718045758.B1A12A3@coconut.itojun.org> <20030718045758.B1A12A3@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:28 AM 7/18/2003 -0400, Stephen Kent wrote: >At 13:57 +0900 7/18/03, itojun@iijlab.net wrote: >> >Here is the new, proposed processing model for IPsec. Comments >>>welcome, of course. >> >> the text is a bit unclear whether it is talking about transport mode >> or tunnel mode. >> >> "virtual interface" is for tunnel mode only, am i right? if so, >> you can now remove tunnel mode from FFC2401 - there are bunch of >> tunnel specification available (like RFC2893, RFC1853, RFC2003) >> and tunnel mode will be replaced by "transport mode + tunnelling". >> i love to see the change. >> >> if "virtual interface" is used also for transport mode, it will be >> incompatible with IPv6 linklocal address (by changing inbound >> interface >> for a packet, i.e. m->m_pkthdr.rcvif in BSD, you change the scope >> zone). therefore i object to apply "virtual interface" concept >> to transport mode. >> >>itojun > >There is no plan to remove tunnel mode from the spec. The plan was to >apply this model for both transport and tunnle modes. As recommended by Ferguson and Schneier? Mark >Steve From owner-ipsec@lists.tislabs.com Fri Jul 18 09:49:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IGnfqt007523; Fri, 18 Jul 2003 09:49:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA12790 Fri, 18 Jul 2003 12:01:59 -0400 (EDT) From: "George Hadjichristofi" To: "Ipsec" Subject: ipsec SAs Date: Fri, 18 Jul 2003 12:07:26 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I have a question about IPSec SAs. There is a nework such as: A----Gateway1 ===tunnel====Gateway2 ----B A and B are the subnets. Gateway 1 and 2 negotiate a tunnel such that A can communicate securely with B. Based on RFC2401, does that mean that A will only be able to talk to B and no other nodes on the network, or just that it will talk to B via a secure tunnel and to everybody else in cleartext? Should A be able to talk to Gateway2? Thank you George *********************************************************** George C. Hadjichristofi Graduate Student Bradley Department of Electrical and Computer Engineering Virginia Tech,Blacksburg,VA 24061,U.S.A TEL:(540)-951-8936 *********************************************************** From owner-ipsec@lists.tislabs.com Fri Jul 18 10:10:59 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IHAwqt008438; Fri, 18 Jul 2003 10:10:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA13006 Fri, 18 Jul 2003 12:36:26 -0400 (EDT) Date: Fri, 18 Jul 2003 12:42:51 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: ipsec SAs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 18 Jul 2003, George Hadjichristofi wrote: > Based on RFC2401, does that mean that A will only be able to talk to B and > no other nodes on the network, or just that it will talk to B via a secure > tunnel and to everybody else in cleartext? Depends on software and configuration. Either choice might be desirable, depending on the circumstances. > Should A be able to talk to Gateway2? If Gateway2 is a member of subnet B, it should be possible (although the implementation of this can be tricky). Otherwise, there's nothing in having a tunnel to B that would permit it. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Fri Jul 18 15:39:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IMdbqt029992; Fri, 18 Jul 2003 15:39:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14373 Fri, 18 Jul 2003 17:57:27 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: <5.1.1.5.2.20030718074219.079be5b0@mira-sjc5-6.cisco.com> References: <20030718045758.B1A12A3@coconut.itojun.org> <20030718045758.B1A12A3@coconut.itojun.org> <5.1.1.5.2.20030718074219.079be5b0@mira-sjc5-6.cisco.com> Date: Fri, 18 Jul 2003 18:01:34 -0400 To: Mark Baugher From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:43 -0700 7/18/03, Mark Baugher wrote: >At 03:28 AM 7/18/2003 -0400, Stephen Kent wrote: >>At 13:57 +0900 7/18/03, itojun@iijlab.net wrote: >>> >Here is the new, proposed processing model for IPsec. Comments >>>>welcome, of course. >>> >>> the text is a bit unclear whether it is talking about transport mode >>> or tunnel mode. >>> >>> "virtual interface" is for tunnel mode only, am i right? if so, >>> you can now remove tunnel mode from FFC2401 - there are bunch of >>> tunnel specification available (like RFC2893, RFC1853, RFC2003) >>> and tunnel mode will be replaced by "transport mode + tunnelling". >>> i love to see the change. >>> >>> if "virtual interface" is used also for transport mode, it will be >>> incompatible with IPv6 linklocal address (by changing >>>inbound interface >>> for a packet, i.e. m->m_pkthdr.rcvif in BSD, you change the scope >>> zone). therefore i object to apply "virtual interface" concept >>> to transport mode. >>> >>>itojun >> >>There is no plan to remove tunnel mode from the spec. The plan was >>to apply this model for both transport and tunnle modes. > >As recommended by Ferguson and Schneier? > >Mark If I understand your question, the answer is no. Long ago this WG decided that the paper you cite had several errors, probably a result of the authors not being protocol experts. their critique of IKE v1 was much more credible than the corresponding comments re ESP and AH. The list discussed the possibility of simplifying IPsec by dropping either tunnel or transport mode, and there was some support for that notion, but the support was divided between those who wanted to drop tunnel mode, and those who wanted to drop transport mode. so, unless directed by the WG chairs, we plan to continue support for both modes. However, consistent with the introduction of the forwarding function and virtual interfaces, and with the growing practice of using IPsec as a lower layer 3 security protocol (vs. upper layer 3, where IP lives), we do intened to relax the restriction on when to use transport mode, along with appropriate warnings. Steve From owner-ipsec@lists.tislabs.com Fri Jul 18 15:40:03 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IMe3qt030010; Fri, 18 Jul 2003 15:40:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14363 Fri, 18 Jul 2003 17:57:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: References: Date: Fri, 18 Jul 2003 18:01:34 -0400 To: "George Hadjichristofi" From: Stephen Kent Subject: Re: ipsec SAs Cc: "Ipsec" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:07 -0400 7/18/03, George Hadjichristofi wrote: >Hi, > >I have a question about IPSec SAs. > >There is a nework such as: >A----Gateway1 ===tunnel====Gateway2 ----B > >A and B are the subnets. >Gateway 1 and 2 negotiate a tunnel such that A can communicate securely with >B. > >Based on RFC2401, does that mean that A will only be able to talk to B and >no other nodes on the network, or just that it will talk to B via a secure >tunnel and to everybody else in cleartext? > >Should A be able to talk to Gateway2? > >Thank you >George > The scenario in your diagram is common. The administrators for the security gateways decide whether the tunnel that is created between them will carry all traffic between any two hosts on the subnets behind them, or just traffic between A & B, or even whether a separate tunnel is created for each different connection between A & B, etc. Depending on how these administrators choose to define the SPD entries for communication between these two subnets, there are lots of possibilities. You ask whether A should be able to talk to Gateway 2. Again, this will be a function of the SPD entries. Steve From owner-ipsec@lists.tislabs.com Fri Jul 18 15:40:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IMeNqt030028; Fri, 18 Jul 2003 15:40:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA14368 Fri, 18 Jul 2003 17:57:23 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com (Unverified) Message-Id: In-Reply-To: <20030718073537.074D813@coconut.itojun.org> References: <20030718073537.074D813@coconut.itojun.org> Date: Fri, 18 Jul 2003 18:01:34 -0400 To: itojun@iijlab.net From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 16:35 +0900 7/18/03, itojun@iijlab.net wrote: > >At 13:57 +0900 7/18/03, itojun@iijlab.net wrote: >>> >Here is the new, proposed processing model for IPsec. Comments >>>>welcome, of course. >>> >>> the text is a bit unclear whether it is talking about transport mode >>> or tunnel mode. >>> >>> "virtual interface" is for tunnel mode only, am i right? if so, >>> you can now remove tunnel mode from FFC2401 - there are bunch of >>> tunnel specification available (like RFC2893, RFC1853, RFC2003) >>> and tunnel mode will be replaced by "transport mode + tunnelling". >>> i love to see the change. >>> >>> if "virtual interface" is used also for transport mode, it will be >>> incompatible with IPv6 linklocal address (by changing inbound interface >>> for a packet, i.e. m->m_pkthdr.rcvif in BSD, you change the scope >>> zone). therefore i object to apply "virtual interface" concept >>> to transport mode. >> >>There is no plan to remove tunnel mode from the spec. The plan was to >>apply this model for both transport and tunnle modes. > > in that case, i would like to express concern w/ IPv6 linklocal address > (the latter paragraph of mine). > >itjoun Could you elaborate a bit more on the nature of the problem? Your paragraph above was not enough for me, since I don't understand what IPv6 does in this regard absent Ipsec. Also, in which of the IPv6 specs is the behavior you are describing defined? Thanks, Steve From owner-ipsec@lists.tislabs.com Sat Jul 19 04:34:51 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JBYpqt085477; Sat, 19 Jul 2003 04:34:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA16676 Sat, 19 Jul 2003 06:52:33 -0400 (EDT) To: Stephen Kent Cc: ipsec@lists.tislabs.com In-reply-to: kent's message of Fri, 18 Jul 2003 18:01:34 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: revised IPsec processing model From: itojun@iijlab.net Date: Sat, 19 Jul 2003 19:59:27 +0900 Message-Id: <20030719105927.0423913@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> in that case, i would like to express concern w/ IPv6 linklocal address >> (the latter paragraph of mine). >Could you elaborate a bit more on the nature of the problem? Your >paragraph above was not enough for me, since I don't understand what >IPv6 does in this regard absent Ipsec. Also, in which of the IPv6 >specs is the behavior you are describing defined? RFC2460/2373. draft-ietf-ipv6-scoping-arch-00.txt will also give you more information. with IPv6, there are not-universally-unique address defined in RFC2373. one of them is link-local address (the other one, site-local address, is going away so i will omit site-local from the discussion). link-local address range is fe80::/10, and address under it is unique on a certain link only. for instance, the following situation is legal: fe80::1 | ==+===== ether segment1 | your machine | ==+===== ether segment2 | fe80::1 i.e. you are seeing the same address (fe80::1) on the different link your machine is attached to. to disambiguate these machines, socket API (RFC2553) has additional field, sin6_scope_id, in sockaddr_in6. specifying 128bit address (fe80::1) is not enough, you have to specify which link you are talking about (textual notation is "fe80::1%segment1"). now, many implementations use interface to identify link. BSD-based implementation normally disambiguates incoming packet by m->m_pkthdr.rcvif. by introducing "virtual interface" and switching m->m_pkthdr.rcvif based on the virtual interface, you will become unable to identify peer correctly - after IPsec processing, both "fe80::1%segment1" and "fe80::1%segment2" would become "fe80::1%ipsec". providing 1-by-1 mapping between virtual interface and real interface does not provide a solution, since you will now see non-IPsec traffic as sent from "fe80::1%segment1" and IPsec traffic as sent from "fe80::1%ipsec1", and upper layer will get confused. itojun From owner-ipsec@lists.tislabs.com Sat Jul 19 09:01:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JG17qt002145; Sat, 19 Jul 2003 09:01:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA17757 Sat, 19 Jul 2003 11:16:08 -0400 (EDT) Message-Id: <200307191522.h6JFMt8Q021016@thunk.east.sun.com> From: Bill Sommerfeld To: itojun@iijlab.net cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: revised IPsec processing model In-Reply-To: Your message of "Sat, 19 Jul 2003 19:59:27 +0900." <20030719105927.0423913@coconut.itojun.org> Reply-to: sommerfeld@east.sun.com Date: Sat, 19 Jul 2003 11:22:55 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > by introducing "virtual interface" and switching m->m_pkthdr.rcvif > based on the virtual interface, you will become unable to identify > peer correctly - after IPsec processing, both "fe80::1%segment1" and > "fe80::1%segment2" would become "fe80::1%ipsec". providing 1-by-1 > mapping between virtual interface and real interface does not provide > a solution, since you will now see non-IPsec traffic as sent from > "fe80::1%segment1" and IPsec traffic as sent from "fe80::1%ipsec1", > and upper layer will get confused. Maybe we just need a name other than "virtual interface" for the ipsec entity. I understood the proposal as for a new kind of entity, the "2401-bis-ipsec-virtual-interface" which is different from the "real" interface as seen by IP. If you needed to record the 2401-bis-vif in packet metadata in addition to the physical interface, you'd put it in a parallel field to the BSD/KAME m->m_pkthdr.rcvif. - Bill From owner-ipsec@lists.tislabs.com Sat Jul 19 09:38:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JGcoqt003056; Sat, 19 Jul 2003 09:38:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17892 Sat, 19 Jul 2003 12:02:54 -0400 (EDT) Date: Sat, 19 Jul 2003 09:09:42 -0700 Subject: Re: revised IPsec processing model: Q: VID and forwarding function Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Stephen Kent To: ipsec mailingList From: Ricky Charlet In-Reply-To: Message-Id: <682DFC4C-BA03-11D7-B9FF-00039349B0FC@speakeasy.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, I'm trying to understand the motivations for VIDs and explicit forwarding function separation. Currently, I am guessing (based on your first paragraph) that these new features enable PPVPNs and/or overlay networks. If so, how so? If not, what new functionality is enabled by these features? This one is an editorial quesiton: I wonder about a particular phrase in the paragraph which begins "- virtual interface:" There is a clause which says "or one virtual interface may map to multiple virtual interfaces.". I suppose from the intended parallelism of the sentence that it perhaps should have read "or one virtual interface may map to multiple physical interfaces." Also, the last paragraph implies a loop behavior for IPsec processing: 1. consult forwarding function to get VID 2. do IPsec processing as per VIDs SPD 3. go to 1. The exit condition for this loop is not specified. Let's consider outbound processing for an example. If the forwarding function is aware of only routing information (i.e. it is separated from security policy decisions) then it seems to me that this loop will get stuck: 1. forwarding function says exit VID is X 2. spd says this packet is allowed to pass 3. go to 1. Certainly as implementors, we could all thing of our own little ways to break this loop. But shouldn't we have uniform guidance? --- Ricky Charlet rcharlet@alumni.calpoly.edu 510.324.3163 On Thursday, July 17, 2003, at 11:48 AM, Stephen Kent wrote: > Folks, > > Here is the new, proposed processing model for IPsec. Comments > welcome, of course. > > Steve > > ------ > > The current IPsec subscriber traffic processing model, as defined in > 2401, is imprecise in several respects, and it does not accommodate > some significant deployment use that have arisen, e.g., PPVPNs. Also, > just as we have created the extended sequence number facility for AH > and ESP to accommodate high speed (10Gb/s and beyond) implementations, > there are changes one can make to the processing model to better > accommodate traffic classification (for outbound traffic). Finally, > there are some simplifications one can make to the mode, consistent > with the overall push for implementation simplification. > > We first look at outbound traffic, which is where most of the proposed > changes are visible, then examine inbound traffic processing. The > focus here is on subscriber traffic, with some discussion of IKE > traffic. > > Several concepts underlie the proposed model: > > - virtual interface: every IPsec device has at least one virtual > interface, which may correspond to one physical interface (the common > case). Multiple virtual interfaces may map to a single physical > interface, e.g., for overlay nets, or one virtual interface may map to > multiple virtual interfaces. The choice of a one-to-one, many-to-one, > or one-to-many mapping for virtual to physical interfaces is a local > matter, which each implementer is free to select apropos to the > environment on which IPsec is implemented. Every virtual interface has > an ID (VID), a purely local identifier, which is used with the > forwarding function defined below, to select the virtual interface to > which outbound traffic is directed. The VID is NOT technically a > selector, because it does not need to appear in an SPD; rather it is > used to select an appropriate SPD. > > - forwarding function: to provide a clear separation between > forwarding (routing) and security decisions, an explicit forwarding > function is added. This function can be trivial, in the case where > there is only one interface (virtual or physical). It may be complex > if there are multiple interfaces and if the implementation elects to > offer a more sophisticated form of route selection. The spec makes no > assumptions about the internal operation of the function, other than > to say that the whole packet is passed to it and the output is a VID. > In turn, the VID is used to select the appropriate SPD. > > - SPD: the SPD is largely the same as currently defined. Instead of > being defined on a per interface basis, it is now per virtual > interface, and is labeled with a VID, as specified above. The new SPD > will differ in terms of the selectors allowed (consistent with IKEv2). > Rather than referring to separate SPDs for inbound vs. outbound > traffic (pre interface) we will talk in terms of entries in each SPD > being directional, i.e., there are separate inbound and outbound > entries for each SPD for each virtual interface. This makes sense > because the inbound and outbound entries are really linked. > > - SPD caches: the current processing model refers to searching the > SPD for each outbound packet to determine how to process it, and to > check inbound traffic after IPsec processing, to ensure that traffic > arriving on an SA is consistent with the selectors defined when the SA > was created. This is a potentially time consuming search process, in > both directions, because of the need to search the SPD entries in the > order specified by the administrator or user who created them. The > search process also is ambiguous as currently defined, with regard to > processing inbound packets. To simplify the process, and to allow for > very fast SA lookups, we introduce the notion of an outbound SPD cache > (on a per virtual interface basis), and the caching of inbound SPD > entries in two places. Since SPD entries may overlap, one cannot > safely cache these entries in general. Simple caching might result in > a match against a cache entry whereas a search of the SPD would have > resulted in a match against a different entry. But, if we decorrelate > the SPD, then the resulting entries can safely be cached. For outbound > traffic, each cached entry maps to an SA, or indicates that matching > traffic should be bypassed or discarded. For inbound traffic, the SPD > cache serves as the reference for the selectors to be matched against > arriving packets, or defines traffic to be bypassed or discarded. An > algorithm for decorrelation was published as an ID some time ago, and > I think there is at least one paper on the topic published as well. > 2401bis will not mandate a specific algorithm, but will include an > example in an appendix. > > With these concepts in mind, we can describe the revised model. First > we examine outbound traffic processing. (There is no separate > discussion of fragment processing for now, as we await the WG > decisions of several pending proposals re fragmentation.) > > 1. when a packet arrives from a subscriber interface, invoke the > forwarding lookup function. > > 2. match the packet headers against the SPD cache specified by the VID > from step 1 > > 3a. if there is a match, then process the packet as specified by the > matching cache entry, i.e., bypass, discard, or apply AH or ESP in the > specified mode. If IPsec processing is applied, there is a link from > the SPD cache entry to the relevant SAD entry (specifying the > algorithms, keys, SPI, etc.). IPsec processing is as previously > defined, for tunnel or transport modes and for AH or ESP, as > specified. > > 3b. if no match, search the SPD that corresponds to this cache. If the > SPD calls for bypass or discard, create a new outbound and inbound > cache entries. If the SPD entry calls for creation of an SA (pair), > the key management mechanism (e.g., IKEv2) is invoked to create the > SA. If SA creation succeeds, a new outbound cache entry is created, > along with an SAD entry, otherwise the packet is discarded, and an > error is logged, and may be signaled. (A packet that triggers an SPD > lookup MAY be discarded by the implementation, or it may be buffered > and then processed against the newly created cache entry, if one is > created.) The SAD entry contains the inbound selector values linked to > the SPD entry used to create the inbound SA, to support checking of > received traffic. > > 4. The VID assigned to the packet in step 1 (the forwarding lookup) is > used to select the interface to which the packet is directed, after > the specified processing (if any) is applied in step 3. > > Inbound processing is somewhat different from outbound processing, > largely because we use of SPIs to map IPsec traffic to SAs, vs. > performing a lookup based on traffic selector values. However, we > still have to perform traffic selector lookups for non-IPsec inbound > traffic, to determine whether this traffic is to be discarded or > bypassed. Thus an inbound IPsec cache is used to quickly process this > traffic. The description below does not include reassembly processing, > while we await a WG decision on the possibility of rejecting fragments > for SAs from specified sources. > > 1. When a packet arrives, it is tagged with a VID. This ID may be > directly mapped from a physical interface, or a lookup function may be > invoked to assign a VID, analogous to what is offered for outbound > traffic in step 1 above. Note that there is no need to tag a packet > with a VID if it is an IPsec packet directed to the IPsec > implementation. This is because there is only one SAD which applies to > all traffic, regardless of the interface. However, because SPDs are > per-interface, entries for bypass or discard traffic might be specific > to the interface via which the inbound traffic is received. If there > is no need to treat inbound traffic differently depending on the > interface upon which it arrived, the VID may be a constant. > > 2. examine the header to determine if it is addressed to the IPsec > implementations, and if so, if it appears to be for a key management > protocol. If so, direct the packet to key management processing. > > 3a. If the packet is addressed to the IPsec implementation and AH or > ESP is specified as the protocol, lookup the packet using the SPI in > the SAD. Remember that each SAD entry now includes 2-bits to specify > which fields are used to determine a match (unicast vs. multicast). If > there is no match, discard the traffic, logging the error as specified > by local management controls. If there is a match in the SAD, apply AH > or ESP as specified, using the SAD entry selected above. Then match > the packet against the inbound selectors in the SAD entry, to verify > that the received packet is appropriate for the SA via which it was > received. If there is a mismatch, log the error and signal it if a > signaling mechamism is available and enabled. > > 3b. If the packet is not addressed to the implementation, or if the > traffic is not AH or ESP, lookup the packet header in the inbound > (discard/bypass) SPD cache for this (virtual) interface. If there is a > match and the packet is to be discarded or bypassed, do so. If there > is no match, lookup the packet in the inbound SPD (for the interface > in question) and create an appropriate inbound and an outbound cache > entry. (No SAs are created in response to receipt of a packet that > requires IPsec; only bypass or discard entries can be created this > way.) > > This processing model is simpler and less vague than the old model, > and it offers the potential for higher speed processing of traffic. It > does, however, remove some functionality. For example, there is no > provision for SA bundles. It would be easy to include support for the > simple AH+ESP combination that IKEv1 was able to negotiate, and that > 2401 mandates, if that combination is still viewed as needed. However, > IKEv1 was not able to negotiate any other nested protocol combinations > and I don't think IKEv2 has addressed this problem either, especially > the notion of adding new SAs to create an SA "bundle." So, I suggest > we remove the requirement to support SA bundles, unless the WG feels > strongly otherwise. > > There is also no provision within this processing model to support > nested SAs, i.e., all IPsec processing is performed in one pass. > However, after the packet is emitted, it could be redirected through > the IPsec module via local, virtual interfaces and use of the > forwarding lookup function, to cause more than one layer of IPsec > headers to be applied or removed. Note that to accomplish this, > multiple entries would have to be created, in distinct SPDs, each > specifying a layer of IPsec processing to be applied. However, IKE > still lacks a means to negotiate this, so I suspect that only manual > configuration, or some key management mechanism not yet defined for > IPsec, would be needed to take advantage of this approach. > From owner-ipsec@lists.tislabs.com Sat Jul 19 09:58:35 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6JGwYqt003383; Sat, 19 Jul 2003 09:58:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA17947 Sat, 19 Jul 2003 12:23:31 -0400 (EDT) Message-Id: <200307191630.h6JGUM8Q021946@thunk.east.sun.com> From: Bill Sommerfeld To: Ricky Charlet cc: ipsec mailingList , Stephen Kent Subject: Re: revised IPsec processing model: Q: VID and forwarding function In-Reply-To: Your message of "Sat, 19 Jul 2003 09:09:42 PDT." <682DFC4C-BA03-11D7-B9FF-00039349B0FC@speakeasy.net> Reply-to: sommerfeld@east.sun.com Date: Sat, 19 Jul 2003 12:30:22 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > This one is an editorial quesiton: I wonder about a particular phrase > in the paragraph which begins "- virtual interface:" There is a clause > which says "or one virtual interface may map to multiple virtual > interfaces.". I suppose from the intended parallelism of the sentence > that it perhaps should have read "or one virtual interface may map to > multiple physical interfaces." That was my read of the sentance as well (actually I didn't even notice the word substitution). The case of single-vif to multiple physical interfaces is interesting for simplifying management (i.e., when all interfaces really are connected to the "the same" net, or when you have the traditional "red" vs "black" trusted vs untrusted net but multiple links to one or both are present for any number of reasons). Note also that in the case of layer-2 multiplexing (vlans, atm virtual circuits, etc.,), one layer's virtual interface is the next layer's physical interface. Perhaps we should use a term like "policy enforcement point" rather than "virtual interface"? - Bill From owner-ipsec@lists.tislabs.com Sat Jul 19 21:28:55 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K4Ssqt081547; Sat, 19 Jul 2003 21:28:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA19847 Sat, 19 Jul 2003 23:49:39 -0400 (EDT) To: "'ipsec mailingList'" Subject: Re: EAP Message Format In-reply-to: Your message of "Wed, 09 Jul 2003 07:44:14 +0200." <003b01c345dd$223232f0$292e1dc2@YnirNew> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 19 Jul 2003 18:01:49 +0200 Message-ID: <1090.1058630509@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Yoav" == Yoav Nir writes: Yoav> I'm confused. Where did you get this 4-byte length field? Current Yoav> technology does not allow 65536-byte frames, so what authentication Yoav> type would need a 4-byte length field? HIPPI has long used 64K frames :-) It is my understanding that the research community is now using even longer frames as well. As HIPPI is used in clusters and such, the likely hood of them needing to run EAP is pretty low. ] At IETF57 in Wien, Austria | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] printk("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 iQCVAwUBPxlra4qHRg3pndX9AQHrOAQAw57gS+YPR+FC+7xBFhRhwW/hhDVWveWE ZfPhkNbP3STAvyTjMlhBcjbRKaiD2dsDlEPVZyWQSqWpqCFR/JADxnLBg+QuiPng EdcYzGmS0u1u9gicInS+GaTmTIhPu+azhTo331VGnUH8RBKGQBg+RNUzFyEVReF3 5oR5Z1WxlPQ= =gQI/ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat Jul 19 21:28:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K4Swqt081548; Sat, 19 Jul 2003 21:28:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA19843 Sat, 19 Jul 2003 23:49:31 -0400 (EDT) To: ipsec@lists.tislabs.com Subject: Re: revised IPsec processing model In-reply-to: Your message of "Fri, 18 Jul 2003 16:35:37 +0900." <20030718073537.074D813@coconut.itojun.org> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Fri, 18 Jul 2003 12:26:10 +0200 Message-ID: <6748.1058523970@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "itojun" == itojun writes: >>> incompatible with IPv6 linklocal address (by changing inbound >>> interface for a packet, i.e. m->m_pkthdr.rcvif in BSD, you change >>> the scope zone). therefore i object to apply "virtual interface" >>> concept to transport mode. >> There is no plan to remove tunnel mode from the spec. The plan was to >> apply this model for both transport and tunnle modes. itojun> in that case, i would like to express concern w/ IPv6 linklocal itojun> address (the latter paragraph of mine). There is a disconnect here. Having a "virtual interface" model, does not mean that you have to have an actual virtual address. ] At IETF57 in Wien, Austria | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] printk("Just another Debian GNU/Linux using, kernel hacking, security guy");[ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPxfLQYqHRg3pndX9AQGoFAQAr6tGh2UxPGoP2vf1SB1U7KOA9ZYqIqNe NGuaVmgjxjazWQNGAjG4bX6ZpoKBnYTgFDETfcc+s8q+0PC0sfvYyiuZcTtr3K0l 0dnSU9H+oEWCNnm56vlqZLSAaRvlcFUYD2XLKARZ1xtQ0xXhGc8lgJC2HYqFg9T4 10jOsGZDIr4= =UWuT -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sun Jul 20 09:29:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KGToqt044099; Sun, 20 Jul 2003 09:29:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA21698 Sun, 20 Jul 2003 11:46:29 -0400 (EDT) Message-Id: <5.2.0.9.2.20030718112617.01f39008@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 18 Jul 2003 11:29:49 -0400 To: Stephen Kent , ipsec@lists.tislabs.com From: Russ Housley Subject: Re: revised IPsec processing model In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve: It looks good to me. I do not know if this is draft text for 2401bis. If it is, then I do have a concern about the use of terms like "IPsec packet" and "non-IPsec traffic." In this discussion, on AH and ESP are considered. IKE packets are not addressed at all in this discussion, and they are at a different layer. I would like to avoid confusion by using "AH and ESP packets" or "Layer 3 IPsec packets" to ensure that we are clear. Russ From owner-ipsec@lists.tislabs.com Sun Jul 20 12:00:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KJ0bqt059689; Sun, 20 Jul 2003 12:00:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA22163 Sun, 20 Jul 2003 14:24:28 -0400 (EDT) To: ipsec@lists.tislabs.com Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (remote) interop test target wanted From: itojun@iijlab.net Date: Mon, 21 Jul 2003 03:31:24 +0900 Message-Id: <20030720183124.0BCAF13@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk i would like to test ESP AES counter mode (draft-ietf-ipsec-ciph-aes-ctr-03.txt) AH AES XCBC MAC (draft-ietf-ipsec-ciph-aes-xcbc-mac-03.txt) on our (KAME) implementation against some other implementation. if you could set up manual SA (or two) for me, and allow me to ping/ftp/whatever your node, please let me know privately. itojun From owner-ipsec@lists.tislabs.com Sun Jul 20 21:32:37 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6L4Waqt083872; Sun, 20 Jul 2003 21:32:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA23671 Sun, 20 Jul 2003 23:54:59 -0400 (EDT) Message-ID: <3F1B6488.9000806@roc.co.in> Date: Mon, 21 Jul 2003 09:26:56 +0530 From: Ravi User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: George Hadjichristofi CC: Ipsec Subject: Re: ipsec SAs References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS perl-11 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, It depends on SPD policy you configure. If your policy selectors include only 'B' address, then using this policy,only B can be reached from A. If your policy selector include complete subnet in which 'B' belongs,then all machines in that subnet can be reached from A. Ravi George Hadjichristofi wrote: > Hi, > > I have a question about IPSec SAs. > > There is a nework such as: > A----Gateway1 ===tunnel====Gateway2 ----B > > A and B are the subnets. > Gateway 1 and 2 negotiate a tunnel such that A can communicate securely with > B. > > Based on RFC2401, does that mean that A will only be able to talk to B and > no other nodes on the network, or just that it will talk to B via a secure > tunnel and to everybody else in cleartext? > > Should A be able to talk to Gateway2? > > Thank you > George > > *********************************************************** > George C. Hadjichristofi > Graduate Student > Bradley Department of Electrical and Computer Engineering > Virginia Tech,Blacksburg,VA 24061,U.S.A > TEL:(540)-951-8936 > *********************************************************** > -- The views presented in this mail are completely mine. The company is not responsible for whatsoever. ------------------------------------------------------------------------ Ravi Kumar CH Rendezvous On Chip (i) Pvt Ltd Hyderabad, India Ph: +91-40-2335 1214 / 1175 / 1184 ROC home page From owner-ipsec@lists.tislabs.com Mon Jul 21 07:53:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LEr5qt047583; Mon, 21 Jul 2003 07:53:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00542 Mon, 21 Jul 2003 09:55:27 -0400 (EDT) Date: Sat, 19 Jul 2003 16:25:05 +0200 From: Markus Friedl To: itojun@iijlab.net Cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: revised IPsec processing model Message-ID: <20030719142505.GA31343@folly> References: <20030719105927.0423913@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030719105927.0423913@coconut.itojun.org> User-Agent: Mutt/1.4.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Sat, Jul 19, 2003 at 07:59:27PM +0900, itojun@iijlab.net wrote: > by introducing "virtual interface" and switching m->m_pkthdr.rcvif > based on the virtual interface, you will become unable to identify > peer correctly - after IPsec processing, both "fe80::1%segment1" and > "fe80::1%segment2" would become "fe80::1%ipsec". providing 1-by-1 > mapping between virtual interface and real interface does not provide > a solution, since you will now see non-IPsec traffic as sent from > "fe80::1%segment1" and IPsec traffic as sent from "fe80::1%ipsec1", > and upper layer will get confused. I don't think the 'virtual interface' needs to replace the m_pkthdr.rcvif. The virtual interface can just be attached as some kind of mbuf tag. However, I don't see a difference between having the VID as a special selectors in a single SPD and having mutiple SPDs selected by VID. -m From owner-ipsec@lists.tislabs.com Mon Jul 21 08:05:44 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LF5hqt047986; Mon, 21 Jul 2003 08:05:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00661 Mon, 21 Jul 2003 10:27:32 -0400 (EDT) Message-Id: <200307211433.h6LEXq8Q005101@thunk.east.sun.com> From: Bill Sommerfeld To: Markus Friedl cc: itojun@iijlab.net, Stephen Kent , ipsec@lists.tislabs.com Subject: Re: revised IPsec processing model In-Reply-To: Your message of "Sat, 19 Jul 2003 16:25:05 +0200." <20030719142505.GA31343@folly> Reply-to: sommerfeld@east.sun.com Date: Mon, 21 Jul 2003 10:33:52 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > However, I don't see a difference between having the VID as a > special selectors in a single SPD and having multiple SPDs selected > by VID. Indeed. There's not a whole lot of difference in terms of end result.. - Bill From owner-ipsec@lists.tislabs.com Mon Jul 21 08:12:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LFCwqt048479; Mon, 21 Jul 2003 08:12:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00714 Mon, 21 Jul 2003 10:36:20 -0400 (EDT) Message-Id: <200307211440.h6LEenof067951@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: revised IPsec processing model In-reply-to: Your message of Thu, 17 Jul 2003 14:48:15 EDT. Date: Mon, 21 Jul 2003 16:40:49 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Here is the new, proposed processing model for IPsec. Comments welcome, of course. => some comments: Several concepts underlie the proposed model: - virtual interface: every IPsec device has at least one virtual interface, ... => with scoped addresses, all the physical interfaces must belong to the same zone. In the case of link-local addresses, this means there is a one-to-one built-in mapping between interfaces which support link-local addresses (almost all in IPv6) and some kind of virtual interfaces. BTW, this can answer to Itojun's concern. - forwarding function: to provide a clear separation between forwarding (routing) and security decisions, ... => it is not clear whether the forwarding function applies only to forwarded packets (i.e., packets forwarded by a router) or this is only the "routing" part of the ip_output() procedure. With these concepts in mind, we can describe the revised model. First we examine outbound traffic processing. (There is no separate discussion of fragment processing for now, as we await the WG decisions of several pending proposals re fragmentation.) 1. when a packet arrives from a subscriber interface, invoke the forwarding lookup function. => can you define what is a subscriber interface? I am afraid the model applies only to routers, i.e., what to do with genuine traffic? Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Jul 21 17:03:53 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6M03qqt077907; Mon, 21 Jul 2003 17:03:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02705 Mon, 21 Jul 2003 19:27:35 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <20030719105927.0423913@coconut.itojun.org> References: <20030719105927.0423913@coconut.itojun.org> Date: Mon, 21 Jul 2003 10:52:55 -0400 To: itojun@iijlab.net From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 19:59 +0900 7/19/03, itojun@iijlab.net wrote: > >> in that case, i would like to express concern w/ IPv6 linklocal address >>> (the latter paragraph of mine). >>Could you elaborate a bit more on the nature of the problem? Your >>paragraph above was not enough for me, since I don't understand what >>IPv6 does in this regard absent Ipsec. Also, in which of the IPv6 >>specs is the behavior you are describing defined? > > RFC2460/2373. draft-ietf-ipv6-scoping-arch-00.txt will also give you > more information. > > with IPv6, there are not-universally-unique address defined in RFC2373. > one of them is link-local address (the other one, site-local address, > is going away so i will omit site-local from the discussion). > link-local address range is fe80::/10, and address under it is unique > on a certain link only. for instance, the following situation is > legal: > > fe80::1 > | > ==+===== ether segment1 > | > your machine > | > ==+===== ether segment2 > | > fe80::1 > > i.e. you are seeing the same address (fe80::1) on the different link > your machine is attached to. to disambiguate these machines, socket > API (RFC2553) has additional field, sin6_scope_id, in sockaddr_in6. > specifying 128bit address (fe80::1) is not enough, you have to specify > which link you are talking about (textual notation is > "fe80::1%segment1"). > > > now, many implementations use interface to identify link. BSD-based > implementation normally disambiguates incoming packet by > m->m_pkthdr.rcvif. > > by introducing "virtual interface" and switching m->m_pkthdr.rcvif > based on the virtual interface, you will become unable to identify > peer correctly - after IPsec processing, both "fe80::1%segment1" and > "fe80::1%segment2" would become "fe80::1%ipsec". providing 1-by-1 > mapping between virtual interface and real interface does not provide > a solution, since you will now see non-IPsec traffic as sent from > "fe80::1%segment1" and IPsec traffic as sent from "fe80::1%ipsec1", > and upper layer will get confused. > >itojun Thanks for the additional info. As Bill & Markus pointed out, the VID is not the same as an address, in the sense discussed above. It is an identifier largely internal to IPsec. Does Bill's suggestion of how to accommodate the VID address your concerns? Steve From owner-ipsec@lists.tislabs.com Mon Jul 21 17:03:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6M03uqt077911; Mon, 21 Jul 2003 17:03:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02695 Mon, 21 Jul 2003 19:27:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.2.0.9.2.20030718112617.01f39008@mail.binhost.com> References: <5.2.0.9.2.20030718112617.01f39008@mail.binhost.com> Date: Mon, 21 Jul 2003 10:21:16 -0400 To: Russ Housley From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:29 -0400 7/18/03, Russ Housley wrote: >Steve: > >It looks good to me. > >I do not know if this is draft text for 2401bis. If it is, then I >do have a concern about the use of terms like "IPsec packet" and >"non-IPsec traffic." In this discussion, on AH and ESP are >considered. IKE packets are not addressed at all in this >discussion, and they are at a different layer. I would like to >avoid confusion by using "AH and ESP packets" or "Layer 3 IPsec >packets" to ensure that we are clear. > >Russ Russ, yes, this is 2401bis candidate text. Good point re use of the phrase "IPsec traffic" I will change it to "ESP/AH traffic" going forward. Steve From owner-ipsec@lists.tislabs.com Mon Jul 21 17:04:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6M045qt077945; Mon, 21 Jul 2003 17:04:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02701 Mon, 21 Jul 2003 19:27:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <20030719142505.GA31343@folly> References: <20030719105927.0423913@coconut.itojun.org> <20030719142505.GA31343@folly> Date: Mon, 21 Jul 2003 11:26:41 -0400 To: Markus Friedl From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 16:25 +0200 7/19/03, Markus Friedl wrote: >On Sat, Jul 19, 2003 at 07:59:27PM +0900, itojun@iijlab.net wrote: >> by introducing "virtual interface" and switching m->m_pkthdr.rcvif >> based on the virtual interface, you will become unable to identify >> peer correctly - after IPsec processing, both "fe80::1%segment1" and >> "fe80::1%segment2" would become "fe80::1%ipsec". providing 1-by-1 >> mapping between virtual interface and real interface does not provide >> a solution, since you will now see non-IPsec traffic as sent from >> "fe80::1%segment1" and IPsec traffic as sent from "fe80::1%ipsec1", >> and upper layer will get confused. > >I don't think the 'virtual interface' needs to replace the >m_pkthdr.rcvif. The virtual interface can just be attached as some >kind of mbuf tag. > >However, I don't see a difference between having the VID >as a special selectors in a single SPD and having mutiple SPDs >selected by VID. You are correct that one could choose to implement a single SPD in which the VID was another "selector." However, I avoided presenting this as the basic model for at least two reasons that I can recall now: - in 2401 we talked in terms of per interface SPDs, so it is more consistent with the old model to talk in terms of per-virtual interface SPDs - we have generally reserved the term "selector" for data items extracted from packet headers. the VID is not part of a packet header. Steve From owner-ipsec@lists.tislabs.com Mon Jul 21 17:05:40 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6M05eqt078046; Mon, 21 Jul 2003 17:05:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02717 Mon, 21 Jul 2003 19:28:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <200307191522.h6JFMt8Q021016@thunk.east.sun.com> References: <200307191522.h6JFMt8Q021016@thunk.east.sun.com> Date: Mon, 21 Jul 2003 11:27:51 -0400 To: sommerfeld@east.sun.com From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:22 -0400 7/19/03, Bill Sommerfeld wrote: > > by introducing "virtual interface" and switching m->m_pkthdr.rcvif >> based on the virtual interface, you will become unable to identify >> peer correctly - after IPsec processing, both "fe80::1%segment1" and >> "fe80::1%segment2" would become "fe80::1%ipsec". providing 1-by-1 >> mapping between virtual interface and real interface does not provide >> a solution, since you will now see non-IPsec traffic as sent from >> "fe80::1%segment1" and IPsec traffic as sent from "fe80::1%ipsec1", >> and upper layer will get confused. > >Maybe we just need a name other than "virtual interface" for the ipsec >entity. > >I understood the proposal as for a new kind of entity, the >"2401-bis-ipsec-virtual-interface" which is different from the >"real" interface as seen by IP. > >If you needed to record the 2401-bis-vif in packet metadata in >addition to the physical interface, you'd put it in a parallel field >to the BSD/KAME m->m_pkthdr.rcvif. > > - Bill Thanks Bill. I am not knowledgeable enough about the details of host implementations to have provided an answer like this. Steve From owner-ipsec@lists.tislabs.com Mon Jul 21 17:05:46 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6M05kqt078051; Mon, 21 Jul 2003 17:05:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA02712 Mon, 21 Jul 2003 19:28:32 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <200307191630.h6JGUM8Q021946@thunk.east.sun.com> References: <200307191630.h6JGUM8Q021946@thunk.east.sun.com> Date: Mon, 21 Jul 2003 12:04:39 -0400 To: sommerfeld@east.sun.com From: Stephen Kent Subject: Re: revised IPsec processing model: Q: VID and forwarding function Cc: ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:30 -0400 7/19/03, Bill Sommerfeld wrote: > > This one is an editorial quesiton: I wonder about a particular phrase >> in the paragraph which begins "- virtual interface:" There is a clause >> which says "or one virtual interface may map to multiple virtual >> interfaces.". I suppose from the intended parallelism of the sentence >> that it perhaps should have read "or one virtual interface may map to >> multiple physical interfaces." > >That was my read of the sentance as well (actually I didn't even >notice the word substitution). The case of single-vif to multiple >physical interfaces is interesting for simplifying management (i.e., >when all interfaces really are connected to the "the same" net, or >when you have the traditional "red" vs "black" trusted vs untrusted >net but multiple links to one or both are present for any number of >reasons). Your text is an accurate reflection of the sort of notions that motivated the virtual/physical interface mapping I mentioned. > >Note also that in the case of layer-2 multiplexing (vlans, atm virtual >circuits, etc.,), one layer's virtual interface is the next layer's >physical interface. > >Perhaps we should use a term like "policy enforcement point" rather >than "virtual interface"? I am not absolutely wedded to the term "virtual interface" but it is primarily a routing construct and so I hesitate to use the term you mention above. I fear that "policy" is too generic a term these days to be a useful modifier anymore. Steve From owner-ipsec@lists.tislabs.com Mon Jul 21 19:15:08 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6M2F7qt084422; Mon, 21 Jul 2003 19:15:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA03402 Mon, 21 Jul 2003 21:40:34 -0400 (EDT) Message-ID: <541402FFDC56DA499E7E13329ABFEA8701EA9889@SARATOGA.netscreen.com> From: Gregory Lebovitz To: "Barbara Fraser (E-mail)" , Charlie_Kaufman@notesdev.ibm.com Cc: ipsec@lists.tislabs.com Subject: IKEv2 issue tracker: Identifier Date: Mon, 21 Jul 2003 18:46:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Barbara, At the lounge BOF in Vienna we discussed one item that I believe was missing from the IKEv2 issues tracker, the need for an Identifier. Paul summarized it as "Add an identifier for rekeying so you know which IKE you are rekeying." Did this get added yet? Gregory. !! NETSCREEN HAS MOVED !! New Contact Info: 408.543.8002 805 11th Ave, Bldg 3 Sunnyvale, CA 94089 +*******************++********************+ Gregory M. Lebovitz Staff Architect, CTO Office NetScreen Technologies, Inc. Ph: 408.543.8002 E: gregory@netscreen.com Pg: page.gregory@netscreen.com NASDAQ: NSCN +*******************++********************+ From owner-ipsec@lists.tislabs.com Mon Jul 21 19:29:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6M2TGqt084730; Mon, 21 Jul 2003 19:29:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA03459 Mon, 21 Jul 2003 21:57:28 -0400 (EDT) To: Stephen Kent Cc: ipsec@lists.tislabs.com In-reply-to: kent's message of Mon, 21 Jul 2003 10:52:55 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: revised IPsec processing model Cc: itojun@iijlab.net From: Jun-ichiro itojun Hagino Date: Tue, 22 Jul 2003 11:04:19 +0900 Message-Id: <20030722020419.422BF793@starfruit.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Thanks for the additional info. As Bill & Markus pointed out, the VID >is not the same as an address, in the sense discussed above. It is an >identifier largely internal to IPsec. Does Bill's suggestion of how >to accommodate the VID address your concerns? i see, i guess we need to find some term other than "virtual interface". my another concern is that the text talks too much about implementation details - for instance, SPD cache implementation could vary by implementation to implementation. with our implementation we cache SPD on connected tcp/udp control block (inpcb). maybe put less (but sufficient) text in 2401bis, and add VID and caching details as appendix? itojun From owner-ipsec@lists.tislabs.com Mon Jul 21 19:43:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6M2hfqt085208; Mon, 21 Jul 2003 19:43:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA03555 Mon, 21 Jul 2003 22:13:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <20030722020419.422BF793@starfruit.itojun.org> References: <20030722020419.422BF793@starfruit.itojun.org> Date: Mon, 21 Jul 2003 22:19:01 -0400 To: Jun-ichiro itojun Hagino From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:04 +0900 7/22/03, Jun-ichiro itojun Hagino wrote: > >Thanks for the additional info. As Bill & Markus pointed out, the VID >>is not the same as an address, in the sense discussed above. It is an >>identifier largely internal to IPsec. Does Bill's suggestion of how >>to accommodate the VID address your concerns? > > i see, i guess we need to find some term other than "virtual >interface". > > my another concern is that the text talks too much about implementation > details - for instance, SPD cache implementation could vary by > implementation to implementation. with our implementation we cache > SPD on connected tcp/udp control block (inpcb). > maybe put less (but sufficient) text in 2401bis, and add VID >and caching > details as appendix? > >itojun There is no need to focus on caching in a host, because you can use the tcp/udp blocks, as you note. But for BITS, BITW, and security gateways, caching is critical and thus requires discussion. I will revise the text to make clear this distinction. Steve From owner-ipsec@lists.tislabs.com Mon Jul 21 19:43:48 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6M2hmqt085218; Mon, 21 Jul 2003 19:43:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA03560 Mon, 21 Jul 2003 22:13:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <682DFC4C-BA03-11D7-B9FF-00039349B0FC@speakeasy.net> References: <682DFC4C-BA03-11D7-B9FF-00039349B0FC@speakeasy.net> Date: Mon, 21 Jul 2003 22:20:15 -0400 To: Ricky Charlet From: Stephen Kent Subject: Re: revised IPsec processing model: Q: VID and forwarding function Cc: ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:09 -0700 7/19/03, Ricky Charlet wrote: >Hello, > > I'm trying to understand the motivations for VIDs and >explicit forwarding function separation. Currently, I am guessing >(based on your first paragraph) that these new features enable >PPVPNs and/or overlay networks. If so, how so? If not, what new >functionality is enabled by these features? There was a long series of off-list and post-WG meetings discussions involving folks had expressed concern over how to modify IPsec processing to better accommodate PPVPNs and overlay nets. The grouops included Mark Duffy, Greg Lebovitz, and Joe Touch I developed this model and vetted it with this group some months ago. You are right, of course, that we need to explain how the use of a VID and a forwarding function helps in these circumstances. Let me try to provide a top level explanation. PPVPNs and overlay nets use virtual interfaces in hosts or in network aggregation devices as part of creating virtual nets out of virtual links. So I think it's natural to introduce VIDs as a way to refer to these interfaces, at least within IPsec. I was told that it is necessary to allow for a full packet lookup in selecting the VID, hence the description of that lookup function. There was a desire to use the VID to select the appropriate SPD, to preserve the SPD-per-interface model that we already had, and which seems to be useful in some number of contexts. The model in 2401 was ambiguous about whether one performed a forwarding lookup before or after SPD selection, which was not good for a standard. I'll defer to the folks mentioned above to add their own views about the ways and extent to which this model satisfies their basic requirements. > This one is an editorial quesiton: I wonder about a >particular phrase in the paragraph which begins "- virtual >interface:" There is a clause which says "or one virtual interface >may map to multiple virtual interfaces.". I suppose from the >intended parallelism of the sentence that it perhaps should have >read "or one virtual interface may map to multiple physical >interfaces." Whoops! I did mean to say one virtual interface may map to multiple physical interfaces. Sorry for the typo. > Also, the last paragraph implies a loop behavior for IPsec processing: > 1. consult forwarding function to get VID > 2. do IPsec processing as per VIDs SPD > 3. go to 1. I added the last paragraph to try to accommodate folks who do want to loop through IPsec more than once, something I personally have assurance concerns about. But, you are right that the description was too vague, and needs an exit condition. I was assuming that when a packet had completed the IPsec crypto processing, that the VID would be used to lookup an entry in another table, different from the one used to make the packet->VID assignment. This table would direct the packet to the right virtual interface, based on the VID carried through the IPsec processing. This last forwarding function could cause a loop for additional processing, or could cause the packet to exit the device. I assumed that it is the responsibility of the local admin to ensure that the table does not result in a non-terminating loop. As I noted, there is no way in IKE to negotiate the management of this table, to cause multiple passes through IPsec processing, which is one reason I am not excited about the option. However, manual configuration could be used. Note that after a packet passes through IPsec (not bypass traffic), it will be changed, and so it is easy to imagine that a different VID will be returned the second time through, if there is any loop. For example, the next protocol field would be AH or ESP, not TCP or UPD. > The exit condition for this loop is not specified. Let's >consider outbound processing for an example. If the forwarding >function is aware of only routing information (i.e. it is separated >from security policy decisions) then it seems to me that this loop >will get stuck: > 1. forwarding function says exit VID is X > 2. spd says this packet is allowed to pass > 3. go to 1. > > Certainly as implementors, we could all thing of our own >little ways to break this loop. But shouldn't we have uniform >guidance? My observation is that step 3 above is not what would necessarily happen, because a separate forwarding function should be used after IPsec processing. Steve From owner-ipsec@lists.tislabs.com Tue Jul 22 04:19:56 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MBJtqt034320; Tue, 22 Jul 2003 04:19:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id GAA05318 Tue, 22 Jul 2003 06:39:44 -0400 (EDT) Message-Id: <200307221046.h6MAkc8Q023877@thunk.east.sun.com> From: Bill Sommerfeld To: Stephen Kent cc: ipsec mailingList Subject: Re: revised IPsec processing model: Q: VID and forwarding function In-Reply-To: Your message of "Mon, 21 Jul 2003 12:04:39 EDT." Reply-to: sommerfeld@east.sun.com Date: Tue, 22 Jul 2003 06:46:38 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > >Perhaps we should use a term like "policy enforcement point" rather > >than "virtual interface"? > > I am not absolutely wedded to the term "virtual interface" but it is > primarily a routing construct and so I hesitate to use the term you > mention above. I fear that "policy" is too generic a term these days > to be a useful modifier anymore. "naming is hard". In a fit of whimsy, I propose "IPsec tollbooth" - Bill From owner-ipsec@lists.tislabs.com Tue Jul 22 05:30:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MCUwqt039541; Tue, 22 Jul 2003 05:30:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA05503 Tue, 22 Jul 2003 07:56:00 -0400 (EDT) Message-ID: <3F1C3CD4.4090603@nomadiclab.com> Date: Mon, 21 Jul 2003 22:19:48 +0300 From: Pekka Nikander Reply-To: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: saag@mit.edu, ipsec@lists.tislabs.com, rpsec@ietf.org Subject: New mailing list to discuss IP layer signalling security Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk As agreed at SAAG at IETF-57, Vienna, we now have a mailing list to discuss IP layer signalling security. The aim is to discuss the problem, and find out whether there would be enough of interest to look at the more generic problem to warrant an IETF working group. The ML is kindly hosted by VPNC (thanks, Paul). To subscribe, either access the web page at http://www.vpnc.org/ietf-ipsigsec/index.html or simply send a message to with the single word subscribe in the body of the message. To give people time to subscribe to the list, it is not yet possible to post to the list. Once posting becomes possible I will send a separate note to the *list* (not here). The mailing list is chartered as follows. If you think that this chartering is not what was earlier discussed at the saag ML or at the meeting, please send e-mail to me. ------------------------------ Initial ML Charter: The ietf-ipsigsec mailing list is for discussing standizing protocols or protocol components for securing IP layer signalling protocols, such as IPv6 Neighbor Discovery and Autoconfiguration, Mobile IP, Mobile IP optimization protocols, and perhaps some routing protocols. This mailing list may turn into an IETF Working Group. As a background, experience has shown that the IPsec Authentication Header (AH), as it is currently standardized, does not cover the requirements. Hence, for example, the Mobile IPv6 Route Optimization and Secure IPv6 Neighbor Discovery (SEND) both use more-or-less ad hoc, protocol specific mechanisms to reach their security goals. One purpose of this mailing list is to see if something can be learned from these experiences. The topics, to be discussed on the mailing list, are the following: * Address the need for generic protocol components that could be used to secure current and future IP layer (internetworking layer) signalling protocols. Examples of components to consider include Return Routability (RR) and Cryptographically Generated Addresses (CGA). * Progress towards a security model that would cover all or most IP layer signalling protocol security requirements. The focus is on situations where one cannot rely on existing or supposed security infrastructures. * Understand how the proposed separation of the identifier and locator roles of IP addresses may affect the security requirements in the IP layer signalling scope. * Based on the topics above, consider the applicability of the IPsec AH protocol. That is, it is allowed to state that there seems to be no use of AH within this space, or that AH seems to be a perfect match to the needs, as long as such statements are well founded and based on discussion on the items above. However, it is strictly out of scope to state opinions on AH without basing those opinions on clearly argumented technical discussion, or to discuss the applicability of AH for any other purpose but IP layer signalling security. From owner-ipsec@lists.tislabs.com Tue Jul 22 05:32:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MCWcqt039650; Tue, 22 Jul 2003 05:32:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA05557 Tue, 22 Jul 2003 08:00:49 -0400 (EDT) From: vikagupta@hss.hns.com Subject: Exporting symbols into linux kernel? To: ipsec@lists.tislabs.com Date: Tue, 22 Jul 2003 15:10:40 +0530 Message-ID: X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26, 2002) at 22/07/2003 03:09:36 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi All I saw your question on the internet regarding exporting symbols in linux kernel. Even i have done similar thing and i am also facing the same problem. Since you have faced this problem in past so i hope you must have got its solution as well. Can you please share the same with me . I am attaching the question once again for quick reference. Thanks in advance Regards Vikash Gupta ================================================== hi all I have a problem. I am tampering the tcp/ip source code. In the /net/ipv4/ip_input.c file i want to call my function which is defined in another .c file and declared in another .h file(declared as extern function), and I will include this .h file in the ip_input.c. But this doesn't work? Do i need to export symbols? Do i have to make an entry in netsyms.c and what about /proc/kysms ?? Please tell me what should i do. I think exporting symbols might help. If i need to export symbols, then how should i go about doing it. ========================================================= "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." From owner-ipsec@lists.tislabs.com Tue Jul 22 07:26:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MEQrqt051302; Tue, 22 Jul 2003 07:26:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA06176 Tue, 22 Jul 2003 09:43:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Tue, 22 Jul 2003 09:51:50 -0400 To: ipsec mailingList From: Karen Seo Subject: IPsec -- AH-bis, ESP-bis, ESN addendum Cc: kseo@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hello, We have submitted the latest drafts of 3 IPsec specs to the IETF publications folks: 1. IP Authentication Header -- draft-ietf-ipsec-rfc2402bis-04.txt 2. IP Encapsulating Security Payload (ESP) -- draft-ietf-ipsec-esp-v3-06.txt 3. Extended Sequence Number Addendum to IPsec DOI for ISAKMP -- draft-ietf-ipsec-esn-addendum-02.txt I made a couple of minor edits since the last set of emails (7/16 listing changes) were sent to this list. These were just clarifications/fixes. Thank you, Karen From owner-ipsec@lists.tislabs.com Tue Jul 22 10:52:03 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MHq2qt061201; Tue, 22 Jul 2003 10:52:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA06940 Tue, 22 Jul 2003 13:07:56 -0400 (EDT) Message-ID: <3F1D70E5.EBEDB431@fid4.com> Date: Tue, 22 Jul 2003 13:14:13 -0400 From: "Michael C. Cambria" X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: ipsec mailingList CC: Stephen Kent , Ricky Charlet Subject: Re: revised IPsec processing model: Q: VID and forwarding function References: <682DFC4C-BA03-11D7-B9FF-00039349B0FC@speakeasy.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: > > At 9:09 -0700 7/19/03, Ricky Charlet wrote: [deleted] > > This one is an editorial quesiton: I wonder about a > >particular phrase in the paragraph which begins "- virtual > >interface:" There is a clause which says "or one virtual interface > >may map to multiple virtual interfaces.". I suppose from the > >intended parallelism of the sentence that it perhaps should have > >read "or one virtual interface may map to multiple physical > >interfaces." > > Whoops! I did mean to say one virtual interface may map to multiple > physical interfaces. Sorry for the typo. This text change could be read to rule out the possibility of a virtual interface mapping to another virtual interface (e.g. overlay on an overlay)? Is this the goal? > > Also, the last paragraph implies a loop behavior for IPsec processing: > > 1. consult forwarding function to get VID > > 2. do IPsec processing as per VIDs SPD > > 3. go to 1. > > I added the last paragraph to try to accommodate folks who do want to > loop through IPsec more than once, something I personally have > assurance concerns about. But, you are right that the description was > too vague, and needs an exit condition. I was assuming that when a > packet had completed the IPsec crypto processing, that the VID would > be used to lookup an entry in another table, different from the one > used to make the packet->VID assignment. This table would direct the > packet to the right virtual interface, based on the VID carried > through the IPsec processing. This last forwarding function could > cause a loop for additional processing, or could cause the packet to > exit the device. I'm confused by what you say above. To me the exit of the loop was clear. Your reference to looking up an entry in _another_ table is what I don't understand. For tunnel mode, after Step 3, there will be an new IP header. This header is used in Step 1 to obtain a new VID. This VID will either have IPsec enabled or not. If not, IPsec is done, loop exited. If IPsec is enabled, the new IP header must match an entry in this VID's SPD. The matching entry will either drop, bypass or apply IPsec. For drop or bypass the loop ends. For apply, we do loop again, but at some point, we hit a VID that has a bypass policy or that doesn't have IPsec enabled at all. Where would the other table you refer to exist? Thanks, MikeC From owner-ipsec@lists.tislabs.com Tue Jul 22 14:30:44 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MLUhqt071818; Tue, 22 Jul 2003 14:30:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07545 Tue, 22 Jul 2003 16:51:42 -0400 (EDT) Message-Id: <200307222058.h6MKwf8Q028095@thunk.east.sun.com> From: Bill Sommerfeld To: Gregory Lebovitz cc: "Barbara Fraser (E-mail)" , Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com Subject: Re: IKEv2 issue tracker: Identifier In-Reply-To: Your message of "Mon, 21 Jul 2003 18:46:53 PDT." <541402FFDC56DA499E7E13329ABFEA8701EA9889@SARATOGA.netscreen.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 22 Jul 2003 16:58:41 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk looks like it's there as: https://roundup.machshav.com/ipsec/issue64 - Bill From owner-ipsec@lists.tislabs.com Wed Jul 23 08:46:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NFkBqt051367; Wed, 23 Jul 2003 08:46:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA11189 Wed, 23 Jul 2003 10:58:10 -0400 (EDT) Message-ID: <00ac01c35127$9552ecc0$b64f728c@timl> From: "Yi-Wen Liu" To: Subject: IPsec SA endpoint update Date: Wed, 23 Jul 2003 22:34:51 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01C3516A.A2049B60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C3516A.A2049B60 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Hi folks: If a user changes his network attachment and gets new IP address = from DHCP,=20 does IPsec support SA endpoint update? ps: The user is on external network and connects to intranet = though VPN Gateway. Anybody knows? Thanks for your answer. Best Regrads, Tim Liu ------=_NextPart_000_00A9_01C3516A.A2049B60 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable
Hi folks:
        If a user changes his = network=20 attachment and gets new IP address from DHCP,
           do= es=20 IPsec support SA endpoint update?
 
        ps: The user is on = external=20 network and connects to intranet though VPN Gateway.
 
        Anybody knows? Thanks for = your=20 answer.
 
Best Regrads,
Tim Liu
------=_NextPart_000_00A9_01C3516A.A2049B60-- From owner-ipsec@lists.tislabs.com Thu Jul 24 05:39:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OCdtqt039635; Thu, 24 Jul 2003 05:39:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA15051 Thu, 24 Jul 2003 07:48:20 -0400 (EDT) Message-ID: <3F1F0437.1020905@sockeye.com> Date: Wed, 23 Jul 2003 17:55:03 -0400 From: John Shriver Organization: Sockeye Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: change in values of Auth Method from IKEv1 to IKEv2? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm actively trying to clean up my Textual Conventions MIB. Perhaps foolishly, I'm even hoping to make it relevant to both IKEv1 and IKEv2. Some of the differences are merely annoying (all the Transform Types were changed from 2 bytes to 1 byte), but can be documented. (Although this will complicate the IANA's work!) But Auth Method (in Section 3.8 of /tmp/draft-ietf-ipsec-ikev2-08.txt) is totally recoded. Is this intended to be addressed by Issue 6 in the Issues Registry? (There's not much detail there.) Is it intended to recode this consistent with the values in Appendix A of RFC 2409 and the IANA registry? If not, I have to make separate Textual Conventions for the two, which MIB designers will find most distasteful, not to mention the IANA... From owner-ipsec@lists.tislabs.com Thu Jul 24 05:42:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OCgGqt039883; Thu, 24 Jul 2003 05:42:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA15104 Thu, 24 Jul 2003 08:05:11 -0400 (EDT) Message-Id: <200307241209.h6OC9Pof078410@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Yi-Wen Liu" cc: ipsec@lists.tislabs.com Subject: Re: IPsec SA endpoint update In-reply-to: Your message of Wed, 23 Jul 2003 22:34:51 +0800. <00ac01c35127$9552ecc0$b64f728c@timl> Date: Thu, 24 Jul 2003 14:09:25 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: If a user changes his network attachment and gets new IP address from DHCP, does IPsec support SA endpoint update? => not yet (there is a post-IKEv2 scheduled activity to provide this feature, today you have at least to rekey). Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Jul 24 10:48:18 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OHmHqt060862; Thu, 24 Jul 2003 10:48:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16379 Thu, 24 Jul 2003 13:03:53 -0400 (EDT) Message-Id: <5.2.0.9.0.20030724113200.01feed80@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 24 Jul 2003 13:09:33 -0400 To: Stephen Kent , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: revised IPsec processing model In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, and thank you. I think this is a good direction to go in, though I think it should be taken a little further. Comments embedded below. Thanks, Mark At 02:48 PM 7/17/2003 -0400, Stephen Kent wrote: >Folks, > >Here is the new, proposed processing model for IPsec. Comments welcome, >of course. > >Steve > >------ > >The current IPsec subscriber traffic processing model, as defined in 2401, >is imprecise in several respects, and it does not accommodate some >significant deployment use that have arisen, e.g., PPVPNs. Also, just as >we have created the extended sequence number facility for AH and ESP to >accommodate high speed (10Gb/s and beyond) implementations, there are >changes one can make to the processing model to better accommodate traffic >classification (for outbound traffic). Finally, there are some >simplifications one can make to the mode, consistent with the overall push >for implementation simplification. > >We first look at outbound traffic, which is where most of the proposed >changes are visible, then examine inbound traffic processing. The focus >here is on subscriber traffic, with some discussion of IKE traffic. > >Several concepts underlie the proposed model: > >- virtual interface: every IPsec device has at least one virtual >interface, which may correspond to one physical interface (the common >case). Multiple virtual interfaces may map to a single physical interface, >e.g., for overlay nets, or one virtual interface may map to multiple >virtual interfaces. The choice of a one-to-one, many-to-one, or >one-to-many mapping for virtual to physical interfaces is a local matter, >which each implementer is free to select apropos to the environment on >which IPsec is implemented. Every virtual interface has an ID (VID), a >purely local identifier, which is used with the forwarding function >defined below, to select the virtual interface to which outbound traffic >is directed. The VID is NOT technically a selector, because it does not >need to appear in an SPD; rather it is used to select an appropriate SPD. > >- forwarding function: to provide a clear separation between forwarding >(routing) and security decisions, an explicit forwarding function is >added. This function can be trivial, in the case where there is only one >interface (virtual or physical). It may be complex if there are multiple >interfaces and if the implementation elects to offer a more sophisticated >form of route selection. The spec makes no assumptions about the internal >operation of the function, other than to say that the whole packet is >passed to it and the output is a VID. In turn, the VID is used to select >the appropriate SPD. Regarding the virtual interface and the forwarding function: A close reading shows that the "forwarding function" may be an arbitrary function of the packet (and hopefully of meta-information about the packet, such as where it was received from). However, the term itself is fairly loaded and will suggest destination-address-based IP forwarding to many readers. Moreover, 2401bis should IMO permit a separation between where a packet is forwarded to, and what SPD is applied to it. This for example to support a device that has one uplink to the Internet and provides protection for different LANs using different SPDs: in this case the SPD to use for outbound processing might be implied by the interface the packet came in on rather than by the interface it goes out on. So I would propose that instead of a "forwarding function" we have a "SPD selection function" that is done on a per-packet basis. Like the forwarding function described above this function is a local matter for the IPsec implementation. It might be a mapping from interface to SPD (RFC2401 model), or any other function of the packet fields and packet meta-information. With this change the concept of virtual interface could be dropped entirely (my preference, since the SPDs would not necessarily correspond to the logical IP network interfaces that the term suggests to me) or the virtual interface could be considered as a highly abstract thing that is one-to-one with an SPD but has no particular relationship to where the packet is forwarded, making the VID into an "SPD identifier". > - SPD: the SPD is largely the same as currently defined. Instead > of being defined on a per interface basis, it is now per virtual > interface, and is labeled with a VID, as specified above. The new SPD > will differ in terms of the selectors allowed (consistent with IKEv2). > Rather than referring to separate SPDs for inbound vs. outbound traffic > (pre interface) we will talk in terms of entries in each SPD being > directional, i.e., there are separate inbound and outbound entries for > each SPD for each virtual interface. This makes sense because the inbound > and outbound entries are really linked. Yes, that's great. In fact, aren't the inbound and outbound entries actually constrained to be symmetrical reflections of one another, at least if IKE is to be used? > - SPD caches: the current processing model refers to searching > the SPD for each outbound packet to determine how to process it, and to > check inbound traffic after IPsec processing, to ensure that traffic > arriving on an SA is consistent with the selectors defined when the SA > was created. This is a potentially time consuming search process, in both > directions, because of the need to search the SPD entries in the order > specified by the administrator or user who created them. The search > process also is ambiguous as currently defined, with regard to processing > inbound packets. To simplify the process, and to allow for very fast SA > lookups, we introduce the notion of an outbound SPD cache (on a per > virtual interface basis), and the caching of inbound SPD entries in two > places. Since SPD entries may overlap, one cannot safely cache these > entries in general. Simple caching might result in a match against a > cache entry whereas a search of the SPD would have resulted in a match > against a different entry. But, if we decorrelate the SPD, then the > resulting entries can safely be cached. For outbound traffic, each cached > entry maps to an SA, or indicates that matching traffic should be > bypassed or discarded. For inbound traffic, the SPD cache serves as the > reference for the selectors to be matched against arriving packets, or > defines traffic to be bypassed or discarded. An algorithm for > decorrelation was published as an ID some time ago, and I think there is > at least one paper on the topic published as well. 2401bis will not > mandate a specific algorithm, but will include an example in an appendix. The discussion of decorrelating the SPD, and maintaining a cache, seems a lot like implementation design. I would introduce these in 2401bis only if it significantly simplifies the description of the required behavior (which it's not clear to me that it does here). >With these concepts in mind, we can describe the revised model. First we >examine outbound traffic processing. (There is no separate discussion of >fragment processing for now, as we await the WG decisions of several >pending proposals re fragmentation.) > >1. when a packet arrives from a subscriber interface, invoke the >forwarding lookup function. Per my comment above, I would propose changing this to: 1. when a packet arrives at the IPsec implementation and it is determined that the packet is to be protected as an outbound packet, invoke the SPD selection function. >2. match the packet headers against the SPD cache specified by the VID >from step 1 > >3a. if there is a match, then process the packet as specified by the >matching cache entry, i.e., bypass, discard, or apply AH or ESP in the >specified mode. If IPsec processing is applied, there is a link from the >SPD cache entry to the relevant SAD entry (specifying the algorithms, >keys, SPI, etc.). IPsec processing is as previously defined, for tunnel or >transport modes and for AH or ESP, as specified. > >3b. if no match, search the SPD that corresponds to this cache. If the SPD >calls for bypass or discard, create a new outbound and inbound cache >entries. If the SPD entry calls for creation of an SA (pair), the key >management mechanism (e.g., IKEv2) is invoked to create the SA. If SA >creation succeeds, a new outbound and inbound? > cache entry is created, along with an SAD entry, otherwise the packet is > discarded, and an error is logged, and may be signaled. (A packet that > triggers an SPD lookup MAY be discarded by the implementation, or it may > be buffered and then processed against the newly created cache entry, if > one is created.) The SAD entry contains the inbound selector values > linked to the SPD entry used to create the inbound SA, to support > checking of received traffic. > >4. The VID assigned to the packet in step 1 (the forwarding lookup) is >used to select the interface to which the packet is directed, after the >specified processing (if any) is applied in step 3. I have 2 comments on that. Per my first comment above, I believe the IP forwarding decision should be independent of the SPD selection decision. Also, for packets that have IPsec applied, in tunnel mode, the IP destination address of the new packet may now be different. It is my belief that an IPsec implementation that is also a router should at this point perform a new IP forwarding decision, based on the new address. >Inbound processing is somewhat different from outbound processing, largely >because we use of SPIs to map IPsec traffic to SAs, vs. performing a >lookup based on traffic selector values. However, we still have to perform >traffic selector lookups for non-IPsec inbound traffic, to determine >whether this traffic is to be discarded or bypassed. Thus an inbound IPsec >cache is used to quickly process this traffic. The description below does >not include reassembly processing, while we await a WG decision on the >possibility of rejecting fragments for SAs from specified sources. > >1. When a packet arrives, it is tagged with a VID. This ID may be directly >mapped from a physical interface, or a lookup function may be invoked to >assign a VID, analogous to what is offered for outbound traffic in step 1 >above. Just as for outbound processing, I urge that the model here should have a SPD selection function that is a local matter and may or may not be based on arriving and/or departing interface. > Note that there is no need to tag a packet with a VID if it is an IPsec > packet directed to the IPsec implementation. This is because there is > only one SAD which applies to all traffic, regardless of the interface. > However, because SPDs are per-interface, entries for bypass or discard > traffic might be specific to the interface via which the inbound traffic > is received. If there is no need to treat inbound traffic differently > depending on the interface upon which it arrived, the VID may be a constant. > >2. examine the header to determine if it is addressed to the IPsec >implementations, and if so, if it appears to be for a key management >protocol. If so, direct the packet to key management processing. > >3a. If the packet is addressed to the IPsec implementation and AH or ESP >is specified as the protocol, lookup the packet using the SPI in the SAD. >Remember that each SAD entry now includes 2-bits to specify which fields >are used to determine a match (unicast vs. multicast). If there is no >match, discard the traffic, logging the error as specified by local >management controls. If there is a match in the SAD, apply AH or ESP as >specified, using the SAD entry selected above. Then match the packet >against the inbound selectors in the SAD entry, to verify that the >received packet is appropriate for the SA via which it was received. If >there is a mismatch, log the error and signal it if a signaling mechamism >is available and enabled. > >3b. If the packet is not addressed to the implementation, or if the >traffic is not AH or ESP, lookup the packet header in the inbound >(discard/bypass) SPD cache for this (virtual) interface. If there is a >match and the packet is to be discarded or bypassed, do so. If there is no >match, lookup the packet in the inbound SPD (for the interface in >question) and create an appropriate inbound and an outbound cache entry. >(No SAs are created in response to receipt of a packet that requires >IPsec; only bypass or discard entries can be created this way.) > >This processing model is simpler and less vague than the old model, and it >offers the potential for higher speed processing of traffic. It does, >however, remove some functionality. For example, there is no provision >for SA bundles. It would be easy to include support for the simple AH+ESP >combination that IKEv1 was able to negotiate, and that 2401 mandates, if >that combination is still viewed as needed. However, IKEv1 was not able to >negotiate any other nested protocol combinations and I don't think IKEv2 >has addressed this problem either, especially the notion of adding new SAs >to create an SA "bundle." So, I suggest we remove the requirement to >support SA bundles, unless the WG feels strongly otherwise. You won't hear any complaints from me. >There is also no provision within this processing model to support nested >SAs, i.e., all IPsec processing is performed in one pass. However, after >the packet is emitted, it could be redirected through the IPsec module via >local, virtual interfaces and use of the forwarding lookup function, to >cause more than one layer of IPsec headers to be applied or removed. Note >that to accomplish this, multiple entries would have to be created, in >distinct SPDs, each specifying a layer of IPsec processing to be applied. >However, IKE still lacks a means to negotiate this, so I suspect that only >manual configuration, or some key management mechanism not yet defined for >IPsec, would be needed to take advantage of this approach. I don't see why IKE as-is could not negotiate this, so long as it allows negotiating an SA to protect payload packets that are ESP or AH protocol. It then becomes a local issue of what SPD(s) a packet is subjected to as it flows through the IPsec device, and any/all SAs needed would be independently negotiated. From owner-ipsec@lists.tislabs.com Thu Jul 24 13:25:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OKPZqt071569; Thu, 24 Jul 2003 13:25:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16963 Thu, 24 Jul 2003 15:44:06 -0400 (EDT) Message-Id: <200307241832.OAA20383@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-ctr-05.txt Date: Thu, 24 Jul 2003 14:32:47 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --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 : Using AES Counter Mode With IPsec ESP Author(s) : R. Housley Filename : draft-ietf-ipsec-ciph-aes-ctr-05.txt Pages : 19 Date : 2003-7-24 This document describes the use of AES Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload confidentiality mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ciph-aes-ctr-05.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-ciph-aes-ctr-05.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: <2003-7-24122621.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-ctr-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-24122621.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Jul 24 13:25:36 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OKPZqt071568; Thu, 24 Jul 2003 13:25:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16970 Thu, 24 Jul 2003 15:44:40 -0400 (EDT) Message-Id: <200307241832.OAA20362@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-ccm-04.txt Date: Thu, 24 Jul 2003 14:32:43 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --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 : Using AES CCM Mode With IPsec ESP Author(s) : R. Housley Filename : draft-ietf-ipsec-ciph-aes-ccm-04.txt Pages : 13 Date : 2003-7-24 This document describes the use of AES CCM Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, connectionless integrity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ciph-aes-ccm-04.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-ciph-aes-ccm-04.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: <2003-7-24122610.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-ccm-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-24122610.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 25 13:38:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PKcuqt086117; Fri, 25 Jul 2003 13:38:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21229 Fri, 25 Jul 2003 15:46:32 -0400 (EDT) Message-Id: <200307251928.PAA17778@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esp-v3-06.txt Date: Fri, 25 Jul 2003 15:28:05 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --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 : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent Filename : draft-ietf-ipsec-esp-v3-06.txt Pages : 42 Date : 2003-7-25 This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and Ipv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document is based upon RFC 2406 (November 1998). Section 7 provides a brief review of the differences between this document and RFC 2406. Comments should be sent to Stephen Kent (kent@bbn.com). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-esp-v3-06.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-esp-v3-06.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: <2003-7-25152058.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v3-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v3-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-25152058.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 25 13:40:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PKe1qt086148; Fri, 25 Jul 2003 13:40:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21223 Fri, 25 Jul 2003 15:45:56 -0400 (EDT) Message-Id: <200307251928.PAA17760@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-rfc2402bis-04.txt Date: Fri, 25 Jul 2003 15:28:01 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --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 : IP Authentication Header Author(s) : S. Kent Filename : draft-ietf-ipsec-rfc2402bis-04.txt Pages : 32 Date : 2003-7-25 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document is based upon RFC 2402 (November 1998) [KA98c]. Section 7 provides a brief review of the differences between this document and RFC 2402. Comments should be sent to Stephen Kent (kent@bbn.com). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2402bis-04.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-rfc2402bis-04.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: <2003-7-25152047.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2402bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-25152047.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Fri Jul 25 13:40:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PKe1qt086149; Fri, 25 Jul 2003 13:40:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21217 Fri, 25 Jul 2003 15:45:28 -0400 (EDT) Message-Id: <200307251927.PAA17741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-esn-addendum-02.txt Date: Fri, 25 Jul 2003 15:27:56 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --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 : Extended Sequence Number Addendum to IPsec DOI for ISAKMP Author(s) : S. Kent Filename : draft-ietf-ipsec-esn-addendum-02.txt Pages : 5 Date : 2003-7-25 The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for the Internet Security Association and Key Management Protocol(ISAKMP). These extensions support negotiation of the use of traditional 32-bit sequence numbers or extended 64-bit sequence numbers for a particular AH or ESP security association. Comments should be sent to Stephen Kent (kent@bbn.com). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esn-addendum-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-esn-addendum-02.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-esn-addendum-02.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: <2003-7-25152033.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esn-addendum-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esn-addendum-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-25152033.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jul 28 06:24:35 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SDOZqt057430; Mon, 28 Jul 2003 06:24:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02052 Mon, 28 Jul 2003 08:28:33 -0400 (EDT) X-Originating-IP: [172.169.89.223] X-Originating-Email: [isalekul@hotmail.com] From: "Salekul Islam" To: Cc: "Sagor" Subject: Sliding Window Mechanism using ESN in AH Date: Fri, 25 Jul 2003 16:11:01 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C352C7.573EAA40" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 25 Jul 2003 20:07:16.0015 (UTC) FILETIME=[5814BBF0:01C352E8] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C352C7.573EAA40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am trying to understand the Anti-Replay mechanism using Extended (64 = bit) Sequence Number (ESN) proposed in the latest draft of IP = Authentication Header. There is one Pseudo-code example at the end of = the draft in Apeendix B2.3. I have two questions.=20 First of all, I have studied the draft very carefully. What I have = understood is we are using 64 bit counter in both ends (sender and = receiver) while sending only lower 32 bits. The receiver will maintain = its own higher bits and concanate received 32 bits to get the whole 64 = bits. These things are clear and straight forward. But, if we follow the = given algorithm in the appendix, I am facing one problem. In the sliding = window mechanism,=20 1. Anything left side window =3D> reject 2. Anything inside window =3D> check whether it was received or not and = if not received then receive otherwise reject 3. Anything right side window =3D> receive and right shift the window Acording to the draft, I have no problem in case 2 and 3 but when we = receive any packet that is left side the window, we are considering it = as a valid sequence which is in the next bit space and we are forwarding = our window. It is possible if don't consider any attacker or any replay = inside the network. But if any attacker generate a false packet with = such a sequence number, certainly the algorithm given in the present = draft will receive the packet and forward the window to next bit space = (2^32 -1).=20 My second point is, I think one line is missing in the given algorithm = and I have added that line in the following pseudo-code: =20 If (Tl >=3D W - 1) Case A ....... Else Case B If (Seql >=3D Tl - W + 1) ................. Else If (Seql <=3D Tl) Seqh =3D Th /* Add this line here */ If (pass replay check) ...... Else reject packet I am expecting that someone will make me clear if I get it wrong. Thank you for your consideration, Salekul ------=_NextPart_000_0016_01C352C7.573EAA40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am trying to understand the = Anti-Replay=20 mechanism using Extended (64 bit) Sequence Number (ESN) proposed in = the=20 latest draft of IP Authentication Header. There is one = Pseudo-code=20 example at the end of the draft in Apeendix B2.3. I have two = questions.=20 First of all, I have studied the = draft very=20 carefully. What I have understood is we are using 64 bit counter in both = ends=20 (sender and receiver) while sending only lower 32 bits. The receiver = will=20 maintain its own higher bits and concanate received 32 bits to get the = whole 64=20 bits. These things are clear and straight forward. But, if we follow the = given=20 algorithm in the appendix, I am facing one problem. In the sliding = window=20 mechanism, 1. Anything left side window = =3D>=20 reject 2. Anything inside window =3D> = check whether=20 it was received or not and if not received then receive otherwise=20 reject 3. Anything right side window = =3D> receive=20 and right shift the window Acording to the draft, I have no = problem in=20 case 2 and 3 but when we receive any packet that is left side the = window, we are=20 considering it as a valid sequence which is in the next bit space = and we=20 are forwarding our window. It is possible if don't consider any attacker = or any=20 replay inside the network. But if any attacker generate a false packet = with such=20 a sequence number, certainly the algorithm given in the present = draft will=20 receive the packet and forward the window to next bit space (2^32 = -1).=20 My second point is, I think = one line is=20 missing in the given algorithm and I have added that line in the = following=20 pseudo-code: If (Tl >=3D W - 1) = =20 Case A = ....... Else = =20 Case = B If (Seql = >=3D Tl - W +=20 1) = =20 ................. = Else = If=20 (Seql <=3D Tl) &nbs= p; Seqh=20 =3D Th /* Add this line here */ = =20 If (pass replay check) &nbs= p;=20 ...... = =20 Else reject packet I am expecting that = someone will make=20 me clear if I get it wrong. Thank you for your=20 consideration, Salekul ------=_NextPart_000_0016_01C352C7.573EAA40-- From owner-ipsec@lists.tislabs.com Mon Jul 28 08:15:18 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SFFHqt066717; Mon, 28 Jul 2003 08:15:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA02458 Mon, 28 Jul 2003 10:25:58 -0400 (EDT) X-Originating-IP: [172.203.199.244] X-Originating-Email: [isalekul@hotmail.com] From: "Salekul Islam" To: Cc: "Sagor" Subject: Sliding Window Mechanism using ESN in AH (sending again) Date: Wed, 30 Jul 2003 09:58:35 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C35681.248D0F20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 28 Jul 2003 13:54:50.0507 (UTC) FILETIME=[D05C0DB0:01C3550F] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C35681.248D0F20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 I am trying to understand the Anti-Replay mechanism using Extended (64 = bit) Sequence Number (ESN) proposed in the latest draft of IP = Authentication Header. There is one pseudo-code example at the end of = the draft in Apeendix B2.3. I have two questions.=20 First of all, I have studied the draft very carefully. What I have = understood is we are using 64 bit counter in both ends (sender and = receiver) while sending only lower 32 bits. The receiver will maintain = its own higher bits and concanate received 32 bits to get the whole 64 = bits. These things are clear and straight forward. But, if I follow the = given algorithm in the appendix, I am facing one problem. In the sliding = window mechanism,=20 1. Anything left side window =3D> reject packet 2. Anything inside window =3D> check whether it was received or not = and if not received then receive otherwise reject=20 3. Anything right side window =3D> receive and right shift the = window=20 Acording to the draft, I have no problem in case 2 and 3 but when we = receive any packet that is left side the window, we are considering it = as a valid sequence which is in the next bit space and we are forwarding = our window. It is possible if don't consider any attacker or any replay = inside the network. But if any attacker generate a false packet with = such a sequence number, certainly the algorithm given in the present = draft will receive the packet and forward the window to next bit space = (2^32 =3D1). The same thing may happen, if a delayed packet inside the = network is received after a while. My second point is, I think one line is missing in the given algorithm = and I have added that line in the following pseudo-code:=20 If (Tl >=3D W - 1) /* Case A */ ......=20 Else /* Case B*/=20 If (Seql =3D=3D Tl - W + 1)=20 .................=20 Else=20 If (Seql <=3D Tl)=20 Seqh =3D Th /* Add this line here */=20 If (pass replay check)=20 ......=20 Else reject packet=20 I am expecting that someone will make me clear if I get it wrong.=20 Thank you for your consideration,=20 Salekul=20 ------=_NextPart_000_0025_01C35681.248D0F20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I am trying to understand the Anti-Replay mechanism using Extended = (64 bit)=20 Sequence Number (ESN) proposed in the latest draft of IP Authentication = Header.=20 There is one pseudo-code example at the end of the draft in Apeendix = B2.3. I=20 have two questions. First of all, I have studied the draft very carefully. What I have=20 understood is we are using 64 bit counter in both ends (sender and = receiver)=20 while sending only lower 32 bits. The receiver will maintain its own = higher bits=20 and concanate received 32 bits to get the whole 64 bits. These things = are clear=20 and straight forward. But, if I follow the given algorithm in the = appendix,=20 I am facing one problem. In the sliding window mechanism, 1. Anything left side window =3D> reject = packet 2. Anything inside window =3D> check whether = it was=20 received or not and if not received then receive otherwise reject 3. Anything right side window =3D> receive = and right=20 shift the window Acording to the draft, I have no problem in case 2 and 3 but when = we=20 receive any packet that is left side the window, we are considering it = as a=20 valid sequence which is in the next bit space and we are forwarding our = window.=20 It is possible if don't consider any attacker or any replay inside the = network.=20 But if any attacker generate a false packet with such a sequence number, = certainly the algorithm given in the present draft will receive the = packet and=20 forward the window to next bit space (2^32 =3D1). The same thing may = happen, if a=20 delayed packet inside the network is received after a while. My second point is, I think one line is missing in the given = algorithm and=20 I have added that line in the following pseudo-code: If (Tl >=3D W - 1) /* Case A */ ...... Else /* Case B*/ If (Seql =3D=3D Tl - W + 1) ................. = Else If (Seql <=3D Tl) &n= bsp; Seqh=20 =3D Th /* Add this line here */ &n= bsp; If=20 (pass replay check) = =20 ...... &n= bsp; Else=20 reject packet I am expecting that someone will make me clear if I get it wrong. = Thank you for your consideration, Salekul ------=_NextPart_000_0025_01C35681.248D0F20-- From owner-ipsec@lists.tislabs.com Mon Jul 28 08:43:34 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6SFhYqt068361; Mon, 28 Jul 2003 08:43:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA02599 Mon, 28 Jul 2003 11:00:15 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 28 Jul 2003 11:03:10 -0400 To: "Salekul Islam" From: Stephen Kent Subject: Re: Sliding Window Mechanism using ESN in AH (sending again) Cc: , "Sagor" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:58 -0400 7/30/03, Salekul Islam wrote: > > >Hi, >I am trying to understand the Anti-Replay mechanism using Extended (64 = >bit) Sequence Number (ESN) proposed in the latest draft of IP = >Authentication Header. There is one pseudo-code example at the end of = >the draft in Apeendix B2.3. I have two questions.=20 > >First of all, I have studied the draft very carefully. What I have = >understood is we are using 64 bit counter in both ends (sender and = >receiver) while sending only lower 32 bits. The receiver will maintain = >its own higher bits and concanate received 32 bits to get the whole 64 = >bits. These things are clear and straight forward. But, if I follow the = >given algorithm in the appendix, I am facing one problem. In the sliding = >window mechanism,=20 > 1. Anything left side window =3D> reject packet > 2. Anything inside window =3D> check whether it was received or not = >and if not received then receive otherwise reject=20 > 3. Anything right side window =3D> receive and right shift the = >window=20 >Acording to the draft, I have no problem in case 2 and 3 but when we = >receive any packet that is left side the window, we are considering it = >as a valid sequence which is in the next bit space and we are forwarding = >our window. It is possible if don't consider any attacker or any replay = >inside the network. But if any attacker generate a false packet with = >such a sequence number, certainly the algorithm given in the present = >draft will receive the packet and forward the window to next bit space = >(2^32 =3D1). The same thing may happen, if a delayed packet inside the = >network is received after a while. We do not change our idea of the upper bits of the window UNLESS the packet passes the integrity check. So the sort of attack you mention is not possible, unless the attacker can generate a packet with a valid ICV and a modified sequence number, which is not feasible given a good integrity algorithm. Steve From owner-ipsec@lists.tislabs.com Mon Jul 28 17:36:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6T0a9qt097776; Mon, 28 Jul 2003 17:36:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA04697 Mon, 28 Jul 2003 19:45:06 -0400 (EDT) From: Sebastian Wain To: ipsec@lists.tislabs.com Subject: ipsec compatibility issues Date: Mon, 28 Jul 2003 20:51:51 -0300 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307282051.51322.sebastian_wain@gmx.net> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear ipsec Members, There is currently some compatibility issues using ipsec connecting the following platforms? - Microsoft Windows 2K. - AIX 5.1. - Solaris 8 (with and without sun crypto accelerator 4000). Thank You Sebastian Wain -- Sebastian Wain - http://swain.webframe.org From owner-ipsec@lists.tislabs.com Tue Jul 29 10:18:38 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6THIbqt072903; Tue, 29 Jul 2003 10:18:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA07621 Tue, 29 Jul 2003 12:26:18 -0400 (EDT) Message-Id: <200307291614.MAA27668@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-aes-xcbc-prf-00.txt Date: Tue, 29 Jul 2003 12:14:44 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --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 : The AES-XCBC-PRF-128 algorithm for IKE Author(s) : P. Hoffman Filename : draft-ietf-ipsec-aes-xcbc-prf-00.txt Pages : 0 Date : 2003-7-29 Some implementations of IPsec may want to use a pseudo-random function derived from AES. This document describes such an algorithm, called AES-XCBC-PRF-128. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-aes-xcbc-prf-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-aes-xcbc-prf-00.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-aes-xcbc-prf-00.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: <2003-7-29122701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-aes-xcbc-prf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-aes-xcbc-prf-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-29122701.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jul 30 06:11:08 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UDB8qt063959; Wed, 30 Jul 2003 06:11:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11616 Wed, 30 Jul 2003 08:27:52 -0400 (EDT) From: Internet-Drafts@ietf.org X-PMX-From: ;owner-ietf-announce@ietf.org; X-PMX-To: 4;;;; X-MSI-From: ;owner-ietf-announce@ietf.org; X-MSI-To: 4;;;; Message-Id: <200307291614.MAA27668@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-aes-xcbc-prf-00.txt Date: Tue, 29 Jul 2003 12:14:44 -0400 X-ATT-Spam: Gauge=XXXXIII, Probability=43%, Report='NO_REAL_NAME, TO_MALFORMED, SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02' X-OriginalArrivalTime: 29 Jul 2003 18:38:34.0054 (UTC) FILETIME=[9D98EE60:01C35600] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --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 : The AES-XCBC-PRF-128 algorithm for IKE Author(s) : P. Hoffman Filename : draft-ietf-ipsec-aes-xcbc-prf-00.txt Pages : 0 Date : 2003-7-29 Some implementations of IPsec may want to use a pseudo-random function derived from AES. This document describes such an algorithm, called AES-XCBC-PRF-128. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-aes-xcbc-prf-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-aes-xcbc-prf-00.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-aes-xcbc-prf-00.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: <2003-7-29122701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-aes-xcbc-prf-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-aes-xcbc-prf-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-29122701.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jul 30 06:13:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UDDMqt064337; Wed, 30 Jul 2003 06:13:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA11667 Wed, 30 Jul 2003 08:36:56 -0400 (EDT) Message-Id: <200307301241.IAA28690@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ui-suites-02.txt Date: Wed, 30 Jul 2003 08:41:02 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --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 : Cryptographic Suites for IPsec Author(s) : P. Hoffman Filename : draft-ietf-ipsec-ui-suites-02.txt Pages : 5 Date : 2003-7-29 The IPsec, IKE, and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKE version 1, or with IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ui-suites-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ui-suites-02.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-ui-suites-02.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: <2003-7-29141012.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ui-suites-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ui-suites-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-29141012.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Wed Jul 30 09:06:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UG6bqt078662; Wed, 30 Jul 2003 09:06:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA12485 Wed, 30 Jul 2003 11:24:51 -0400 (EDT) Message-Id: <200307301530.h6UFUxof002582@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: IKEv2 CERT #13 Date: Wed, 30 Jul 2003 17:30:59 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In draft-ietf-ipsec-ikev2-08.txt there are some new certificate encodings, include the "Hash and URL of PKIX bundle" #13. The text is more accurate than in IKEv1, for instance the common #4 (X.509 Certificate - Signature) is defined as the BER encoding of a X.509 certificate (a "X.509 public key certificate" would be perfect). The #13 content is defined by: Hash and URL of PKIX bundle (13) contains a 20 octet SHA-1 hash of a PKIX certificate bundle followed by a variable length URL the resolves to the BER encoded certificate bundle itself. The bundle is a BER encoded SEQUENCE of certificates and CRLs. I have a concern with the last statement: a SEQUENCE of certificates and CRLs is not a valid ASN.1 definition, even as interpreted as a SEQUENCE of CHOICES between certificates and CRLs because both certificates and CRLs are SIGNED SEQUENCEs. Note that nearly anything more specified should work, so this is easy to fix: my concern is this has to be fixed. Regards Francis.Dupont@enst-bretagne.fr PS: a SET seems to be better than a SEQUENCE (and avoid the "what is in front" question). PPS: questions for IKEv1 implementors: how do you handle multiple certificates (aka certificate chains). Type #1 (pkcs7 aka CMS) is an obvious answer, if it is heavily used why not move to last CMS specs, i.e., RFC 3369? From owner-ipsec@lists.tislabs.com Wed Jul 30 10:53:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UHrOqt084568; Wed, 30 Jul 2003 10:53:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA12965 Wed, 30 Jul 2003 13:08:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F1D70E5.EBEDB431@fid4.com> References: <682DFC4C-BA03-11D7-B9FF-00039349B0FC@speakeasy.net> <3F1D70E5.EBEDB431@fid4.com> Date: Wed, 30 Jul 2003 13:15:09 -0400 To: "Michael C. Cambria" From: Stephen Kent Subject: Re: revised IPsec processing model: Q: VID and forwarding function Cc: ipsec mailingList Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 13:14 -0400 7/22/03, Michael C. Cambria wrote: >Stephen Kent wrote: >> >> At 9:09 -0700 7/19/03, Ricky Charlet wrote: > >[deleted] > >> > This one is an editorial quesiton: I wonder about a >> >particular phrase in the paragraph which begins "- virtual >> >interface:" There is a clause which says "or one virtual interface >> >may map to multiple virtual interfaces.". I suppose from the >> >intended parallelism of the sentence that it perhaps should have >> >read "or one virtual interface may map to multiple physical >> >interfaces." >> >> Whoops! I did mean to say one virtual interface may map to multiple >> physical interfaces. Sorry for the typo. > >This text change could be read to rule out the possibility of a virtual >interface mapping to another virtual interface (e.g. overlay on an >overlay)? Is this the goal? that was not my intent. so yes, the entry in the table could be for a virtual interface, or for a physical interface. > >> > Also, the last paragraph implies a loop behavior for IPsec >>processing: >> > 1. consult forwarding function to get VID >> > 2. do IPsec processing as per VIDs SPD >> > 3. go to 1. >> >> I added the last paragraph to try to accommodate folks who do want to >> loop through IPsec more than once, something I personally have >> assurance concerns about. But, you are right that the description was >> too vague, and needs an exit condition. I was assuming that when a >> packet had completed the IPsec crypto processing, that the VID would >> be used to lookup an entry in another table, different from the one >> used to make the packet->VID assignment. This table would direct the >> packet to the right virtual interface, based on the VID carried >> through the IPsec processing. This last forwarding function could >> cause a loop for additional processing, or could cause the packet to >> exit the device. > >I'm confused by what you say above. To me the exit of the loop was >clear. Your reference to looking up an entry in _another_ table is what >I don't understand. > >For tunnel mode, after Step 3, there will be an new IP header. This >header is used in Step 1 to obtain a new VID. I did not intend that one looped back to step 1 after applying the new header. Also, in transport mode the header may differ only in the value of the next protocol field. So, yes, one could loop back to step 1, OR one could perform another lookup which might have the same effect as goig to step 1 or might use a different table entirely. >This VID will either have IPsec enabled or not. If not, IPsec is done, >loop exited. If IPsec is enabled, the new IP header must match an entry >in this VID's SPD. The matching entry will either drop, bypass or apply >IPsec. For drop or bypass the loop ends. For apply, we do loop again, >but at some point, we hit a VID that has a bypass policy or that doesn't >have IPsec enabled at all. > >Where would the other table you refer to exist? There has been no discussion of a virtual interface having IPsec enabled or not. Rather the SPD for a VID has entries that specify what to do with all traffic, which would translate into the equivalent statement ONLY for some possible configurations of an SPD. remember, an SPD has entries that cover ALL possible traffic, not just traffic to which IPsec is applied. Steve From owner-ipsec@lists.tislabs.com Wed Jul 30 13:05:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UK5Hqt094143; Wed, 30 Jul 2003 13:05:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA13551 Wed, 30 Jul 2003 15:28:42 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20030724113200.01feed80@email> References: <5.2.0.9.0.20030724113200.01feed80@email> Date: Wed, 30 Jul 2003 15:33:06 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, responses inline to your comments: >Regarding the virtual interface and the forwarding function: > >A close reading shows that the "forwarding function" may be an >arbitrary function of the packet (and hopefully of meta-information >about the packet, such as where it was received from). However, the >term itself is fairly loaded and will suggest >destination-address-based IP forwarding to many readers. Moreover, >2401bis should IMO permit a separation between where a packet is >forwarded to, and what SPD is applied to it. This for example to >support a device that has one uplink to the Internet and provides >protection for different LANs using different SPDs: in this case the >SPD to use for outbound processing might be implied by the interface >the packet came in on rather than by the interface it goes out on. The intent is that the forwarding function can use any data from the packet. I'm open to suggestions for other names for the function, but I think Joe Touch suggested this one, and he definitely intended it to cover the broader set of possible inputs. The question of one SPD, or an SPD per (virtual) interface is a separate matter. Before introducing virtual interfaces in the processing model, we had one SPD per physical interface. So, I just maintained this part of the model going forward, and doing what seems to be the obvious, logical extension. So, from a "preserve the status quo unless the WG expresses consensus otherwise ..." perspective, I will plan to retain the per-virtual interface SPD model for now. >So I would propose that instead of a "forwarding function" we have a >"SPD selection function" that is done on a per-packet basis. Like >the forwarding function described above this function is a local >matter for the IPsec implementation. It might be a mapping from >interface to SPD (RFC2401 model), or any other function of the >packet fields and packet meta-information. With this change the >concept of virtual interface could be dropped entirely (my >preference, since the SPDs would not necessarily correspond to the >logical IP network interfaces that the term suggests to me) or the >virtual interface could be considered as a highly abstract thing >that is one-to-one with an SPD but has no particular relationship to >where the packet is forwarded, making the VID into an "SPD >identifier". I don't understand the reasoning here. We have been told that it is inappropriate (unduly restrictive?) to have the SPD embody forwarding info, hence the introduction of the forwarding function and the embodying of its output in a VID value that can be used both for SPD selection and to carry forward with the packet to control where it goes after IPsec processing. >> - SPD: the SPD is largely the same as currently defined. >>Instead of being defined on a per interface basis, it is now per >>virtual interface, and is labeled with a VID, as specified above. >>The new SPD will differ in terms of the selectors allowed >>(consistent with IKEv2). Rather than referring to separate SPDs for >>inbound vs. outbound traffic (pre interface) we will talk in terms >>of entries in each SPD being directional, i.e., there are separate >>inbound and outbound entries for each SPD for each virtual >>interface. This makes sense because the inbound and outbound >>entries are really linked. > >Yes, that's great. In fact, aren't the inbound and outbound entries >actually constrained to be symmetrical reflections of one another, >at least if IKE is to be used? The entries need not be symmetric in all cases, because SPD entries cover ALL traffic: IPsec, bypass, and discard. >> >The discussion of decorrelating the SPD, and maintaining a cache, >seems a lot like implementation design. I would introduce these in >2401bis only if it significantly simplifies the description of the >required behavior (which it's not clear to me that it does here). How one performs decorrelation is an implementation detail, but I found that I needed to call out a cache explicitly to clarify how processing was done. And, we cannot cache entries unless we decorrelate them. That's why the description is stated in its current form. >>With these concepts in mind, we can describe the revised model. >>First we examine outbound traffic processing. (There is no >>separate discussion of fragment processing for now, as we await the >>WG decisions of several pending proposals re fragmentation.) >> >>1. when a packet arrives from a subscriber interface, invoke the >>forwarding lookup function. > >Per my comment above, I would propose changing this to: > >1. when a packet arrives at the IPsec implementation and it is >determined that the packet is to be protected as an outbound packet, >invoke the SPD selection function. I am not comfortable with this, for several reasons. First, we disagree about the use of a function to select an SPD, vs. selecting an interface with an SPD. Second, I found it too difficult to explain how to do the processing without introducing caches, especially for outbound traffic. >> >> >>3b. if no match, search the SPD that corresponds to this cache. If >>the SPD calls for bypass or discard, create a new outbound and >>inbound cache entries. If the SPD entry calls for creation of an SA >>(pair), the key management mechanism (e.g., IKEv2) is invoked to >>create the SA. If SA creation succeeds, a new outbound > >and inbound? There is no inbound SPD cache for IPsec traffic. The SPD data in put in the SAD entry and inbound IPsec traffic is looked up in the SAD. >>4. The VID assigned to the packet in step 1 (the forwarding lookup) >>is used to select the interface to which the packet is directed, >>after the specified processing (if any) is applied in step 3. > >I have 2 comments on that. >Per my first comment above, I believe the IP forwarding decision >should be independent of the SPD selection decision. >Also, for packets that have IPsec applied, in tunnel mode, the IP >destination address of the new packet may now be different. It is >my belief that an IPsec implementation that is also a router should >at this point perform a new IP forwarding decision, based on the new >address. No to the first comment. yes to the second, which is why I amended the model, in response to other comments, to include a second lookup. >>Inbound processing is somewhat different from outbound processing, >>largely because we use of SPIs to map IPsec traffic to SAs, vs. >>performing a lookup based on traffic selector values. However, we >>still have to perform traffic selector lookups for non-IPsec >>inbound traffic, to determine whether this traffic is to be >>discarded or bypassed. Thus an inbound IPsec cache is used to >>quickly process this traffic. The description below does not >>include reassembly processing, while we await a WG decision on the >>possibility of rejecting fragments for SAs from specified sources. >> >>1. When a packet arrives, it is tagged with a VID. This ID may be >>directly mapped from a physical interface, or a lookup function may >>be invoked to assign a VID, analogous to what is offered for >>outbound traffic in step 1 above. > >Just as for outbound processing, I urge that the model here should >have a SPD selection function that is a local matter and may or may >not be based on arriving and/or departing interface. See my responses to this issue above. >> Note that there is no need to tag a packet with a VID if it is an >>IPsec packet directed to the IPsec implementation. This is because >>there is only one SAD which applies to all traffic, regardless of >>the interface. However, because SPDs are per-interface, entries for >>bypass or discard traffic might be specific to the interface via >>which the inbound traffic is received. If there is no need to treat >>inbound traffic differently depending on the interface upon which >>it arrived, the VID may be a constant. The VID may be a constant, and that trivial implementation of the lookup function is fine for an implementation that does not support multiple virtual interfaces. There is no intent to mandate such support; rather the notion is that IF the device natively supports multiple virtual interfaces, THEN this is how IPsec will accommodate them. >>There is also no provision within this processing model to support >>nested SAs, i.e., all IPsec processing is performed in one pass. >>However, after the packet is emitted, it could be redirected >>through the IPsec module via local, virtual interfaces and use of >>the forwarding lookup function, to cause more than one layer of >>IPsec headers to be applied or removed. Note that to accomplish >>this, multiple entries would have to be created, in distinct SPDs, >>each specifying a layer of IPsec processing to be applied. However, >>IKE still lacks a means to negotiate this, so I suspect that only >>manual configuration, or some key management mechanism not yet >>defined for IPsec, would be needed to take advantage of this >>approach. > >I don't see why IKE as-is could not negotiate this, so long as it >allows negotiating an SA to protect payload packets that are ESP or >AH protocol. It then becomes a local issue of what SPD(s) a packet >is subjected to as it flows through the IPsec device, and any/all >SAs needed would be independently negotiated. IKE, as-is, negotiates one pair of SAs at a time, and has not means to communicate the intent of one side to bind together different SAs negotiated independently, as best I know. So, rather than saying that there might be some magic way to express this through SPD entries, I was suggesting that we cleanly abandon it if IKE cannot negotiate it. Otherwise we have so many ways to have things not work despite successful IKE-level negotiation ... Steve From owner-ipsec@lists.tislabs.com Wed Jul 30 14:39:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ULdcqt098504; Wed, 30 Jul 2003 14:39:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13825 Wed, 30 Jul 2003 17:05:02 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200307211440.h6LEenof067951@givry.rennes.enst-bretagne.fr> References: <200307211440.h6LEenof067951@givry.rennes.enst-bretagne.fr> Date: Wed, 30 Jul 2003 17:11:35 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 16:40 +0200 7/21/03, Francis Dupont wrote: > In your previous mail you wrote: > > Here is the new, proposed processing model for IPsec. Comments > welcome, of course. > >=> some comments: > > Several concepts underlie the proposed model: > > - virtual interface: every IPsec device has at least one virtual > interface, ... > >=> with scoped addresses, all the physical interfaces must belong >to the same zone. In the case of link-local addresses, this means >there is a one-to-one built-in mapping between interfaces which >support link-local addresses (almost all in IPv6) and some kind of >virtual interfaces. BTW, this can answer to Itojun's concern. As I mentioned in my earlier messages, I don't understand the internals of an IPv6 host implementation well enough to appreciate these issues. I am assuming that the responses from other folks about how to interpret the VID concept in this context will suffice. > > - forwarding function: to provide a clear separation between > forwarding (routing) and security decisions, ... > >=> it is not clear whether the forwarding function applies only >to forwarded packets (i.e., packets forwarded by a router) or >this is only the "routing" part of the ip_output() procedure. I do tend to think in terms of BITW/BITS and SG implementations of IPsec, so that prejudice may be showing here. The intent of the forwarding function, in a host environment and absent IPsec, would be to select the interface to which the packet would be forwarded. So, I think this maps to the "routing part ..." as you noted above. > With these concepts in mind, we can describe the revised model. First > we examine outbound traffic processing. (There is no separate > discussion of fragment processing for now, as we await the WG > decisions of several pending proposals re fragmentation.) > > 1. when a packet arrives from a subscriber interface, invoke the > forwarding lookup function. > >=> can you define what is a subscriber interface? I am afraid the >model applies only to routers, i.e., what to do with genuine traffic? I was thinking in terms of the interface via which an outbound packet is initially received. so, in a host, this is the interface form which upper layer protocols present packets to the IP layer. In a SG, it the the interface hat connects to the network that we think of as being "behind" the security gateway. Steve From owner-ipsec@lists.tislabs.com Wed Jul 30 14:56:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6ULuLqt099523; Wed, 30 Jul 2003 14:56:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA13954 Wed, 30 Jul 2003 17:22:59 -0400 (EDT) Message-ID: <3F2838C4.CC8A3B21@cisco.com> Date: Wed, 30 Jul 2003 14:29:40 -0700 From: Tom Hu Reply-To: tomhu@cisco.com X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf ipsec Subject: NAT-T, IKEv2, Vendor ID, port floating?? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, In IKEv1, peers should exchange vendor ID to know each other capability of NAT-T. In IKEv2, NAT-T implementation is optional. Should we exchange Vendor ID (NAT-T) at Initial exchange? If the answer is yes, that means we have Vendor ID with NAT-Detect payload on the Initial exchange? We should know the order of payload at the message. Another question is that Initiator and Responder exchange the NAT-D to find the NAT existence at Initial Exchange. Does it mean at the AUTH exchange, both peers should float the port to 4500? Thanks, Tom Hu From owner-ipsec@lists.tislabs.com Thu Jul 31 02:50:29 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6V9oSqt059782; Thu, 31 Jul 2003 02:50:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA16298 Thu, 31 Jul 2003 05:04:36 -0400 (EDT) Message-Id: <200307310910.h6V9Afof005498@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: tomhu@cisco.com cc: ietf ipsec Subject: Re: NAT-T, IKEv2, Vendor ID, port floating?? In-reply-to: Your message of Wed, 30 Jul 2003 14:29:40 PDT. <3F2838C4.CC8A3B21@cisco.com> Date: Thu, 31 Jul 2003 11:10:41 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: In IKEv2, NAT-T implementation is optional. => this is in fact unclear: - is the support of UDP port 4500 mandatory? Current text says it is only when NAT-T is supported. As when there is no listener at port 4500 the initiator gets an ICMP port unreachable, IMHO we can keep the document idea that no support of port 4500 implies no NAT-T support. - is the support of NAT detection mandatory? For some other reasons (implicit peer address protection) I stronly believe it should be mandatory when the IKE_SA_INIT is done over port 500 and to answer the next point it should be mandatory in all cases. - does the support of UDP port 4500 imply the support of NAT-T? I don't think so because a responder can reject the NAT-T in IKE_AUTH, i.e., I makes a distinction between no NAT-T support and disabled NAT-T support: real no NAT-T support is just inconvenience, NAT-T should be supported but can be disabled for policy reasons for instance. Note the NAT detection works for both the initiator and the responder even only the initiator use it, so the next point is: - does the use of UDP port 4500 imply the use of NAT-T? As the NAT detection (which I want to make mandatory) is reliable for both peers, this doesn't really matter but the document should be clarified about this point. Should we exchange Vendor ID (NAT-T) at Initial exchange? => I don't think so: IKEv2 assumes NAT-T support (which should be permanently disabled when it is not really implemented). If the answer is yes, that means we have Vendor ID with NAT-Detect payload on the Initial exchange? We should know the order of payload at the message. => this is a generic question: what is the order of payloads? Even this is a "Clarified required ordering for payloads" in changes (:-), the only specifications are in sections 1 and 2 (the document says "the figures in section 2" ??). IMHO we should get a rule like notifications first, vendor IDs last. Another question is that Initiator and Responder exchange the NAT-D to find the NAT existence at Initial Exchange. Does it mean at the AUTH exchange, both peers should float the port to 4500? => yes, the document is (this time :-) very clear: The IKE initiator MUST check these payloads (NAT-D) if present and if they do not match the addresses in the outer packet MUST tunnel all future IKE, ESP, and AH packets associated with this IKE_SA over UDP port 4500. as the NAT-D is in IKE_SA_INIT, IKE_AUTH is included in the future IKE packets. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Jul 31 07:43:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VEhNqt088321; Thu, 31 Jul 2003 07:43:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA17370 Thu, 31 Jul 2003 10:03:19 -0400 (EDT) Message-Id: <200307311358.JAA26046@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ui-suites-03.txt Date: Thu, 31 Jul 2003 09:58:40 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --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 : Cryptographic Suites for IPsec Author(s) : P. Hoffman Filename : draft-ietf-ipsec-ui-suites-03.txt Pages : 5 Date : 2003-7-31 The IPsec, IKE, and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKE version 1, or with IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ui-suites-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ui-suites-03.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-ui-suites-03.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: <2003-7-31101347.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ui-suites-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ui-suites-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-31101347.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Thu Jul 31 12:41:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VJftqt004715; Thu, 31 Jul 2003 12:41:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA18352 Thu, 31 Jul 2003 14:58:52 -0400 (EDT) Message-Id: <5.2.0.9.0.20030731120622.02631138@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 31 Jul 2003 14:44:32 -0400 To: Stephen Kent , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: revised IPsec processing model In-Reply-To: References: <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030724113200.01feed80@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks Steve. I have a further comment on just two items, below. --Mark >>So I would propose that instead of a "forwarding function" we have a "SPD >>selection function" that is done on a per-packet basis. Like the >>forwarding function described above this function is a local matter for >>the IPsec implementation. It might be a mapping from interface to SPD >>(RFC2401 model), or any other function of the packet fields and packet >>meta-information. With this change the concept of virtual interface >>could be dropped entirely (my preference, since the SPDs would not >>necessarily correspond to the logical IP network interfaces that the term >>suggests to me) or the virtual interface could be considered as a highly >>abstract thing that is one-to-one with an SPD but has no particular >>relationship to where the packet is forwarded, making the VID into an >>"SPD identifier". > >I don't understand the reasoning here. We have been told that it is >inappropriate (unduly restrictive?) to have the SPD embody forwarding >info, hence the introduction of the forwarding function and the embodying >of its output in a VID value that can be used both for SPD selection and >to carry forward with the packet to control where it goes after IPsec >processing. It is the "used both for..." part of that that I am resisting. My opinion is that the proposed forwarding function and virtual interface concepts are helpful, but do not go far enough in generalizing the IPsec model. What I would hope to see 2401bis embrace is a model where packets enter an IPsec device, some device-specific logic selects an SPD to apply, and then the IPsec and bypassed packets are forwarded out an interface chosen by some separate device-specific logic, for example IP longest matching prefix forwarding. Let me give an example of a hypothetical yet reasonable device that is not readily accomodated by the 2401bis model as proposed. Suppose we have a security gateway sort of device that has 3 LAN interfaces that it is protecting i.e. "protected networks" and 2 WAN interfaces to the Internet i.e. "uplinks." Plaintext packets are sent and received on the protected network interfaces, and a mix of plaintext and IPsec packets are sent and received on the uplinks. Suppose that a separate SPD is to be used for each protected network interface. Consider the case of packets arriving from the protected network interfaces. The SPD to be applied needs to be selected based on the interface the packet srrived _from_, not the interface the packet (either bypassed, or encapsulated in IPsec) will be forwarded _to_. One could explain that in terms of the proposed model by saying that the incoming packets are sent by a "forwarding function" (based on the protected interface they were received from) to one of 3 virtual interfaces, and that each of those virtual interfaces has an SPD associated. Then, after packets are encapsulated or bypassed, there is another forwarding function that chooses the outgoing uplink. IMO however such an explanation would be a contortion. >>>There is also no provision within this processing model to support >>>nested SAs, i.e., all IPsec processing is performed in one pass. >>>However, after the packet is emitted, it could be redirected through the >>>IPsec module via local, virtual interfaces and use of the forwarding >>>lookup function, to cause more than one layer of IPsec headers to be >>>applied or removed. Note that to accomplish this, multiple entries would >>>have to be created, in distinct SPDs, each specifying a layer of IPsec >>>processing to be applied. However, IKE still lacks a means to negotiate >>>this, so I suspect that only manual configuration, or some key >>>management mechanism not yet defined for IPsec, would be needed to take >>>advantage of this approach. >> >>I don't see why IKE as-is could not negotiate this, so long as it allows >>negotiating an SA to protect payload packets that are ESP or AH >>protocol. It then becomes a local issue of what SPD(s) a packet is >>subjected to as it flows through the IPsec device, and any/all SAs needed >>would be independently negotiated. > >IKE, as-is, negotiates one pair of SAs at a time, and has not means to >communicate the intent of one side to bind together different SAs >negotiated independently, as best I know. So, rather than saying that >there might be some magic way to express this through SPD entries, I was >suggesting that we cleanly abandon it if IKE cannot negotiate it. >Otherwise we have so many ways to have things not work despite successful >IKE-level negotiation ... My point was that depending on the specific functions of IPsec devices, and depending on their configuration, the nesting of SAs might "just happen" and that even though IKE would not be used to bind the SAs together, the whole thing would "just work". I don't see any reason for 2401bis to explicitly disallow this, as this would not be requiring any specific support from 2401bis or from IKE. For example, packets might be forwarded via a virtual interface with an associated SPD. That SPD causes certain packets to be encapsulated in tunnel mode IPsec packets of SA sa-1 addressed to IPsec peer p-1. Those IPsec packets (as well as other packets) are subjected to another forwarding decision to select the correct outgoing physical link towards their destination, such as p-1. Suppose that that outgoing interface also has an associated SPD that causes AH and ESP (and other) packets to be encapsulated in IPsec SA sa-2. So, some packets might be sent out encapsulated in sa-1. some in sa-2, some in sa-1 nested withing sa-2, and some sent unencapsulated. But sa-1 and sa-2 have no particular relationship to one another. --Mark From owner-ipsec@lists.tislabs.com Thu Jul 31 13:00:21 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VK0Kqt006799; Thu, 31 Jul 2003 13:00:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA18394 Thu, 31 Jul 2003 15:18:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20030731120622.02631138@email> References: <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030731120622.02631138@email> Date: Thu, 31 Jul 2003 15:22:43 -0400 To: Mark Duffy From: Stephen Kent Subject: Re: revised IPsec processing model Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, I've trimmed the message to keep it readable, since I think we agree on the facts, just not what to do as a result :-). So we agree that there is a way to achieve source-based SPD selection, and to provide independent forwarding, but you don't think the mechanism is not elegant. If I understand your suggestion, though, you would remove all specification of this functionality, and I don't think we have a useful spec if we do that. Did I misunderstand what you were suggesting here? I agree that one could manage to configure SPDs so that nested SA could result. But, it's probably hard for most folks to do this, and without explicit, support in IKE, if this fails the results will be hard to diagnose. Also, because one would have to effect two IKE negotiations to create both sets of SAs, there are timing issues that could arise that also would result in possibly confusing behavior. It's easy to have 2401bis not say that nesting of SAs is prohibited. It's harder to say that that nesting MUST or MAY be supported, and how. What do you think should be said here? My concern, in part, is that if we say nothing, then users don't know what to expect re functionality, nor do they have any sense of whether two implementations by two different vendors will support this sort of nesting. That's not a good thing for a standard. Steve From owner-ipsec@lists.tislabs.com Thu Jul 31 16:07:46 2003 Received: from lists.tislabs.com (portal.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VN7jqt019133; Thu, 31 Jul 2003 16:07:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA19321 Thu, 31 Jul 2003 18:30:06 -0400 (EDT) Message-ID: <3F2999BF.3020309@airespace.com> Date: Thu, 31 Jul 2003 15:35:43 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Duffy CC: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: revised IPsec processing model References: <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030724113200.01feed80@email> <5.2.0.9.0.20030731120622.02631138@email> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2003 22:36:50.0335 (UTC) FILETIME=[3BABCAF0:01C357B4] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a few comments on this (interspersed below...) Mark Duffy wrote: | It is the "used both for..." part of that that I am resisting. | | My opinion is that the proposed forwarding function and virtual | interface concepts are helpful, but do not go far enough in generalizing | the IPsec model. What I would hope to see 2401bis embrace is a model | where packets enter an IPsec device, some device-specific logic selects | an SPD to apply, and then the IPsec and bypassed packets are forwarded | out an interface chosen by some separate device-specific logic, for | example IP longest matching prefix forwarding. | | Let me give an example of a hypothetical yet reasonable device that is | not readily accomodated by the 2401bis model as proposed. Suppose we | have a security gateway sort of device that has 3 LAN interfaces that it | is protecting i.e. "protected networks" and 2 WAN interfaces to the | Internet i.e. "uplinks." Plaintext packets are sent and received on the | protected network interfaces, and a mix of plaintext and IPsec packets | are sent and received on the uplinks. Suppose that a separate SPD is to | be used for each protected network interface. Consider the case of | packets arriving from the protected network interfaces. The SPD to be | applied needs to be selected based on the interface the packet srrived | _from_, not the interface the packet (either bypassed, or encapsulated | in IPsec) will be forwarded _to_. Steve can correct me if I've misinterpreted the model, but what you are saying here doesn't square with my understanding of the model. Here is how I understand it (and have implemented it in a previous life): ~ +-----------------+ ~ | packet from an | ~ | application | ~ +-------+---------+ ~ | outgoing ~ V packet ~ +----------------------------------------------+ ~ | packet forwarding (routing) module | ~ | ~ | +-->----->------+ ~ +-/-----------------\---------------------------+ ~ incoming / \ outgoing ~ packet / | packet ~ +----------------+ +----V-----------+ +----------------+ ~ | Interface 0 | | Interface 1 | | Interface n | ~ | +-------+ | | +-------+ | | +-------+ | ~ | | SPD 0 | | | | SPD 1 | | ... | | SPD n | | ~ | +-------+ | | +-------+ | | +-------+ | ~ +----------------+ +----------------+ +----------------+ ~ ^ _______/ incoming packet1 Note that these interfaces may be physical *or* logical. In this model, packets coming in from the network are first evaluated according to the policies of the ingress interface. Assuming the packet is allowed to continue (i.e. it is not discarded), the next step is to perform a forwarding lookup. If the packet is locally destined, it will be passed up to the appropriate internal consumer. If not, the egress interface must be determined according to the forwarding lookup (which will be longest prefix match), and then the policy of the egress interface will be examined to determine what to do next. In the case of internally generated (outbound) packets, the local application hands them to the stack, which first does a forwarding lookup to determine the egress interface, and then the policies of that interface are applied. Why doesn't this model permit the processing you want? Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/KZm/MtIdhO0pgN4RAkuHAKCQfChUHIezvxLwI1jSclplZvowkgCgmHcg nelEM/7mIs/FQIqX3SLf/so= =kGDK -----END PGP SIGNATURE-----