From ipsec-bounces@ietf.org Mon Oct 6 21:53:57 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD7953A6B2D; Mon, 6 Oct 2008 21:53:56 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C1B3A691C for ; Mon, 6 Oct 2008 21:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.203 X-Spam-Level: X-Spam-Status: No, score=0.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, J_CHICKENPOX_56=0.6, NORMAL_HTTP_TO_IP=0.001, SARE_BAYES_5x8=0.8, SARE_BAYES_6x8=0.8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKMJ761H-LP3 for ; Mon, 6 Oct 2008 21:49:51 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id CA5ED3A6859 for ; Mon, 6 Oct 2008 21:49:50 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so2153670fga.41 for ; Mon, 06 Oct 2008 21:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=9D0pvdaaNBS619Xm++JykAR3NNZtIui28Kt7dmYHtNQ=; b=sxJzdScWJ3IJMoTOw5ppPTFpd9hxt1UFQVuM1X3Jt90xnPkEdyLRZlICVjDCxwjfs6 tBxSryBtzG1bEZ1aVjOzaGPXTCSN8fMTG6Bm/8p3U3xPthlldQruForg/ne8PlHlLQ41 yf3TA1uDRd/YpM76FgSah45a1PyHwfa8ESThA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=uO5n9HxAmIONjkVC5rUUVyHkEaF5RSbzB/iEA327HPGVk8QpYUoHPTq4zk7xy2u/cG KlPBMB+rMpeZSEKza/l+8hYBq02PXeQNkWYc8fb2PJYDr1px2FVQcIU7rWuAfibVswAS Iy/eeKGR+01P1Bv9CgU8L/pZfSYA98VjzkyCQ= Received: by 10.86.80.5 with SMTP id d5mr5364391fgb.26.1223355027498; Mon, 06 Oct 2008 21:50:27 -0700 (PDT) Received: by 10.86.89.13 with HTTP; Mon, 6 Oct 2008 21:50:27 -0700 (PDT) Message-ID: <9cd3ad9d0810062150s28c64934mb24a89935e6efb70@mail.gmail.com> Date: Tue, 7 Oct 2008 10:20:27 +0530 From: "Sujithra P" To: ipsec@ietf.org MIME-Version: 1.0 Subject: [IPsec] NAT-T support in 2.6 kernel X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1299937223==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1299937223== Content-Type: multipart/alternative; boundary="----=_Part_13291_4415313.1223355027497" ------=_Part_13291_4415313.1223355027497 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I am testing the UDP-Encapsulated-ESP Tunnel mode IPSEC between IMS clieny and the PCSCF. (3GPP TS 33.203) I am simulating the IMS UE using a SIP client that runs on linux and uses NETKEY support to install and delete SAs. The IMS Client is able to send a UDP encapsulated packet to PCSCF. But the UDP encapsulated traffic from PCSCF is dropped by the kernel. The following is the details of the setup and the setkey config on the linux machine. The SAs are installed using manual keying. Linux Version: Linux ubuntu 2.6.24 # setkey -D 10.6.2.49[4500] 192.168.10.10[4500] esp-udp mode=tunnel spi=33589962(0x02008aca) reqid=3(0x00000003) E: 3des-cbc 343acfea 1a84fffd a2e62344 fe2032b1 343acfea 1a84fffd A: hmac-sha1 be65b76d 0abba80b 7fea2992 ca891792 00000000 seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Oct 2 15:57:46 2008 current: Oct 6 13:30:12 2008 diff: 336746(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=1 pid=7274 refcnt=0 10.6.2.49[4500] 192.168.10.10[4500] esp-udp mode=tunnel spi=16812490(0x010089ca) reqid=2(0x00000002) E: 3des-cbc 343acfea 1a84fffd a2e62344 fe2032b1 343acfea 1a84fffd A: hmac-sha1 be65b76d 0abba80b 7fea2992 ca891792 00000000 seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Oct 2 15:57:46 2008 current: Oct 6 13:30:12 2008 diff: 336746(s) hard: 0(s) soft: 0(s) last: Oct 2 15:57:46 2008 hard: 0(s) soft: 0(s) current: 4328(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 4 hard: 0 soft: 0 sadb_seq=2 pid=7274 refcnt=0 192.168.10.10[4500] 10.6.2.49[4500] esp-udp mode=tunnel spi=23456789(0x0165ec15) reqid=0(0x00000000) E: 3des-cbc 343acfea 1a84fffd a2e62344 fe2032b1 343acfea 1a84fffd A: hmac-sha1 be65b76d 0abba80b 7fea2992 ca891792 00000000 seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Oct 2 15:57:46 2008 current: Oct 6 13:30:12 2008 diff: 336746(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=3 pid=7274 refcnt=0 192.168.10.10[4500] 10.6.2.49[4500] esp-udp mode=tunnel spi=12345678(0x00bc614e) reqid=0(0x00000000) E: 3des-cbc 343acfea 1a84fffd a2e62344 fe2032b1 343acfea 1a84fffd A: hmac-sha1 be65b76d 0abba80b 7fea2992 ca891792 00000000 seq=0x00000000 replay=0 flags=0x00000000 state=mature created: Oct 2 15:57:46 2008 current: Oct 6 13:30:12 2008 diff: 336746(s) hard: 0(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=7274 refcnt=0 # setkey -DP 192.168.10.10[6070] 10.6.2.49[8000] any in ipsec esp/tunnel/192.168.10.10-10.6.2.49/require created: Oct 2 15:57:46 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=17664 seq=1 pid=7275 refcnt=1 192.168.10.10[5070] 10.6.2.49[7000] any in ipsec esp/tunnel/192.168.10.10-10.6.2.49/require created: Oct 2 15:57:46 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=17672 seq=2 pid=7275 refcnt=1 10.6.2.49[7000] 192.168.10.10[5070] any out ipsec esp/tunnel/10.6.2.49-192.168.10.10/unique:2 created: Oct 2 15:57:46 2008 lastused: Oct 2 15:57:50 2008 lifetime: 0(s) validtime: 0(s) spid=17649 seq=3 pid=7275 refcnt=1 10.6.2.49[8000] 192.168.10.10[6070] any out ipsec esp/tunnel/10.6.2.49-192.168.10.10/unique:3 created: Oct 2 15:57:46 2008 lastused: lifetime: 0(s) validtime: 0(s) spid=17657 seq=0 pid=7275 refcnt=1 10.6.2.49 is the UE public IP address 192.168.10.10 is the PCSCF IP address The UDP encapsulated packet from PCSCF to IMS Client is dropped by the kernel 15:34:54.605608 IP 10.6.2.49.4500 > 192.168.10.10.4500: UDP-encap: ESP(spi=0x010089ca,seq=0x1), length 1116 15:34:54.803321 IP 192.168.10.10.4500 > 10.6.2.49.4500: UDP-encap: ESP(spi=0x00bc614e,seq=0x1), length 660 15:34:54.803340 IP 10.6.2.49 > 192.168.10.10: ICMP 10.6.2.49 udp port 4500 unreachable, length 556 <<< Kernel sends ICMP error. Can any one tell me what could be the issue. Any help on this is greatly appreciated. Thanks, Sujithra. ------=_Part_13291_4415313.1223355027497 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

I am testing the UDP-Encapsulated-ESP Tunnel mode IPSEC between IMS clieny and the PCSCF. (3GPP TS 33.203)

I am simulating the IMS UE using a SIP client that runs on linux and uses NETKEY support to install and delete SAs.
The IMS Client is able to send a UDP encapsulated packet to PCSCF.
But the UDP encapsulated traffic from PCSCF is dropped by the kernel.

The following is the details of the setup and the setkey config on the linux machine.
The SAs are installed using manual keying.

Linux Version: Linux ubuntu 2.6.24

# setkey -D
10.6.2.49[4500] 192.168.10.10[4500]
        esp-udp mode=tunnel spi=33589962(0x02008aca) reqid=3(0x00000003)
        E: 3des-cbc  343acfea 1a84fffd a2e62344 fe2032b1 343acfea 1a84fffd
        A: hmac-sha1  be65b76d 0abba80b 7fea2992 ca891792 00000000
        seq=0x00000000 replay=0 flags=0x00000000 state=mature
        created: Oct  2 15:57:46 2008   current: Oct  6 13:30:12 2008
        diff: 336746(s) hard: 0(s)      soft: 0(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=1 pid=7274 refcnt=0
10.6.2.49[4500] 192.168.10.10[4500]
        esp-udp mode=tunnel spi=16812490(0x010089ca) reqid=2(0x00000002)
        E: 3des-cbc  343acfea 1a84fffd a2e62344 fe2032b1 343acfea 1a84fffd
        A: hmac-sha1  be65b76d 0abba80b 7fea2992 ca891792 00000000
        seq=0x00000000 replay=0 flags=0x00000000 state=mature
        created: Oct  2 15:57:46 2008   current: Oct  6 13:30:12 2008
        diff: 336746(s) hard: 0(s)      soft: 0(s)
        last: Oct  2 15:57:46 2008      hard: 0(s)      soft: 0(s)
        current: 4328(bytes)    hard: 0(bytes)  soft: 0(bytes)
        allocated: 4    hard: 0 soft: 0
        sadb_seq=2 pid=7274 refcnt=0
192.168.10.10[4500] 10.6.2.49[4500]
        esp-udp mode=tunnel spi=23456789(0x0165ec15) reqid=0(0x00000000)
        E: 3des-cbc  343acfea 1a84fffd a2e62344 fe2032b1 343acfea 1a84fffd
        A: hmac-sha1  be65b76d 0abba80b 7fea2992 ca891792 00000000
        seq=0x00000000 replay=0 flags=0x00000000 state=mature
        created: Oct  2 15:57:46 2008   current: Oct  6 13:30:12 2008
        diff: 336746(s) hard: 0(s)      soft: 0(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=3 pid=7274 refcnt=0
192.168.10.10[4500] 10.6.2.49[4500]
        esp-udp mode=tunnel spi=12345678(0x00bc614e) reqid=0(0x00000000)
        E: 3des-cbc  343acfea 1a84fffd a2e62344 fe2032b1 343acfea 1a84fffd
        A: hmac-sha1  be65b76d 0abba80b 7fea2992 ca891792 00000000
        seq=0x00000000 replay=0 flags=0x00000000 state=mature
        created: Oct  2 15:57:46 2008   current: Oct  6 13:30:12 2008
        diff: 336746(s) hard: 0(s)      soft: 0(s)
        last:                           hard: 0(s)      soft: 0(s)
        current: 0(bytes)       hard: 0(bytes)  soft: 0(bytes)
        allocated: 0    hard: 0 soft: 0
        sadb_seq=0 pid=7274 refcnt=0

# setkey -DP
192.168.10.10[6070] 10.6.2.49[8000] any
        in ipsec
        esp/tunnel/192.168.10.10-10.6.2.49/require
        created: Oct  2 15:57:46 2008  lastused:
        lifetime: 0(s) validtime: 0(s)
        spid=17664 seq=1 pid=7275
        refcnt=1
192.168.10.10[5070] 10.6.2.49[7000] any
        in ipsec
        esp/tunnel/192.168.10.10-10.6.2.49/require
        created: Oct  2 15:57:46 2008  lastused:
        lifetime: 0(s) validtime: 0(s)
        spid=17672 seq=2 pid=7275
        refcnt=1
10.6.2.49[7000] 192.168.10.10[5070] any
        out ipsec
        esp/tunnel/10.6.2.49-192.168.10.10/unique:2
        created: Oct  2 15:57:46 2008  lastused: Oct  2 15:57:50 2008
        lifetime: 0(s) validtime: 0(s)
        spid=17649 seq=3 pid=7275
        refcnt=1
10.6.2.49[8000] 192.168.10.10[6070] any
        out ipsec
        esp/tunnel/10.6.2.49-192.168.10.10/unique:3
        created: Oct  2 15:57:46 2008  lastused:
        lifetime: 0(s) validtime: 0(s)
        spid=17657 seq=0 pid=7275
        refcnt=1

10.6.2.49 is the UE public IP address
192.168.10.10 is the PCSCF IP address

The UDP encapsulated packet from PCSCF to IMS Client is dropped by the kernel

15:34:54.605608 IP 10.6.2.49.4500 > 192.168.10.10.4500: UDP-encap: ESP(spi=0x010089ca,seq=0x1), length 1116
15:34:54.803321 IP 192.168.10.10.4500 > 10.6.2.49.4500: UDP-encap: ESP(spi=0x00bc614e,seq=0x1), length 660
15:34:54.803340 IP 10.6.2.49 > 192.168.10.10: ICMP 10.6.2.49 udp port 4500 unreachable, length 556 <<< Kernel sends ICMP error.

Can any one tell me what could be the issue.
Any help on this is greatly appreciated.

Thanks,
Sujithra.
 ------=_Part_13291_4415313.1223355027497-- --===============1299937223== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1299937223==-- From ipsec-bounces@ietf.org Tue Oct 7 00:49:18 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F8C28C0E9; Tue, 7 Oct 2008 00:49:18 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76D283A6990 for ; Tue, 7 Oct 2008 00:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4EYs3mqrQVn for ; Tue, 7 Oct 2008 00:49:13 -0700 (PDT) Received: from strongswan.org (sidv0150.hsr.ch [152.96.52.150]) by core3.amsl.com (Postfix) with ESMTP id 9E0B33A6947 for ; Tue, 7 Oct 2008 00:49:13 -0700 (PDT) Received: from [152.96.15.212] (unknown [152.96.15.212]) by strongswan.org (Postfix) with ESMTP id 0034EEFB22; Tue, 7 Oct 2008 09:49:52 +0200 (CEST) Message-ID: <48EB1492.8090103@strongswan.org> Date: Tue, 07 Oct 2008 09:49:38 +0200 From: Martin Willi User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: Sujithra P References: <9cd3ad9d0810062150s28c64934mb24a89935e6efb70@mail.gmail.com> In-Reply-To: <9cd3ad9d0810062150s28c64934mb24a89935e6efb70@mail.gmail.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] NAT-T support in 2.6 kernel X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, > The IMS Client is able to send a UDP encapsulated packet to PCSCF. > But the UDP encapsulated traffic from PCSCF is dropped by the kernel. The linux kernel drops encapsulated packets unless you set the UDP_ENCAP socket option on at least one socket. For an example how we do it in strongSwan, have a look at http://trac.strongswan.org/browser/trunk/src/charon/network/socket.c#L494 Best regards Martin _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 7 04:32:25 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2243A6B53; Tue, 7 Oct 2008 04:32:25 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677CB3A6864 for ; Tue, 7 Oct 2008 04:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=-0.591, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnO-4rw0zY0Y for ; Tue, 7 Oct 2008 04:32:24 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id D45E93A67CC for ; Tue, 7 Oct 2008 04:30:49 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m97BV4Kk009282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Oct 2008 14:31:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m97BV2nE013766; Tue, 7 Oct 2008 14:31:02 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18667.18550.411482.352616@fireball.kivinen.iki.fi> Date: Tue, 7 Oct 2008 14:31:02 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 7 min X-Total-Time: 43 min Cc: ipsec@ietf.org Subject: [IPsec] NON_FIRST_FRAGMENTS_ALSO question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Scott C Moonen writes: > 1) Does your implementation perform stateful fragment checking? Yes, we always do stateful fragment checking. > 2) Regardless of the answer to #1, does your implementation correctly > recognize that in this case there is a pseudo stateful fragment checking > going on even though the traffic at your endpoint is not forwarded? As we always do stateful checking that does include locally generated packets too. > 3) How do you handle this case? Do you send NON_FIRST_FRAGMENTS_ALSO? > Or do you mark the SA as stateful-fragment-checking=false, perhaps > discarding those non-first fragments? Or do you have additional logic to > perform a second SPD lookup for these non-first fragments after they have > been produced, so that they can be sent on the appropriate port=ALL or > port=OPAQUE SA? We always send NON_FIRST_FRAGMENTS_ALSO notify and always do stateful fragment checking, and send non first fragments in the same SA. > 4) If you treat this as a NON_FIRST_FRAGMENTS_ALSO case, what do you do > in the event that NON_FIRST_FRAGMENTS_ALSO is not also sent by the peer? > Do you delete the SA and document that a port=ALL SA must be established > instead (e.g., by setting the port PFP flags to false)? Or do you revert > to any of the behaviors suggested in the previous question? Currently we simply ignore the fact that other end didn't send the NON_FIRST_FRAGMENTS_ALSO and send non first fragments to the SA, and if other end drops them, then we do have configuration mismatch causing black hole for fragmented packets. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 7 06:07:45 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 010D328C15C; Tue, 7 Oct 2008 06:07:45 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CB3B28C13D for ; Tue, 7 Oct 2008 06:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwSbH-iUqRqn for ; Tue, 7 Oct 2008 06:07:40 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 1384E28C15C for ; Tue, 7 Oct 2008 06:07:40 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so548378ywj.49 for ; Tue, 07 Oct 2008 06:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=D/9ZqJF+EErVVt+olNXGozZN0gtvu1aeRTaqPrDia94=; b=Yn5hDvKAwePyFfSNpPE0p1FHDKDTrrDPQW+xRmlnWbZh+yt2xBO70F5kPNxNXsyT6g cLSYPjX+Mo2IShhZdDpwkU5LZQdIwLF/WYn59aQKNBD/JCHW+145Hg6VBFWwuQ4gcvIz UwuYnrgonzgCPi84XXEj262nA7MlnYysX9mSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=K3XniuCyle29cFjX4D8W7oY8M+TzRNJLmzHJ4JVU3rg7sXk0O1JAgo6Bipq4aJ5l0Q 6JlTt/o9q1NihH9gWmy5tweqOrGsctJEBPfVGgPLVVzmBmH2Q/ibD7iuLFYmiXFgt+h3 Euse2NX2OMBmmAh+zBUPY9Oya1gGtb0ioRRuQ= Received: by 10.142.213.9 with SMTP id l9mr2660988wfg.2.1223384861394; Tue, 07 Oct 2008 06:07:41 -0700 (PDT) Received: by 10.142.133.20 with HTTP; Tue, 7 Oct 2008 06:07:41 -0700 (PDT) Message-ID: <4c5c7a6d0810070607o77c31107k6e3ab8229e399bca@mail.gmail.com> Date: Tue, 7 Oct 2008 21:07:41 +0800 From: "Peny Yang" To: ipsec@ietf.org In-Reply-To: <20081007125515.2996B3A6B6F@core3.amsl.com> MIME-Version: 1.0 Content-Disposition: inline References: <20081007125515.2996B3A6B6F@core3.amsl.com> Cc: Hui Deng , Paul Hoffman Subject: [IPsec] Fwd: New Version Notification for draft-xu-ike-sa-sync-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Folks: We updated our draft on IKE SA session resumption. Please review it. Comments are more than welcome. Thanks a lot BRG - Peny ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Tue, Oct 7, 2008 at 8:55 PM Subject: New Version Notification for draft-xu-ike-sa-sync-01 To: peng.yang.chn@gmail.com Cc: xydkl@163.com, ycma@hitachi.cn, denghui@chinamobile.com, xuke@mail.tsinghua.edu.cn A new version of I-D, draft-xu-ike-sa-sync-01.txt has been successfuly submitted by Peng Yang and posted to the IETF repository. Filename: draft-xu-ike-sa-sync Revision: 01 Title: IKEv2 SA Synchronization for session resumption Creation_date: 2008-10-07 WG ID: Independent Submission Number_of_pages: 18 Abstract: It will take a long time and mass computation to do session resumption among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/IPsec SAs, when the serving gateway fails or over-loaded. The major reason is that the prcocedure of IKEv2 SA re-establishment will incur a time-consuming computation especially in the Diffie- Hellman exchange. In this draft, a new IKE security associations synchronization solution is proposed to do fast IKE SA session resumption by directly transferring the indexed IKE SA (named stub) from old gateway to new gateway, wherein the most expensive Diffie- Hellman calculation can be avoided. Without some time-consuming IKEv2 exchanges, the huge amount of IKE/IPsec SA session resumption procedures can be finished in a short time. The IETF Secretariat. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 7 06:16:41 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B538528C15C; Tue, 7 Oct 2008 06:16:41 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 030723A69FE for ; Tue, 7 Oct 2008 06:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+OZ+Q-Rwq-e for ; Tue, 7 Oct 2008 06:16:35 -0700 (PDT) Received: from mail-gx0-f16.google.com (mail-gx0-f16.google.com [209.85.217.16]) by core3.amsl.com (Postfix) with ESMTP id A8E863A6B5C for ; Tue, 7 Oct 2008 06:16:35 -0700 (PDT) Received: by gxk9 with SMTP id 9so6454483gxk.13 for ; Tue, 07 Oct 2008 06:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=QM1ERPASCRxP+ncXBTPPBwS3BOBqKjarUii0SMWBXhw=; b=ez9Qit3QPmIYSXtmwkfDxDZ2M8oiywQAVo/NxVzI8+U3ceIYdK6RUrCoL8ZNu8bQia koo2pm6W71x7NTf77KW0r6zvBUzsHD+bpgLmlRzcYYDeIqmnVZC8imYLYbZIVv+o7N19 HnjdnN8h6ql+l+3IwEcqel7jBAQmom7LrAmpc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=bSTI47bp/Db/DeT9Hi9jtMabmdvubMvqJSbHZiYoK+xU4+qHW9oMZlE5FpmSjzxceI r+o96tsScwBX8+JlXVl0eFw4uV8uZHVtcF6AXzq4ceYrcDUMq99OcvoBC6xoFfhl/INq y+TtAlocFZDzQEe/X0YV+k3FEagEEOmKK4PBk= Received: by 10.142.229.5 with SMTP id b5mr2650214wfh.280.1223385429581; Tue, 07 Oct 2008 06:17:09 -0700 (PDT) Received: by 10.142.133.20 with HTTP; Tue, 7 Oct 2008 06:17:09 -0700 (PDT) Message-ID: <4c5c7a6d0810070617q7816d710q2e96080a47057572@mail.gmail.com> Date: Tue, 7 Oct 2008 21:17:09 +0800 From: "Peny Yang" To: ipsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline Cc: Hui Deng , Paul Hoffman Subject: [IPsec] Fw: I-D Action:draft-xu-ike-sa-sync-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Folks: Sorry, I am afraid this poster should be fowarded instread for convenience. Forget the one I posted just now. :) Thanks a lot BRG - Peny A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IKEv2 SA Synchronization for session resumption Author(s) : Y. Xu, et al. Filename : draft-xu-ike-sa-sync-01.txt Pages : 18 Date : 2008-10-07 It will take a long time and mass computation to do session resumption among IKE/IPsec gateways possibly maintaining huge numbers of IKEv2/IPsec SAs, when the serving gateway fails or over-loaded. The major reason is that the prcocedure of IKEv2 SA re-establishment will incur a time-consuming computation especially in the Diffie- Hellman exchange. In this draft, a new IKE security associations synchronization solution is proposed to do fast IKE SA session resumption by directly transferring the indexed IKE SA (named stub) from old gateway to new gateway, wherein the most expensive Diffie- Hellman calculation can be avoided. Without some time-consuming IKEv2 exchanges, the huge amount of IKE/IPsec SA session resumption procedures can be finished in a short time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 7 10:09:15 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4237C3A6B52; Tue, 7 Oct 2008 10:09:15 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44EB928C10F for ; Tue, 7 Oct 2008 10:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXY9fb7Th+BQ for ; Tue, 7 Oct 2008 10:09:12 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 5E15228C106 for ; Tue, 7 Oct 2008 10:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1223399391; x=1254935391; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding:x-ironport-av; z=Message-ID:=20<48EB97DD.2040305@qualcomm.com>|Date:=20Tu e,=2007=20Oct=202008=2010:09:49=20-0700|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.17=20(Windows/20080914)|MIME-Version:=201 .0|To:=20ipsec@ietf.org|Subject:=20[Fwd:=20I-D=20Action:d raft-tschofenig-ipsecme-ikev2-resumption-00.txt] |Content-Type:=20text/plain=3B=20charset=3DISO-8859-15=3B =20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5300,2777,5399"=3B=20 a=3D"10236304"; bh=dJCpGlpKlfojklan8pz3M24G0Ufoyp6dzike74XFlGs=; b=zG9tLsSEWnIY3tMgonH2SCNK8EpU9bEGOZfwxI4PsQPFJEB38Bu3SfWo 8iaM9fqXSxDTb3lNeAzwGzyxPBS3MpEa73UFEe6xKkX/svtg/BQn0jAmD WqQZUvzDbsTCWByQ9g1HPRN27tZbXJAdRTxeqOPbqBKeVS0Z94JW00HtU Y=; X-IronPort-AV: E=McAfee;i="5300,2777,5399"; a="10236304" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Oct 2008 10:09:51 -0700 Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m97H9p1s027927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Oct 2008 10:09:51 -0700 Received: from [10.50.69.50] (qconnect-10-50-69-50.qualcomm.com [10.50.69.50]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m97H9p2j013649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 7 Oct 2008 10:09:51 -0700 Message-ID: <48EB97DD.2040305@qualcomm.com> Date: Tue, 07 Oct 2008 10:09:49 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] [Fwd: I-D Action:draft-tschofenig-ipsecme-ikev2-resumption-00.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org FYI -------- Original Message -------- Subject: I-D Action:draft-tschofenig-ipsecme-ikev2-resumption-00.txt Date: Wed, 1 Oct 2008 08:45:10 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IKEv2 Session Resumption Author(s) : Y. Sheffer, et al. Filename : draft-tschofenig-ipsecme-ikev2-resumption-00.txt Pages : 19 Date : 2008-10-01 The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. To re-establish security associations (SA) upon a failure recovery condition is time consuming, especially when an IPsec peer, such as a VPN gateway, needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In order to avoid the need to re-run the key exchange protocol from scratch it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach uses a ticket to store state information that is later made available to the IKEv2 responder for re-authentication. Restoring state information by utilizing a ticket, although the format is not specified in this document, is one possible way. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-tschofenig-ipsecme-ikev2-resumption-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 7 10:42:48 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 353A03A6856; Tue, 7 Oct 2008 10:42:48 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70CC03A6856 for ; Tue, 7 Oct 2008 10:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sa2kdgIXdfMq for ; Tue, 7 Oct 2008 10:42:45 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BE1E53A67F7 for ; Tue, 7 Oct 2008 10:42:44 -0700 (PDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m97HhIEQ097751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Oct 2008 10:43:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <48EB97DD.2040305@qualcomm.com> <4c5c7a6d0810070617q7816d710q2e96080a47057572@mail.gmail.com> References: <48EB97DD.2040305@qualcomm.com> <4c5c7a6d0810070617q7816d710q2e96080a47057572@mail.gmail.com> Date: Tue, 7 Oct 2008 10:43:15 -0700 To: ipsec@ietf.org From: Paul Hoffman Subject: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org We now have revised drafts from the two parties who has published earlier drafts on session resumption. The (truncated) announcements are below. The WG should start discussing what we want from session resumption and which of these two drafts (or what ideas from each of these two drafts) is of interest to the WG. As a reminder, I start off with what our charter says. Extra points are awarded for not copying this entire message in your response. :-) --Paul Hoffman ========== - A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotiation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). The idea is similar to TLS session resumption without server-side state, specified in RFC 5077. The main goals for this extension are to avoid public-key computations (to reduce VPN gateway load when a large number of clients reconnect to the gateway within a short period of time, such as following a network outage), and remove the need for user interaction for authentication (which may be required by some authentication mechanisms). The extension shall not have negative impact on IKEv2 security features. Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Specifying the detailed contents of the "session ticket" is also beyond the scope of this document; if there is sufficient interest, this could be specified later in a separate document. To the degree its content falls within the scope of this work item, text and ideas from draft-sheffer-ipsec-failover will be used as a starting point. ========== At 9:17 PM +0800 10/7/08, Peny Yang wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : IKEv2 SA Synchronization for session resumption > Author(s) : Y. Xu, et al. > Filename : draft-xu-ike-sa-sync-01.txt > Pages : 18 > Date : 2008-10-07 > >It will take a long time and mass computation to do session >resumption among IKE/IPsec gateways possibly maintaining huge numbers >of IKEv2/IPsec SAs, when the serving gateway fails or over-loaded. >The major reason is that the prcocedure of IKEv2 SA re-establishment >will incur a time-consuming computation especially in the Diffie- >Hellman exchange. In this draft, a new IKE security associations >synchronization solution is proposed to do fast IKE SA session >resumption by directly transferring the indexed IKE SA (named stub) >from old gateway to new gateway, wherein the most expensive Diffie- >Hellman calculation can be avoided. Without some time-consuming >IKEv2 exchanges, the huge amount of IKE/IPsec SA session resumption >procedures can be finished in a short time. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-01.txt > At 10:09 AM -0700 10/7/08, Lakshminath Dondeti wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : IKEv2 Session Resumption > Author(s) : Y. Sheffer, et al. > Filename : draft-tschofenig-ipsecme-ikev2-resumption-00.txt > Pages : 19 > Date : 2008-10-01 > >The Internet Key Exchange version 2 (IKEv2) protocol has a certain >computational and communication overhead with respect to the number >of round-trips required and the cryptographic operations involved. >In remote access situations, the Extensible Authentication Protocol >(EAP) is used for authentication, which adds several more round trips >and consequently latency. > >To re-establish security associations (SA) upon a failure recovery >condition is time consuming, especially when an IPsec peer, such as a >VPN gateway, needs to re-establish a large number of SAs with various >end points. A high number of concurrent sessions might cause >additional problems for an IPsec peer during SA re-establishment. > >In order to avoid the need to re-run the key exchange protocol from >scratch it would be useful to provide an efficient way to resume an >IKE/IPsec session. This document proposes an extension to IKEv2 that >allows a client to re-establish an IKE SA with a gateway in a highly >efficient manner, utilizing a previously established IKE SA. > >A client can reconnect to a gateway from which it was disconnected. >The proposed approach uses a ticket to store state information that >is later made available to the IKEv2 responder for re-authentication. >Restoring state information by utilizing a ticket, although the >format is not specified in this document, is one possible way. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-tschofenig-ipsecme-ikev2-resumption-00.txt --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 7 16:21:25 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334713A686C; Tue, 7 Oct 2008 16:21:25 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9A93A686C for ; Tue, 7 Oct 2008 16:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNO-0ch12Iao for ; Tue, 7 Oct 2008 16:21:23 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 2DB2A3A681A for ; Tue, 7 Oct 2008 16:21:23 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6A580294002; Wed, 8 Oct 2008 01:22:02 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7F67A294001; Wed, 8 Oct 2008 01:20:43 +0200 (IST) Received: from [172.31.21.116] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m97NKgke017523; Wed, 8 Oct 2008 01:20:43 +0200 (IST) Message-Id: <9F4E8CC2-524F-40E3-AFB8-24ABBF922344@checkpoint.com> From: Yoav Nir To: Paul Hoffman In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 01:20:42 +0200 References: <48EB97DD.2040305@qualcomm.com> <4c5c7a6d0810070617q7816d710q2e96080a47057572@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Oct 7, 2008, at 7:43 PM, Paul Hoffman wrote: > > > We now have revised drafts from the two parties who has published > earlier drafts on session resumption. The (truncated) announcements > are below. > > The WG should start discussing what we want from session resumption > and which of these two drafts (or what ideas from each of these two > drafts) is of interest to the WG. As a reminder, I start off with > what our charter says. > > Extra points are awarded for not copying this entire message in your > response. :-) > > --Paul Hoffman From a cursory read of both, the "stub" concept is very similar to the "ticket" concept. The difference is that the ticket is stored client-side, and therefore needs encryption, while the stub is stored server-side (or in some repository) and the security measures needed may or may not require encryption. draft-xu-ike-sa-sync also addresses failover due to overload, but that seems to me to be outside the scope of this work item. I think we have three resumption scenarios: - single gateway fails, and reboots - a gateway fails, and a backup gateway with the same Identities, certificates and IP addresses takes over - a gateway fails, and the client connects to a different gateway with another IP address. I'm not sure whether this scenario is even in scope. Both proposals can handle all three cases. To implement the synchronization proposal, you need some kind of persistent storage, large enough to carry as many stubs as there are IKE SAs. This can be a local disk (synchronized between the gateways in case #2), an external storage module or database, or some other form of persistent storage. It also needs a process for transferring the stubs between gateways or between a gateway and the storage module. The resumption proposal does not need this extra piece of infrastructure and network traffic, which IMO gives it an edge. In terms of bandwidth, the synchronization proposal has the edge, since the stub need not be transmitted to the client. The ticket shares the packet with traffic selectors, configuration payload, authentication, certificates and other payloads. That packet can be quite large, which leads to fragmentation and potentially packet loss. The amount of work done is session resumption seems about similar, so there's nothing there to tell the proposals apart. I think that on balance, the stub bank requirement is harder than the bandwidth requirements. I personally like session resumption better. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 8 05:06:52 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C25AC3A6803; Wed, 8 Oct 2008 05:06:52 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDB1C3A6774 for ; Wed, 8 Oct 2008 05:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOeZHDo04hwo for ; Wed, 8 Oct 2008 05:06:48 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id E9EE73A6884 for ; Wed, 8 Oct 2008 05:06:47 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so4231920wfd.31 for ; Wed, 08 Oct 2008 05:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=v/vcILACDwfux8LVTTi6bcJFwuppOYGcMZYWOgk907s=; b=SgJqgF8QTgZoD8zrNdUVhzuUQn+7j62UWcwKCkbxh7EJ79lo6ocmG+hQY4JN1FgRUy IS3AvCC7BZzS1v0n/lPQ+iu7Lw+zccItYM6xHMO7F49TUjKGDnEYtq/VwrLYt81NII2e qA7jYncUZ/WySPjg/84tV1Vp+DOdKxUGm1kfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=KlvgClv4yzXqUsmhSuvW7O0cGQabt79mZsGEFuqsU1wSZfBDr8i8Li7piDasBWPdRn Oku2bzcCxcR8EzcBRj05S10EEpEC7UDvbKmYP3MWRqrteDXz9P3qpMNIc6FRA9RE9uRU NrFYZsj5dFFatRJcD1+MMP4KXdEaDDbzdHPPA= Received: by 10.142.180.19 with SMTP id c19mr3369338wff.322.1223467240777; Wed, 08 Oct 2008 05:00:40 -0700 (PDT) Received: by 10.142.133.20 with HTTP; Wed, 8 Oct 2008 05:00:40 -0700 (PDT) Message-ID: <4c5c7a6d0810080500t7da800d8xacaecb5eff3e08cd@mail.gmail.com> Date: Wed, 8 Oct 2008 20:00:40 +0800 From: "Peny Yang" To: "Paul Hoffman" , ipsec@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <48EB97DD.2040305@qualcomm.com> <4c5c7a6d0810070617q7816d710q2e96080a47057572@mail.gmail.com> Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > We now have revised drafts from the two parties who has published earlier drafts on session resumption. The (truncated) announcements are below. > > The WG should start discussing what we want from session resumption and which of these two drafts (or what ideas from each of these two drafts) is of interest to the WG. As a reminder, I start off with what our charter says. > > Extra points are awarded for not copying this entire message in your response. :-) > > --Paul Hoffman > > ========== Hi, Paul: Thanks a lot for your consideration. Firstly, to make this discussion more smooth, may I propose to clarify the terminology in this discussion beforehand. How about calling these two drafts with "ticket solution" and "stub solution". In emails previously, it seems the word of "resumption solution" is used for the ticket solution somewhere, which is a little confusing. IMHO, the stub solution DOES do the session resumption as well. Is this suggestion acceptable? Thanks. I just compared the two solution: "ticket solution" and "Stub Solution". These two solutions have the same protocol round trips if the session resumption can be successfully finished. However, if we could consider the case when the session resumption CAN NOT be continued by the gateway, these two solutions are different in protocol round trips. The stub solution adds the payload in the IKE_INIT message. The gateway can choose the normal procedure by sending the normal IKEv2 IKE_INIT response without any other round trips. The ticket solution have 1 more round trips in this case to deliver the ticket to gateway. And, these messages may be sent over the air. If we also include the ticket provision procedure from GW to client, in this case, the big ticket packet will be transferred over the air at least *TWICE*, which may even possibly make nothing help to the protocol in case of no unsuccessful session resumption. Lastly, the stub solution does not need to extend the base IKEv2 protocol with new messages. It re-use the IKE_INIT messages to do the session resumption with good flexibility. From the view of protocol implementation, it's easier. Thanks again. regards, Peny _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 8 17:13:20 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FAC63A6C0B; Wed, 8 Oct 2008 17:13:20 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAAD53A6C05 for ; Wed, 8 Oct 2008 17:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDlWnv6o51Aw for ; Wed, 8 Oct 2008 17:13:18 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 30B023A6C0B for ; Wed, 8 Oct 2008 17:13:18 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B9E87A888594; Wed, 8 Oct 2008 17:14:00 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 8 Oct 2008 17:14:00 -0700 (PDT) Message-ID: <5a2ca0895bd67f47edbbfe079761eb55.squirrel@www.trepanning.net> In-Reply-To: References: <48EB97DD.2040305@qualcomm.com> <4c5c7a6d0810070617q7816d710q2e96080a47057572@mail.gmail.com> Date: Wed, 8 Oct 2008 17:14:00 -0700 (PDT) From: "Dan Harkins" To: "Paul Hoffman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hello, On Tue, October 7, 2008 10:43 am, Paul Hoffman wrote: [snip] > The WG should start discussing what we want from session resumption and > which of these two drafts (or what ideas from each of these two drafts) is > of interest to the WG. I prefer the approach in draft-tschofenig-ipsecme-ikev2-resumption. A "stub bank" is not very attractive to me and requiring one will impose restrictions on solutions. The charter vaguely says, "The extension shall not have negative impact (sic) on IKEv2 security features" so I'm happy to see the Security Considerations of draft-tschofenig-ipsecme-ikev2-resumption touch on some of the things that could impact IKEv2 security features. Of the two, I think it's the more complete document and something of interest to the WG. regards, Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 9 02:17:44 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74C213A6A53; Thu, 9 Oct 2008 02:17:44 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7893A3A6A53 for ; Thu, 9 Oct 2008 02:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsPghWms4O6w for ; Thu, 9 Oct 2008 02:17:42 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 815EF3A6893 for ; Thu, 9 Oct 2008 02:17:42 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8G00J0ISHLJI@szxga01-in.huawei.com> for ipsec@ietf.org; Thu, 09 Oct 2008 17:17:45 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K8G00CG0SHLUB@szxga01-in.huawei.com> for ipsec@ietf.org; Thu, 09 Oct 2008 17:17:45 +0800 (CST) Received: from s00102542 ([10.111.12.200]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K8G007HVSHHFC@szxml03-in.huawei.com> for ipsec@ietf.org; Thu, 09 Oct 2008 17:17:45 +0800 (CST) Date: Thu, 09 Oct 2008 17:17:41 +0800 From: Sean Shen In-reply-to: To: 'Paul Hoffman' , ipsec@ietf.org Message-id: <014201c929ef$e1a74c50$c80c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Thread-index: AckopDB8uJvelAfsQs6mUiv3l2NqUwBRziKg Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I went through the draft-tschofenig draft and have't finished reading the draft-xu draft. Right now I have a few comments on the first draft as following , hopefully more questions on both coming soon, :) Section 1: "Using only symmetric cryptography to minimize CPU consumption." Sean: A ticket is not huge and ticket generation can be out of the SA setup precedure, it can be done at "spare time". Why bother to specify it. Section 1: "Allowing a gateway to push state to clients." Sean: The coverage of the "state" should be given. Section 3: Sean: This section gives two senarios, but which one does the "In this scenario" refer to? Section 3: Sean: I was confused by the 5th paragraph of section 3. But eventually I guess that "remote network", "remote access gateway" below to oppsite sides of an IPSec connection, am I right? Section 4.2: " Tickets are intended for one-time use: a client MUST NOT reuse a ticket, either with the same or with a different gateway. A gateway SHOULD reject a reused ticket. However, a responder is not required to maintain the state for terminated sessions." Sean: I did not see how a gateway know that a ticket is reused. Section 4.2: HDR, Ni, N(TICKET_OPAQUE), [N+,] Sean: what's the "N+"? Section 4.2: " o When the responder receives a ticket for an IKE SA that is still active and if the responder accepts it, then the old SAs SHOULD be silently deleted without sending a DELETE informational exchange. " Sean: I want to know an example for such a senario. Why will a initiator start a resume session when the current session is not terminated. Is it an accident or an attack? Regards, Sean _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 9 03:13:32 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50CF53A6A04; Thu, 9 Oct 2008 03:13:32 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461FC3A6A57 for ; Thu, 9 Oct 2008 03:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rfgm5a4RAMm5 for ; Thu, 9 Oct 2008 03:13:30 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 9AFF13A67C1 for ; Thu, 9 Oct 2008 03:13:30 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id n4so2570558wag.5 for ; Thu, 09 Oct 2008 03:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=uXXm9DEGg93zwqxQ0yDKt4pi3rw56B8AVoA1HmSx4TI=; b=IM03sdlM3dIsE5g2cWCNUWtvu+8bKtCeUfuZ57ILTGEjDVSlkU79s2TSmtyU2lJmXh D9fE+Ihn9utLZaZA7tY1VTdt6AUqXHnc2mS278aJYEOkbVT3ABXoCk+LKcJxhvZLTBDX iDHA+PPvbWCmp2xOPnHsleDyDIT+ZQvcMlpTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=qoCLk/Ej2NSuvX2Q8NpQWEUYtYbItMxHMFsiwpc9AgYlIa4h/iIeEBPZuJvZdvLp2z u6WYBRXtNLJaw+E44oYQukdNWICLJTQxxZyp2RNmpJgB6PxpQ63rx5toIMflKlMhpw8M yBo/nwSAIHXpw0eewlWETz+NoVy7hMJUi7TH8= Received: by 10.114.106.13 with SMTP id e13mr10544774wac.157.1223547243280; Thu, 09 Oct 2008 03:14:03 -0700 (PDT) Received: by 10.114.180.9 with HTTP; Thu, 9 Oct 2008 03:14:03 -0700 (PDT) Message-ID: Date: Thu, 9 Oct 2008 18:14:03 +0800 From: "Zhen Cao" To: ipsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dear All, I have a quick review of these two drafts. Basically, both drafts need to transfer ticket/stub to gateway from somewhere during session resumption. In ticket draft, the ticket need to be presented to client before hand and delivered to gateway in the IKE_SESSION_RESUME message in session resumption. In the stub draft, the stub need to be transfered between gateway and stub bank. My point is that the worth of bandwidth are different for different ways of transferring. When we transfer the stub between gateways, we use fiber. If we transfer the ticket to the client, we may even need to use the luxurious wireless spectrum in the mobile network. And, the ticket will expire. If the session resumption does not happen for a long time in the mobile network, the updated tickets will be sent over the air continuously to the client. In this case, the continuous cost of ticket presenting will be taken by operator or subscribers in vain. In this case, I think stub solution should be a mandatory, ticket maybe optional. Thanks Zhen -cut below _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 9 07:31:16 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1F403A6983; Thu, 9 Oct 2008 07:31:16 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3ADA3A6A18 for ; Thu, 9 Oct 2008 07:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DDQ07+5EN6P for ; Thu, 9 Oct 2008 07:31:15 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id D34753A6983 for ; Thu, 9 Oct 2008 07:31:14 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KnwYX-00081W-FQ; Thu, 09 Oct 2008 10:31:58 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 9 Oct 2008 10:12:05 -0400 To: "Zhen Cao" From: Stephen Kent Cc: ipsec@ietf.org Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0128173383==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0128173383== Content-Type: multipart/alternative; boundary="============_-988559731==_ma============" --============_-988559731==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 6:14 PM +0800 10/9/08, Zhen Cao wrote: >... >My point is that the worth of bandwidth are different for different >ways of transferring. When we transfer the stub between gateways, we >use fiber. If we transfer the ticket to the client, we may even need >to use the luxurious wireless spectrum in the mobile network. And, the >ticket will expire. If the session resumption does not happen for a >long time in the mobile network, the updated tickets will be sent over >the air continuously to the client. In this case, the continuous cost >of ticket presenting will be taken by operator or subscribers in vain. > >In this case, I think stub solution should be a mandatory, ticket >maybe optional. In the immediately preceding message, from, Sean Shen, he says: >Section 1: "Using only symmetric cryptography to minimize CPU consumption." >Sean: A ticket is not huge and ticket generation can be out of the SA setup >precedure, it can be done at "spare time". Why bother to specify it. In two messages that arrived in my mailbox less than an hour apart, we have two radically different views of whether a ticket is big or small. If we can't agree on the size of this data, perhaps because they are vendor-specific in detail, then we ought not make decisions on mandating the stub vs. the ticket model on this basis. Steve --============_-988559731==_ma============ Content-Type: text/html; charset="us-ascii" Re: [IPsec] Resuming the session resumption discussion
At 6:14 PM +0800 10/9/08, Zhen Cao wrote:
...
My point is that the worth of bandwidth are different for different
ways of transferring. When we transfer the stub between gateways, we
use fiber. If we transfer the ticket to the client, we may even need
to use the luxurious wireless spectrum in the mobile network. And, the
ticket will expire. If the session resumption does not happen for a
long time in the mobile network, the updated tickets will be sent over
the air continuously to the client. In this case, the continuous cost
of ticket presenting will be taken by operator or subscribers in vain.

In this case, I think stub solution should be a mandatory, ticket
maybe optional.

In the immediately preceding message, from, Sean Shen, he says:

Section 1:  "Using only symmetric cryptography to minimize CPU consumption."
Sean: A ticket is not huge and ticket generation can be out of the SA setup
precedure, it can be done at  "spare time". Why bother to specify it.

In two messages that arrived in my mailbox less than an hour apart, we have two radically different views of whether a ticket is big or small.  If we can't agree on the size of this data, perhaps because they are vendor-specific in detail, then we ought not make decisions on mandating the stub vs. the ticket model on this basis.

Steve

--============_-988559731==_ma============-- --===============0128173383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0128173383==-- From ipsec-bounces@ietf.org Thu Oct 9 13:07:06 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF35128C0FC; Thu, 9 Oct 2008 13:07:06 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A44E28C0FC for ; Thu, 9 Oct 2008 13:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.878 X-Spam-Level: X-Spam-Status: No, score=-5.878 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDPsumX4Kb6W for ; Thu, 9 Oct 2008 13:07:03 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id C05203A6912 for ; Thu, 9 Oct 2008 13:07:03 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m99K7Kx9025282 for ; Thu, 9 Oct 2008 16:07:20 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m99K78YV123862 for ; Thu, 9 Oct 2008 14:07:14 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m99K6ckh002079 for ; Thu, 9 Oct 2008 14:06:38 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m99K6cca002072; Thu, 9 Oct 2008 14:06:38 -0600 In-Reply-To: <18667.18550.411482.352616@fireball.kivinen.iki.fi> References: <18667.18550.411482.352616@fireball.kivinen.iki.fi> MIME-Version: 1.0 X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 10/09/2008 04:04:54 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 10/09/2008 04:04:54 PM, Serialize complete at 10/09/2008 04:04:54 PM, S/MIME Sign failed at 10/09/2008 04:04:54 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_M2_08202008HFIGS1|August 20, 2008) at 10/09/2008 14:07:07, Serialize complete at 10/09/2008 14:07:07 To: Tero Kivinen X-KeepSent: 73634373:9A349521-852574DD:006C4C14; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen Message-ID: Date: Thu, 9 Oct 2008 16:05:09 -0400 Cc: ipsec@ietf.org Subject: Re: [IPsec] NON_FIRST_FRAGMENTS_ALSO question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1182160846==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1182160846== Content-Type: multipart/alternative; boundary="=_alternative 006E52F4852574DD_=" This is a multipart message in MIME format. --=_alternative 006E52F4852574DD_= Content-Type: text/plain; charset="US-ASCII" Tero, thanks for your reply. I would be very tempted to take the same approach, issuing a warning message but leaving the SA up and continuing to flow traffic. I also wonder if it is possible that some minimal implementations may not be sending N(NON_FIRST_FRAGMENTS_ALSO) in the case I described, perhaps wrongly thinking that this payload doesn't apply to them since they don't perform stateful fragment checking. Taking a lax approach would provide the ability to interoperate with such an implementation without forcing the SA to specify all ports/types/codes. However, this text from RFC 4301 makes me reluctant to take your approach: . . . If an implementation does not successfully negotiate transmission of non-initial fragments for such an SA, it MUST NOT send such fragments over the SA. . . I wonder: 1) Are there any implementations that don't perform stateful fragment checking which have made the mistake of not sending N(NON_FIRST_FRAGMENTS_ALSO) in the case I described earlier (tunnel-mode SA sending locally originated traffic)? 2) Are there any implementations, like yours, that are treating the absence of NON_FIRST_FRAGMENTS_ALSO in a more lenient fashion than RFC 4301 allows? 3) Do you have plans to change your own implementation to conform to RFC 4301 as quoted above? Thanks, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: ipsec@ietf.org Date: 10/07/2008 07:41 AM Subject: [IPsec] NON_FIRST_FRAGMENTS_ALSO question Scott C Moonen writes: > 1) Does your implementation perform stateful fragment checking? Yes, we always do stateful fragment checking. > 2) Regardless of the answer to #1, does your implementation correctly > recognize that in this case there is a pseudo stateful fragment checking > going on even though the traffic at your endpoint is not forwarded? As we always do stateful checking that does include locally generated packets too. > 3) How do you handle this case? Do you send NON_FIRST_FRAGMENTS_ALSO? > Or do you mark the SA as stateful-fragment-checking=false, perhaps > discarding those non-first fragments? Or do you have additional logic to > perform a second SPD lookup for these non-first fragments after they have > been produced, so that they can be sent on the appropriate port=ALL or > port=OPAQUE SA? We always send NON_FIRST_FRAGMENTS_ALSO notify and always do stateful fragment checking, and send non first fragments in the same SA. > 4) If you treat this as a NON_FIRST_FRAGMENTS_ALSO case, what do you do > in the event that NON_FIRST_FRAGMENTS_ALSO is not also sent by the peer? > Do you delete the SA and document that a port=ALL SA must be established > instead (e.g., by setting the port PFP flags to false)? Or do you revert > to any of the behaviors suggested in the previous question? Currently we simply ignore the fact that other end didn't send the NON_FIRST_FRAGMENTS_ALSO and send non first fragments to the SA, and if other end drops them, then we do have configuration mismatch causing black hole for fragmented packets. -- kivinen@safenet-inc.com --=_alternative 006E52F4852574DD_= Content-Type: text/html; charset="US-ASCII"
Tero, thanks for your reply.  I would be very tempted to take the same approach, issuing a warning message but leaving the SA up and continuing to flow traffic.  I also wonder if it is possible that some minimal implementations may not be sending N(NON_FIRST_FRAGMENTS_ALSO) in the case I described, perhaps wrongly thinking that this payload doesn't apply to them since they don't perform stateful fragment checking.  Taking a lax approach would provide the ability to interoperate with such an implementation without forcing the SA to specify all ports/types/codes.

However, this text from RFC 4301 makes me reluctant to take your approach:

   . . . If an implementation does not
   successfully negotiate transmission of non-initial fragments for such
   an SA, it MUST NOT send such fragments over the SA. . .

I wonder:

  1) Are there any implementations that don't perform stateful fragment checking which have made the mistake of not sending N(NON_FIRST_FRAGMENTS_ALSO) in the case I described earlier (tunnel-mode SA sending locally originated traffic)?
  2) Are there any implementations, like yours, that are treating the absence of NON_FIRST_FRAGMENTS_ALSO in a more lenient fashion than RFC 4301 allows?
  3) Do you have plans to change your own implementation to conform to RFC 4301 as quoted above?

Thanks,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen


From: Tero Kivinen <kivinen@iki.fi>
To: Scott C Moonen/Raleigh/IBM@IBMUS
Cc: ipsec@ietf.org
Date: 10/07/2008 07:41 AM
Subject: [IPsec] NON_FIRST_FRAGMENTS_ALSO question




Scott C Moonen writes:
>   1) Does your implementation perform stateful fragment checking?

Yes, we always do stateful fragment checking.

>   2) Regardless of the answer to #1, does your implementation correctly
> recognize that in this case there is a pseudo stateful fragment checking
> going on even though the traffic at your endpoint is not forwarded?

As we always do stateful checking that does include locally generated
packets too.

>   3) How do you handle this case?  Do you send NON_FIRST_FRAGMENTS_ALSO?
> Or do you mark the SA as stateful-fragment-checking=false, perhaps
> discarding those non-first fragments?  Or do you have additional logic to
> perform a second SPD lookup for these non-first fragments after they have
> been produced, so that they can be sent on the appropriate port=ALL or
> port=OPAQUE SA?

We always send NON_FIRST_FRAGMENTS_ALSO notify and always do stateful
fragment checking, and send non first fragments in the same SA.

>   4) If you treat this as a NON_FIRST_FRAGMENTS_ALSO case, what do you do
> in the event that NON_FIRST_FRAGMENTS_ALSO is not also sent by the peer?
> Do you delete the SA and document that a port=ALL SA must be established
> instead (e.g., by setting the port PFP flags to false)?  Or do you revert
> to any of the behaviors suggested in the previous question?

Currently we simply ignore the fact that other end didn't send the
NON_FIRST_FRAGMENTS_ALSO and send non first fragments to the SA, and
if other end drops them, then we do have configuration mismatch
causing black hole for fragmented packets.
--
kivinen@safenet-inc.com

--=_alternative 006E52F4852574DD_=-- --===============1182160846== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1182160846==-- From wslovenl@textware.com Sat Oct 11 20:49:50 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654693A6855 for ; Sat, 11 Oct 2008 20:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.384 X-Spam-Level: *** X-Spam-Status: No, score=3.384 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_DE=0.35, HELO_EQ_DSL=1.129, RCVD_IN_PBL=0.905] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOQlbczCp23m for ; Sat, 11 Oct 2008 20:49:49 -0700 (PDT) Received: from g229197016.adsl.alicedsl.de (g229197016.adsl.alicedsl.de [92.229.197.16]) by core3.amsl.com (Postfix) with SMTP id 871C53A680E for ; Sat, 11 Oct 2008 20:49:48 -0700 (PDT) From: To: Subject: IOX RockHardErection For Long Tieduzg Date: Sat, 11 Oct 2008 20:50:47 -0800 MIME-Version: 1.0 Message-Id: <20081012034948.871C53A680E@core3.amsl.com> http://spaces.live.com/lhllxybvngo?aeykoaorflwp reu Bjdn4txsYHzIUs1pU1 From ipsec-bounces@ietf.org Sun Oct 12 03:19:22 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 723743A690E; Sun, 12 Oct 2008 03:19:22 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473E33A6974 for ; Sun, 12 Oct 2008 03:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf4QjRQNCFKD for ; Sun, 12 Oct 2008 03:19:20 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id AFF3C3A690E for ; Sun, 12 Oct 2008 03:19:19 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id AAD11294003; Sun, 12 Oct 2008 12:20:07 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 38EE5294002 for ; Sun, 12 Oct 2008 12:20:06 +0200 (IST) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9CAK5ke002155 for ; Sun, 12 Oct 2008 12:20:05 +0200 (IST) Message-Id: <0084113E-DDF5-4042-9B06-F3AA2FADB839@checkpoint.com> From: Yoav Nir To: ipsec@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 12 Oct 2008 12:20:03 +0200 References: <20081012093002.1349D3A6934@core3.amsl.com> X-Mailer: Apple Mail (2.929.2) Subject: [IPsec] Fwd: I-D Action:draft-nir-ike-qcd-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1919337003==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1919337003== Content-Type: multipart/alternative; boundary=Apple-Mail-5-686468151 --Apple-Mail-5-686468151 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi all This is version -03 of QCD. It includes clarifications based on comments we've got and an explanation of the scenario of a load-sharing cluster without intramember synchronization. As always, comments are welcome. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: October 12, 2008 11:30:02 AM GMT+02:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-nir-ike-qcd-03.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : A Quick Crash Detection Method for IKE > Author(s) : Y. Nir, et al. > Filename : draft-nir-ike-qcd-03.txt > Pages : 19 > Date : 2008-10-12 > > This document describes an extension to the IKEv2 protocol that > allows for faster detection of SA desynchronization using a saved > token. > > When an IPsec tunnel between two IKEv2 peers is disconnected due to a > restart of one peer, it can take as much as several minutes for the > other peer to discover that the reboot has occurred, thus delaying > recovery. In this text we propose an extension to the protocol, that > allows for recovery immediately following the restart. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nir-ike-qcd-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Scanned by Check Point Total Security Gateway. --Apple-Mail-5-686468151 Content-Type: multipart/mixed; boundary=Apple-Mail-6-686468151 --Apple-Mail-6-686468151 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi all

This = is version -03 of QCD.

It includes = clarifications based on comments we've got and an explanation of the = scenario of a load-sharing cluster without intramember = synchronization.

As always, comments are = welcome.

Begin forwarded message:

Date: October 12, 2008 11:30:02 AM = GMT+02:00
To: i-d-announce@ietf.org
Subject: = I-D Action:draft-nir-ike-qcd-03.txt 

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.

Title =           : A Quick = Crash Detection Method for IKE
Author(s) =       : Y. Nir, et al.
Filename =        : = draft-nir-ike-qcd-03.txt
Pages =           : = 19
= Date =            : = 2008-10-12

This document describes an extension to the IKEv2 = protocol that
allows for faster detection of SA desynchronization = using a saved
token.

When an IPsec tunnel between two IKEv2 = peers is disconnected due to a
restart of one peer, it can take as = much as several minutes for the
other peer to discover that the = reboot has occurred, thus delaying
recovery.  In this text we = propose an extension to the protocol, that
allows for recovery = immediately following the restart.

A URL for this Internet-Draft = is:
http= ://www.ietf.org/internet-drafts/draft-nir-ike-qcd-03.txt

Intern= et-Drafts are also available by anonymous FTP = at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-6-686468151 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2008-10-12022358.I-D@ietf.org>

--Apple-Mail-6-686468151 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Scanned by Check Point Total Security Gateway.

--Apple-Mail-6-686468151-- --Apple-Mail-5-686468151-- --===============1919337003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1919337003==-- From ipsec-bounces@ietf.org Mon Oct 13 03:21:27 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6874F3A68B2; Mon, 13 Oct 2008 03:21:27 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9AF3A6778 for ; Mon, 13 Oct 2008 03:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yvwsUWkTA7P for ; Mon, 13 Oct 2008 03:21:25 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id D39333A68B2 for ; Mon, 13 Oct 2008 03:21:24 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so792876tib.25 for ; Mon, 13 Oct 2008 03:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=eSFUtQfauRo0U/Cs4eDJbO6F12KFvdZXEdlYmGT0jQM=; b=Vguzw1ffSrJ9e+BzYmLHjuroZX+9nJIuA4b70VgfW7KZ2HsqijE+qM8HkahX8mhd5k KLJ4yUYBSJo1+N5jpcNF9YYtPybFgMAoYFBAKUKOJIpPnHDjDp6weWa8Y6VzxQyqpL+e BB/kOpFJX4DjfPo/x3WDLWRPSJf0uBMGi6S+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=inAz5vBQyRlLuWkvFxpSXyrZd+CvCo/VnxHF966ipgap41PheJ97E+V3Qxj1RCsyha h702nQq4ryry3eqK2bDgVL+Vl07UJzhMMorUbaSS/YBxegt0ACAKD4wA/yqVuStWtHJQ rKnfL46RCom60wIyLxfTgfYBZ02jVHnDtHIuU= Received: by 10.110.95.15 with SMTP id s15mr5195752tib.8.1223893336800; Mon, 13 Oct 2008 03:22:16 -0700 (PDT) Received: by 10.110.47.16 with HTTP; Mon, 13 Oct 2008 03:22:16 -0700 (PDT) Message-ID: Date: Mon, 13 Oct 2008 18:22:16 +0800 From: "ma yc" To: ipsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, all After reading both drafts, I have the feeling that both solutions need to find some places to store the ticket/stub before the session resumption happens. The Stub bank needs extra piece of storage which is located in operator's network. In the ticket approach, this storage distributed to the clients. Simply changing the storage location does not save the storage as a total at all. IMHO, I do believe the unit cost of Gateway storage is much cheaper than the one internally inside the Client, especially when we consider the mobile device case. Also, power consumption may increase to maintain this kind of extra storage in mobile device. For the sake of maintainence cost, this extra piece of storage on the network side is a better choice. -Yuanchen > > > We now have revised drafts from the two parties who has published earlier drafts on session resumption. The (truncated) announcements are below. > > The WG should start discussing what we want from session resumption and which of these two drafts (or what ideas from each of these two drafts) is of interest to the WG. As a reminder, I start off with what our charter says. > > Extra points are awarded for not copying this entire message in your response. :-) > > --Paul Hoffman > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 13 12:57:09 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0DD93A67F7; Mon, 13 Oct 2008 12:57:09 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECD8A3A6846 for ; Mon, 13 Oct 2008 12:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYD8YUsYAwwN for ; Mon, 13 Oct 2008 12:57:07 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0C44E3A67AB for ; Mon, 13 Oct 2008 12:57:06 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id BAA63294002; Mon, 13 Oct 2008 21:57:18 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 216D2294001; Mon, 13 Oct 2008 21:56:43 +0200 (IST) Received: from [172.31.21.141] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9DJucke003064; Mon, 13 Oct 2008 21:56:42 +0200 (IST) Message-Id: <64B21443-B613-4CB1-B201-572A1AFAEC39@checkpoint.com> From: Yoav Nir To: ma yc In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 13 Oct 2008 21:56:34 +0200 References: X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Yuanchen. I don't think this reasoning is quite correct. Storing thousands of stubs in a module accessible to multiple gateways (or persistent for one gateway) requires extra hardware and extra internal protocols. It has a real cost in terms of hardware. Extra storage on the client is essentially free. Whether the client is a PC or a mobile phone, increasing the size of the IKE SA by the amount needed by the ticket should not be a problem. In one implementation I've seen, an IKE SA took about 1K-2K, while a ticket should be at about 0.5K. And the client side has only one IKE SA. What IKE implementation is so constrained that adding a 0.5K requirement has a measurable cost? Yoav On Oct 13, 2008, at 12:22 PM, ma yc wrote: > Hi, all > > After reading both drafts, I have the feeling that both solutions > need to find some places to store the ticket/stub before the > session resumption happens. > > The Stub bank needs extra piece of storage which is located in > operator's network. In the ticket approach, this storage distributed > to the clients. Simply changing the storage location does not save > the storage as a total at all. > > IMHO, I do believe the unit cost of Gateway storage is much cheaper > than the one internally inside the Client, especially when we consider > the mobile device case. Also, power consumption may increase to > maintain this kind of extra storage in mobile device. For the sake of > maintainence cost, this extra piece of storage on the network side is > a better choice. > > -Yuanchen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 14 03:33:03 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09B213A67EE; Tue, 14 Oct 2008 03:33:03 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39E0C3A67EE for ; Tue, 14 Oct 2008 03:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPrQpje69Ul5 for ; Tue, 14 Oct 2008 03:32:57 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 6E8C83A67EA for ; Tue, 14 Oct 2008 03:32:57 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9EAWrPW018468; Tue, 14 Oct 2008 05:33:16 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:32:58 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:32:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 13:32:56 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201E72AFB@vaebe104.NOE.Nokia.com> In-Reply-To: <18650.7814.808443.474300@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA Thread-Index: AckeNU3LJb3+cqRVQOiqhp0QZxoxeQPskbYQ References: <18648.62020.138458.908262@fireball.kivinen.iki.fi> <18650.7814.808443.474300@fireball.kivinen.iki.fi> From: To: , X-OriginalArrivalTime: 14 Oct 2008 10:32:57.0479 (UTC) FILETIME=[395C6970:01C92DE8] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > Responder takes IV field from the packet a generates the real IV given > to the AES CTR by concatenating nonce (which is from keying material > generated by IKEv2), IV field, and block number (0). Responder does > not care how the IV was generated, and it does not need to care. > Responder will be interoperable with the other end regardless how the > initiator generates IVs. Note that RFC 4306 specifies that the IV length is equal to the block length of the underlying encryption algorithm. This doesn't work for CTR mode, so there's no way RFC 4306 and use of CTR mode in IKEv2 are compatible. (We could, of course, change this text in IKEv2bis...) Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 14 03:41:41 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1713A6A8D; Tue, 14 Oct 2008 03:41:41 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CAD13A6A8D for ; Tue, 14 Oct 2008 03:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yeJ6P10aR8KO for ; Tue, 14 Oct 2008 03:41:39 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 704E53A69C6 for ; Tue, 14 Oct 2008 03:41:39 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9EAfnNJ010293; Tue, 14 Oct 2008 13:41:52 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:41:47 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:41:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 13:41:39 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201E72B2A@vaebe104.NOE.Nokia.com> In-Reply-To: <18648.62996.136882.689426@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Issue #32 Demoted SHOULD: EAP Identity Request Thread-Index: AckdhI49704r6SWASQKtc0cVV5cktgQZC21Q References: <18648.62996.136882.689426@fireball.kivinen.iki.fi> From: To: , X-OriginalArrivalTime: 14 Oct 2008 10:41:44.0117 (UTC) FILETIME=[7342FE50:01C92DE9] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #32 Demoted SHOULD: EAP Identity Request X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > I.e. the valid reason for not skipping identity request would have > been that it is impossible because the EAP library does them > automatically and they cannot be disabled. The bad thing about doing > EAP identity request is that the policy lookups for the entity are NOT > done based on them, but based on the ID payloads in the IKEv2. If the > identity payloads mismatch (i.e. EAP payloads claim I am > kivinen@iki.fi, but the ID payload claims I am paul.hoffman@vpnc.org), > the authentication might still succeed as EAP library just uses the > EAP identity payload to verify the credentials, but IKE library uses > the ID sent in the IKE, and nobody matches that those two matches. > > BTW, I think we need to add some text that says those identities must > match or at least you MUST use the EAP identity for access control and > policy lookups, and also add some text to security considerations > section. When using e.g. EAP method that provides identity privacy using temporary pseudonyms, the identity carried in IDi and the identity authenticated by EAP won't typically match. RFC 4718 Section 3.5 has text about this: When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for AAA routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method (see [EAP], Sections 5.1 and 7.3). It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder using, e.g., RADIUS [RADEAP]. In this case, the authenticated identity has to be sent from the AAA server to the IKEv2 responder. This made its way to draft-ietf-ipsecme-ikev2bis-00, end of Section 2.16: {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is possible that the contents of the IDi payload is used only for AAA routing purposes and selecting which EAP method to use. This value may be different from the identity authenticated by the EAP method. It is important that policy lookups and access control decisions use the actual authenticated identity. Often the EAP server is implemented in a separate AAA server that communicates with the IKEv2 responder. In this case, the authenticated identity has to be sent from the AAA server to the IKEv2 responder. Do you think we need more text about this? Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 14 03:56:18 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25CFF3A6889; Tue, 14 Oct 2008 03:56:18 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA9B53A6889 for ; Tue, 14 Oct 2008 03:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.401 X-Spam-Level: X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzKKupdFTf2Z for ; Tue, 14 Oct 2008 03:56:16 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 11FD43A67F8 for ; Tue, 14 Oct 2008 03:56:16 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9EAtmsp007519; Tue, 14 Oct 2008 05:56:39 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:56:20 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 13:56:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 14 Oct 2008 13:56:16 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201E72B7C@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Original initiator (was: Some (ok, a lot) comments to ikev2bis) Thread-Index: AckbkcN7ahgGKQK5SFGYgRmIth7oTwSWOPXg References: <18574.24516.764629.590327@fireball.kivinen.iki.fi> From: To: , X-OriginalArrivalTime: 14 Oct 2008 10:56:18.0345 (UTC) FILETIME=[7C579990:01C92DEB] X-Nokia-AV: Clean Subject: [IPsec] Original initiator (was: Some (ok, a lot) comments to ikev2bis) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Paul Hoffman wrote: > > * I(nitiator) (bit 3 of Flags) - This bit MUST be set in > > messages sent by the original initiator of the IKE_SA and > > MUST be cleared in messages sent by the original responder. > > It is used by the recipient to determine which eight octets > > of the SPI were generated by the recipient. > > Add clarification here, that the Inititor bit does not change even > if IKE SA is rekeyed (regardless who rekeys it). > > ===Done. Hmm -- is this consistent with Clarif-5.9? (included in the end of Section 2.8) Tero seems to be proposing that rekeying can't change who the original initiator is, but that's not what we decided back in 2005 when discussing what to say in Clarif-5.9. This did cause some terminology challenges in MOBIKE (see RFC 4555, Section 1.3, 3rd paragraph), but in the end, it works either way. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 14 05:40:27 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F17393A683C; Tue, 14 Oct 2008 05:40:26 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AC6528C0CF for ; Tue, 14 Oct 2008 05:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7rJvMU6w2ID for ; Tue, 14 Oct 2008 05:40:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id D0EC63A683C for ; Tue, 14 Oct 2008 05:40:10 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m9ECdaqx007511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 15:39:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m9ECdY1B014180; Tue, 14 Oct 2008 15:39:34 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18676.37638.443520.835980@fireball.kivinen.iki.fi> Date: Tue, 14 Oct 2008 15:39:34 +0300 From: Tero Kivinen To: In-Reply-To: <1696498986EFEC4D9153717DA325CB7201E72AFB@vaebe104.NOE.Nokia.com> References: <18648.62020.138458.908262@fireball.kivinen.iki.fi> <18650.7814.808443.474300@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201E72AFB@vaebe104.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 19 min X-Total-Time: 22 min Cc: ipsec@ietf.org, paul.hoffman@vpnc.org Subject: Re: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > Tero Kivinen wrote: > > Responder takes IV field from the packet a generates the real IV given > > to the AES CTR by concatenating nonce (which is from keying material > > generated by IKEv2), IV field, and block number (0). Responder does > > not care how the IV was generated, and it does not need to care. > > Responder will be interoperable with the other end regardless how the > > initiator generates IVs. > > Note that RFC 4306 specifies that the IV length is equal to the block > length of the underlying encryption algorithm. This doesn't work for > CTR mode, so there's no way RFC 4306 and use of CTR mode in IKEv2 are > compatible. AES (the underlying encryption algorithm) has block size of 128 bits, and IV length to be used with CTR mode is defined in the section 3.1 in the RFC3686. I do not see any way anybody could use any other IV length than the one defined in the RFC3686 which also matches the "block length of the underlying encryption algorithm". I do not really see any reason why this does not work with CTR mode too, especially as it is using "underlying encryption algorithm" instead of refering the block size requiremetns of the selected mode and algorithm to be used. > (We could, of course, change this text in IKEv2bis...) As there is no newer RFCs or drafts to specify how to use counter mode algorithms, and I do not really consider the text in RFC4306 to forbid CTR mode ciphers, and RFC3686 do fill up the gaps in the RFC4306 by specifying the IV length and the IV generation rules. We should most likely change the IKEv2bis text from: ---------------------------------------------------------------------- o Initialization Vector - Optional block of bits that is required to allow encrption algorithm to produce a unique stream independent from other streams produced by same key. The length and generation depends on the encryption algorithm and mode it is used in. For CBC modes the initialization vector is a randomly chosen value whose length is equal to the block length of the underlying encryption algorithm. Recipients MUST accept any value. Senders SHOULD either pick this value pseudo-randomly and independently for each message or use the final ciphertext block of the previous message sent. Senders MUST NOT use the same value for each message, use a sequence of values with low hamming distance (e.g., a sequence number), or use ciphertext from a received message. For other modes the IV format and processing is specified in the document specifying the encryption algorithm and mode. ---------------------------------------------------------------------- I.e. change add some generic text to really tell what IV is (I copied that mostly from wikipedia), and then tell that the rest of the text is for CBC mode, and other modes do tell how the IV is used in the corresponding documents. The RFC3686 do tell IV length and how it is generated. Hmm.. found another problem in the RFC4306. The ENCR_AES_CTR has wrong reference. It is refering to the RFC3664 (The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)), instead of the RFC3686 (Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 14 05:47:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 942EC3A6BBB; Tue, 14 Oct 2008 05:47:50 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6A3D3A6BB8 for ; Tue, 14 Oct 2008 05:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDeS1F1trhEB for ; Tue, 14 Oct 2008 05:47:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 60F3F3A67D6 for ; Tue, 14 Oct 2008 05:46:45 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m9EClQL3006248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 15:47:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m9EClQ41024469; Tue, 14 Oct 2008 15:47:26 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18676.38110.500984.207815@fireball.kivinen.iki.fi> Date: Tue, 14 Oct 2008 15:47:26 +0300 From: Tero Kivinen To: In-Reply-To: <1696498986EFEC4D9153717DA325CB7201E72B2A@vaebe104.NOE.Nokia.com> References: <18648.62996.136882.689426@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201E72B2A@vaebe104.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #32 Demoted SHOULD: EAP Identity Request X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > This made its way to draft-ietf-ipsecme-ikev2bis-00, end of Section 2.16: > > {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is > possible that the contents of the IDi payload is used only for AAA > routing purposes and selecting which EAP method to use. This value > may be different from the identity authenticated by the EAP method. > It is important that policy lookups and access control decisions use > the actual authenticated identity. Often the EAP server is > implemented in a separate AAA server that communicates with the IKEv2 > responder. In this case, the authenticated identity has to be sent > from the AAA server to the IKEv2 responder. > > Do you think we need more text about this? Ah, missed that text. Would have mostly assumed it to be in the security considerations section, but I think the EAP section is ok too. Perhaps add another pointer to that section in the section 3.16 where it tells that "responder SHOULD NOT send EAP identity requests", and point implementors to that Clarif-3.5 text if the that SHOULD NOT is not followed. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 14 06:09:53 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A343A6BA4; Tue, 14 Oct 2008 06:09:53 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A56193A6BA4 for ; Tue, 14 Oct 2008 06:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55jzDVSlngUy for ; Tue, 14 Oct 2008 06:09:52 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 86A1A3A69C0 for ; Tue, 14 Oct 2008 06:07:51 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m9ED8M3R005142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Oct 2008 16:08:22 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m9ED8MbV007374; Tue, 14 Oct 2008 16:08:22 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18676.39366.358720.94324@fireball.kivinen.iki.fi> Date: Tue, 14 Oct 2008 16:08:22 +0300 From: Tero Kivinen To: In-Reply-To: <1696498986EFEC4D9153717DA325CB7201E72B7C@vaebe104.NOE.Nokia.com> References: <18574.24516.764629.590327@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201E72B7C@vaebe104.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 4 min X-Total-Time: 17 min Cc: ipsec@ietf.org, paul.hoffman@vpnc.org Subject: [IPsec] Original initiator (was: Some (ok, a lot) comments to ikev2bis) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > Paul Hoffman wrote: > > > > * I(nitiator) (bit 3 of Flags) - This bit MUST be set in > > > messages sent by the original initiator of the IKE_SA and > > > MUST be cleared in messages sent by the original responder. > > > It is used by the recipient to determine which eight octets > > > of the SPI were generated by the recipient. > > > > Add clarification here, that the Inititor bit does not change even > > if IKE SA is rekeyed (regardless who rekeys it). > > > > ===Done. > > Hmm -- is this consistent with Clarif-5.9? (included in the end > of Section 2.8) > > Tero seems to be proposing that rekeying can't change who the > original initiator is, but that's not what we decided back in 2005 > when discussing what to say in Clarif-5.9. This did cause some > terminology challenges in MOBIKE (see RFC 4555, Section 1.3, 3rd > paragraph), but in the end, it works either way. Ah true, it was that way around. Forgot that already, but that just proves the point that we need to mention it here too, as even I misremembered how it should be... :-) So the clarification should say that this bit changes to reflect who initiated the last rekey for the IKE SA. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 14 07:45:54 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC193A6C0D; Tue, 14 Oct 2008 07:45:54 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BEE23A6BF1 for ; Tue, 14 Oct 2008 07:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5P6CisHuHoNN for ; Tue, 14 Oct 2008 07:45:52 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 623BA3A6C03 for ; Tue, 14 Oct 2008 07:45:21 -0700 (PDT) Received: from [165.227.249.203] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9EEkDgp002941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Oct 2008 07:46:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18676.39366.358720.94324@fireball.kivinen.iki.fi> References: <18574.24516.764629.590327@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201E72B7C@vaebe104.NOE.Nokia.com> <18676.39366.358720.94324@fireball.kivinen.iki.fi> Date: Tue, 14 Oct 2008 07:39:53 -0700 To: From: Paul Hoffman Subject: Re: [IPsec] Original initiator (was: Some (ok, a lot) comments to ikev2bis) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 4:08 PM +0300 10/14/08, Tero Kivinen wrote: >Pasi.Eronen@nokia.com writes: >> Paul Hoffman wrote: >> >> > > * I(nitiator) (bit 3 of Flags) - This bit MUST be set in >> > > messages sent by the original initiator of the IKE_SA and >> > > MUST be cleared in messages sent by the original responder. >> > > It is used by the recipient to determine which eight octets >> > > of the SPI were generated by the recipient. >> > >> > Add clarification here, that the Inititor bit does not change even >> > if IKE SA is rekeyed (regardless who rekeys it). >> > >> > ===Done. >> >> Hmm -- is this consistent with Clarif-5.9? (included in the end >> of Section 2.8) >> > > Tero seems to be proposing that rekeying can't change who the >> original initiator is, but that's not what we decided back in 2005 >> when discussing what to say in Clarif-5.9. This did cause some >> terminology challenges in MOBIKE (see RFC 4555, Section 1.3, 3rd >> paragraph), but in the end, it works either way. > >Ah true, it was that way around. Forgot that already, but that just >proves the point that we need to mention it here too, as even I >misremembered how it should be... :-) > >So the clarification should say that this bit changes to reflect who >initiated the last rekey for the IKE SA. Is that what we actually want? Or do we want to say what Tero proposed (the initiator is always the initiator)? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 14 11:03:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E86B3A69CD; Tue, 14 Oct 2008 11:03:50 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFD93A69CD for ; Tue, 14 Oct 2008 11:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lPYCXWmNVRS for ; Tue, 14 Oct 2008 11:03:48 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 557A03A67D6 for ; Tue, 14 Oct 2008 11:03:48 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7FFDE10224092; Tue, 14 Oct 2008 11:04:06 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 14 Oct 2008 11:04:06 -0700 (PDT) Message-ID: In-Reply-To: <1696498986EFEC4D9153717DA325CB7201E72B2A@vaebe104.NOE.Nokia.com> References: <18648.62996.136882.689426@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201E72B2A@vaebe104.NOE.Nokia.com> Date: Tue, 14 Oct 2008 11:04:06 -0700 (PDT) From: "Dan Harkins" To: Pasi.Eronen@nokia.com User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, kivinen@iki.fi Subject: Re: [IPsec] Issue #32 Demoted SHOULD: EAP Identity Request X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Pasi, On Tue, October 14, 2008 3:41 am, Pasi.Eronen@nokia.com wrote: [snip] > This made its way to draft-ietf-ipsecme-ikev2bis-00, end of Section 2.16: > > {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is > possible that the contents of the IDi payload is used only for AAA > routing purposes and selecting which EAP method to use. This value > may be different from the identity authenticated by the EAP method. > It is important that policy lookups and access control decisions use > the actual authenticated identity. Often the EAP server is > implemented in a separate AAA server that communicates with the IKEv2 > responder. In this case, the authenticated identity has to be sent > from the AAA server to the IKEv2 responder. > > Do you think we need more text about this? What AAA attribute is supposed to be used by the AAA server to communicate this information back to the IKEv2 responder? And it's a little more complicated too. Not only is the EAP server often implemented in a separate AAA server, in some EAP methods that server won't even me the one doing the actual client authentication! In a tunneled EAP method like PEAP or TTLS the "inner method" may be done by yet another AAA server. Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 14 14:46:14 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56C1728C1B5; Tue, 14 Oct 2008 14:46:14 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EF0628C1B5 for ; Tue, 14 Oct 2008 14:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zde3VJ4gLfVZ for ; Tue, 14 Oct 2008 14:46:12 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 5D55928C145 for ; Tue, 14 Oct 2008 14:46:12 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7F38A294004; Tue, 14 Oct 2008 23:46:43 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 17CEC294003; Tue, 14 Oct 2008 23:46:42 +0200 (IST) Received: from [172.31.21.141] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9ELkeke006942; Tue, 14 Oct 2008 23:46:41 +0200 (IST) Message-Id: From: Yoav Nir To: =?UTF-8?B?6IOh5rOK?= In-Reply-To: <36f1fcac18324f585784a155344d8959@mail.ritt.com.cn> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 14 Oct 2008 23:46:40 +0200 References: <36f1fcac18324f585784a155344d8959@mail.ritt.com.cn> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org, paul.hoffman@vpnc.org Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Ck9uIE9jdCAxNCwgMjAwOCwgYXQgNjozNSBQTSwg6IOh5rOKIHdyb3RlOgoKPiBIaSwgWW9hdiBh bmQgYWxsOgo+Cj4gVGhpcyBkaXNjdXNzaW9uIGlzIGJlY29taW5nIG1vcmUgYW5kIG1vcmUgaW50 ZXJlc3RpbmcuIFBsZWFzZSBjaGVjayBteQo+IHJlcGx5IGJlbG93Ogo+Cj4+PiBUaGUgdGlja2V0 IHNoYXJlcyB0aGUgcGFja2V0IHdpdGggdHJhZmZpYyBzZWxlY3RvcnMsIGNvbmZpZ3VyYXRpb24K Pj4+IHBheWxvYWQsIGF1dGhlbnRpY2F0aW9uLCBjZXJ0aWZpY2F0ZXMgYW5kIG90aGVyIHBheWxv YWRzLiBUaGF0Cj4+PiBwYWNrZXQgY2FuIGJlIHF1aXRlIGxhcmdlLCB3aGljaCBsZWFkcyB0byBm cmFnbWVudGF0aW9uIGFuZCAgCj4+PiBwb3RlbnRpYWxseQo+Pj4gcGFja2V0IGxvc3MuCj4KPiBJ biB0aGlzIHNlbnNlLCB0aGUgbWVzc2FnZSB0byBkZWxpdmVyIHRpY2tldCBjb3VsZCBzdWZmZXIg ZnJvbSB0aGUgSVAKPiBmcmFnbWVudGF0aW9uLiBXZWxsLCB3aGVuIHdlIHNlZSB0aGUgUkZDNDMw NiAoSUtFdjLCo8KpwqPCrHRoZSAgCj4gZm9sbG93aW5nCj4gbGluZXMgY2FuIGJlIGZvdW5kOgo+ Cj4gPT09PT09PT09PT09PT09PT09PT09Cj4gIEFsdGhvdWdoIElLRXYyIG1lc3NhZ2VzIGFyZSBp bnRlbmRlZCB0byBiZSBzaG9ydCwgdGhleSBjb250YWluCj4gIHN0cnVjdHVyZXMgd2l0aCBubyBo YXJkIHVwcGVyIGJvdW5kIG9uIHNpemUgKGluIHBhcnRpY3VsYXIsIFguNTA5Cj4gIGNlcnRpZmlj YXRlcyksIGFuZCBJS0V2MiBpdHNlbGYgZG9lcyBub3QgaGF2ZSBhIG1lY2hhbmlzbSBmb3IKPiAg ZnJhZ21lbnRpbmcgbGFyZ2UgbWVzc2FnZXMuICBJUCBkZWZpbmVzIGEgbWVjaGFuaXNtIGZvciBm cmFnbWVudGF0aW9uCj4gIG9mIG92ZXJzaXplIFVEUCBtZXNzYWdlcywgYnV0IGltcGxlbWVudGF0 aW9ucyB2YXJ5IGluIHRoZSBtYXhpbXVtCj4gIG1lc3NhZ2Ugc2l6ZSBzdXBwb3J0ZWQuICBGdXJ0 aGVybW9yZSwgdXNlIG9mIElQIGZyYWdtZW50YXRpb24gb3BlbnMKPiAgYW4gaW1wbGVtZW50YXRp b24gdG8gZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrcyBbS1BTMDNdLiAgRmluYWxseSwKPiAgc29t ZSBOQVQgYW5kL29yIGZpcmV3YWxsIGltcGxlbWVudGF0aW9ucyBtYXkgYmxvY2sgSVAgZnJhZ21l bnRzLgo+Cj4gPT09PT09PT09PT09PT09PT09PT09Cj4gT2J2aW91c2x5LCBiYXNlIElLRXYyIHBy b3RvY29sIHJlY29tbWVuZHMgc2hvcnQgbWVzc2FnZXMuIEluIHRoZQo+IHRpY2tldCBzb2x1dGlv biwgZXhjZXB0IGZvciB0aGUgdGlja2V0IHByZXNlbnRhdGlvbiwgdGhlIEdXIHN1cmVseQo+IG5l ZWQgdG8gcHVzaCB0aGUgdGlja2V0cyB0byBjbGllbnRzIGJ5IElLRXYyIG1lc3NhZ2VzIGJlZm9y ZWhhbmQuIFdpbGwKPiB0aGUgZnJhZ21lbnRlZCBwYWNrZXQgZm9yIHRpY2tldCBkZWxpdmVyeSBj b21wcm9taXNlIHRoZSBwcmluY2lwbGUgb2YKPiBJS0V2MiBiYXNlIHByb3RvY29sPwo+Cj4gRG9l cyBhbnlib2R5IGluIHRoaXMgbGlzdCBjYW4gY2xhcmlmeSBIb3cgbXVjaCBuZWdhdGl2ZSBlZmZl Y3Qgb2YKPiBtZXNzYWdlIGZyYWdtZW50YXRpb24gaXMgb24gSUtFdjIgb3BlcmF0aW9uPwo+Cj4g VGhhbmtzCj4KPiAtUG8KCklLRXYyIHJlY29tbWVuZHMgc2hvcnQgbWVzc2FnZXMsIGJ1dCB0aGVu IGdvZXMgb24gdG8gaW5jbHVkZSBpbiB0aGUgIApsYXN0IElLRV9BVVRIIHBhY2tldCB0aGUgdHJh ZmZpYyBzZWxlY3RvcnMgKHdoaWNoIG1heSBpbmNsdWRlIHRoZSAgCmVudGlyZSBwcm90ZWN0ZWQg bmV0d29ya3MpLCB0aGUgY29uZmlndXJhdGlvbiBwYXlsb2FkICh3aGljaCBtYXkgYWxzbyAgCmlu Y2x1ZGUgdGhlIGVudGlyZSBwcm90ZWN0ZWQgbmV0d29ya3MsIGJ1dCBpbiBhIGRpZmZlcmVudCBm b3JtYXQsICAKY2VydGlmaWNhdGVzICh3aGljaCBoYXZlIG5vIHVwcGVyIGJvdW5kIG9uIHNpemUp IGFuZCBwb3RlbnRpYWxseSBldmVuICAKQ1JMcy4gIFNvIHRoYXQgcGFja2V0IGlzIGFscmVhZHkg aW4gZGFuZ2VyIG9mIGJlaW5nIHRvbyBsYXJnZSwgYW5kICAKYWRkaW5nIGEgY2h1bmt5IHBheWxv YWQgbGlrZSB0aGUgdGlja2V0IGluY3JlYXNlcyB0aGUgbGlrZWxpaG9vZCBvZiAgCmZyYWdtZW50 YXRpb24uCgpBcyBmb3IgdGhlIG5lZ2F0aXZlIGVmZmVjdHMsIHRoZXJlIGlzIG9idmlvdXNseSB0 aGUgcHJvYmxlbSBvZiBwYWNrZXQgIApsb3NzLiBJbiBhIGhpZ2ggcGFja2V0IGxvc3MgZW52aXJv bm1lbnQgKHdpcmVsZXNzIGRldmljZXMgY29tZSB0byAgCm1pbmQpIGlmLCBzYXksIDMwJSBvZiBw YWNrZXRzIGdldCBsb3N0LCA1MCUgb2YgMi1mcmFnbWVudCBwYWNrZXRzIHdpbGwgIApiZSBsb3N0 LCBhbmQgNjUlIG9mIDMtZnJhZ21lbnQgcGFja2V0cy4gQWxzbywgYXMgdGhlIElLRXYyIGRvY3Vt ZW50ICAKc2F5cywgc29tZSBvcGVyYXRpbmcgc3lzdGVtcyB3aWxsIGhhdmUgYSBsaW1pdCBvbiBh c3NlbWJseSwgYXMgd2lsbCAgCnNvbWUgZmlyZXdhbGxzIHRoYXQgcmVhc3NlbWJsZSBmcmFnbWVu dHMgdG8gaW5zcGVjdCB0aGUgcGFja2V0IGluIGZ1bGwuCgpJbiB0aGUgZWFybHkgMjAwMCdzIGEg bG90IG9mIHdpcmVsZXNzIGFjY2VzcyBwb2ludHMsIGhvbWUgcm91dGVycywgRFNMICAKbW9kZW1z IGFuZCBzdWNoIHdlcmUgYnJva2VuIC0gdGhleSBkcm9wcGVkIGFsbCBmcmFnbWVudHMsIHNvIGFu eSAgCnBhY2tldCBsYXJnZXIgdGhhbiB0aGUgTVRVIHdhcyBkb29tZWQgdG8gYmUgZHJvcHBlZC4g VGhpbmdzIHdlcmUgc28gIApiYWQsIHRoYXQgbXkgY29tcGFueSBoYWQgdG8gaW52ZW50IGEgcHJv cHJpZXRhcnkgSUtFLW92ZXItVENQIGp1c3QgdG8gIApnZXQgY2xpZW50IGNvbm5lY3Rpb25zIHdv cmtpbmcuIFRoaXMgaGFzIHZhc3RseSBpbXByb3ZlZC4gVG9kYXkgbW9zdCAgCnN1Y2ggZXF1aXBt ZW50IGlzIHdvcmtpbmcgd2VsbCwgYW5kIGZyYWdtZW50cyBhcmUgcGFzc2VkIHRocm91Z2ggIApj b3JyZWN0bHkuIE9wZXJhdGluZyBzeXN0ZW1zIGluIHVzZSB0b2RheSBhcmUgYWxzbyBpbiBiZXR0 ZXIgc2hhcGUsICAKYW5kIEkgY2FuJ3QgdGhpbmsgb2YgYW55IGN1cnJlbnQgdmVyc2lvbiB0aGF0 IHdvbid0IGhhbmRsZSBVRFAgcGFja2V0cyAgCmFzIGxhcmdlIGFzIHRoZSBzdGFuZGFyZHMgYWxs b3cuIFBhY2tldCBsb3NzIGlzIHN0aWxsIGFuIGlzc3VlLCBidXQgIApmb3IgcmVndWxhciB3aXJl ZCBhbmQgd2lyZWxlc3MgYWNjZXNzLCBldmVuIG1vc3QgY2VsbHVsYXIsIHBhY2tldCBsb3NzICAK aXMgcmVhc29uYWJseSBsb3cuCgpJIGFkbWl0IHRoYXQgbXkgZXhwZXJpZW5jZSBtYXkgbm90IGJl IHJlcHJlc2VudGF0aXZlIG9mIGFsbCB0aGUgd29ybGQsICAKYnV0IElNTyBzb21lIGZyYWdtZW50 YXRpb24gaXMgbm90IGFzIGJpZyBhIHByb2JsZW0gYXMgaXQgdXNlZCB0byBiZS4KCllvYXYKCgoK X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSVBzZWMgbWFp bGluZyBsaXN0CklQc2VjQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaXBzZWMK From ipsec-bounces@ietf.org Wed Oct 15 03:08:38 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB8263A6C66; Wed, 15 Oct 2008 03:08:37 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84CBF3A6AA6 for ; Wed, 15 Oct 2008 03:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NudFqwwEcMVQ for ; Wed, 15 Oct 2008 03:08:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 0613B3A6922 for ; Wed, 15 Oct 2008 03:08:20 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m9FA8pY0024814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Oct 2008 13:08:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m9FA8oBN016799; Wed, 15 Oct 2008 13:08:50 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18677.49458.329951.94608@fireball.kivinen.iki.fi> Date: Wed, 15 Oct 2008 13:08:50 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <18574.24516.764629.590327@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201E72B7C@vaebe104.NOE.Nokia.com> <18676.39366.358720.94324@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Original initiator (was: Some (ok, a lot) comments to ikev2bis) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Paul Hoffman writes: > Is that what we actually want? Or do we want to say what Tero > proposed (the initiator is always the initiator)? We must keep backward compatibility and this do affect interoperation, thus we must keep it as it was before. I just remembered that there had been problems with that bit before, but as I didn't check the specification for that bit when I wrote those comments, I got it wrong way around... -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 15 05:39:40 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93A5A28C217; Wed, 15 Oct 2008 05:39:40 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2839128C217 for ; Wed, 15 Oct 2008 05:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_83=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RxDeJAd6t0V for ; Wed, 15 Oct 2008 05:39:38 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id A116628C213 for ; Wed, 15 Oct 2008 05:39:38 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so661752yxg.49 for ; Wed, 15 Oct 2008 05:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=0LDJQmz8IxDJtnfjrw9PJie0aoKf6sQxQos0rRbBpXg=; b=qe+av7kkEDrN04jb/PIvLKVFLlUVrOm6AzlHSQTggYfK1soD++SBoAzkIPoPW3mIZ6 PYayyg+NKC2ga/5nGV4LZMQGrBQDmX1iYpqQu64XIcabYg+0NZ37gQG3gY5vJwLqSPH/ 72b/fp8mwXuvmY+1fzeLl33aclIl9XQZgbO2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=sNW+m7Fds3umhqCAlZlLaofmUj5F9+ONkJ9v5h7uoflOYJHDzLu5tJFNZbRI4P7bhe SnhipylCeBEaezbdqT6Zn2sRp4+NkUhIBac9VoRVYIGiiexpUcMgDzmFQ3c3gYTITp+s QRPwf58cQwr5UUE7zDblZomWVvTzcAzvWHcp4= Received: by 10.90.94.2 with SMTP id r2mr1097078agb.54.1224074426422; Wed, 15 Oct 2008 05:40:26 -0700 (PDT) Received: by 10.90.66.4 with HTTP; Wed, 15 Oct 2008 05:40:26 -0700 (PDT) Message-ID: <850df0c40810150540w10ba5ee8q630884fef5c67bf1@mail.gmail.com> Date: Wed, 15 Oct 2008 14:40:26 +0200 From: "balaji raghavan" To: "Dan Harkins" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <18648.62996.136882.689426@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201E72B2A@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, kivinen@iki.fi Subject: Re: [IPsec] Issue #32 Demoted SHOULD: EAP Identity Request X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balaji.raghavan.t@gmail.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, >> This made its way to draft-ietf-ipsecme-ikev2bis-00, end of Section 2.16: >> >> {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is >> possible that the contents of the IDi payload is used only for AAA >> routing purposes and selecting which EAP method to use. This value >> may be different from the identity authenticated by the EAP method. >> It is important that policy lookups and access control decisions use >> the actual authenticated identity. Often the EAP server is >> implemented in a separate AAA server that communicates with the IKEv2 >> responder. In this case, the authenticated identity has to be sent >> from the AAA server to the IKEv2 responder. >> >> Do you think we need more text about this? > > What AAA attribute is supposed to be used by the AAA server to communicate > this information back to the IKEv2 responder? > > And it's a little more complicated too. Not only is the EAP server often > implemented in a separate AAA server, in some EAP methods that server won't > even me the one doing the actual client authentication! In a tunneled EAP > method like PEAP or TTLS the "inner method" may be done by yet another AAA > server. > The AAA server can communicate the authenticated identity to the IKEv2 responder if required, for example in the case of RADIUS using the User-Name attribute in an Access-Accept response.. However it is not mandatory for the RADIUS server to do so. Identifiers are used to match responses to requests(rfc 2865). Perhaps it was meant to be interpreted as this: The RADIUS server not only authenticates the EAP identity, but also communicates to the IKEv2 responder as to what is acceptable in the IDi payload ? However wouldn't that be stretching the use of the 'User-Name' attribute in rfc 2865 ? But the bottom line is that the identity in the IDi payload is used to determine the policy lookup, access control etc and maybe if needed to select the EAP method. -Best Regards Balaji Raghavan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 16 02:43:36 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CB383A6B40; Thu, 16 Oct 2008 02:43:36 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF683A6B40 for ; Thu, 16 Oct 2008 02:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFNvBj+CaDfi for ; Thu, 16 Oct 2008 02:43:35 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by core3.amsl.com (Postfix) with ESMTP id A3EF13A6AA9 for ; Thu, 16 Oct 2008 02:43:35 -0700 (PDT) Received: from [221.222.171.188] (helo=xuke-x61) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63) (envelope-from ) id 1KqPOr-0005ir-5y for ipsec@ietf.org; Thu, 16 Oct 2008 17:44:09 +0800 Date: Thu, 16 Oct 2008 17:44:11 +0800 From: "xuke" To: "ipsec" Message-ID: <200810161744113434215@mail.tsinghua.edu.cn> Organization: Institute of Computer Network and Technology, Tsinghua University X-mailer: Foxmail 6, 11, 101, 15 [cn] Mime-Version: 1.0 Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xuke@mail.tsinghua.edu.cn List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, all Basically, I agree with Yoav that the "ticket" concept is very similar to the "stub" concept. We did once thought to store the stub in the corresponding client separately. And, in our draft, we also analyzed this case. However, In the case of stub co-located with IPsec Client, the stub MUST be perfectly protected to prevent the malicious attackers from cracking the stub, if they can obtain the stub on the link. Actually, from previous experiences, even if the stub is strongly encrypted, there still has the risk. With the development of harware in accord with the Moore's Law, the capability of computing equipment will be increased step by step. Sometime, somehow, the brutal force decryption of the stub/ticket encryption method may be possible. And, there is also posibility that the currently safe encryption algorithm may be proved to be mathematically solvable. So, in our draft, it is only optional to transport the stub on the untrusted network, even if it can be protected strongly. And, If we see it from the client point of view, the client does not need to maintain a data structure to store the stubs. Lastly, in the mobile network, the transfer of stubs over the air at client side surely have much more service cost than doing it over the fiber in network side. All in all, to keep the client to be simpler, easier for upgrade in the future and keep the stub safer, personally, I'd rather to keep the stub in the network side. xuke Tsinghua University > > > We now have revised drafts from the two parties who has published earlier drafts on session resumption. The (truncated) announcements are below. > > The WG should start discussing what we want from session resumption and which of these two drafts (or what ideas from each of these two drafts) is of interest to the WG. As a reminder, I start off with what our charter says. > > Extra points are awarded for not copying this entire message in your response. :-) > > --Paul Hoffman > _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 16 03:14:04 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AFCD3A6B39; Thu, 16 Oct 2008 03:14:04 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B0C3A6B40 for ; Thu, 16 Oct 2008 03:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.405 X-Spam-Level: X-Spam-Status: No, score=-6.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izn4IhU+tHiq for ; Thu, 16 Oct 2008 03:14:01 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A908A3A6AC0 for ; Thu, 16 Oct 2008 03:14:01 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9GADfuv029818; Thu, 16 Oct 2008 05:14:44 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Oct 2008 13:14:08 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Oct 2008 13:14:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Oct 2008 13:13:54 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201EEFF7D@vaebe104.NOE.Nokia.com> In-Reply-To: <18676.37638.443520.835980@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA Thread-Index: Ackt+jXw7AAVv7d3TKKUcL/jb+3dtQBe5aDA References: <18648.62020.138458.908262@fireball.kivinen.iki.fi><18650.7814.808443.474300@fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB7201E72AFB@vaebe104.NOE.Nokia.com> <18676.37638.443520.835980@fireball.kivinen.iki.fi> From: To: X-OriginalArrivalTime: 16 Oct 2008 10:14:03.0830 (UTC) FILETIME=[EA7ACD60:01C92F77] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > > Note that RFC 4306 specifies that the IV length is equal to the > > block length of the underlying encryption algorithm. This doesn't > > work for CTR mode, so there's no way RFC 4306 and use of CTR mode > > in IKEv2 are compatible. > > AES (the underlying encryption algorithm) has block size of 128 bits, > and IV length to be used with CTR mode is defined in the section 3.1 > in the RFC3686. I do not see any way anybody could use any other IV > length than the one defined in the RFC3686 which also matches the > "block length of the underlying encryption algorithm". No, it does *not* match -- the block size is 128 bits (16 octets), while the IV length in Section 3.1 of RFC 3686 is 8 octets. > I do not really see any reason why this does not work with CTR mode > too, especially as it is using "underlying encryption algorithm" > instead of refering the block size requiremetns of the selected mode > and algorithm to be used. > > > (We could, of course, change this text in IKEv2bis...) > > As there is no newer RFCs or drafts to specify how to use counter mode > algorithms, and I do not really consider the text in RFC4306 to forbid > CTR mode ciphers, and RFC3686 do fill up the gaps in the RFC4306 by > specifying the IV length and the IV generation rules. The problem is that RFC 4306 also specifies the IV length and IV generation rules -- and those don't match RFC 3686. > We should most likely change the IKEv2bis text from: > ---------------------------------------------------------------------- > o Initialization Vector - Optional block of bits that is required > to allow encrption algorithm to produce a unique stream > independent from other streams produced by same key. The length > and generation depends on the encryption algorithm and mode it > is used in. For CBC modes the initialization vector is a > randomly chosen value whose length is equal to the block length > of the underlying encryption algorithm. Recipients MUST accept > any value. Senders SHOULD either pick this value > pseudo-randomly and independently for each message or use the > final ciphertext block of the previous message sent. Senders > MUST NOT use the same value for each message, use a sequence of > values with low hamming distance (e.g., a sequence > number), or use > ciphertext from a received message. For other modes the IV > format and processing is specified in the document specifying > the encryption algorithm and mode. > ---------------------------------------------------------------------- > I.e. change add some generic text to really tell what IV is (I copied > that mostly from wikipedia), and then tell that the rest of the text > is for CBC mode, and other modes do tell how the IV is used in the > corresponding documents. The RFC3686 do tell IV length and how it is > generated. BTW, note that ikev2bis has updated this text (in particular, the text about using the final ciphertext block of the previous is just wrong, shown to be insecure in practise, and explicitly forbidden in the NIST spec of CBC mode). If we want to add support for CTR mode in this document (which isn't all that clear -- if someone really needs this, it could be a separate document like RFC 5282), we could prephrase this, of course... > Hmm.. found another problem in the RFC4306. The ENCR_AES_CTR has wrong > reference. It is refering to the RFC3664 (The AES-XCBC-PRF-128 > Algorithm for the Internet Key Exchange Protocol (IKE)), instead of > the RFC3686 (Using Advanced Encryption Standard (AES) Counter Mode > With IPsec Encapsulating Security Payload (ESP)). Already fixed in ikev2bis almost a year ago :-) Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 16 03:16:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E033A6A60; Thu, 16 Oct 2008 03:16:23 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD5E3A68C0 for ; Thu, 16 Oct 2008 03:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRu8mkOV3eDi for ; Thu, 16 Oct 2008 03:16:22 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 979283A6AA2 for ; Thu, 16 Oct 2008 03:16:21 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9GAGgRa013359; Thu, 16 Oct 2008 13:16:56 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Oct 2008 13:16:55 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Oct 2008 13:16:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 16 Oct 2008 13:16:54 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201EEFF87@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Issue #32 Demoted SHOULD: EAP Identity Request Thread-Index: AckuJ0kr9hN2kPKxRReCGudYI7FsOABUK5uQ References: <18648.62996.136882.689426@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201E72B2A@vaebe104.NOE.Nokia.com> From: To: X-OriginalArrivalTime: 16 Oct 2008 10:16:54.0564 (UTC) FILETIME=[503EBE40:01C92F78] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #32 Demoted SHOULD: EAP Identity Request X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dan Harkins wrote: > What AAA attribute is supposed to be used by the AAA server to > communicate this information back to the IKEv2 responder? > > And it's a little more complicated too. Not only is the EAP server > often implemented in a separate AAA server, in some EAP methods that > server won't even me the one doing the actual client authentication! > In a tunneled EAP method like PEAP or TTLS the "inner method" may be > done by yet another AAA server. Currently, there's no RFC or Internet-Draft that describes AAA attributes for IKEv2 at all -- but e.g. RFC 4072, Section 2.8.1, talks about using the User-Name AVP for similar purpose. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 16 07:36:44 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35C7F3A6922; Thu, 16 Oct 2008 07:36:44 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 328453A67E6 for ; Thu, 16 Oct 2008 07:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmYxbQ+C-8EO for ; Thu, 16 Oct 2008 07:36:42 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 392E83A698E for ; Thu, 16 Oct 2008 07:36:33 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m9GEbVep012189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Oct 2008 17:37:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m9GEbTPL010072; Thu, 16 Oct 2008 17:37:29 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18679.20905.763167.3524@fireball.kivinen.iki.fi> Date: Thu, 16 Oct 2008 17:37:29 +0300 From: Tero Kivinen To: In-Reply-To: <1696498986EFEC4D9153717DA325CB7201EEFF7D@vaebe104.NOE.Nokia.com> References: <18648.62020.138458.908262@fireball.kivinen.iki.fi> <18650.7814.808443.474300@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201E72AFB@vaebe104.NOE.Nokia.com> <18676.37638.443520.835980@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201EEFF7D@vaebe104.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 17 min X-Total-Time: 18 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > Tero Kivinen wrote: > > > > Note that RFC 4306 specifies that the IV length is equal to the > > > block length of the underlying encryption algorithm. This doesn't > > > work for CTR mode, so there's no way RFC 4306 and use of CTR mode > > > in IKEv2 are compatible. > > > > AES (the underlying encryption algorithm) has block size of 128 bits, > > and IV length to be used with CTR mode is defined in the section 3.1 > > in the RFC3686. I do not see any way anybody could use any other IV > > length than the one defined in the RFC3686 which also matches the > > "block length of the underlying encryption algorithm". > > No, it does *not* match -- the block size is 128 bits (16 octets), > while the IV length in Section 3.1 of RFC 3686 is 8 octets. True. But this is exactly same situation we have with AES-GCM (IV = 8 bytes, block size is 16 bytes). Does that mean that we cannot use AES-GCM regardless that we have rfc5282 as RFC 4306 mandates the IV to be same as block length? I myself think that if the algorithm specific RFC (RFC 5282 for AES-GCM and RFC 3686 for AES-CTR) specifies some other IV processing rules those are used even when the RFC 4306 says that the iv length is equal the block length of the underlying encryption algorithm. > The problem is that RFC 4306 also specifies the IV length and IV > generation rules -- and those don't match RFC 3686. Thats why I think we need to change those rules to apply only to CBC modes defined in the RFC4306 (or the bis) and for other algorithms you use the rules specified in those documents. > BTW, note that ikev2bis has updated this text (in particular, the text > about using the final ciphertext block of the previous is just wrong, > shown to be insecure in practise, and explicitly forbidden in the NIST > spec of CBC mode). So I can see it has, but it still has the text which forbids using any other mode than where the IV length is same as block length. This removes AES-GCM, AES-CCM and AES-CTR for example. I think we should remove the text saying the IV length is same as block length, and refer to the algorithm sepecific IV length specifications and use that text for only CBC modes. > If we want to add support for CTR mode in this document (which isn't > all that clear -- if someone really needs this, it could be a separate > document like RFC 5282), we could prephrase this, of course... We do have that already. It is the RFC 3686. It is specifically writen so it can be used with both IKEv1 and IKEv2 (i.e. using the KEYMAT term to match both IKEv1 and IKEv2 specifications), and it does specify the IV length and other things needed. Note, that RFC 5282 does have about same text as RFC 3686. I do not really see any real difference there. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 16 15:59:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F09E3A6944; Thu, 16 Oct 2008 15:59:17 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487463A68FB for ; Thu, 16 Oct 2008 15:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzG8ZjnIJqLS for ; Thu, 16 Oct 2008 15:59:15 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 846203A67B0 for ; Thu, 16 Oct 2008 15:59:15 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 957A9102241D0; Thu, 16 Oct 2008 16:00:17 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 16 Oct 2008 16:00:17 -0700 (PDT) Message-ID: In-Reply-To: <200810161744113434215@mail.tsinghua.edu.cn> References: <200810161744113434215@mail.tsinghua.edu.cn> Date: Thu, 16 Oct 2008 16:00:17 -0700 (PDT) From: "Dan Harkins" To: xuke@mail.tsinghua.edu.cn User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: ipsec Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hello, I'm not sure what "perfectly protected" means but if one uses a key-wrapping technique with provable security (like RFC 5297-- AES-SIV, which is in AUTH48 state and should be published very shortly) then an attack against the ticket should be no more possible than an attack against the IPsec traffic itself. These tickets must use deterministic authenticated encryption and provided the thing that's being wrapped in the ticket is a cryptographic key, like SK_d, the randomness it adds will allow the ticket protection scheme to achieve semantic security. Dan. On Thu, October 16, 2008 2:44 am, xuke wrote: > Hi, all > > Basically, I agree with Yoav that the "ticket" concept is very similar > to the "stub" concept. > We did once thought to store the stub in the corresponding client > separately. And, in our draft, we also analyzed this case. > However, In the case of stub co-located with IPsec Client, the stub > MUST be perfectly protected to prevent the malicious attackers from > cracking the stub, if they can obtain the stub on the link. Actually, > from previous experiences, even if the stub is strongly encrypted, > there still has the risk. With the development of harware in accord > with the Moore's Law, the capability of computing equipment will be > increased step by step. Sometime, somehow, the brutal force decryption > of the stub/ticket encryption method may be possible. And, there is > also posibility that the currently safe encryption algorithm may be > proved to be mathematically solvable. So, in our draft, it is only > optional to transport the stub on the untrusted network, even if it > can be protected strongly. > > And, If we see it from the client point of view, the client does not > need to maintain a data structure to store the stubs. > Lastly, in the mobile network, the transfer of stubs over the air at > client side surely have much more service cost than doing it over the > fiber in network side. > > All in all, to keep the client to be simpler, easier for upgrade in > the future and keep the stub safer, personally, I'd rather to keep the > stub in the network side. > > xuke > Tsinghua University > >> >> >> We now have revised drafts from the two parties who has published >> earlier drafts on session resumption. The (truncated) announcements are >> below. >> >> The WG should start discussing what we want from session resumption and >> which of these two drafts (or what ideas from each of these two drafts) >> is of interest to the WG. As a reminder, I start off with what our >> charter says. >> >> Extra points are awarded for not copying this entire message in your >> response. :-) >> >> --Paul Hoffman >> > _______________________________________________ > IPsec mailing list > IPsec at ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 17 17:48:27 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6253A67F8; Fri, 17 Oct 2008 17:48:27 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFA4E3A6B09 for ; Fri, 17 Oct 2008 17:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2DW1yciXFBo for ; Fri, 17 Oct 2008 17:35:30 -0700 (PDT) Received: from smtp1gap.foundrynet.com (smtp1gap.foundrynet.com [76.199.70.29]) by core3.amsl.com (Postfix) with ESMTP id ACB7A3A6A5F for ; Fri, 17 Oct 2008 17:35:30 -0700 (PDT) Received: from xmail.ds.foundrynet.com (unknown [10.101.218.254]) by smtp1gap.foundrynet.com (Postfix) with ESMTP id 453843E0002 for ; Fri, 17 Oct 2008 17:36:13 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 17 Oct 2008 17:35:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Reauthentication extension for IKEv2 Thread-Index: AckwuW47rg9jzjP+Tkm36/sDCB07lw== From: "Gary Hemminger" To: Subject: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1469186668==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1469186668== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C930B9.6EA7B0F6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C930B9.6EA7B0F6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable One comment on the heuristics approach. As a hardware vendor of L4-7 ADC boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended. What I mean is that the heuristic may be easy to define now, but there is no certainty that it would remain this way. My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway. =20 While I like the idea of some "other" box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the "other" box, I think we should think about the long term, not the short term. Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit.=20 =20 Gary =20 [IPsec] Reauthentication extension for IKEv2 ________________________________ * To: Martin Willi > * Subject: [IPsec] Reauthentication extension for IKEv2 * From: Tero Kivinen > * Date: Tue, 16 Sep 2008 12:09:14 +0300 * Cc: ipsec at ietf.org =20 * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com =20 * Delivered-to: ipsec at core3.amsl.com =20 * In-reply-to: <48CF5D7D.7070701 at strongswan.org > * List-archive: * List-help: * List-id: Discussion of IPsec protocols * List-post: * List-subscribe: , * List-unsubscribe: , * References: <48CF5D7D.7070701 at strongswan.org > * Sender: ipsec-bounces at ietf.org =20 ________________________________ Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... =20 The first question I have is why are you doing reauthentication at all? =20 What is the benefits of the reauthentication? =20 What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? =20 I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. =20 The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." =20 In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. =20 This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." =20 Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have.=20 --=20 kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 ________________________________ * Follow-Ups:=20 * Re: [IPsec] Reauthentication extension for IKEv2 =20 * From: Martin Willi * References:=20 * [IPsec] Reauthentication extension for IKEv2 =20 * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 =20 * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 =20 * Previous by thread: [IPsec] Reauthentication extension for IKEv2 =20 * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 =20 * Index(es):=20 * Date * Thread =20 Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IE =20 ------_=_NextPart_001_01C930B9.6EA7B0F6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

One comment on = the heuristics approach.  As a hardware vendor of L4-7 ADC boxes, I am a little = concerned about having to terminate IPSEC streams based on the heuristics = approach, because this is open ended.  What I mean is that the heuristic may = be easy to define now, but there is no certainty that it would remain this = way.  My past experience suggests that eventually the heuristic would become = too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway.  =  

While I like the = idea of some “other” box having to solve this issue, which prevents = clients from having to be changed, as we are a vendor of the “other” = box, I think we should think about the long term, not the short term.  = Just my opinion, and I am certainly flexible, but the heuristics approach = worries me a bit.

 

Gary

=

 

[IPsec] Reauthentication extension for IKEv2

Martin Willi writes:
> What do you think =
about such an extension? Already considered =
something
> similar, or does your =
reauthentication procedure work hassle-free? =
I'm
> wondering if we are the only ones facing =
these problems or if such an
> extension would =
gain broader =
acceptance...
 
The first =
question I have is why are you doing reauthentication =
at
all?
 
= 
What is the benefits of the =
reauthentication?
 
What =
is the benefits of the reauthentication that can be done =
WITHOUT
user intervention (i.e. no user typing in =
password or pin code or
fingerprint or =
similar)?
 
I myself can =
only really see benefits from reauthentication when =
it
does require that user is really sitting there =
on the machine, and
gives something that the =
machine itself cannot give. In those cases
the user =
is required to type in something or do something =
anyways,
thus it does not really matter if the =
communications is interrupted
for second if user =
must stop his work for much longer time to type =
in
his passphrase or pin =
code.
 
The RFC 4478 =
simply skips this question and says "With some =
IPsec
peers, particularly in the remote access =
scenario, it is desirable to
repeat the mutual =
authentication periodically. The purpose of this =
is
to limit the time that security associations =
(SAs) can be used by a
third party who has gained =
control of the IPsec =
peer."
 
In most =
cases if third party has gained control of the IPsec peer =
he
will also get control of all authentication =
information inside the
peer, including private keys =
and pre shared keys. Only way to make
sure that he =
does not get access to those is to protect them =
with
passphrase, or pin code or similar that is =
only known by the =
user.
 
This is also said =
out in the RFC 4478: "However, in the remote =
access
scenario it is usually up to a human user to =
supply the
authentication credentials =
..."
 
Because of =
this I do not think there is that much requirement =
for
reauthentication protocol that is faster than =
what we already have. 
-- =

kivinen at =
safenet-inc.com
____________________________________=
___________
IPsec mailing =
list
IPsec at ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
 
<= pre> 

Note: Messages sent to this list are the opinions of the senders and = do not imply endorsement by the IE

 

------_=_NextPart_001_01C930B9.6EA7B0F6-- --===============1469186668== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1469186668==-- From ipsec-bounces@ietf.org Sat Oct 18 14:02:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9787B3A6960; Sat, 18 Oct 2008 14:02:23 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6EA23A6931 for ; Sat, 18 Oct 2008 14:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8rKG93NpANT for ; Sat, 18 Oct 2008 14:02:20 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 85F223A6960 for ; Sat, 18 Oct 2008 14:02:19 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 54696294005; Sat, 18 Oct 2008 23:03:22 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5A14E294003; Sat, 18 Oct 2008 23:03:20 +0200 (IST) Received: from [172.31.21.40] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9IL3Ike025517; Sat, 18 Oct 2008 23:03:18 +0200 (IST) Message-Id: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com> From: Yoav Nir To: Gary Hemminger In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 18 Oct 2008 23:03:17 +0200 References: X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0810549026==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0810549026== Content-Type: multipart/alternative; boundary=Apple-Mail-1--904021815 --Apple-Mail-1--904021815 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Gary. I'm not sure what heuristics you are talking about. The problem of re-=20= authentication is simply this. The owner of the remote access gateway =20= has a security policy that says that connections can be open for only =20= so long (say, 2 hours) without authenticating the user again. This is =20= a favorite requirement by auditors, who believe that this is an =20 important part of risk management. If somebody steals your laptop (or =20= mobile phone) or sits down at the Internet Cafe station where you were =20= logged on, we want to limit the amount of time they are connected to =20 the internal network. This requirement makes sense if the user has to =20= type in their password to authenticate. It makes less sense if there =20 are user certificates that are stored on the computer, or if the =20 client software has a "save password" feature. Whether it makes sense or not, this is a requirement by auditors and =20 regulators. If the user does not re-authenticate within the specified =20= time, the IKE SA and all dependent child SAs are deleted. This =20 creates a usability problem, because the SA is deleted without any =20 advance warning to the user, so the user is likely to get a relatively =20= long time with no connectivity. This can break TCP connections such as =20= FTP, HTTP, and IMAP. Outlook tends to make accounts permanently =20 offline when this happens. RFC 4778 and the improvement that Martin Willi is proposing, are aimed =20= at solving this usability problem by informing the client software in =20= advance when the re-authentication needs to be done, and allowing them =20= to re-authenticate early enough, so that connections are not broken. =20 The heuristic does not affect the security or the IPsec streams. Yoav On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: > One comment on the heuristics approach. As a hardware vendor of =20 > L4-7 ADC boxes, I am a little concerned about having to terminate =20 > IPSEC streams based on the heuristics approach, because this is open =20= > ended. What I mean is that the heuristic may be easy to define now, =20= > but there is no certainty that it would remain this way. My past =20 > experience suggests that eventually the heuristic would become too =20 > complex, and a well defined mechanism for determining which payload =20= > is encrypted would need to be employed anyway. > > While I like the idea of some =93other=94 box having to solve this =20 > issue, which prevents clients from having to be changed, as we are a =20= > vendor of the =93other=94 box, I think we should think about the long =20= > term, not the short term. Just my opinion, and I am certainly =20 > flexible, but the heuristics approach worries me a bit. > > > > Gary > > > > [IPsec] Reauthentication extension for IKEv2 > > To: Martin Willi > Subject: [IPsec] Reauthentication extension for IKEv2 > From: Tero Kivinen > Date: Tue, 16 Sep 2008 12:09:14 +0300 > Cc: ipsec at ietf.org > Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com > Delivered-to: ipsec at core3.amsl.com > In-reply-to: <48CF5D7D.7070701 at strongswan.org> > List-archive: > List-help: > List-id: Discussion of IPsec protocols > List-post: > List-subscribe: , = > > List-unsubscribe: , = > > References: <48CF5D7D.7070701 at strongswan.org> > Sender: ipsec-bounces at ietf.org > Martin Willi writes: > > What do you think about such an extension? Already considered =20 > something > > similar, or does your reauthentication procedure work hassle-free? =20= > I'm > > wondering if we are the only ones facing these problems or if such =20= > an > > extension would gain broader acceptance... > > The first question I have is why are you doing reauthentication at > all? > > What is the benefits of the reauthentication? > > What is the benefits of the reauthentication that can be done WITHOUT > user intervention (i.e. no user typing in password or pin code or > fingerprint or similar)? > > I myself can only really see benefits from reauthentication when it > does require that user is really sitting there on the machine, and > gives something that the machine itself cannot give. In those cases > the user is required to type in something or do something anyways, > thus it does not really matter if the communications is interrupted > for second if user must stop his work for much longer time to type in > his passphrase or pin code. > > The RFC 4478 simply skips this question and says "With some IPsec > peers, particularly in the remote access scenario, it is desirable to > repeat the mutual authentication periodically. The purpose of this is > to limit the time that security associations (SAs) can be used by a > third party who has gained control of the IPsec peer." > > In most cases if third party has gained control of the IPsec peer he > will also get control of all authentication information inside the > peer, including private keys and pre shared keys. Only way to make > sure that he does not get access to those is to protect them with > passphrase, or pin code or similar that is only known by the user. > > This is also said out in the RFC 4478: "However, in the remote access > scenario it is usually up to a human user to supply the > authentication credentials ..." > > Because of this I do not think there is that much requirement for > reauthentication protocol that is faster than what we already have. > --=20 > kivinen at safenet-inc.com > _______________________________________________ > IPsec mailing list > IPsec at ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > Follow-Ups: > Re: [IPsec] Reauthentication extension for IKEv2 > From: Martin Willi > References: > [IPsec] Reauthentication extension for IKEv2 > From: Martin Willi > Prev by Date: [IPsec] Reauthentication extension for IKEv2 > Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 > Previous by thread: [IPsec] Reauthentication extension for IKEv2 > Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 > Index(es): > Date > Thread > Note: Messages sent to this list are the opinions of the senders and =20= > do not imply endorsement by the IE > > > > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-1--904021815 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Gary.

I'm = not sure what heuristics you are talking about. The problem of = re-authentication is simply this. The owner of the remote access gateway = has a security policy that says that connections can be open for only so = long (say, 2 hours) without authenticating the user again. This is a = favorite requirement by auditors, who believe that this is an important = part of risk management. If somebody steals your laptop (or mobile = phone) or sits down at the Internet Cafe station where you were logged = on, we want to limit the amount of time they are connected to the = internal network. This requirement makes sense if the user has to type = in their password to authenticate. It makes less sense if there are user = certificates that are stored on the computer, or if the client software = has a "save password" feature.

Whether it makes = sense or not, this is a requirement by auditors and regulators. If the = user does not re-authenticate within the specified time, the IKE SA and = all dependent child SAs are deleted.  This creates a = usability problem, because the SA is deleted without any advance warning = to the user, so the user is likely to get a relatively long time with no = connectivity. This can break TCP connections such as FTP, HTTP, and = IMAP. Outlook tends to make accounts permanently offline when this = happens.

RFC 4778 and the improvement that = Martin Willi is proposing, are aimed at solving this usability problem = by informing the client software in advance when the re-authentication = needs to be done, and allowing them to re-authenticate early enough, so = that connections are not broken. The heuristic does not affect the = security or the IPsec = streams.

Yoav

= On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote:

One = comment on the heuristics approach.  As a hardware vendor of L4-7 = ADC boxes, I am a little concerned about having to terminate IPSEC = streams based on the heuristics approach, because this is open = ended.  What I mean is that the heuristic may be easy to define = now, but there is no certainty that it would remain this way.  My = past experience suggests that eventually the heuristic would become too = complex, and a well defined mechanism for determining which payload is = encrypted would need to be employed anyway.  =  

While I = like the idea of some =93other=94 box having to solve this issue, which = prevents clients from having to be changed, as we are a vendor of the = =93other=94 box, I think we should think about the long term, not the = short term.  Just my opinion, and I am certainly flexible, but the = heuristics approach worries me a bit.

 

Gary

 

[IPsec] Reauthentication = extension for IKEv2

Martin Willi writes:
> similar, or does your reauthentication =
procedure work hassle-free? I'm
> wondering if we are the =
only ones facing these problems or if such an
The first question I have is why are you =
doing reauthentication at
all?
What is the benefits of the =
reauthentication?
 
user intervention (i.e. no user typing in =
password or pin code or
fingerprint or =
similar)?
 
does require that user is really sitting there on the =
machine, and
gives something that the machine =
itself cannot give. In those cases
thus it does not really matter if the =
communications is interrupted
for second if user must =
stop his work for much longer time to type in
The RFC 4478 simply skips this question =
and says "With some IPsec
peers, particularly in the remote =
access scenario, it is desirable to
to limit the time that security associations (SAs) can =
be used by a
third party who has gained control =
of the IPsec peer."
 
will also get control of all authentication information =
inside the
peer, including private keys and pre =
shared keys. Only way to make
sure that he does not get =
access to those is to protect them with
 
This is also said out in the RFC =
4478: "However, in the remote access
authentication credentials ..."
Because of this I do not think there is =
that much requirement for
reauthentication protocol that is =
faster than what we already have. 
kivinen at safenet-inc.com
IPsec at =
ietf.org
 


Scanned by = Check Point Total Security Gateway. 

_____________________= __________________________
IPsec mailing list
IPsec@ietf.org
X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0583A6ACA; Mon, 20 Oct 2008 10:35:20 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 782983A6A99 for ; Mon, 20 Oct 2008 10:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWAmpsVc8ghd for ; Mon, 20 Oct 2008 10:35:18 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B16D23A69F5 for ; Mon, 20 Oct 2008 10:35:17 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E1EBB294005; Mon, 20 Oct 2008 19:35:52 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 61C00294003; Mon, 20 Oct 2008 19:35:10 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9KHZ9ke021892; Mon, 20 Oct 2008 19:35:09 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 20 Oct 2008 19:35:09 +0200 From: Yaron Sheffer To: Yoav Nir , =?utf-8?B?6IOh5rOK?= Date: Mon, 20 Oct 2008 19:35:13 +0200 Thread-Topic: [IPsec] Resuming the session resumption discussion Thread-Index: AckuRndVst0T37PZTmaeHMpu0S9RuwEkx8tw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7D9@il-ex01.ad.checkpoint.com> References: <36f1fcac18324f585784a155344d8959@mail.ritt.com.cn> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "paul.hoffman@vpnc.org" Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0702633734==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0702633734== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0135_01C932EA.F90D3C20" ------=_NextPart_000_0135_01C932EA.F90D3C20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable [Spoken as a coauthor of draft-tschofenig:] Draft-tschofenig does have a facility to mitigate this issue, by = ensuring that the ticket is the only thing that goes into the IKE = message. Quoting from the draft: o [The gateway] returns an N(TICKET_ACK), if it cannot grant a ticket immediately, e.g., due to packet size limitations. In this case the client MAY request a ticket later using an Informational exchange, at any time during the lifetime of the IKE SA. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Yoav Nir Sent: Tuesday, October 14, 2008 23:47 To: =E8=83=A1=E6=B3=8A Cc: ipsec@ietf.org; paul.hoffman@vpnc.org Subject: Re: [IPsec] Resuming the session resumption discussion On Oct 14, 2008, at 6:35 PM, =E8=83=A1=E6=B3=8A wrote: > Hi, Yoav and all: > > This discussion is becoming more and more interesting. Please check my > reply below: > >>> The ticket shares the packet with traffic selectors, configuration >>> payload, authentication, certificates and other payloads. That >>> packet can be quite large, which leads to fragmentation and >>> potentially >>> packet loss. > > In this sense, the message to deliver ticket could suffer from the IP > fragmentation. Well, when we see the RFC4306 = (IKEv2=C2=A3=C2=A9=C2=A3=C2=ACthe > following > lines can be found: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Although IKEv2 messages are intended to be short, they contain > structures with no hard upper bound on size (in particular, X.509 > certificates), and IKEv2 itself does not have a mechanism for > fragmenting large messages. IP defines a mechanism for fragmentation > of oversize UDP messages, but implementations vary in the maximum > message size supported. Furthermore, use of IP fragmentation opens > an implementation to denial of service attacks [KPS03]. Finally, > some NAT and/or firewall implementations may block IP fragments. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Obviously, base IKEv2 protocol recommends short messages. In the > ticket solution, except for the ticket presentation, the GW surely > need to push the tickets to clients by IKEv2 messages beforehand. Will > the fragmented packet for ticket delivery compromise the principle of > IKEv2 base protocol? > > Does anybody in this list can clarify How much negative effect of > message fragmentation is on IKEv2 operation? > > Thanks > > -Po IKEv2 recommends short messages, but then goes on to include in the last IKE_AUTH packet the traffic selectors (which may include the entire protected networks), the configuration payload (which may also include the entire protected networks, but in a different format, certificates (which have no upper bound on size) and potentially even CRLs. So that packet is already in danger of being too large, and adding a chunky payload like the ticket increases the likelihood of fragmentation. As for the negative effects, there is obviously the problem of packet loss. In a high packet loss environment (wireless devices come to mind) if, say, 30% of packets get lost, 50% of 2-fragment packets will be lost, and 65% of 3-fragment packets. Also, as the IKEv2 document says, some operating systems will have a limit on assembly, as will some firewalls that reassemble fragments to inspect the packet in full. In the early 2000's a lot of wireless access points, home routers, DSL modems and such were broken - they dropped all fragments, so any packet larger than the MTU was doomed to be dropped. Things were so bad, that my company had to invent a proprietary IKE-over-TCP just to get client connections working. This has vastly improved. Today most such equipment is working well, and fragments are passed through correctly. Operating systems in use today are also in better shape, and I can't think of any current version that won't handle UDP packets as large as the standards allow. Packet loss is still an issue, but for regular wired and wireless access, even most cellular, packet loss is reasonably low. I admit that my experience may not be representative of all the world, but IMO some fragmentation is not as big a problem as it used to be. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0135_01C932EA.F90D3C20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyMDE3MzUxM1owIwYJKoZIhvcNAQkEMRYEFEvzX7lEaFcY qyN0zPCbBzdvfrHJMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA JtU/LiH4ROlf34I2eOKMewIEfZJqmqc/rH7UKHnRjh4NFWfbwUg+iRfClBFOiwhcjL+BRfgz9SwB JnlANrp9HyOtb0eu14d9hzPL5qteqKIbSP5Yz7fzgnu2E2Cg2boEfTXyyPQxDrVztR8vMURJICgr JVjuJPL06qhuq9xXSHCeWNw3Rt+dUJDgCBe5Hrk5yCuZ6Mucjvja1G0WuOOuyz3KwgrC4IXKvOtW 514MO0INn8CoakU/RDtyIr2BdDubzCbEzOPRRw3oH8El0+/5YWzz+y0a4OLonhJALx+dfV4OXTgx /APYBIJgCqADmmVggEE+tid7Z3aTUVnXRC/JfQAAAAAAAA== ------=_NextPart_000_0135_01C932EA.F90D3C20-- --===============0702633734== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0702633734==-- From ipsec-bounces@ietf.org Mon Oct 20 10:44:56 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2C503A69F5; Mon, 20 Oct 2008 10:44:56 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C121C3A69F5 for ; Mon, 20 Oct 2008 10:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdWB9G68vGOL for ; Mon, 20 Oct 2008 10:44:54 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 333413A6887 for ; Mon, 20 Oct 2008 10:44:54 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B2A93294005; Mon, 20 Oct 2008 19:45:42 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 39988294003; Mon, 20 Oct 2008 19:44:59 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9KHiwke024862; Mon, 20 Oct 2008 19:44:58 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 20 Oct 2008 19:44:58 +0200 From: Yaron Sheffer To: "xuke@mail.tsinghua.edu.cn" , ipsec Date: Mon, 20 Oct 2008 19:45:04 +0200 Thread-Topic: [IPsec] Resuming the session resumption discussion Thread-Index: Ackvc9LjWse6Gd/6QDOW5p4MwPwWBQDZnhrQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7DA@il-ex01.ad.checkpoint.com> References: <200810161744113434215@mail.tsinghua.edu.cn> In-Reply-To: <200810161744113434215@mail.tsinghua.edu.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0015003115==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0015003115== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0139_01C932EC.59096B70" ------=_NextPart_000_0139_01C932EC.59096B70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Seen from a protocol point of view, it is critically important that the ticket (or stub) is secured. But the contents of the ticket is much less critical, since it is opaque to the client anyway. Draft-tschofenig mentions that the ticket can contain the actual IKE (subset-) state, or it can contain a reference (pointer) to such state, which is presumably stored on the gateway or near it. Quoting: Ticket reference: A pointer to a ticket. When resolving the reference it obtains the ticket. In subsequent sections we use the term ticket and thereby refer to both the ticket per value and by reference, unless indicated otherwise. (And yes, we could do a better job of mentioning this concept in Sec. 5, where we describe the ticket in detail.) Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of xuke Sent: Thursday, October 16, 2008 11:44 To: ipsec Subject: Re: [IPsec] Resuming the session resumption discussion Hi, all Basically, I agree with Yoav that the "ticket" concept is very similar to the "stub" concept. We did once thought to store the stub in the corresponding client separately. And, in our draft, we also analyzed this case. However, In the case of stub co-located with IPsec Client, the stub MUST be perfectly protected to prevent the malicious attackers from cracking the stub, if they can obtain the stub on the link. Actually, from previous experiences, even if the stub is strongly encrypted, there still has the risk. With the development of harware in accord with the Moore's Law, the capability of computing equipment will be increased step by step. Sometime, somehow, the brutal force decryption of the stub/ticket encryption method may be possible. And, there is also posibility that the currently safe encryption algorithm may be proved to be mathematically solvable. So, in our draft, it is only optional to transport the stub on the untrusted network, even if it can be protected strongly. And, If we see it from the client point of view, the client does not need to maintain a data structure to store the stubs. Lastly, in the mobile network, the transfer of stubs over the air at client side surely have much more service cost than doing it over the fiber in network side. All in all, to keep the client to be simpler, easier for upgrade in the future and keep the stub safer, personally, I'd rather to keep the stub in the network side. xuke Tsinghua University > > > We now have revised drafts from the two parties who has published earlier drafts on session resumption. The (truncated) announcements are below. > > The WG should start discussing what we want from session resumption and which of these two drafts (or what ideas from each of these two drafts) is of interest to the WG. As a reminder, I start off with what our charter says. > > Extra points are awarded for not copying this entire message in your response. :-) > > --Paul Hoffman > _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0139_01C932EC.59096B70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyMDE3NDUwNFowIwYJKoZIhvcNAQkEMRYEFPBeDiXend7l gjuMV1hRsqK4hBBIMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA cMiVgo72EC/gCyEza4cOoKv7nIBzvFYreFBGgUeU0nMTaGywYrc8X20VqejDif3zQ0xJ9bp/ZOWi U7x+QQ2+NM2TchdALCe7CNqiS5MyxTsW7oKRW54LknuS+G5jsEywGq2XGAKD0S5ERFlO71bKPSjz hy23VAMljRmzmdlEa9SD/9IEhd++ers3/Wn9eFpfFmx/e/6OWN/looOUFaZYlqCSkopbIb0OgHCq EAeAWsLufyWoRRxEoov17fm6LhDotrETLHchMlifRM10BOkQJ2GH2+5y0d0n99tWGbzI7ftUDcZp mFRVDxWNgCg3tv3xNUjc2TMN8QZNOBsNcejHSwAAAAAAAA== ------=_NextPart_000_0139_01C932EC.59096B70-- --===============0015003115== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0015003115==-- From ipsec-bounces@ietf.org Mon Oct 20 11:29:07 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDBD33A6AF9; Mon, 20 Oct 2008 11:29:07 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3693A6AF9 for ; Mon, 20 Oct 2008 11:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[AWL=-1.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFFU8kTdk92y for ; Mon, 20 Oct 2008 11:28:53 -0700 (PDT) Received: from smtp1gap.foundrynet.com (smtp1gap.foundrynet.com [76.199.70.29]) by core3.amsl.com (Postfix) with ESMTP id DA3D13A69F4 for ; Mon, 20 Oct 2008 11:28:52 -0700 (PDT) Received: from xmail.ds.foundrynet.com (unknown [10.101.218.254]) by smtp1gap.foundrynet.com (Postfix) with ESMTP id EA6333E0002; Mon, 20 Oct 2008 11:29:27 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 20 Oct 2008 11:26:02 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Reauthentication extension for IKEv2 Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkh References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com> From: "Gary Hemminger" To: "Yoav Nir" Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0544474398==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0544474398== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C932E1.BD5393B5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C932E1.BD5393B5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I was talking about how to make the determination that the payload is = encrypted. Evidently there are two approaches: one based on a = heuristic, another based on a payload wrapper that flags the payload is = encrypted. We would need some mechanism to determine the payload is = encryped if we need to terminate the IPSEC traffic and make a = determination of which server to send it to. Sorry about the confusion. =20 Gary ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sat 10/18/2008 2:03 PM To: Gary Hemminger Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 Hi Gary.=20 I'm not sure what heuristics you are talking about. The problem of = re-authentication is simply this. The owner of the remote access gateway = has a security policy that says that connections can be open for only so = long (say, 2 hours) without authenticating the user again. This is a = favorite requirement by auditors, who believe that this is an important = part of risk management. If somebody steals your laptop (or mobile = phone) or sits down at the Internet Cafe station where you were logged = on, we want to limit the amount of time they are connected to the = internal network. This requirement makes sense if the user has to type = in their password to authenticate. It makes less sense if there are user = certificates that are stored on the computer, or if the client software = has a "save password" feature. Whether it makes sense or not, this is a requirement by auditors and = regulators. If the user does not re-authenticate within the specified = time, the IKE SA and all dependent child SAs are deleted. This creates = a usability problem, because the SA is deleted without any advance = warning to the user, so the user is likely to get a relatively long time = with no connectivity. This can break TCP connections such as FTP, HTTP, = and IMAP. Outlook tends to make accounts permanently offline when this = happens. RFC 4778 and the improvement that Martin Willi is proposing, are aimed = at solving this usability problem by informing the client software in = advance when the re-authentication needs to be done, and allowing them = to re-authenticate early enough, so that connections are not broken. The = heuristic does not affect the security or the IPsec streams. Yoav On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: =09 One comment on the heuristics approach. As a hardware vendor of L4-7 = ADC boxes, I am a little concerned about having to terminate IPSEC = streams based on the heuristics approach, because this is open ended. = What I mean is that the heuristic may be easy to define now, but there = is no certainty that it would remain this way. My past experience = suggests that eventually the heuristic would become too complex, and a = well defined mechanism for determining which payload is encrypted would = need to be employed anyway. =20 While I like the idea of some "other" box having to solve this issue, = which prevents clients from having to be changed, as we are a vendor of = the "other" box, I think we should think about the long term, not the = short term. Just my opinion, and I am certainly flexible, but the = heuristics approach worries me a bit. =20 Gary =20 [IPsec] Reauthentication extension for IKEv2 ________________________________ =09 * To: Martin Willi >=20 * Subject: [IPsec] Reauthentication extension for IKEv2=20 * From: Tero Kivinen = >=20 * Date: Tue, 16 Sep 2008 12:09:14 +0300=20 * Cc: ipsec at ietf.org =20 * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com = =20 * Delivered-to: ipsec at core3.amsl.com =20 * In-reply-to: <48CF5D7D.7070701 at strongswan.org = >=20 * List-archive: =20 * List-help: =20 * List-id: Discussion of IPsec protocols =20 * List-post: =20 * List-subscribe: , = =20 * List-unsubscribe: , = =20 * References: <48CF5D7D.7070701 at strongswan.org = >=20 * Sender: ipsec-bounces at ietf.org = =20 ________________________________ Martin Willi writes: > What do you think about such an extension? Already considered = something > similar, or does your reauthentication procedure work hassle-free? = I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... =20 The first question I have is why are you doing reauthentication at all? =20 What is the benefits of the reauthentication? =20 What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? =20 I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. =20 The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." =20 In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. =20 This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." =20 Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have.=20 --=20 kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 ________________________________ =09 * Follow-Ups:=20 * Re: [IPsec] Reauthentication extension for IKEv2 = =20 * From: Martin Willi * References:=20 * [IPsec] Reauthentication extension for IKEv2 = =20 * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 = =20 * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 = =20 * Previous by thread: [IPsec] Reauthentication extension for IKEv2 = =20 * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 = =20 * Index(es):=20 * Date = = =20 * Thread = =20 Note: Messages sent to this list are the opinions of the senders and do = not imply endorsement by the IE =20 Scanned by Check Point Total Security Gateway.=20 =09 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =09 ------_=_NextPart_001_01C932E1.BD5393B5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
I was talking = about how to make the determination that the payload is encrypted.  = Evidently there are two approaches:  one based on a heuristic, = another based on a payload wrapper that flags the payload is = encrypted.  We would need some mechanism to determine the payload = is encryped if we need to terminate the IPSEC traffic and make a = determination of which server to send it to.  Sorry about the = confusion.
=0A=
 
=0A=
Gary
=0A=

=0A=
=0A= From: Yoav Nir = [mailto:ynir@checkpoint.com]
Sent: Sat 10/18/2008 2:03 = PM
To: Gary Hemminger
Cc: = ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension = for IKEv2

=0A=
Hi Gary. =0A=

=0A=
I'm not sure what heuristics you are talking about. The problem of = re-authentication is simply this. The owner of the remote access gateway = has a security policy that says that connections can be open for only so = long (say, 2 hours) without authenticating the user again. This is a = favorite requirement by auditors, who believe that this is an important = part of risk management. If somebody steals your laptop (or mobile = phone) or sits down at the Internet Cafe station where you were logged = on, we want to limit the amount of time they are connected to the = internal network. This requirement makes sense if the user has to type = in their password to authenticate. It makes less sense if there are user = certificates that are stored on the computer, or if the client software = has a "save password" feature.
=0A=

=0A=
Whether it makes sense or not, this is a requirement by auditors = and regulators. If the user does not re-authenticate within the = specified time, the IKE SA and all dependent child SAs are = deleted.  This creates a usability problem, because the SA is = deleted without any advance warning to the user, so the user is likely = to get a relatively long time with no connectivity. This can break TCP = connections such as FTP, HTTP, and IMAP. Outlook tends to make accounts = permanently offline when this happens.
=0A=

=0A=
RFC 4778 and the improvement that Martin Willi is proposing, are = aimed at solving this usability problem by informing the client software = in advance when the re-authentication needs to be done, and allowing = them to re-authenticate early enough, so that connections are not = broken. The heuristic does not affect the security or the IPsec = streams.
=0A=

=0A=
Yoav
=0A=

=0A=
=0A=
=0A=
On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote:

=0A=
=0A=
=0A=
=0A=

One comment on the heuristics approach.  = As a hardware vendor of L4-7 ADC boxes, I am a little concerned about = having to terminate IPSEC streams based on the heuristics approach, = because this is open ended.  What I mean is that the heuristic may = be easy to define now, but there is no certainty that it would remain = this way.  My past experience suggests that eventually the = heuristic would become too complex, and a well defined mechanism for = determining which payload is encrypted would need to be employed = anyway.   

=0A=

While I like the idea of some = “other” box having to solve this issue, which prevents = clients from having to be changed, as we are a vendor of the = “other” box, I think we should think about the long term, = not the short term.  Just my opinion, and I am certainly flexible, = but the heuristics approach worries me a bit.

=0A=

 

=0A=

Gary

=0A=

 

=0A=

[IPsec] Reauthentication = extension for IKEv2

=0A=
=0A=
=0A=
=0A= =0A=
=0A=
=0A= 
Martin Willi writes:
> What do you think =
about such an extension? Already considered something
> similar, or does your reauthentication procedure work =
hassle-free? I'm
> wondering if we are the only ones =
facing these problems or if such an
> extension would =
gain broader acceptance...
 
The first question I have is why are you doing reauthentication =
at
all?
 
What is the =
benefits of the reauthentication?
 
What is the benefits of the reauthentication that can be done =
WITHOUT
user intervention (i.e. no user typing in =
password or pin code or
fingerprint or similar)?
 
I myself can only really see benefits from =
reauthentication when it
does require that user is really =
sitting there on the machine, and
gives something that =
the machine itself cannot give. In those cases
the user is required to type in something or do something =
anyways,
thus it does not really matter if the =
communications is interrupted
for second if user must =
stop his work for much longer time to type in
his passphrase or pin code.
 
The RFC 4478 simply skips this question and says "With some =
IPsec
peers, particularly in the remote access =
scenario, it is desirable to
repeat the mutual =
authentication periodically. The purpose of this is
to limit the time that security associations (SAs) can be used by =
a
third party who has gained control of the IPsec =
peer."
 
In most cases if third =
party has gained control of the IPsec peer he
will also get control of all authentication information inside =
the
peer, including private keys and pre shared =
keys. Only way to make
sure that he does not get access to =
those is to protect them with
passphrase, or pin code =
or similar that is only known by the user.
 
This is also said out in the RFC 4478: "However, in the remote =
access
scenario it is usually up to a human user to =
supply the
authentication credentials ..."
 
Because of this I do not think there is that =
much requirement for
reauthentication protocol that is =
faster than what we already have. 
-- 
kivinen at safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
 
 
=0A=
=0A=
=0A=
=0A= =0A= =0A= =0A=

Note: Messages sent to this list = are the opinions of the senders and do not imply endorsement by the = IE

=0A=
 


Scanned by Check Point = Total Security Gateway. 

______________________= _________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org= /mailman/listinfo/ipsec

=
------_=_NextPart_001_01C932E1.BD5393B5-- --===============0544474398== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0544474398==-- From ipsec-bounces@ietf.org Mon Oct 20 11:34:40 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BADA03A69D6; Mon, 20 Oct 2008 11:34:40 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE73D3A69D6 for ; Mon, 20 Oct 2008 11:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKNjKSVZbLXn for ; Mon, 20 Oct 2008 11:34:38 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id D98953A6780 for ; Mon, 20 Oct 2008 11:34:37 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so686748eyd.31 for ; Mon, 20 Oct 2008 11:35:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=IaPU/gGScrcltzsVgzPJxEZy+gB+rTFLcMOUnxaUm4I=; b=bL6clnFcOtbhRkkizb1MIsyXL80LEBSlrgmgN2D1TUf4e3Em/N6i59Ir4Aq+a4/5nS 9kVvOhh4loLe5A+b1V8tAURZic8JFFK5BNMwSHbU4cX2c3hq0DJU/lKi/Fpv2fqKhdo5 Z61dK+JyMpw8rsH1AA8EKIKbZvSt6wHPH4Pec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=TGYbc7msrJiM/11sT3dbPROoGo+pl54Ib56eV7/1pSXJ1HYY0zKjQ/9BU7LFqJKDI5 AOEmdl0ZOoGwYbkcBTOYMvQH1VxlDpNGEwYiNWUvM2mPkdY4ec24A5gLsFEKgQrpsdiA yousgmlLrh4V1fu7pIc1AtCuCaD99ERiMlNxQ= Received: by 10.210.78.16 with SMTP id a16mr3926468ebb.66.1224527747707; Mon, 20 Oct 2008 11:35:47 -0700 (PDT) Received: by 10.210.109.14 with HTTP; Mon, 20 Oct 2008 11:35:47 -0700 (PDT) Message-ID: <1d38a3350810201135o22321abcw7ff23bfc5b28114e@mail.gmail.com> Date: Mon, 20 Oct 2008 20:35:47 +0200 From: "Hui Deng" To: "Yaron Sheffer" In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7DA@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 References: <200810161744113434215@mail.tsinghua.edu.cn> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7DA@il-ex01.ad.checkpoint.com> Cc: ipsec , "xuke@mail.tsinghua.edu.cn" Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1811931362==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1811931362== Content-Type: multipart/alternative; boundary="----=_Part_159317_10303851.1224527747706" ------=_Part_159317_10303851.1224527747706 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear authors, I would not like to offend how your authors are doing here. But we do carefully read through your previous draft and your "update" part of the new draft, Nothing could be found related to the "ticket reference". In such case, something would better be reminded that if some idea has been invented by the other draft, and you would like to use it by some revised form, please do refer to that draft. Many thanks -Hui 2008/10/20 Yaron Sheffer > > > Seen from a protocol point of view, it is critically important that the > ticket (or stub) is secured. But the contents of the ticket is much less > critical, since it is opaque to the client anyway. > > Draft-tschofenig mentions that the ticket can contain the actual IKE > (subset-) state, or it can contain a reference (pointer) to such state, > which is presumably stored on the gateway or near it. Quoting: > > Ticket reference: A pointer to a ticket. When resolving the > reference it obtains the ticket. > > In subsequent sections we use the term ticket and thereby refer to > both the ticket per value and by reference, unless indicated otherwise. > > (And yes, we could do a better job of mentioning this concept in Sec. 5, > where we describe the ticket in detail.) > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > xuke > Sent: Thursday, October 16, 2008 11:44 > To: ipsec > Subject: Re: [IPsec] Resuming the session resumption discussion > > Hi, all > > Basically, I agree with Yoav that the "ticket" concept is very similar > to the "stub" concept. > We did once thought to store the stub in the corresponding client > separately. And, in our draft, we also analyzed this case. > However, In the case of stub co-located with IPsec Client, the stub > MUST be perfectly protected to prevent the malicious attackers from > cracking the stub, if they can obtain the stub on the link. Actually, > from previous experiences, even if the stub is strongly encrypted, > there still has the risk. With the development of harware in accord > with the Moore's Law, the capability of computing equipment will be > increased step by step. Sometime, somehow, the brutal force decryption > of the stub/ticket encryption method may be possible. And, there is > also posibility that the currently safe encryption algorithm may be > proved to be mathematically solvable. So, in our draft, it is only > optional to transport the stub on the untrusted network, even if it > can be protected strongly. > > And, If we see it from the client point of view, the client does not > need to maintain a data structure to store the stubs. > Lastly, in the mobile network, the transfer of stubs over the air at > client side surely have much more service cost than doing it over the > fiber in network side. > > All in all, to keep the client to be simpler, easier for upgrade in > the future and keep the stub safer, personally, I'd rather to keep the > stub in the network side. > > xuke > Tsinghua University > > > > > > > We now have revised drafts from the two parties who has published earlier > drafts on session resumption. The (truncated) announcements are below. > > > > The WG should start discussing what we want from session resumption and > which of these two drafts (or what ideas from each of these two drafts) is > of interest to the WG. As a reminder, I start off with what our charter > says. > > > > Extra points are awarded for not copying this entire message in your > response. :-) > > > > --Paul Hoffman > > > _______________________________________________ > IPsec mailing list > IPsec at ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > ------=_Part_159317_10303851.1224527747706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear authors,
 
I would not like to offend how your authors are doing here.
 
But we do carefully read through your previous draft and your "update" part of the new draft,
Nothing could be found related to the "ticket reference".
 
In such case, something would better be reminded that if some idea has been invented by the other draft, and you would like to use it by some revised form, please do refer to that draft.
 
Many thanks
 
-Hui

2008/10/20 Yaron Sheffer <yaronf@checkpoint.com>
<co-chair hat off>

Seen from a protocol point of view, it is critically important that the
ticket (or stub) is secured. But the contents of the ticket is much less
critical, since it is opaque to the client anyway.

Draft-tschofenig mentions that the ticket can contain the actual IKE
(subset-) state, or it can contain a reference (pointer) to such state,
which is presumably stored on the gateway or near it. Quoting:

       Ticket reference:  A pointer to a ticket.  When resolving the
     reference it obtains the ticket.

       In subsequent sections we use the term ticket and thereby refer to
both the ticket per value and by reference, unless indicated otherwise.

(And yes, we could do a better job of mentioning this concept in Sec. 5,
where we describe the ticket in detail.)

Thanks,
       Yaron

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of
xuke
Sent: Thursday, October 16, 2008 11:44
To: ipsec
Subject: Re: [IPsec] Resuming the session resumption discussion

Hi, all

Basically, I agree with Yoav that the "ticket" concept is very similar
to the "stub" concept.
We did once thought to store the stub in the corresponding client
separately. And, in our draft, we also analyzed this case.
However, In the case of stub co-located with IPsec Client, the stub
MUST be perfectly protected to prevent the malicious attackers from
cracking the stub, if they can obtain the stub on the link.  Actually,
from previous experiences, even if the stub is strongly encrypted,
there still has the risk. With the development of harware in accord
with the Moore's Law, the capability of computing equipment will be
increased step by step. Sometime, somehow, the brutal force decryption
of the stub/ticket encryption method may be possible.  And, there is
also posibility that the currently safe encryption algorithm may be
proved to be mathematically solvable.  So, in our draft, it is only
optional to transport the stub on the untrusted network, even if it
can be protected strongly.

And, If we see it from the client point of view, the client does not
need to maintain a data structure to store the stubs.
Lastly, in the mobile network, the transfer of stubs over the air at
client side surely have much more service cost than doing it over the
fiber in network side.

All in all, to keep the client to be simpler, easier for upgrade in
the future and keep the stub safer, personally, I'd rather to keep the
stub in the network side.

xuke
Tsinghua University

> <co-chair hat on>
>
> We now have revised drafts from the two parties who has published earlier
drafts on session resumption. The (truncated) announcements are below.
>
> The WG should start discussing what we want from session resumption and
which of these two drafts (or what ideas from each of these two drafts) is
of interest to the WG. As a reminder, I start off with what our charter
says.
>
> Extra points are awarded for not copying this entire message in your
response. :-)
>
> --Paul Hoffman
>
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


------=_Part_159317_10303851.1224527747706-- --===============1811931362== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1811931362==-- From ipsec-bounces@ietf.org Mon Oct 20 11:56:03 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8ED23A692C; Mon, 20 Oct 2008 11:56:02 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D283A692C for ; Mon, 20 Oct 2008 11:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbgUU76ogwPX for ; Mon, 20 Oct 2008 11:55:54 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 50D373A6780 for ; Mon, 20 Oct 2008 11:55:53 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8BB1D294005; Mon, 20 Oct 2008 20:57:04 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3F4B2294003; Mon, 20 Oct 2008 20:57:03 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9KIv1ke016975; Mon, 20 Oct 2008 20:57:01 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 20 Oct 2008 20:57:01 +0200 From: Yaron Sheffer To: Hui Deng Date: Mon, 20 Oct 2008 20:56:55 +0200 Thread-Topic: [IPsec] Resuming the session resumption discussion Thread-Index: Acky4rI+4vDH0B1fT/GtR7Mrxt++vAAANXrg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E3@il-ex01.ad.checkpoint.com> References: <200810161744113434215@mail.tsinghua.edu.cn> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7DA@il-ex01.ad.checkpoint.com> <1d38a3350810201135o22321abcw7ff23bfc5b28114e@mail.gmail.com> In-Reply-To: <1d38a3350810201135o22321abcw7ff23bfc5b28114e@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: ipsec , "xuke@mail.tsinghua.edu.cn" Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2037651665==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2037651665== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_016B_01C932F6.62831070" ------=_NextPart_000_016B_01C932F6.62831070 Content-Type: multipart/alternative; boundary="----=_NextPart_001_016C_01C932F6.62831070" ------=_NextPart_001_016C_01C932F6.62831070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Hui, Yes, we should have cited your draft. And we could have had a more detailed description of the changes from the previous version. Note however that the idea of server-side storage of crypto protocol state has been around for ages, e.g. in the TLS "session cache" notion (RFC 2246). Thanks, Yaron _____ From: Hui Deng [mailto:denghui02@gmail.com] Sent: Monday, October 20, 2008 20:36 To: Yaron Sheffer Cc: xuke@mail.tsinghua.edu.cn; ipsec Subject: Re: [IPsec] Resuming the session resumption discussion Dear authors, I would not like to offend how your authors are doing here. But we do carefully read through your previous draft and your "update" part of the new draft, Nothing could be found related to the "ticket reference". In such case, something would better be reminded that if some idea has been invented by the other draft, and you would like to use it by some revised form, please do refer to that draft. Many thanks -Hui 2008/10/20 Yaron Sheffer Seen from a protocol point of view, it is critically important that the ticket (or stub) is secured. But the contents of the ticket is much less critical, since it is opaque to the client anyway. Draft-tschofenig mentions that the ticket can contain the actual IKE (subset-) state, or it can contain a reference (pointer) to such state, which is presumably stored on the gateway or near it. Quoting: Ticket reference: A pointer to a ticket. When resolving the reference it obtains the ticket. In subsequent sections we use the term ticket and thereby refer to both the ticket per value and by reference, unless indicated otherwise. (And yes, we could do a better job of mentioning this concept in Sec. 5, where we describe the ticket in detail.) Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of xuke Sent: Thursday, October 16, 2008 11:44 To: ipsec Subject: Re: [IPsec] Resuming the session resumption discussion Hi, all Basically, I agree with Yoav that the "ticket" concept is very similar to the "stub" concept. We did once thought to store the stub in the corresponding client separately. And, in our draft, we also analyzed this case. However, In the case of stub co-located with IPsec Client, the stub MUST be perfectly protected to prevent the malicious attackers from cracking the stub, if they can obtain the stub on the link. Actually, from previous experiences, even if the stub is strongly encrypted, there still has the risk. With the development of harware in accord with the Moore's Law, the capability of computing equipment will be increased step by step. Sometime, somehow, the brutal force decryption of the stub/ticket encryption method may be possible. And, there is also posibility that the currently safe encryption algorithm may be proved to be mathematically solvable. So, in our draft, it is only optional to transport the stub on the untrusted network, even if it can be protected strongly. And, If we see it from the client point of view, the client does not need to maintain a data structure to store the stubs. Lastly, in the mobile network, the transfer of stubs over the air at client side surely have much more service cost than doing it over the fiber in network side. All in all, to keep the client to be simpler, easier for upgrade in the future and keep the stub safer, personally, I'd rather to keep the stub in the network side. xuke Tsinghua University > > > We now have revised drafts from the two parties who has published earlier drafts on session resumption. The (truncated) announcements are below. > > The WG should start discussing what we want from session resumption and which of these two drafts (or what ideas from each of these two drafts) is of interest to the WG. As a reminder, I start off with what our charter says. > > Extra points are awarded for not copying this entire message in your response. :-) > > --Paul Hoffman > _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ------=_NextPart_001_016C_01C932F6.62831070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Hui,

 

Yes, we should have cited your = draft. And we could have had a more detailed description of the changes from the = previous version.

 

Note however that the idea of = server-side storage of crypto protocol state has been around for ages, e.g. in the = TLS “session cache” notion (RFC 2246).

 

Thanks,

=

      =       Yaron

 

From: Hui = Deng [mailto:denghui02@gmail.com]
Sent: Monday, October 20, = 2008 20:36
To: Yaron Sheffer
Cc: = xuke@mail.tsinghua.edu.cn; ipsec
Subject: Re: [IPsec] = Resuming the session resumption discussion

 

Dear authors,

 

I would not like to offend how your = authors are doing here.

 

But we do carefully read through your previous = draft and your "update" part of the new = draft,

Nothing could be found related to the "ticket reference".

 

In such case, something would better be reminded that if some = idea has been invented by the other draft, and you would like = to use it by some revised form, please do refer to that = draft.

 

Many thanks

 

-Hui

2008/10/20 Yaron = Sheffer <yaronf@checkpoint.com><= /o:p>

<co-chair hat off>

Seen from a protocol point of view, it is critically important that = the
ticket (or stub) is secured. But the contents of the ticket is much = less
critical, since it is opaque to the client anyway.

Draft-tschofenig mentions that the ticket can contain the actual IKE
(subset-) state, or it can contain a reference (pointer) to such = state,
which is presumably stored on the gateway or near it. Quoting:

       Ticket reference:  A pointer to a = ticket.  When resolving the
     reference it obtains the ticket.

       In subsequent sections we use the term ticket = and thereby refer to
both the ticket per value and by reference, unless indicated = otherwise.

(And yes, we could do a better job of mentioning this concept in Sec. = 5,
where we describe the ticket in detail.)


Thanks,
       Yaron

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of

xuke
Sent: Thursday, October 16, 2008 11:44
To: ipsec
Subject: Re: [IPsec] Resuming the session resumption = discussion

Hi, all

Basically, I agree with Yoav that the "ticket" concept is very similar
to the "stub" concept.
We did once thought to store the stub in the corresponding client
separately. And, in our draft, we also analyzed this case.
However, In the case of stub co-located with IPsec Client, the stub
MUST be perfectly protected to prevent the malicious attackers from
cracking the stub, if they can obtain the stub on the link. =  Actually,
from previous experiences, even if the stub is strongly encrypted,
there still has the risk. With the development of harware in accord
with the Moore's Law, the capability of computing equipment will be
increased step by step. Sometime, somehow, the brutal force = decryption
of the stub/ticket encryption method may be possible.  And, there = is
also posibility that the currently safe encryption algorithm may be
proved to be mathematically solvable.  So, in our draft, it is = only
optional to transport the stub on the untrusted network, even if it
can be protected strongly.

And, If we see it from the client point of view, the client does not
need to maintain a data structure to store the stubs.
Lastly, in the mobile network, the transfer of stubs over the air at
client side surely have much more service cost than doing it over = the
fiber in network side.

All in all, to keep the client to be simpler, easier for upgrade in
the future and keep the stub safer, personally, I'd rather to keep = the
stub in the network side.

xuke
Tsinghua University

> <co-chair hat on>
>
> We now have revised drafts from the two parties who has published = earlier
drafts on session resumption. The (truncated) announcements are = below.
>
> The WG should start discussing what we want from session resumption = and
which of these two drafts (or what ideas from each of these two drafts) = is
of interest to the WG. As a reminder, I start off with what our = charter
says.
>
> Extra points are awarded for not copying this entire message in = your
response. :-)
>
> --Paul Hoffman
>
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by = Check Point Total Security Gateway.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

 



Scanned by Check Point Total Security Gateway. =

------=_NextPart_001_016C_01C932F6.62831070-- ------=_NextPart_000_016B_01C932F6.62831070 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyMDE4NTY1NVowIwYJKoZIhvcNAQkEMRYEFNf9BLv73kTv ReGFuUv/CFIqJn3+MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA a/H8VNb1izFhtmZDatRg+RtaVqx2+E89xHsiKs4lI6eYiTXdm60BdZPS/IpmjYcQqXe7AZXnAZxo 5u0EhNbhxwetMZHVp3qt5obwmoc044hTp9UVQwATlvkmKKs5WIR213a9rqkMdulshM1k3tbOszfF lVyHH0otk+0Lbnru+4KFjqm9I7kY+ayZdFl/eMtb1iwFX78wvuvgC9RBTMDI60ddfAhu1Hk+8s6M 4On7ED/jseaS/0XzEYqUsyXBEORcI992AiyhBnwXzeaFDsd4RQ8VfGTkJY5htG4zhvcwi0uZ5yRf mzvHbgdn3ZK5wAoOP4Ahv9RLfkkyxz2haQDUIAAAAAAAAA== ------=_NextPart_000_016B_01C932F6.62831070-- --===============2037651665== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============2037651665==-- From ipsec-bounces@ietf.org Mon Oct 20 12:18:05 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A5D43A6887; Mon, 20 Oct 2008 12:18:05 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA023A6936 for ; Mon, 20 Oct 2008 12:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnE7yPliOE6I for ; Mon, 20 Oct 2008 12:18:02 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 5969E3A6887 for ; Mon, 20 Oct 2008 12:18:00 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2008 19:19:08 -0000 Received: from chello084114137227.1.15.vie.surfer.at (EHLO 4FIL42860) [84.114.137.227] by mail.gmx.net (mp027) with SMTP; 20 Oct 2008 21:19:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+gajVQe16gOskpyYjoT/GXUePIaYX4OUy5Tn3n4I zUYZ7jmL0uTBO8 From: "Hannes Tschofenig" To: "'Yaron Sheffer'" , "'Hui Deng'" References: <200810161744113434215@mail.tsinghua.edu.cn><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7DA@il-ex01.ad.checkpoint.com><1d38a3350810201135o22321abcw7ff23bfc5b28114e@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E3@il-ex01.ad.checkpoint.com> Date: Mon, 20 Oct 2008 22:19:05 +0300 Message-ID: <03ff01c932e8$bbf3fa60$0900a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E3@il-ex01.ad.checkpoint.com> Thread-Index: Acky4rI+4vDH0B1fT/GtR7Mrxt++vAAANXrgAAE+6yA= X-Y-GMX-Trusted: 0 X-FuHaFi: 0.83 Cc: 'ipsec' , xuke@mail.tsinghua.edu.cn Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Since we got asked by the group to get rid of the ticket format recommendations I believe we don't need to talk about the content at all. As such, it could be anything. We could call it ticket blob. I guess that should make everyone happy. Ciao Hannes ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: 20 October, 2008 21:57 To: Hui Deng Cc: ipsec; xuke@mail.tsinghua.edu.cn Subject: Re: [IPsec] Resuming the session resumption discussion Hi Hui, Yes, we should have cited your draft. And we could have had a more detailed description of the changes from the previous version. Note however that the idea of server-side storage of crypto protocol state has been around for ages, e.g. in the TLS "session cache" notion (RFC 2246). Thanks, Yaron ________________________________ From: Hui Deng [mailto:denghui02@gmail.com] Sent: Monday, October 20, 2008 20:36 To: Yaron Sheffer Cc: xuke@mail.tsinghua.edu.cn; ipsec Subject: Re: [IPsec] Resuming the session resumption discussion Dear authors, I would not like to offend how your authors are doing here. But we do carefully read through your previous draft and your "update" part of the new draft, Nothing could be found related to the "ticket reference". In such case, something would better be reminded that if some idea has been invented by the other draft, and you would like to use it by some revised form, please do refer to that draft. Many thanks -Hui 2008/10/20 Yaron Sheffer Seen from a protocol point of view, it is critically important that the ticket (or stub) is secured. But the contents of the ticket is much less critical, since it is opaque to the client anyway. Draft-tschofenig mentions that the ticket can contain the actual IKE (subset-) state, or it can contain a reference (pointer) to such state, which is presumably stored on the gateway or near it. Quoting: Ticket reference: A pointer to a ticket. When resolving the reference it obtains the ticket. In subsequent sections we use the term ticket and thereby refer to both the ticket per value and by reference, unless indicated otherwise. (And yes, we could do a better job of mentioning this concept in Sec. 5, where we describe the ticket in detail.) Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of xuke Sent: Thursday, October 16, 2008 11:44 To: ipsec Subject: Re: [IPsec] Resuming the session resumption discussion Hi, all Basically, I agree with Yoav that the "ticket" concept is very similar to the "stub" concept. We did once thought to store the stub in the corresponding client separately. And, in our draft, we also analyzed this case. However, In the case of stub co-located with IPsec Client, the stub MUST be perfectly protected to prevent the malicious attackers from cracking the stub, if they can obtain the stub on the link. Actually, from previous experiences, even if the stub is strongly encrypted, there still has the risk. With the development of harware in accord with the Moore's Law, the capability of computing equipment will be increased step by step. Sometime, somehow, the brutal force decryption of the stub/ticket encryption method may be possible. And, there is also posibility that the currently safe encryption algorithm may be proved to be mathematically solvable. So, in our draft, it is only optional to transport the stub on the untrusted network, even if it can be protected strongly. And, If we see it from the client point of view, the client does not need to maintain a data structure to store the stubs. Lastly, in the mobile network, the transfer of stubs over the air at client side surely have much more service cost than doing it over the fiber in network side. All in all, to keep the client to be simpler, easier for upgrade in the future and keep the stub safer, personally, I'd rather to keep the stub in the network side. xuke Tsinghua University > > > We now have revised drafts from the two parties who has published earlier drafts on session resumption. The (truncated) announcements are below. > > The WG should start discussing what we want from session resumption and which of these two drafts (or what ideas from each of these two drafts) is of interest to the WG. As a reminder, I start off with what our charter says. > > Extra points are awarded for not copying this entire message in your response. :-) > > --Paul Hoffman > _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 20 12:42:28 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6C53A6A72; Mon, 20 Oct 2008 12:42:28 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3443A6839 for ; Mon, 20 Oct 2008 12:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkL-Zz9beIS7 for ; Mon, 20 Oct 2008 12:42:27 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id E61D43A68F7 for ; Mon, 20 Oct 2008 12:42:25 -0700 (PDT) Received: (qmail invoked by alias); 20 Oct 2008 19:43:26 -0000 Received: from chello084114137227.1.15.vie.surfer.at (EHLO 4FIL42860) [84.114.137.227] by mail.gmx.net (mp052) with SMTP; 20 Oct 2008 21:43:26 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+9ut0GVR29BtznNeqxqvM+wyEuXakpdZ1s7PWAqE E4pqjZWNZm8lxt From: "Hannes Tschofenig" To: "'Hannes Tschofenig'" , "'Yaron Sheffer'" , "'Hui Deng'" References: <200810161744113434215@mail.tsinghua.edu.cn><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7DA@il-ex01.ad.checkpoint.com><1d38a3350810201135o22321abcw7ff23bfc5b28114e@mail.gmail.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E3@il-ex01.ad.checkpoint.com> <03ff01c932e8$bbf3fa60$0900a8c0@nsnintra.net> Date: Mon, 20 Oct 2008 22:43:25 +0300 Message-ID: <040501c932ec$20f3a980$0900a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <03ff01c932e8$bbf3fa60$0900a8c0@nsnintra.net> Thread-Index: Acky4rI+4vDH0B1fT/GtR7Mrxt++vAAANXrgAAE+6yAAANDY0A== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Cc: 'ipsec' , xuke@mail.tsinghua.edu.cn Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I thought about using the term "ticket blob" again and I think it is a really good idea. It puts a stronger emphasis on the fact that the document is not supposed to specify the content of the payload. I guess I will make this change to the draft. Thoughts? >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >On Behalf Of Hannes Tschofenig >Sent: 20 October, 2008 22:19 >To: 'Yaron Sheffer'; 'Hui Deng' >Cc: 'ipsec'; xuke@mail.tsinghua.edu.cn >Subject: Re: [IPsec] Resuming the session resumption discussion > >Since we got asked by the group to get rid of the ticket >format recommendations I believe we don't need to talk about >the content at all. >As such, it could be anything. We could call it ticket blob. > >I guess that should make everyone happy. > >Ciao >Hannes > > > >________________________________ > > From: ipsec-bounces@ietf.org >[mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer > Sent: 20 October, 2008 21:57 > To: Hui Deng > Cc: ipsec; xuke@mail.tsinghua.edu.cn > Subject: Re: [IPsec] Resuming the session resumption discussion > > > > Hi Hui, > > > > Yes, we should have cited your draft. And we could have >had a more detailed description of the changes from the >previous version. > > > > Note however that the idea of server-side storage of >crypto protocol state has been around for ages, e.g. in the >TLS "session cache" notion (RFC 2246). > > > > Thanks, > > Yaron > > > > ________________________________ > > From: Hui Deng [mailto:denghui02@gmail.com] > Sent: Monday, October 20, 2008 20:36 > To: Yaron Sheffer > Cc: xuke@mail.tsinghua.edu.cn; ipsec > Subject: Re: [IPsec] Resuming the session resumption discussion > > > > Dear authors, > > > > I would not like to offend how your authors are doing here. > > > > But we do carefully read through your previous draft >and your "update" part of the new draft, > > Nothing could be found related to the "ticket reference". > > > > In such case, something would better be reminded that >if some idea has been invented by the other draft, and you >would like to use it by some revised form, please do refer to >that draft. > > > > Many thanks > > > > -Hui > > 2008/10/20 Yaron Sheffer > > > > Seen from a protocol point of view, it is critically >important that the > ticket (or stub) is secured. But the contents of the >ticket is much less > critical, since it is opaque to the client anyway. > > Draft-tschofenig mentions that the ticket can contain >the actual IKE > (subset-) state, or it can contain a reference >(pointer) to such state, > which is presumably stored on the gateway or near it. Quoting: > > Ticket reference: A pointer to a ticket. When >resolving the > reference it obtains the ticket. > > In subsequent sections we use the term ticket >and thereby refer to > both the ticket per value and by reference, unless >indicated otherwise. > > (And yes, we could do a better job of mentioning this >concept in Sec. 5, > where we describe the ticket in detail.) > > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org >[mailto:ipsec-bounces@ietf.org] On Behalf Of > > xuke > Sent: Thursday, October 16, 2008 11:44 > To: ipsec > Subject: Re: [IPsec] Resuming the session resumption discussion > > Hi, all > > Basically, I agree with Yoav that the "ticket" concept >is very similar > to the "stub" concept. > We did once thought to store the stub in the >corresponding client > separately. And, in our draft, we also analyzed this case. > However, In the case of stub co-located with IPsec >Client, the stub > MUST be perfectly protected to prevent the malicious >attackers from > cracking the stub, if they can obtain the stub on the link. >Actually, > from previous experiences, even if the stub is strongly >encrypted, > there still has the risk. With the development of >harware in accord > with the Moore's Law, the capability of computing >equipment will be > increased step by step. Sometime, somehow, the brutal >force decryption > of the stub/ticket encryption method may be possible. >And, there is > also posibility that the currently safe encryption >algorithm may be > proved to be mathematically solvable. So, in our >draft, it is only > optional to transport the stub on the untrusted >network, even if it > can be protected strongly. > > And, If we see it from the client point of view, the >client does not > need to maintain a data structure to store the stubs. > Lastly, in the mobile network, the transfer of stubs >over the air at > client side surely have much more service cost than >doing it over the > fiber in network side. > > All in all, to keep the client to be simpler, easier >for upgrade in > the future and keep the stub safer, personally, I'd >rather to keep the > stub in the network side. > > xuke > Tsinghua University > > > > > > > We now have revised drafts from the two parties who >has published earlier > drafts on session resumption. The (truncated) >announcements are below. > > > > The WG should start discussing what we want from >session resumption and > which of these two drafts (or what ideas from each of these two >drafts) is > of interest to the WG. As a reminder, I start off with >what our charter > says. > > > > Extra points are awarded for not copying this entire >message in your > response. :-) > > > > --Paul Hoffman > > > _______________________________________________ > IPsec mailing list > IPsec at ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > Scanned by Check Point Total Security Gateway. > > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 20 13:15:02 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45DD13A6ADE; Mon, 20 Oct 2008 13:15:02 -0700 (PDT) X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5E8793A6AF2; Mon, 20 Oct 2008 13:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081020201501.5E8793A6AF2@core3.amsl.com> Date: Mon, 20 Oct 2008 13:15:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Re-direct Mechanism for IKEv2 Author(s) : V. Devarapalli, K. Weniger Filename : draft-ietf-ipsecme-ikev2-redirect-00.txt Pages : 11 Date : 2008-10-20 IKEv2 is a popular protocol for setting up VPN tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently there is no standard mechanism specified that allows an overloaded VPN gateway to re- direct the VPN client to attach to another gateway. This document proposes a re-direct mechanism for IKEv2. The proposed mechanism can also be used for Mobile IPv6 to enable the home agent to re-direct the mobile node to another home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ipsecme-ikev2-redirect-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-20130700.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Mon Oct 20 13:59:12 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01A83A6ADD; Mon, 20 Oct 2008 13:59:12 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28963A6ADD for ; Mon, 20 Oct 2008 13:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Lzah9jnXgau for ; Mon, 20 Oct 2008 13:59:10 -0700 (PDT) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id 714003A6AD5 for ; Mon, 20 Oct 2008 13:59:10 -0700 (PDT) Received: (qmail 21312 invoked by uid 0); 20 Oct 2008 20:53:36 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.145.18) by woodstock.binhost.com with SMTP; 20 Oct 2008 20:53:36 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 20 Oct 2008 16:39:11 -0400 To: "Hannes Tschofenig" From: Russ Housley In-Reply-To: <040501c932ec$20f3a980$0900a8c0@nsnintra.net> References: <200810161744113434215@mail.tsinghua.edu.cn> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7DA@il-ex01.ad.checkpoint.com> <1d38a3350810201135o22321abcw7ff23bfc5b28114e@mail.gmail.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E3@il-ex01.ad.checkpoint.com> <03ff01c932e8$bbf3fa60$0900a8c0@nsnintra.net> <040501c932ec$20f3a980$0900a8c0@nsnintra.net> Mime-Version: 1.0 Message-Id: <20081020205910.714003A6AD5@core3.amsl.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The term "opaque ticket" may work better for people from diverse cultures. Russ At 03:43 PM 10/20/2008, Hannes Tschofenig wrote: >I thought about using the term "ticket blob" again and I think it is a >really good idea. >It puts a stronger emphasis on the fact that the document is not supposed to >specify the content of the payload. > >I guess I will make this change to the draft. > >Thoughts? > > >-----Original Message----- > >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > >On Behalf Of Hannes Tschofenig > >Sent: 20 October, 2008 22:19 > >To: 'Yaron Sheffer'; 'Hui Deng' > >Cc: 'ipsec'; xuke@mail.tsinghua.edu.cn > >Subject: Re: [IPsec] Resuming the session resumption discussion > > > >Since we got asked by the group to get rid of the ticket > >format recommendations I believe we don't need to talk about > >the content at all. > >As such, it could be anything. We could call it ticket blob. > > > >I guess that should make everyone happy. > > > >Ciao > >Hannes > > > > > > > >________________________________ > > > > From: ipsec-bounces@ietf.org > >[mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer > > Sent: 20 October, 2008 21:57 > > To: Hui Deng > > Cc: ipsec; xuke@mail.tsinghua.edu.cn > > Subject: Re: [IPsec] Resuming the session resumption discussion > > > > > > > > Hi Hui, > > > > > > > > Yes, we should have cited your draft. And we could have > >had a more detailed description of the changes from the > >previous version. > > > > > > > > Note however that the idea of server-side storage of > >crypto protocol state has been around for ages, e.g. in the > >TLS "session cache" notion (RFC 2246). > > > > > > > > Thanks, > > > > Yaron > > > > > > > > ________________________________ > > > > From: Hui Deng [mailto:denghui02@gmail.com] > > Sent: Monday, October 20, 2008 20:36 > > To: Yaron Sheffer > > Cc: xuke@mail.tsinghua.edu.cn; ipsec > > Subject: Re: [IPsec] Resuming the session resumption discussion > > > > > > > > Dear authors, > > > > > > > > I would not like to offend how your authors are doing here. > > > > > > > > But we do carefully read through your previous draft > >and your "update" part of the new draft, > > > > Nothing could be found related to the "ticket reference". > > > > > > > > In such case, something would better be reminded that > >if some idea has been invented by the other draft, and you > >would like to use it by some revised form, please do refer to > >that draft. > > > > > > > > Many thanks > > > > > > > > -Hui > > > > 2008/10/20 Yaron Sheffer > > > > > > > > Seen from a protocol point of view, it is critically > >important that the > > ticket (or stub) is secured. But the contents of the > >ticket is much less > > critical, since it is opaque to the client anyway. > > > > Draft-tschofenig mentions that the ticket can contain > >the actual IKE > > (subset-) state, or it can contain a reference > >(pointer) to such state, > > which is presumably stored on the gateway or near it. Quoting: > > > > Ticket reference: A pointer to a ticket. When > >resolving the > > reference it obtains the ticket. > > > > In subsequent sections we use the term ticket > >and thereby refer to > > both the ticket per value and by reference, unless > >indicated otherwise. > > > > (And yes, we could do a better job of mentioning this > >concept in Sec. 5, > > where we describe the ticket in detail.) > > > > > > Thanks, > > Yaron > > > > -----Original Message----- > > From: ipsec-bounces@ietf.org > >[mailto:ipsec-bounces@ietf.org] On Behalf Of > > > > xuke > > Sent: Thursday, October 16, 2008 11:44 > > To: ipsec > > Subject: Re: [IPsec] Resuming the session resumption discussion > > > > Hi, all > > > > Basically, I agree with Yoav that the "ticket" concept > >is very similar > > to the "stub" concept. > > We did once thought to store the stub in the > >corresponding client > > separately. And, in our draft, we also analyzed this case. > > However, In the case of stub co-located with IPsec > >Client, the stub > > MUST be perfectly protected to prevent the malicious > >attackers from > > cracking the stub, if they can obtain the stub on the link. > >Actually, > > from previous experiences, even if the stub is strongly > >encrypted, > > there still has the risk. With the development of > >harware in accord > > with the Moore's Law, the capability of computing > >equipment will be > > increased step by step. Sometime, somehow, the brutal > >force decryption > > of the stub/ticket encryption method may be possible. > >And, there is > > also posibility that the currently safe encryption > >algorithm may be > > proved to be mathematically solvable. So, in our > >draft, it is only > > optional to transport the stub on the untrusted > >network, even if it > > can be protected strongly. > > > > And, If we see it from the client point of view, the > >client does not > > need to maintain a data structure to store the stubs. > > Lastly, in the mobile network, the transfer of stubs > >over the air at > > client side surely have much more service cost than > >doing it over the > > fiber in network side. > > > > All in all, to keep the client to be simpler, easier > >for upgrade in > > the future and keep the stub safer, personally, I'd > >rather to keep the > > stub in the network side. > > > > xuke > > Tsinghua University > > > > > > > > > > > We now have revised drafts from the two parties who > >has published earlier > > drafts on session resumption. The (truncated) > >announcements are below. > > > > > > The WG should start discussing what we want from > >session resumption and > > which of these two drafts (or what ideas from each of these two > >drafts) is > > of interest to the WG. As a reminder, I start off with > >what our charter > > says. > > > > > > Extra points are awarded for not copying this entire > >message in your > > response. :-) > > > > > > --Paul Hoffman > > > > > _______________________________________________ > > IPsec mailing list > > IPsec at ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > Scanned by Check Point Total Security Gateway. > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > > > > > Scanned by Check Point Total Security Gateway. > > > > > >_______________________________________________ > >IPsec mailing list > >IPsec@ietf.org > >https://www.ietf.org/mailman/listinfo/ipsec > > > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 20 15:48:51 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BD283A6862; Mon, 20 Oct 2008 15:48:51 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A0AF3A6862 for ; Mon, 20 Oct 2008 15:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnX9KrhTqfFS for ; Mon, 20 Oct 2008 15:48:49 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 5FAA23A67E9 for ; Mon, 20 Oct 2008 15:48:49 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 595EC1FE0210; Mon, 20 Oct 2008 15:50:01 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 20 Oct 2008 15:50:01 -0700 (PDT) Message-ID: <6ebe21296f38bcced604f912ee5583fd.squirrel@www.trepanning.net> In-Reply-To: <040501c932ec$20f3a980$0900a8c0@nsnintra.net> References: <200810161744113434215@mail.tsinghua.edu.cn><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7DA@il-ex01.ad.checkpoint.com><1d38a3350810201135o22321abcw7ff23bfc5b28114e@mail.gmail.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E3@il-ex01.ad.checkpoint.com> <03ff01c932e8$bbf3fa60$0900a8c0@nsnintra.net> <040501c932ec$20f3a980$0900a8c0@nsnintra.net> Date: Mon, 20 Oct 2008 15:50:01 -0700 (PDT) From: "Dan Harkins" To: "Hannes Tschofenig" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: 'Hui Deng' , 'ipsec' , 'Hannes Tschofenig' , xuke@mail.tsinghua.edu.cn Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Well, strictly speaking it says "detailed contents" so I guess it depends on what the word "detailed" means. If nothing is said on the matter I fear that the scenario that Xuke mentioned will happen. Just because there are no interoperability requirements on some particular part of a protocol does not mean we can't recommend (or even insist upon) behavior. There is precedence for recommending behavior on things that have no interoperability impact. If the opaque blob is a reference or index into some server-maintained context and has no sensitive components then there really isn't much to worry about but if the opaque blob contains cryptographic keying material then I don't think we can be silent on the matter. Dan. On Mon, October 20, 2008 12:43 pm, Hannes Tschofenig wrote: > I thought about using the term "ticket blob" again and I think it is a > really good idea. > It puts a stronger emphasis on the fact that the document is not supposed > to > specify the content of the payload. > > I guess I will make this change to the draft. > > Thoughts? > >>-----Original Message----- >>From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >>On Behalf Of Hannes Tschofenig >>Sent: 20 October, 2008 22:19 >>To: 'Yaron Sheffer'; 'Hui Deng' >>Cc: 'ipsec'; xuke@mail.tsinghua.edu.cn >>Subject: Re: [IPsec] Resuming the session resumption discussion >> >>Since we got asked by the group to get rid of the ticket >>format recommendations I believe we don't need to talk about >>the content at all. >>As such, it could be anything. We could call it ticket blob. >> >>I guess that should make everyone happy. >> >>Ciao >>Hannes >> >> >> >>________________________________ >> >> From: ipsec-bounces@ietf.org >>[mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer >> Sent: 20 October, 2008 21:57 >> To: Hui Deng >> Cc: ipsec; xuke@mail.tsinghua.edu.cn >> Subject: Re: [IPsec] Resuming the session resumption discussion >> >> >> >> Hi Hui, >> >> >> >> Yes, we should have cited your draft. And we could have >>had a more detailed description of the changes from the >>previous version. >> >> >> >> Note however that the idea of server-side storage of >>crypto protocol state has been around for ages, e.g. in the >>TLS "session cache" notion (RFC 2246). >> >> >> >> Thanks, >> >> Yaron >> >> >> >> ________________________________ >> >> From: Hui Deng [mailto:denghui02@gmail.com] >> Sent: Monday, October 20, 2008 20:36 >> To: Yaron Sheffer >> Cc: xuke@mail.tsinghua.edu.cn; ipsec >> Subject: Re: [IPsec] Resuming the session resumption discussion >> >> >> >> Dear authors, >> >> >> >> I would not like to offend how your authors are doing here. >> >> >> >> But we do carefully read through your previous draft >>and your "update" part of the new draft, >> >> Nothing could be found related to the "ticket reference". >> >> >> >> In such case, something would better be reminded that >>if some idea has been invented by the other draft, and you >>would like to use it by some revised form, please do refer to >>that draft. >> >> >> >> Many thanks >> >> >> >> -Hui >> >> 2008/10/20 Yaron Sheffer >> >> >> >> Seen from a protocol point of view, it is critically >>important that the >> ticket (or stub) is secured. But the contents of the >>ticket is much less >> critical, since it is opaque to the client anyway. >> >> Draft-tschofenig mentions that the ticket can contain >>the actual IKE >> (subset-) state, or it can contain a reference >>(pointer) to such state, >> which is presumably stored on the gateway or near it. Quoting: >> >> Ticket reference: A pointer to a ticket. When >>resolving the >> reference it obtains the ticket. >> >> In subsequent sections we use the term ticket >>and thereby refer to >> both the ticket per value and by reference, unless >>indicated otherwise. >> >> (And yes, we could do a better job of mentioning this >>concept in Sec. 5, >> where we describe the ticket in detail.) >> >> >> Thanks, >> Yaron >> >> -----Original Message----- >> From: ipsec-bounces@ietf.org >>[mailto:ipsec-bounces@ietf.org] On Behalf Of >> >> xuke >> Sent: Thursday, October 16, 2008 11:44 >> To: ipsec >> Subject: Re: [IPsec] Resuming the session resumption discussion >> >> Hi, all >> >> Basically, I agree with Yoav that the "ticket" concept >>is very similar >> to the "stub" concept. >> We did once thought to store the stub in the >>corresponding client >> separately. And, in our draft, we also analyzed this case. >> However, In the case of stub co-located with IPsec >>Client, the stub >> MUST be perfectly protected to prevent the malicious >>attackers from >> cracking the stub, if they can obtain the stub on the link. >>Actually, >> from previous experiences, even if the stub is strongly >>encrypted, >> there still has the risk. With the development of >>harware in accord >> with the Moore's Law, the capability of computing >>equipment will be >> increased step by step. Sometime, somehow, the brutal >>force decryption >> of the stub/ticket encryption method may be possible. >>And, there is >> also posibility that the currently safe encryption >>algorithm may be >> proved to be mathematically solvable. So, in our >>draft, it is only >> optional to transport the stub on the untrusted >>network, even if it >> can be protected strongly. >> >> And, If we see it from the client point of view, the >>client does not >> need to maintain a data structure to store the stubs. >> Lastly, in the mobile network, the transfer of stubs >>over the air at >> client side surely have much more service cost than >>doing it over the >> fiber in network side. >> >> All in all, to keep the client to be simpler, easier >>for upgrade in >> the future and keep the stub safer, personally, I'd >>rather to keep the >> stub in the network side. >> >> xuke >> Tsinghua University >> >> > >> > >> > We now have revised drafts from the two parties who >>has published earlier >> drafts on session resumption. The (truncated) >>announcements are below. >> > >> > The WG should start discussing what we want from >>session resumption and >> which of these two drafts (or what ideas from each of these two >>drafts) is >> of interest to the WG. As a reminder, I start off with >>what our charter >> says. >> > >> > Extra points are awarded for not copying this entire >>message in your >> response. :-) >> > >> > --Paul Hoffman >> > >> _______________________________________________ >> IPsec mailing list >> IPsec at ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> >> >> >> Scanned by Check Point Total Security Gateway. >> >> >>_______________________________________________ >>IPsec mailing list >>IPsec@ietf.org >>https://www.ietf.org/mailman/listinfo/ipsec >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Oct 21 00:15:48 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC1B3A6A12; Tue, 21 Oct 2008 00:15:48 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F853A689B for ; Tue, 21 Oct 2008 00:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtHbwjYAbTm9 for ; Tue, 21 Oct 2008 00:15:47 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with SMTP id DE9903A67D9 for ; Tue, 21 Oct 2008 00:15:39 -0700 (PDT) Received: from source ([213.206.132.136]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Tue, 21 Oct 2008 00:16:48 PDT Received: from NOI1EXCH002.sfnt.local ([172.25.10.6]) by cam1exch002.sfnt.local with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 08:16:47 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 21 Oct 2008 12:46:13 +0530 Message-ID: <7A581A93408E68408DB73274370D78D372BCED@NOI1EXCH002.sfnt.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EAP-AKA' draft queries. Thread-Index: AckzTOZffR7L3HJSTpuQx99mXbW5SA== From: "Kumar, Sunil" To: X-OriginalArrivalTime: 21 Oct 2008 07:16:47.0231 (UTC) FILETIME=[FAA358F0:01C9334C] Cc: ipsec@ietf.org, "Pal, Yogendra" Subject: [IPsec] EAP-AKA' draft queries. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1131168041==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1131168041== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9334C.E6E23B40" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9334C.E6E23B40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Arkko, =20 We were going through the details of the new variant of EAP-AKA in IETF drafts and found your draft of EAP-AKA' (draft-arkko-eap-aka-kdf-xx.txt) We have few queries related to the same Referring to the section 3.3 of draft, during full authentication process, MK is derived as follows: MK =3D PRF' ( IK' | CK' , "EAP-AKA' " | Identity ) Ques1 What is the value of the "EAP-AKA' " in above MK derivation? As there is no proposed value or description is available in the draft document. When we are considering the case of fast re-authentication process, MK is derived as follows: MK =3D PRF' (K_re, "EAP-AKA' re-auth" | Identity | Counter | = NONCE_S) Ques 2 What is the value of the "EAP-AKA' re-auth" in above MK generation? Similarly here also there is no proposed value or description is available. =20 Thanks and Regards, Sunil / Yogendra The information contained in this electronic mail transmission = may be privileged and confidential, and therefore, protected = from disclosure. If you have received this communication in = error, please notify us immediately by replying to this = message and deleting it from your computer without copying = or disclosing it. =0D ------_=_NextPart_001_01C9334C.E6E23B40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Arkko,

 

We were going through the details of the new variant of EAP-AKA = in IETF drafts
and found your draft of EAP-AKA' (draft-arkko-eap-aka-kdf-xx.txt)

We have few queries related to the same


 Referring to the section 3.3 of draft, during full authentication process,
      MK is derived as follows:

      MK =3D PRF' ( IK' | CK' , = "EAP-AKA' " | Identity )

Ques1  What is the = value of the "EAP-AKA' " = in above MK derivation? As there is no proposed value or description is available = in the draft document.

    When we are considering the case of fast re-authentication process,

    MK is derived as follows:
    MK =3D PRF' (K_re, "EAP-AKA'  re-auth" = | Identity | Counter | NONCE_S)

Ques = 2   What is the value of the "EAP-AKA'  re-auth" in above MK generation? Similarly here also = there is no proposed value or description is = available.

 

Thanks and Regards,

Sunil / Yogendra

The RFC 4478 simply skips this question and says "With s=
ome IPsec
peers, particularly in the remote access scenario, it is desi=
rable to
repeat the mutual authentication periodically. The purpose of=
 this is
to limit the time that security associations (SAs) can be use=
d by a
third party who has gained control of the IPsec peer."
 
In most cases if third party has gained control of the IPsec =
peer he
will also get control of all authentication information insid=
e the
peer, including private keys and pre shared keys. Only way to=
 make
sure that he does not get access to those is to protect them =
with
passphrase, or pin code or similar that is only known by the =
user.
 
This is also said out in the RFC 4478: "However, in the =
remote access
scenario it is usually up to a human user to supply the<=
/o:p>
authentication credentials ..."=

 
Because of this I do not think there is that much requirement=
 for
reauthentication protocol that is faster than what we already=
 have. 
-- 
kivinen at safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/m=
ailman/listinfo/ipsec
 
 
  • Follow-Ups:
      • = From: <= /span>Martin Willi
  • References:
      • = From: <= /span>Martin Willi
 
The information contained in this electronic mail transmission =

may be privileged and confidential, and therefore, protected =

from disclosure. If you have received this communication in =

error, please notify us immediately by replying to this =

message and deleting it from your computer without copying =

or disclosing it.

=0D
------_=_NextPart_001_01C9334C.E6E23B40--

--===============1131168041==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--===============1131168041==--


From ipsec-bounces@ietf.org  Tue Oct 21 00:25:54 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E11583A6810;
	Tue, 21 Oct 2008 00:25:54 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E9A743A67FF
	for ; Tue, 21 Oct 2008 00:25:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 4vjB2CkH5jTw for ;
	Tue, 21 Oct 2008 00:25:53 -0700 (PDT)
Received: from ns.64translator.com (ns.64translator.com [202.214.123.16])
	by core3.amsl.com (Postfix) with ESMTP id D8AB33A67D9
	for ; Tue, 21 Oct 2008 00:25:52 -0700 (PDT)
Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3])
	by ns.64translator.com (8.14.2/8.14.2) with ESMTP id m9L7PoqR052784
	for ; Tue, 21 Oct 2008 16:25:50 +0900 (JST)
	(envelope-from akisada@tahi.org)
Received: from localhost (dhcp163.64translator.com [10.21.32.163])
	by bahamas.64translator.com (8.13.6/8.13.6) with SMTP id m9L7PePw005133
	for ; Tue, 21 Oct 2008 16:25:40 +0900 (JST)
	(envelope-from akisada@tahi.org)
Date: Tue, 21 Oct 2008 16:25:31 +0900
From: Yukiyo Akisada 
To: ipsec@ietf.org
Message-Id: <20081021162531.af9b7963.akisada@tahi.org>
Organization: TAHI Project
X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.12; i386-portbld-freebsd4.11)
Mime-Version: 1.0
Subject: [IPsec] [IKEv2] Call for Review
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

We, IPv6 Ready Logo Committee would like to call for
review of IPv6 Ready Logo Program Phase-2 for IKEv2.

This program covers following RFCs.

    - RFC 4306 - Internet Key Exchange (IKEv2) Protocol
    - RFC 4307 - Cryptographic Algorithms for Use in the
                 Internet Key Exchange Version 2 (IKEv2)
    - RFC 4718 - IKEv2 Clarifications and Implementation Guidelines

You can find
the conformance test specification and the interoperability test scenario
from .
And test tool is also available for dry-run.

Please send any comments to  by Nov. 20th.

Thanks for your feedback.

Regards,


-- 
Yukiyo Akisada 
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


From ipsec-bounces@ietf.org  Tue Oct 21 02:07:26 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 222BD3A6B33;
	Tue, 21 Oct 2008 02:07:26 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 27A0E3A6B33
	for ; Tue, 21 Oct 2008 02:07:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.495
X-Spam-Level: 
X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, 
	BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id acXCJZ2Xl9pJ for ;
	Tue, 21 Oct 2008 02:07:24 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54])
	by core3.amsl.com (Postfix) with ESMTP id 3CAB43A67E1
	for ; Tue, 21 Oct 2008 02:07:24 -0700 (PDT)
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105)
	id 04E51294003; Tue, 21 Oct 2008 11:08:37 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68])
	by dlpdemo.checkpoint.com (Postfix) with ESMTP id 232A6294005;
	Tue, 21 Oct 2008 11:08:31 +0200 (IST)
Received: from localhost (localhost [127.0.0.1])
	by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id
	m9L98Ukl000124; Tue, 21 Oct 2008 11:08:30 +0200 (IST)
Message-Id: 
From: Yoav Nir 
To: Hannes Tschofenig 
In-Reply-To: <03ff01c932e8$bbf3fa60$0900a8c0@nsnintra.net>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Tue, 21 Oct 2008 11:08:27 +0200
References: <200810161744113434215@mail.tsinghua.edu.cn><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7DA@il-ex01.ad.checkpoint.com><1d38a3350810201135o22321abcw7ff23bfc5b28114e@mail.gmail.com>
	<7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E3@il-ex01.ad.checkpoint.com>
	<03ff01c932e8$bbf3fa60$0900a8c0@nsnintra.net>
X-Mailer: Apple Mail (2.929.2)
Cc: 'Hui Deng' , 'ipsec' ,
	xuke@mail.tsinghua.edu.cn
Subject: Re: [IPsec] Resuming the session resumption discussion
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Getting rid of a format may be OK, but your draft should list  
everything that has to be inside the ticket, even though it's possible  
to figure it out from the protocol.

And maybe we also need a document to explain the terms blob, ticket,  
token, stub and opaque, and when each is appropriate :-)

Yoav

On Oct 20, 2008, at 9:19 PM, Hannes Tschofenig wrote:

> Since we got asked by the group to get rid of the ticket format
> recommendations I believe we don't need to talk about the content at  
> all.
> As such, it could be anything. We could call it ticket blob.
>
> I guess that should make everyone happy.
>
> Ciao
> Hannes
>


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


From ipsec-bounces@ietf.org  Tue Oct 21 03:47:55 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 67B5C3A6B44;
	Tue, 21 Oct 2008 03:47:55 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C36BE3A6B0B
	for ; Tue, 21 Oct 2008 03:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.203
X-Spam-Level: *
X-Spam-Status: No, score=1.203 tagged_above=-999 required=5
	tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6,
	J_CHICKENPOX_21=0.6, NORMAL_HTTP_TO_IP=0.001]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id MmwYNhaKZ254 for ;
	Tue, 21 Oct 2008 03:47:52 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.235])
	by core3.amsl.com (Postfix) with ESMTP id 0F7023A6B44
	for ; Tue, 21 Oct 2008 03:47:52 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id b25so2055847rvf.49
	for ; Tue, 21 Oct 2008 03:48:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to
	:subject:mime-version:content-type;
	bh=BRTtJOWO3yhDNt5SGtkBZSvKZ9tcYJQtb1cpzSBuKkw=;
	b=rFskEbtmiZAZ8+eilzGVq+HgxpnMk7dRiwSLBD0hP1jDQkAU76UKnCCnmNrf1HjTF5
	kiqPsrvJ1eidusCOqhWaM+Eg7OnUWyJ8hojP5QeC257MKdXWA7hhBKIEV7yD17fY4cRL
	4ZNz3lFhN4NpM1TlqlZt/v8w9rKLG9vgbSemk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:mime-version:content-type;
	b=VuRpdz9oCqrSw20n53tIc91JMK7dewU2/8rm+3SzQhgOR8MrnLO9OXPwUhYIdrAc0F
	WHMjbN6mYRNn7BRdFhdKa4w7crmkH+vMHelmr3QlUSF7+VNMOKO34qBmPZnUdZk5iVgM
	+b8iieyek2PTiRNLSgdMw83ObWrTR7AmmGogg=
Received: by 10.140.132.8 with SMTP id f8mr5566257rvd.122.1224586132768;
	Tue, 21 Oct 2008 03:48:52 -0700 (PDT)
Received: by 10.141.115.14 with HTTP; Tue, 21 Oct 2008 03:48:52 -0700 (PDT)
Message-ID: <9cd3ad9d0810210348n49c44d90j179f808cc88cc143@mail.gmail.com>
Date: Tue, 21 Oct 2008 16:18:52 +0530
From: "Sujithra P" 
To: ipsec@ietf.org
MIME-Version: 1.0
Subject: [IPsec] Fragmentation of ESP Packets on 2.6 linux kernel
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1096938693=="
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

--===============1096938693==
Content-Type: multipart/alternative; 
	boundary="----=_Part_2398_1710126.1224586132746"

------=_Part_2398_1710126.1224586132746
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,

I am using ESP in transport mode between IMS SIP Client and PCSCF ( 3GPP
33.203).
I am running the SIP client on linux kernel using setkey to manage SAs.
When the ESP packets from the PCSCF are fragmented, the linux kernel is not
processing it.
I am not able to receive the packet at the application.

Linux Version: Linux ubuntu 2.6.24

The following ESP packet is fragmented, but the kernel is not processing it.
I am not receiving the packet at application. If the ESP packet is not
fragmented, it works fine.

14:18:23.995392 IP 192.168.10.10 > 10.6.2.49: ESP(spi=0x00acf799,seq=0x6),
length 1436
        0x0000:  4500 05b0 8d1f 2000 fb32 3613 c0a8 0a0a  E........26.....
        0x0010:  0a06 0231 00ac f799 0000 0006 0000 0000  ...1............
        0x0020:  0000 0000 32b8 7c8c 4db9 872d 0fb8 85a6  ....2.|.M..-....
        0x0030:  9078 4040 596c 0d34 f3f2 dca3 0536 5083  .x@@Yl.4.....6P.
        0x0040:  112c ed0f 8311 ba30 b95c c16a a940 753c  .,.....0.\.j.@u<
        0x0050:  16eb cf57 f02c 9306 0343 adae 6c12 4dea  ...W.,...C..l.M.
        0x0060:  4917 fcc5 ef4d eddd 5f2c 9df4 8092 bebe  I....M.._,......
        0x0070:  72d8 a704 4415 6cc0 3fe5 3295 22ab c014  r...D.l.?.2."...
        0x0080:  cbeb 9e93 1000 65ca 2655 be46 d4b1 43cf  ......e.&U.F..C.
        0x0090:  b5f4 a4cf c139 e453 9eb3 9a3b f901 ee1d  .....9.S...;....
        0x00a0:  7fa2 2bfd 04a2 1be2 b850 824d 8e32 b14f  ..+......P.M.2.O
        0x00b0:  a817 2a20 c554 0e79 8ffa 4a0d 4dff ec98  ..*..T.y..J.M...
        0x00c0:  f61b a163 0fe8 0326 4a72 5fb6 d0e9 de26  ...c...&Jr_....&
        0x00d0:  09cb 9a8f 4ce5 101a 2841 b4fb 8178 ad59  ....L...(A...x.Y
        0x00e0:  0774 6459 7c1d 72bb 61b2 ee61 132e 810b  .tdY|.r.a..a....
        0x00f0:  105c a328 d742 dd7b 8ffc 1da5 a703 290d  .\.(.B.{......).
        0x0100:  3301 ffcb 9267 dcd2 cfff de8a 5de6 018e  3....g......]...
        0x0110:  dd3b ef17 db86 52ce 8f70 53c9 5e5f 6482  .;....R..pS.^_d.
        0x0120:  9340 8d87 af62 e90a 7bdb 5c10 eb71 2ab7  .@...b..{.\..q*.
        0x0130:  e7e0 a212 4a7f f014 6469 7887 942a 99a8  ....J...dix..*..
        0x0140:  051e 5c3c c98e 11d3 a1d8 1254 44a8 20bf  ..\<.......TD...
        0x0150:  16f4 ff9b f0dc f71d a641 3bea e6d8 82b6  .........A;.....
        0x0160:  1547 6b40 24c3 3418 8471 0240 2f7f ddd7  .Gk@$.4..q.@/...
        0x0170:  fd90 ea94 51d5 64d1 bd61 ea50 542f 7b91  ....Q.d..a.PT/{.
        0x0180:  1c8b 7a64 bf90 bcac 56f6 1cde 7b54 645c  ..zd....V...{Td\
        0x0190:  440d a9a3 fd24 f3d3 76ac 3ab1 76f2 21a3  D....$..v.:.v.!.
        0x01a0:  d9b1 c622 4205 bbc0 92e9 a30d 900f 8cac  ..."B...........
        0x01b0:  fb14 05e8 0a46 9b90 8183 335e b5d8 7472  .....F....3^..tr
        0x01c0:  79cc 2492 03ff d9fb 3b9a 4345 ba0b 4936  y.$.....;.CE..I6
        0x01d0:  1b7a bf01 83c6 e18f 71fa 00f9 45f2 e671  .z......q...E..q
        0x01e0:  ed36 c437 d4a8 c2ee aa44 9d22 869c a937  .6.7.....D."...7
        0x01f0:  9cf3 4d42 c97f d707 60d2 b597 f943 cd53  ..MB....`....C.S
        0x0200:  8895 a7a0 aefd 4e55 510d 1659 a06f 9695  ......NUQ..Y.o..
        0x0210:  1824 75bf fb2e 018a c8b0 9681 f1a7 3db4  .$u...........=.
        0x0220:  fa98 d833 0e2e 23cf 9e8f bb25 caa6 93d9  ...3..#....%....
        0x0230:  a546 ecb8 bdc5 8f7d 6056 6e86 2d6b 9b1d  .F.....}`Vn.-k..
        0x0240:  d5a3 28b7 b1d6 628f d817 b5b9 2bdc 70a6  ..(...b.....+.p.
        0x0250:  2b08 350a d1fe 8b4f e536 f0e7 5bb6 0007  +.5....O.6..[...
        0x0260:  bd49 3ada 864a 59b6 d449 ec81 dafc 908b  .I:..JY..I......
        0x0270:  99a4 88ed 1e65 1a1f d598 db65 2656 f28a  .....e.....e&V..
        0x0280:  0182 8762 4679 fd82 dec6 4a52 0a98 c16b  ...bFy....JR...k
        0x0290:  5c0d b194 e592 6180 5225 4367 f3e3 af65  \.....a.R%Cg...e
        0x02a0:  4d99 a596 1059 4d5a 8a9c 0ca8 df5f 0131  M....YMZ....._.1
        0x02b0:  73ca 8d6c 305a 7391 db45 6a16 79a4 443d  s..l0Zs..Ej.y.D=
        0x02c0:  438b eecb d13d 6a55 2887 7f3d d3fd 95db  C....=jU(..=....
        0x02d0:  d401 4146 e970 3947 57ef ac10 4ea0 aa34  ..AF.p9GW...N..4
        0x02e0:  8c1c b0b3 3df8 d432 2e03 1e8a cb93 f116  ....=..2........
        0x02f0:  acc3 01f4 05db 5869 e037 1f3f 49bf 13bf  ......Xi.7.?I...
        0x0300:  4c73 6d2d a886 b351 a719 39ca 4da5 9499  Lsm-...Q..9.M...
        0x0310:  38f3 6581 1089 be1a fbf6 b8bd 4ba9 04a7  8.e.........K...
        0x0320:  f7ce aa8c 2bf4 5e8f 5025 b6fd c0fe 8c8a  ....+.^.P%......
        0x0330:  aa93 2b49 9fc6 29be cf9b 0cce 18f0 f901  ..+I..).........
        0x0340:  6dbf 8274 22e2 b2e8 2d63 3b1e 0e2f 8718  m..t"...-c;../..
        0x0350:  69e3 5cee edf7 8611 326d b081 8f2c 44b7  i.\.....2m...,D.
        0x0360:  4d63 6acf 2f3b 47ce dc68 c695 dd80 e0dd  Mcj./;G..h......
        0x0370:  919e 7d0c 9212 7597 3afd a95c af4a 6883  ..}...u.:..\.Jh.
        0x0380:  e90d 0702 9dac 4b01 0dc8 cf23 f02d aa93  ......K....#.-..
        0x0390:  6615 eae9 bce0 567d db37 c0ef 748a 1825  f.....V}.7..t..%
        0x03a0:  762b 4b24 4af1 72bb e286 c44a cf49 b818  v+K$J.r....J.I..
        0x03b0:  22b6 fae6 9295 aa81 202a 407c 0228 df98  "........*@|.(..
        0x03c0:  7609 bac9 ba5b 1a35 e30a bedf 33ed c78b  v....[.5....3...
        0x03d0:  f8c8 92db 9d7a 1a45 818f 3542 3134 fdbc  .....z.E..5B14..
        0x03e0:  1ffe 21c8 dcd8 14a4 0dab bc4e b82d e416  ..!........N.-..
        0x03f0:  90f0 3e9f 59bc 43b7 a6d1 1835 5896 90b6  ..>.Y.C....5X...
        0x0400:  6586 efdc 9efe 04ae 125b 1afb f425 1e94  e........[...%..
        0x0410:  c704 3d30 d71f 344c 3643 5658 e723 ac9b  ..=0..4L6CVX.#..
        0x0420:  ed07 7835 3447 a22f 9cf2 06e6 f0f4 6e53  ..x54G./......nS
        0x0430:  24cc b0e7 0cfb efdd 29a4 c3f2 a122 55a2  $.......)...."U.
        0x0440:  ca63 df2f c1b6 aa0c a90a 9f7c 70ab 4486  .c./.......|p.D.
        0x0450:  5b18 74e4 8fb7 fa9c 8c48 942e fe0a 2ee5  [.t......H......
        0x0460:  d550 cae3 fe4e b1c8 5a17 134c 4109 2f73  .P...N..Z..LA./s
        0x0470:  6d80 ac4b 371e a9ba 01e7 3348 6719 f749  m..K7.....3Hg..I
        0x0480:  3274 4ee3 4ac1 6b5d fd7c bceb 398f 1633  2tN.J.k].|..9..3
        0x0490:  bb6d b629 6c0b 140d 7afe c53f d0d5 323d  .m.)l...z..?..2=
        0x04a0:  c15b 5d56 ff16 e3a9 0447 e820 a292 c271  .[]V.....G.....q
        0x04b0:  289d 4606 394c 1a2c 7836 76bc 3186 db98  (.F.9L.,x6v.1...
        0x04c0:  1e52 ab07 88c8 aa7d a97d 3591 01dd dd50  .R.....}.}5....P
        0x04d0:  e5be 7209 ffd1 4581 807a b3fe e3f6 8071  ..r...E..z.....q
        0x04e0:  2944 ea97 99ae 5a96 efaa 4799 3fca c9da  )D....Z...G.?...
        0x04f0:  0540 092e 00e3 7dc0 3117 cdee 379d 7714  .@....}.1...7.w.
        0x0500:  ef31 b190 e9ff aab0 b866 3c27 b8cd 3a8f  .1.......f<'..:.
        0x0510:  9930 2900 a288 de1b 1de5 aa4d e9b4 8f9a  .0)........M....
        0x0520:  4596 2367 c813 0a8f 4955 e9ff 1ef6 df55  E.#g....IU.....U
        0x0530:  0e19 ba64 c3ff 4623 8072 23f6 43b5 9f9b  ...d..F#.r#.C...
        0x0540:  dd86 058f 6b48 5924 5845 1b5b 674c 53f5  ....kHY$XE.[gLS.
        0x0550:  0eff a8b1 88f3 0917 01eb 2d9c b52d f768  ..........-..-.h
        0x0560:  107d d45c 1fda 0351 7f5f ed42 6790 31db  .}.\...Q._.Bg.1.
        0x0570:  c878 92a4 9046 0da6 a022 a227 a778 262d  .x...F...".'.x&-
        0x0580:  e5a5 50d3 0740 16dc 4502 4db2 e328 37e3  ..P..@..E.M..(7.
        0x0590:  3f46 830f 81ed 7c02 0d3d 8657 067d 887f  ?F....|..=.W.}..
        0x05a0:  7550 f676 37ac 6384 06ee 47d9 9909 c916  uP.v7.c...G.....
14:18:23.995410 IP 192.168.10.10 > 10.6.2.49: esp
        0x0000:  4500 00e0 8d1f 00af fb32 5a34 c0a8 0a0a  E........2Z4....
        0x0010:  0a06 0231 00ac f799 0000 0007 0000 0000  ...1............
        0x0020:  0000 0000 0384 71c9 5ef7 99c2 4bba c63d  ......q.^...K..=
        0x0030:  a562 f8f2 2aef e4dd cc60 038e d015 38a6  .b..*....`....8.
        0x0040:  cd64 8bd5 5d64 2fcd f059 a46e 08cd 4771  .d..]d/..Y.n..Gq
        0x0050:  a68a 6624 9957 7ace 5231 2626 3471 2061  ..f$.Wz.R1&&4q.a
        0x0060:  41a7 2a32 39d1 a259 5b5c 61d8 535e 9f39  A.*29..Y[\a.S^.9
        0x0070:  0da8 9c45 52b9 f6d3 c272 b2a7 f23a f868  ...ER....r...:.h
        0x0080:  6691 d0e1 a526 9ea5 9a5b 3534 6951 124e  f....&...[54iQ.N
        0x0090:  56da 592d 1cc0 6d75 29cb 15b4 f077 fa2c  V.Y-..mu)....w.,
        0x00a0:  2eff 178a baa8 889f b512 6585 f5da 6332  ..........e...c2
        0x00b0:  2670 2ab2 2eb6 66b2 19c7 a148 3872 2972  &p*...f....H8r)r
        0x00c0:  a967 6a77 d79f dffa e3f8 9e86 2a87 f0ba  .gjw........*...
        0x00d0:  4467 03fa 1d01 28a6 9a7e 46f9 6679 1fe8  Dg....(..~F.fy..

Could anyone tell me what is the issue.
Any help in this regard is greatly appreciated.

Thanks in advance,
Sujithra.

------=_Part_2398_1710126.1224586132746
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi all,



I am using ESP in transport mode between IMS SIP Client and PCSCF ( 3GPP 33.203).

I am running the SIP client on linux kernel using setkey to manage SAs.

When the ESP packets from the PCSCF are fragmented, the linux kernel is not processing it.

I am not able to receive the packet at the application.



Linux Version: Linux ubuntu 2.6.24



The following ESP packet is fragmented, but the kernel is not
processing it. I am not receiving the packet at application. If the ESP
packet is not fragmented, it works fine.



14:18:23.995392 IP 192.168.10.10 > 10.6.2.49: ESP(spi=0x00acf799,seq=0x6), length 1436

        0x0000:  4500 05b0 8d1f 2000 fb32 3613 c0a8 0a0a  E........26.....

        0x0010:  0a06 0231 00ac f799 0000 0006 0000 0000  ...1............

        0x0020:  0000 0000 32b8 7c8c 4db9 872d 0fb8 85a6  ....2.|.M..-....

        0x0030:  9078 4040 596c 0d34 f3f2 dca3 0536 5083  .x@@Yl.4.....6P.

        0x0040:  112c ed0f 8311 ba30 b95c c16a a940 753c  .,.....0.\.j.@u<

        0x0050:  16eb cf57 f02c 9306 0343 adae 6c12 4dea  ...W.,...C..l.M.

        0x0060:  4917 fcc5 ef4d eddd 5f2c 9df4 8092 bebe  I....M.._,......

        0x0070:  72d8 a704 4415 6cc0 3fe5 3295 22ab c014  r...D.l.?.2."...

        0x0080:  cbeb 9e93 1000 65ca 2655 be46 d4b1 43cf  ......e.&U.F..C.

        0x0090:  b5f4 a4cf c139 e453 9eb3 9a3b f901 ee1d  .....9.S...;....

        0x00a0:  7fa2 2bfd 04a2 1be2 b850 824d 8e32 b14f  ..+......P.M.2.O

        0x00b0:  a817 2a20 c554 0e79 8ffa 4a0d 4dff ec98  ..*..T.y..J.M...

        0x00c0:  f61b a163 0fe8 0326 4a72 5fb6 d0e9 de26  ...c...&Jr_....&

        0x00d0:  09cb 9a8f 4ce5 101a 2841 b4fb 8178 ad59  ....L...(A...x.Y

        0x00e0:  0774 6459 7c1d 72bb 61b2 ee61 132e 810b  .tdY|.r.a..a....

        0x00f0:  105c a328 d742 dd7b 8ffc 1da5 a703 290d  .\.(.B.{......).

        0x0100:  3301 ffcb 9267 dcd2 cfff de8a 5de6 018e  3....g......]...

        0x0110:  dd3b ef17 db86 52ce 8f70 53c9 5e5f 6482  .;....R..pS.^_d.

        0x0120:  9340 8d87 af62 e90a 7bdb 5c10 eb71 2ab7  .@...b..{.\..q*.

        0x0130:  e7e0 a212 4a7f f014 6469 7887 942a 99a8  ....J...dix..*..

        0x0140:  051e 5c3c c98e 11d3 a1d8 1254 44a8 20bf  ..\<.......TD...

        0x0150:  16f4 ff9b f0dc f71d a641 3bea e6d8 82b6  .........A;.....

        0x0160:  1547 6b40 24c3 3418 8471 0240 2f7f ddd7  .Gk@$.4..q.@/...

        0x0170:  fd90 ea94 51d5 64d1 bd61 ea50 542f 7b91  ....Q.d..a.PT/{.

        0x0180:  1c8b 7a64 bf90 bcac 56f6 1cde 7b54 645c  ..zd....V...{Td\

        0x0190:  440d a9a3 fd24 f3d3 76ac 3ab1 76f2 21a3  D....$..v.:.v.!.

        0x01a0:  d9b1 c622 4205 bbc0 92e9 a30d 900f 8cac  ..."B...........

        0x01b0:  fb14 05e8 0a46 9b90 8183 335e b5d8 7472  .....F....3^..tr

        0x01c0:  79cc 2492 03ff d9fb 3b9a 4345 ba0b 4936  y.$.....;.CE..I6

        0x01d0:  1b7a bf01 83c6 e18f 71fa 00f9 45f2 e671  .z......q...E..q

        0x01e0:  ed36 c437 d4a8 c2ee aa44 9d22 869c a937  .6.7.....D."...7

        0x01f0:  9cf3 4d42 c97f d707 60d2 b597 f943 cd53  ..MB....`....C.S

        0x0200:  8895 a7a0 aefd 4e55 510d 1659 a06f 9695  ......NUQ..Y.o..

        0x0210:  1824 75bf fb2e 018a c8b0 9681 f1a7 3db4  .$u...........=.

        0x0220:  fa98 d833 0e2e 23cf 9e8f bb25 caa6 93d9  ...3..#....%....

        0x0230:  a546 ecb8 bdc5 8f7d 6056 6e86 2d6b 9b1d  .F.....}`Vn.-k..

        0x0240:  d5a3 28b7 b1d6 628f d817 b5b9 2bdc 70a6  ..(...b.....+.p.

        0x0250:  2b08 350a d1fe 8b4f e536 f0e7 5bb6 0007  +.5....O.6..[...

        0x0260:  bd49 3ada 864a 59b6 d449 ec81 dafc 908b  .I:..JY..I......

        0x0270:  99a4 88ed 1e65 1a1f d598 db65 2656 f28a  .....e.....e&V..

        0x0280:  0182 8762 4679 fd82 dec6 4a52 0a98 c16b  ...bFy....JR...k

        0x0290:  5c0d b194 e592 6180 5225 4367 f3e3 af65  \.....a.R%Cg...e

        0x02a0:  4d99 a596 1059 4d5a 8a9c 0ca8 df5f 0131  M....YMZ....._.1

        0x02b0:  73ca 8d6c 305a 7391 db45 6a16 79a4 443d  s..l0Zs..Ej.y.D=

        0x02c0:  438b eecb d13d 6a55 2887 7f3d d3fd 95db  C....=jU(..=....

        0x02d0:  d401 4146 e970 3947 57ef ac10 4ea0 aa34  ..AF.p9GW...N..4

        0x02e0:  8c1c b0b3 3df8 d432 2e03 1e8a cb93 f116  ....=..2........

        0x02f0:  acc3 01f4 05db 5869 e037 1f3f 49bf 13bf  ......Xi.7.?I...

        0x0300:  4c73 6d2d a886 b351 a719 39ca 4da5 9499  Lsm-...Q..9.M...

        0x0310:  38f3 6581 1089 be1a fbf6 b8bd 4ba9 04a7  8.e.........K...

        0x0320:  f7ce aa8c 2bf4 5e8f 5025 b6fd c0fe 8c8a  ....+.^.P%......

        0x0330:  aa93 2b49 9fc6 29be cf9b 0cce 18f0 f901  ..+I..).........

        0x0340:  6dbf 8274 22e2 b2e8 2d63 3b1e 0e2f 8718  m..t"...-c;../..

        0x0350:  69e3 5cee edf7 8611 326d b081 8f2c 44b7  i.\.....2m...,D.

        0x0360:  4d63 6acf 2f3b 47ce dc68 c695 dd80 e0dd  Mcj./;G..h......

        0x0370:  919e 7d0c 9212 7597 3afd a95c af4a 6883  ..}...u.:..\.Jh.

        0x0380:  e90d 0702 9dac 4b01 0dc8 cf23 f02d aa93  ......K....#.-..

        0x0390:  6615 eae9 bce0 567d db37 c0ef 748a 1825  f.....V}.7..t..%

        0x03a0:  762b 4b24 4af1 72bb e286 c44a cf49 b818  v+K$J.r....J.I..

        0x03b0:  22b6 fae6 9295 aa81 202a 407c 0228 df98  "........*@|.(..

        0x03c0:  7609 bac9 ba5b 1a35 e30a bedf 33ed c78b  v....[.5....3...

        0x03d0:  f8c8 92db 9d7a 1a45 818f 3542 3134 fdbc  .....z.E..5B14..

        0x03e0:  1ffe 21c8 dcd8 14a4 0dab bc4e b82d e416  ..!........N.-..

        0x03f0:  90f0 3e9f 59bc 43b7 a6d1 1835 5896 90b6  ..>.Y.C....5X...

        0x0400:  6586 efdc 9efe 04ae 125b 1afb f425 1e94  e........[...%..

        0x0410:  c704 3d30 d71f 344c 3643 5658 e723 ac9b  ..=0..4L6CVX.#..

        0x0420:  ed07 7835 3447 a22f 9cf2 06e6 f0f4 6e53  ..x54G./......nS

        0x0430:  24cc b0e7 0cfb efdd 29a4 c3f2 a122 55a2  $.......)...."U.

        0x0440:  ca63 df2f c1b6 aa0c a90a 9f7c 70ab 4486  .c./.......|p.D.

        0x0450:  5b18 74e4 8fb7 fa9c 8c48 942e fe0a 2ee5  [.t......H......

        0x0460:  d550 cae3 fe4e b1c8 5a17 134c 4109 2f73  .P...N..Z..LA./s

        0x0470:  6d80 ac4b 371e a9ba 01e7 3348 6719 f749  m..K7.....3Hg..I

        0x0480:  3274 4ee3 4ac1 6b5d fd7c bceb 398f 1633  2tN.J.k].|..9..3

        0x0490:  bb6d b629 6c0b 140d 7afe c53f d0d5 323d  .m.)l...z..?..2=

        0x04a0:  c15b 5d56 ff16 e3a9 0447 e820 a292 c271  .[]V.....G.....q

        0x04b0:  289d 4606 394c 1a2c 7836 76bc 3186 db98  (.F.9L.,x6v.1...

        0x04c0:  1e52 ab07 88c8 aa7d a97d 3591 01dd dd50  .R.....}.}5....P

        0x04d0:  e5be 7209 ffd1 4581 807a b3fe e3f6 8071  ..r...E..z.....q

        0x04e0:  2944 ea97 99ae 5a96 efaa 4799 3fca c9da  )D....Z...G.?...

        0x04f0:  0540 092e 00e3 7dc0 3117 cdee 379d 7714  .@....}.1...7.w.

        0x0500:  ef31 b190 e9ff aab0 b866 3c27 b8cd 3a8f  .1.......f<'..:.

        0x0510:  9930 2900 a288 de1b 1de5 aa4d e9b4 8f9a  .0)........M....

        0x0520:  4596 2367 c813 0a8f 4955 e9ff 1ef6 df55  E.#g....IU.....U

        0x0530:  0e19 ba64 c3ff 4623 8072 23f6 43b5 9f9b  ...d..F#.r#.C...

        0x0540:  dd86 058f 6b48 5924 5845 1b5b 674c 53f5  ....kHY$XE.[gLS.

        0x0550:  0eff a8b1 88f3 0917 01eb 2d9c b52d f768  ..........-..-.h

        0x0560:  107d d45c 1fda 0351 7f5f ed42 6790 31db  .}.\...Q._.Bg.1.

        0x0570:  c878 92a4 9046 0da6 a022 a227 a778 262d  .x...F...".'.x&-

        0x0580:  e5a5 50d3 0740 16dc 4502 4db2 e328 37e3  ..P..@..E.M..(7.

        0x0590:  3f46 830f 81ed 7c02 0d3d 8657 067d 887f  ?F....|..=.W.}..

        0x05a0:  7550 f676 37ac 6384 06ee 47d9 9909 c916  uP.v7.c...G.....

14:18:23.995410 IP 192.168.10.10 > 10.6.2.49: esp

        0x0000:  4500 00e0 8d1f 00af fb32 5a34 c0a8 0a0a  E........2Z4....

        0x0010:  0a06 0231 00ac f799 0000 0007 0000 0000  ...1............

        0x0020:  0000 0000 0384 71c9 5ef7 99c2 4bba c63d  ......q.^...K..=

        0x0030:  a562 f8f2 2aef e4dd cc60 038e d015 38a6  .b..*....`....8.

        0x0040:  cd64 8bd5 5d64 2fcd f059 a46e 08cd 4771  .d..]d/..Y.n..Gq

        0x0050:  a68a 6624 9957 7ace 5231 2626 3471 2061  ..f$.Wz.R1&&4q.a

        0x0060:  41a7 2a32 39d1 a259 5b5c 61d8 535e 9f39  A.*29..Y[\a.S^.9

        0x0070:  0da8 9c45 52b9 f6d3 c272 b2a7 f23a f868  ...ER....r...:.h

        0x0080:  6691 d0e1 a526 9ea5 9a5b 3534 6951 124e  f....&...[54iQ.N

        0x0090:  56da 592d 1cc0 6d75 29cb 15b4 f077 fa2c  V.Y-..mu)....w.,

        0x00a0:  2eff 178a baa8 889f b512 6585 f5da 6332  ..........e...c2

        0x00b0:  2670 2ab2 2eb6 66b2 19c7 a148 3872 2972  &p*...f....H8r)r

        0x00c0:  a967 6a77 d79f dffa e3f8 9e86 2a87 f0ba  .gjw........*...

        0x00d0:  4467 03fa 1d01 28a6 9a7e 46f9 6679 1fe8  Dg....(..~F.fy..



Could anyone tell me what is the issue.

Any help in this regard is greatly appreciated.



Thanks in advance,

Sujithra.








------=_Part_2398_1710126.1224586132746--

--===============1096938693==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--===============1096938693==--


From ipsec-bounces@ietf.org  Tue Oct 21 04:23:05 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id BF2473A687D;
	Tue, 21 Oct 2008 04:23:05 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 7641E3A687D
	for ; Tue, 21 Oct 2008 04:23:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id 82x7jJWFsrLh for ;
	Tue, 21 Oct 2008 04:23:03 -0700 (PDT)
Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81])
	by core3.amsl.com (Postfix) with ESMTP id 3DEAD3A67A7
	for ; Tue, 21 Oct 2008 04:23:02 -0700 (PDT)
Received: from [59.66.24.181] (helo=xuke-x61)
	by smtp.tsinghua.edu.cn with esmtpa (Exim 4.63)
	(envelope-from )
	id 1KsFLQ-0002Mo-Qe; Tue, 21 Oct 2008 19:24:12 +0800
Date: Tue, 21 Oct 2008 19:24:15 +0800
From: "xuke" 
To: "Dan Harkins" 
References: <200810161744113434215@mail.tsinghua.edu.cn>,
	
Message-ID: <200810211924147654792@mail.tsinghua.edu.cn>
Organization: Institute of Computer Network and Technology, Tsinghua University
X-mailer: Foxmail 6, 11, 101, 15 [cn]
Mime-Version: 1.0
Cc: ipsec 
Subject: Re: [IPsec] Resuming the session resumption discussion
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: xuke@mail.tsinghua.edu.cn
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Hi, Dan

Basically, I agree with your point. That's one of the reason we put
the client co-located stub as an option in the draft.
By the way, one thing for sure, the stub in the network side is PURELY safe.

Thanks
xuke

>
>  Hello,
>
>  I'm not sure what "perfectly protected" means but if one uses a
>key-wrapping technique with provable security (like RFC 5297-- AES-SIV,
>which is in AUTH48 state and should be published very shortly) then
>an attack against the ticket should be no more possible than an attack
>against the IPsec traffic itself. These tickets must use deterministic
>authenticated encryption and provided the thing that's being wrapped in
>the ticket is a cryptographic key, like SK_d, the randomness it adds
>will allow the ticket protection scheme to achieve semantic security.
>
>  Dan.
>
>On Thu, October 16, 2008 2:44 am, xuke wrote:
>> Hi, all
>>
>> Basically, I agree with Yoav that the "ticket" concept is very similar
>> to the "stub" concept.
>> We did once thought to store the stub in the corresponding client
>> separately. And, in our draft, we also analyzed this case.
>> However, In the case of stub co-located with IPsec Client, the stub
>> MUST be perfectly protected to prevent the malicious attackers from
>> cracking the stub, if they can obtain the stub on the link.  Actually,
>> from previous experiences, even if the stub is strongly encrypted,
>> there still has the risk. With the development of harware in accord
>> with the Moore's Law, the capability of computing equipment will be
>> increased step by step. Sometime, somehow, the brutal force decryption
>> of the stub/ticket encryption method may be possible.  And, there is
>> also posibility that the currently safe encryption algorithm may be
>> proved to be mathematically solvable.  So, in our draft, it is only
>> optional to transport the stub on the untrusted network, even if it
>> can be protected strongly.
>>
>> And, If we see it from the client point of view, the client does not
>> need to maintain a data structure to store the stubs.
>> Lastly, in the mobile network, the transfer of stubs over the air at
>> client side surely have much more service cost than doing it over the
>> fiber in network side.
>>
>> All in all, to keep the client to be simpler, easier for upgrade in
>> the future and keep the stub safer, personally, I'd rather to keep the
>> stub in the network side.
>>
>> xuke
>> Tsinghua University
>>
>>> 
>>>
>>> We now have revised drafts from the two parties who has published
>>> earlier drafts on session resumption. The (truncated) announcements are
>>> below.
>>>
>>> The WG should start discussing what we want from session resumption and
>>> which of these two drafts (or what ideas from each of these two drafts)
>>> is of interest to the WG. As a reminder, I start off with what our
>>> charter says.
>>>
>>> Extra points are awarded for not copying this entire message in your
>>> response. :-)
>>>
>>> --Paul Hoffman
>>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec at ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>
>
>_______________________________________________
>IPsec mailing list
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec
>

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


From ipsec-bounces@ietf.org  Tue Oct 21 06:09:45 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 2CC4C3A6836;
	Tue, 21 Oct 2008 06:09:45 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id DCAC63A6A95
	for ; Tue, 21 Oct 2008 06:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.033
X-Spam-Level: 
X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5
	tests=[AWL=-0.676, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001,
	HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id EVd0QPoDDlYU for ;
	Tue, 21 Oct 2008 06:09:31 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54])
	by core3.amsl.com (Postfix) with ESMTP id 912483A6836
	for ; Tue, 21 Oct 2008 06:09:29 -0700 (PDT)
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105)
	id 54C9F29C001; Tue, 21 Oct 2008 15:09:49 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68])
	by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9A997294005;
	Tue, 21 Oct 2008 15:09:46 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1])
	by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id
	m9LD9jke021256; Tue, 21 Oct 2008 15:09:45 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by
	il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 21 Oct 2008
	15:09:44 +0200
From: Yaron Sheffer 
To: Gary Hemminger , Yoav Nir 
Date: Tue, 21 Oct 2008 15:09:42 +0200
Thread-Topic: Identifying encrypted traffic (was: [IPsec] Reauthentication
	extension for IKEv2)
Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkhACbyvnA=
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com>
References: 
	<648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com>
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "ipsec@ietf.org" 
Subject: [IPsec] Identifying encrypted traffic (was: Reauthentication
 extension for IKEv2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0309076203=="
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

--===============0309076203==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0180_01C9338F.0B9F02C0"

------=_NextPart_000_0180_01C9338F.0B9F02C0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0181_01C9338F.0BA173C0"


------=_NextPart_001_0181_01C9338F.0BA173C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Gary,

 

I'm puzzled by the scenario you are presenting. I've been considering the
work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01)
as useful for middleboxes that want to look at the IPsec-protected traffic,
but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In
general, if you can terminate IPsec, that means that you have access to the
encryption keys and you can easily differentiate protected and unprotected
traffic, Can you explain the use case that you have in mind?

 

Thanks,

            Yaron

 

  _____  

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of
Gary Hemminger
Sent: Monday, October 20, 2008 20:26
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for IKEv2

 

I was talking about how to make the determination that the payload is
encrypted.  Evidently there are two approaches:  one based on a heuristic,
another based on a payload wrapper that flags the payload is encrypted.  We
would need some mechanism to determine the payload is encryped if we need to
terminate the IPSEC traffic and make a determination of which server to send
it to.  Sorry about the confusion.

 

Gary

 

  _____  

From: Yoav Nir [mailto:ynir@checkpoint.com]
Sent: Sat 10/18/2008 2:03 PM
To: Gary Hemminger
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for IKEv2

Hi Gary. 

 

I'm not sure what heuristics you are talking about. The problem of
re-authentication is simply this. The owner of the remote access gateway has
a security policy that says that connections can be open for only so long
(say, 2 hours) without authenticating the user again. This is a favorite
requirement by auditors, who believe that this is an important part of risk
management. If somebody steals your laptop (or mobile phone) or sits down at
the Internet Cafe station where you were logged on, we want to limit the
amount of time they are connected to the internal network. This requirement
makes sense if the user has to type in their password to authenticate. It
makes less sense if there are user certificates that are stored on the
computer, or if the client software has a "save password" feature.

 

Whether it makes sense or not, this is a requirement by auditors and
regulators. If the user does not re-authenticate within the specified time,
the IKE SA and all dependent child SAs are deleted.  This creates a
usability problem, because the SA is deleted without any advance warning to
the user, so the user is likely to get a relatively long time with no
connectivity. This can break TCP connections such as FTP, HTTP, and IMAP.
Outlook tends to make accounts permanently offline when this happens.

 

RFC 4778 and the improvement that Martin Willi is proposing, are aimed at
solving this usability problem by informing the client software in advance
when the re-authentication needs to be done, and allowing them to
re-authenticate early enough, so that connections are not broken. The
heuristic does not affect the security or the IPsec streams.

 

Yoav

 

On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote:






One comment on the heuristics approach.  As a hardware vendor of L4-7 ADC
boxes, I am a little concerned about having to terminate IPSEC streams based
on the heuristics approach, because this is open ended.  What I mean is that
the heuristic may be easy to define now, but there is no certainty that it
would remain this way.  My past experience suggests that eventually the
heuristic would become too complex, and a well defined mechanism for
determining which payload is encrypted would need to be employed anyway.   


While I like the idea of some "other" box having to solve this issue, which
prevents clients from having to be changed, as we are a vendor of the
"other" box, I think we should think about the long term, not the short
term.  Just my opinion, and I am certainly flexible, but the heuristics
approach worries me a bit.


 


Gary


 


[IPsec] Reauthentication extension for IKEv2

  _____  


*	To: Martin Willi 
strongswan.org> 
*	Subject: [IPsec] Reauthentication extension for IKEv2 
*	From: Tero Kivinen 
> 
*	Date: Tue, 16 Sep 2008 12:09:14 +0300 
*	Cc: ipsec at ietf.org   
*	Delivered-to: ietfarch-ipsec-web-archive
  at core3.amsl.com 
*	Delivered-to: ipsec at core3.amsl.com   
*	In-reply-to: <48CF5D7D.7070701 at
  strongswan.org> 
*	List-archive:  
*	List-help:  
*	List-id: Discussion of IPsec protocols  
*	List-post:  
*	List-subscribe: ,
 
*	List-unsubscribe: ,
 
*	References: <48CF5D7D.7070701 at
  strongswan.org> 
*	Sender: ipsec-bounces at ietf.org
 

  _____  

Martin Willi writes:
> What do you think about such an extension? Already considered something
> similar, or does your reauthentication procedure work hassle-free? I'm
> wondering if we are the only ones facing these problems or if such an
> extension would gain broader acceptance...
 
The first question I have is why are you doing reauthentication at
all?
 
What is the benefits of the reauthentication?
 
What is the benefits of the reauthentication that can be done WITHOUT
user intervention (i.e. no user typing in password or pin code or
fingerprint or similar)?
 
I myself can only really see benefits from reauthentication when it
does require that user is really sitting there on the machine, and
gives something that the machine itself cannot give. In those cases
the user is required to type in something or do something anyways,
thus it does not really matter if the communications is interrupted
for second if user must stop his work for much longer time to type in
his passphrase or pin code.
 
The RFC 4478 simply skips this question and says "With some IPsec
peers, particularly in the remote access scenario, it is desirable to
repeat the mutual authentication periodically. The purpose of this is
to limit the time that security associations (SAs) can be used by a
third party who has gained control of the IPsec peer."
 
In most cases if third party has gained control of the IPsec peer he
will also get control of all authentication information inside the
peer, including private keys and pre shared keys. Only way to make
sure that he does not get access to those is to protect them with
passphrase, or pin code or similar that is only known by the user.
 
This is also said out in the RFC 4478: "However, in the remote access
scenario it is usually up to a human user to supply the
authentication credentials ..."
 
Because of this I do not think there is that much requirement for
reauthentication protocol that is faster than what we already have. 
-- 
kivinen at safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
 
 
  _____  


*	Follow-Ups: 

*	 
Re: [IPsec] Reauthentication extension for IKEv2 

*	From: Martin Willi

*	References: 

*	 
[IPsec] Reauthentication extension for IKEv2 

*	From: Martin Willi

*	Prev by Date: [IPsec]

Reauthentication extension for IKEv2 
*	Next by Date: Re:
  [IPsec]
Reauthentication extension for IKEv2 
*	Previous by thread: [IPsec]

Reauthentication extension for IKEv2 
*	Next by thread: Re:
  [IPsec]
Reauthentication extension for IKEv2 
*	Index(es): 

*

Date 
*

Thread


Note: Messages sent to this list are the opinions of the senders and do not
imply endorsement by the IE


 



Scanned by Check Point Total Security Gateway. 

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

 



Scanned by Check Point Total Security Gateway. 


------=_NextPart_001_0181_01C9338F.0BA173C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




















Hi =
Gary,



 



I’m puzzled by the scenario =
you are
presenting. I’ve been considering the work on ESP-null detection =
(e.g. draft-grewal-ipsec-traffic-visibility-01)
as useful for middleboxes that want to look at the IPsec-protected =
traffic, but
do NOT want to terminate IPsec (i.e. decapsulate the traffic). In =
general, if
you can terminate IPsec, that means that you have access to the =
encryption keys
and you can easily differentiate protected and unprotected traffic, Can =
you
explain the use case that you have in mind?



 



Thanks,
=



      =
      Yaron



 















From:
ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger

Sent: Monday, October 20, =
2008
20:26

To: Yoav
 Nir

Cc: ipsec@ietf.org

Subject: Re: [IPsec]
Reauthentication extension for IKEv2






 









I was talking about how to make =
the
determination that the payload is encrypted.  Evidently there are =
two
approaches:  one based on a heuristic, another based on a payload =
wrapper
that flags the payload is encrypted.  We would need some mechanism =
to
determine the payload is encryped if we need to terminate the IPSEC =
traffic and
make a determination of which server to send it to.  Sorry about =
the
confusion.









 









Gary












 












From: Yoav Nir [mailto:ynir@checkpoint.com]

Sent: Sat 10/18/2008 2:03 =
PM

To: Gary Hemminger

Cc: ipsec@ietf.org

Subject: Re: [IPsec]
Reauthentication extension for IKEv2









Hi Gary. 






 









I'm not sure what heuristics you are talking about. The problem =
of
re-authentication is simply this. The owner of the remote access gateway =
has a
security policy that says that connections can be open for only so long =
(say, 2
hours) without authenticating the user again. This is a favorite =
requirement by
auditors, who believe that this is an important part of risk management. =
If
somebody steals your laptop (or mobile phone) or sits down at the =
Internet Cafe
station where you were logged on, we want to limit the amount of time =
they are
connected to the internal network. This requirement makes sense if the =
user has
to type in their password to authenticate. It makes less sense if there =
are user
certificates that are stored on the computer, or if the client software =
has a
"save password" feature.









 









Whether it makes sense or not, this is a requirement by auditors =
and
regulators. If the user does not re-authenticate within the specified =
time, the
IKE SA and all dependent child SAs are deleted.  This =
creates a
usability problem, because the SA is deleted without any advance warning =
to the
user, so the user is likely to get a relatively long time with no =
connectivity.
This can break TCP connections such as FTP, HTTP, and IMAP. Outlook =
tends to
make accounts permanently offline when this =
happens.









 









RFC 4778 and the improvement that Martin Willi is proposing, are =
aimed
at solving this usability problem by informing the client software in =
advance
when the re-authentication needs to be done, and allowing them to
re-authenticate early enough, so that connections are not broken. The =
heuristic
does not affect the security or the IPsec =
streams.









 









Yoav









 















On Oct 18, 2008, at 2:35 AM, Gary Hemminger =
wrote:






















One comment on the heuristics
approach.  As a hardware vendor of L4-7 ADC boxes, I am a little =
concerned
about having to terminate IPSEC streams based on the heuristics =
approach,
because this is open ended.  What I mean is that the heuristic may =
be easy
to define now, but there is no certainty that it would remain this =
way. 
My past experience suggests that eventually the heuristic would become =
too
complex, and a well defined mechanism for determining which payload is
encrypted would need to be employed anyway.  =
 



While I like the idea of some =
“other”
box having to solve this issue, which prevents clients from having to be
changed, as we are a vendor of the “other” box, I think we =
should think about
the long term, not the short term.  Just my opinion, and I am =
certainly
flexible, but the heuristics approach worries me a =
bit.



 



Gary



 



[IPsec] Reauthentication extension for =
IKEv2



























Martin Willi =
writes:
> What do you think about such =
an extension? Already considered =
something
> similar, or does your =
reauthentication procedure work hassle-free? =
I'm
> wondering if we are the only =
ones facing these problems or if such =
an
> extension would gain broader =
acceptance...
 
The first question I have is why =
are you doing reauthentication =
at
all?
 
What is the benefits of the =
reauthentication?
 
What is the benefits of the =
reauthentication that can be done =
WITHOUT
user intervention (i.e. no user =
typing in password or pin code =
or
fingerprint or =
similar)?
 
I myself can only really see =
benefits from reauthentication when =
it
does require that user is really =
sitting there on the machine, =
and
gives something that the machine =
itself cannot give. In those =
cases
the user is required to type in =
something or do something =
anyways,
thus it does not really matter if =
the communications is =
interrupted
for second if user must stop his =
work for much longer time to type =
in
his passphrase or pin =
code.
 
The RFC 4478 simply skips this =
question and says "With some =
IPsec
peers, particularly in the remote =
access scenario, it is desirable =
to
repeat the mutual authentication =
periodically. The purpose of this =
is
to limit the time that security =
associations (SAs) can be used by =
a
third party who has gained =
control of the IPsec =
peer."
 
In most cases if third party has =
gained control of the IPsec peer =
he
will also get control of all =
authentication information inside =
the
peer, including private keys and =
pre shared keys. Only way to =
make
sure that he does not get access =
to those is to protect them =
with
passphrase, or pin code or =
similar that is only known by the =
user.
 
This is also said out in the RFC =
4478: "However, in the remote =
access
scenario it is usually up to a =
human user to supply the
authentication credentials =
..."
 
Because of this I do not think =
there is that much requirement =
for
reauthentication protocol that is =
faster than what we already have. =

-- =

kivinen at =
safenet-inc.com
__________________________________=
_____________
IPsec mailing =
list
IPsec at =
ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
 
 













    
 
  • Follow-Ups: =

    • 






    
 
      
  
        
   
      • From: Martin
       Willi
        • 
  
      
 
    




    
 
  • References: =

    • 






    
 
      
  
        
   
      • From: Martin
       Willi
        • 
  
      
 
    










Note: Messages sent to this list are the opinions of =
the
senders and do not imply endorsement by the =
IE






 













Scanned by Check Point Total Security Gateway. 



_______________________________________________

IPsec mailing list

IPsec@ietf.org

https://www.ietf.org=
/mailman/listinfo/ipsec









 













Scanned by Check Point Total Security Gateway. =










------=_NextPart_001_0181_01C9338F.0BA173C0--

------=_NextPart_000_0180_01C9338F.0B9F02C0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw
ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0
ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0
ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y
ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB
QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+
QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM
JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl
gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za
BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH
Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH
7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw
OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js
MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww
DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP
YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg
asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh
ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP
nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD
AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k
byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx
MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD
VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD
VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD
ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le
pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo
Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0
YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA
FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV
HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH
AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k
by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG
SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf
liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph
dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ
MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1
OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR
AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0
d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF
UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN
MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B
IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0
cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp
bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj
a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs
8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI
W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH
k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza
a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx
EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u
BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T
AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD
AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj
dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI
oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0
aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j
b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j
b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB
BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV
MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+
31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu
P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF
uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ
BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t
MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC
EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyMTEzMDk0MlowIwYJKoZIhvcNAQkEMRYEFCvaP31z7Y4Y
1xj+fy0GvYFHCqmfMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3
DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG
A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G
A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG
9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0
IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw
Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA
CWyKtTpcZxvr8+JmJnVll+TZMvdIZp47LkOYA8Voj0b8GiwhY5zIg/l3VhWm0vYJqF5kPrkYJFO7
X7SLT0pQtTISu81X+JHtPPNx9AtFNVIjSAEw1kkTZ33UDeLu3bJBuScWEz/f9jyGP5hhQR0jmzu8
0Zqs6n4prcmlbf9aL80uvRfJe7Bb3/Z+JbYcw7+X5qLEhaedQ9JQEuXjydUSBvUndXAtjE4tru0L
RtvdSgkiT29pTiwDX4Zq5gSrBwBxdDbNKLQifvBLiv3qd2aTqFoJxfqp0xOCW5sRL0NE7v/iZdoO
9p3s6Mm0O/NKNhX2TAh7Fz+f5pjCWJf2aWojoAAAAAAAAA==

------=_NextPart_000_0180_01C9338F.0B9F02C0--

--===============0309076203==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--===============0309076203==--


From ipsec-bounces@ietf.org  Tue Oct 21 06:53:53 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3EF2C3A6A0D;
	Tue, 21 Oct 2008 06:53:53 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 9CAC93A6869
	for ; Tue, 21 Oct 2008 06:53:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.452
X-Spam-Level: **
X-Spam-Status: No, score=2.452 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2,
	FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id tjZV43FLeWqI for ;
	Tue, 21 Oct 2008 06:53:47 -0700 (PDT)
Received: from mail.ritt.com.cn (unknown [211.167.85.58])
	by core3.amsl.com (Postfix) with SMTP id A25393A6916
	for ; Tue, 21 Oct 2008 06:53:46 -0700 (PDT)
X-MAILFROM: 
X-RCPTTO: 
X-FROMIP: 211.167.85.39
X-EQManager-Scaned: 1
X-Received: unknown,211.167.85.39,20081021215601
Received: from unknown (HELO mai.ritt.com.cn) (211.167.85.39)
	by localhost with SMTP; 21 Oct 2008 13:56:01 -0000
Received: from localhost ([127.0.0.1])
	by mai.ritt.com.cn (VisNetic.MailServer.v8.3.5.0) with SMTP id BXW12554
	for ; Tue, 21 Oct 2008 21:53:54 +0800
Date: Tue, 21 Oct 2008 21:53:54 +0800
From: =?GB2312?Q?=BA=FA=B2=B4?= 
To: ipsec@ietf.org
Message-ID: <6afe8a35524abc5561beb902d99d64c6@mail.ritt.com.cn>
X-Mailer: VisNetic WebMail 8.3.5.0
X-Originating-IP: 88.128.82.220
MIME-Version: 1.0
Subject: Re: [IPsec] Resuming the session resumption discussion
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Hello, Yoav,

Snip---

IKEv2 recommends short messages, but then goes on to include in the last IKE_AUTH packet the traffic selectors (which may include the entire protected networks), the configuration payload (which may also include the entire protected networks, but in a different format, certificates (which have no upper bound on size) and potentially even CRLs.  So that packet is already in danger of being too large, and adding a chunky payload like the ticket increases the likelihood of fragmentation.

As for the negative effects, there is obviously the problem of packet loss. In a high packet loss environment (wireless devices come to mind) if, say, 30% of packets get lost, 50% of 2-fragment packets will be lost, and 65% of 3-fragment packets. Also, as the IKEv2 document says, some operating systems will have a limit on assembly, as will some firewalls that reassemble fragments to inspect the packet in full.

In the early 2000's a lot of wireless access points, home routers, DSL modems and such were broken - they dropped all fragments, so any packet larger than the MTU was doomed to be dropped. Things were so bad, that my company had to invent a proprietary IKE-over-TCP just to get client connections working. This has vastly improved. Today most such equipment is working well, and fragments are passed through correctly. Operating systems in use today are also in better shape, and I can't think of any current version that won't handle UDP packets as large as the standards allow. Packet loss is still an issue, but for regular wired and wireless access, even most cellular, packet loss is reasonably low.

I admit that my experience may not be representative of all the world, but IMO some fragmentation is not as big a problem as it used to be.

Yoav

Snip--

sorry for my late reply, I am getting swamped with test recently,
I guess that your experience doesn't represent the huge world where doesn't use checkpoint product.
at least, I experienced too many fragment  configuration related issue based on my testing.
thanks for your explanation.

-Po 

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


From ipsec-bounces@ietf.org  Tue Oct 21 06:54:56 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D154D3A6995;
	Tue, 21 Oct 2008 06:54:56 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3959A3A6905
	for ; Tue, 21 Oct 2008 06:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.452
X-Spam-Level: **
X-Spam-Status: No, score=2.452 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2,
	FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id N4hY9trCEgEp for ;
	Tue, 21 Oct 2008 06:54:54 -0700 (PDT)
Received: from mail.ritt.com.cn (unknown [211.167.85.58])
	by core3.amsl.com (Postfix) with SMTP id B82863A6995
	for ; Tue, 21 Oct 2008 06:54:53 -0700 (PDT)
X-MAILFROM: 
X-RCPTTO: 
X-FROMIP: 211.167.85.39
X-EQManager-Scaned: 1
X-Received: unknown,211.167.85.39,20081021215708
Received: from unknown (HELO mai.ritt.com.cn) (211.167.85.39)
	by localhost with SMTP; 21 Oct 2008 13:57:08 -0000
Received: from localhost ([127.0.0.1])
	by mai.ritt.com.cn (VisNetic.MailServer.v8.3.5.0) with SMTP id BXY93700
	for ; Tue, 21 Oct 2008 21:55:00 +0800
Date: Tue, 21 Oct 2008 21:55:00 +0800
From: =?GB2312?Q?=BA=FA=B2=B4?= 
To: ipsec@ietf.org
Message-ID: <6e7120cfd5fb7308e023577d8a15f333@mail.ritt.com.cn>
X-Mailer: VisNetic WebMail 8.3.5.0
X-Originating-IP: 88.128.82.220
MIME-Version: 1.0
Subject: Re: [IPsec] Resuming the session resumption discussion
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Hello all

Based on the discuss in the mailing list, 
I don't like the potential Internet RFC has to been based on some propritary solution,
As far as my testing experience, most of product doesn't implement that part.
In that case, Stub based solution should be recommended other than ticket.

Thanks,

-Po



We now have revised drafts from the two parties who has published earlier drafts on session resumption. The (truncated) announcements are below.

The WG should start discussing what we want from session resumption and which of these two drafts (or what ideas from each of these two drafts) is of interest to the WG. As a reminder, I start off with what our charter says.

Extra points are awarded for not copying this entire message in your response. :-)

--Paul Hoffman

==========

- A standards-track extension that allows an IPsec remote access client
to "resume" a session with a gateway; that is, to skip certain parts of
IKE negotiation when connecting again to the same gateway (or possibly a
cluster of closely cooperating gateways). The idea is similar to TLS
session resumption without server-side state, specified in RFC 5077.

The main goals for this extension are to avoid public-key computations
(to reduce VPN gateway load when a large number of clients reconnect to
the gateway within a short period of time, such as following a network
outage), and remove the need for user interaction for authentication
(which may be required by some authentication mechanisms). The extension
shall not have negative impact on IKEv2 security features.

Failover from one gateway to another, mechanisms for detecting when a
session should be resumed, and specifying communication mechanisms
between gateways are beyond the scope of this work item. Specifying the
detailed contents of the "session ticket" is also beyond the scope of
this document; if there is sufficient interest, this could be specified
later in a separate document.

To the degree its content falls within the scope of this work item, text
and ideas from draft-sheffer-ipsec-failover will be used as a starting
point.

==========

At 9:17 PM +0800 10/7/08, Peny Yang wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>       Title           : IKEv2 SA Synchronization for session resumption
>       Author(s)       : Y. Xu, et al.
>       Filename        : draft-xu-ike-sa-sync-01.txt
>       Pages           : 18
>       Date            : 2008-10-07
>
>It will take a long time and mass computation to do session
>resumption among IKE/IPsec gateways possibly maintaining huge numbers
>of IKEv2/IPsec SAs, when the serving gateway fails or over-loaded.
>The major reason is that the prcocedure of IKEv2 SA re-establishment
>will incur a time-consuming computation especially in the Diffie-
>Hellman exchange.  In this draft, a new IKE security associations
>synchronization solution is proposed to do fast IKE SA session
>resumption by directly transferring the indexed IKE SA (named stub)
>from old gateway to new gateway, wherein the most expensive Diffie-
>Hellman calculation can be avoided.  Without some time-consuming
>IKEv2 exchanges, the huge amount of IKE/IPsec SA session resumption
>procedures can be finished in a short time.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-xu-ike-sa-sync-01.txt
>

At 10:09 AM -0700 10/7/08, Lakshminath Dondeti wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>       Title           : IKEv2 Session Resumption
>       Author(s)       : Y. Sheffer, et al.
>       Filename        : draft-tschofenig-ipsecme-ikev2-resumption-00.txt
>       Pages           : 19
>       Date            : 2008-10-01
>
>The Internet Key Exchange version 2 (IKEv2) protocol has a certain
>computational and communication overhead with respect to the number
>of round-trips required and the cryptographic operations involved.
>In remote access situations, the Extensible Authentication Protocol
>(EAP) is used for authentication, which adds several more round trips
>and consequently latency.
>
>To re-establish security associations (SA) upon a failure recovery
>condition is time consuming, especially when an IPsec peer, such as a
>VPN gateway, needs to re-establish a large number of SAs with various
>end points.  A high number of concurrent sessions might cause
>additional problems for an IPsec peer during SA re-establishment.
>
>In order to avoid the need to re-run the key exchange protocol from
>scratch it would be useful to provide an efficient way to resume an
>IKE/IPsec session.  This document proposes an extension to IKEv2 that
>allows a client to re-establish an IKE SA with a gateway in a highly
>efficient manner, utilizing a previously established IKE SA.
>
>A client can reconnect to a gateway from which it was disconnected.
>The proposed approach uses a ticket to store state information that
>is later made available to the IKEv2 responder for re-authentication.
>Restoring state information by utilizing a ticket, although the
>format is not specified in this document, is one possible way.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-tschofenig-ipsecme-ikev2-resumption-00.txt

--Paul Hoffman, Director
--VPN Consortium 

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


From ipsec-bounces@ietf.org  Tue Oct 21 08:32:11 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A5AA63A68F0;
	Tue, 21 Oct 2008 08:32:11 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D29123A6A44
	for ; Tue, 21 Oct 2008 02:45:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.57
X-Spam-Level: 
X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 
	BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id j2mxuvLRzQIy for ;
	Tue, 21 Oct 2008 02:45:01 -0700 (PDT)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130])
	by core3.amsl.com (Postfix) with ESMTP id 003213A68F0
	for ; Tue, 21 Oct 2008 02:45:01 -0700 (PDT)
Received: from smtp.piuha.net (localhost [127.0.0.1])
	by smtp.piuha.net (Postfix) with ESMTP id 3CE7219868A;
	Tue, 21 Oct 2008 12:46:14 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130])
	by smtp.piuha.net (Postfix) with ESMTP id F099519863B;
	Tue, 21 Oct 2008 12:46:13 +0300 (EEST)
Message-ID: <48FDA520.4060101@piuha.net>
Date: Tue, 21 Oct 2008 12:47:12 +0300
From: Jari Arkko 
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: "Kumar, Sunil" 
References: <7A581A93408E68408DB73274370D78D372BCED@NOI1EXCH002.sfnt.local>
In-Reply-To: <7A581A93408E68408DB73274370D78D372BCED@NOI1EXCH002.sfnt.local>
X-Virus-Scanned: ClamAV using ClamSMTP
X-Mailman-Approved-At: Tue, 21 Oct 2008 08:32:11 -0700
Cc: ipsec@ietf.org, "Pal, Yogendra" 
Subject: Re: [IPsec] EAP-AKA' draft queries.
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

These are literal strings fed as input to the PRF.

Jari

Kumar, Sunil wrote:
>
> Hi Arkko,
>
>  
>
> We were going through the details of the new variant of EAP-AKA in 
> IETF drafts
> and found your draft of EAP-AKA' (draft-arkko-eap-aka-kdf-xx.txt)
>
> We have few queries related to the same
>
>
>  Referring to the section 3.3 of draft, during full authentication 
> process,
>       MK is derived as follows:
>
>       MK = PRF' ( IK' | CK' , "EAP-AKA' " | Identity )
>
> *Ques1*  What is the value of the *"EAP-AKA' "* in above MK 
> derivation? As there is no proposed value or description is available 
> in the draft document.
>
>     When we are considering the case of fast re-authentication process,
>
>     MK is derived as follows:
>     MK = PRF' (K_re, "EAP-AKA'  re-auth" | Identity | Counter | NONCE_S)
>
> *Ques 2*   What is the value of the *"EAP-AKA'  re-auth"* in above MK 
> generation? Similarly here also there is no proposed value or 
> description is available.
>
>  
>
> Thanks and Regards,
>
> Sunil / Yogendra
>
> The information contained in this electronic mail transmission 
> may be privileged and confidential, and therefore, protected 
> from disclosure. If you have received this communication in 
> error, please notify us immediately by replying to this 
> message and deleting it from your computer without copying 
> or disclosing it.
>
>
>   

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


From ipsec-bounces@ietf.org  Tue Oct 21 10:01:26 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 649D928C0FC;
	Tue, 21 Oct 2008 10:01:26 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 5A7023A6B1A
	for ; Tue, 21 Oct 2008 10:01:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.358
X-Spam-Level: 
X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id ajlzoZ6i4Nrh for ;
	Tue, 21 Oct 2008 10:01:12 -0700 (PDT)
Received: from malawi.foundrynet.com (malawi.foundrynet.com [63.236.63.253])
	by core3.amsl.com (Postfix) with ESMTP id 8DC423A6B76
	for ; Tue, 21 Oct 2008 10:01:02 -0700 (PDT)
Received: from smtp1gap.foundrynet.com (unknown [10.101.103.18])
	by malawi.foundrynet.com (Postfix) with ESMTP id 0E617166834
	for ; Tue, 21 Oct 2008 10:02:17 -0700 (PDT)
Received: from xmail.ds.foundrynet.com (unknown [10.101.218.254])
	by smtp1gap.foundrynet.com (Postfix) with ESMTP id B39013E0001;
	Tue, 21 Oct 2008 10:02:03 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 21 Oct 2008 10:01:30 -0700
Message-ID: 
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Identifying encrypted traffic (was: [IPsec] Reauthentication
	extension for IKEv2)
Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkhACbyvnAACETf8A==
References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com>
	
	<7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com>
From: "Gary Hemminger" 
To: "Yaron Sheffer" , "Yoav Nir" 
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication
	extension for IKEv2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2077490842=="
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

This is a multi-part message in MIME format.

--===============2077490842==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C9339E.AA54EFEE"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C9339E.AA54EFEE
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

The use case you are thinking about is probably pure IPsec VPN, where an
encrypted stream only lives across the WAN.  But what if you are a load
balancer and the IPsec traffic is end to end?  In this case, you may
have a load balancer that needs to terminate the traffic so it can make
the decision which server to handle the request.  All load balancers
today support SSL termination.  Same thing applies to IPsec traffic.  We
cannot make the decision which server to handle the request, nor can we
maintain persistence without decrypting the traffic. =20

=20

Gary

=20

From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20
Sent: Tuesday, October 21, 2008 6:10 AM
To: Gary Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication
extension for IKEv2)

=20

Hi Gary,

=20

I'm puzzled by the scenario you are presenting. I've been considering
the work on ESP-null detection (e.g.
draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that
want to look at the IPsec-protected traffic, but do NOT want to
terminate IPsec (i.e. decapsulate the traffic). In general, if you can
terminate IPsec, that means that you have access to the encryption keys
and you can easily differentiate protected and unprotected traffic, Can
you explain the use case that you have in mind?

=20

Thanks,

            Yaron

=20

________________________________

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
Of Gary Hemminger
Sent: Monday, October 20, 2008 20:26
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for IKEv2

=20

I was talking about how to make the determination that the payload is
encrypted.  Evidently there are two approaches:  one based on a
heuristic, another based on a payload wrapper that flags the payload is
encrypted.  We would need some mechanism to determine the payload is
encryped if we need to terminate the IPSEC traffic and make a
determination of which server to send it to.  Sorry about the confusion.

=20

Gary

=20

________________________________

From: Yoav Nir [mailto:ynir@checkpoint.com]
Sent: Sat 10/18/2008 2:03 PM
To: Gary Hemminger
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for IKEv2

Hi Gary.=20

=20

I'm not sure what heuristics you are talking about. The problem of
re-authentication is simply this. The owner of the remote access gateway
has a security policy that says that connections can be open for only so
long (say, 2 hours) without authenticating the user again. This is a
favorite requirement by auditors, who believe that this is an important
part of risk management. If somebody steals your laptop (or mobile
phone) or sits down at the Internet Cafe station where you were logged
on, we want to limit the amount of time they are connected to the
internal network. This requirement makes sense if the user has to type
in their password to authenticate. It makes less sense if there are user
certificates that are stored on the computer, or if the client software
has a "save password" feature.

=20

Whether it makes sense or not, this is a requirement by auditors and
regulators. If the user does not re-authenticate within the specified
time, the IKE SA and all dependent child SAs are deleted.  This creates
a usability problem, because the SA is deleted without any advance
warning to the user, so the user is likely to get a relatively long time
with no connectivity. This can break TCP connections such as FTP, HTTP,
and IMAP. Outlook tends to make accounts permanently offline when this
happens.

=20

RFC 4778 and the improvement that Martin Willi is proposing, are aimed
at solving this usability problem by informing the client software in
advance when the re-authentication needs to be done, and allowing them
to re-authenticate early enough, so that connections are not broken. The
heuristic does not affect the security or the IPsec streams.

=20

Yoav

=20

On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote:

=20


One comment on the heuristics approach.  As a hardware vendor of L4-7
ADC boxes, I am a little concerned about having to terminate IPSEC
streams based on the heuristics approach, because this is open ended.
What I mean is that the heuristic may be easy to define now, but there
is no certainty that it would remain this way.  My past experience
suggests that eventually the heuristic would become too complex, and a
well defined mechanism for determining which payload is encrypted would
need to be employed anyway.  =20


While I like the idea of some "other" box having to solve this issue,
which prevents clients from having to be changed, as we are a vendor of
the "other" box, I think we should think about the long term, not the
short term.  Just my opinion, and I am certainly flexible, but the
heuristics approach worries me a bit.


=20


Gary


=20


[IPsec] Reauthentication extension for IKEv2

________________________________


*	To: Martin Willi  >=20
*	Subject: [IPsec] Reauthentication extension for IKEv2=20
*	From: Tero Kivinen  >=20
*	Date: Tue, 16 Sep 2008 12:09:14 +0300=20
*	Cc: ipsec at ietf.org  =20
*	Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com
 =20
*	Delivered-to: ipsec at core3.amsl.com
 =20
*	In-reply-to: <48CF5D7D.7070701 at strongswan.org
 >=20
*	List-archive: =20
*	List-help: =20
*	List-id: Discussion of IPsec protocols =20
*	List-post: =20
*	List-subscribe: ,
=20
*	List-unsubscribe: ,
=20
*	References: <48CF5D7D.7070701 at strongswan.org
 >=20
*	Sender: ipsec-bounces at ietf.org
=20

________________________________

Martin Willi writes:
> What do you think about such an extension? Already considered
something
> similar, or does your reauthentication procedure work hassle-free? I'm
> wondering if we are the only ones facing these problems or if such an
> extension would gain broader acceptance...
=20
The first question I have is why are you doing reauthentication at
all?
=20
What is the benefits of the reauthentication?
=20
What is the benefits of the reauthentication that can be done WITHOUT
user intervention (i.e. no user typing in password or pin code or
fingerprint or similar)?
=20
I myself can only really see benefits from reauthentication when it
does require that user is really sitting there on the machine, and
gives something that the machine itself cannot give. In those cases
the user is required to type in something or do something anyways,
thus it does not really matter if the communications is interrupted
for second if user must stop his work for much longer time to type in
his passphrase or pin code.
=20
The RFC 4478 simply skips this question and says "With some IPsec
peers, particularly in the remote access scenario, it is desirable to
repeat the mutual authentication periodically. The purpose of this is
to limit the time that security associations (SAs) can be used by a
third party who has gained control of the IPsec peer."
=20
In most cases if third party has gained control of the IPsec peer he
will also get control of all authentication information inside the
peer, including private keys and pre shared keys. Only way to make
sure that he does not get access to those is to protect them with
passphrase, or pin code or similar that is only known by the user.
=20
This is also said out in the RFC 4478: "However, in the remote access
scenario it is usually up to a human user to supply the
authentication credentials ..."
=20
Because of this I do not think there is that much requirement for
reauthentication protocol that is faster than what we already have.=20
--=20
kivinen at safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
=20
=20
________________________________


*	Follow-Ups:=20

	*	Re: [IPsec] Reauthentication extension for IKEv2
 =20

		*	From: Martin Willi

*	References:=20

	*	[IPsec] Reauthentication extension for IKEv2
 =20

		*	From: Martin Willi

*	Prev by Date: [IPsec] Reauthentication extension for IKEv2
 =20
*	Next by Date: Re: [IPsec] Reauthentication extension for IKEv2
 =20
*	Previous by thread: [IPsec] Reauthentication extension for IKEv2
 =20
*	Next by thread: Re: [IPsec] Reauthentication extension for IKEv2
 =20
*	Index(es):=20

	*	Date


	*	Thread
=20


Note: Messages sent to this list are the opinions of the senders and do
not imply endorsement by the IE


=20



Scanned by Check Point Total Security Gateway.=20

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

=20



Scanned by Check Point Total Security Gateway.=20


------_=_NextPart_001_01C9339E.AA54EFEE
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

















The use case you are thinking about is probably pure =
IPsec VPN,
where an encrypted stream only lives across the WAN.  But what if =
you are a
load balancer and the IPsec traffic is end to end?  In this case, =
you may have
a load balancer that needs to terminate the traffic so it can make the =
decision
which server to handle the request.  All load balancers today =
support SSL
termination.  Same thing applies to IPsec traffic.  We cannot =
make the decision
which server to handle the request, nor can we maintain persistence =
without
decrypting the traffic.  



 



Gary



 









From:=
 Yaron =
Sheffer
[mailto:yaronf@checkpoint.com] 

Sent: Tuesday, October 21, 2008 6:10 AM

To: Gary Hemminger; Yoav Nir

Cc: ipsec@ietf.org

Subject: Identifying encrypted traffic (was: [IPsec] =
Reauthentication
extension for IKEv2)









 



Hi Gary,



 



I’m puzzled by the scenario you are presenting. =
I’ve been
considering the work on ESP-null detection (e.g.
draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that =
want
to look at the IPsec-protected traffic, but do NOT want to terminate =
IPsec
(i.e. decapsulate the traffic). In general, if you can terminate IPsec, =
that
means that you have access to the encryption keys and you can easily
differentiate protected and unprotected traffic, Can you explain the use =
case
that you have in mind?



 



Thanks,



          &=
nbsp;
Yaron



 















From:=

ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of =
Gary
Hemminger

Sent: Monday, October 20, 2008 20:26

To: Yoav Nir

Cc: ipsec@ietf.org

Subject: Re: [IPsec] Reauthentication extension for =
IKEv2






 









I was talking about how to make the determination that the =
payload
is encrypted.  Evidently there are two approaches:  one based =
on a
heuristic, another based on a payload wrapper that flags the payload is
encrypted.  We would need some mechanism to determine the payload =
is
encryped if we need to terminate the IPSEC traffic and make a =
determination of
which server to send it to.  Sorry about the =
confusion.









 









Gary












 












From: Yoav Nir =
[mailto:ynir@checkpoint.com]

Sent: Sat 10/18/2008 2:03 PM

To: Gary Hemminger

Cc: ipsec@ietf.org

Subject: Re: [IPsec] Reauthentication extension for =
IKEv2









Hi Gary. 






 









I'm not sure what heuristics you are talking about. =
The
problem of re-authentication is simply this. The owner of the remote =
access
gateway has a security policy that says that connections can be open for =
only
so long (say, 2 hours) without authenticating the user again. This is a
favorite requirement by auditors, who believe that this is an important =
part of
risk management. If somebody steals your laptop (or mobile phone) or =
sits down
at the Internet Cafe station where you were logged on, we want to limit =
the
amount of time they are connected to the internal network. This =
requirement
makes sense if the user has to type in their password to authenticate. =
It makes
less sense if there are user certificates that are stored on the =
computer, or
if the client software has a "save password" =
feature.









 









Whether it makes sense or not, this is a =
requirement by
auditors and regulators. If the user does not re-authenticate within the
specified time, the IKE SA and all dependent child SAs are =
deleted.
 This creates a usability problem, because the SA is deleted =
without any
advance warning to the user, so the user is likely to get a relatively =
long
time with no connectivity. This can break TCP connections such as FTP, =
HTTP,
and IMAP. Outlook tends to make accounts permanently offline when this =
happens.









 









RFC 4778 and the improvement that Martin Willi is =
proposing,
are aimed at solving this usability problem by informing the client =
software in
advance when the re-authentication needs to be done, and allowing them =
to
re-authenticate early enough, so that connections are not broken. The =
heuristic
does not affect the security or the IPsec streams.









 









Yoav









 















On Oct 18, 2008, at 2:35 AM, Gary Hemminger =
wrote:






 









One =
comment
on the heuristics approach.  As a hardware vendor of L4-7 ADC =
boxes, I am
a little concerned about having to terminate IPSEC streams based on the
heuristics approach, because this is open ended.  What I mean is =
that the
heuristic may be easy to define now, but there is no certainty that it =
would
remain this way.  My past experience suggests that eventually the
heuristic would become too complex, and a well defined mechanism for
determining which payload is encrypted would need to be employed =
anyway. 
 



While I like
the idea of some “other” box having to solve this issue, =
which prevents clients
from having to be changed, as we are a vendor of the “other” =
box, I think we
should think about the long term, not the short term.  Just my =
opinion,
and I am certainly flexible, but the heuristics approach worries me a =
bit.



 



Gary



 



[IPsec] Reauthentication extension for =
IKEv2



























Martin Willi =
writes:
> What do you think about such an extension? =
Already considered something
> similar, or does your reauthentication =
procedure work hassle-free? I'm
> wondering if we are the only ones facing =
these problems or if such an
> extension would gain broader =
acceptance...
 
The first question I have is why are you doing =
reauthentication at
all?
 
What is the benefits of the =
reauthentication?
 
What is the benefits of the reauthentication that =
can be done WITHOUT
user intervention (i.e. no user typing in password =
or pin code or
fingerprint or =
similar)?
 
I myself can only really see benefits from =
reauthentication when it
does require that user is really sitting there on =
the machine, and
gives something that the machine itself cannot =
give. In those cases
the user is required to type in something or do =
something anyways,
thus it does not really matter if the =
communications is interrupted
for second if user must stop his work for much =
longer time to type in
his passphrase or pin =
code.
 
The RFC 4478 simply skips this question and says =
"With some IPsec
peers, particularly in the remote access scenario, =
it is desirable to
repeat the mutual authentication periodically. The =
purpose of this is
to limit the time that security associations (SAs) =
can be used by a
third party who has gained control of the IPsec =
peer."
 
In most cases if third party has gained control of =
the IPsec peer he
will also get control of all authentication =
information inside the
peer, including private keys and pre shared keys. =
Only way to make
sure that he does not get access to those is to =
protect them with
passphrase, or pin code or similar that is only =
known by the user.
 
This is also said out in the RFC 4478: =
"However, in the remote access
scenario it is usually up to a human user to =
supply the
authentication credentials =
..."
 
Because of this I do not think there is that much =
requirement for
reauthentication protocol that is faster than what =
we already have. 
-- 
kivinen at =
safenet-inc.com
_______________________________________________
IPsec mailing =
list
IPsec at =
ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
 
 














    
 
  • Follow-Ups<=
/span>: =

    • 






    
 
      
  
        
   
      • From: Martin =
Willi
        • 
  
      
 
    




    
 
  • References<=
/span>: =

    • 






    
 
      
  
        
   
      • From: Martin =
Willi
        • 
  
      
 
    










Note: Messages sent to this list are the =
opinions
of the senders and do not imply endorsement by the =
IE






 













Scanned by Check Point Total Security Gateway. 



_______________________________________________

IPsec mailing list

IPsec@ietf.org

https://www.ietf.org=
/mailman/listinfo/ipsec









 













Scanned by Check Point Total Security Gateway. 









------_=_NextPart_001_01C9339E.AA54EFEE--

--===============2077490842==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--===============2077490842==--


From ipsec-bounces@ietf.org  Tue Oct 21 13:36:03 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 56F7B3A6A95;
	Tue, 21 Oct 2008 13:36:03 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D727C28C191
	for ; Tue, 21 Oct 2008 13:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.971
X-Spam-Level: 
X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5
	tests=[AWL=-0.614, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001,
	HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id vb7AFir3Lae8 for ;
	Tue, 21 Oct 2008 13:35:50 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54])
	by core3.amsl.com (Postfix) with ESMTP id AACBE3A68D3
	for ; Tue, 21 Oct 2008 13:35:49 -0700 (PDT)
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105)
	id EE439294005; Tue, 21 Oct 2008 22:37:03 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68])
	by dlpdemo.checkpoint.com (Postfix) with ESMTP id CDB07294003;
	Tue, 21 Oct 2008 22:37:01 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1])
	by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id
	m9LKaxke016438; Tue, 21 Oct 2008 22:37:00 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by
	il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 21 Oct 2008
	22:36:59 +0200
From: Yaron Sheffer 
To: Gary Hemminger , Yoav Nir 
Date: Tue, 21 Oct 2008 22:36:52 +0200
Thread-Topic: Identifying encrypted traffic (was: [IPsec] Reauthentication
	extension for IKEv2)
Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkhACbyvnAACETf8AAHhWiA
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com>
References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com>
	
	<7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com>
	
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication
 extension for IKEv2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1336376059=="
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

--===============1336376059==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0191_01C933CD.837FC1B0"

------=_NextPart_000_0191_01C933CD.837FC1B0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0192_01C933CD.837FC1B0"


------=_NextPart_001_0192_01C933CD.837FC1B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

OK. But if your load balancer is able to decrypt the traffic (i.e. it has
the credentials or secret keys), then it can do that with today's normal
IKE/IPsec. There is no need in this case to modify the protocol to make it
easier to detect encrypted traffic.

 

Thanks,

            Yaron

 

  _____  

From: Gary Hemminger [mailto:ghemminger@foundrynet.com] 
Sent: Tuesday, October 21, 2008 19:02
To: Yaron Sheffer; Yoav Nir
Cc: ipsec@ietf.org
Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication
extension for IKEv2)

 

The use case you are thinking about is probably pure IPsec VPN, where an
encrypted stream only lives across the WAN.  But what if you are a load
balancer and the IPsec traffic is end to end?  In this case, you may have a
load balancer that needs to terminate the traffic so it can make the
decision which server to handle the request.  All load balancers today
support SSL termination.  Same thing applies to IPsec traffic.  We cannot
make the decision which server to handle the request, nor can we maintain
persistence without decrypting the traffic.  

 

Gary

 

From: Yaron Sheffer [mailto:yaronf@checkpoint.com] 
Sent: Tuesday, October 21, 2008 6:10 AM
To: Gary Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication
extension for IKEv2)

 

Hi Gary,

 

I'm puzzled by the scenario you are presenting. I've been considering the
work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01)
as useful for middleboxes that want to look at the IPsec-protected traffic,
but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In
general, if you can terminate IPsec, that means that you have access to the
encryption keys and you can easily differentiate protected and unprotected
traffic, Can you explain the use case that you have in mind?

 

Thanks,

            Yaron

 

  _____  

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of
Gary Hemminger
Sent: Monday, October 20, 2008 20:26
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for IKEv2

 

I was talking about how to make the determination that the payload is
encrypted.  Evidently there are two approaches:  one based on a heuristic,
another based on a payload wrapper that flags the payload is encrypted.  We
would need some mechanism to determine the payload is encryped if we need to
terminate the IPSEC traffic and make a determination of which server to send
it to.  Sorry about the confusion.

 

Gary

 

  _____  

From: Yoav Nir [mailto:ynir@checkpoint.com]
Sent: Sat 10/18/2008 2:03 PM
To: Gary Hemminger
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for IKEv2

Hi Gary. 

 

I'm not sure what heuristics you are talking about. The problem of
re-authentication is simply this. The owner of the remote access gateway has
a security policy that says that connections can be open for only so long
(say, 2 hours) without authenticating the user again. This is a favorite
requirement by auditors, who believe that this is an important part of risk
management. If somebody steals your laptop (or mobile phone) or sits down at
the Internet Cafe station where you were logged on, we want to limit the
amount of time they are connected to the internal network. This requirement
makes sense if the user has to type in their password to authenticate. It
makes less sense if there are user certificates that are stored on the
computer, or if the client software has a "save password" feature.

 

Whether it makes sense or not, this is a requirement by auditors and
regulators. If the user does not re-authenticate within the specified time,
the IKE SA and all dependent child SAs are deleted.  This creates a
usability problem, because the SA is deleted without any advance warning to
the user, so the user is likely to get a relatively long time with no
connectivity. This can break TCP connections such as FTP, HTTP, and IMAP.
Outlook tends to make accounts permanently offline when this happens.

 

RFC 4778 and the improvement that Martin Willi is proposing, are aimed at
solving this usability problem by informing the client software in advance
when the re-authentication needs to be done, and allowing them to
re-authenticate early enough, so that connections are not broken. The
heuristic does not affect the security or the IPsec streams.

 

Yoav

 

On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote:

 


One comment on the heuristics approach.  As a hardware vendor of L4-7 ADC
boxes, I am a little concerned about having to terminate IPSEC streams based
on the heuristics approach, because this is open ended.  What I mean is that
the heuristic may be easy to define now, but there is no certainty that it
would remain this way.  My past experience suggests that eventually the
heuristic would become too complex, and a well defined mechanism for
determining which payload is encrypted would need to be employed anyway.   


While I like the idea of some "other" box having to solve this issue, which
prevents clients from having to be changed, as we are a vendor of the
"other" box, I think we should think about the long term, not the short
term.  Just my opinion, and I am certainly flexible, but the heuristics
approach worries me a bit.


 


Gary


 


[IPsec] Reauthentication extension for IKEv2

  _____  


*	To: Martin Willi 
strongswan.org> 
*	Subject: [IPsec] Reauthentication extension for IKEv2 
*	From: Tero Kivinen 
> 
*	Date: Tue, 16 Sep 2008 12:09:14 +0300 
*	Cc: ipsec at ietf.org   
*	Delivered-to: ietfarch-ipsec-web-archive
  at core3.amsl.com 
*	Delivered-to: ipsec at core3.amsl.com   
*	In-reply-to: <48CF5D7D.7070701 at
  strongswan.org> 
*	List-archive:  
*	List-help:  
*	List-id: Discussion of IPsec protocols  
*	List-post:  
*	List-subscribe: ,
 
*	List-unsubscribe: ,
 
*	References: <48CF5D7D.7070701 at
  strongswan.org> 
*	Sender: ipsec-bounces at ietf.org
 

  _____  

Martin Willi writes:
> What do you think about such an extension? Already considered something
> similar, or does your reauthentication procedure work hassle-free? I'm
> wondering if we are the only ones facing these problems or if such an
> extension would gain broader acceptance...
 
The first question I have is why are you doing reauthentication at
all?
 
What is the benefits of the reauthentication?
 
What is the benefits of the reauthentication that can be done WITHOUT
user intervention (i.e. no user typing in password or pin code or
fingerprint or similar)?
 
I myself can only really see benefits from reauthentication when it
does require that user is really sitting there on the machine, and
gives something that the machine itself cannot give. In those cases
the user is required to type in something or do something anyways,
thus it does not really matter if the communications is interrupted
for second if user must stop his work for much longer time to type in
his passphrase or pin code.
 
The RFC 4478 simply skips this question and says "With some IPsec
peers, particularly in the remote access scenario, it is desirable to
repeat the mutual authentication periodically. The purpose of this is
to limit the time that security associations (SAs) can be used by a
third party who has gained control of the IPsec peer."
 
In most cases if third party has gained control of the IPsec peer he
will also get control of all authentication information inside the
peer, including private keys and pre shared keys. Only way to make
sure that he does not get access to those is to protect them with
passphrase, or pin code or similar that is only known by the user.
 
This is also said out in the RFC 4478: "However, in the remote access
scenario it is usually up to a human user to supply the
authentication credentials ..."
 
Because of this I do not think there is that much requirement for
reauthentication protocol that is faster than what we already have. 
-- 
kivinen at safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
 
 
  _____  


*	Follow-Ups: 

*	 
Re: [IPsec] Reauthentication extension for IKEv2 

*	From: Martin Willi

*	References: 

*	 
[IPsec] Reauthentication extension for IKEv2 

*	From: Martin Willi

*	Prev by Date: [IPsec]

Reauthentication extension for IKEv2 
*	Next by Date: Re:
  [IPsec]
Reauthentication extension for IKEv2 
*	Previous by thread: [IPsec]

Reauthentication extension for IKEv2 
*	Next by thread: Re:
  [IPsec]
Reauthentication extension for IKEv2 
*	Index(es): 

*

Date 
*

Thread


Note: Messages sent to this list are the opinions of the senders and do not
imply endorsement by the IE


 



Scanned by Check Point Total Security Gateway. 

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

 



Scanned by Check Point Total Security Gateway. 


------=_NextPart_001_0192_01C933CD.837FC1B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable






















------=_NextPart_001_0192_01C933CD.837FC1B0--

------=_NextPart_000_0191_01C933CD.837FC1B0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw
ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0
ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0
ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y
ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx
EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB
QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+
QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM
JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl
gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za
BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH
Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH
7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw
OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js
MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww
DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP
YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg
asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh
ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP
nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD
AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k
byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx
MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD
VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD
VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD
ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le
pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo
Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0
YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA
FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV
HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH
AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k
by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG
SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf
liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph
dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ
MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1
OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR
AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI
EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0
d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF
UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN
MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B
IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0
cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp
bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj
a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs
8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI
W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH
k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza
a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx
EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u
BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T
AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD
AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj
dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv
Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI
oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0
aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j
b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j
b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB
BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV
MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+
31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu
P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF
uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ
BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT
FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t
MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC
EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyMTIwMzY1MlowIwYJKoZIhvcNAQkEMRYEFDRWglJFxP28
aBXcxxHS53QPV4gOMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA
MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3
DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG
A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G
A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs
aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG
9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0
IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw
Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl
bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA
KXtr9nzpHodv+JXuXX2R1Ijb9qNDNPjHOWExL08ZLNME5hYrXi2cc4OmwmT6z//ZtOCUr+59lLlj
jZwBD1I0eWIQa6dJPAWPvUfT+0q4LNLQiWkk0b34EZfp5hBi++1Mcqvuy1hTeqENbOAFIPERYdg2
gcLMX1V0rwknkObJUAl3zcv9g1SFYmtiz+WnC+99em7PQAwhrfUL4KFHDBhgPQZIe0wQ3PVydjw9
l69UfbxsMiW7MZZrGsmqZ2E2a6/AFWQ9B4hVJRR1syp2xNMxB1b2AASLtc0iGv5S1iuraNhgyrt2
Zy1j/OAFlA2YrSA9aruA2PE2Nju7kcq7VAMMIgAAAAAAAA==

------=_NextPart_000_0191_01C933CD.837FC1B0--

--===============1336376059==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--===============1336376059==--


From ipsec-bounces@ietf.org  Tue Oct 21 14:55:39 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 1B7A03A6BAE;
	Tue, 21 Oct 2008 14:55:39 -0700 (PDT)
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id C6B3F3A6BA4
	for ; Tue, 21 Oct 2008 14:55:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.357
X-Spam-Level: 
X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001,
	HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id aqHRV+-+kpmA for ;
	Tue, 21 Oct 2008 14:55:22 -0700 (PDT)
Received: from mga03.intel.com (mga03.intel.com [143.182.124.21])
	by core3.amsl.com (Postfix) with ESMTP id 4DA9B3A6BB4
	for ; Tue, 21 Oct 2008 14:55:22 -0700 (PDT)
Received: from azsmga001.ch.intel.com ([10.2.17.19])
	by azsmga101.ch.intel.com with ESMTP; 21 Oct 2008 14:56:13 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.33,460,1220252400"; d="scan'208,217";a="63303981"
Received: from unknown (HELO azsmsx001.amr.corp.intel.com) ([10.2.167.98])
	by azsmga001.ch.intel.com with ESMTP; 21 Oct 2008 14:56:13 -0700
Received: from rrsmsx602.amr.corp.intel.com (10.31.0.33) by
	azsmsx001.amr.corp.intel.com (10.2.167.98) with Microsoft SMTP Server
	(TLS) id 8.1.291.1; Tue, 21 Oct 2008 14:56:13 -0700
Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by
	rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Tue, 21 Oct 2008
	15:56:12 -0600
From: "Grewal, Ken" 
To: Yaron Sheffer , Gary Hemminger
	, Yoav Nir 
Date: Tue, 21 Oct 2008 15:55:39 -0600
Thread-Topic: [IPsec] Identifying encrypted traffic (was: Reauthentication
	extension for IKEv2)
Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkhACbyvnAACETf8AAHhWiAAAKQj8A=
Message-ID: 
References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com>
	
	<7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com>
	
	<7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com>
In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "ipsec@ietf.org" 
Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication
 extension for IKEv2)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1955882027=="
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

--===============1955882027==
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_A1E36B4547AAF443BEA10955A159923B0881D190rrsmsx505amrcor_"

--_000_A1E36B4547AAF443BEA10955A159923B0881D190rrsmsx505amrcor_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Some observations below:


 1.  I agree with Yaron in that if a load balancer needs to 'terminate' the=
 traffic before applying any rules to distribute the load, then it should h=
ave the keys to do so without any modifications to the current protocol. In=
 this case, the session setup (via IKE) should have been negotiated with th=
e load balancer and it is the natural termination point of the IPsec SA. Th=
e load balancer is essentially acting as a VPN gateway for tunnel mode or s=
ome kind of front end proxy to the multiple servers behind it in transport =
mode.
 2.  My understanding of a 'pure' load balancer is that it distributes traf=
fic streams to different resources available to it and this is typically ba=
sed on rules such as source / destination IP protocols, ports (e.g. TCP por=
ts) and potentially some other information. Furthermore, as some of the upp=
er layer protocols are stateful (e.g. TCP), it is desirable for the load ba=
lancer to ensure that a higher layer 'session' (e.g. TCP session) is 'pegge=
d' to a resource (server) that has been handling the same session - this al=
lows efficient state maintenance on a given resource / server, instead of a=
ll resources needing access to that state. Now if the traffic is protected =
using IPsec, then the load balancer needs access to upper layer payload dat=
a in the packet in order to apply the aforementioned rules for load balanci=
ng decisions. The charter item on traffic visibility provides for a clean s=
olution where the load-balancer (as well as other network monitoring tools)=
 is able to ascertain that the packet if not encrypted and hence look insid=
e the packet to analyze the protocol / ports to make load balancing decisio=
ns. In this case, IPsec is still being terminated on the server behind the =
load balancer, but the load balancer can examine the IPsec protected packet=
 en-route to ensure it gets to the right server. In essence, this charter i=
tem allows the load balancer (and other network tools) to continue to funct=
ion in IPsec environments.
 3.  I agree with Gary on his observations about heuristics as being comple=
x in HW, undeterministic and the associated parsing rules liable to change =
based on new protocols / payloads.

Thanks,
- Ken

________________________________
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y=
aron Sheffer
Sent: Tuesday, October 21, 2008 1:37 PM
To: Gary Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication e=
xtension for IKEv2)

OK. But if your load balancer is able to decrypt the traffic (i.e. it has t=
he credentials or secret keys), then it can do that with today's normal IKE=
/IPsec. There is no need in this case to modify the protocol to make it eas=
ier to detect encrypted traffic.

Thanks,
            Yaron

________________________________
From: Gary Hemminger [mailto:ghemminger@foundrynet.com]
Sent: Tuesday, October 21, 2008 19:02
To: Yaron Sheffer; Yoav Nir
Cc: ipsec@ietf.org
Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication e=
xtension for IKEv2)

The use case you are thinking about is probably pure IPsec VPN, where an en=
crypted stream only lives across the WAN.  But what if you are a load balan=
cer and the IPsec traffic is end to end?  In this case, you may have a load=
 balancer that needs to terminate the traffic so it can make the decision w=
hich server to handle the request.  All load balancers today support SSL te=
rmination.  Same thing applies to IPsec traffic.  We cannot make the decisi=
on which server to handle the request, nor can we maintain persistence with=
out decrypting the traffic.

Gary

From: Yaron Sheffer [mailto:yaronf@checkpoint.com]
Sent: Tuesday, October 21, 2008 6:10 AM
To: Gary Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication exten=
sion for IKEv2)

Hi Gary,

I'm puzzled by the scenario you are presenting. I've been considering the w=
ork on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) a=
s useful for middleboxes that want to look at the IPsec-protected traffic, =
but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In gener=
al, if you can terminate IPsec, that means that you have access to the encr=
yption keys and you can easily differentiate protected and unprotected traf=
fic, Can you explain the use case that you have in mind?

Thanks,
            Yaron

________________________________
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of G=
ary Hemminger
Sent: Monday, October 20, 2008 20:26
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for IKEv2

I was talking about how to make the determination that the payload is encry=
pted.  Evidently there are two approaches:  one based on a heuristic, anoth=
er based on a payload wrapper that flags the payload is encrypted.  We woul=
d need some mechanism to determine the payload is encryped if we need to te=
rminate the IPSEC traffic and make a determination of which server to send =
it to.  Sorry about the confusion.

Gary

________________________________
From: Yoav Nir [mailto:ynir@checkpoint.com]
Sent: Sat 10/18/2008 2:03 PM
To: Gary Hemminger
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for IKEv2
Hi Gary.

I'm not sure what heuristics you are talking about. The problem of re-authe=
ntication is simply this. The owner of the remote access gateway has a secu=
rity policy that says that connections can be open for only so long (say, 2=
 hours) without authenticating the user again. This is a favorite requireme=
nt by auditors, who believe that this is an important part of risk manageme=
nt. If somebody steals your laptop (or mobile phone) or sits down at the In=
ternet Cafe station where you were logged on, we want to limit the amount o=
f time they are connected to the internal network. This requirement makes s=
ense if the user has to type in their password to authenticate. It makes le=
ss sense if there are user certificates that are stored on the computer, or=
 if the client software has a "save password" feature.

Whether it makes sense or not, this is a requirement by auditors and regula=
tors. If the user does not re-authenticate within the specified time, the I=
KE SA and all dependent child SAs are deleted.  This creates a usability pr=
oblem, because the SA is deleted without any advance warning to the user, s=
o the user is likely to get a relatively long time with no connectivity. Th=
is can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to =
make accounts permanently offline when this happens.

RFC 4778 and the improvement that Martin Willi is proposing, are aimed at s=
olving this usability problem by informing the client software in advance w=
hen the re-authentication needs to be done, and allowing them to re-authent=
icate early enough, so that connections are not broken. The heuristic does =
not affect the security or the IPsec streams.

Yoav

On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote:

One comment on the heuristics approach.  As a hardware vendor of L4-7 ADC b=
oxes, I am a little concerned about having to terminate IPSEC streams based=
 on the heuristics approach, because this is open ended.  What I mean is th=
at the heuristic may be easy to define now, but there is no certainty that =
it would remain this way.  My past experience suggests that eventually the =
heuristic would become too complex, and a well defined mechanism for determ=
ining which payload is encrypted would need to be employed anyway.
While I like the idea of some "other" box having to solve this issue, which=
 prevents clients from having to be changed, as we are a vendor of the "oth=
er" box, I think we should think about the long term, not the short term.  =
Just my opinion, and I am certainly flexible, but the heuristics approach w=
orries me a bit.

Gary

[IPsec] Reauthentication extension for IKEv2
________________________________

 *   To: Martin Willi >
 *   Subject: [IPsec] Reauthentication extension for IKEv2
 *   From: Tero Kivinen >
 *   Date: Tue, 16 Sep 2008 12:09:14 +0300
 *   Cc: ipsec at ietf.org
 *   Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com
 *   Delivered-to: ipsec at core3.amsl.com
 *   In-reply-to: <48CF5D7D.7070701 at strongswan.org>
 *   List-archive: 
 *   List-help: 
 *   List-id: Discussion of IPsec protocols 
 *   List-post: 
 *   List-subscribe: , 
 *   List-unsubscribe: , 
 *   References: <48CF5D7D.7070701 at strongswan.org>
 *   Sender: ipsec-bounces at ietf.org

________________________________

Martin Willi writes:

> What do you think about such an extension? Already considered something

> similar, or does your reauthentication procedure work hassle-free? I'm

> wondering if we are the only ones facing these problems or if such an

> extension would gain broader acceptance...



The first question I have is why are you doing reauthentication at

all?



What is the benefits of the reauthentication?



What is the benefits of the reauthentication that can be done WITHOUT

user intervention (i.e. no user typing in password or pin code or

fingerprint or similar)?



I myself can only really see benefits from reauthentication when it

does require that user is really sitting there on the machine, and

gives something that the machine itself cannot give. In those cases

the user is required to type in something or do something anyways,

thus it does not really matter if the communications is interrupted

for second if user must stop his work for much longer time to type in

his passphrase or pin code.



The RFC 4478 simply skips this question and says "With some IPsec

peers, particularly in the remote access scenario, it is desirable to

repeat the mutual authentication periodically. The purpose of this is

to limit the time that security associations (SAs) can be used by a

third party who has gained control of the IPsec peer."



In most cases if third party has gained control of the IPsec peer he

will also get control of all authentication information inside the

peer, including private keys and pre shared keys. Only way to make

sure that he does not get access to those is to protect them with

passphrase, or pin code or similar that is only known by the user.



This is also said out in the RFC 4478: "However, in the remote access

scenario it is usually up to a human user to supply the

authentication credentials ..."



Because of this I do not think there is that much requirement for

reauthentication protocol that is faster than what we already have.

--

kivinen at safenet-inc.com

_______________________________________________

IPsec mailing list

IPsec at ietf.org

https://www.ietf.org/mailman/listinfo/ipsec





________________________________

 *   Follow-Ups:

    *   Re: [IPsec] Reauthentication extension for IKEv2

       *   From: Martin Willi

 *   References:

    *   [IPsec] Reauthentication extension for IKEv2

       *   From: Martin Willi

 *   Prev by Date: [IPsec] Reauthentication extension for IKEv2
 *   Next by Date: Re: [IPsec] Reauthentication extension for IKEv2
 *   Previous by thread: [IPsec] Reauthentication extension for IKEv2
 *   Next by thread: Re: [IPsec] Reauthentication extension for IKEv2
 *   Index(es):

    *   Date
    *   Thread

Note: Messages sent to this list are the opinions of the senders and do not=
 imply endorsement by the IE



Scanned by Check Point Total Security Gateway.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



Scanned by Check Point Total Security Gateway.

--_000_A1E36B4547AAF443BEA10955A159923B0881D190rrsmsx505amrcor_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable




















OK. But if your load balancer is =
able to
decrypt the traffic (i.e. it has the credentials or secret keys), then =
it can
do that with today’s normal IKE/IPsec. There is no need in this =
case to modify
the protocol to make it easier to detect encrypted =
traffic.



 



Thanks,
=



      =
      Yaron



 















From: Gary =
Hemminger
[mailto:ghemminger@foundrynet.com] 

Sent: Tuesday, October =
21, 2008
19:02

To: Yaron
 Sheffer; Yoav =
Nir

Cc: ipsec@ietf.org

Subject: RE: Identifying =
encrypted
traffic (was: [IPsec] Reauthentication extension for =
IKEv2)






 



The use =
case you are
thinking about is probably pure IPsec VPN, where an encrypted stream =
only lives
across the WAN.  But what if you are a load balancer and the IPsec =
traffic
is end to end?  In this case, you may have a load balancer that =
needs to
terminate the traffic so it can make the decision which server to handle =
the
request.  All load balancers today support SSL termination.  =
Same
thing applies to IPsec traffic.  We cannot make the decision which =
server
to handle the request, nor can we maintain persistence without =
decrypting the
traffic.  



 <=
/o:p>



Gary



 <=
/o:p>









From: =
Yaron Sheffer =
[mailto:yaronf@checkpoint.com] 

Sent: Tuesday, October =
21, 2008
6:10 AM

To: Gary Hemminger; =
Yoav Nir

Cc: ipsec@ietf.org

Subject: Identifying =
encrypted
traffic (was: [IPsec] Reauthentication extension for =
IKEv2)









 



Hi =
Gary,



 



I’m puzzled by the scenario =
you are
presenting. I’ve been considering the work on ESP-null detection =
(e.g.
draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that =
want
to look at the IPsec-protected traffic, but do NOT want to terminate =
IPsec
(i.e. decapsulate the traffic). In general, if you can terminate IPsec, =
that
means that you have access to the encryption keys and you can easily
differentiate protected and unprotected traffic, Can you explain the use =
case
that you have in mind?



 



Thanks,
=



      =
     
Yaron



 















From:
ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger

Sent: Monday, October 20, =
2008
20:26

To: Yoav
 Nir

Cc: ipsec@ietf.org

Subject: Re: [IPsec]
Reauthentication extension for IKEv2






 









I was talking about how to make =
the
determination that the payload is encrypted.  Evidently there are =
two
approaches:  one based on a heuristic, another based on a payload =
wrapper
that flags the payload is encrypted.  We would need some mechanism =
to
determine the payload is encryped if we need to terminate the IPSEC =
traffic and
make a determination of which server to send it to.  Sorry about =
the
confusion.









 









Gary












 












From: Yoav Nir [mailto:ynir@checkpoint.com]

Sent: Sat 10/18/2008 2:03 =
PM

To: Gary Hemminger

Cc: ipsec@ietf.org

Subject: Re: [IPsec]
Reauthentication extension for IKEv2









Hi Gary. 






 









I'm not sure what heuristics you are talking about. The problem =
of
re-authentication is simply this. The owner of the remote access gateway =
has a
security policy that says that connections can be open for only so long =
(say, 2
hours) without authenticating the user again. This is a favorite =
requirement by
auditors, who believe that this is an important part of risk management. =
If
somebody steals your laptop (or mobile phone) or sits down at the =
Internet Cafe
station where you were logged on, we want to limit the amount of time =
they are
connected to the internal network. This requirement makes sense if the =
user has
to type in their password to authenticate. It makes less sense if there =
are
user certificates that are stored on the computer, or if the client =
software
has a "save password" feature.









 









Whether it makes sense or not, this is a requirement by auditors =
and
regulators. If the user does not re-authenticate within the specified =
time, the
IKE SA and all dependent child SAs are deleted.  This =
creates a
usability problem, because the SA is deleted without any advance warning =
to the
user, so the user is likely to get a relatively long time with no =
connectivity.
This can break TCP connections such as FTP, HTTP, and IMAP. Outlook =
tends to
make accounts permanently offline when this =
happens.









 









RFC 4778 and the improvement that Martin Willi is proposing, are =
aimed
at solving this usability problem by informing the client software in =
advance
when the re-authentication needs to be done, and allowing them to
re-authenticate early enough, so that connections are not broken. The =
heuristic
does not affect the security or the IPsec =
streams.









 









Yoav









 















On Oct 18, 2008, at 2:35 AM, Gary Hemminger =
wrote:






 









One comment on the heuristics
approach.  As a hardware vendor of L4-7 ADC boxes, I am a little =
concerned
about having to terminate IPSEC streams based on the heuristics =
approach,
because this is open ended.  What I mean is that the heuristic may =
be easy
to define now, but there is no certainty that it would remain this =
way. 
My past experience suggests that eventually the heuristic would become =
too
complex, and a well defined mechanism for determining which payload is
encrypted would need to be employed anyway.  =
 



While I like the idea of some =
“other”
box having to solve this issue, which prevents clients from having to be
changed, as we are a vendor of the “other” box, I think we =
should think about
the long term, not the short term.  Just my opinion, and I am =
certainly
flexible, but the heuristics approach worries me a =
bit.



 



Gary



 



[IPsec] Reauthentication extension for =
IKEv2



























Martin Willi =
writes:
> What do you think about such =
an extension? Already considered =
something
> similar, or does your =
reauthentication procedure work hassle-free? =
I'm
> wondering if we are the only =
ones facing these problems or if such =
an
> extension would gain broader =
acceptance...
 
The first question I have is why =
are you doing reauthentication =
at
all?
 
What is the benefits of the =
reauthentication?
 
What is the benefits of the =
reauthentication that can be done =
WITHOUT
user intervention (i.e. no user =
typing in password or pin code =
or
fingerprint or =
similar)?
 
I myself can only really see =
benefits from reauthentication when =
it
does require that user is really =
sitting there on the machine, =
and
gives something that the machine =
itself cannot give. In those =
cases
the user is required to type in =
something or do something =
anyways,
thus it does not really matter if =
the communications is =
interrupted
for second if user must stop his =
work for much longer time to type =
in
his passphrase or pin =
code.
 
The RFC 4478 simply skips this =
question and says "With some =
IPsec
peers, particularly in the remote =
access scenario, it is desirable =
to
repeat the mutual authentication =
periodically. The purpose of this =
is
to limit the time that security =
associations (SAs) can be used by =
a
third party who has gained =
control of the IPsec =
peer."
 
In most cases if third party has =
gained control of the IPsec peer =
he
will also get control of all =
authentication information inside =
the
peer, including private keys and =
pre shared keys. Only way to =
make
sure that he does not get access =
to those is to protect them =
with
passphrase, or pin code or =
similar that is only known by the =
user.
 
This is also said out in the RFC =
4478: "However, in the remote =
access
scenario it is usually up to a =
human user to supply the
authentication credentials =
..."
 
Because of this I do not think =
there is that much requirement =
for
reauthentication protocol that is =
faster than what we already have. =

-- =

kivinen at =
safenet-inc.com
__________________________________=
_____________
IPsec mailing =
list
IPsec at =
ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
 
 













    
 
  • Follow-Ups: =

    • 






    
 
      
  
        
   
      • From: Martin
       Willi
        • 
  
      
 
    




    
 
  • References: =

    • 






    
 
      
  
        
   
      • From: Martin
       Willi
        • 
  
      
 
    










Note: Messages sent to this list are the opinions of =
the
senders and do not imply endorsement by the =
IE






 













Scanned by Check Point Total Security Gateway. 



_______________________________________________

IPsec mailing list

IPsec@ietf.org

https://www.ietf.org=
/mailman/listinfo/ipsec









 













Scanned by Check Point Total Security Gateway. =







Some observations below:



 



    
 
  1. I
     agree with Yaron in that if a load balancer needs to ‘terminate&=
#8217;
     the traffic before applying any rules to distribute the load, then it
     should have the keys to do so without any modifications to the current
     protocol. In this case, the session setup (via IKE) should have been
     negotiated with the load balancer and it is the natural termination po=
int
     of the IPsec SA. The load balancer is essentially acting as a VPN gate=
way
     for tunnel mode or some kind of front end proxy to the multiple server=
s
     behind it in transport mode. 
    2. 
 
  2. My
     understanding of a ‘pure’ load balancer is that it distrib=
utes
     traffic streams to different resources available to it and this is
     typically based on rules such as source / destination IP protocols, po=
rts
     (e.g. TCP ports) and potentially some other information. Furthermore, =
as
     some of the upper layer protocols are stateful (e.g. TCP), it is desir=
able
     for the load balancer to ensure that a higher layer ‘sessionR=
17;
     (e.g. TCP session) is ‘pegged’ to a resource (server) that=
 has
     been handling the same session – this allows efficient state
     maintenance on a given resource / server, instead of all resources nee=
ding
     access to that state. Now if the traffic is protected using IPsec, the=
n
     the load balancer needs access to upper layer payload data in the pack=
et
     in order to apply the aforementioned rules for load balancing decision=
s.
     The charter item on traffic visibility provides for a clean solution w=
here
     the load-balancer (as well as other network monitoring tools) is able =
to ascertain
     that the packet if not encrypted and hence look inside the packet to
     analyze the protocol / ports to make load balancing decisions. In this
     case, IPsec is still being terminated on the server behind the load
     balancer, but the load balancer can examine the IPsec protected packet
     en-route to ensure it gets to the right server. In essence, this chart=
er
     item allows the load balancer (and other network tools) to continue to
     function in IPsec environments. 
    3. 
 
  3. I
     agree with Gary
     on his observations about heuristics as being complex in HW,
     undeterministic and the associated parsing rules liable to change base=
d on
     new protocols / payloads. 
    4. 




 



<=
span
style=3D'font-size:12.0pt;color:navy'>Thanks, 



<=
span
style=3D'font-size:12.0pt;color:navy'>- Ken



 


















From:
ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer

Sent: Tuesday, October 21, 2=
008
1:37 PM

To: Gary Hemminger; Yoav Nir=


Cc: ipsec@ietf.org

Subject: Re: [IPsec] Identif=
ying
encrypted traffic (was: Reauthentication extension for IKEv2)=







 



OK. But if your load balancer is able =
to
decrypt the traffic (i.e. it has the credentials or secret keys), then it c=
an
do that with today’s normal IKE/IPsec. There is no need in this case =
to
modify the protocol to make it easier to detect encrypted traffic.



 



Thanks,



      &n=
bsp;    
Yaron



 















From: Gary Hem=
minger
[mailto:ghemminger@foundrynet.com] 

Sent: Tuesday, October 21, 2=
008
19:02

To: Yaron
 Sheffer; Yoav Nir

Cc: ipsec@ietf.org

Subject: RE: Identifying enc=
rypted
traffic (was: [IPsec] Reauthentication extension for IKEv2)






 



The use case y=
ou are
thinking about is probably pure IPsec VPN, where an encrypted stream only l=
ives
across the WAN.  But what if you are a load balancer and the IPsec tra=
ffic
is end to end?  In this case, you may have a load balancer that needs =
to
terminate the traffic so it can make the decision which server to handle th=
e
request.  All load balancers today support SSL termination.  Same
thing applies to IPsec traffic.  We cannot make the decision which ser=
ver
to handle the request, nor can we maintain persistence without decrypting t=
he
traffic.  



 



Gary



 









From: Yaron Sheffer [mailto:yaronf@checkpoint.com] <=
br>
Sent: Tuesday, October 21, 2=
008
6:10 AM

To: Gary Hemminger; Yoav Nir

Cc: ipsec@ietf.org

Subject: Identifying encrypt=
ed
traffic (was: [IPsec] Reauthentication extension for IKEv2)









 



Hi Gary,



 



I’m puzzled by the scenario you =
are
presenting. I’ve been considering the work on ESP-null detection (e.g=
.
draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that wa=
nt
to look at the IPsec-protected traffic, but do NOT want to terminate IPsec
(i.e. decapsulate the traffic). In general, if you can terminate IPsec, tha=
t
means that you have access to the encryption keys and you can easily
differentiate protected and unprotected traffic, Can you explain the use ca=
se
that you have in mind?



 



Thanks,



      &n=
bsp;    
Yaron



 















From:
ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger

Sent: Monday, October 20, 20=
08 20:26

To: Yoav
 Nir

Cc: ipsec@ietf.org

Subject: Re: [IPsec]
Reauthentication extension for IKEv2






 









I was talking about how to make the
determination that the payload is encrypted.  Evidently there are two
approaches:  one based on a heuristic, another based on a payload wrap=
per
that flags the payload is encrypted.  We would need some mechanism to
determine the payload is encryped if we need to terminate the IPSEC traffic=
 and
make a determination of which server to send it to.  Sorry about the
confusion.









 









Gary












 












From:=
=
 Yoav Nir [mailto:ynir@checkpoint.com]

Sent: Sat 10/18/2008 2:03 PM=


To: Gary Hemminger

Cc: ipsec@ietf.org

Subject: Re: [IPsec]
Reauthentication extension for IKEv2









Hi Gary. 






 









I'm not sure what heuristics you are talking about. The problem of
re-authentication is simply this. The owner of the remote access gateway ha=
s a
security policy that says that connections can be open for only so long (sa=
y, 2
hours) without authenticating the user again. This is a favorite requiremen=
t by
auditors, who believe that this is an important part of risk management. If
somebody steals your laptop (or mobile phone) or sits down at the Internet =
Cafe
station where you were logged on, we want to limit the amount of time they =
are
connected to the internal network. This requirement makes sense if the user=
 has
to type in their password to authenticate. It makes less sense if there are
user certificates that are stored on the computer, or if the client softwar=
e
has a "save password" feature.









 









Whether it makes sense or not, this is a requirement by auditors an=
d
regulators. If the user does not re-authenticate within the specified time,=
 the
IKE SA and all dependent child SAs are deleted.  This create=
s a
usability problem, because the SA is deleted without any advance warning to=
 the
user, so the user is likely to get a relatively long time with no connectiv=
ity.
This can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends t=
o
make accounts permanently offline when this happens.









 









RFC 4778 and the improvement that Martin Willi is proposing, are ai=
med
at solving this usability problem by informing the client software in advan=
ce
when the re-authentication needs to be done, and allowing them to re-authen=
ticate
early enough, so that connections are not broken. The heuristic does not af=
fect
the security or the IPsec streams.









 









Yoav









 















On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote:






 =










One comment on the heuristics
approach.  As a hardware vendor of L4-7 ADC boxes, I am a little conce=
rned
about having to terminate IPSEC streams based on the heuristics approach,
because this is open ended.  What I mean is that the heuristic may be =
easy
to define now, but there is no certainty that it would remain this way.&nbs=
p;
My past experience suggests that eventually the heuristic would become too
complex, and a well defined mechanism for determining which payload is
encrypted would need to be employed anyway.   <=
font
color=3Dblack>



While I like the idea of some
“other” box having to solve this issue, which prevents clients =
from
having to be changed, as we are a vendor of the “other” box, I
think we should think about the long term, not the short term.  Just m=
y
opinion, and I am certainly flexible, but the heuristics approach worries m=
e a
bit.=




 



Gary=




 



[IPsec] Reauthentication extension for IKEv2=




























Martin Willi writes:
> What do you think about such an extension? Already consi=
dered something
> similar, or does your reauthentication procedure work ha=
ssle-free? I'm
> wondering if we are the only ones facing these problems =
or if such an
> extension would gain broader acceptance...
 
The first question I have is why are you doing reauthenticati=
on at
all?
 
What is the benefits of the reauthentication?
 
What is the benefits of the reauthentication that can be done=
 WITHOUT
user intervention (i.e. no user typing in password or pin cod=
e or
fingerprint or similar)?
<=
font
size=3D2 color=3Dblack face=3D"Courier New"> 
I myself can only really see benefits from reauthentication w=
hen it
does require that user is really sitting there on the machine=
, and
gives something that the machine itself cannot give. In those=
 cases
the user is required to type in something or do something any=
ways,
thus it does not really matter if the communications is inter=
rupted
for second if user must stop his work for much longer time to=
 type in
his passphrase or pin code.
 
    • <= a href=3D"http://www.ietf.org/mail-archive/web/ipsec/current/maillist.h= tml#03107">Date=
    • <= a href=3D"http://www.ietf.org/mail-archive/web/ipsec/current/threads.ht= ml#03107">Thread

Note: Messages sent to this list are the opinions of th= e senders and do not imply endorsement by the IE=

 



Scanned by Check Point Total Security Gateway. 

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.or= g/mailman/listinfo/ipsec

 



Scanned by Check Point Total Security Gateway. --_000_A1E36B4547AAF443BEA10955A159923B0881D190rrsmsx505amrcor_-- --===============1955882027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1955882027==-- From ipsec-bounces@ietf.org Tue Oct 21 15:22:55 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC32B3A6AD3; Tue, 21 Oct 2008 15:22:55 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691413A6AD3 for ; Tue, 21 Oct 2008 15:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=-0.563, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0FDUlDNbgNc for ; Tue, 21 Oct 2008 15:22:37 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 566423A68F9 for ; Tue, 21 Oct 2008 15:22:36 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 23500294005; Wed, 22 Oct 2008 00:23:49 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C03CD294003; Wed, 22 Oct 2008 00:22:56 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9LMMtke016737; Wed, 22 Oct 2008 00:22:56 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 22 Oct 2008 00:22:55 +0200 From: Yaron Sheffer To: "Grewal, Ken" , Gary Hemminger , Yoav Nir Date: Wed, 22 Oct 2008 00:22:47 +0200 Thread-Topic: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkhACbyvnAACETf8AAHhWiAAAKQj8AAALjDUA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0584196017==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0584196017== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01DC_01C933DC.4F58EF60" ------=_NextPart_000_01DC_01C933DC.4F58EF60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01DD_01C933DC.4F58EF60" ------=_NextPart_001_01DD_01C933DC.4F58EF60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ken, Thanks for the clarification. But I still don't understand how your scenario works. Assume for simplicity an environment where everybody uses ESP in transport mode, with null encryption. Client C1 does an IKE negotiation with a random server (as selected by the load balancer) S1. They negotiate some ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn the SPI value. Now when the first ESP packet is sent from C1 towards the load balancer, there is not enough information for it to forward the packet to S1, regardless of its being able to look into the cleartext packet! Only S1 has the ESP keying material, and if LB forwards the packet elsewhere, the receiver will not be able to verify its integrity. Regards, Yaron _____ From: Grewal, Ken [mailto:ken.grewal@intel.com] Sent: Tuesday, October 21, 2008 23:56 To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Some observations below: 1. I agree with Yaron in that if a load balancer needs to 'terminate' the traffic before applying any rules to distribute the load, then it should have the keys to do so without any modifications to the current protocol. In this case, the session setup (via IKE) should have been negotiated with the load balancer and it is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of front end proxy to the multiple servers behind it in transport mode. 2. My understanding of a 'pure' load balancer is that it distributes traffic streams to different resources available to it and this is typically based on rules such as source / destination IP protocols, ports (e.g. TCP ports) and potentially some other information. Furthermore, as some of the upper layer protocols are stateful (e.g. TCP), it is desirable for the load balancer to ensure that a higher layer 'session' (e.g. TCP session) is 'pegged' to a resource (server) that has been handling the same session - this allows efficient state maintenance on a given resource / server, instead of all resources needing access to that state. Now if the traffic is protected using IPsec, then the load balancer needs access to upper layer payload data in the packet in order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibility provides for a clean solution where the load-balancer (as well as other network monitoring tools) is able to ascertain that the packet if not encrypted and hence look inside the packet to analyze the protocol / ports to make load balancing decisions. In this case, IPsec is still being terminated on the server behind the load balancer, but the load balancer can examine the IPsec protected packet en-route to ensure it gets to the right server. In essence, this charter item allows the load balancer (and other network tools) to continue to function in IPsec environments. 3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change based on new protocols / payloads. Thanks, - Ken _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, October 21, 2008 1:37 PM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) OK. But if your load balancer is able to decrypt the traffic (i.e. it has the credentials or secret keys), then it can do that with today's normal IKE/IPsec. There is no need in this case to modify the protocol to make it easier to detect encrypted traffic. Thanks, Yaron _____ From: Gary Hemminger [mailto:ghemminger@foundrynet.com] Sent: Tuesday, October 21, 2008 19:02 To: Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) The use case you are thinking about is probably pure IPsec VPN, where an encrypted stream only lives across the WAN. But what if you are a load balancer and the IPsec traffic is end to end? In this case, you may have a load balancer that needs to terminate the traffic so it can make the decision which server to handle the request. All load balancers today support SSL termination. Same thing applies to IPsec traffic. We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic. Gary From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Tuesday, October 21, 2008 6:10 AM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) Hi Gary, I'm puzzled by the scenario you are presenting. I've been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that want to look at the IPsec-protected traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use case that you have in mind? Thanks, Yaron _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger Sent: Monday, October 20, 2008 20:26 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 I was talking about how to make the determination that the payload is encrypted. Evidently there are two approaches: one based on a heuristic, another based on a payload wrapper that flags the payload is encrypted. We would need some mechanism to determine the payload is encryped if we need to terminate the IPSEC traffic and make a determination of which server to send it to. Sorry about the confusion. Gary _____ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sat 10/18/2008 2:03 PM To: Gary Hemminger Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 Hi Gary. I'm not sure what heuristics you are talking about. The problem of re-authentication is simply this. The owner of the remote access gateway has a security policy that says that connections can be open for only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important part of risk management. If somebody steals your laptop (or mobile phone) or sits down at the Internet Cafe station where you were logged on, we want to limit the amount of time they are connected to the internal network. This requirement makes sense if the user has to type in their password to authenticate. It makes less sense if there are user certificates that are stored on the computer, or if the client software has a "save password" feature. Whether it makes sense or not, this is a requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are deleted. This creates a usability problem, because the SA is deleted without any advance warning to the user, so the user is likely to get a relatively long time with no connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to make accounts permanently offline when this happens. RFC 4778 and the improvement that Martin Willi is proposing, are aimed at solving this usability problem by informing the client software in advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The heuristic does not affect the security or the IPsec streams. Yoav On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: One comment on the heuristics approach. As a hardware vendor of L4-7 ADC boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended. What I mean is that the heuristic may be easy to define now, but there is no certainty that it would remain this way. My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway. While I like the idea of some "other" box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the "other" box, I think we should think about the long term, not the short term. Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit. Gary [IPsec] Reauthentication extension for IKEv2 _____ * To: Martin Willi strongswan.org> * Subject: [IPsec] Reauthentication extension for IKEv2 * From: Tero Kivinen > * Date: Tue, 16 Sep 2008 12:09:14 +0300 * Cc: ipsec at ietf.org * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com * Delivered-to: ipsec at core3.amsl.com * In-reply-to: <48CF5D7D.7070701 at strongswan.org> * List-archive: * List-help: * List-id: Discussion of IPsec protocols * List-post: * List-subscribe: , * List-unsubscribe: , * References: <48CF5D7D.7070701 at strongswan.org> * Sender: ipsec-bounces at ietf.org _____ Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... The first question I have is why are you doing reauthentication at all? What is the benefits of the reauthentication? What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have. -- kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec _____ * Follow-Ups: * Re: [IPsec] Reauthentication extension for IKEv2 * From: Martin Willi * References: * [IPsec] Reauthentication extension for IKEv2 * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 * Previous by thread: [IPsec] Reauthentication extension for IKEv2 * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 * Index(es): * Date * Thread Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IE Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. ------=_NextPart_001_01DD_01C933DC.4F58EF60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Ken,

 

Thanks for the clarification. But I = still don’t understand how your scenario works.

 

Assume for simplicity an = environment where everybody uses ESP in transport mode, with null = encryption.

 

Client C1 does an IKE negotiation = with a random server (as selected by the load balancer) S1. They negotiate some = ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the = load balancer cannot learn the SPI value.

 

Now when the first ESP packet is = sent from C1 towards the load balancer, there is not enough information for it to = forward the packet to S1, regardless of its being able to look into the = cleartext packet! Only S1 has the ESP keying material, and if LB forwards the = packet elsewhere, the receiver will not be able to verify its = integrity.

 

Regards,

      =       Yaron

 

From: = Grewal, Ken [mailto:ken.grewal@intel.com]
Sent: Tuesday, October = 21, 2008 23:56
To: Yaron Sheffer; Gary Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: RE: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

 

Some observations = below:

 

  1. I agree with Yaron in that if a load balancer needs to = ‘terminate’ the traffic before applying any rules to distribute the load, then it = should have the keys to do so without any modifications to the current = protocol. In this case, the session setup (via IKE) should have been = negotiated with the load balancer and it is the natural termination point of the = IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel = mode or some kind of front end proxy to the multiple servers behind it = in transport mode.
  2. My understanding of a ‘pure’ load balancer is that it = distributes traffic streams to different resources available to it and this is = typically based on rules such as source / destination IP protocols, ports (e.g. TCP = ports) and potentially some other information. Furthermore, as some of the = upper layer protocols are stateful (e.g. TCP), it is desirable for the = load balancer to ensure that a higher layer ‘session’ (e.g. = TCP session) is ‘pegged’ to a resource (server) that has been handling = the same session – this allows efficient state maintenance on a given resource / = server, instead of all resources needing access to that state. Now if the = traffic is protected using IPsec, then the load balancer needs access to = upper layer payload data in the packet in order to apply the = aforementioned rules for load balancing decisions. The charter item on traffic = visibility provides for a clean solution where the load-balancer (as well as = other network monitoring tools) is able to ascertain that the packet if = not encrypted and hence look inside the packet to analyze the protocol = / ports to make load balancing decisions. In this case, IPsec is still = being terminated on the server behind the load balancer, but the load = balancer can examine the IPsec protected packet en-route to ensure it gets = to the right server. In essence, this charter item allows the load = balancer (and other network tools) to continue to function in IPsec environments. =
  3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change = based on new protocols / payloads.

 

Thanks, =

- Ken

 

From: = ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On = Behalf Of Yaron Sheffer
Sent: Tuesday, October = 21, 2008 1:37 PM
To: Gary Hemminger; = Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

 

OK. But if your load balancer is = able to decrypt the traffic (i.e. it has the credentials or secret keys), then = it can do that with today’s normal IKE/IPsec. There is no need in this = case to modify the protocol to make it easier to detect encrypted = traffic.

 

Thanks,

=

      =       Yaron

 

From: Gary = Hemminger [mailto:ghemminger@foundrynet.com]
Sent: Tuesday, October = 21, 2008 19:02
To: Yaron Sheffer; Yoav = Nir
Cc: ipsec@ietf.org
Subject: RE: Identifying = encrypted traffic (was: [IPsec] Reauthentication extension for = IKEv2)

 

The use = case you are thinking about is probably pure IPsec VPN, where an encrypted stream = only lives across the WAN.  But what if you are a load balancer and the IPsec = traffic is end to end?  In this case, you may have a load balancer that = needs to terminate the traffic so it can make the decision which server to handle = the request.  All load balancers today support SSL termination.  = Same thing applies to IPsec traffic.  We cannot make the decision which = server to handle the request, nor can we maintain persistence without = decrypting the traffic. 

 <= /o:p>

Gary

 <= /o:p>

From: = Yaron Sheffer = [mailto:yaronf@checkpoint.com]
Sent: Tuesday, October = 21, 2008 6:10 AM
To: Gary Hemminger; = Yoav Nir
Cc: ipsec@ietf.org
Subject: Identifying = encrypted traffic (was: [IPsec] Reauthentication extension for = IKEv2)

 

Hi = Gary,

 

I’m puzzled by the scenario = you are presenting. I’ve been considering the work on ESP-null detection = (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that = want to look at the IPsec-protected traffic, but do NOT want to terminate = IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, = that means that you have access to the encryption keys and you can easily = differentiate protected and unprotected traffic, Can you explain the use case that you = have in mind?

 

Thanks,

=

      =       Yaron

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger
Sent: Monday, October 20, = 2008 20:26
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for IKEv2

 

I was talking about how to make = the determination that the payload is encrypted.  Evidently there are = two approaches:  one based on a heuristic, another based on a payload = wrapper that flags the payload is encrypted.  We would need some mechanism = to determine the payload is encryped if we need to terminate the IPSEC = traffic and make a determination of which server to send it to.  Sorry about = the confusion.

 

Gary

 

From: Yoav Nir [mailto:ynir@checkpoint.com]
Sent: Sat 10/18/2008 2:03 = PM
To: Gary Hemminger
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for IKEv2

Hi Gary.

 

I'm not sure what heuristics you are talking about. The problem = of re-authentication is simply this. The owner of the remote access gateway has a security = policy that says that connections can be open for only so long (say, 2 hours) = without authenticating the user again. This is a favorite requirement by = auditors, who believe that this is an important part of risk management. If somebody = steals your laptop (or mobile phone) or sits down at the Internet Cafe station = where you were logged on, we want to limit the amount of time they are = connected to the internal network. This requirement makes sense if the user has to = type in their password to authenticate. It makes less sense if there are user certificates that are stored on the computer, or if the client software = has a "save password" feature.

 

Whether it makes sense or not, this is a requirement by auditors = and regulators. If the user does not re-authenticate within the specified = time, the IKE SA and all dependent child SAs are deleted.  This = creates a usability problem, because the SA is deleted without any advance warning = to the user, so the user is likely to get a relatively long time with no = connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook = tends to make accounts permanently offline when this = happens.

 

RFC 4778 and the improvement that Martin Willi is proposing, are = aimed at solving this usability problem by informing the client software in = advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The = heuristic does not affect the security or the IPsec = streams.

 

Yoav

 

On Oct 18, 2008, at 2:35 AM, Gary Hemminger = wrote:

 

One comment on the heuristics approach.  As a hardware vendor of L4-7 ADC boxes, I am a little = concerned about having to terminate IPSEC streams based on the heuristics = approach, because this is open ended.  What I mean is that the heuristic may = be easy to define now, but there is no certainty that it would remain this = way.  My past experience suggests that eventually the heuristic would become = too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway.  =  

While I like the idea of some = “other” box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the “other” box, I think we = should think about the long term, not the short term.  Just my opinion, and I am = certainly flexible, but the heuristics approach worries me a = bit.

 

Gary

 

[IPsec] Reauthentication extension for = IKEv2

Martin Willi =
writes:
> What do you think about such =
an extension? Already considered =
something
> similar, or does your =
reauthentication procedure work hassle-free? =
I'm
> wondering if we are the only =
ones facing these problems or if such =
an
> extension would gain broader =
acceptance...
 
The first question I have is why =
are you doing reauthentication =
at
all?
 
What is the benefits of the =
reauthentication?
 
What is the benefits of the =
reauthentication that can be done =
WITHOUT
user intervention (i.e. no user =
typing in password or pin code =
or
fingerprint or =
similar)?
 
I myself can only really see =
benefits from reauthentication when =
it
does require that user is really =
sitting there on the machine, =
and
gives something that the machine =
itself cannot give. In those =
cases
the user is required to type in =
something or do something =
anyways,
thus it does not really matter if =
the communications is =
interrupted
for second if user must stop his =
work for much longer time to type =
in
his passphrase or pin =
code.
 
The RFC 4478 simply skips this =
question and says "With some =
IPsec
peers, particularly in the remote =
access scenario, it is desirable =
to
repeat the mutual authentication =
periodically. The purpose of this =
is
to limit the time that security =
associations (SAs) can be used by =
a
third party who has gained =
control of the IPsec =
peer."
 
In most cases if third party has =
gained control of the IPsec peer =
he
will also get control of all =
authentication information inside =
the
peer, including private keys and =
pre shared keys. Only way to =
make
sure that he does not get access =
to those is to protect them =
with
passphrase, or pin code or =
similar that is only known by the =
user.
 
This is also said out in the RFC =
4478: "However, in the remote =
access
scenario it is usually up to a =
human user to supply the
authentication credentials =
..."
 
Because of this I do not think =
there is that much requirement =
for
reauthentication protocol that is =
faster than what we already have. =

-- =

kivinen at =
safenet-inc.com
__________________________________=
_____________
IPsec mailing =
list
IPsec at =
ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
 
 













    
 
  • Follow-Ups: =

    • 






    
 
      
  
        
   
      • From: Martin
       Willi
        • 
  
      
 
    




    
 
  • References: =

    • 






    
 
      
  
        
   
      • From: Martin
       Willi
        • 
  
      
 
    










Note: Messages sent to this list are the opinions of =
the
senders and do not imply endorsement by the =
IE






 



Scanned by Check Point Total Security Gateway. 

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org= /mailman/listinfo/ipsec

 



Scanned by Check Point Total Security Gateway. =



Scanned by Check Point Total Security Gateway. =

------=_NextPart_001_01DD_01C933DC.4F58EF60-- ------=_NextPart_000_01DC_01C933DC.4F58EF60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyMTIyMjI0N1owIwYJKoZIhvcNAQkEMRYEFBqu0pg7x1hi jm3FXOXmNxofpkDWMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA XqIaJ+80TXX6gEtHKyBMXyggB5B+5nX2J6BAJjatKEyeUK7ck5AWofTs8D3KnnM9ERaV2RhN9lwb 5zrhnql4OrdbPxwIoL3mie237zuIDuo1Rx59FVdDSvteVyLM7STlbxTaX9g6AQwgKCuDtDtuPHGq aZfdgw9HoaXovJR3/NsyGAxkslhcpFOaNyJqaAEYX5uxwjR+lnj1BnzMX0M5tFhEgmhhYqIW83ki a66IaJpuuW7VWepjbIkqQqlWjVW5FoJYGx0fYkuQmbaI+nzRynH2HIrK2I47Krzg+IceDRNSqG2A 7ObPmCWDbHZP3nxW12VMEtoGWGV9qYmlj5WypgAAAAAAAA== ------=_NextPart_000_01DC_01C933DC.4F58EF60-- --===============0584196017== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0584196017==-- From ipsec-bounces@ietf.org Tue Oct 21 16:53:03 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0311F3A690A; Tue, 21 Oct 2008 16:53:03 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D573C3A690A for ; Tue, 21 Oct 2008 16:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qse-NLqEldpV for ; Tue, 21 Oct 2008 16:52:45 -0700 (PDT) Received: from smtp1gap.foundrynet.com (smtp1gap.foundrynet.com [76.199.70.29]) by core3.amsl.com (Postfix) with ESMTP id E855A3A67FA for ; Tue, 21 Oct 2008 16:52:43 -0700 (PDT) Received: from xmail.ds.foundrynet.com (unknown [10.101.218.254]) by smtp1gap.foundrynet.com (Postfix) with ESMTP id 1773E3E0003; Tue, 21 Oct 2008 16:53:41 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 16:53:57 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkhACbyvnAACETf8AAHhWiAAAKQj8AABD3OQA== References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com> From: "Gary Hemminger" To: "Grewal, Ken" , "Yaron Sheffer" , "Yoav Nir" Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1028295130==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1028295130== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C933D8.4884406C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C933D8.4884406C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Ken, =20 These are accurate depictions of the scenarios we will face. Server persistence is very important. And yes, I was a bit concerned about the "heuristics approach," but I haven't seen what these heuristics might be. Any heuristics would need to use either proprietary hardware or done in software. Maybe it wouldn't be difficult, but it might change over time. With the payload wrapper approach, we could have the merchant silicon vendor add it to their products (hopefully). =20 Gary =20 From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Grewal, Ken Sent: Tuesday, October 21, 2008 2:56 PM To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 Some observations below: =20 1. I agree with Yaron in that if a load balancer needs to 'terminate' the traffic before applying any rules to distribute the load, then it should have the keys to do so without any modifications to the current protocol. In this case, the session setup (via IKE) should have been negotiated with the load balancer and it is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of front end proxy to the multiple servers behind it in transport mode.=20 2. My understanding of a 'pure' load balancer is that it distributes traffic streams to different resources available to it and this is typically based on rules such as source / destination IP protocols, ports (e.g. TCP ports) and potentially some other information. Furthermore, as some of the upper layer protocols are stateful (e.g. TCP), it is desirable for the load balancer to ensure that a higher layer 'session' (e.g. TCP session) is 'pegged' to a resource (server) that has been handling the same session - this allows efficient state maintenance on a given resource / server, instead of all resources needing access to that state. Now if the traffic is protected using IPsec, then the load balancer needs access to upper layer payload data in the packet in order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibility provides for a clean solution where the load-balancer (as well as other network monitoring tools) is able to ascertain that the packet if not encrypted and hence look inside the packet to analyze the protocol / ports to make load balancing decisions. In this case, IPsec is still being terminated on the server behind the load balancer, but the load balancer can examine the IPsec protected packet en-route to ensure it gets to the right server. In essence, this charter item allows the load balancer (and other network tools) to continue to function in IPsec environments. 3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change based on new protocols / payloads.=20 =20 Thanks,=20 - Ken =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, October 21, 2008 1:37 PM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 OK. But if your load balancer is able to decrypt the traffic (i.e. it has the credentials or secret keys), then it can do that with today's normal IKE/IPsec. There is no need in this case to modify the protocol to make it easier to detect encrypted traffic. =20 Thanks, Yaron =20 ________________________________ From: Gary Hemminger [mailto:ghemminger@foundrynet.com]=20 Sent: Tuesday, October 21, 2008 19:02 To: Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) =20 The use case you are thinking about is probably pure IPsec VPN, where an encrypted stream only lives across the WAN. But what if you are a load balancer and the IPsec traffic is end to end? In this case, you may have a load balancer that needs to terminate the traffic so it can make the decision which server to handle the request. All load balancers today support SSL termination. Same thing applies to IPsec traffic. We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic. =20 =20 Gary =20 From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 Sent: Tuesday, October 21, 2008 6:10 AM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) =20 Hi Gary, =20 I'm puzzled by the scenario you are presenting. I've been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that want to look at the IPsec-protected traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use case that you have in mind? =20 Thanks, Yaron =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger Sent: Monday, October 20, 2008 20:26 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 =20 I was talking about how to make the determination that the payload is encrypted. Evidently there are two approaches: one based on a heuristic, another based on a payload wrapper that flags the payload is encrypted. We would need some mechanism to determine the payload is encryped if we need to terminate the IPSEC traffic and make a determination of which server to send it to. Sorry about the confusion. =20 Gary =20 ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sat 10/18/2008 2:03 PM To: Gary Hemminger Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 Hi Gary.=20 =20 I'm not sure what heuristics you are talking about. The problem of re-authentication is simply this. The owner of the remote access gateway has a security policy that says that connections can be open for only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important part of risk management. If somebody steals your laptop (or mobile phone) or sits down at the Internet Cafe station where you were logged on, we want to limit the amount of time they are connected to the internal network. This requirement makes sense if the user has to type in their password to authenticate. It makes less sense if there are user certificates that are stored on the computer, or if the client software has a "save password" feature. =20 Whether it makes sense or not, this is a requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are deleted. This creates a usability problem, because the SA is deleted without any advance warning to the user, so the user is likely to get a relatively long time with no connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to make accounts permanently offline when this happens. =20 RFC 4778 and the improvement that Martin Willi is proposing, are aimed at solving this usability problem by informing the client software in advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The heuristic does not affect the security or the IPsec streams. =20 Yoav =20 On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: =20 One comment on the heuristics approach. As a hardware vendor of L4-7 ADC boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended. What I mean is that the heuristic may be easy to define now, but there is no certainty that it would remain this way. My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway. =20 While I like the idea of some "other" box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the "other" box, I think we should think about the long term, not the short term. Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit. =20 Gary =20 [IPsec] Reauthentication extension for IKEv2 ________________________________ * To: Martin Willi >=20 * Subject: [IPsec] Reauthentication extension for IKEv2=20 * From: Tero Kivinen >=20 * Date: Tue, 16 Sep 2008 12:09:14 +0300=20 * Cc: ipsec at ietf.org =20 * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com =20 * Delivered-to: ipsec at core3.amsl.com =20 * In-reply-to: <48CF5D7D.7070701 at strongswan.org >=20 * List-archive: =20 * List-help: =20 * List-id: Discussion of IPsec protocols =20 * List-post: =20 * List-subscribe: , =20 * List-unsubscribe: , =20 * References: <48CF5D7D.7070701 at strongswan.org >=20 * Sender: ipsec-bounces at ietf.org =20 ________________________________ Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... =20 The first question I have is why are you doing reauthentication at all? =20 What is the benefits of the reauthentication? =20 What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? =20 I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. =20 The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." =20 In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. =20 This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." =20 Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have.=20 --=20 kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 ________________________________ * Follow-Ups:=20 * Re: [IPsec] Reauthentication extension for IKEv2 =20 * From: Martin Willi * References:=20 * [IPsec] Reauthentication extension for IKEv2 =20 * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 =20 * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 =20 * Previous by thread: [IPsec] Reauthentication extension for IKEv2 =20 * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 =20 * Index(es):=20 * Date * Thread =20 Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IE =20 Scanned by Check Point Total Security Gateway.=20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 Scanned by Check Point Total Security Gateway.=20 ------_=_NextPart_001_01C933D8.4884406C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Ken,

 

These are accurate depictions of the scenarios we will face.  Server persistence is very important.  And yes, I was a = bit concerned about the “heuristics approach,” but I = haven’t seen what these heuristics might be.  Any heuristics would need to use = either proprietary hardware or done in software.  Maybe it wouldn’t = be difficult, but it might change over time.  With the payload wrapper approach, we could have the merchant silicon vendor add it to their = products (hopefully).

 

Gary

 

From:= = ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Grewal, Ken
Sent: Tuesday, October 21, 2008 2:56 PM
To: Yaron Sheffer; Gary Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

 

Some observations below:

 

  1. I agree = with Yaron in that if a load balancer needs to ‘terminate’ = the traffic before applying any rules to distribute the load, then it = should have the keys to do so without any modifications to the current = protocol. In this case, the session setup (via IKE) should have been = negotiated with the load balancer and it is the natural termination point of the = IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel = mode or some kind of front end proxy to the multiple servers behind it = in transport mode.
  2. My = understanding of a ‘pure’ load balancer is that it distributes = traffic streams to different resources available to it and this is = typically based on rules such as source / destination IP protocols, ports (e.g. TCP = ports) and potentially some other information. Furthermore, as some of the = upper layer protocols are stateful (e.g. TCP), it is desirable for the = load balancer to ensure that a higher layer ‘session’ (e.g. = TCP session) is ‘pegged’ to a resource (server) that has = been handling the same session – this allows efficient state = maintenance on a given resource / server, instead of all resources needing = access to that state. Now if the traffic is protected using IPsec, then the = load balancer needs access to upper layer payload data in the packet in order to = apply the aforementioned rules for load balancing decisions. The charter = item on traffic visibility provides for a clean solution where the = load-balancer (as well as other network monitoring tools) is able to ascertain = that the packet if not encrypted and hence look inside the packet to analyze = the protocol / ports to make load balancing decisions. In this case, = IPsec is still being terminated on the server behind the load balancer, but = the load balancer can examine the IPsec protected packet en-route to = ensure it gets to the right server. In essence, this charter item allows the = load balancer (and other network tools) to continue to function in IPsec environments.
  3. I agree = with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change = based on new protocols / payloads.

 

Thanks, =

- = Ken

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yaron Sheffer
Sent: Tuesday, October 21, 2008 1:37 PM
To: Gary Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

 

OK. But if your load balancer is able to decrypt the traffic = (i.e. it has the credentials or secret keys), then it can do that with = today’s normal IKE/IPsec. There is no need in this case to modify the protocol = to make it easier to detect encrypted traffic.

 

Thanks,

          &= nbsp; Yaron

 

From:= Gary = Hemminger [mailto:ghemminger@foundrynet.com]
Sent: Tuesday, October 21, 2008 19:02
To: Yaron Sheffer; Yoav Nir
Cc: ipsec@ietf.org
Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2)

 

The use case you are thinking about is probably pure = IPsec VPN, where an encrypted stream only lives across the WAN.  But what if = you are a load balancer and the IPsec traffic is end to end?  In this case, = you may have a load balancer that needs to terminate the traffic so it can = make the decision which server to handle the request.  All load balancers = today support SSL termination.  Same thing applies to IPsec = traffic.  We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic.  =

 

Gary

 

From:= Yaron = Sheffer [mailto:yaronf@checkpoint.com]
Sent: Tuesday, October 21, 2008 6:10 AM
To: Gary Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: Identifying encrypted traffic (was: [IPsec] = Reauthentication extension for IKEv2)

 

Hi Gary,

 

I’m puzzled by the scenario you are presenting. = I’ve been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that = want to look at the IPsec-protected traffic, but do NOT want to terminate = IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, = that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use = case that you have in mind?

 

Thanks,

          &= nbsp; Yaron

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Gary Hemminger
Sent: Monday, October 20, 2008 20:26
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for = IKEv2

 

I was talking about how to make the determination that the = payload is encrypted.  Evidently there are two approaches:  one based = on a heuristic, another based on a payload wrapper that flags the payload is encrypted.  We would need some mechanism to determine the payload = is encryped if we need to terminate the IPSEC traffic and make a = determination of which server to send it to.  Sorry about the = confusion.

 

Gary

 

From: Yoav Nir = [mailto:ynir@checkpoint.com]
Sent: Sat 10/18/2008 2:03 PM
To: Gary Hemminger
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for = IKEv2

Hi Gary.

 

I'm not sure what heuristics you are talking about. = The problem of re-authentication is simply this. The owner of the remote = access gateway has a security policy that says that connections can be open for = only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important = part of risk management. If somebody steals your laptop (or mobile phone) or = sits down at the Internet Cafe station where you were logged on, we want to limit = the amount of time they are connected to the internal network. This = requirement makes sense if the user has to type in their password to authenticate. = It makes less sense if there are user certificates that are stored on the = computer, or if the client software has a "save password" = feature.

 

Whether it makes sense or not, this is a = requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are = deleted.  This creates a usability problem, because the SA is deleted = without any advance warning to the user, so the user is likely to get a relatively = long time with no connectivity. This can break TCP connections such as FTP, = HTTP, and IMAP. Outlook tends to make accounts permanently offline when this = happens.

 

RFC 4778 and the improvement that Martin Willi is = proposing, are aimed at solving this usability problem by informing the client = software in advance when the re-authentication needs to be done, and allowing them = to re-authenticate early enough, so that connections are not broken. The = heuristic does not affect the security or the IPsec streams.

 

Yoav

 

On Oct 18, 2008, at 2:35 AM, Gary Hemminger = wrote:

 

One = comment on the heuristics approach.  As a hardware vendor of L4-7 ADC = boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended.  What I mean is = that the heuristic may be easy to define now, but there is no certainty that it = would remain this way.  My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed = anyway.   

While I like the idea of some “other” box having to solve this issue, = which prevents clients from having to be changed, as we are a vendor of the “other” box, I think we should think about the long term, = not the short term.  Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit.

 

Gary

 

[IPsec] Reauthentication extension for = IKEv2

Martin Willi =
writes:
> What do you think about such an extension? =
Already considered something
> similar, or does your reauthentication =
procedure work hassle-free? I'm
> wondering if we are the only ones facing =
these problems or if such an
> extension would gain broader =
acceptance...
 
The first question I have is why are you doing =
reauthentication at
all?
 
What is the benefits of the =
reauthentication?
 
What is the benefits of the reauthentication that =
can be done WITHOUT
user intervention (i.e. no user typing in password =
or pin code or
fingerprint or =
similar)?
 
I myself can only really see benefits from =
reauthentication when it
does require that user is really sitting there on =
the machine, and
gives something that the machine itself cannot =
give. In those cases
the user is required to type in something or do =
something anyways,
thus it does not really matter if the =
communications is interrupted
for second if user must stop his work for much =
longer time to type in
his passphrase or pin =
code.
 
The RFC 4478 simply skips this question and says =
"With some IPsec
peers, particularly in the remote access scenario, =
it is desirable to
repeat the mutual authentication periodically. The =
purpose of this is
to limit the time that security associations (SAs) =
can be used by a
third party who has gained control of the IPsec =
peer."
 
In most cases if third party has gained control of =
the IPsec peer he
will also get control of all authentication =
information inside the
peer, including private keys and pre shared keys. =
Only way to make
sure that he does not get access to those is to =
protect them with
passphrase, or pin code or similar that is only =
known by the user.
 
This is also said out in the RFC 4478: =
"However, in the remote access
scenario it is usually up to a human user to =
supply the
authentication credentials =
..."
 
Because of this I do not think there is that much =
requirement for
reauthentication protocol that is faster than what =
we already have. 
-- 
kivinen at =
safenet-inc.com
_______________________________________________
IPsec mailing =
list
IPsec at =
ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
 
 
  • Follow-Ups<= /span>: =
      • From: Martin = Willi
  • References<= /span>: =
      • From: Martin = Willi

Note: Messages sent to this list are the = opinions of the senders and do not imply endorsement by the = IE

 



Scanned by Check Point Total Security Gateway. 

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org= /mailman/listinfo/ipsec

 



Scanned by Check Point Total Security Gateway.

------_=_NextPart_001_01C933D8.4884406C-- --===============1028295130== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1028295130==-- From ipsec-bounces@ietf.org Tue Oct 21 16:59:01 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC83D3A6A0F; Tue, 21 Oct 2008 16:59:00 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C2E3A6A0F for ; Tue, 21 Oct 2008 16:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.441 X-Spam-Level: X-Spam-Status: No, score=-1.441 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjI9wKYEz4Ni for ; Tue, 21 Oct 2008 16:58:42 -0700 (PDT) Received: from smtp1gap.foundrynet.com (smtp1gap.foundrynet.com [76.199.70.29]) by core3.amsl.com (Postfix) with ESMTP id F36D03A6886 for ; Tue, 21 Oct 2008 16:58:41 -0700 (PDT) Received: from xmail.ds.foundrynet.com (unknown [10.101.218.254]) by smtp1gap.foundrynet.com (Postfix) with ESMTP id 0007B3E0003; Tue, 21 Oct 2008 16:59:44 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Oct 2008 17:00:02 -0700 Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkhACbyvnAACETf8AAHhWiAAAKQj8AAALjDUAAD0PSg References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> From: "Gary Hemminger" To: "Yaron Sheffer" , "Grewal, Ken" , "Yoav Nir" Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1516087162==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1516087162== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C933D9.21FE7167" This is a multi-part message in MIME format. ------_=_NextPart_001_01C933D9.21FE7167 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable The client would negotiate IKE with the load balancer and would not directly negotiate with the Server. =20 Gary =20 From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 Sent: Tuesday, October 21, 2008 3:23 PM To: Grewal, Ken; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 Hi Ken, =20 Thanks for the clarification. But I still don't understand how your scenario works. =20 Assume for simplicity an environment where everybody uses ESP in transport mode, with null encryption. =20 Client C1 does an IKE negotiation with a random server (as selected by the load balancer) S1. They negotiate some ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn the SPI value. =20 Now when the first ESP packet is sent from C1 towards the load balancer, there is not enough information for it to forward the packet to S1, regardless of its being able to look into the cleartext packet! Only S1 has the ESP keying material, and if LB forwards the packet elsewhere, the receiver will not be able to verify its integrity. =20 Regards, Yaron =20 ________________________________ From: Grewal, Ken [mailto:ken.grewal@intel.com]=20 Sent: Tuesday, October 21, 2008 23:56 To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 Some observations below: =20 1. I agree with Yaron in that if a load balancer needs to 'terminate' the traffic before applying any rules to distribute the load, then it should have the keys to do so without any modifications to the current protocol. In this case, the session setup (via IKE) should have been negotiated with the load balancer and it is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of front end proxy to the multiple servers behind it in transport mode.=20 2. My understanding of a 'pure' load balancer is that it distributes traffic streams to different resources available to it and this is typically based on rules such as source / destination IP protocols, ports (e.g. TCP ports) and potentially some other information. Furthermore, as some of the upper layer protocols are stateful (e.g. TCP), it is desirable for the load balancer to ensure that a higher layer 'session' (e.g. TCP session) is 'pegged' to a resource (server) that has been handling the same session - this allows efficient state maintenance on a given resource / server, instead of all resources needing access to that state. Now if the traffic is protected using IPsec, then the load balancer needs access to upper layer payload data in the packet in order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibility provides for a clean solution where the load-balancer (as well as other network monitoring tools) is able to ascertain that the packet if not encrypted and hence look inside the packet to analyze the protocol / ports to make load balancing decisions. In this case, IPsec is still being terminated on the server behind the load balancer, but the load balancer can examine the IPsec protected packet en-route to ensure it gets to the right server. In essence, this charter item allows the load balancer (and other network tools) to continue to function in IPsec environments. 3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change based on new protocols / payloads.=20 =20 Thanks,=20 - Ken =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, October 21, 2008 1:37 PM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 OK. But if your load balancer is able to decrypt the traffic (i.e. it has the credentials or secret keys), then it can do that with today's normal IKE/IPsec. There is no need in this case to modify the protocol to make it easier to detect encrypted traffic. =20 Thanks, Yaron =20 ________________________________ From: Gary Hemminger [mailto:ghemminger@foundrynet.com]=20 Sent: Tuesday, October 21, 2008 19:02 To: Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) =20 The use case you are thinking about is probably pure IPsec VPN, where an encrypted stream only lives across the WAN. But what if you are a load balancer and the IPsec traffic is end to end? In this case, you may have a load balancer that needs to terminate the traffic so it can make the decision which server to handle the request. All load balancers today support SSL termination. Same thing applies to IPsec traffic. We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic. =20 =20 Gary =20 From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 Sent: Tuesday, October 21, 2008 6:10 AM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) =20 Hi Gary, =20 I'm puzzled by the scenario you are presenting. I've been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that want to look at the IPsec-protected traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use case that you have in mind? =20 Thanks, Yaron =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger Sent: Monday, October 20, 2008 20:26 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 =20 I was talking about how to make the determination that the payload is encrypted. Evidently there are two approaches: one based on a heuristic, another based on a payload wrapper that flags the payload is encrypted. We would need some mechanism to determine the payload is encryped if we need to terminate the IPSEC traffic and make a determination of which server to send it to. Sorry about the confusion. =20 Gary =20 ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sat 10/18/2008 2:03 PM To: Gary Hemminger Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 Hi Gary.=20 =20 I'm not sure what heuristics you are talking about. The problem of re-authentication is simply this. The owner of the remote access gateway has a security policy that says that connections can be open for only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important part of risk management. If somebody steals your laptop (or mobile phone) or sits down at the Internet Cafe station where you were logged on, we want to limit the amount of time they are connected to the internal network. This requirement makes sense if the user has to type in their password to authenticate. It makes less sense if there are user certificates that are stored on the computer, or if the client software has a "save password" feature. =20 Whether it makes sense or not, this is a requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are deleted. This creates a usability problem, because the SA is deleted without any advance warning to the user, so the user is likely to get a relatively long time with no connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to make accounts permanently offline when this happens. =20 RFC 4778 and the improvement that Martin Willi is proposing, are aimed at solving this usability problem by informing the client software in advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The heuristic does not affect the security or the IPsec streams. =20 Yoav =20 On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: =20 One comment on the heuristics approach. As a hardware vendor of L4-7 ADC boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended. What I mean is that the heuristic may be easy to define now, but there is no certainty that it would remain this way. My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway. =20 While I like the idea of some "other" box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the "other" box, I think we should think about the long term, not the short term. Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit. =20 Gary =20 [IPsec] Reauthentication extension for IKEv2 ________________________________ * To: Martin Willi >=20 * Subject: [IPsec] Reauthentication extension for IKEv2=20 * From: Tero Kivinen >=20 * Date: Tue, 16 Sep 2008 12:09:14 +0300=20 * Cc: ipsec at ietf.org =20 * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com =20 * Delivered-to: ipsec at core3.amsl.com =20 * In-reply-to: <48CF5D7D.7070701 at strongswan.org >=20 * List-archive: =20 * List-help: =20 * List-id: Discussion of IPsec protocols =20 * List-post: =20 * List-subscribe: , =20 * List-unsubscribe: , =20 * References: <48CF5D7D.7070701 at strongswan.org >=20 * Sender: ipsec-bounces at ietf.org =20 ________________________________ Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... =20 The first question I have is why are you doing reauthentication at all? =20 What is the benefits of the reauthentication? =20 What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? =20 I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. =20 The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." =20 In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. =20 This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." =20 Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have.=20 --=20 kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 ________________________________ * Follow-Ups:=20 * Re: [IPsec] Reauthentication extension for IKEv2 =20 * From: Martin Willi * References:=20 * [IPsec] Reauthentication extension for IKEv2 =20 * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 =20 * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 =20 * Previous by thread: [IPsec] Reauthentication extension for IKEv2 =20 * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 =20 * Index(es):=20 * Date * Thread =20 Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IE =20 Scanned by Check Point Total Security Gateway.=20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 Scanned by Check Point Total Security Gateway.=20 Scanned by Check Point Total Security Gateway.=20 ------_=_NextPart_001_01C933D9.21FE7167 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

The client would negotiate IKE  with the load = balancer and would not directly negotiate with the Server.

 

Gary

 

From:= Yaron = Sheffer [mailto:yaronf@checkpoint.com]
Sent: Tuesday, October 21, 2008 3:23 PM
To: Grewal, Ken; Gary Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

 

Hi Ken,

 

Thanks for the clarification. But I still don’t = understand how your scenario works.

 

Assume for simplicity an environment where everybody uses = ESP in transport mode, with null encryption.

 

Client C1 does an IKE negotiation with a random server (as = selected by the load balancer) S1. They negotiate some ESP traffic stream, = denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn = the SPI value.

 

Now when the first ESP packet is sent from C1 towards the = load balancer, there is not enough information for it to forward the packet = to S1, regardless of its being able to look into the cleartext packet! Only S1 = has the ESP keying material, and if LB forwards the packet elsewhere, the = receiver will not be able to verify its integrity.

 

Regards,

          &= nbsp; Yaron

 

From:= Grewal, = Ken [mailto:ken.grewal@intel.com]
Sent: Tuesday, October 21, 2008 23:56
To: Yaron Sheffer; Gary Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

 

Some observations below:

 

  1. I agree = with Yaron in that if a load balancer needs to ‘terminate’ = the traffic before applying any rules to distribute the load, then it should have the = keys to do so without any modifications to the current protocol. In this = case, the session setup (via IKE) should have been negotiated with the load = balancer and it is the natural termination point of the IPsec SA. The load = balancer is essentially acting as a VPN gateway for tunnel mode or some kind = of front end proxy to the multiple servers behind it in transport = mode.
  2. My = understanding of a ‘pure’ load balancer is that it distributes = traffic streams to different resources available to it and this is typically based on = rules such as source / destination IP protocols, ports (e.g. TCP ports) = and potentially some other information. Furthermore, as some of the = upper layer protocols are stateful (e.g. TCP), it is desirable for the = load balancer to ensure that a higher layer ‘session’ (e.g. = TCP session) is ‘pegged’ to a resource (server) that has been handling = the same session – this allows efficient state maintenance on a given resource / = server, instead of all resources needing access to that state. Now if the = traffic is protected using IPsec, then the load balancer needs access to = upper layer payload data in the packet in order to apply the = aforementioned rules for load balancing decisions. The charter item on traffic = visibility provides for a clean solution where the load-balancer (as well as = other network monitoring tools) is able to ascertain that the packet if = not encrypted and hence look inside the packet to analyze the protocol = / ports to make load balancing decisions. In this case, IPsec is still = being terminated on the server behind the load balancer, but the load = balancer can examine the IPsec protected packet en-route to ensure it gets = to the right server. In essence, this charter item allows the load = balancer (and other network tools) to continue to function in IPsec environments. =
  3. I agree = with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change = based on new protocols / payloads.

 

Thanks, =

- = Ken

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yaron Sheffer
Sent: Tuesday, October 21, 2008 1:37 PM
To: Gary Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

 

OK. But if your load balancer is able to decrypt the traffic = (i.e. it has the credentials or secret keys), then it can do that with = today’s normal IKE/IPsec. There is no need in this case to modify the protocol to make = it easier to detect encrypted traffic.

 

Thanks,

          &= nbsp; Yaron

 

From:= Gary = Hemminger [mailto:ghemminger@foundrynet.com]
Sent: Tuesday, October 21, 2008 19:02
To: Yaron Sheffer; Yoav Nir
Cc: ipsec@ietf.org
Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2)

 

The use case you are thinking about is probably pure = IPsec VPN, where an encrypted stream only lives across the WAN.  But what if = you are a load balancer and the IPsec traffic is end to end?  In this case, = you may have a load balancer that needs to terminate the traffic so it can = make the decision which server to handle the request.  All load balancers = today support SSL termination.  Same thing applies to IPsec traffic.  We = cannot make the decision which server to handle the request, nor can we = maintain persistence without decrypting the traffic. 

 

Gary

 

From:= Yaron = Sheffer [mailto:yaronf@checkpoint.com]
Sent: Tuesday, October 21, 2008 6:10 AM
To: Gary Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: Identifying encrypted traffic (was: [IPsec] = Reauthentication extension for IKEv2)

 

Hi Gary,

 

I’m puzzled by the scenario you are presenting. = I’ve been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that = want to look at the IPsec-protected traffic, but do NOT want to terminate = IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, = that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use = case that you have in mind?

 

Thanks,

          &= nbsp; Yaron

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Gary Hemminger
Sent: Monday, October 20, 2008 20:26
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for = IKEv2

 

I was talking about how to make the determination that the = payload is encrypted.  Evidently there are two approaches:  one based = on a heuristic, another based on a payload wrapper that flags the payload is encrypted.  We would need some mechanism to determine the payload = is encryped if we need to terminate the IPSEC traffic and make a = determination of which server to send it to.  Sorry about the = confusion.

 

Gary

 

From: Yoav Nir = [mailto:ynir@checkpoint.com]
Sent: Sat 10/18/2008 2:03 PM
To: Gary Hemminger
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Reauthentication extension for = IKEv2

Hi Gary.

 

I'm not sure what heuristics you are talking about. = The problem of re-authentication is simply this. The owner of the remote = access gateway has a security policy that says that connections can be open for = only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important = part of risk management. If somebody steals your laptop (or mobile phone) or = sits down at the Internet Cafe station where you were logged on, we want to limit = the amount of time they are connected to the internal network. This = requirement makes sense if the user has to type in their password to authenticate. = It makes less sense if there are user certificates that are stored on the = computer, or if the client software has a "save password" = feature.

 

Whether it makes sense or not, this is a = requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are = deleted.  This creates a usability problem, because the SA is deleted = without any advance warning to the user, so the user is likely to get a relatively = long time with no connectivity. This can break TCP connections such as FTP, = HTTP, and IMAP. Outlook tends to make accounts permanently offline when this = happens.

 

RFC 4778 and the improvement that Martin Willi is = proposing, are aimed at solving this usability problem by informing the client = software in advance when the re-authentication needs to be done, and allowing them = to re-authenticate early enough, so that connections are not broken. The = heuristic does not affect the security or the IPsec streams.

 

Yoav

 

On Oct 18, 2008, at 2:35 AM, Gary Hemminger = wrote:

 

One = comment on the heuristics approach.  As a hardware vendor of L4-7 ADC = boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended.  What I mean is = that the heuristic may be easy to define now, but there is no certainty that it = would remain this way.  My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed = anyway.   

While I like the idea of some “other” box having to solve this issue, = which prevents clients from having to be changed, as we are a vendor of the “other” = box, I think we should think about the long term, not the short term.  Just my = opinion, and I am certainly flexible, but the heuristics approach worries me a = bit.

 

Gary

 

[IPsec] Reauthentication extension for = IKEv2

Martin Willi =
writes:
> What do you think about such an extension? =
Already considered something
> similar, or does your reauthentication =
procedure work hassle-free? I'm
> wondering if we are the only ones facing =
these problems or if such an
> extension would gain broader =
acceptance...
 
The first question I have is why are you doing =
reauthentication at
all?
 
What is the benefits of the =
reauthentication?
 
What is the benefits of the reauthentication that =
can be done WITHOUT
user intervention (i.e. no user typing in password =
or pin code or
fingerprint or =
similar)?
 
I myself can only really see benefits from =
reauthentication when it
does require that user is really sitting there on =
the machine, and
gives something that the machine itself cannot =
give. In those cases
the user is required to type in something or do =
something anyways,
thus it does not really matter if the =
communications is interrupted
for second if user must stop his work for much =
longer time to type in
his passphrase or pin =
code.
 
The RFC 4478 simply skips this question and says =
"With some IPsec
peers, particularly in the remote access scenario, =
it is desirable to
repeat the mutual authentication periodically. The =
purpose of this is
to limit the time that security associations (SAs) =
can be used by a
third party who has gained control of the IPsec =
peer."
 
In most cases if third party has gained control of =
the IPsec peer he
will also get control of all authentication =
information inside the
peer, including private keys and pre shared keys. =
Only way to make
sure that he does not get access to those is to =
protect them with
passphrase, or pin code or similar that is only =
known by the user.
 
This is also said out in the RFC 4478: =
"However, in the remote access
scenario it is usually up to a human user to =
supply the
authentication credentials =
..."
 
Because of this I do not think there is that much =
requirement for
reauthentication protocol that is faster than what =
we already have. 
-- 
kivinen at =
safenet-inc.com
_______________________________________________
IPsec mailing =
list
IPsec at =
ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
 
 
  • Follow-Ups<= /span>: =
      • From: Martin = Willi
  • References<= /span>: =
      • From: Martin = Willi

Note: Messages sent to this list are the = opinions of the senders and do not imply endorsement by the = IE

 



Scanned by Check Point Total Security Gateway. 

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org= /mailman/listinfo/ipsec

 



Scanned by Check Point Total Security Gateway.



Scanned by Check Point Total Security Gateway.

------_=_NextPart_001_01C933D9.21FE7167-- --===============1516087162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1516087162==-- From ipsec-bounces@ietf.org Wed Oct 22 00:02:38 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CAEA28C0FC; Wed, 22 Oct 2008 00:02:38 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9895828C0FC for ; Wed, 22 Oct 2008 00:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=-0.520, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrmG9uHui3r4 for ; Wed, 22 Oct 2008 00:02:19 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id DD81D3A6835 for ; Wed, 22 Oct 2008 00:02:17 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 27714294005; Wed, 22 Oct 2008 09:03:33 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C07DB294003; Wed, 22 Oct 2008 09:03:30 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9M73Ske020073; Wed, 22 Oct 2008 09:03:29 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 22 Oct 2008 09:03:28 +0200 From: Yaron Sheffer To: Gary Hemminger , "Grewal, Ken" , Yoav Nir Date: Wed, 22 Oct 2008 09:03:15 +0200 Thread-Topic: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkhACbyvnAACETf8AAHhWiAAAKQj8AAALjDUAAD0PSgAA7QhJA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC80B@il-ex01.ad.checkpoint.com> References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0278436271==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0278436271== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_01E4_01C93425.048921A0" ------=_NextPart_000_01E4_01C93425.048921A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_01E5_01C93425.04904D90" ------=_NextPart_001_01E5_01C93425.04904D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In that case, the load balancer can identify the traffic using the normal ESP SPI field, and knows exactly what kind of traffic it is and whether it is encrypted. There is no need to change the ESP protocol for this scenario. Thanks, Yaron _____ From: Gary Hemminger [mailto:ghemminger@foundrynet.com] Sent: Wednesday, October 22, 2008 2:00 To: Yaron Sheffer; Grewal, Ken; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) The client would negotiate IKE with the load balancer and would not directly negotiate with the Server. Gary From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Tuesday, October 21, 2008 3:23 PM To: Grewal, Ken; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Hi Ken, Thanks for the clarification. But I still don't understand how your scenario works. Assume for simplicity an environment where everybody uses ESP in transport mode, with null encryption. Client C1 does an IKE negotiation with a random server (as selected by the load balancer) S1. They negotiate some ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn the SPI value. Now when the first ESP packet is sent from C1 towards the load balancer, there is not enough information for it to forward the packet to S1, regardless of its being able to look into the cleartext packet! Only S1 has the ESP keying material, and if LB forwards the packet elsewhere, the receiver will not be able to verify its integrity. Regards, Yaron _____ From: Grewal, Ken [mailto:ken.grewal@intel.com] Sent: Tuesday, October 21, 2008 23:56 To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Some observations below: 1. I agree with Yaron in that if a load balancer needs to 'terminate' the traffic before applying any rules to distribute the load, then it should have the keys to do so without any modifications to the current protocol. In this case, the session setup (via IKE) should have been negotiated with the load balancer and it is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of front end proxy to the multiple servers behind it in transport mode. 2. My understanding of a 'pure' load balancer is that it distributes traffic streams to different resources available to it and this is typically based on rules such as source / destination IP protocols, ports (e.g. TCP ports) and potentially some other information. Furthermore, as some of the upper layer protocols are stateful (e.g. TCP), it is desirable for the load balancer to ensure that a higher layer 'session' (e.g. TCP session) is 'pegged' to a resource (server) that has been handling the same session - this allows efficient state maintenance on a given resource / server, instead of all resources needing access to that state. Now if the traffic is protected using IPsec, then the load balancer needs access to upper layer payload data in the packet in order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibility provides for a clean solution where the load-balancer (as well as other network monitoring tools) is able to ascertain that the packet if not encrypted and hence look inside the packet to analyze the protocol / ports to make load balancing decisions. In this case, IPsec is still being terminated on the server behind the load balancer, but the load balancer can examine the IPsec protected packet en-route to ensure it gets to the right server. In essence, this charter item allows the load balancer (and other network tools) to continue to function in IPsec environments. 3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change based on new protocols / payloads. Thanks, - Ken _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, October 21, 2008 1:37 PM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) OK. But if your load balancer is able to decrypt the traffic (i.e. it has the credentials or secret keys), then it can do that with today's normal IKE/IPsec. There is no need in this case to modify the protocol to make it easier to detect encrypted traffic. Thanks, Yaron _____ From: Gary Hemminger [mailto:ghemminger@foundrynet.com] Sent: Tuesday, October 21, 2008 19:02 To: Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) The use case you are thinking about is probably pure IPsec VPN, where an encrypted stream only lives across the WAN. But what if you are a load balancer and the IPsec traffic is end to end? In this case, you may have a load balancer that needs to terminate the traffic so it can make the decision which server to handle the request. All load balancers today support SSL termination. Same thing applies to IPsec traffic. We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic. Gary From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Tuesday, October 21, 2008 6:10 AM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) Hi Gary, I'm puzzled by the scenario you are presenting. I've been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that want to look at the IPsec-protected traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use case that you have in mind? Thanks, Yaron _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger Sent: Monday, October 20, 2008 20:26 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 I was talking about how to make the determination that the payload is encrypted. Evidently there are two approaches: one based on a heuristic, another based on a payload wrapper that flags the payload is encrypted. We would need some mechanism to determine the payload is encryped if we need to terminate the IPSEC traffic and make a determination of which server to send it to. Sorry about the confusion. Gary _____ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sat 10/18/2008 2:03 PM To: Gary Hemminger Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 Hi Gary. I'm not sure what heuristics you are talking about. The problem of re-authentication is simply this. The owner of the remote access gateway has a security policy that says that connections can be open for only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important part of risk management. If somebody steals your laptop (or mobile phone) or sits down at the Internet Cafe station where you were logged on, we want to limit the amount of time they are connected to the internal network. This requirement makes sense if the user has to type in their password to authenticate. It makes less sense if there are user certificates that are stored on the computer, or if the client software has a "save password" feature. Whether it makes sense or not, this is a requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are deleted. This creates a usability problem, because the SA is deleted without any advance warning to the user, so the user is likely to get a relatively long time with no connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to make accounts permanently offline when this happens. RFC 4778 and the improvement that Martin Willi is proposing, are aimed at solving this usability problem by informing the client software in advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The heuristic does not affect the security or the IPsec streams. Yoav On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: One comment on the heuristics approach. As a hardware vendor of L4-7 ADC boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended. What I mean is that the heuristic may be easy to define now, but there is no certainty that it would remain this way. My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway. While I like the idea of some "other" box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the "other" box, I think we should think about the long term, not the short term. Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit. Gary [IPsec] Reauthentication extension for IKEv2 _____ * To: Martin Willi strongswan.org> * Subject: [IPsec] Reauthentication extension for IKEv2 * From: Tero Kivinen > * Date: Tue, 16 Sep 2008 12:09:14 +0300 * Cc: ipsec at ietf.org * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com * Delivered-to: ipsec at core3.amsl.com * In-reply-to: <48CF5D7D.7070701 at strongswan.org> * List-archive: * List-help: * List-id: Discussion of IPsec protocols * List-post: * List-subscribe: , * List-unsubscribe: , * References: <48CF5D7D.7070701 at strongswan.org> * Sender: ipsec-bounces at ietf.org _____ Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... The first question I have is why are you doing reauthentication at all? What is the benefits of the reauthentication? What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have. -- kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec _____ * Follow-Ups: * Re: [IPsec] Reauthentication extension for IKEv2 * From: Martin Willi * References: * [IPsec] Reauthentication extension for IKEv2 * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 * Previous by thread: [IPsec] Reauthentication extension for IKEv2 * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 * Index(es): * Date * Thread Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IE Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. ------=_NextPart_001_01E5_01C93425.04904D90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_01E5_01C93425.04904D90-- ------=_NextPart_000_01E4_01C93425.048921A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyMjA3MDMxNVowIwYJKoZIhvcNAQkEMRYEFNTu6gZ91Kna KpEIdp6eLQCo5yXiMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA HJAfWU35tnTBHnvYg2Yi8kPAM3iGwI32Hwb6atNFa0cjVV64FhrUQrLbAo66XRnLDdlWlONdn0sr aANrkxkYjlRx2S+RzwWUay5RXVCoZPJPWwj+G7jN4p7/bAzysB1pYkqQFCusjYW0oCWkttBN8G8N 3zzLuSOSR2FRM3wemVyE5NsCh9yt5fmYYTei+B5xpg+Tqd15KuIOoL+PgIARCQ4XwWQmHMlTJgrj /2w4IZH3wmYIYrDBtMYLSPB8BrZCjr1ikZAVC18lLj365gir+6Pf2VyBwG4zat2Isu/KEXpV/9vw 4SmcrtWvh2ltrCM0u/01p1/XbbetGUzGBlbZNAAAAAAAAA== ------=_NextPart_000_01E4_01C93425.048921A0-- --===============0278436271== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0278436271==-- From ipsec-bounces@ietf.org Wed Oct 22 00:57:55 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54F743A6B08; Wed, 22 Oct 2008 00:57:55 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D05D3A6B10 for ; Wed, 22 Oct 2008 00:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[AWL=-0.521, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ecf9QUO-Nsif for ; Wed, 22 Oct 2008 00:57:50 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7A6863A67FA for ; Wed, 22 Oct 2008 00:57:49 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id BC70E29C002; Wed, 22 Oct 2008 09:59:04 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B08B929C001; Wed, 22 Oct 2008 09:57:21 +0200 (IST) Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id m9M7vLkh008697; Wed, 22 Oct 2008 09:57:21 +0200 (IST) Message-Id: <206900B6-1B1D-45EB-8F6D-D035F4BB3670@checkpoint.com> From: Yoav Nir To: "Gary Hemminger" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 08:40:12 +0200 References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org, "Grewal, Ken" Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0643508697==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0643508697== Content-Type: multipart/alternative; boundary=Apple-Mail-1--610206667 --Apple-Mail-1--610206667 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Gary If that's the case, then the load balancer would need neither =20 heuristics nor a wrapper. Having terminated the IKE, the load balancer =20= would have the child SA, and would know for certain whether the =20 algorithm is ESP-NULL or something encrypted. In fact, the load =20 balancer would even be able to enforce such a policy. Yoav On Oct 22, 2008, at 2:00 AM, Gary Hemminger wrote: > The client would negotiate IKE with the load balancer and would not =20= > directly negotiate with the Server. > > Gary > > From: Yaron Sheffer [mailto:yaronf@checkpoint.com] > Sent: Tuesday, October 21, 2008 3:23 PM > To: Grewal, Ken; Gary Hemminger; Yoav Nir > Cc: ipsec@ietf.org > Subject: RE: [IPsec] Identifying encrypted traffic (was: =20 > Reauthentication extension for IKEv2) > > Hi Ken, > > Thanks for the clarification. But I still don=92t understand how your =20= > scenario works. > > Assume for simplicity an environment where everybody uses ESP in =20 > transport mode, with null encryption. > > Client C1 does an IKE negotiation with a random server (as selected =20= > by the load balancer) S1. They negotiate some ESP traffic stream, =20 > denoted by an SPI. This whole thing is encrypted, so the load =20 > balancer cannot learn the SPI value. > > Now when the first ESP packet is sent from C1 towards the load =20 > balancer, there is not enough information for it to forward the =20 > packet to S1, regardless of its being able to look into the =20 > cleartext packet! Only S1 has the ESP keying material, and if LB =20 > forwards the packet elsewhere, the receiver will not be able to =20 > verify its integrity. > > Regards, > Yaron > > From: Grewal, Ken [mailto:ken.grewal@intel.com] > Sent: Tuesday, October 21, 2008 23:56 > To: Yaron Sheffer; Gary Hemminger; Yoav Nir > Cc: ipsec@ietf.org > Subject: RE: [IPsec] Identifying encrypted traffic (was: =20 > Reauthentication extension for IKEv2) > > Some observations below: > > I agree with Yaron in that if a load balancer needs to =91terminate=92 = =20 > the traffic before applying any rules to distribute the load, then =20 > it should have the keys to do so without any modifications to the =20 > current protocol. In this case, the session setup (via IKE) should =20 > have been negotiated with the load balancer and it is the natural =20 > termination point of the IPsec SA. The load balancer is essentially =20= > acting as a VPN gateway for tunnel mode or some kind of front end =20 > proxy to the multiple servers behind it in transport mode. > My understanding of a =91pure=92 load balancer is that it distributes =20= > traffic streams to different resources available to it and this is =20 > typically based on rules such as source / destination IP protocols, =20= > ports (e.g. TCP ports) and potentially some other information. =20 > Furthermore, as some of the upper layer protocols are stateful (e.g. =20= > TCP), it is desirable for the load balancer to ensure that a higher =20= > layer =91session=92 (e.g. TCP session) is =91pegged=92 to a resource =20= > (server) that has been handling the same session =96 this allows =20 > efficient state maintenance on a given resource / server, instead of =20= > all resources needing access to that state. Now if the traffic is =20 > protected using IPsec, then the load balancer needs access to upper =20= > layer payload data in the packet in order to apply the =20 > aforementioned rules for load balancing decisions. The charter item =20= > on traffic visibility provides for a clean solution where the load-=20 > balancer (as well as other network monitoring tools) is able to =20 > ascertain that the packet if not encrypted and hence look inside the =20= > packet to analyze the protocol / ports to make load balancing =20 > decisions. In this case, IPsec is still being terminated on the =20 > server behind the load balancer, but the load balancer can examine =20 > the IPsec protected packet en-route to ensure it gets to the right =20 > server. In essence, this charter item allows the load balancer (and =20= > other network tools) to continue to function in IPsec environments. > I agree with Gary on his observations about heuristics as being =20 > complex in HW, undeterministic and the associated parsing rules =20 > liable to change based on new protocols / payloads. > > Thanks, > - Ken > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On =20 > Behalf Of Yaron Sheffer > Sent: Tuesday, October 21, 2008 1:37 PM > To: Gary Hemminger; Yoav Nir > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Identifying encrypted traffic (was: =20 > Reauthentication extension for IKEv2) > > OK. But if your load balancer is able to decrypt the traffic (i.e. =20 > it has the credentials or secret keys), then it can do that with =20 > today=92s normal IKE/IPsec. There is no need in this case to modify =20= > the protocol to make it easier to detect encrypted traffic. > > Thanks, > Yaron > > From: Gary Hemminger [mailto:ghemminger@foundrynet.com] > Sent: Tuesday, October 21, 2008 19:02 > To: Yaron Sheffer; Yoav Nir > Cc: ipsec@ietf.org > Subject: RE: Identifying encrypted traffic (was: [IPsec] =20 > Reauthentication extension for IKEv2) > > The use case you are thinking about is probably pure IPsec VPN, =20 > where an encrypted stream only lives across the WAN. But what if =20 > you are a load balancer and the IPsec traffic is end to end? In =20 > this case, you may have a load balancer that needs to terminate the =20= > traffic so it can make the decision which server to handle the =20 > request. All load balancers today support SSL termination. Same =20 > thing applies to IPsec traffic. We cannot make the decision which =20 > server to handle the request, nor can we maintain persistence =20 > without decrypting the traffic. > > Gary > > From: Yaron Sheffer [mailto:yaronf@checkpoint.com] > Sent: Tuesday, October 21, 2008 6:10 AM > To: Gary Hemminger; Yoav Nir > Cc: ipsec@ietf.org > Subject: Identifying encrypted traffic (was: [IPsec] =20 > Reauthentication extension for IKEv2) > > Hi Gary, > > I=92m puzzled by the scenario you are presenting. I=92ve been =20 > considering the work on ESP-null detection (e.g. draft-grewal-ipsec-=20= > traffic-visibility-01) as useful for middleboxes that want to look =20 > at the IPsec-protected traffic, but do NOT want to terminate IPsec =20 > (i.e. decapsulate the traffic). In general, if you can terminate =20 > IPsec, that means that you have access to the encryption keys and =20 > you can easily differentiate protected and unprotected traffic, Can =20= > you explain the use case that you have in mind? > > Thanks, > Yaron > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On =20 > Behalf Of Gary Hemminger > Sent: Monday, October 20, 2008 20:26 > To: Yoav Nir > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Reauthentication extension for IKEv2 > > I was talking about how to make the determination that the payload =20 > is encrypted. Evidently there are two approaches: one based on a =20 > heuristic, another based on a payload wrapper that flags the payload =20= > is encrypted. We would need some mechanism to determine the payload =20= > is encryped if we need to terminate the IPSEC traffic and make a =20 > determination of which server to send it to. Sorry about the =20 > confusion. > > Gary > > From: Yoav Nir [mailto:ynir@checkpoint.com] > Sent: Sat 10/18/2008 2:03 PM > To: Gary Hemminger > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Reauthentication extension for IKEv2 > Hi Gary. > > I'm not sure what heuristics you are talking about. The problem of =20 > re-authentication is simply this. The owner of the remote access =20 > gateway has a security policy that says that connections can be open =20= > for only so long (say, 2 hours) without authenticating the user =20 > again. This is a favorite requirement by auditors, who believe that =20= > this is an important part of risk management. If somebody steals =20 > your laptop (or mobile phone) or sits down at the Internet Cafe =20 > station where you were logged on, we want to limit the amount of =20 > time they are connected to the internal network. This requirement =20 > makes sense if the user has to type in their password to =20 > authenticate. It makes less sense if there are user certificates =20 > that are stored on the computer, or if the client software has a =20 > "save password" feature. > > Whether it makes sense or not, this is a requirement by auditors and =20= > regulators. If the user does not re-authenticate within the =20 > specified time, the IKE SA and all dependent child SAs are deleted. =20= > This creates a usability problem, because the SA is deleted without =20= > any advance warning to the user, so the user is likely to get a =20 > relatively long time with no connectivity. This can break TCP =20 > connections such as FTP, HTTP, and IMAP. Outlook tends to make =20 > accounts permanently offline when this happens. > > RFC 4778 and the improvement that Martin Willi is proposing, are =20 > aimed at solving this usability problem by informing the client =20 > software in advance when the re-authentication needs to be done, and =20= > allowing them to re-authenticate early enough, so that connections =20 > are not broken. The heuristic does not affect the security or the =20 > IPsec streams. > > Yoav > > On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: > > One comment on the heuristics approach. As a hardware vendor of =20 > L4-7 ADC boxes, I am a little concerned about having to terminate =20 > IPSEC streams based on the heuristics approach, because this is open =20= > ended. What I mean is that the heuristic may be easy to define now, =20= > but there is no certainty that it would remain this way. My past =20 > experience suggests that eventually the heuristic would become too =20 > complex, and a well defined mechanism for determining which payload =20= > is encrypted would need to be employed anyway. > > While I like the idea of some =93other=94 box having to solve this =20 > issue, which prevents clients from having to be changed, as we are a =20= > vendor of the =93other=94 box, I think we should think about the long =20= > term, not the short term. Just my opinion, and I am certainly =20 > flexible, but the heuristics approach worries me a bit. > > > > Gary > > > > [IPsec] Reauthentication extension for IKEv2 > > To: Martin Willi > Subject: [IPsec] Reauthentication extension for IKEv2 > From: Tero Kivinen > Date: Tue, 16 Sep 2008 12:09:14 +0300 > Cc: ipsec at ietf.org > Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com > Delivered-to: ipsec at core3.amsl.com > In-reply-to: <48CF5D7D.7070701 at strongswan.org> > List-archive: > List-help: > List-id: Discussion of IPsec protocols > List-post: > List-subscribe: , = > > List-unsubscribe: , = > > References: <48CF5D7D.7070701 at strongswan.org> > Sender: ipsec-bounces at ietf.org > Martin Willi writes: > > What do you think about such an extension? Already considered =20 > something > > similar, or does your reauthentication procedure work hassle-free? =20= > I'm > > wondering if we are the only ones facing these problems or if such =20= > an > > extension would gain broader acceptance... > > The first question I have is why are you doing reauthentication at > all? > > What is the benefits of the reauthentication? > > What is the benefits of the reauthentication that can be done WITHOUT > user intervention (i.e. no user typing in password or pin code or > fingerprint or similar)? > > I myself can only really see benefits from reauthentication when it > does require that user is really sitting there on the machine, and > gives something that the machine itself cannot give. In those cases > the user is required to type in something or do something anyways, > thus it does not really matter if the communications is interrupted > for second if user must stop his work for much longer time to type in > his passphrase or pin code. > > The RFC 4478 simply skips this question and says "With some IPsec > peers, particularly in the remote access scenario, it is desirable to > repeat the mutual authentication periodically. The purpose of this is > to limit the time that security associations (SAs) can be used by a > third party who has gained control of the IPsec peer." > > In most cases if third party has gained control of the IPsec peer he > will also get control of all authentication information inside the > peer, including private keys and pre shared keys. Only way to make > sure that he does not get access to those is to protect them with > passphrase, or pin code or similar that is only known by the user. > > This is also said out in the RFC 4478: "However, in the remote access > scenario it is usually up to a human user to supply the > authentication credentials ..." > > Because of this I do not think there is that much requirement for > reauthentication protocol that is faster than what we already have. > --=20 > kivinen at safenet-inc.com > _______________________________________________ > IPsec mailing list > IPsec at ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > Follow-Ups: > Re: [IPsec] Reauthentication extension for IKEv2 > From: Martin Willi > References: > [IPsec] Reauthentication extension for IKEv2 > From: Martin Willi > Prev by Date: [IPsec] Reauthentication extension for IKEv2 > Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 > Previous by thread: [IPsec] Reauthentication extension for IKEv2 > Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 > Index(es): > Date > Thread > Note: Messages sent to this list are the opinions of the senders and =20= > do not imply endorsement by the IE > > > > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > Scanned by Check Point Total Security Gateway. > > > Scanned by Check Point Total Security Gateway. > > > Scanned by Check Point Total Security Gateway. > --Apple-Mail-1--610206667 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Gary

If = that's the case, then the load balancer would need neither heuristics = nor a wrapper. Having terminated the IKE, the load balancer would have = the child SA, and would know for certain whether the algorithm is = ESP-NULL or something encrypted. In fact, the load balancer would even = be able to enforce such a = policy.

Yoav

On Oct 22, = 2008, at 2:00 AM, Gary Hemminger wrote:

The client would = negotiate IKE  with the load balancer and would not directly = negotiate with the Server.
From: Yaron Sheffer [mailto:yaronf@checkpoint.com] 
Sent: Tuesday, October 21, 2008 = 3:23 PM
To: Grewal, Ken; Gary = Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: RE: [IPsec] Identifying = encrypted traffic (was: Reauthentication extension for = IKEv2)
Hi = Ken,
Thanks for the = clarification. But I still don=92t understand how your scenario = works.
Assume for = simplicity an environment where everybody uses ESP in transport mode, = with null encryption.
Client C1 does an = IKE negotiation with a random server (as selected by the load balancer) = S1. They negotiate some ESP traffic stream, denoted by an SPI. This = whole thing is encrypted, so the load balancer cannot learn the SPI = value.
Now when the first = ESP packet is sent from C1 towards the load balancer, there is not = enough information for it to forward the packet to S1, regardless of its = being able to look into the cleartext packet! Only S1 has the ESP keying = material, and if LB forwards the packet elsewhere, the receiver will not = be able to verify its integrity.
 
Regards,
 Grewal, = Ken [mailto:ken.grewal@intel.com] 
Sent: Tuesday, October 21, 2008 = 23:56
To: Yaron Sheffer; Gary = Hemminger; Yoav Nir
Cc: ipsec@ietf.org
Subject: RE: [IPsec] Identifying = encrypted traffic (was: Reauthentication extension for = IKEv2)
Some observations = below:
  • I agree with Yaron in that if a load balancer needs to = =91terminate=92 the traffic before applying any rules to distribute the = load, then it should have the keys to do so without any modifications to = the current protocol. In this case, the session setup (via IKE) should = have been negotiated with the load balancer and it is the natural = termination point of the IPsec SA. The load balancer is essentially = acting as a VPN gateway for tunnel mode or some kind of front end proxy = to the multiple servers behind it in transport = mode.
  • My understanding of a =91pure=92 load balancer is that it = distributes traffic streams to different resources available to it and = this is typically based on rules such as source / destination IP = protocols, ports (e.g. TCP ports) and potentially some other = information. Furthermore, as some of the upper layer protocols are = stateful (e.g. TCP), it is desirable for the load balancer to ensure = that a higher layer =91session=92 (e.g. TCP session) is =91pegged=92 to = a resource (server) that has been handling the same session =96 this = allows efficient state maintenance on a given resource / server, instead = of all resources needing access to that state. Now if the traffic is = protected using IPsec, then the load balancer needs access to upper = layer payload data in the packet in order to apply the aforementioned = rules for load balancing decisions. The charter item on traffic = visibility provides for a clean solution where the load-balancer (as = well as other network monitoring tools) is able to ascertain that the = packet if not encrypted and hence look inside the packet to analyze the = protocol / ports to make load balancing decisions. In this case, IPsec = is still being terminated on the server behind the load balancer, but = the load balancer can examine the IPsec protected packet en-route to = ensure it gets to the right server. In essence, this charter item allows = the load balancer (and other network tools) to continue to function in = IPsec environments.
  • I agree with Gary on his observations about heuristics as = being complex in HW, undeterministic and the associated parsing rules = liable to change based on new protocols / = payloads.
    • Thanks,
    - Ken
     ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron = Sheffer
    Sent: Tuesday, October 21, 2008 = 1:37 PM
    To: Gary Hemminger; Yoav = Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Identifying = encrypted traffic (was: Reauthentication extension for = IKEv2)
    OK. But if your load = balancer is able to decrypt the traffic (i.e. it has the credentials or = secret keys), then it can do that with today=92s normal IKE/IPsec. There = is no need in this case to modify the protocol to make it easier to = detect encrypted traffic.
     Gary = Hemminger [ 
    Sent: Tuesday, October 21, 2008 = 19:02
    To: Yaron Sheffer; Yoav = Nir
    Cc:     ipsec@ietf.org
    Subject: RE: Identifying encrypted = traffic (was: [IPsec] Reauthentication extension for = IKEv2)
    The use = case you are thinking about is probably pure IPsec VPN, where an = encrypted stream only lives across the WAN.  But what if you are a = load balancer and the IPsec traffic is end to end?  In this case, = you may have a load balancer that needs to terminate the traffic so it = can make the decision which server to handle the request.  All load = balancers today support SSL termination.  Same thing applies to = IPsec traffic.  We cannot make the decision which server to handle = the request, nor can we maintain persistence without decrypting the = traffic. 
    From: Yaron Sheffer [mailto:yaronf@checkpoint.com] 
    Sent: Tuesday, October 21, 2008 = 6:10 AM
    To: Gary Hemminger; Yoav = Nir
    Cc: ipsec@ietf.org
    Subject: Identifying encrypted = traffic (was: [IPsec] Reauthentication extension for = IKEv2)
    Hi = Gary,
    I=92m puzzled by = the scenario you are presenting. I=92ve been considering the work on = ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as = useful for middleboxes that want to look at the IPsec-protected traffic, = but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In = general, if you can terminate IPsec, that means that you have access to = the encryption keys and you can easily differentiate protected and = unprotected traffic, Can you explain the use case that you have in = mind?
     ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary = Hemminger
    Sent: Monday, October 20, 2008 = 20:26
    To: Yoav= Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] = Reauthentication extension for IKEv2
     
    I was talking = about how to make the determination that the payload is encrypted.  = Evidently there are two approaches:  one based on a heuristic, = another based on a payload wrapper that flags the payload is = encrypted.  We would need some mechanism to determine the payload = is encryped if we need to terminate the IPSEC traffic and make a = determination of which server to send it to.  Sorry about the = confusion.
    From: Yoav Nir [ Sat 10/18/2008 2:03 = PM
    To: Gary = Hemminger
    Cc:     ipsec@ietf.org
    Subject: Re: [IPsec] = Reauthentication extension for = IKEv2
    Hi = Gary.
    I'm not sure what = heuristics you are talking about. The problem of re-authentication is = simply this. The owner of the remote access gateway has a security = policy that says that connections can be open for only so long (say, 2 = hours) without authenticating the user again. This is a favorite = requirement by auditors, who believe that this is an important part of = risk management. If somebody steals your laptop (or mobile phone) or = sits down at the Internet Cafe station where you were logged on, we want = to limit the amount of time they are connected to the internal network. = This requirement makes sense if the user has to type in their password = to authenticate. It makes less sense if there are user certificates that = are stored on the computer, or if the client software has a "save = password" feature.
    Whether it makes sense or = not, this is a requirement by auditors and regulators. If the user does = not re-authenticate within the specified time, the IKE SA and = all dependent child SAs are deleted.  This creates a = usability problem, because the SA is deleted without any advance warning = to the user, so the user is likely to get a relatively long time with no = connectivity. This can break TCP connections such as FTP, HTTP, and = IMAP. Outlook tends to make accounts permanently offline when this = happens.
    RFC 4778 and the = improvement that Martin Willi is proposing, are aimed at solving this = usability problem by informing the client software in advance when the = re-authentication needs to be done, and allowing them to re-authenticate = early enough, so that connections are not broken. The heuristic does not = affect the security or the IPsec = streams.
    On Oct 18, = 2008, at 2:35 AM, Gary Hemminger wrote:
     

    One comment on the heuristics = approach.  As a hardware vendor of L4-7 ADC boxes, I am a little = concerned about having to terminate IPSEC streams based on the = heuristics approach, because this is open ended.  What I mean is = that the heuristic may be easy to define now, but there is no certainty = that it would remain this way.  My past experience suggests that = eventually the heuristic would become too complex, and a well defined = mechanism for determining which payload is encrypted would need to be = employed anyway.   While I = like the idea of some =93other=94 box having to solve this issue, which = prevents clients from having to be changed, as we are a vendor of the = =93other=94 box, I think we should think about the long term, not the = short term.  Just my opinion, and I am certainly flexible, but the = heuristics approach worries me a bit. 

    Gary

     

    Martin Willi writes:
    > What do you think about such an =
extension? Already considered something
    > similar, or does your =
reauthentication procedure work hassle-free? =
I'm
    > wondering =
if we are the only ones facing these problems or if such =
an
    > extension =
would gain broader acceptance...
     
    The first question I have is why are =
you doing reauthentication at
    all?
     
    What is the benefits of the =
reauthentication?
    What =
is the benefits of the reauthentication that can be done =
WITHOUT
    user =
intervention (i.e. no user typing in password or pin code =
or
    fingerprint =
or similar)?
    I =
myself can only really see benefits from reauthentication when =
it
    does =
require that user is really sitting there on the machine, =
and
    gives =
something that the machine itself cannot give. In those =
cases
    the =
user is required to type in something or do something =
anyways,
    thus =
it does not really matter if the communications is =
interrupted
    for =
second if user must stop his work for much longer time to type =
in
    his =
passphrase or pin code.
     
    The =
RFC 4478 simply skips this question and says "With some =
IPsec
    repeat the =
mutual authentication periodically. The purpose of this =
is
    to limit =
the time that security associations (SAs) can be used by =
a
    third party =
who has gained control of the IPsec peer."
     
    In most cases if third party has gained =
control of the IPsec peer he
    will also get control of all =
authentication information inside the
    peer, including private keys and pre =
shared keys. Only way to make
    sure that he does not get access to =
those is to protect them with
    passphrase, or pin code or similar that =
is only known by the user.
     
    This is also said out in the RFC 4478: =
"However, in the remote access
    scenario it is usually up to a human =
user to supply the
     
    Because of this I do not think there is =
that much requirement for
    reauthentication protocol that is faster than what we already =
have. 
    -- =

    kivinen at =
safenet-inc.com
    IPsec mailing =
list
    IPsec at =
ietf.org
     
     
        • From: Martin = Willi
        • From: Martin = Willi


    Scanned by = Check Point Total Security Gateway. 


    = --Apple-Mail-1--610206667-- --===============0643508697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0643508697==-- From ipsec-bounces@ietf.org Wed Oct 22 10:04:26 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ECC628C118; Wed, 22 Oct 2008 10:04:26 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D4C28C118 for ; Wed, 22 Oct 2008 10:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bfTRMx96dod for ; Wed, 22 Oct 2008 10:04:02 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 7B13E3A686B for ; Wed, 22 Oct 2008 10:04:01 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 22 Oct 2008 09:59:23 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.33,465,1220252400"; d="p7s'?scan'208,217";a="351233276" Received: from azsmsx602.amr.corp.intel.com ([10.2.121.201]) by orsmga002.jf.intel.com with ESMTP; 22 Oct 2008 10:03:49 -0700 Received: from rrsmsx602.amr.corp.intel.com (10.31.0.33) by azsmsx602.amr.corp.intel.com (10.2.121.201) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 22 Oct 2008 10:04:19 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Wed, 22 Oct 2008 11:04:13 -0600 From: "Grewal, Ken" To: Yaron Sheffer , Gary Hemminger , Yoav Nir Date: Wed, 22 Oct 2008 11:03:39 -0600 Thread-Topic: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkhACbyvnAACETf8AAHhWiAAAKQj8AAALjDUAAnmfuQ Message-ID: References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0045617033==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0045617033== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02CC_01C9342D.74D41AC0" ------=_NextPart_000_02CC_01C9342D.74D41AC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02CD_01C9342D.74D41AC0" ------=_NextPart_001_02CD_01C9342D.74D41AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Yaron, The scenario I was referring to requires the servers behind the load balancer to act as a cluster and hence on the first ESP packet, obtain the IPsec SA from another member of the cluster with which the SA was negotiated (this may be inherently done on the completion of an IKE SA also). I have seen this deployed using a back-end dedicated management interface for state synchronization. Remember, as far as the client is concerned, it is talking to just one server and does not see a cluster, so the cluster of servers have to act as one to some degree, including synchronization between them. Now, state synchronization on the first packet (e.g. of a new TCP connection) is one thing and achievable, but the real benefit of the load balancer is to 'peg' all subsequent packets for that TCP session to the same server. This ensures that within a given TCP (or another stateful protocol) session, there is no need to continually synchronize the TCP state between all members of the server cluster - if this was to be done, then the management / synchronization port between the cluster members would generate more traffic then being received into the cluster, which is not desirable or practical. So, from a load balancer point of view, it can look into the ESP (null) packet and see if this is a new connection (i.e. no existing rules based on IP/port information). If a new connection, it can use whatever internal rules to assign this packet to any server with the least load. On doing this, the load balancer updates internal rules to ensure any subsequent packets for the same stream as sent to the same server as the initial packet - that is the benefit (this is what load balancers do today for clear text traffic). I have also seen alternative solutions proposed - e.g. A given server completing an IKE negotiation can communicate 3-tuple (IP, SPI, protocol) information back to a load balancer and the load balancer can utilize this for any subsequent decisions on assigning load for IPsec encapsulated packet, but solutions like this require synchronization between the load balancer and the servers, which is less desirable. For any cluster of resources acting together to accommodate load balancing solutions, a certain amount of inter-cluster communication is expected and that fits in with the former solution above. Also remember, that IPsec E2E is not widely deployed because of problems exactly like this one (loss of visibility / control / functionality for intermediary devices) and this is what we are trying to address. Thanks, - Ken _____ From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Tuesday, October 21, 2008 3:23 PM To: Grewal, Ken; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Hi Ken, Thanks for the clarification. But I still don't understand how your scenario works. Assume for simplicity an environment where everybody uses ESP in transport mode, with null encryption. Client C1 does an IKE negotiation with a random server (as selected by the load balancer) S1. They negotiate some ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn the SPI value. Now when the first ESP packet is sent from C1 towards the load balancer, there is not enough information for it to forward the packet to S1, regardless of its being able to look into the cleartext packet! Only S1 has the ESP keying material, and if LB forwards the packet elsewhere, the receiver will not be able to verify its integrity. Regards, Yaron _____ From: Grewal, Ken [mailto:ken.grewal@intel.com] Sent: Tuesday, October 21, 2008 23:56 To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Some observations below: 1. I agree with Yaron in that if a load balancer needs to 'terminate' the traffic before applying any rules to distribute the load, then it should have the keys to do so without any modifications to the current protocol. In this case, the session setup (via IKE) should have been negotiated with the load balancer and it is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of front end proxy to the multiple servers behind it in transport mode. 2. My understanding of a 'pure' load balancer is that it distributes traffic streams to different resources available to it and this is typically based on rules such as source / destination IP protocols, ports (e.g. TCP ports) and potentially some other information. Furthermore, as some of the upper layer protocols are stateful (e.g. TCP), it is desirable for the load balancer to ensure that a higher layer 'session' (e.g. TCP session) is 'pegged' to a resource (server) that has been handling the same session - this allows efficient state maintenance on a given resource / server, instead of all resources needing access to that state. Now if the traffic is protected using IPsec, then the load balancer needs access to upper layer payload data in the packet in order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibility provides for a clean solution where the load-balancer (as well as other network monitoring tools) is able to ascertain that the packet if not encrypted and hence look inside the packet to analyze the protocol / ports to make load balancing decisions. In this case, IPsec is still being terminated on the server behind the load balancer, but the load balancer can examine the IPsec protected packet en-route to ensure it gets to the right server. In essence, this charter item allows the load balancer (and other network tools) to continue to function in IPsec environments. 3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change based on new protocols / payloads. Thanks, - Ken _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, October 21, 2008 1:37 PM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) OK. But if your load balancer is able to decrypt the traffic (i.e. it has the credentials or secret keys), then it can do that with today's normal IKE/IPsec. There is no need in this case to modify the protocol to make it easier to detect encrypted traffic. Thanks, Yaron _____ From: Gary Hemminger [mailto:ghemminger@foundrynet.com] Sent: Tuesday, October 21, 2008 19:02 To: Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) The use case you are thinking about is probably pure IPsec VPN, where an encrypted stream only lives across the WAN. But what if you are a load balancer and the IPsec traffic is end to end? In this case, you may have a load balancer that needs to terminate the traffic so it can make the decision which server to handle the request. All load balancers today support SSL termination. Same thing applies to IPsec traffic. We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic. Gary From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Tuesday, October 21, 2008 6:10 AM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) Hi Gary, I'm puzzled by the scenario you are presenting. I've been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that want to look at the IPsec-protected traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use case that you have in mind? Thanks, Yaron _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger Sent: Monday, October 20, 2008 20:26 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 I was talking about how to make the determination that the payload is encrypted. Evidently there are two approaches: one based on a heuristic, another based on a payload wrapper that flags the payload is encrypted. We would need some mechanism to determine the payload is encryped if we need to terminate the IPSEC traffic and make a determination of which server to send it to. Sorry about the confusion. Gary _____ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sat 10/18/2008 2:03 PM To: Gary Hemminger Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 Hi Gary. I'm not sure what heuristics you are talking about. The problem of re-authentication is simply this. The owner of the remote access gateway has a security policy that says that connections can be open for only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important part of risk management. If somebody steals your laptop (or mobile phone) or sits down at the Internet Cafe station where you were logged on, we want to limit the amount of time they are connected to the internal network. This requirement makes sense if the user has to type in their password to authenticate. It makes less sense if there are user certificates that are stored on the computer, or if the client software has a "save password" feature. Whether it makes sense or not, this is a requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are deleted. This creates a usability problem, because the SA is deleted without any advance warning to the user, so the user is likely to get a relatively long time with no connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to make accounts permanently offline when this happens. RFC 4778 and the improvement that Martin Willi is proposing, are aimed at solving this usability problem by informing the client software in advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The heuristic does not affect the security or the IPsec streams. Yoav On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: One comment on the heuristics approach. As a hardware vendor of L4-7 ADC boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended. What I mean is that the heuristic may be easy to define now, but there is no certainty that it would remain this way. My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway. While I like the idea of some "other" box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the "other" box, I think we should think about the long term, not the short term. Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit. Gary [IPsec] Reauthentication extension for IKEv2 _____ * To: Martin Willi strongswan.org> * Subject: [IPsec] Reauthentication extension for IKEv2 * From: Tero Kivinen > * Date: Tue, 16 Sep 2008 12:09:14 +0300 * Cc: ipsec at ietf.org * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com * Delivered-to: ipsec at core3.amsl.com * In-reply-to: <48CF5D7D.7070701 at strongswan.org> * List-archive: * List-help: * List-id: Discussion of IPsec protocols * List-post: * List-subscribe: , * List-unsubscribe: , * References: <48CF5D7D.7070701 at strongswan.org> * Sender: ipsec-bounces at ietf.org _____ Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... The first question I have is why are you doing reauthentication at all? What is the benefits of the reauthentication? What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have. -- kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec _____ * Follow-Ups: * Re: [IPsec] Reauthentication extension for IKEv2 * From: Martin Willi * References: * [IPsec] Reauthentication extension for IKEv2 * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 * Previous by thread: [IPsec] Reauthentication extension for IKEv2 * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 * Index(es): * Date * Thread Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IE Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. ------=_NextPart_001_02CD_01C9342D.74D41AC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Yaron, =

    The scenario I was referring to = requires the servers behind the load balancer to act as a cluster and hence on = the first ESP packet, obtain the IPsec SA from another member of the cluster with = which the SA was negotiated (this may be inherently done on the completion of = an IKE SA also). I have seen this deployed using a back-end dedicated = management interface for state synchronization. Remember, as far as the client is concerned, it is talking to just one server and does not see a cluster, = so the cluster of servers have to act as one to some degree, including = synchronization between them.

     

    Now, state synchronization on the = first packet (e.g. of a new TCP connection) is one thing and achievable, but = the real benefit of the load balancer is to ‘peg’ all subsequent = packets for that TCP session to the same server. This ensures that within a given = TCP (or another stateful protocol) session, there is no need to continually = synchronize the TCP state between all members of the server cluster – if this = was to be done, then the management / synchronization port between the cluster = members would generate more traffic then being received into the cluster, which = is not desirable or practical.

     

    So, from a load balancer point of = view, it can look into the ESP (null) packet and see if this is a new connection = (i.e. no existing rules based on IP/port information). If a new connection, it = can use whatever internal rules to assign this packet to any server with the = least load. On doing this, the load balancer updates internal rules to ensure = any subsequent packets for the same stream as sent to the same server as the initial packet – that is the benefit (this is what load balancers = do today for clear text traffic).

     

    I have also seen alternative = solutions proposed – e.g. A given server completing an IKE negotiation can = communicate 3-tuple (IP, SPI, protocol) information back to a load balancer and the = load balancer can utilize this for any subsequent decisions on assigning load = for IPsec encapsulated packet, but solutions like this require = synchronization between the load balancer and the servers, which is less desirable. For = any cluster of resources acting together to accommodate load balancing = solutions, a certain amount of inter-cluster communication is expected and that fits = in with the former solution above.

     

    Also remember, that IPsec E2E is = not widely deployed because of problems exactly like this one (loss of = visibility / control / functionality for intermediary devices) and this is what we = are trying to address.

     

    Thanks, =

    - Ken

     

    From: Yaron = Sheffer [mailto:yaronf@checkpoint.com]
    Sent: Tuesday, October = 21, 2008 3:23 PM
    To: Grewal, Ken; Gary = Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    Hi = Ken,

     

    Thanks for the clarification. But I = still don’t understand how your scenario = works.

     

    Assume for simplicity an = environment where everybody uses ESP in transport mode, with null = encryption.

     

    Client C1 does an IKE negotiation = with a random server (as selected by the load balancer) S1. They negotiate some = ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the = load balancer cannot learn the SPI value.

     

    Now when the first ESP packet is = sent from C1 towards the load balancer, there is not enough information for it to = forward the packet to S1, regardless of its being able to look into the = cleartext packet! Only S1 has the ESP keying material, and if LB forwards the = packet elsewhere, the receiver will not be able to verify its = integrity.

     

    Regards,

          =       Yaron

     

    From: = Grewal, Ken [mailto:ken.grewal@intel.com]
    Sent: Tuesday, October = 21, 2008 23:56
    To: Yaron Sheffer; Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    Some observations = below:

     

    1. I agree with Yaron in that if a load balancer needs to ‘terminate’ the traffic before applying any rules to distribute the load, then it should have the keys to do so without = any modifications to the current protocol. In this case, the session = setup (via IKE) should have been negotiated with the load balancer and it = is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of = front end proxy to the multiple servers behind it in transport mode. =
    2. My understanding of a ‘pure’ load balancer is that it = distributes traffic streams to different resources available to it and this is typically based on rules such as source / destination IP protocols, = ports (e.g. TCP ports) and potentially some other information. = Furthermore, as some of the upper layer protocols are stateful (e.g. TCP), it is = desirable for the load balancer to ensure that a higher layer = ‘session’ (e.g. TCP session) is ‘pegged’ to a resource (server) = that has been handling the same session – this allows efficient state maintenance on a given resource / server, instead of all resources = needing access to that state. Now if the traffic is protected using IPsec, = then the load balancer needs access to upper layer payload data in the = packet in order to apply the aforementioned rules for load balancing = decisions. The charter item on traffic visibility provides for a clean = solution where the load-balancer (as well as other network monitoring tools) is = able to ascertain that the packet if not encrypted and hence look inside = the packet to analyze the protocol / ports to make load balancing = decisions. In this case, IPsec is still being terminated on the server behind = the load balancer, but the load balancer can examine the IPsec = protected packet en-route to ensure it gets to the right server. In essence, = this charter item allows the load balancer (and other network tools) to continue = to function in IPsec environments.
    3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change = based on new protocols / payloads.

     

    Thanks, =

    - Ken

     

    From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer
    Sent: Tuesday, October = 21, 2008 1:37 PM
    To: Gary Hemminger; = Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    OK. But if your load balancer is = able to decrypt the traffic (i.e. it has the credentials or secret keys), then = it can do that with today’s normal IKE/IPsec. There is no need in this = case to modify the protocol to make it easier to detect encrypted = traffic.

     

    Thanks,

    =

          =       Yaron

     

    From: Gary = Hemminger [mailto:ghemminger@foundrynet.com]
    Sent: Tuesday, October = 21, 2008 19:02
    To: Yaron Sheffer; Yoav = Nir
    Cc: ipsec@ietf.org
    Subject: RE: Identifying = encrypted traffic (was: [IPsec] Reauthentication extension for = IKEv2)

     

    The use = case you are thinking about is probably pure IPsec VPN, where an encrypted stream = only lives across the WAN.  But what if you are a load balancer and the IPsec = traffic is end to end?  In this case, you may have a load balancer that = needs to terminate the traffic so it can make the decision which server to handle = the request.  All load balancers today support SSL termination.  = Same thing applies to IPsec traffic.  We cannot make the decision which = server to handle the request, nor can we maintain persistence without = decrypting the traffic. 

     <= /o:p>

    Gary

     <= /o:p>

    From: = Yaron Sheffer = [mailto:yaronf@checkpoint.com]
    Sent: Tuesday, October = 21, 2008 6:10 AM
    To: Gary Hemminger; = Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Identifying = encrypted traffic (was: [IPsec] Reauthentication extension for = IKEv2)

     

    Hi = Gary,

     

    I’m puzzled by the scenario = you are presenting. I’ve been considering the work on ESP-null detection = (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that want to look at the IPsec-protected = traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In = general, if you can terminate IPsec, that means that you have access to the = encryption keys and you can easily differentiate protected and unprotected traffic, Can = you explain the use case that you have in mind?

     

    Thanks,

    =

          =       Yaron

     

    From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger
    Sent: Monday, October 20, = 2008 20:26
    To: Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Reauthentication extension for IKEv2

     

    I was talking about how to make = the determination that the payload is encrypted.  Evidently there are = two approaches:  one based on a heuristic, another based on a payload = wrapper that flags the payload is encrypted.  We would need some mechanism = to determine the payload is encryped if we need to terminate the IPSEC = traffic and make a determination of which server to send it to.  Sorry about = the confusion.

     

    Gary

     

    From: Yoav Nir [mailto:ynir@checkpoint.com]
    Sent: Sat 10/18/2008 2:03 = PM
    To: Gary Hemminger
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Reauthentication extension for IKEv2

    Hi Gary.

     

    I'm not sure what heuristics you are talking about. The problem = of re-authentication is simply this. The owner of the remote access gateway = has a security policy that says that connections can be open for only so long = (say, 2 hours) without authenticating the user again. This is a favorite = requirement by auditors, who believe that this is an important part of risk management. = If somebody steals your laptop (or mobile phone) or sits down at the = Internet Cafe station where you were logged on, we want to limit the amount of time = they are connected to the internal network. This requirement makes sense if the = user has to type in their password to authenticate. It makes less sense if there = are user certificates that are stored on the computer, or if the client = software has a "save password" feature.

     

    Whether it makes sense or not, this is a requirement by auditors = and regulators. If the user does not re-authenticate within the specified = time, the IKE SA and all dependent child SAs are deleted.  This = creates a usability problem, because the SA is deleted without any advance warning = to the user, so the user is likely to get a relatively long time with no = connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook = tends to make accounts permanently offline when this = happens.

     

    RFC 4778 and the improvement that Martin Willi is proposing, are = aimed at solving this usability problem by informing the client software in = advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The = heuristic does not affect the security or the IPsec = streams.

     

    Yoav

     

    On Oct 18, 2008, at 2:35 AM, Gary Hemminger = wrote:

     

    One comment on the heuristics approach.  As a hardware vendor of L4-7 ADC boxes, I am a little = concerned about having to terminate IPSEC streams based on the heuristics = approach, because this is open ended.  What I mean is that the heuristic may = be easy to define now, but there is no certainty that it would remain this = way.  My past experience suggests that eventually the heuristic would become = too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway.  =  

    While I like the idea of some “other” box having to solve this issue, which prevents = clients from having to be changed, as we are a vendor of the “other” box, = I think we should think about the long term, not the short term.  = Just my opinion, and I am certainly flexible, but the heuristics approach = worries me a bit.

     

    Gary

     

    [IPsec] Reauthentication extension for = IKEv2

     
    Martin Willi =
writes:
    > What do you think about such =
an extension? Already considered =
something
    > similar, or does your =
reauthentication procedure work hassle-free? =
I'm
    > wondering if we are the only =
ones facing these problems or if such =
an
    > extension would gain broader =
acceptance...
     
    The first question I have is why =
are you doing reauthentication =
at
    all?
     
    What is the benefits of the =
reauthentication?
     
    What is the benefits of the =
reauthentication that can be done =
WITHOUT
    user intervention (i.e. no user =
typing in password or pin code =
or
    fingerprint or =
similar)?
     
    I myself can only really see =
benefits from reauthentication when =
it
    does require that user is really =
sitting there on the machine, =
and
    gives something that the machine =
itself cannot give. In those =
cases
    the user is required to type in =
something or do something =
anyways,
    thus it does not really matter if =
the communications is =
interrupted
    for second if user must stop his =
work for much longer time to type =
in
    his passphrase or pin =
code.
     
    The RFC 4478 simply skips this =
question and says "With some =
IPsec
    peers, particularly in the remote =
access scenario, it is desirable =
to
    repeat the mutual authentication =
periodically. The purpose of this =
is
    to limit the time that security =
associations (SAs) can be used by =
a
    third party who has gained =
control of the IPsec =
peer."
     
    In most cases if third party has =
gained control of the IPsec peer =
he
    will also get control of all =
authentication information inside =
the
    peer, including private keys and =
pre shared keys. Only way to =
make
    sure that he does not get access =
to those is to protect them =
with
    passphrase, or pin code or =
similar that is only known by the =
user.
     
    This is also said out in the RFC =
4478: "However, in the remote =
access
    scenario it is usually up to a =
human user to supply the
    authentication credentials =
..."
     
    Because of this I do not think =
there is that much requirement =
for
    reauthentication protocol that is =
faster than what we already have. =

    -- =

    kivinen at =
safenet-inc.com
    __________________________________=
_____________
    IPsec mailing =
list
    IPsec at =
ietf.org
    https://www.ietf.org=
/mailman/listinfo/ipsec
     
     


    


    


    




      
 
    • Follow-Ups: =

      • 

    




      
 
        
  
          
   
        • From: Martin
       Willi
          • 
  
        
 
      

    


      
 
    • References: =

      • 

    




      
 
        
  
          
   
        • From: Martin
       Willi
          • 
  
        
 
      

    





    


    Note: Messages sent to this list are the opinions of =
the
senders and do not imply endorsement by the =
IE
    


    


     



    Scanned by Check Point Total Security Gateway. 

    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org= /mailman/listinfo/ipsec

     



    Scanned by Check Point Total Security Gateway. =



    Scanned by Check Point Total Security Gateway. =

    ------=_NextPart_001_02CD_01C9342D.74D41AC0-- ------=_NextPart_000_02CC_01C9342D.74D41AC0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYCTCCAyAw ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05 ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3 wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1 hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8 7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3 ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4 lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+ iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0 Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69 tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFYzCCBEugAwIBAgIKYSyUiQAA AAAABTANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wNjAzMjIy MjIyNDJaFw0xMjAzMjIyMjMyNDJaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKvXqH/ah10uJc7YzQUh+XEDNqS6IsXOyqCtizr9 x6F+v6iRAbvddRRJRWixfV78qarSN9WMymJ90M8c9/Dfr1yzFuq95RgCAF3vdve3wKi7kJv6lkMJ wyyB+uIYcWtljYx2LDqbb9S6Z6He3q8W/aGKvu23I9ksNx+cmZcDNZwGdXVIEHpEMyA4bp0RvYtf p8BsGAyn6YuK63HugeyYdeFL+4+Wz2tGUqw9OWhob6oV1oDH3zboLhHJiQ2oIj3jAJ3/LrIkzcWP 2R20UIliDAPAAl6MNWJPdsNK5EEeuxEuUSpdFsMj5rBmPHH4U8i8rUmi6GEOcX5rwAw64AzS3gEC AwEAAaOCAjUwggIxMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFAlpgTN7BnOPI0wKA9/3FoER ghMFMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIBADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBi AEMAQTAfBgNVHSMEGDAWgBQaxgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGs oIGphk5odHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFs JTIwQmFzaWMlMjBQb2xpY3klMjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29t L3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNy bDCB4wYIKwYBBQUHAQEEgdYwgdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3Jl cG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUy MENBLmNydDBsBggrBgEFBQcwAoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3Np dG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0Eu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCuNCnecJ+vDpXzsHOzMEyz4KgTNDbJROHag8H/ZVga7soc oJyC+HKqDfQgxifVorbTbSajCBEAxqg6bbNWBJ6qKOFHneBrXkENf5WdD50eCTCFWRV3EIsHEOQ1 kP0eNYV5Ed4hp9y6wASV6z2z86O4+qouLJiow4AIhoCKD8rEyD7ODgTvjvLCKpsVyPlG1jOVSsOS IF2VUmueAmK3RFU4np83zerK/j0G37owhniEDT6ZhwkUd0XL45nt1m7yApMEbnXUTHNaXnE+P98k k3nDXdW25sB+5xWcYR3GpgMdQiZgP/f0KZ+yZKNE7gcp3I/O4pXqUNWIsLSYTi3soAR2MIIF9zCC BN+gAwIBAgIKG5+jTgAAAAAg/jANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UE ChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3Vp bmcgQ0EgM0EwHhcNMDgwNjAyMTU1MzQxWhcNMTEwNjAyMTU1MzQxWjA7MRQwEgYDVQQDEwtHcmV3 YWwsIEtlbjEjMCEGCSqGSIb3DQEJARYUa2VuLmdyZXdhbEBpbnRlbC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC4FCPKjpfz6Mt/j1HuGDmHHXcamuS7gQlfSOQy+phBM4G2Jqw+ oYdOmEj3FadVI6osyhOShSj7mvFE+2UkDyEeIAD1LJrjJHC03jkl5Ll1YrxeNpYN/EMlSCtZZ2iW hd6M0uk+e408Zx2lD06ju+EJ2uNZ4Hux6COGT0cnm8oeL2Lr0eRUM/SdqOGw/LM3btEg6WUfN2MJ 3NeE7TvPifTPSQMMAh7mBzW2YUNem4Cj4uq+vacrn0zEijuh3/wCsn8M7GF1uDBjv7WM9jB/P+lD yCA9hOPxsD+4++AtAkDYm/DAUvarOa3jSAOXPv1PBLexJru6J3a30h1ZbHT1AX9bAgMBAAGjggLg MIIC3DALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFDjNfXcVsj96VG4IIV5BNTJmL9nAMDwGCSsGAQQB gjcVBwQvMC0GJSsGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJZ4HevTmV8EMCAWQCAQYwHwYD VR0jBBgwFoAUCWmBM3sGc48jTAoD3/cWgRGCEwUwgckGA1UdHwSBwTCBvjCBu6CBuKCBtYZUaHR0 cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2lj JTIwSXNzdWluZyUyMENBJTIwM0EuY3Jshl1odHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9y ZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAz QS5jcmwwge8GCCsGAQUFBwEBBIHiMIHfMGkGCCsGAQUFBzAChl1odHRwOi8vd3d3LmludGVsLmNv bS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1 aW5nJTIwQ0ElMjAzQS5jcnQwcgYIKwYBBQUHMAKGZmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwu Y29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElz c3VpbmclMjBDQSUyMDNBLmNydDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDApBgkr BgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwwwRQYDVR0RBD4wPKAkBgorBgEE AYI3FAIDoBYMFGtlbi5ncmV3YWxAaW50ZWwuY29tgRRrZW4uZ3Jld2FsQGludGVsLmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAorkt9OOF3L7PME5cQ/2ZXtVbS07RUTBsu+nuHQygUbgYt0sUsnL0G+CA +fu+2R8RrLKvFSsCdkw8FHi+DSaIuYXxQkof+B8GN/9AJ+Xt2zf1Y36ILLoBdwKAwG2GmVEngUoc 0FQQZ9n3GB7DSIK0wKXNwWILJSlnHW0nq5j1k3zP/pmpWe/xv10UGL/otML5weJl0BUDkSoxMES9 Zzi0/Ph4/vENFnZwvbzrLbxi5/wZLsD3KK9PofcAEqXi4z33QIW4Thd8IQzc+UzvRDXS1On+DZyH RbGt9/7GAwfVoFlswIb+/yGds/LuBTxUsVe1d1MRrmeTBniv4UL9Dt2jRjCCBj4wggUmoAMCAQIC Chue2YYAAAAAIP0wDQYJKoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVs IENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDNB MB4XDTA4MDYwMjE1NTI0M1oXDTExMDYwMjE1NTI0M1owOzEUMBIGA1UEAxMLR3Jld2FsLCBLZW4x IzAhBgkqhkiG9w0BCQEWFGtlbi5ncmV3YWxAaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA9OP+3itCo/qwJlycjkVscHNGVD6syIQkohfFYGbEwgXDmZ11Mjnfly9kIKmb qJi4AmQLbzxiCNLhze/iWE9oS9q7oTron00id0Jq8RFugV0exfAeZxpsZORofjcq5gpUUAGcMONT 0e8CS9JcQ+X9imcanwXgIpmWs6w5L0j49Lnx3Q5chY3RNp3TZJZlQ5XNVw68ZTj5KBzLRsJGdym9 vMKKvzgkyQVDswbFvnl/AdM2A9X0SLzdmmCOuIxXMLxClqEQfjWq7oVq0U4j7eGk+RkP0Phj02xP qP+VOmXCU8AEAVIO/809uKvPjK8rSEEIybKEb+s/8jWtlw1bH3FyTQIDAQABo4IDJzCCAyMwCwYD VR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIA gDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUznBDWAHsnnyH0lGMsHGgDuEq7HYwPQYJ KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhsOMdYSZ5VGD/YEohY6fU4KRwAlnhLnZQYeE/04CAWQC AQkwHwYDVR0jBBgwFoAUCWmBM3sGc48jTAoD3/cWgRGCEwUwgckGA1UdHwSBwTCBvjCBu6CBuKCB tYZUaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0EuY3Jshl1odHRwOi8vY2VydGlmaWNhdGVzLmludGVs LmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIw Q0ElMjAzQS5jcmwwge8GCCsGAQUFBwEBBIHiMIHfMGkGCCsGAQUFBzAChl1odHRwOi8vd3d3Lmlu dGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMl MjBJc3N1aW5nJTIwQ0ElMjAzQS5jcnQwcgYIKwYBBQUHMAKGZmh0dHA6Ly9jZXJ0aWZpY2F0ZXMu aW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNp YyUyMElzc3VpbmclMjBDQSUyMDNBLmNydDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoD BDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQwRQYDVR0RBD4wPKAk BgorBgEEAYI3FAIDoBYMFGtlbi5ncmV3YWxAaW50ZWwuY29tgRRrZW4uZ3Jld2FsQGludGVsLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEALND1Kg3D0peyUCD/XDB7cpsOWB8zf6omdTwotvEUWZo+KTxB xP5jW3wg++RRfjm5/NoSxJDzEYUTIByV8wI/qlGPPMnFu8MePB3YazYj5UPmgAQzgNTZfKj4UNgG R80voebkkzRBiFsa3j/dd6XHdAf7B+Rsl4ryUzSb87CkAdJVsEadHgjDM+Ft56oumvWzl+v7JWCk BmGPAlUnJGbpREoqWvesP5nGChYh77GYvHDRrSMgpFJ/x30V91BHwEQgSOPPccvf6OZqUJuSc7zT ElztMjoPIL9hjxNsz45KlkEk28siciKUwq2Jx0lnWJiVSL1svhV2DlXSUvn2a4VGWTGCA0EwggM9 AgEBMGQwVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQD EyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDNBAgobn6NOAAAAACD+MAkGBSsOAwIa BQCgggGyMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyMjE3 MDMzOVowIwYJKoZIhvcNAQkEMRYEFMjnnCFe0W0ABhynwsSIvsK2kdPCMGcGCSqGSIb3DQEJDzFa MFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMHMGCSsGAQQBgjcQBDFmMGQwVjELMAkG A1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRl cm5hbCBCYXNpYyBJc3N1aW5nIENBIDNBAgobntmGAAAAACD9MHUGCyqGSIb3DQEJEAILMWagZDBW MQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVs IEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ECChue2YYAAAAAIP0wDQYJKoZIhvcNAQEBBQAE ggEAp6tdlNCb5dNJRkX9H1+/tURpGZcXp/kkS8SolxH1GbRX0mk4ZSp+ceNjwlogYpKHuv0dnFM3 r6bx/A1G62mKB9CqagIAcFirIxvbfFUukj7CS83FNu2DxWeDZUGU2wdnGMKfRufyGGeqSzdLk7v2 ktVR0xccB7OCgVQYzTkDzTiIZ7STd6zQElzD+W71w9+Ji3gbnExl915A40fTTlqraFQlrpqEbLJQ ik+Iw9skjOYX3xxIozNRseGsATqDVMIh4I7yQqLGbJrghaDkQts56UIxHmgzVV5jvEew5yEtQo7C Gg22V8B4RV8sdtwVPfuc7l8Mthk+HQ7QuqoxAPZ5ZQAAAAAAAA== ------=_NextPart_000_02CC_01C9342D.74D41AC0-- --===============0045617033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0045617033==-- From ipsec-bounces@ietf.org Wed Oct 22 10:09:57 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3183A6949; Wed, 22 Oct 2008 10:09:57 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9F3A3A6949 for ; Wed, 22 Oct 2008 10:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8CNXXCj-27B for ; Wed, 22 Oct 2008 10:09:37 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id EC3F23A686B for ; Wed, 22 Oct 2008 10:09:36 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 22 Oct 2008 10:05:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.33,465,1220252400"; d="p7s'?scan'208,217";a="351235683" Received: from azsmsx602.amr.corp.intel.com ([10.2.121.201]) by orsmga002.jf.intel.com with ESMTP; 22 Oct 2008 10:09:38 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by azsmsx602.amr.corp.intel.com (10.2.121.201) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 22 Oct 2008 10:10:09 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Wed, 22 Oct 2008 11:09:58 -0600 From: "Grewal, Ken" To: Yaron Sheffer , Gary Hemminger , Yoav Nir Date: Wed, 22 Oct 2008 11:09:24 -0600 Thread-Topic: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkhACbyvnAACETf8AAHhWiAAAKQj8AAALjDUAAD0PSgAA7QhJAAFRZWMA== Message-ID: References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC80B@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC80B@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0614576283==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0614576283== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02F7_01C9342E.42151E30" ------=_NextPart_000_02F7_01C9342E.42151E30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02F8_01C9342E.42151E30" ------=_NextPart_001_02F8_01C9342E.42151E30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Gary, I agree with Yaron here. The scenario you are describing can be done today if the load balancer can act as an IPsec termination point and nothing new is needed. Also, please see my other response on using a load balancer which does not terminate IPsec, but can benefit from the changes being proposed. Let me know if I am missing something. Thanks, - Ken _____ From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Wednesday, October 22, 2008 12:03 AM To: Gary Hemminger; Grewal, Ken; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) In that case, the load balancer can identify the traffic using the normal ESP SPI field, and knows exactly what kind of traffic it is and whether it is encrypted. There is no need to change the ESP protocol for this scenario. Thanks, Yaron _____ From: Gary Hemminger [mailto:ghemminger@foundrynet.com] Sent: Wednesday, October 22, 2008 2:00 To: Yaron Sheffer; Grewal, Ken; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) The client would negotiate IKE with the load balancer and would not directly negotiate with the Server. Gary From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Tuesday, October 21, 2008 3:23 PM To: Grewal, Ken; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Hi Ken, Thanks for the clarification. But I still don't understand how your scenario works. Assume for simplicity an environment where everybody uses ESP in transport mode, with null encryption. Client C1 does an IKE negotiation with a random server (as selected by the load balancer) S1. They negotiate some ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn the SPI value. Now when the first ESP packet is sent from C1 towards the load balancer, there is not enough information for it to forward the packet to S1, regardless of its being able to look into the cleartext packet! Only S1 has the ESP keying material, and if LB forwards the packet elsewhere, the receiver will not be able to verify its integrity. Regards, Yaron _____ From: Grewal, Ken [mailto:ken.grewal@intel.com] Sent: Tuesday, October 21, 2008 23:56 To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Some observations below: 1. I agree with Yaron in that if a load balancer needs to 'terminate' the traffic before applying any rules to distribute the load, then it should have the keys to do so without any modifications to the current protocol. In this case, the session setup (via IKE) should have been negotiated with the load balancer and it is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of front end proxy to the multiple servers behind it in transport mode. 2. My understanding of a 'pure' load balancer is that it distributes traffic streams to different resources available to it and this is typically based on rules such as source / destination IP protocols, ports (e.g. TCP ports) and potentially some other information. Furthermore, as some of the upper layer protocols are stateful (e.g. TCP), it is desirable for the load balancer to ensure that a higher layer 'session' (e.g. TCP session) is 'pegged' to a resource (server) that has been handling the same session - this allows efficient state maintenance on a given resource / server, instead of all resources needing access to that state. Now if the traffic is protected using IPsec, then the load balancer needs access to upper layer payload data in the packet in order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibility provides for a clean solution where the load-balancer (as well as other network monitoring tools) is able to ascertain that the packet if not encrypted and hence look inside the packet to analyze the protocol / ports to make load balancing decisions. In this case, IPsec is still being terminated on the server behind the load balancer, but the load balancer can examine the IPsec protected packet en-route to ensure it gets to the right server. In essence, this charter item allows the load balancer (and other network tools) to continue to function in IPsec environments. 3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change based on new protocols / payloads. Thanks, - Ken _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, October 21, 2008 1:37 PM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) OK. But if your load balancer is able to decrypt the traffic (i.e. it has the credentials or secret keys), then it can do that with today's normal IKE/IPsec. There is no need in this case to modify the protocol to make it easier to detect encrypted traffic. Thanks, Yaron _____ From: Gary Hemminger [mailto:ghemminger@foundrynet.com] Sent: Tuesday, October 21, 2008 19:02 To: Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) The use case you are thinking about is probably pure IPsec VPN, where an encrypted stream only lives across the WAN. But what if you are a load balancer and the IPsec traffic is end to end? In this case, you may have a load balancer that needs to terminate the traffic so it can make the decision which server to handle the request. All load balancers today support SSL termination. Same thing applies to IPsec traffic. We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic. Gary From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Tuesday, October 21, 2008 6:10 AM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) Hi Gary, I'm puzzled by the scenario you are presenting. I've been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that want to look at the IPsec-protected traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use case that you have in mind? Thanks, Yaron _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger Sent: Monday, October 20, 2008 20:26 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 I was talking about how to make the determination that the payload is encrypted. Evidently there are two approaches: one based on a heuristic, another based on a payload wrapper that flags the payload is encrypted. We would need some mechanism to determine the payload is encryped if we need to terminate the IPSEC traffic and make a determination of which server to send it to. Sorry about the confusion. Gary _____ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sat 10/18/2008 2:03 PM To: Gary Hemminger Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 Hi Gary. I'm not sure what heuristics you are talking about. The problem of re-authentication is simply this. The owner of the remote access gateway has a security policy that says that connections can be open for only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important part of risk management. If somebody steals your laptop (or mobile phone) or sits down at the Internet Cafe station where you were logged on, we want to limit the amount of time they are connected to the internal network. This requirement makes sense if the user has to type in their password to authenticate. It makes less sense if there are user certificates that are stored on the computer, or if the client software has a "save password" feature. Whether it makes sense or not, this is a requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are deleted. This creates a usability problem, because the SA is deleted without any advance warning to the user, so the user is likely to get a relatively long time with no connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to make accounts permanently offline when this happens. RFC 4778 and the improvement that Martin Willi is proposing, are aimed at solving this usability problem by informing the client software in advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The heuristic does not affect the security or the IPsec streams. Yoav On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: One comment on the heuristics approach. As a hardware vendor of L4-7 ADC boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended. What I mean is that the heuristic may be easy to define now, but there is no certainty that it would remain this way. My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway. While I like the idea of some "other" box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the "other" box, I think we should think about the long term, not the short term. Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit. Gary [IPsec] Reauthentication extension for IKEv2 _____ * To: Martin Willi strongswan.org> * Subject: [IPsec] Reauthentication extension for IKEv2 * From: Tero Kivinen > * Date: Tue, 16 Sep 2008 12:09:14 +0300 * Cc: ipsec at ietf.org * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com * Delivered-to: ipsec at core3.amsl.com * In-reply-to: <48CF5D7D.7070701 at strongswan.org> * List-archive: * List-help: * List-id: Discussion of IPsec protocols * List-post: * List-subscribe: , * List-unsubscribe: , * References: <48CF5D7D.7070701 at strongswan.org> * Sender: ipsec-bounces at ietf.org _____ Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... The first question I have is why are you doing reauthentication at all? What is the benefits of the reauthentication? What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have. -- kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec _____ * Follow-Ups: * Re: [IPsec] Reauthentication extension for IKEv2 * From: Martin Willi * References: * [IPsec] Reauthentication extension for IKEv2 * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 * Previous by thread: [IPsec] Reauthentication extension for IKEv2 * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 * Index(es): * Date * Thread Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IE Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. ------=_NextPart_001_02F8_01C9342E.42151E30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_02F8_01C9342E.42151E30-- ------=_NextPart_000_02F7_01C9342E.42151E30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYCTCCAyAw ggKJoAMCAQICBDXe9M8wDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0Vx dWlmYXgxLTArBgNVBAsTJEVxdWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw05 ODA4MjIxNjQxNTFaFw0xODA4MjIxNjQxNTFaME4xCzAJBgNVBAYTAlVTMRAwDgYDVQQKEwdFcXVp ZmF4MS0wKwYDVQQLEyRFcXVpZmF4IFNlY3VyZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwgZ8wDQYJ KoZIhvcNAQEBBQADgY0AMIGJAoGBAMFdsVhnCGLuoJotHwhtkRRomAoe/toEbxOEYiHD0XzOnwXg uAHwTjTs4oqVBGSs8WtTXwWzy2eAv0ICjv7dAQns4QAUT/z78AzdQ7pbK+EfgHCZFVeTFvEPl2q3 wmgjHMxNWTCsUR47ryvW7mNFe8XZX1DS41APOojnvxT94Me5AgMBAAGjggEJMIIBBTBwBgNVHR8E aTBnMGWgY6BhpF8wXTELMAkGA1UEBhMCVVMxEDAOBgNVBAoTB0VxdWlmYXgxLTArBgNVBAsTJEVx dWlmYXggU2VjdXJlIENlcnRpZmljYXRlIEF1dGhvcml0eTENMAsGA1UEAxMEQ1JMMTAaBgNVHRAE EzARgQ8yMDE4MDgyMjE2NDE1MVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFEjmaPkr0rKV10fY IyAQTzOYkJ/UMB0GA1UdDgQWBBRI5mj5K9KylddH2CMgEE8zmJCf1DAMBgNVHRMEBTADAQH/MBoG CSqGSIb2fQdBAAQNMAsbBVYzLjBjAwIGwDANBgkqhkiG9w0BAQUFAAOBgQBYzinq/Pfetc4CuRe1 hdG54+CVzCUxDQCmkm5/tpJjnlCV0Zpv5BHeY4VumO6o/1rI01WyZnFX3sAh6z0qpyNJAQSGQnv8 7n+iFlK1Z2fTQNs7JliyKHc9rhR3Ydb6KmYnoA36p3Nc6nDxlCFlRF/6/O8paKmih3nvee9PrAd3 ODCCAz0wggKmoAMCAQICAwWw/zANBgkqhkiG9w0BAQUFADBOMQswCQYDVQQGEwJVUzEQMA4GA1UE ChMHRXF1aWZheDEtMCsGA1UECxMkRXF1aWZheCBTZWN1cmUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MB4XDTA2MDIxNjE4MDEzMFoXDTE2MDIxOTE4MDEzMFowUjELMAkGA1UEBhMCVVMxGjAYBgNVBAoT EUludGVsIENvcnBvcmF0aW9uMScwJQYDVQQDEx5JbnRlbCBFeHRlcm5hbCBCYXNpYyBQb2xpY3kg Q0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDBpd/XOb9QVqEZ8mQ1042TdOIq3ATD IsV2xDyt30yLyMR5Wjtus0bn3B+he89BiNO/LP6+rFzEwlD55PlX+HLGIKeNNG97dqyc30FElEUj ZzTZFq2N4e3kVJ/XAEEgANzV8v9qp7qWwxugPgfc3z9BkYot+CifozexHLb/hEZj+yISCU61kRZv uSQ0E11yYL4dRgcglJeaHo3oX57rvIckaLsYV5/1Aj+R8DM1Ppk965XQAKsHfnyT7C4S50T4lVn4 lz36wOdNZn/zegG1zp41lnoTFfT4KuKVJH5x7YD1p6KbgJCKLovnujGuohquBNfdXKpZkvz6pGv+ iC1HawJdAgMBAAGjgaAwgZ0wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaxgxKxEdvqNutK/D0 Vgaj7TdUDDA6BgNVHR8EMzAxMC+gLaArhilodHRwOi8vY3JsLmdlb3RydXN0LmNvbS9jcmxzL3Nl Y3VyZWNhLmNybDAfBgNVHSMEGDAWgBRI5mj5K9KylddH2CMgEE8zmJCf1DAPBgNVHRMBAf8EBTAD AQH/MA0GCSqGSIb3DQEBBQUAA4GBABMQOK2kVKVIlUWwLTdywJ+e2O+PC/uQltK2F3lRyrPfBn69 tOkIP4SgDJOfsxyobIrPLe75kBLw+Dom13OBDp/EMZJZ1CglQfVV8co9mT3aZMjSGGQiMgkJLR3j Mfr900fXZKj5XeqCJ+JP0mEhJGEdVCY+FFlksJjV86fDrq1QMIIFYzCCBEugAwIBAgIKYSyUiQAA AAAABTANBgkqhkiG9w0BAQUFADBSMQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9y YXRpb24xJzAlBgNVBAMTHkludGVsIEV4dGVybmFsIEJhc2ljIFBvbGljeSBDQTAeFw0wNjAzMjIy MjIyNDJaFw0xMjAzMjIyMjMyNDJaMFYxCzAJBgNVBAYTAlVTMRowGAYDVQQKExFJbnRlbCBDb3Jw b3JhdGlvbjErMCkGA1UEAxMiSW50ZWwgRXh0ZXJuYWwgQmFzaWMgSXNzdWluZyBDQSAzQTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKvXqH/ah10uJc7YzQUh+XEDNqS6IsXOyqCtizr9 x6F+v6iRAbvddRRJRWixfV78qarSN9WMymJ90M8c9/Dfr1yzFuq95RgCAF3vdve3wKi7kJv6lkMJ wyyB+uIYcWtljYx2LDqbb9S6Z6He3q8W/aGKvu23I9ksNx+cmZcDNZwGdXVIEHpEMyA4bp0RvYtf p8BsGAyn6YuK63HugeyYdeFL+4+Wz2tGUqw9OWhob6oV1oDH3zboLhHJiQ2oIj3jAJ3/LrIkzcWP 2R20UIliDAPAAl6MNWJPdsNK5EEeuxEuUSpdFsMj5rBmPHH4U8i8rUmi6GEOcX5rwAw64AzS3gEC AwEAAaOCAjUwggIxMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFAlpgTN7BnOPI0wKA9/3FoER ghMFMAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEEAwIBADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBi AEMAQTAfBgNVHSMEGDAWgBQaxgxKxEdvqNutK/D0Vgaj7TdUDDCBvQYDVR0fBIG1MIGyMIGvoIGs oIGphk5odHRwOi8vd3d3LmludGVsLmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFs JTIwQmFzaWMlMjBQb2xpY3klMjBDQS5jcmyGV2h0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwuY29t L3JlcG9zaXRvcnkvQ1JML0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUyMENBLmNy bDCB4wYIKwYBBQUHAQEEgdYwgdMwYwYIKwYBBQUHMAKGV2h0dHA6Ly93d3cuaW50ZWwuY29tL3Jl cG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMFBvbGljeSUy MENBLmNydDBsBggrBgEFBQcwAoZgaHR0cDovL2NlcnRpZmljYXRlcy5pbnRlbC5jb20vcmVwb3Np dG9yeS9jZXJ0aWZpY2F0ZXMvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2ljJTIwUG9saWN5JTIwQ0Eu Y3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCuNCnecJ+vDpXzsHOzMEyz4KgTNDbJROHag8H/ZVga7soc oJyC+HKqDfQgxifVorbTbSajCBEAxqg6bbNWBJ6qKOFHneBrXkENf5WdD50eCTCFWRV3EIsHEOQ1 kP0eNYV5Ed4hp9y6wASV6z2z86O4+qouLJiow4AIhoCKD8rEyD7ODgTvjvLCKpsVyPlG1jOVSsOS IF2VUmueAmK3RFU4np83zerK/j0G37owhniEDT6ZhwkUd0XL45nt1m7yApMEbnXUTHNaXnE+P98k k3nDXdW25sB+5xWcYR3GpgMdQiZgP/f0KZ+yZKNE7gcp3I/O4pXqUNWIsLSYTi3soAR2MIIF9zCC BN+gAwIBAgIKG5+jTgAAAAAg/jANBgkqhkiG9w0BAQUFADBWMQswCQYDVQQGEwJVUzEaMBgGA1UE ChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVsIEV4dGVybmFsIEJhc2ljIElzc3Vp bmcgQ0EgM0EwHhcNMDgwNjAyMTU1MzQxWhcNMTEwNjAyMTU1MzQxWjA7MRQwEgYDVQQDEwtHcmV3 YWwsIEtlbjEjMCEGCSqGSIb3DQEJARYUa2VuLmdyZXdhbEBpbnRlbC5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC4FCPKjpfz6Mt/j1HuGDmHHXcamuS7gQlfSOQy+phBM4G2Jqw+ oYdOmEj3FadVI6osyhOShSj7mvFE+2UkDyEeIAD1LJrjJHC03jkl5Ll1YrxeNpYN/EMlSCtZZ2iW hd6M0uk+e408Zx2lD06ju+EJ2uNZ4Hux6COGT0cnm8oeL2Lr0eRUM/SdqOGw/LM3btEg6WUfN2MJ 3NeE7TvPifTPSQMMAh7mBzW2YUNem4Cj4uq+vacrn0zEijuh3/wCsn8M7GF1uDBjv7WM9jB/P+lD yCA9hOPxsD+4++AtAkDYm/DAUvarOa3jSAOXPv1PBLexJru6J3a30h1ZbHT1AX9bAgMBAAGjggLg MIIC3DALBgNVHQ8EBAMCB4AwHQYDVR0OBBYEFDjNfXcVsj96VG4IIV5BNTJmL9nAMDwGCSsGAQQB gjcVBwQvMC0GJSsGAQQBgjcVCIbDjHWEmeVRg/2BKIWOn1OCkcAJZ4HevTmV8EMCAWQCAQYwHwYD VR0jBBgwFoAUCWmBM3sGc48jTAoD3/cWgRGCEwUwgckGA1UdHwSBwTCBvjCBu6CBuKCBtYZUaHR0 cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUyMEJhc2lj JTIwSXNzdWluZyUyMENBJTIwM0EuY3Jshl1odHRwOi8vY2VydGlmaWNhdGVzLmludGVsLmNvbS9y ZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIwQ0ElMjAz QS5jcmwwge8GCCsGAQUFBwEBBIHiMIHfMGkGCCsGAQUFBzAChl1odHRwOi8vd3d3LmludGVsLmNv bS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1 aW5nJTIwQ0ElMjAzQS5jcnQwcgYIKwYBBQUHMAKGZmh0dHA6Ly9jZXJ0aWZpY2F0ZXMuaW50ZWwu Y29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNpYyUyMElz c3VpbmclMjBDQSUyMDNBLmNydDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDApBgkr BgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwwwRQYDVR0RBD4wPKAkBgorBgEE AYI3FAIDoBYMFGtlbi5ncmV3YWxAaW50ZWwuY29tgRRrZW4uZ3Jld2FsQGludGVsLmNvbTANBgkq hkiG9w0BAQUFAAOCAQEAorkt9OOF3L7PME5cQ/2ZXtVbS07RUTBsu+nuHQygUbgYt0sUsnL0G+CA +fu+2R8RrLKvFSsCdkw8FHi+DSaIuYXxQkof+B8GN/9AJ+Xt2zf1Y36ILLoBdwKAwG2GmVEngUoc 0FQQZ9n3GB7DSIK0wKXNwWILJSlnHW0nq5j1k3zP/pmpWe/xv10UGL/otML5weJl0BUDkSoxMES9 Zzi0/Ph4/vENFnZwvbzrLbxi5/wZLsD3KK9PofcAEqXi4z33QIW4Thd8IQzc+UzvRDXS1On+DZyH RbGt9/7GAwfVoFlswIb+/yGds/LuBTxUsVe1d1MRrmeTBniv4UL9Dt2jRjCCBj4wggUmoAMCAQIC Chue2YYAAAAAIP0wDQYJKoZIhvcNAQEFBQAwVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVs IENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDNB MB4XDTA4MDYwMjE1NTI0M1oXDTExMDYwMjE1NTI0M1owOzEUMBIGA1UEAxMLR3Jld2FsLCBLZW4x IzAhBgkqhkiG9w0BCQEWFGtlbi5ncmV3YWxAaW50ZWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA9OP+3itCo/qwJlycjkVscHNGVD6syIQkohfFYGbEwgXDmZ11Mjnfly9kIKmb qJi4AmQLbzxiCNLhze/iWE9oS9q7oTron00id0Jq8RFugV0exfAeZxpsZORofjcq5gpUUAGcMONT 0e8CS9JcQ+X9imcanwXgIpmWs6w5L0j49Lnx3Q5chY3RNp3TZJZlQ5XNVw68ZTj5KBzLRsJGdym9 vMKKvzgkyQVDswbFvnl/AdM2A9X0SLzdmmCOuIxXMLxClqEQfjWq7oVq0U4j7eGk+RkP0Phj02xP qP+VOmXCU8AEAVIO/809uKvPjK8rSEEIybKEb+s/8jWtlw1bH3FyTQIDAQABo4IDJzCCAyMwCwYD VR0PBAQDAgQwMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIA gDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUznBDWAHsnnyH0lGMsHGgDuEq7HYwPQYJ KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIhsOMdYSZ5VGD/YEohY6fU4KRwAlnhLnZQYeE/04CAWQC AQkwHwYDVR0jBBgwFoAUCWmBM3sGc48jTAoD3/cWgRGCEwUwgckGA1UdHwSBwTCBvjCBu6CBuKCB tYZUaHR0cDovL3d3dy5pbnRlbC5jb20vcmVwb3NpdG9yeS9DUkwvSW50ZWwlMjBFeHRlcm5hbCUy MEJhc2ljJTIwSXNzdWluZyUyMENBJTIwM0EuY3Jshl1odHRwOi8vY2VydGlmaWNhdGVzLmludGVs LmNvbS9yZXBvc2l0b3J5L0NSTC9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMlMjBJc3N1aW5nJTIw Q0ElMjAzQS5jcmwwge8GCCsGAQUFBwEBBIHiMIHfMGkGCCsGAQUFBzAChl1odHRwOi8vd3d3Lmlu dGVsLmNvbS9yZXBvc2l0b3J5L2NlcnRpZmljYXRlcy9JbnRlbCUyMEV4dGVybmFsJTIwQmFzaWMl MjBJc3N1aW5nJTIwQ0ElMjAzQS5jcnQwcgYIKwYBBQUHMAKGZmh0dHA6Ly9jZXJ0aWZpY2F0ZXMu aW50ZWwuY29tL3JlcG9zaXRvcnkvY2VydGlmaWNhdGVzL0ludGVsJTIwRXh0ZXJuYWwlMjBCYXNp YyUyMElzc3VpbmclMjBDQSUyMDNBLmNydDAfBgNVHSUEGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoD BDApBgkrBgEEAYI3FQoEHDAaMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQwRQYDVR0RBD4wPKAk BgorBgEEAYI3FAIDoBYMFGtlbi5ncmV3YWxAaW50ZWwuY29tgRRrZW4uZ3Jld2FsQGludGVsLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEALND1Kg3D0peyUCD/XDB7cpsOWB8zf6omdTwotvEUWZo+KTxB xP5jW3wg++RRfjm5/NoSxJDzEYUTIByV8wI/qlGPPMnFu8MePB3YazYj5UPmgAQzgNTZfKj4UNgG R80voebkkzRBiFsa3j/dd6XHdAf7B+Rsl4ryUzSb87CkAdJVsEadHgjDM+Ft56oumvWzl+v7JWCk BmGPAlUnJGbpREoqWvesP5nGChYh77GYvHDRrSMgpFJ/x30V91BHwEQgSOPPccvf6OZqUJuSc7zT ElztMjoPIL9hjxNsz45KlkEk28siciKUwq2Jx0lnWJiVSL1svhV2DlXSUvn2a4VGWTGCA0EwggM9 AgEBMGQwVjELMAkGA1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQD EyJJbnRlbCBFeHRlcm5hbCBCYXNpYyBJc3N1aW5nIENBIDNBAgobn6NOAAAAACD+MAkGBSsOAwIa BQCgggGyMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyMjE3 MDkyM1owIwYJKoZIhvcNAQkEMRYEFBfJyXEKUPY1lWXRmIlrXXiGNqbPMGcGCSqGSIb3DQEJDzFa MFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0G CCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMHMGCSsGAQQBgjcQBDFmMGQwVjELMAkG A1UEBhMCVVMxGjAYBgNVBAoTEUludGVsIENvcnBvcmF0aW9uMSswKQYDVQQDEyJJbnRlbCBFeHRl cm5hbCBCYXNpYyBJc3N1aW5nIENBIDNBAgobntmGAAAAACD9MHUGCyqGSIb3DQEJEAILMWagZDBW MQswCQYDVQQGEwJVUzEaMBgGA1UEChMRSW50ZWwgQ29ycG9yYXRpb24xKzApBgNVBAMTIkludGVs IEV4dGVybmFsIEJhc2ljIElzc3VpbmcgQ0EgM0ECChue2YYAAAAAIP0wDQYJKoZIhvcNAQEBBQAE ggEAifq5Y+Vu+kW5wKLNZKd3eYwSlVG5s/8vz5mu5U9ub1eF9xz66cDu7wDgbf+GQe7BX817PhsV 7mxBR0iPGzHedsPAB/jBIjHoeq1YfvM4jem0FIeGJz/+ihRgDOo39INsKsxPKziivo2Z6JPuM+NY zLjDg+dZJPlIzbl5tWFc+9AenJdTGErqgxFjpTf/h/YHUpk8+NF/tQTU3f/7hU72veq9ICew0xW8 spJYcrI5JPyU4dcKShmzFQ5sx03xzA9IvEs6JosGRGkto4p501xu8f0bAEpnE+fefL8iTiMk9ZyF xOVZGYQLdIqK8lRHuNYkJ7JHg7wi8HezYQ5qrAHBXAAAAAAAAA== ------=_NextPart_000_02F7_01C9342E.42151E30-- --===============0614576283== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0614576283==-- From ipsec-bounces@ietf.org Wed Oct 22 10:26:59 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 404BE3A6A07; Wed, 22 Oct 2008 10:26:59 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3560328C142 for ; Wed, 22 Oct 2008 10:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.357 X-Spam-Level: X-Spam-Status: No, score=-5.357 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+e8sO4nhrV9 for ; Wed, 22 Oct 2008 10:26:39 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id D7BAD3A6947 for ; Wed, 22 Oct 2008 10:26:38 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 22 Oct 2008 10:22:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.33,465,1220252400"; d="scan'208,217";a="351241260" Received: from unknown (HELO azsmsx601.amr.corp.intel.com) ([10.2.121.193]) by orsmga002.jf.intel.com with ESMTP; 22 Oct 2008 10:26:34 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.1.291.1; Wed, 22 Oct 2008 10:27:06 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Wed, 22 Oct 2008 11:26:56 -0600 From: "Grewal, Ken" To: Yoav Nir , Gary Hemminger Date: Wed, 22 Oct 2008 11:26:23 -0600 Thread-Topic: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Thread-Index: Ack0HBFHzdIZKbmYTyadfeP1v1px6AATyJJw Message-ID: References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> <206900B6-1B1D-45EB-8F6D-D035F4BB3670@checkpoint.com> In-Reply-To: <206900B6-1B1D-45EB-8F6D-D035F4BB3670@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1133826803==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1133826803== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_A1E36B4547AAF443BEA10955A159923B0881D81Frrsmsx505amrcor_" --_000_A1E36B4547AAF443BEA10955A159923B0881D81Frrsmsx505amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed! ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Tuesday, October 21, 2008 11:40 PM To: Gary Hemminger Cc: Yaron Sheffer; Grewal, Ken; ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication e= xtension for IKEv2) Hi Gary If that's the case, then the load balancer would need neither heuristics no= r a wrapper. Having terminated the IKE, the load balancer would have the ch= ild SA, and would know for certain whether the algorithm is ESP-NULL or som= ething encrypted. In fact, the load balancer would even be able to enforce = such a policy. Yoav On Oct 22, 2008, at 2:00 AM, Gary Hemminger wrote: The client would negotiate IKE with the load balancer and would not direct= ly negotiate with the Server. Gary From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Tuesday, October 21, 2008 3:23 PM To: Grewal, Ken; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication e= xtension for IKEv2) Hi Ken, Thanks for the clarification. But I still don't understand how your scenari= o works. Assume for simplicity an environment where everybody uses ESP in transport = mode, with null encryption. Client C1 does an IKE negotiation with a random server (as selected by the = load balancer) S1. They negotiate some ESP traffic stream, denoted by an SP= I. This whole thing is encrypted, so the load balancer cannot learn the SPI= value. Now when the first ESP packet is sent from C1 towards the load balancer, th= ere is not enough information for it to forward the packet to S1, regardles= s of its being able to look into the cleartext packet! Only S1 has the ESP = keying material, and if LB forwards the packet elsewhere, the receiver will= not be able to verify its integrity. Regards, Yaron ________________________________ From: Grewal, Ken [mailto:ken.grewal@intel.com] Sent: Tuesday, October 21, 2008 23:56 To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication e= xtension for IKEv2) Some observations below: 1. I agree with Yaron in that if a load balancer needs to 'terminate' the= traffic before applying any rules to distribute the load, then it should h= ave the keys to do so without any modifications to the current protocol. In= this case, the session setup (via IKE) should have been negotiated with th= e load balancer and it is the natural termination point of the IPsec SA. Th= e load balancer is essentially acting as a VPN gateway for tunnel mode or s= ome kind of front end proxy to the multiple servers behind it in transport = mode. 2. My understanding of a 'pure' load balancer is that it distributes traf= fic streams to different resources available to it and this is typically ba= sed on rules such as source / destination IP protocols, ports (e.g. TCP por= ts) and potentially some other information. Furthermore, as some of the upp= er layer protocols are stateful (e.g. TCP), it is desirable for the load ba= lancer to ensure that a higher layer 'session' (e.g. TCP session) is 'pegge= d' to a resource (server) that has been handling the same session - this al= lows efficient state maintenance on a given resource / server, instead of a= ll resources needing access to that state. Now if the traffic is protected = using IPsec, then the load balancer needs access to upper layer payload dat= a in the packet in order to apply the aforementioned rules for load balanci= ng decisions. The charter item on traffic visibility provides for a clean s= olution where the load-balancer (as well as other network monitoring tools)= is able to ascertain that the packet if not encrypted and hence look insid= e the packet to analyze the protocol / ports to make load balancing decisio= ns. In this case, IPsec is still being terminated on the server behind the = load balancer, but the load balancer can examine the IPsec protected packet= en-route to ensure it gets to the right server. In essence, this charter i= tem allows the load balancer (and other network tools) to continue to funct= ion in IPsec environments. 3. I agree with Gary on his observations about heuristics as being comple= x in HW, undeterministic and the associated parsing rules liable to change = based on new protocols / payloads. Thanks, - Ken ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-b= ounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, October 21, 2008 1:37 PM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication e= xtension for IKEv2) OK. But if your load balancer is able to decrypt the traffic (i.e. it has t= he credentials or secret keys), then it can do that with today's normal IKE= /IPsec. There is no need in this case to modify the protocol to make it eas= ier to detect encrypted traffic. Thanks, Yaron ________________________________ From: Gary Hemminger [mailto:ghemminger@foundrynet.com] Sent: Tuesday, October 21, 2008 19:02 To: Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication e= xtension for IKEv2) The use case you are thinking about is probably pure IPsec VPN, where an en= crypted stream only lives across the WAN. But what if you are a load balan= cer and the IPsec traffic is end to end? In this case, you may have a load= balancer that needs to terminate the traffic so it can make the decision w= hich server to handle the request. All load balancers today support SSL te= rmination. Same thing applies to IPsec traffic. We cannot make the decisi= on which server to handle the request, nor can we maintain persistence with= out decrypting the traffic. Gary From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Tuesday, October 21, 2008 6:10 AM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication exten= sion for IKEv2) Hi Gary, I'm puzzled by the scenario you are presenting. I've been considering the w= ork on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) a= s useful for middleboxes that want to look at the IPsec-protected traffic, = but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In gener= al, if you can terminate IPsec, that means that you have access to the encr= yption keys and you can easily differentiate protected and unprotected traf= fic, Can you explain the use case that you have in mind? Thanks, Yaron ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-b= ounces@ietf.org] On Behalf Of Gary Hemminger Sent: Monday, October 20, 2008 20:26 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 I was talking about how to make the determination that the payload is encry= pted. Evidently there are two approaches: one based on a heuristic, anoth= er based on a payload wrapper that flags the payload is encrypted. We woul= d need some mechanism to determine the payload is encryped if we need to te= rminate the IPSEC traffic and make a determination of which server to send = it to. Sorry about the confusion. Gary ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sat 10/18/2008 2:03 PM To: Gary Hemminger Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 Hi Gary. I'm not sure what heuristics you are talking about. The problem of re-authe= ntication is simply this. The owner of the remote access gateway has a secu= rity policy that says that connections can be open for only so long (say, 2= hours) without authenticating the user again. This is a favorite requireme= nt by auditors, who believe that this is an important part of risk manageme= nt. If somebody steals your laptop (or mobile phone) or sits down at the In= ternet Cafe station where you were logged on, we want to limit the amount o= f time they are connected to the internal network. This requirement makes s= ense if the user has to type in their password to authenticate. It makes le= ss sense if there are user certificates that are stored on the computer, or= if the client software has a "save password" feature. Whether it makes sense or not, this is a requirement by auditors and regula= tors. If the user does not re-authenticate within the specified time, the I= KE SA and all dependent child SAs are deleted. This creates a usability pr= oblem, because the SA is deleted without any advance warning to the user, s= o the user is likely to get a relatively long time with no connectivity. Th= is can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to = make accounts permanently offline when this happens. RFC 4778 and the improvement that Martin Willi is proposing, are aimed at s= olving this usability problem by informing the client software in advance w= hen the re-authentication needs to be done, and allowing them to re-authent= icate early enough, so that connections are not broken. The heuristic does = not affect the security or the IPsec streams. Yoav On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: One comment on the heuristics approach. As a hardware vendor of L4-7 ADC b= oxes, I am a little concerned about having to terminate IPSEC streams based= on the heuristics approach, because this is open ended. What I mean is th= at the heuristic may be easy to define now, but there is no certainty that = it would remain this way. My past experience suggests that eventually the = heuristic would become too complex, and a well defined mechanism for determ= ining which payload is encrypted would need to be employed anyway. While I like the idea of some "other" box having to solve this issue, which= prevents clients from having to be changed, as we are a vendor of the "oth= er" box, I think we should think about the long term, not the short term. = Just my opinion, and I am certainly flexible, but the heuristics approach w= orries me a bit. Gary [IPsec] Reauthentication extension for IKEv2 ________________________________ * To: Martin Willi > * Subject: [IPsec] Reauthentication extension for IKEv2 * From: Tero Kivinen > * Date: Tue, 16 Sep 2008 12:09:14 +0300 * Cc: ipsec at ietf.org * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com * Delivered-to: ipsec at core3.amsl.com * In-reply-to: <48CF5D7D.7070701 at strongswan.org> * List-archive: * List-help: * List-id: Discussion of IPsec protocols * List-post: * List-subscribe: , * List-unsubscribe: , * References: <48CF5D7D.7070701 at strongswan.org> * Sender: ipsec-bounces at ietf.org ________________________________ Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... The first question I have is why are you doing reauthentication at all? What is the benefits of the reauthentication? What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have. -- kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec ________________________________ * Follow-Ups: * Re: [IPsec] Reauthentication extension for IKEv2 * From: Martin Willi * References: * [IPsec] Reauthentication extension for IKEv2 * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 * Previous by thread: [IPsec] Reauthentication extension for IKEv2 * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 * Index(es): * Date * Thread Note: Messages sent to this list are the opinions of the senders and do not= imply endorsement by the IE Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. --_000_A1E36B4547AAF443BEA10955A159923B0881D81Frrsmsx505amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Gary, =

    I agree with Yaron here. The = scenario you are describing can be done today if the load balancer can act as an = IPsec termination point and nothing new is needed. =

    Also, please see my other response = on using a load balancer which does not terminate IPsec, but can benefit from the changes being proposed.

     

    Let me know if I am missing = something.

     

    Thanks, =

    - Ken

     

    From: Yaron = Sheffer [mailto:yaronf@checkpoint.com]
    Sent: Wednesday, October = 22, 2008 12:03 AM
    To: Gary Hemminger; = Grewal, Ken; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    In that case, the load balancer can identify the traffic using the normal ESP SPI field, and knows exactly = what kind of traffic it is and whether it is encrypted. There is no need to = change the ESP protocol for this scenario.

     

    Thanks,

    =

          =       Yaron

     

    From: Gary = Hemminger [mailto:ghemminger@foundrynet.com]
    Sent: Wednesday, October = 22, 2008 2:00
    To: Yaron Sheffer; Grewal, Ken; Yoav = Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    The client = would negotiate IKE  with the load balancer and would not directly = negotiate with the Server.

     <= /o:p>

    Gary

     <= /o:p>

    From: = Yaron Sheffer = [mailto:yaronf@checkpoint.com]
    Sent: Tuesday, October = 21, 2008 3:23 PM
    To: Grewal, Ken; Gary = Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    Hi = Ken,

     

    Thanks for the clarification. But I = still don’t understand how your scenario = works.

     

    Assume for simplicity an = environment where everybody uses ESP in transport mode, with null = encryption.

     

    Client C1 does an IKE negotiation = with a random server (as selected by the load balancer) S1. They negotiate some = ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the = load balancer cannot learn the SPI value.

     

    Now when the first ESP packet is = sent from C1 towards the load balancer, there is not enough information for it to = forward the packet to S1, regardless of its being able to look into the = cleartext packet! Only S1 has the ESP keying material, and if LB forwards the = packet elsewhere, the receiver will not be able to verify its = integrity.

     

    Regards,

          =       Yaron

     

    From: = Grewal, Ken [mailto:ken.grewal@intel.com]
    Sent: Tuesday, October = 21, 2008 23:56
    To: Yaron Sheffer; Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    Some observations = below:

     

    1. I agree with Yaron in that if a load balancer needs to ‘terminate’ the traffic before applying any rules to distribute the load, then it should have the keys to do so without = any modifications to the current protocol. In this case, the session = setup (via IKE) should have been negotiated with the load balancer and it = is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of = front end proxy to the multiple servers behind it in transport mode. =
    2. My understanding of a ‘pure’ load balancer is that it = distributes traffic streams to different resources available to it and this is typically based on rules such as source / destination IP protocols, = ports (e.g. TCP ports) and potentially some other information. = Furthermore, as some of the upper layer protocols are stateful (e.g. TCP), it is = desirable for the load balancer to ensure that a higher layer = ‘session’ (e.g. TCP session) is ‘pegged’ to a resource (server) = that has been handling the same session – this allows efficient state maintenance on a given resource / server, instead of all resources = needing access to that state. Now if the traffic is protected using IPsec, = then the load balancer needs access to upper layer payload data in the = packet in order to apply the aforementioned rules for load balancing = decisions. The charter item on traffic visibility provides for a clean = solution where the load-balancer (as well as other network monitoring tools) is = able to ascertain that the packet if not encrypted and hence look inside = the packet to analyze the protocol / ports to make load balancing = decisions. In this case, IPsec is still being terminated on the server behind = the load balancer, but the load balancer can examine the IPsec = protected packet en-route to ensure it gets to the right server. In essence, = this charter item allows the load balancer (and other network tools) to continue to function in IPsec environments. =
    3. I agree with Gary on his observations about heuristics as being complex in HW, = undeterministic and the associated parsing rules liable to change based on new = protocols / payloads.

     

    Thanks, =

    - Ken

     

    From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer
    Sent: Tuesday, October = 21, 2008 1:37 PM
    To: Gary Hemminger; = Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    OK. But if your load balancer is = able to decrypt the traffic (i.e. it has the credentials or secret keys), then = it can do that with today’s normal IKE/IPsec. There is no need in this = case to modify the protocol to make it easier to detect encrypted = traffic.

     

    Thanks,

    =

          =       Yaron

     

    From: Gary = Hemminger [mailto:ghemminger@foundrynet.com]
    Sent: Tuesday, October = 21, 2008 19:02
    To: Yaron Sheffer; Yoav = Nir
    Cc: ipsec@ietf.org
    Subject: RE: Identifying = encrypted traffic (was: [IPsec] Reauthentication extension for = IKEv2)

     

    The use = case you are thinking about is probably pure IPsec VPN, where an encrypted stream = only lives across the WAN.  But what if you are a load balancer and the IPsec = traffic is end to end?  In this case, you may have a load balancer that = needs to terminate the traffic so it can make the decision which server to handle = the request.  All load balancers today support SSL termination.  = Same thing applies to IPsec traffic.  We cannot make the decision which = server to handle the request, nor can we maintain persistence without = decrypting the traffic. 

     <= /o:p>

    Gary

     <= /o:p>

    From: = Yaron Sheffer = [mailto:yaronf@checkpoint.com]
    Sent: Tuesday, October = 21, 2008 6:10 AM
    To: Gary Hemminger; = Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Identifying = encrypted traffic (was: [IPsec] Reauthentication extension for = IKEv2)

     

    Hi = Gary,

     

    I’m puzzled by the scenario = you are presenting. I’ve been considering the work on ESP-null detection = (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that = want to look at the IPsec-protected traffic, but do NOT want to terminate = IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, = that means that you have access to the encryption keys and you can easily = differentiate protected and unprotected traffic, Can you explain the use case that you = have in mind?

     

    Thanks,

    =

          =       Yaron

     

    From: = ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On = Behalf Of Gary Hemminger
    Sent: Monday, October 20, = 2008 20:26
    To: Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Reauthentication extension for IKEv2

     

    I was talking about how to make = the determination that the payload is encrypted.  Evidently there are = two approaches:  one based on a heuristic, another based on a payload = wrapper that flags the payload is encrypted.  We would need some mechanism = to determine the payload is encryped if we need to terminate the IPSEC = traffic and make a determination of which server to send it to.  Sorry about = the confusion.

     

    Gary

     

    From: Yoav Nir [mailto:ynir@checkpoint.com]
    Sent: Sat 10/18/2008 2:03 = PM
    To: Gary Hemminger
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] = Reauthentication extension for IKEv2

    Hi Gary.

     

    I'm not sure what heuristics you are talking about. The problem = of re-authentication is simply this. The owner of the remote access gateway = has a security policy that says that connections can be open for only so long = (say, 2 hours) without authenticating the user again. This is a favorite = requirement by auditors, who believe that this is an important part of risk management. = If somebody steals your laptop (or mobile phone) or sits down at the = Internet Cafe station where you were logged on, we want to limit the amount of time = they are connected to the internal network. This requirement makes sense if the = user has to type in their password to authenticate. It makes less sense if there = are user certificates that are stored on the computer, or if the client = software has a "save password" feature.

     

    Whether it makes sense or not, this is a requirement by auditors = and regulators. If the user does not re-authenticate within the specified = time, the IKE SA and all dependent child SAs are deleted.  This = creates a usability problem, because the SA is deleted without any advance warning = to the user, so the user is likely to get a relatively long time with no = connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook = tends to make accounts permanently offline when this = happens.

     

    RFC 4778 and the improvement that Martin Willi is proposing, are = aimed at solving this usability problem by informing the client software in = advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The = heuristic does not affect the security or the IPsec = streams.

     

    Yoav

     

    On Oct 18, 2008, at 2:35 AM, Gary Hemminger = wrote:

     

    One comment on the heuristics approach.  As a hardware vendor of L4-7 ADC boxes, I am a little = concerned about having to terminate IPSEC streams based on the heuristics = approach, because this is open ended.  What I mean is that the heuristic may = be easy to define now, but there is no certainty that it would remain this = way.  My past experience suggests that eventually the heuristic would become = too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway.  =  

    While I like the idea of some “other” box having to solve this issue, which prevents = clients from having to be changed, as we are a vendor of the “other” box, = I think we should think about the long term, not the short term.  = Just my opinion, and I am certainly flexible, but the heuristics approach = worries me a bit.

     

    Gary

     

    [IPsec] Reauthentication extension for = IKEv2

    Martin Willi =
writes:
    > What do you think about such =
an extension? Already considered =
something
    > similar, or does your =
reauthentication procedure work hassle-free? =
I'm
    > wondering if we are the only =
ones facing these problems or if such =
an
    > extension would gain broader =
acceptance...
     
    The first question I have is why =
are you doing reauthentication =
at
    all?
     
    What is the benefits of the =
reauthentication?
     
    What is the benefits of the =
reauthentication that can be done =
WITHOUT
    user intervention (i.e. no user =
typing in password or pin code =
or
    fingerprint or =
similar)?
     
    I myself can only really see =
benefits from reauthentication when =
it
    does require that user is really =
sitting there on the machine, =
and
    gives something that the machine =
itself cannot give. In those =
cases
    the user is required to type in =
something or do something =
anyways,
    thus it does not really matter if =
the communications is =
interrupted
    for second if user must stop his =
work for much longer time to type =
in
    his passphrase or pin =
code.
     
    The RFC 4478 simply skips this =
question and says "With some =
IPsec
    peers, particularly in the remote =
access scenario, it is desirable =
to
    repeat the mutual authentication =
periodically. The purpose of this =
is
    to limit the time that security =
associations (SAs) can be used by =
a
    third party who has gained =
control of the IPsec =
peer."
     
    In most cases if third party has =
gained control of the IPsec peer =
he
    will also get control of all =
authentication information inside =
the
    peer, including private keys and =
pre shared keys. Only way to =
make
    sure that he does not get access =
to those is to protect them =
with
    passphrase, or pin code or =
similar that is only known by the =
user.
     
    This is also said out in the RFC =
4478: "However, in the remote =
access
    scenario it is usually up to a =
human user to supply the
    authentication credentials =
..."
     
    Because of this I do not think =
there is that much requirement =
for
    reauthentication protocol that is =
faster than what we already have. =

    -- =

    kivinen at =
safenet-inc.com
    __________________________________=
_____________
    IPsec mailing =
list
    IPsec at =
ietf.org
    https://www.ietf.org=
/mailman/listinfo/ipsec
     
     


    


    


    




      
 
    • Follow-Ups: =

      • 

    




      
 
        
  
          
   
        • From: Martin
       Willi
          • 
  
        
 
      

    


      
 
    • References: =

      • 

    




      
 
        
  
          
   
        • From: Martin
       Willi
          • 
  
        
 
      

    





    


    Note: Messages sent to this list are the opinions of =
the
senders and do not imply endorsement by the =
IE
    


    


     



    Scanned by Check Point Total Security Gateway. 

    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org= /mailman/listinfo/ipsec

     



    Scanned by Check Point Total Security Gateway. =



    Scanned by Check Point Total Security Gateway. =



    Scanned by Check Point Total Security Gateway. =

    Agreed!

     

    From: Yoav Nir [mailto:ynir@checkpoint.com]
    Sent: Tuesday, October 21, 2= 008 11:40 PM
    To: Gary Hemminger
    Cc: Yaron Sheffer; Grewal, K= en; ipsec@ietf.org
    Subject: Re: [IPsec] Identif= ying encrypted traffic (was: Reauthentication extension for IKEv2)    =

     

    Hi Gary

     

    If that's the case, then the load balancer would need neither heuristics nor a wrapper. Having terminated the IKE, the load balancer woul= d have the child SA, and would know for certain whether the algorithm is ESP-= NULL or something encrypted. In fact, the load balancer would even be able to en= force such a policy.

     

    Yoav

     

    On Oct 22, 2008, at 2:00 AM, Gary Hemminger wrote:



    The client wou= ld negotiate IKE  with the load balancer and would not directly negotiate with the Server.

     

    Gary

     

    = From: Yaron Sheffer [mailto= :yaronf@checkpoint.com] 
    Sent: Tuesday, October 21, 2008 3:23 P= M
    To: Grewal, Ken; Gary Hemminger; Yoa= v Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] Identifying encrypte= d traffic (was: Reauthentication extension for IKEv2)

    =  

    Hi Ken,

     

    Thanks for the clarification. But I st= ill don’t understand how your scenario works.<= font color=3Dblack>

     

    Assume for simplicity an environment w= here everybody uses ESP in transport mode, with null encryption.

     

    Client C1 does an IKE negotiation with= a random server (as selected by the load balancer) S1. They negotiate some ES= P traffic stream, denoted by an SPI. This whole thing is encrypted, so the lo= ad balancer cannot learn the SPI value.

     

    Now when the first ESP packet is sent = from C1 towards the load balancer, there is not enough information for it to for= ward the packet to S1, regardless of its being able to look into the cleartext packet! Only S1 has the ESP keying material, and if LB forwards the packet = elsewhere, the receiver will not be able to verify its integrity.<= /font>

     

    Regards,

          &n= bsp;     Yaron

     

    = From: Grewal, Ken [mailto:ke= n.grewal@intel.com] 
    Sent: Tuesday, October 21, 2008 23:56<= br> To: Yaron Sheffer; Gary Hemminger; Y= oav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] Identifying encrypte= d traffic (was: Reauthentication extension for IKEv2)

    =  

    Some observations below:<= /span>

     

    1. I agree with Yaron in that if a load balancer needs to ‘terminate&= #8217; the traffic before applying any rules to distribute the load, then it shou= ld have the keys to do so without any modifications to the current protoc= ol. In this case, the session setup (via IKE) should have been negotiated = with the load balancer and it is the natural termination point of the IPsec= SA. The load balancer is essentially acting as a VPN gateway for tunnel mo= de or some kind of front end proxy to the multiple servers behind it in t= ransport mode.
    2. My understanding of a ‘pure’ load balancer is that it distrib= utes traffic streams to different resources available to it and this is typically b= ased on rules such as source / destination IP protocols, ports (e.g. TCP po= rts) and potentially some other information. Furthermore, as some of the up= per layer protocols are stateful (e.g. TCP), it is desirable for the load balancer to ensure that a higher layer ‘session’ (e.g. TCP= session) is ‘pegged’ to a resource (server) that has been handling the= same session – this allows efficient state maintenance on a given resource / server, instead of all resources needing access to that state. Now if the traf= fic is protected using IPsec, then the load balancer needs access to upper layer payload data in the packet in order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibi= lity provides for a clean solution where the load-balancer (as well as othe= r network monitoring tools) is able to ascertain that the packet if not encrypted and hence look inside the packet to analyze the protocol / p= orts to make load balancing decisions. In this case, IPsec is still being terminated on the server behind the load balancer, but the load balanc= er can examine the IPsec protected packet en-route to ensure it gets to t= he right server. In essence, this charter item allows the load balancer (= and other network tools) to continue to function in IPsec environments.
    3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change base= d on new protocols / payloads.

     

    <= span style=3D'font-size:12.0pt;color:navy'>Thanks,

    <= span style=3D'font-size:12.0pt;color:navy'>- Ken

     

    =  

    OK. But if your load balancer is able = to decrypt the traffic (i.e. it has the credentials or secret keys), then it c= an do that with today’s normal IKE/IPsec. There is no need in this case = to modify the protocol to make it easier to detect encrypted traffic.

     

    Thanks,

          &n= bsp;     Yaron

     

    = From: Gary Hemminger [m= ailto:ghemminger@foundrynet.com] 
    Sent: Tuesday, October 21, 2008 19:02<= br> To: Yaron Sheffer; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: Identifying encrypted traffi= c (was: [IPsec] Reauthentication extension for IKEv2)

    =  

    The use case y= ou are thinking about is probably pure IPsec VPN, where an encrypted stream only l= ives across the WAN.  But what if you are a load balancer and the IPsec tra= ffic is end to end?  In this case, you may have a load balancer that needs = to terminate the traffic so it can make the decision which server to handle th= e request.  All load balancers today support SSL termination.  Same thing applies to IPsec traffic.  We cannot make the decision which ser= ver to handle the request, nor can we maintain persistence without decrypting t= he traffic. 

     

    Gary

     

    = From: Yaron Sheffer [mailto= :yaronf@checkpoint.com] 
    Sent: Tuesday, October 21, 2008 6:10 A= M
    To: Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Identifying encrypted traffic (w= as: [IPsec] Reauthentication extension for IKEv2)

    =  

    Hi Gary,

     

    I’m puzzled by the scenario you = are presenting. I’ve been considering the work on ESP-null detection (e.g= . draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that wa= nt to look at the IPsec-protected traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, tha= t means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use ca= se that you have in mind?

     

    Thanks,

          &n= bsp;     Yaron

     

    =  

    I was talking about how to make the determination that the payload is encrypted.  Evidently there are two approaches:  one based on a heuristic, another based on a payload wrap= per that flags the payload is encrypted.  We would need some mechanism to determine the payload is encryped if we need to terminate the IPSEC traffic= and make a determination of which server to send it to.  Sorry about the confusion.

    =  

    Gary

    =  

    = From: Yoav Nir [mailto:ynir@c= heckpoint.com]
    Sent: Sat 10/18/2008 2:03 PM
    To: Gary Hemminger
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Reauthentication ext= ension for IKEv2

    = Hi Gary.

    =  

    = I'm not sure what heuristics you are talking about. The problem of re-authentication is simply this. The owner o= f the remote access gateway has a security policy that says that connections = can be open for only so long (say, 2 hours) without authenticating the user aga= in. This is a favorite requirement by auditors, who believe that this is an important part of risk management. If somebody steals your laptop (or mobil= e phone) or sits down at the Internet Cafe station where you were logged on, = we want to limit the amount of time they are connected to the internal network= . This requirement makes sense if the user has to type in their password to authenticate. It makes less sense if there are user certificates that are stored on the computer, or if the client software has a "save password" feature.

    =  

    = Whether it makes sense or not, this = is a requirement by auditors and regulators. If the user does not re-authenticat= e within the specified time, the IKE SA and all dependent child SAs= are deleted.  This creates a usability problem, because the SA is deleted without any advance warning to the user, so the user is likely to get a relatively long time with no connectivity. This can break TCP connections s= uch as FTP, HTTP, and IMAP. Outlook tends to make accounts permanently offline = when this happens.

    =  

    = RFC 4778 and the improvement that Ma= rtin Willi is proposing, are aimed at solving this usability problem by informin= g the client software in advance when the re-authentication needs to be done,= and allowing them to re-authenticate early enough, so that connections are not broken. The heuristic does not affect the security or the IPsec streams.

    =  

    = Yoav

    =  

    = On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote:

    =  

    One comment on the heuristics approach.  As a hardware vendor of L4-7 ADC boxes, I am a little conce= rned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended.  What I mean is that the heuristic may be = easy to define now, but there is no certainty that it would remain this way.&nbs= p; My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway.   <= font color=3Dblack>

    While I like the idea of some “= ;other” box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the “other” box, I think we shou= ld think about the long term, not the short term.  Just my opinion, and I am certainl= y flexible, but the heuristics approach worries me a bit.

     

    Gary=

     

    [IPsec] Reauthentication extension for IKEv2

     
    Martin Willi writes:
    > What do you think about such an extension? Already consi=
dered something
    > similar, or does your reauthentication procedure work ha=
ssle-free? I'm
    > wondering if we are the only ones facing these problems =
or if such an
    > extension would gain broader acceptance...<=
o:p>
     
    The first question I have is why are you doing reauthenticati=
on at
    all?
     
    What is the benefits of the reauthentication?
     
    What is the benefits of the reauthentication that can be done=
 WITHOUT
    user intervention (i.e. no user typing in password or pin cod=
e or
    fingerprint or similar)?
     
    I myself can only really see benefits from reauthentication w=
hen it
    does require that user is really sitting there on the machine=
, and
    gives something that the machine itself cannot give. In those=
 cases
    the user is required to type in something or do something any=
ways,
    thus it does not really matter if the communications is inter=
rupted
    for second if user must stop his work for much longer time to=
 type in
    his passphrase or pin code.
     
    The RFC 4478 simply skips this question and says "With s=
ome IPsec
    peers, particularly in the remote access scenario, it is desi=
rable to
    repeat the mutual authentication periodically. The purpose of=
 this is
    to limit the time that security associations (SAs) can be use=
d by a
    third party who has gained control of the IPsec peer."
     
    In most cases if third party has gained control of the IPsec =
peer he
    will also get control of all authentication information insid=
e the
    peer, including private keys and pre shared keys. Only way to=
 make
    sure that he does not get access to those is to protect them =
with
    passphrase, or pin code or similar that is only known by the =
user.
     
    This is also said out in the RFC 4478: "However, in the =
remote access
    scenario it is usually up to a human user to supply the=

    authentication credentials ..."<=
/span>
     
    Because of this I do not think there is that much requirement=
 for
    reauthentication protocol that is faster than what we already=
 have. 
    -- 
    kivinen at safenet-inc.com
    _______________________________________________<=
o:p>
    IPsec mailing list
    IPsec at ietf.org
    =

    https://www.ietf.org/m=
ailman/listinfo/ipsec
    <=
font
size=3D2 color=3Dblack face=3D"Courier New"> 
     
    


    


    


    




      
 
    • Follow-Ups:
      • 

    




      
 
        
  
          
   
        • =
From: <=
/span>Martin
       Willi
          • 
  
        
 
      

    


      
 
    • References:
      • 

    




      
 
        
  
          
   
        • =
From: <=
/span>Martin
       Willi
          • 
  
        
 
      

    





    


    Note: Messages sent to this list are the opinions of th=
e
senders and do not imply endorsement by the IE
    


    


    


     



    Scanned by Check Point Total Security Gateway. 

    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.or= g/mailman/listinfo/ipsec

    =  

    =

    Scanned by Check Point Total Security Gateway.

    =

    Scanned by Check Point Total Security Gateway.

    =

    Scanned by Check Point Total Security Gateway. 

     

    --_000_A1E36B4547AAF443BEA10955A159923B0881D81Frrsmsx505amrcor_-- --===============1133826803== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1133826803==-- From ipsec-bounces@ietf.org Wed Oct 22 10:29:42 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126AE28C170; Wed, 22 Oct 2008 10:29:42 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156E828C170 for ; Wed, 22 Oct 2008 10:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+PpSv1B5JZa for ; Wed, 22 Oct 2008 10:29:24 -0700 (PDT) Received: from smtp1gap.foundrynet.com (smtp1gap.foundrynet.com [76.199.70.29]) by core3.amsl.com (Postfix) with ESMTP id 1092C3A69B2 for ; Wed, 22 Oct 2008 10:29:24 -0700 (PDT) Received: from xmail.ds.foundrynet.com (unknown [10.101.218.254]) by smtp1gap.foundrynet.com (Postfix) with ESMTP id 9E4103E0004; Wed, 22 Oct 2008 10:29:47 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 10:29:48 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Thread-Index: Ack0HBFHzdIZKbmYTyadfeP1v1px6AATyJJwAAAkm9A= References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> <206900B6-1B1D-45EB-8F6D-D035F4BB3670@checkpoint.com> From: "Gary Hemminger" To: "Grewal, Ken" , "Yoav Nir" Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0729073294==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0729073294== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9346B.C4A53C8B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9346B.C4A53C8B Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Good point. =20 From: Grewal, Ken [mailto:ken.grewal@intel.com]=20 Sent: Wednesday, October 22, 2008 10:26 AM To: Yoav Nir; Gary Hemminger Cc: Yaron Sheffer; ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 Agreed! =20 ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Tuesday, October 21, 2008 11:40 PM To: Gary Hemminger Cc: Yaron Sheffer; Grewal, Ken; ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 Hi Gary =20 If that's the case, then the load balancer would need neither heuristics nor a wrapper. Having terminated the IKE, the load balancer would have the child SA, and would know for certain whether the algorithm is ESP-NULL or something encrypted. In fact, the load balancer would even be able to enforce such a policy. =20 Yoav =20 On Oct 22, 2008, at 2:00 AM, Gary Hemminger wrote: =20 The client would negotiate IKE with the load balancer and would not directly negotiate with the Server. =20 Gary =20 From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 Sent: Tuesday, October 21, 2008 3:23 PM To: Grewal, Ken; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 Hi Ken, =20 Thanks for the clarification. But I still don't understand how your scenario works. =20 Assume for simplicity an environment where everybody uses ESP in transport mode, with null encryption. =20 Client C1 does an IKE negotiation with a random server (as selected by the load balancer) S1. They negotiate some ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn the SPI value. =20 Now when the first ESP packet is sent from C1 towards the load balancer, there is not enough information for it to forward the packet to S1, regardless of its being able to look into the cleartext packet! Only S1 has the ESP keying material, and if LB forwards the packet elsewhere, the receiver will not be able to verify its integrity. =20 Regards, Yaron =20 ________________________________ From: Grewal, Ken [mailto:ken.grewal@intel.com]=20 Sent: Tuesday, October 21, 2008 23:56 To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 Some observations below: =20 1. I agree with Yaron in that if a load balancer needs to 'terminate' the traffic before applying any rules to distribute the load, then it should have the keys to do so without any modifications to the current protocol. In this case, the session setup (via IKE) should have been negotiated with the load balancer and it is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of front end proxy to the multiple servers behind it in transport mode. 2. My understanding of a 'pure' load balancer is that it distributes traffic streams to different resources available to it and this is typically based on rules such as source / destination IP protocols, ports (e.g. TCP ports) and potentially some other information. Furthermore, as some of the upper layer protocols are stateful (e.g. TCP), it is desirable for the load balancer to ensure that a higher layer 'session' (e.g. TCP session) is 'pegged' to a resource (server) that has been handling the same session - this allows efficient state maintenance on a given resource / server, instead of all resources needing access to that state. Now if the traffic is protected using IPsec, then the load balancer needs access to upper layer payload data in the packet in order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibility provides for a clean solution where the load-balancer (as well as other network monitoring tools) is able to ascertain that the packet if not encrypted and hence look inside the packet to analyze the protocol / ports to make load balancing decisions. In this case, IPsec is still being terminated on the server behind the load balancer, but the load balancer can examine the IPsec protected packet en-route to ensure it gets to the right server. In essence, this charter item allows the load balancer (and other network tools) to continue to function in IPsec environments. 3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change based on new protocols / payloads. =20 Thanks, - Ken =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, October 21, 2008 1:37 PM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 OK. But if your load balancer is able to decrypt the traffic (i.e. it has the credentials or secret keys), then it can do that with today's normal IKE/IPsec. There is no need in this case to modify the protocol to make it easier to detect encrypted traffic. =20 Thanks, Yaron =20 ________________________________ From: Gary Hemminger [mailto:ghemminger@foundrynet.com]=20 Sent: Tuesday, October 21, 2008 19:02 To: Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) =20 The use case you are thinking about is probably pure IPsec VPN, where an encrypted stream only lives across the WAN. But what if you are a load balancer and the IPsec traffic is end to end? In this case, you may have a load balancer that needs to terminate the traffic so it can make the decision which server to handle the request. All load balancers today support SSL termination. Same thing applies to IPsec traffic. We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic.=20 =20 Gary =20 From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 Sent: Tuesday, October 21, 2008 6:10 AM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) =20 Hi Gary, =20 I'm puzzled by the scenario you are presenting. I've been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that want to look at the IPsec-protected traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use case that you have in mind? =20 Thanks, Yaron =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger Sent: Monday, October 20, 2008 20:26 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 =20 I was talking about how to make the determination that the payload is encrypted. Evidently there are two approaches: one based on a heuristic, another based on a payload wrapper that flags the payload is encrypted. We would need some mechanism to determine the payload is encryped if we need to terminate the IPSEC traffic and make a determination of which server to send it to. Sorry about the confusion. =20 Gary =20 ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sat 10/18/2008 2:03 PM To: Gary Hemminger Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 Hi Gary. =20 I'm not sure what heuristics you are talking about. The problem of re-authentication is simply this. The owner of the remote access gateway has a security policy that says that connections can be open for only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important part of risk management. If somebody steals your laptop (or mobile phone) or sits down at the Internet Cafe station where you were logged on, we want to limit the amount of time they are connected to the internal network. This requirement makes sense if the user has to type in their password to authenticate. It makes less sense if there are user certificates that are stored on the computer, or if the client software has a "save password" feature. =20 Whether it makes sense or not, this is a requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are deleted. This creates a usability problem, because the SA is deleted without any advance warning to the user, so the user is likely to get a relatively long time with no connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to make accounts permanently offline when this happens. =20 RFC 4778 and the improvement that Martin Willi is proposing, are aimed at solving this usability problem by informing the client software in advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The heuristic does not affect the security or the IPsec streams. =20 Yoav =20 On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: =20 One comment on the heuristics approach. As a hardware vendor of L4-7 ADC boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended. What I mean is that the heuristic may be easy to define now, but there is no certainty that it would remain this way. My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway. =20 While I like the idea of some "other" box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the "other" box, I think we should think about the long term, not the short term. Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit. =20 Gary =20 [IPsec] Reauthentication extension for IKEv2 ________________________________ * To: Martin Willi > * Subject: [IPsec] Reauthentication extension for IKEv2 * From: Tero Kivinen > * Date: Tue, 16 Sep 2008 12:09:14 +0300 * Cc: ipsec at ietf.org =20 * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com =20 * Delivered-to: ipsec at core3.amsl.com =20 * In-reply-to: <48CF5D7D.7070701 at strongswan.org > * List-archive: * List-help: * List-id: Discussion of IPsec protocols * List-post: * List-subscribe: , * List-unsubscribe: , * References: <48CF5D7D.7070701 at strongswan.org > * Sender: ipsec-bounces at ietf.org =20 ________________________________ Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... =20 The first question I have is why are you doing reauthentication at all? =20 What is the benefits of the reauthentication? =20 What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? =20 I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. =20 The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." =20 In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. =20 This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." =20 Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have.=20 --=20 kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 ________________________________ * Follow-Ups: * Re: [IPsec] Reauthentication extension for IKEv2 =20 * From: Martin Willi * References: * [IPsec] Reauthentication extension for IKEv2 =20 * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 =20 * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 =20 * Previous by thread: [IPsec] Reauthentication extension for IKEv2 =20 * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 =20 * Index(es): * Date * Thread =20 Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IE =20 Scanned by Check Point Total Security Gateway.=20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway.=20 =20 ------_=_NextPart_001_01C9346B.C4A53C8B Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

    Good point.

     

    From:= Grewal, = Ken [mailto:ken.grewal@intel.com]
    Sent: Wednesday, October 22, 2008 10:26 AM
    To: Yoav Nir; Gary Hemminger
    Cc: Yaron Sheffer; ipsec@ietf.org
    Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

     

    Agreed!

     

    From:= Yoav Nir [mailto:ynir@checkpoint.com]
    Sent: Tuesday, October 21, 2008 11:40 PM
    To: Gary Hemminger
    Cc: Yaron Sheffer; Grewal, Ken; ipsec@ietf.org
    Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

     

    Hi Gary

     

    If that's the case, then the load balancer would = need neither heuristics nor a wrapper. Having terminated the IKE, the load = balancer would have the child SA, and would know for certain whether the = algorithm is ESP-NULL or something encrypted. In fact, the load balancer would even = be able to enforce such a policy.

     

    Yoav

     

    On Oct 22, 2008, at 2:00 AM, Gary Hemminger = wrote:

     

    The client would negotiate IKE  with the load = balancer and would not directly negotiate with the Server.

     

    Gary

     

    From:=  = Yaron Sheffer [mailto:yaronf@checkpoint.com] 
    Sent: Tuesday, = October 21, 2008 3:23 PM
    To: Grewal, Ken; = Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: = [IPsec] Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    Hi Ken,

     

    Thanks for the clarification. But I still don’t = understand how your scenario works.

     

    Assume for simplicity an environment where everybody uses = ESP in transport mode, with null encryption.

     

    Client C1 does an IKE negotiation with a random server (as = selected by the load balancer) S1. They negotiate some ESP traffic stream, = denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn = the SPI value.

     

    Now when the first ESP packet is sent from C1 towards the = load balancer, there is not enough information for it to forward the packet = to S1, regardless of its being able to look into the cleartext packet! Only S1 = has the ESP keying material, and if LB forwards the packet elsewhere, the = receiver will not be able to verify its integrity.

     

    Regards,

              &= nbsp; Yaron

     

    From:=  = Grewal, Ken [mailto:ken.grewal@intel.com] 
    Sent: Tuesday, = October 21, 2008 23:56
    To: Yaron = Sheffer; Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: = [IPsec] Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    Some observations below:

     

    1. I agree = with Yaron in that if a load balancer needs to ‘terminate’ = the traffic before applying any rules to distribute the load, then it should have the = keys to do so without any modifications to the current protocol. In this = case, the session setup (via IKE) should have been negotiated with the load = balancer and it is the natural termination point of the IPsec SA. The load = balancer is essentially acting as a VPN gateway for tunnel mode or some kind = of front end proxy to the multiple servers behind it in transport = mode.
    2. My = understanding of a ‘pure’ load balancer is that it distributes = traffic streams to different resources available to it and this is typically based on = rules such as source / destination IP protocols, ports (e.g. TCP ports) = and potentially some other information. Furthermore, as some of the = upper layer protocols are stateful (e.g. TCP), it is desirable for the = load balancer to ensure that a higher layer ‘session’ (e.g. = TCP session) is ‘pegged’ to a resource (server) that has been handling = the same session – this allows efficient state maintenance on a given resource / = server, instead of all resources needing access to that state. Now if the = traffic is protected using IPsec, then the load balancer needs access to = upper layer payload data in the packet in order to apply the = aforementioned rules for load balancing decisions. The charter item on traffic = visibility provides for a clean solution where the load-balancer (as well as = other network monitoring tools) is able to ascertain that the packet if = not encrypted and hence look inside the packet to analyze the protocol = / ports to make load balancing decisions. In this case, IPsec is still = being terminated on the server behind the load balancer, but the load = balancer can examine the IPsec protected packet en-route to ensure it gets = to the right server. In essence, this charter item allows the load = balancer (and other network tools) to continue to function in IPsec = environments.
    3. I agree = with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change = based on new protocols / payloads.

     

    Thanks,

    - Ken

     

    From:=  = ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=  On Behalf Of Yaron Sheffer
    Sent: Tuesday, = October 21, 2008 1:37 PM
    To: Gary = Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: = [IPsec] Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    OK. But if your load balancer is able to decrypt the traffic = (i.e. it has the credentials or secret keys), then it can do that with = today’s normal IKE/IPsec. There is no need in this case to modify the protocol to make = it easier to detect encrypted traffic.

     

    Thanks,

              &= nbsp; Yaron

     

    From:=  = Gary Hemminger [mailto:ghemminger@foundrynet.co= m] 
    Sent: Tuesday, = October 21, 2008 19:02
    To: Yaron = Sheffer; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: = Identifying encrypted traffic (was: [IPsec] Reauthentication extension for = IKEv2)

     

    The use case you are thinking about is probably pure = IPsec VPN, where an encrypted stream only lives across the WAN.  But what if = you are a load balancer and the IPsec traffic is end to end?  In this case, = you may have a load balancer that needs to terminate the traffic so it can = make the decision which server to handle the request.  All load balancers = today support SSL termination.  Same thing applies to IPsec traffic.  We = cannot make the decision which server to handle the request, nor can we = maintain persistence without decrypting the traffic. 

     

    Gary

     

    From:=  = Yaron Sheffer [mailto:yaronf@checkpoint.com] 
    Sent: Tuesday, = October 21, 2008 6:10 AM
    To: Gary = Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for = IKEv2)

     

    Hi Gary,

     

    I’m puzzled by the scenario you are presenting. = I’ve been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that = want to look at the IPsec-protected traffic, but do NOT want to terminate IPsec = (i.e. decapsulate the traffic). In general, if you can terminate IPsec, that = means that you have access to the encryption keys and you can easily = differentiate protected and unprotected traffic, Can you explain the use case that you = have in mind?

     

    Thanks,

              &= nbsp; Yaron

     

    From:=  = ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=  On Behalf Of Gary Hemminger
    Sent: Monday, = October 20, 2008 20:26
    To: Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: = [IPsec] Reauthentication extension for IKEv2

     

    I was talking about how to make the determination that the = payload is encrypted.  Evidently there are two approaches:  one based = on a heuristic, another based on a payload wrapper that flags the payload is encrypted.  We would need some mechanism to determine the payload = is encryped if we need to terminate the IPSEC traffic and make a = determination of which server to send it to.  Sorry about the confusion.

     

    Gary

     

    From:=  = Yoav Nir [mailto:ynir@checkpoint.com]
    Sent: Sat = 10/18/2008 2:03 PM
    To: Gary = Hemminger
    Cc: ipsec@ietf.org
    Subject: Re: = [IPsec] Reauthentication extension for IKEv2

    Hi = Gary.

     

    I'm not sure what = heuristics you are talking about. The problem of re-authentication is simply this. The = owner of the remote access gateway has a security policy that says that = connections can be open for only so long (say, 2 hours) without authenticating the = user again. This is a favorite requirement by auditors, who believe that this = is an important part of risk management. If somebody steals your laptop (or = mobile phone) or sits down at the Internet Cafe station where you were logged = on, we want to limit the amount of time they are connected to the internal = network. This requirement makes sense if the user has to type in their password = to authenticate. It makes less sense if there are user certificates that = are stored on the computer, or if the client software has a "save password" feature.

     

    Whether it makes sense = or not, this is a requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are deleted.  This creates a = usability problem, because the SA is deleted without any advance warning to the = user, so the user is likely to get a relatively long time with no connectivity. = This can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to make accounts permanently offline when this happens.

     

    RFC 4778 and the = improvement that Martin Willi is proposing, are aimed at solving this usability problem = by informing the client software in advance when the re-authentication = needs to be done, and allowing them to re-authenticate early enough, so that = connections are not broken. The heuristic does not affect the security or the IPsec streams.

     

    Yoav

     

    On Oct 18, 2008, at = 2:35 AM, Gary Hemminger wrote:

     

    One = comment on the heuristics approach.  As a hardware vendor of L4-7 ADC = boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended.  What I mean is = that the heuristic may be easy to define now, but there is no certainty that it = would remain this way.  My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed = anyway.   

    While I like the idea of some “other” box having to solve this issue, = which prevents clients from having to be changed, as we are a vendor of the “other” = box, I think we should think about the long term, not the short term.  Just my = opinion, and I am certainly flexible, but the heuristics approach worries me a = bit.

     

    Gary

     

    [IPsec] Reauthentication extension for = IKEv2

    Martin Willi =
writes:
    > What do you think about such an extension? =
Already considered something
    > similar, or does your reauthentication =
procedure work hassle-free? I'm
    > wondering if we are the only ones facing =
these problems or if such an
    > extension would gain broader =
acceptance...
     
    The first question I have is why are you doing =
reauthentication at
    all?
     
    What is the benefits of the =
reauthentication?
     
    What is the benefits of the reauthentication that =
can be done WITHOUT
    user intervention (i.e. no user typing in password =
or pin code or
    fingerprint or =
similar)?
     
    I myself can only really see benefits from =
reauthentication when it
    does require that user is really sitting there on =
the machine, and
    gives something that the machine itself cannot =
give. In those cases
    the user is required to type in something or do =
something anyways,
    thus it does not really matter if the =
communications is interrupted
    for second if user must stop his work for much =
longer time to type in
    his passphrase or pin =
code.
     
    The RFC 4478 simply skips this question and says =
"With some IPsec
    peers, particularly in the remote access scenario, =
it is desirable to
    repeat the mutual authentication periodically. The =
purpose of this is
    to limit the time that security associations (SAs) =
can be used by a
    third party who has gained control of the IPsec =
peer."
     
    In most cases if third party has gained control of =
the IPsec peer he
    will also get control of all authentication =
information inside the
    peer, including private keys and pre shared keys. =
Only way to make
    sure that he does not get access to those is to =
protect them with
    passphrase, or pin code or similar that is only =
known by the user.
     
    This is also said out in the RFC 4478: =
"However, in the remote access
    scenario it is usually up to a human user to =
supply the
    authentication credentials =
..."
     
    Because of this I do not think there is that much =
requirement for
    reauthentication protocol that is faster than what =
we already have. 
    -- 
    kivinen at =
safenet-inc.com
    _______________________________________________
    IPsec mailing =
list
    IPsec at =
ietf.org
    https://www.ietf.org=
/mailman/listinfo/ipsec
     
     
    • Follow-Ups<= /span>:
        • From: Martin = Willi
    • References<= /span>:
        • From: Martin = Willi

    Note: Messages sent to this list are the = opinions of the senders and do not imply endorsement by the = IE

     



    Scanned by Check Point Total Security Gateway. 

    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org= /mailman/listinfo/ipsec

     



    Scanned by Check Point Total Security Gateway.



    Scanned by Check Point Total Security Gateway.



    Scanned by Check Point Total Security Gateway. 

     

    ------_=_NextPart_001_01C9346B.C4A53C8B-- --===============0729073294== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0729073294==-- From ipsec-bounces@ietf.org Wed Oct 22 12:17:12 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E61E13A68B6; Wed, 22 Oct 2008 12:17:12 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9173A68B6 for ; Wed, 22 Oct 2008 12:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIFiqBSIC9Ev for ; Wed, 22 Oct 2008 12:16:52 -0700 (PDT) Received: from smtp1gap.foundrynet.com (smtp1gap.foundrynet.com [76.199.70.29]) by core3.amsl.com (Postfix) with ESMTP id 857013A63D3 for ; Wed, 22 Oct 2008 12:16:52 -0700 (PDT) Received: from xmail.ds.foundrynet.com (unknown [10.101.218.254]) by smtp1gap.foundrynet.com (Postfix) with ESMTP id 66C7C3E0005; Wed, 22 Oct 2008 12:17:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 22 Oct 2008 12:17:06 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkhACbyvnAACETf8AAHhWiAAAKQj8AAALjDUAAD0PSgAA7QhJAAFRZWMAAA0Gag References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC80B@il-ex01.ad.checkpoint.com> From: "Gary Hemminger" To: "Grewal, Ken" , "Yaron Sheffer" , "Yoav Nir" Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1600337264==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1600337264== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9347A.C1C1E667" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9347A.C1C1E667 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable You are absolutely correct Ken. I think I switched the names of the parties I agree with in a previous email sorry. Anyway, we need to do the termination. Very few organizations use load balancers where the servers all have to share state with each other. This is simply too difficult to get working, and to debug. =20 Gary =20 From: Grewal, Ken [mailto:ken.grewal@intel.com]=20 Sent: Wednesday, October 22, 2008 10:09 AM To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 Hi Gary,=20 I agree with Yaron here. The scenario you are describing can be done today if the load balancer can act as an IPsec termination point and nothing new is needed.=20 Also, please see my other response on using a load balancer which does not terminate IPsec, but can benefit from the changes being proposed. =20 Let me know if I am missing something.=20 =20 Thanks,=20 - Ken =20 ________________________________ From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 Sent: Wednesday, October 22, 2008 12:03 AM To: Gary Hemminger; Grewal, Ken; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 In that case, the load balancer can identify the traffic using the normal ESP SPI field, and knows exactly what kind of traffic it is and whether it is encrypted. There is no need to change the ESP protocol for this scenario. =20 Thanks, Yaron =20 ________________________________ From: Gary Hemminger [mailto:ghemminger@foundrynet.com]=20 Sent: Wednesday, October 22, 2008 2:00 To: Yaron Sheffer; Grewal, Ken; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 The client would negotiate IKE with the load balancer and would not directly negotiate with the Server. =20 Gary =20 From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 Sent: Tuesday, October 21, 2008 3:23 PM To: Grewal, Ken; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 Hi Ken, =20 Thanks for the clarification. But I still don't understand how your scenario works. =20 Assume for simplicity an environment where everybody uses ESP in transport mode, with null encryption. =20 Client C1 does an IKE negotiation with a random server (as selected by the load balancer) S1. They negotiate some ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn the SPI value. =20 Now when the first ESP packet is sent from C1 towards the load balancer, there is not enough information for it to forward the packet to S1, regardless of its being able to look into the cleartext packet! Only S1 has the ESP keying material, and if LB forwards the packet elsewhere, the receiver will not be able to verify its integrity. =20 Regards, Yaron =20 ________________________________ From: Grewal, Ken [mailto:ken.grewal@intel.com]=20 Sent: Tuesday, October 21, 2008 23:56 To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 Some observations below: =20 1. I agree with Yaron in that if a load balancer needs to 'terminate' the traffic before applying any rules to distribute the load, then it should have the keys to do so without any modifications to the current protocol. In this case, the session setup (via IKE) should have been negotiated with the load balancer and it is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of front end proxy to the multiple servers behind it in transport mode.=20 2. My understanding of a 'pure' load balancer is that it distributes traffic streams to different resources available to it and this is typically based on rules such as source / destination IP protocols, ports (e.g. TCP ports) and potentially some other information. Furthermore, as some of the upper layer protocols are stateful (e.g. TCP), it is desirable for the load balancer to ensure that a higher layer 'session' (e.g. TCP session) is 'pegged' to a resource (server) that has been handling the same session - this allows efficient state maintenance on a given resource / server, instead of all resources needing access to that state. Now if the traffic is protected using IPsec, then the load balancer needs access to upper layer payload data in the packet in order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibility provides for a clean solution where the load-balancer (as well as other network monitoring tools) is able to ascertain that the packet if not encrypted and hence look inside the packet to analyze the protocol / ports to make load balancing decisions. In this case, IPsec is still being terminated on the server behind the load balancer, but the load balancer can examine the IPsec protected packet en-route to ensure it gets to the right server. In essence, this charter item allows the load balancer (and other network tools) to continue to function in IPsec environments. 3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change based on new protocols / payloads.=20 =20 Thanks,=20 - Ken =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, October 21, 2008 1:37 PM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 OK. But if your load balancer is able to decrypt the traffic (i.e. it has the credentials or secret keys), then it can do that with today's normal IKE/IPsec. There is no need in this case to modify the protocol to make it easier to detect encrypted traffic. =20 Thanks, Yaron =20 ________________________________ From: Gary Hemminger [mailto:ghemminger@foundrynet.com]=20 Sent: Tuesday, October 21, 2008 19:02 To: Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) =20 The use case you are thinking about is probably pure IPsec VPN, where an encrypted stream only lives across the WAN. But what if you are a load balancer and the IPsec traffic is end to end? In this case, you may have a load balancer that needs to terminate the traffic so it can make the decision which server to handle the request. All load balancers today support SSL termination. Same thing applies to IPsec traffic. We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic. =20 =20 Gary =20 From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 Sent: Tuesday, October 21, 2008 6:10 AM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) =20 Hi Gary, =20 I'm puzzled by the scenario you are presenting. I've been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that want to look at the IPsec-protected traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use case that you have in mind? =20 Thanks, Yaron =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger Sent: Monday, October 20, 2008 20:26 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 =20 I was talking about how to make the determination that the payload is encrypted. Evidently there are two approaches: one based on a heuristic, another based on a payload wrapper that flags the payload is encrypted. We would need some mechanism to determine the payload is encryped if we need to terminate the IPSEC traffic and make a determination of which server to send it to. Sorry about the confusion. =20 Gary =20 ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sat 10/18/2008 2:03 PM To: Gary Hemminger Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 Hi Gary.=20 =20 I'm not sure what heuristics you are talking about. The problem of re-authentication is simply this. The owner of the remote access gateway has a security policy that says that connections can be open for only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important part of risk management. If somebody steals your laptop (or mobile phone) or sits down at the Internet Cafe station where you were logged on, we want to limit the amount of time they are connected to the internal network. This requirement makes sense if the user has to type in their password to authenticate. It makes less sense if there are user certificates that are stored on the computer, or if the client software has a "save password" feature. =20 Whether it makes sense or not, this is a requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are deleted. This creates a usability problem, because the SA is deleted without any advance warning to the user, so the user is likely to get a relatively long time with no connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to make accounts permanently offline when this happens. =20 RFC 4778 and the improvement that Martin Willi is proposing, are aimed at solving this usability problem by informing the client software in advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The heuristic does not affect the security or the IPsec streams. =20 Yoav =20 On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: =20 One comment on the heuristics approach. As a hardware vendor of L4-7 ADC boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended. What I mean is that the heuristic may be easy to define now, but there is no certainty that it would remain this way. My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway. =20 While I like the idea of some "other" box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the "other" box, I think we should think about the long term, not the short term. Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit. =20 Gary =20 [IPsec] Reauthentication extension for IKEv2 ________________________________ * To: Martin Willi >=20 * Subject: [IPsec] Reauthentication extension for IKEv2=20 * From: Tero Kivinen >=20 * Date: Tue, 16 Sep 2008 12:09:14 +0300=20 * Cc: ipsec at ietf.org =20 * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com =20 * Delivered-to: ipsec at core3.amsl.com =20 * In-reply-to: <48CF5D7D.7070701 at strongswan.org >=20 * List-archive: =20 * List-help: =20 * List-id: Discussion of IPsec protocols =20 * List-post: =20 * List-subscribe: , =20 * List-unsubscribe: , =20 * References: <48CF5D7D.7070701 at strongswan.org >=20 * Sender: ipsec-bounces at ietf.org =20 ________________________________ Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... =20 The first question I have is why are you doing reauthentication at all? =20 What is the benefits of the reauthentication? =20 What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? =20 I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. =20 The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." =20 In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. =20 This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." =20 Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have.=20 --=20 kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 ________________________________ * Follow-Ups:=20 * Re: [IPsec] Reauthentication extension for IKEv2 =20 * From: Martin Willi * References:=20 * [IPsec] Reauthentication extension for IKEv2 =20 * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 =20 * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 =20 * Previous by thread: [IPsec] Reauthentication extension for IKEv2 =20 * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 =20 * Index(es):=20 * Date * Thread =20 Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IE =20 Scanned by Check Point Total Security Gateway.=20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 Scanned by Check Point Total Security Gateway.=20 Scanned by Check Point Total Security Gateway.=20 Scanned by Check Point Total Security Gateway.=20 ------_=_NextPart_001_01C9347A.C1C1E667 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

    You are absolutely correct Ken.  I think I switched = the names of the parties I agree with in a previous email sorry.  Anyway, we = need to do the termination.  Very few organizations use load balancers = where the servers all have to share state with each other.  This is simply = too difficult to get working, and to debug.

     

    Gary

     

    From:= Grewal, = Ken [mailto:ken.grewal@intel.com]
    Sent: Wednesday, October 22, 2008 10:09 AM
    To: Yaron Sheffer; Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

     

    Hi Gary,

    I agree with Yaron here. The scenario you are describing can = be done today if the load balancer can act as an IPsec termination point = and nothing new is needed.

    Also, please see my other response on using a load balancer = which does not terminate IPsec, but can benefit from the changes being = proposed.

     

    Let me know if I am missing something. =

     

    Thanks, =

    - = Ken

     

    From:= Yaron = Sheffer [mailto:yaronf@checkpoint.com]
    Sent: Wednesday, October 22, 2008 12:03 AM
    To: Gary Hemminger; Grewal, Ken; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

     

    In that case, the load balancer can identify the traffic = using the normal ESP SPI field, and knows exactly what kind of traffic it is and = whether it is encrypted. There is no need to change the ESP protocol for this = scenario.

     

    Thanks,

              &= nbsp; Yaron

     

    From:= Gary = Hemminger [mailto:ghemminger@foundrynet.com]
    Sent: Wednesday, October 22, 2008 2:00
    To: Yaron Sheffer; Grewal, Ken; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

     

    The client would negotiate IKE  with the load = balancer and would not directly negotiate with the Server.

     

    Gary

     

    From:= Yaron = Sheffer [mailto:yaronf@checkpoint.com]
    Sent: Tuesday, October 21, 2008 3:23 PM
    To: Grewal, Ken; Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

     

    Hi Ken,

     

    Thanks for the clarification. But I still don’t = understand how your scenario works.

     

    Assume for simplicity an environment where everybody uses = ESP in transport mode, with null encryption.

     

    Client C1 does an IKE negotiation with a random server (as = selected by the load balancer) S1. They negotiate some ESP traffic stream, = denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn = the SPI value.

     

    Now when the first ESP packet is sent from C1 towards the = load balancer, there is not enough information for it to forward the packet = to S1, regardless of its being able to look into the cleartext packet! Only S1 = has the ESP keying material, and if LB forwards the packet elsewhere, the = receiver will not be able to verify its integrity.

     

    Regards,

              &= nbsp; Yaron

     

    From:= Grewal, = Ken [mailto:ken.grewal@intel.com]
    Sent: Tuesday, October 21, 2008 23:56
    To: Yaron Sheffer; Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

     

    Some observations below:

     

    1. I agree = with Yaron in that if a load balancer needs to ‘terminate’ = the traffic before applying any rules to distribute the load, then it = should have the keys to do so without any modifications to the current = protocol. In this case, the session setup (via IKE) should have been = negotiated with the load balancer and it is the natural termination point of the = IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel = mode or some kind of front end proxy to the multiple servers behind it = in transport mode.
    2. My = understanding of a ‘pure’ load balancer is that it distributes = traffic streams to different resources available to it and this is = typically based on rules such as source / destination IP protocols, ports (e.g. TCP = ports) and potentially some other information. Furthermore, as some of the = upper layer protocols are stateful (e.g. TCP), it is desirable for the = load balancer to ensure that a higher layer ‘session’ (e.g. = TCP session) is ‘pegged’ to a resource (server) that has = been handling the same session – this allows efficient state = maintenance on a given resource / server, instead of all resources needing = access to that state. Now if the traffic is protected using IPsec, then the = load balancer needs access to upper layer payload data in the packet in = order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibility provides for a clean solution = where the load-balancer (as well as other network monitoring tools) is able = to ascertain that the packet if not encrypted and hence look inside = the packet to analyze the protocol / ports to make load balancing = decisions. In this case, IPsec is still being terminated on the server behind = the load balancer, but the load balancer can examine the IPsec = protected packet en-route to ensure it gets to the right server. In essence, this = charter item allows the load balancer (and other network tools) to continue = to function in IPsec environments.
    3. I agree = with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change = based on new protocols / payloads.

     

    Thanks, =

    - = Ken

     

    From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yaron Sheffer
    Sent: Tuesday, October 21, 2008 1:37 PM
    To: Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

     

    OK. But if your load balancer is able to decrypt the traffic = (i.e. it has the credentials or secret keys), then it can do that with = today’s normal IKE/IPsec. There is no need in this case to modify the protocol = to make it easier to detect encrypted traffic.

     

    Thanks,

              &= nbsp; Yaron

     

    From:= Gary = Hemminger [mailto:ghemminger@foundrynet.com]
    Sent: Tuesday, October 21, 2008 19:02
    To: Yaron Sheffer; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2)

     

    The use case you are thinking about is probably pure = IPsec VPN, where an encrypted stream only lives across the WAN.  But what if = you are a load balancer and the IPsec traffic is end to end?  In this case, = you may have a load balancer that needs to terminate the traffic so it can = make the decision which server to handle the request.  All load balancers = today support SSL termination.  Same thing applies to IPsec = traffic.  We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic.  =

     

    Gary

     

    From:= Yaron = Sheffer [mailto:yaronf@checkpoint.com]
    Sent: Tuesday, October 21, 2008 6:10 AM
    To: Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Identifying encrypted traffic (was: [IPsec] = Reauthentication extension for IKEv2)

     

    Hi Gary,

     

    I’m puzzled by the scenario you are presenting. = I’ve been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that = want to look at the IPsec-protected traffic, but do NOT want to terminate = IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, = that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use = case that you have in mind?

     

    Thanks,

              &= nbsp; Yaron

     

    From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Gary Hemminger
    Sent: Monday, October 20, 2008 20:26
    To: Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Reauthentication extension for = IKEv2

     

    I was talking about how to make the determination that the = payload is encrypted.  Evidently there are two approaches:  one based = on a heuristic, another based on a payload wrapper that flags the payload is encrypted.  We would need some mechanism to determine the payload = is encryped if we need to terminate the IPSEC traffic and make a = determination of which server to send it to.  Sorry about the = confusion.

     

    Gary

     

    From: Yoav Nir = [mailto:ynir@checkpoint.com]
    Sent: Sat 10/18/2008 2:03 PM
    To: Gary Hemminger
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Reauthentication extension for = IKEv2

    Hi Gary.

     

    I'm not sure what heuristics you are talking about. = The problem of re-authentication is simply this. The owner of the remote = access gateway has a security policy that says that connections can be open for = only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important = part of risk management. If somebody steals your laptop (or mobile phone) or = sits down at the Internet Cafe station where you were logged on, we want to limit = the amount of time they are connected to the internal network. This = requirement makes sense if the user has to type in their password to authenticate. = It makes less sense if there are user certificates that are stored on the = computer, or if the client software has a "save password" = feature.

     

    Whether it makes sense or not, this is a = requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are = deleted.  This creates a usability problem, because the SA is deleted = without any advance warning to the user, so the user is likely to get a relatively = long time with no connectivity. This can break TCP connections such as FTP, = HTTP, and IMAP. Outlook tends to make accounts permanently offline when this = happens.

     

    RFC 4778 and the improvement that Martin Willi is = proposing, are aimed at solving this usability problem by informing the client = software in advance when the re-authentication needs to be done, and allowing them = to re-authenticate early enough, so that connections are not broken. The = heuristic does not affect the security or the IPsec streams.

     

    Yoav

     

    On Oct 18, 2008, at 2:35 AM, Gary Hemminger = wrote:

     

    One = comment on the heuristics approach.  As a hardware vendor of L4-7 ADC = boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended.  What I mean is = that the heuristic may be easy to define now, but there is no certainty that it = would remain this way.  My past experience suggests that eventually the = heuristic would become too complex, and a well defined mechanism for determining = which payload is encrypted would need to be employed anyway.  =  

    While I like the idea of some “other” box having to solve this issue, = which prevents clients from having to be changed, as we are a vendor of the “other” box, I think we should think about the long term, = not the short term.  Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit.

     

    Gary

     

    [IPsec] Reauthentication extension for = IKEv2

    Martin Willi =
writes:
    > What do you think about such an extension? =
Already considered something
    > similar, or does your reauthentication =
procedure work hassle-free? I'm
    > wondering if we are the only ones facing =
these problems or if such an
    > extension would gain broader =
acceptance...
     
    The first question I have is why are you doing =
reauthentication at
    all?
     
    What is the benefits of the =
reauthentication?
     
    What is the benefits of the reauthentication that =
can be done WITHOUT
    user intervention (i.e. no user typing in password =
or pin code or
    fingerprint or =
similar)?
     
    I myself can only really see benefits from =
reauthentication when it
    does require that user is really sitting there on =
the machine, and
    gives something that the machine itself cannot =
give. In those cases
    the user is required to type in something or do =
something anyways,
    thus it does not really matter if the =
communications is interrupted
    for second if user must stop his work for much =
longer time to type in
    his passphrase or pin =
code.
     
    The RFC 4478 simply skips this question and says =
"With some IPsec
    peers, particularly in the remote access scenario, =
it is desirable to
    repeat the mutual authentication periodically. The =
purpose of this is
    to limit the time that security associations (SAs) =
can be used by a
    third party who has gained control of the IPsec =
peer."
     
    In most cases if third party has gained control of =
the IPsec peer he
    will also get control of all authentication =
information inside the
    peer, including private keys and pre shared keys. =
Only way to make
    sure that he does not get access to those is to =
protect them with
    passphrase, or pin code or similar that is only =
known by the user.
     
    This is also said out in the RFC 4478: =
"However, in the remote access
    scenario it is usually up to a human user to =
supply the
    authentication credentials =
..."
     
    Because of this I do not think there is that much =
requirement for
    reauthentication protocol that is faster than what =
we already have. 
    -- 
    kivinen at =
safenet-inc.com
    _______________________________________________
    IPsec mailing =
list
    IPsec at =
ietf.org
    https://www.ietf.org=
/mailman/listinfo/ipsec
     
     
    • Follow-Ups<= /span>: =
        • From: Martin = Willi
    • References<= /span>: =
        • From: Martin = Willi

    Note: Messages sent to this list are the = opinions of the senders and do not imply endorsement by the = IE

     



    Scanned by Check Point Total Security Gateway. 

    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org= /mailman/listinfo/ipsec

     



    Scanned by Check Point Total Security Gateway.



    Scanned by Check Point Total Security Gateway.



    Scanned by Check Point Total Security Gateway.

    ------_=_NextPart_001_01C9347A.C1C1E667-- --===============1600337264== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1600337264==-- From ipsec-bounces@ietf.org Wed Oct 22 16:22:32 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27333A6A94; Wed, 22 Oct 2008 16:22:32 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 188163A6A94 for ; Wed, 22 Oct 2008 16:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2pqYgUevyTo for ; Wed, 22 Oct 2008 16:22:30 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A9AE43A6A26 for ; Wed, 22 Oct 2008 16:22:29 -0700 (PDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9MNNdZP053193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Oct 2008 16:23:40 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <48B64A69.2010705@checkpoint.com> References: <48B64A69.2010705@checkpoint.com> Date: Wed, 22 Oct 2008 16:23:37 -0700 To: Yaron Sheffer , ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] IKEv2-bis notes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Sorry for the delayed reply. I am now catching up so that we can turn a -01 in before the cutoff deadline. There are three types of responses. Each type has a different effect on the new WG issue tracker. My responses are marked with "===" at the beginning of the line. - Done. This is now in my working copy of -01. Yaron won't fill these in the tracker. - Not done, but take it to the list. This is not a simple editorial change or clarification, and needs to be taken to the list for discussion. Yaron will mark these in the tracker as open issues. - Not done and disagree. Some of these are editorial changes that make things harder to understand, others are disagreements about whether they are correct. Yaron will mark these in the issue tracker as closed issues; someone can re-open them if sufficiently motivated. At 9:49 AM +0300 8/28/08, Yaron Sheffer wrote: - Sec. 1: "intended to replace": the status WRT IKEv1 and IKEv2 is obviously very different. I suggest: [4306] has obsoleted the IKEv1 document set. The current document replaces [IKEv2] and [Clarif] by a single unified description of the IKEv2 protocol. ===Not done, take this to the list. I think the current working is actually more correct than the proposed rewording. - Sec. 1 (editorial): is there a good reason to call Child SAs "CHILD_SAs" rather than "Child SAs" (why the Fortran-like underscore?). "That's the way 4306 has it" is not a sufficient reason. ===Done. Also changed "IKE_SA" to "IKE SA". - Sec. 1: liveness tests are described here and in Sec. 2.4 and 2.21. They deserve their own subsection, as well as mention of the commonly used name "DPD, dead peer detection". ===Partially done. Added a sentence to 2.4 saying that liveness detection is sometimes called dead peer detection, but did not create a separate section about it because it really does warrant metion in 1, 2.4, 2.21, and 3.9. - 1.1.2: "if there is an inner IP header" then this is not transport mode, contrary to the previous sentence. ===Done - 1.1.3: this text "for the initiator to request an IP address owned by the security gateway for use for the duration of its SA" implies that the lifetime of the address is identical to that of the IKE SA. If this is true, it should be explicit in the text of 3.15.1. ===Not done, but will do so after more discussion. In 3.15.1, it already says: "The requested address is valid until there are no IKE SAs between the peers. This is described in more detail in Section 3.15.3." That is different than what you say above. Which do we want? - 1.2 "All but the headers of all the messages that follow are encrypted and integrity protected." This sentence is hard to understand. I suggest: "The messages that follow are encrypted and integrity protected in their entirety, with the exception of message headers." ===Done. - 1.2: Clarif-4.3 is a nit, it probably belongs somewhere else, rather than the first description of the protocol. ===Not done. This is not a nit, and is very much about what is and is not OK in the exchanges. - 1.3.1: the two clarifications at the end are a bit confusing. TFC is negotiated separately for each peer, but non-first-fragment is apparently negotiated for both sides. But this is not explicity stated for the latter. Also, please reword "If the peer rejects the proposal of the SA" as "If the peer is unwilling to send or to receive non-first fragments". ===Done. - 1.3.2: "supplied in the SPI fields", add: "of the SA payload". ==Done. - Need a reference to 2.14 (generation of the IKE_SA crypto material) from both 1.2 and 1.3.2. ==Done. Added to 1.2 and 1.3, but not to the sub-sections of 1.3. - 1.3.2: why is KE a SHOULD, not a MUST? How is the SA generated if it is omitted? ===Not done. This needs to be brought up as a separate thread on the mailing list with the stuff that Yaron and Tero discussed, as well as the old discussion. I am not hopeful.... - 1.4: "replaced for the purpose of rekeying" - replace by "rekeyed". ===Done. - 1.4: "This is the expected way an endpoint can ask the other endpoint to verify that it is alive." Add: "This is often referred to as a liveness check, or Dead Peer Detection (DPD)". ===Not done; did it in 2.4 instead, as above. - 1.4: "in inbound half" should be "the inbound half". ===Done. - 1.4: the section should be broken into two, maybe "The INFORMATIONAL Exchange" and "Deleting an SA". ===Done. Good catch. This was classic documentation creep. - 1.6: page 17 is a bit late in the game to introduce the word "MUST". ===Not done. There is no other good place to do this without messing up the section numbering. - 1.7: I don't know what "amplifications" means. Also, the following paragraph (major and minor numbers) is redundant and confusing. This *is* the same protocol. ===Not done. "Amplification" means that some things from the earlier document are described in more detail (although not louder...). The major/minor stuff is not redundant: it is relevant to what has changed in this document, namely that it is not a protocol change. I added a short note about that. - 2. Clarif-7.5 is redundant, it is mentioned in 2.23. ===Not done. It is redundant, and is important to say in both places. - 2.3: The first paragraph contains an apparent contradiciton. It mentions that pipelining is done "if the other endpoint has indicated its ability to handle such requests" and then goes on to describe how a pipelining implementation can interoperate with a non-pipelining one. Which should be trivial if the pipelining side knows what the other side is capable of. ===Not done, definitely worth discussing on the list. - 2.4: Clarif-7.9 is unclear: "however, receiving parties need to deal with it in other requests" - what requests? How? Why should it ever happen? ===Not done, needs to be discussed on the list. - 2.6: "needs to choose them so as to be unique identifiers of an IKE_SA" - why was the SHOULD demoted? Uniqueness of the SPI is essential to the protocol. ===Done. - 2.9 "an IP packet and matches" should be "an IP packet that matches". ===Done. - 2.9: I believe it is more appropriate to describe PFKEY as an API, rather than protocol. ===Not done, for the list. - 2.12: "In particular, it MUST forget [...] any state that may persist in the state of a pseudo-random number generator that could be used to recompute the Diffie-Hellman secrets". This is confusing and probably incorrect. Any PRNG state used to generate the DH value is long past by the time the IKE SA is deleted. And ff it isn't, then what we are asking here is to reset the PRNG to a base (0-state) configuration, which is insecure. ===Done. - 2.12: Exponential reuse - can we give a reference on how to do it securely? ===Not done, need someone to provide it. - 2.16: "The shared key generated during an IKE exchange MUST NOT" - it would be clearer to refer to the previous sentence, "This key MUST NOT". ===Done. - 2.19: INTERNAL_ADDRESS_EXPIRY is gone, but shouldn't we specify what the gateway should do if the address lease expires? On a related note, the section does not specify the lifetime of the configuration values, i.e. should they be renewed by the next IKE SA rekey, or reauthentication, or never? ===Not done, definitely needs more list discussion, including Tero's comments. - 2.22: I suggest to add the following last paragraph: In some cases Robust Header Compression (ROHC) may be more appropriate than IP Compression. The reader is referred to an extension [informational ref] that defines the use of ROHC with IKEv2 and IPsec. ===Done. - 2.23: in the 2nd bullet, "the location... are" ==> "is". ===Done. - 3.1 under Flags: "Presence of options are" ==> "is". ===Done. - 3.1: V flag: since no implementation has V=1 yet, can we define that it is also set for minor version changes? Otherwise an attacker can downgrade the minor version advertised by the peers, which could affect their functionality. ===Not done. Bad idea, not needed. - 3.3.2: "This syntax is inherited from ISAKMP, but is unnecessary because the last Proposal could be identified from the length of the SA." Should be: "This syntax is inherited from ISAKMP, but is unnecessary because the last Transform could be identified from the length of the Proposal." ===Done. - 3.3.2: there is no explanation here or elsewhere what is meant by the D-H transform for ESP and AH. If nobody's using it, it should be depracated. ===Not done. This is for PFS, yes? - 3.3.2: "tranform" - typo. ===Done. - 3.3.2: please add at the bottom of the section: "Numerous additional transform types have been defined since the publication of RFC 4306. Please refer to the IANA IKEv2 registry for details." ===Done. - 3.3.4, 2nd paragraph: many things have changed in the last few years. Please remove all the text starting "For example". ===Done. - 3.5: this section is extremely liberal on what access control policies people can implement, but that's too late to change now. However, we CAN at least add a reference to RFC 4301, Sec. 4.4.3.1 (as was done in RFC 4945, pki4ipsec). ===Not done, take to the list. - 3.5: we mention that ID_KEY_ID is opaque and vendor specific, and then we have a MUST implement of ID_KEY_ID for interoperability. This is a contradiction. ===Not done. Removing this from the mandatory list would be a technical change that could cause failures. - 3.6: it is unclear exactly which X.509 format implementations MUST support (presumably #4). Also, the last paragraph is unclear on whether 4 certificate payloads or a bundle with 4 certificates MUST be supported. ===Not done. Specifying a particular one at this late date would be a technical change. - 3.12: "Writers of Internet-Drafts who wish to extend this protocol MUST define a Vendor ID payload to announce the ability to implement the extension in the Internet-Draft." The rules for notifications mean that this is often not needed, because you can ignore unknown notifications. Can we eliminate this requirement? ===Not done; take to the list to see if anyone objects. - 3.15.3: shouldn't we remove the whole section, and add a reference to the work-in-progress in IPv6 configuration? ===Not done, but might do so after the new document moves forwards in the WG. - 5: "It is assumed that all Diffie-Hellman exponents are erased from memory after use. In particular, these exponents MUST NOT be derived from long-lived secrets like the seed to a pseudo-random generator that is not erased after use." This is kind of strange: how is an implementation supposed to derive these exponents then? ===Done. Good catch. - 5: Additional proposed text for the Security Considerations: Admission control is critical to the security of the protocol. For example, IKE trust anchors must be separate from those used for other forms of trust, e.g. to identify trusted Web servers. Moreover, although IKE provides a wide leeway in defining the security policy for trusted peers' identity, credentials and the correlation between them, having such security policy defined explicitly is essential to a secure implementation. Both IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator is authenticated. As a result, an implementation of this protocol (all 100-odd pages!) must be completely robust when deployed on any insecure network. Any implementation vulnerability can and will be exploited by unauthenticated peers. This applies in particular to denial of service attacks, and we note the particular potential issue with the unlimited number of messages in EAP-based authentication. ===Not done, take to the list. - 7: last paragraph: add "Note to RFC Editor" or the poor guy/gal might miss it. ===Done. - Appendix C: please also mention extension notifications [N+]. Also, Vendor ID in the CCSA exchange. ===Partially not done. The N+ is already in C.6; where else did you think it should be? I did add [V+] to C.4 and C.5. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 23 00:59:05 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04AE83A6BFE; Thu, 23 Oct 2008 00:59:05 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179073A6833 for ; Thu, 23 Oct 2008 00:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0Hs6hflD6kE for ; Thu, 23 Oct 2008 00:58:41 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B582C3A6BFE for ; Thu, 23 Oct 2008 00:58:39 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 07832200DCD; Thu, 23 Oct 2008 09:59:10 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 73986200DAC; Thu, 23 Oct 2008 09:59:07 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9N7x6ke001107; Thu, 23 Oct 2008 09:59:06 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 23 Oct 2008 09:59:05 +0200 From: Yaron Sheffer To: "Grewal, Ken" , Gary Hemminger , Yoav Nir Date: Thu, 23 Oct 2008 09:59:02 +0200 Thread-Topic: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkhACbyvnAACETf8AAHhWiAAAKQj8AAALjDUAAnmfuQAB8zc6A= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC975@il-ex01.ad.checkpoint.com> References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0110236971==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0110236971== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_016E_01C934F5.FA080030" ------=_NextPart_000_016E_01C934F5.FA080030 Content-Type: multipart/alternative; boundary="----=_NextPart_001_016F_01C934F5.FA080030" ------=_NextPart_001_016F_01C934F5.FA080030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Ken, This is obviously complex to implement, as Gary mentioned. Also, there are weird interactions with ESP anti-replay. You are proposing in demultiplex one SPI between multiple servers at the backend. The load balancer may be able to keep track of the replay window for the whole SPI (which each server would not be able to do on its own), but it will not be able to send back notifications if any problems are detected. Thanks, Yaron _____ From: Grewal, Ken [mailto:ken.grewal@intel.com] Sent: Wednesday, October 22, 2008 19:04 To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Hi Yaron, The scenario I was referring to requires the servers behind the load balancer to act as a cluster and hence on the first ESP packet, obtain the IPsec SA from another member of the cluster with which the SA was negotiated (this may be inherently done on the completion of an IKE SA also). I have seen this deployed using a back-end dedicated management interface for state synchronization. Remember, as far as the client is concerned, it is talking to just one server and does not see a cluster, so the cluster of servers have to act as one to some degree, including synchronization between them. Now, state synchronization on the first packet (e.g. of a new TCP connection) is one thing and achievable, but the real benefit of the load balancer is to 'peg' all subsequent packets for that TCP session to the same server. This ensures that within a given TCP (or another stateful protocol) session, there is no need to continually synchronize the TCP state between all members of the server cluster - if this was to be done, then the management / synchronization port between the cluster members would generate more traffic then being received into the cluster, which is not desirable or practical. So, from a load balancer point of view, it can look into the ESP (null) packet and see if this is a new connection (i.e. no existing rules based on IP/port information). If a new connection, it can use whatever internal rules to assign this packet to any server with the least load. On doing this, the load balancer updates internal rules to ensure any subsequent packets for the same stream as sent to the same server as the initial packet - that is the benefit (this is what load balancers do today for clear text traffic). I have also seen alternative solutions proposed - e.g. A given server completing an IKE negotiation can communicate 3-tuple (IP, SPI, protocol) information back to a load balancer and the load balancer can utilize this for any subsequent decisions on assigning load for IPsec encapsulated packet, but solutions like this require synchronization between the load balancer and the servers, which is less desirable. For any cluster of resources acting together to accommodate load balancing solutions, a certain amount of inter-cluster communication is expected and that fits in with the former solution above. Also remember, that IPsec E2E is not widely deployed because of problems exactly like this one (loss of visibility / control / functionality for intermediary devices) and this is what we are trying to address. Thanks, - Ken _____ From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Tuesday, October 21, 2008 3:23 PM To: Grewal, Ken; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Hi Ken, Thanks for the clarification. But I still don't understand how your scenario works. Assume for simplicity an environment where everybody uses ESP in transport mode, with null encryption. Client C1 does an IKE negotiation with a random server (as selected by the load balancer) S1. They negotiate some ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn the SPI value. Now when the first ESP packet is sent from C1 towards the load balancer, there is not enough information for it to forward the packet to S1, regardless of its being able to look into the cleartext packet! Only S1 has the ESP keying material, and if LB forwards the packet elsewhere, the receiver will not be able to verify its integrity. Regards, Yaron _____ From: Grewal, Ken [mailto:ken.grewal@intel.com] Sent: Tuesday, October 21, 2008 23:56 To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Some observations below: 1. I agree with Yaron in that if a load balancer needs to 'terminate' the traffic before applying any rules to distribute the load, then it should have the keys to do so without any modifications to the current protocol. In this case, the session setup (via IKE) should have been negotiated with the load balancer and it is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of front end proxy to the multiple servers behind it in transport mode. 2. My understanding of a 'pure' load balancer is that it distributes traffic streams to different resources available to it and this is typically based on rules such as source / destination IP protocols, ports (e.g. TCP ports) and potentially some other information. Furthermore, as some of the upper layer protocols are stateful (e.g. TCP), it is desirable for the load balancer to ensure that a higher layer 'session' (e.g. TCP session) is 'pegged' to a resource (server) that has been handling the same session - this allows efficient state maintenance on a given resource / server, instead of all resources needing access to that state. Now if the traffic is protected using IPsec, then the load balancer needs access to upper layer payload data in the packet in order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibility provides for a clean solution where the load-balancer (as well as other network monitoring tools) is able to ascertain that the packet if not encrypted and hence look inside the packet to analyze the protocol / ports to make load balancing decisions. In this case, IPsec is still being terminated on the server behind the load balancer, but the load balancer can examine the IPsec protected packet en-route to ensure it gets to the right server. In essence, this charter item allows the load balancer (and other network tools) to continue to function in IPsec environments. 3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change based on new protocols / payloads. Thanks, - Ken _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, October 21, 2008 1:37 PM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) OK. But if your load balancer is able to decrypt the traffic (i.e. it has the credentials or secret keys), then it can do that with today's normal IKE/IPsec. There is no need in this case to modify the protocol to make it easier to detect encrypted traffic. Thanks, Yaron _____ From: Gary Hemminger [mailto:ghemminger@foundrynet.com] Sent: Tuesday, October 21, 2008 19:02 To: Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) The use case you are thinking about is probably pure IPsec VPN, where an encrypted stream only lives across the WAN. But what if you are a load balancer and the IPsec traffic is end to end? In this case, you may have a load balancer that needs to terminate the traffic so it can make the decision which server to handle the request. All load balancers today support SSL termination. Same thing applies to IPsec traffic. We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic. Gary From: Yaron Sheffer [mailto:yaronf@checkpoint.com] Sent: Tuesday, October 21, 2008 6:10 AM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) Hi Gary, I'm puzzled by the scenario you are presenting. I've been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that want to look at the IPsec-protected traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use case that you have in mind? Thanks, Yaron _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger Sent: Monday, October 20, 2008 20:26 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 I was talking about how to make the determination that the payload is encrypted. Evidently there are two approaches: one based on a heuristic, another based on a payload wrapper that flags the payload is encrypted. We would need some mechanism to determine the payload is encryped if we need to terminate the IPSEC traffic and make a determination of which server to send it to. Sorry about the confusion. Gary _____ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sat 10/18/2008 2:03 PM To: Gary Hemminger Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 Hi Gary. I'm not sure what heuristics you are talking about. The problem of re-authentication is simply this. The owner of the remote access gateway has a security policy that says that connections can be open for only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important part of risk management. If somebody steals your laptop (or mobile phone) or sits down at the Internet Cafe station where you were logged on, we want to limit the amount of time they are connected to the internal network. This requirement makes sense if the user has to type in their password to authenticate. It makes less sense if there are user certificates that are stored on the computer, or if the client software has a "save password" feature. Whether it makes sense or not, this is a requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are deleted. This creates a usability problem, because the SA is deleted without any advance warning to the user, so the user is likely to get a relatively long time with no connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to make accounts permanently offline when this happens. RFC 4778 and the improvement that Martin Willi is proposing, are aimed at solving this usability problem by informing the client software in advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The heuristic does not affect the security or the IPsec streams. Yoav On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: One comment on the heuristics approach. As a hardware vendor of L4-7 ADC boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended. What I mean is that the heuristic may be easy to define now, but there is no certainty that it would remain this way. My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway. While I like the idea of some "other" box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the "other" box, I think we should think about the long term, not the short term. Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit. Gary [IPsec] Reauthentication extension for IKEv2 _____ * To: Martin Willi > * Subject: [IPsec] Reauthentication extension for IKEv2 * From: Tero Kivinen > * Date: Tue, 16 Sep 2008 12:09:14 +0300 * Cc: ipsec at ietf.org * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com * Delivered-to: ipsec at core3.amsl.com * In-reply-to: <48CF5D7D.7070701 at strongswan.org> * List-archive: * List-help: * List-id: Discussion of IPsec protocols * List-post: * List-subscribe: , * List-unsubscribe: , * References: <48CF5D7D.7070701 at strongswan.org> * Sender: ipsec-bounces at ietf.org _____ Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... The first question I have is why are you doing reauthentication at all? What is the benefits of the reauthentication? What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have. -- kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec _____ * Follow-Ups: * Re: [IPsec] Reauthentication extension for IKEv2 * From: Martin Willi * References: * [IPsec] Reauthentication extension for IKEv2 * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 * Previous by thread: [IPsec] Reauthentication extension for IKEv2 * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 * Index(es): * Date * Thread Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IE Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Scanned by Check Point Total Security Gateway. ------=_NextPart_001_016F_01C934F5.FA080030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable     ------=_NextPart_001_016F_01C934F5.FA080030-- ------=_NextPart_000_016E_01C934F5.FA080030 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyMzA3NTkwMlowIwYJKoZIhvcNAQkEMRYEFIJj4C9MslqT op9gaWcGMiRy9RapMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA nVQ3ixAUkRi7dxDR/F1+3kW4MSnbjTXKb56QXJKUDLQqW7YpmD4Ot0VkXSnO0fo7FS8lCHJd2e8n 09oCVdNCFDtT/lFWQOECePdg5roDmhQSOqFh+DgTLL/AaXHVsCgWF6ifavwCqu/KSW2ZYgFKynnK PLRElUQ6qEG8c7l+biayf+7ZiKTtrrNcdimMh1bYcDmcxObL684idISGbaELzwHhqQMnlgq97EoJ 0vER3AU+vh21X3ZuVbsVQ1swvPXdH/vpoPDxiaEZIg4gGPcOA1CIPZSKgZM6zv1hbh1N3Q3IszPj ImH64F+fK77o9HeimcVJ53o//u3G34RJjvJZOQAAAAAAAA== ------=_NextPart_000_016E_01C934F5.FA080030-- --===============0110236971== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0110236971==-- From ipsec-bounces@ietf.org Thu Oct 23 03:49:53 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15023A6C41; Thu, 23 Oct 2008 03:49:53 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B12E3A6C38 for ; Thu, 23 Oct 2008 03:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0lciyuJnViM for ; Thu, 23 Oct 2008 03:49:44 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 2579A3A6A05 for ; Thu, 23 Oct 2008 03:49:35 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m9NAoi4E018860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 13:50:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m9NAogsU021258; Thu, 23 Oct 2008 13:50:42 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18688.22274.167896.32656@fireball.kivinen.iki.fi> Date: Thu, 23 Oct 2008 13:50:42 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <48B64A69.2010705@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 29 min X-Total-Time: 30 min Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2-bis notes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Paul Hoffman writes: > - Sec. 1: "intended to replace": the status WRT IKEv1 and IKEv2 is > obviously very different. I suggest: > > [4306] has obsoleted the IKEv1 document set. The current > document replaces [IKEv2] and [Clarif] by a single unified > description of the IKEv2 protocol. > > ===Not done, take this to the list. I think the current working is > actually more correct than the proposed rewording. What is the current text for that? I think we should be clear that this document plans to obsolete the RFC4306 which already obsoleted IKEv1. > - 2.3: The first paragraph contains an apparent contradiciton. It > mentions that pipelining is done "if the other endpoint has > indicated its ability to handle such requests" and then goes on to > describe how a pipelining implementation can interoperate with a > non-pipelining one. Which should be trivial if the pipelining side > knows what the other side is capable of. > > ===Not done, definitely worth discussing on the list. I do not really see what is the contradiction there. Could you explain better what you think is the problem there. > - 2.4: Clarif-7.9 is unclear: "however, receiving parties need to > deal with it in other requests" - what requests? How? Why should > it ever happen? > ===Not done, needs to be discussed on the list. I would interpret that text so that it should cause the other end crash, or fail the whole negotiation even if INITIAL_CONTACT notification is sent in the wrong message, i.e. implementations can either silently ignore it or processes it if it comes in the wrong message. I.e. even if it comes in IKE_SA_INIT or some other IKE_AUTH than first, or as separate INFORMATIONAL exchange, the receiving end of that should allow the exchange to continue. The reason it can come in wrong exchange, is that some implmentation sent it in wrong place as the original RFC4306 didn't specify fixed place for it. That kind of implementation is not conformant with the ikev2bis document (violating MUST), but it was conframnt to RFC4306 as it didn't specify where the notification needs to be, so that kind of RFC4306 style implementations might be out there and we want to keep backward compatibility with them still. > - 3.3.2: there is no explanation here or elsewhere what is meant by > the D-H transform for ESP and AH. If nobody's using it, it should > be depracated. > > ===Not done. This is for PFS, yes? Yes, and is very commonly used and part of testing done in interops. > - 3.5: we mention that ID_KEY_ID is opaque and vendor specific, and > then we have a MUST implement of ID_KEY_ID for interoperability. > This is a contradiction. I do not see any contradiction there. We could perhaps add text saying that implementations should allow way to enter ID_KEY_ID any octect string as ID_KEY_ID (either as binary or as hex). I.e. the text saying it is opaque and vendor specific means that there is no format for it defined here for IKEv2 it is just opaque string. Perhaps we should remove the "vendor specific", as it is not really that, but more likely it will be "scenario/environment specific". > - 3.12: "Writers of Internet-Drafts who wish to extend this protocol > MUST define a Vendor ID payload to announce the ability to > implement the extension in the Internet-Draft." The rules for > notifications mean that this is often not needed, because you can > ignore unknown notifications. Can we eliminate this requirement? > > ===Not done; take to the list to see if anyone objects. The reason for requiring vendor id payloads is that before those internet-drafts (note, note rfcs, but drafts) are published the numbers used for them (i.e. the notify message types) are allocated from the private use place, and there can be operlapping numbers for them. Thus for testing those we need to have some way of telling which numbers we are using, i.e. whether the notify message type 40960 means MOBIKE_SUPPORTED or MULTIPLE_AUTH_SUPPORTED. When those drafts go to the RFCs and the private use numbers are replaced with proper iana allocated numbers then there is no need for vendor id payloads anymore. But the vendor id payloads are still needed for the before-iana-allocation phase. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 23 07:54:18 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFDB63A6883; Thu, 23 Oct 2008 07:54:17 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A873C3A685C for ; Thu, 23 Oct 2008 07:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYFHDioV4jk4 for ; Thu, 23 Oct 2008 07:54:08 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 708A83A69AD for ; Thu, 23 Oct 2008 07:54:07 -0700 (PDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NEtMY1014668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 07:55:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18688.22274.167896.32656@fireball.kivinen.iki.fi> References: <48B64A69.2010705@checkpoint.com> <18688.22274.167896.32656@fireball.kivinen.iki.fi> Date: Thu, 23 Oct 2008 07:55:21 -0700 To: Tero Kivinen From: Paul Hoffman Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2-bis notes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero, it would be better if each of the issues had their own thread, just as we did for your list of issues on the same document. Please wait until Yaron and I start those threads, and then comment. Putting all the open issues into one thread will not be helpful to the WG. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 23 08:12:36 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378663A68D7; Thu, 23 Oct 2008 08:12:36 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2CD83A68D7 for ; Thu, 23 Oct 2008 08:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPx9ZGo-kFA6 for ; Thu, 23 Oct 2008 08:12:26 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 95F643A6883 for ; Thu, 23 Oct 2008 08:12:23 -0700 (PDT) Received: from webmail.nist.gov (webmail.nist.gov [129.6.16.34]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9NFDZTN004942 for ; Thu, 23 Oct 2008 11:13:35 -0400 Received: from apache by webmail.nist.gov with local (Exim 4.63) (envelope-from ) id 1Kt1sV-0004tA-6y for IPsec@ietf.org; Thu, 23 Oct 2008 11:13:35 -0400 Received: from pool-96-240-136-139.washdc.fios.verizon.net (pool-96-240-136-139.washdc.fios.verizon.net [96.240.136.139]) by webmail.nist.gov (Horde Framework) with HTTP; Thu, 23 Oct 2008 11:13:35 -0400 Message-ID: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov> Date: Thu, 23 Oct 2008 11:13:35 -0400 From: "Sheila Frankel" To: IPsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline User-Agent: Internet Messaging Program (IMP) H3 (4.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Subject: [IPsec] Roadmap doc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="Yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org We expect to post a version of the roadmap doc before the Minneapolis IETF. Meanwhile, we wanted to request input from the list on the doc's contents. Here is the proposed TOC for the roadmap doc: 1. Introduction 2. IPsec/IKE Background Information 2.1. Interrelationship of IPsec/IKE Documents 2.2 Versions of IPsec 2.2.1. Differences between "old" IPsec and "new" IPsec 2.3. Versions of IKE 2.3.1. Differences between IKEv1 and IKEv2 3. IPsec Documents 3.1. Base Documents 3.1.1. "Old" IPsec 3.1.2. "New" IPsec 3.2. Policy 3.3. MIBs 3.4. Additions to IPsec 3.5. General Considerations 4. IKE Documents 4.1. Base Documents 4.1.1. IKEv1 (IKE) 4.1.2. IKEv2 4.2. Additions and Extensions 4.2.1. Peer Authentication Methods 4.2.2. Certificate Contents and Management 4.2.3. Dead Peer Detection 5. Cryptographic Algorithms and Suites 5.1. Encryption Algorithms 5.2. Integrity-Protection (Authentication) Algorithms 5.2.1. General Considerations 5.3. Combined Algorithms 5.2.1. General Considerations 5.4. Pseudo-Random Functions (PRFs) 5.5. Cryptographic Suites 5.6. Diffie-Hellman Algorithms 6. IPsec/IKE for Multicast 7. Outgrowths of IPsec/IKE 7.1. IPComp (Compression) 7.2. IKEv2 Mobility and Multihoming (MobIKE) 7.3. Better-than-Nothing Security (Btns) 7.4. Kerberized Internet Negotiation of Keys (Kink) 7.5. IPsec Secure Remote Access (IPSRA) 7.6. IPsec Keying Information Resource Record (IPsecKEY) 8. Other Protocols that use IPsec/IKE 8.1. Mobile IP (MIPv4 and MIPv6) 8.2. Open Shortest Path First (OSPF) 8.3. Host Identity Protocol (HIP) 8.4. Extensible Authentication Protocol (EAP) Method Update (EMU) 10 8.5. Stream Control Transmission Protocol (SCTP) 8.6. Fibre Channel 9. Security Considerations 10. IANA Considerations 11. References 11.1. Normative References 11.2. Informative References Sections 1 and 2 will contain introductory material about IPsec and IKE: their functions, placement in the stack, inter-relationships, etc. The rest of the doc will basically be a list of RFCs, with a brief description of each. For the cryptographic algorithms, each section will describe where each type of algorithm is used within IPsec and/or IKE. For each algorithm, the following information will be included: whether it applies to IPsec, IKE, or both; requirement level (MUST etc.); special considerations (e.g. cannot be used with manual keying); how widely/commonly it is deployed. Section 8 (other protocols that use IPsec/IKE) will very briefly mention the context in which each protocol and/or RFC uses IPsec/IKE. Questions for the list: 1) Are there any other topics that should be discussed? 2) Are there other classes of RFCs that should be included? 3) The doc currently includes "old" IPsec and IKEv1. Should they be eliminated? Sheila and Suresh _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 23 09:26:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED39A3A6935; Thu, 23 Oct 2008 09:26:16 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA713A66B4; Thu, 23 Oct 2008 09:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-kxh0kf9gv2; Thu, 23 Oct 2008 09:26:13 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 28F783A6821; Thu, 23 Oct 2008 09:26:12 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Kt30t-0000Ml-8E; Thu, 23 Oct 2008 18:26:19 +0200 X-Hashcash: 1:20:081023:mext@ietf.org::2QF7DldS3LaqWBYk:00001Xc+ From: arno@natisbad.org (Arnaud Ebalard) To: "Sheila Frankel" References: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:081023:sheila.frankel@nist.gov::Fe/iiUSwBeIyuotH:000000000000000000000000000000000000002pcD X-Hashcash: 1:20:081023:ipsec@ietf.org::ndUaEzrUX4jQ/2y0:0009VIc Date: Thu, 23 Oct 2008 18:24:23 +0200 In-Reply-To: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov> (Sheila Frankel's message of "Thu, 23 Oct 2008 11:13:35 -0400") Message-ID: <87skqnl1oo.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: IPsec@ietf.org, IETF MEXT WG ML Subject: Re: [IPsec] Roadmap doc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, [mext added in CC] "Sheila Frankel" writes: > 7. Outgrowths of IPsec/IKE > 7.1. IPComp (Compression) > 7.2. IKEv2 Mobility and Multihoming (MobIKE) > 7.3. Better-than-Nothing Security (Btns) > 7.4. Kerberized Internet Negotiation of Keys (Kink) > 7.5. IPsec Secure Remote Access (IPSRA) > 7.6. IPsec Keying Information Resource Record (IPsecKEY) > 8. Other Protocols that use IPsec/IKE > 8.1. Mobile IP (MIPv4 and MIPv6) IMHO, MIPv6 is user of IPsec/IKE but not a common user: it uses IPsec/IKE for its protection but it also has some very tight interactions with IKE/IPsec/[PF_KEY] and for that reason, specific requirements: - configuration via IKEv2 (various RFC) - bootstrapping and efficient handling of movement in IPsec/IKE context (see draft draft-ebalard-mext-pfkey-enhanced-migrate-00 which is a follow-up of draft-sugimoto-mip6-pfkey-migrate-04) The problem is that this last item sits in the middle of the field with IPsec WG on one side and MIPv6 on the other; each side considering that it should be handled by the other. At the moment, MIPv6 specification documents (3775, 3776, 4877, 5026, ...) have expectations on the behavior in IPsec/IKE environments but IPsec/IKE (and possibly PF_KEY) are missing the interfaces to support those requirements. This is currently making progress outside any working group. In the end, I am wondering where this item stand w.r.t the roadmap document. I know that it is not in the initial set of work items of the WG but this does not prevent clarifying the position of the WG on it in the doc, does it? > 8.2. Open Shortest Path First (OSPF) > 8.3. Host Identity Protocol (HIP) > 8.4. Extensible Authentication Protocol (EAP) Method Update (EMU) 10 > 8.5. Stream Control Transmission Protocol (SCTP) > 8.6. Fibre Channel > 9. Security Considerations > 10. IANA Considerations > 11. References > 11.1. Normative References > 11.2. Informative References > > Sections 1 and 2 will contain introductory material about IPsec and > IKE: their functions, placement in the stack, inter-relationships, > etc. > > The rest of the doc will basically be a list of RFCs, with a brief > description of each. For the cryptographic algorithms, each section > will describe where each type of algorithm is used within IPsec and/or > IKE. For each algorithm, the following information will be included: > whether it applies to IPsec, IKE, or both; requirement level (MUST > etc.); special considerations (e.g. cannot be used with manual > keying); how widely/commonly it is deployed. Section 8 (other > protocols that use IPsec/IKE) will very briefly mention the context in > which each protocol and/or RFC uses IPsec/IKE. > > Questions for the list: > 1) Are there any other topics that should be discussed? the one above, i.e. where should MIPv6 IPsec/IKE roadmap/work be handled ;-) Cheers, a+ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 23 10:28:41 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804FF3A67AF; Thu, 23 Oct 2008 10:28:41 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB0D93A67AF for ; Thu, 23 Oct 2008 10:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTonchuUMLIf for ; Thu, 23 Oct 2008 10:28:38 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3CC2D3A6767 for ; Thu, 23 Oct 2008 10:28:37 -0700 (PDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9NHTrRp029217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Oct 2008 10:29:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1696498986EFEC4D9153717DA325CB7201860ECA@vaebe104.NOE.Nokia.com> References: <1696498986EFEC4D9153717DA325CB7201860ECA@vaebe104.NOE.Nokia.com> Date: Thu, 23 Oct 2008 10:29:51 -0700 To: , From: Paul Hoffman Subject: Re: [IPsec] My notes about IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org [[ The responses have the same format as before. ]] Abstract: needs rephrasing, include at least "IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs)" from RFC 4306 abstract. ===Done. 1.5: Needs rephrasing, maybe merge with 2.21. ===Not done. They don't seem that tightly linked. 2.4: "receiving parties need to deal with it in other requests" Is this right, and how it's dealt with? And only requests, not responses? ===Not done, should be taken to the list. 2.5: Needs to clarify what exactly the message containing the INVALID_MAJOR_VERSION notification looks like (Fukumoto Atsushi's email 2007-06-12) ===Not done, should be taken to the list. 2.6 (near Clarif-2.1) and 2.6.1: needs rephrasing/more explanation (especially "MUST NOT fail" is unclear). ===Not done, should be taken to the list. 2.7 and 3.3.6, possible contradiction about INVALID_KE_PAYLOAD ("MUST again propose its full set of." vs. "SHOULD, however, continue to propose its full supported set") ===Not done, should be taken to the list. 2.7 and 3.3.6: text about INVALID_KE_PAYLOAD might need clarification: if none of the proposed groups is acceptable, NO_PROPOSA_CHOSEN is the correct notification (thread "Is this a good use of the INVALID_KE_PAYLOAD notification", May 2007) ===Not done, should be taken to the list. 2.8: might be wrong place for Clarif-5.9. ===Done. Moved it to 2.2, where the term is first used. 2.8: maybe clarify that when rekeying, the new SA might have different traffic selectors and algorithms than the old one? ===Done. 2.8: probably should clarify what you do when you receive NO_PROPOSAL_CHOSEN during IKE_SA rekeying ===Not done, should be taken to the list. 2.9.1: might not fully consistent with RFC 4301 regarding decorrelated policy etc. (emails 2008-11-28 and 2008-11-30). ===Not done, should be taken to the list. 2.19: text about FAILED_CP_REQUIRED needs editing, and it's in wrong place (breaks flow of other text) ===Not done, should be taken to the list. 2.19 and 2.19.1: needs editing/rephrasing, perhaps merging these two sections to improve flow. ===Not done, deferred to next version so we can have the new section vetted by the WG to make sure we didn't lose anything. 2.19 and 3.15: text about configuration payloads is still in two places; either merge or more clearly separate what goes where. ===Not done, deferred to next version so we can have the new section vetted by the WG to make sure we didn't lose anything. 2.23: lots of bullets here, could be formatted in more readable way? ===Not done. This seems pretty readable as-is, and it makes it more clear what each requirement is. 5: "implementation using EAP MUST also use strong authentication", change from RFC 4306, and "strong" is ambiguous (e.g. is "group secret" strong?) ===Already done. 8.2: RFCs 2251, 2486, and 3513, and FIPS 180-1, have been obsoleted by newer documents. ===Done. Text doesn't cover all the exchange collisions from RFC 4718 Section 5.11 yet (but I doubt implementors will get many of those right anyway...). ===Not done, should be taken to the list. The document probably should talk about PAD in the context of IKE_SA authentication, and traffic selector authorization. ===Not done, should be taken to the list. INVALID_IKE_SPI needs some clarification (emails from 2007-10-17 to 2007-10-19) ===Done. There should be text about how a protected INVALID_SPI notification is processed. ===Not done, should be taken to the list. Mapping of incoming IKE packets to IKE_SA needs clarification (maybe in 2.1, 2.6 or 3.1): it's done using the recipient SPI only, not e.g. using the source IP address. ===Done. The text about transport mode NAT-T isn't right: it really needs to discuss how the SPD and TS payloads work, and it seems incremental checksum fixup can't work as described (I have longer notes about this topic based on discussions with Tero in December 2007). ===Not done, should be taken to the list. ADDITIONAL_TS_POSSIBLE probably needs clarification: it seems the recipient can't really use this for anything else than logging/debugging, if even that (thread August 2008) ===Not done. Need specific wording, becuase the current wording certainly makes it sound like it is more useful than that. Do traffic selectors containing port numbers make sense if the protocol is 0? (thread August 2008) ===Done. Would it be useful to have a separate section describing "CHILD_SA attributes" like ESN, ESP_TFC_PADDING_NOT_SUPPORTED, IPCOMP_SUPPORTED, NON_FIRST_FRAGMENTS_ALSO, etc.? ===Not done, pending proposed wording and discussion on the list. Do we need text about simultaneous reauthentication and/or simultaneous initiation of IKE_SAs? (email 2007-08-21, thread June 2008) ===Not done, given that those threads went into a rathole. Should we support OPAQUE protocol selectors for IPv6 (thread May/June 2007) ===Not done, technical change to the spec. Should we move features with no known implementations from the main text to an appendix? ===Not done, pending a list of such features and discussion on the list. The document will eventually need a "changes to RFC 4306" (or at least "changes that implementors of RFC 4306 should look at") section. ===Done. Well, it's already there as Section 1.7. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 23 18:12:18 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DBEA3A68AA; Thu, 23 Oct 2008 18:12:18 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E316C3A68D1 for ; Thu, 23 Oct 2008 18:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4Cfxh5TeBH4 for ; Thu, 23 Oct 2008 18:11:59 -0700 (PDT) Received: from smtp1gap.foundrynet.com (smtp1gap.foundrynet.com [76.199.70.29]) by core3.amsl.com (Postfix) with ESMTP id DC5073A67A3 for ; Thu, 23 Oct 2008 18:11:58 -0700 (PDT) Received: from xmail.ds.foundrynet.com (unknown [10.101.218.254]) by smtp1gap.foundrynet.com (Postfix) with ESMTP id 340593E0002; Thu, 23 Oct 2008 18:13:04 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 23 Oct 2008 18:12:45 -0700 Message-ID: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC80B@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) Thread-Index: AckxZQVE2aaPDMvETkeeBeM3SJ1SMgBfEkkhACbyvnAACETf8AAHhWiAAAKQj8AAALjDUAAD0PSgAA7QhJAAWGNl4A== References: <648EF152-A65D-4DC5-B978-825086BB3D09@checkpoint.com><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7E8@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7F7@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC7FF@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CC80B@il-ex01.ad.checkpoint.com> From: "Gary Hemminger" To: "Yaron Sheffer" , "Grewal, Ken" , "Yoav Nir" Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1463091998==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1463091998== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C93575.9F97F5D7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C93575.9F97F5D7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable This is correct. We would only need the new wrapper if we were inspecting, but not load balancing. Once we are configured to load balance, we would know, but if we were in inspection only mode, then we would need the wrapper to determine that the payload is encrypted. =20 Gary =20 From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 Sent: Wednesday, October 22, 2008 12:03 AM To: Gary Hemminger; Grewal, Ken; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 In that case, the load balancer can identify the traffic using the normal ESP SPI field, and knows exactly what kind of traffic it is and whether it is encrypted. There is no need to change the ESP protocol for this scenario. =20 Thanks, Yaron =20 ________________________________ From: Gary Hemminger [mailto:ghemminger@foundrynet.com]=20 Sent: Wednesday, October 22, 2008 2:00 To: Yaron Sheffer; Grewal, Ken; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 The client would negotiate IKE with the load balancer and would not directly negotiate with the Server. =20 Gary =20 From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 Sent: Tuesday, October 21, 2008 3:23 PM To: Grewal, Ken; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 Hi Ken, =20 Thanks for the clarification. But I still don't understand how your scenario works. =20 Assume for simplicity an environment where everybody uses ESP in transport mode, with null encryption. =20 Client C1 does an IKE negotiation with a random server (as selected by the load balancer) S1. They negotiate some ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn the SPI value. =20 Now when the first ESP packet is sent from C1 towards the load balancer, there is not enough information for it to forward the packet to S1, regardless of its being able to look into the cleartext packet! Only S1 has the ESP keying material, and if LB forwards the packet elsewhere, the receiver will not be able to verify its integrity. =20 Regards, Yaron =20 ________________________________ From: Grewal, Ken [mailto:ken.grewal@intel.com]=20 Sent: Tuesday, October 21, 2008 23:56 To: Yaron Sheffer; Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 Some observations below: =20 1. I agree with Yaron in that if a load balancer needs to 'terminate' the traffic before applying any rules to distribute the load, then it should have the keys to do so without any modifications to the current protocol. In this case, the session setup (via IKE) should have been negotiated with the load balancer and it is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of front end proxy to the multiple servers behind it in transport mode.=20 2. My understanding of a 'pure' load balancer is that it distributes traffic streams to different resources available to it and this is typically based on rules such as source / destination IP protocols, ports (e.g. TCP ports) and potentially some other information. Furthermore, as some of the upper layer protocols are stateful (e.g. TCP), it is desirable for the load balancer to ensure that a higher layer 'session' (e.g. TCP session) is 'pegged' to a resource (server) that has been handling the same session - this allows efficient state maintenance on a given resource / server, instead of all resources needing access to that state. Now if the traffic is protected using IPsec, then the load balancer needs access to upper layer payload data in the packet in order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibility provides for a clean solution where the load-balancer (as well as other network monitoring tools) is able to ascertain that the packet if not encrypted and hence look inside the packet to analyze the protocol / ports to make load balancing decisions. In this case, IPsec is still being terminated on the server behind the load balancer, but the load balancer can examine the IPsec protected packet en-route to ensure it gets to the right server. In essence, this charter item allows the load balancer (and other network tools) to continue to function in IPsec environments. 3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change based on new protocols / payloads.=20 =20 Thanks,=20 - Ken =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, October 21, 2008 1:37 PM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2) =20 OK. But if your load balancer is able to decrypt the traffic (i.e. it has the credentials or secret keys), then it can do that with today's normal IKE/IPsec. There is no need in this case to modify the protocol to make it easier to detect encrypted traffic. =20 Thanks, Yaron =20 ________________________________ From: Gary Hemminger [mailto:ghemminger@foundrynet.com]=20 Sent: Tuesday, October 21, 2008 19:02 To: Yaron Sheffer; Yoav Nir Cc: ipsec@ietf.org Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) =20 The use case you are thinking about is probably pure IPsec VPN, where an encrypted stream only lives across the WAN. But what if you are a load balancer and the IPsec traffic is end to end? In this case, you may have a load balancer that needs to terminate the traffic so it can make the decision which server to handle the request. All load balancers today support SSL termination. Same thing applies to IPsec traffic. We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic. =20 =20 Gary =20 From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 Sent: Tuesday, October 21, 2008 6:10 AM To: Gary Hemminger; Yoav Nir Cc: ipsec@ietf.org Subject: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2) =20 Hi Gary, =20 I'm puzzled by the scenario you are presenting. I've been considering the work on ESP-null detection (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that want to look at the IPsec-protected traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use case that you have in mind? =20 Thanks, Yaron =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger Sent: Monday, October 20, 2008 20:26 To: Yoav Nir Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 =20 I was talking about how to make the determination that the payload is encrypted. Evidently there are two approaches: one based on a heuristic, another based on a payload wrapper that flags the payload is encrypted. We would need some mechanism to determine the payload is encryped if we need to terminate the IPSEC traffic and make a determination of which server to send it to. Sorry about the confusion. =20 Gary =20 ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Sat 10/18/2008 2:03 PM To: Gary Hemminger Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 Hi Gary.=20 =20 I'm not sure what heuristics you are talking about. The problem of re-authentication is simply this. The owner of the remote access gateway has a security policy that says that connections can be open for only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important part of risk management. If somebody steals your laptop (or mobile phone) or sits down at the Internet Cafe station where you were logged on, we want to limit the amount of time they are connected to the internal network. This requirement makes sense if the user has to type in their password to authenticate. It makes less sense if there are user certificates that are stored on the computer, or if the client software has a "save password" feature. =20 Whether it makes sense or not, this is a requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are deleted. This creates a usability problem, because the SA is deleted without any advance warning to the user, so the user is likely to get a relatively long time with no connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook tends to make accounts permanently offline when this happens. =20 RFC 4778 and the improvement that Martin Willi is proposing, are aimed at solving this usability problem by informing the client software in advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The heuristic does not affect the security or the IPsec streams. =20 Yoav =20 On Oct 18, 2008, at 2:35 AM, Gary Hemminger wrote: =20 One comment on the heuristics approach. As a hardware vendor of L4-7 ADC boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended. What I mean is that the heuristic may be easy to define now, but there is no certainty that it would remain this way. My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway. =20 While I like the idea of some "other" box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the "other" box, I think we should think about the long term, not the short term. Just my opinion, and I am certainly flexible, but the heuristics approach worries me a bit. =20 Gary =20 [IPsec] Reauthentication extension for IKEv2 ________________________________ * To: Martin Willi >=20 * Subject: [IPsec] Reauthentication extension for IKEv2=20 * From: Tero Kivinen >=20 * Date: Tue, 16 Sep 2008 12:09:14 +0300=20 * Cc: ipsec at ietf.org =20 * Delivered-to: ietfarch-ipsec-web-archive at core3.amsl.com =20 * Delivered-to: ipsec at core3.amsl.com =20 * In-reply-to: <48CF5D7D.7070701 at strongswan.org >=20 * List-archive: =20 * List-help: =20 * List-id: Discussion of IPsec protocols =20 * List-post: =20 * List-subscribe: , =20 * List-unsubscribe: , =20 * References: <48CF5D7D.7070701 at strongswan.org >=20 * Sender: ipsec-bounces at ietf.org =20 ________________________________ Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... =20 The first question I have is why are you doing reauthentication at all? =20 What is the benefits of the reauthentication? =20 What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? =20 I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. =20 The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." =20 In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. =20 This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." =20 Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have.=20 --=20 kivinen at safenet-inc.com _______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 ________________________________ * Follow-Ups:=20 * Re: [IPsec] Reauthentication extension for IKEv2 =20 * From: Martin Willi * References:=20 * [IPsec] Reauthentication extension for IKEv2 =20 * From: Martin Willi * Prev by Date: [IPsec] Reauthentication extension for IKEv2 =20 * Next by Date: Re: [IPsec] Reauthentication extension for IKEv2 =20 * Previous by thread: [IPsec] Reauthentication extension for IKEv2 =20 * Next by thread: Re: [IPsec] Reauthentication extension for IKEv2 =20 * Index(es):=20 * Date * Thread =20 Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IE =20 Scanned by Check Point Total Security Gateway.=20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 Scanned by Check Point Total Security Gateway.=20 Scanned by Check Point Total Security Gateway.=20 Scanned by Check Point Total Security Gateway.=20 ------_=_NextPart_001_01C93575.9F97F5D7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

    This is correct.  We would only need the new wrapper = if we were inspecting, but not load balancing.  Once we are configured to load = balance, we would know, but if we were in inspection only mode, then we would need = the wrapper to determine that the payload is = encrypted.

     

    Gary

     

    From:= Yaron = Sheffer [mailto:yaronf@checkpoint.com]
    Sent: Wednesday, October 22, 2008 12:03 AM
    To: Gary Hemminger; Grewal, Ken; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

     

    In that case, the load balancer can identify the traffic = using the normal ESP SPI field, and knows exactly what kind of traffic it is and = whether it is encrypted. There is no need to change the ESP protocol for this = scenario.

     

    Thanks,

              &= nbsp; Yaron

     

    From:= Gary = Hemminger [mailto:ghemminger@foundrynet.com]
    Sent: Wednesday, October 22, 2008 2:00
    To: Yaron Sheffer; Grewal, Ken; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] Identifying encrypted traffic (was: = Reauthentication extension for IKEv2)

     

    The client would negotiate IKE  with the load = balancer and would not directly negotiate with the Server.

     

    Gary

     

    From:= Yaron = Sheffer [mailto:yaronf@checkpoint.com]
    Sent: Tuesday, October 21, 2008 3:23 PM
    To: Grewal, Ken; Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

     

    Hi Ken,

     

    Thanks for the clarification. But I still don’t = understand how your scenario works.

     

    Assume for simplicity an environment where everybody uses = ESP in transport mode, with null encryption.

     

    Client C1 does an IKE negotiation with a random server (as = selected by the load balancer) S1. They negotiate some ESP traffic stream, = denoted by an SPI. This whole thing is encrypted, so the load balancer cannot learn = the SPI value.

     

    Now when the first ESP packet is sent from C1 towards the = load balancer, there is not enough information for it to forward the packet = to S1, regardless of its being able to look into the cleartext packet! Only S1 = has the ESP keying material, and if LB forwards the packet elsewhere, the = receiver will not be able to verify its integrity.

     

    Regards,

              &= nbsp; Yaron

     

    From:= Grewal, = Ken [mailto:ken.grewal@intel.com]
    Sent: Tuesday, October 21, 2008 23:56
    To: Yaron Sheffer; Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

     

    Some observations below:

     

    1. I agree = with Yaron in that if a load balancer needs to ‘terminate’ = the traffic before applying any rules to distribute the load, then it should have the = keys to do so without any modifications to the current protocol. In this = case, the session setup (via IKE) should have been negotiated with the load = balancer and it is the natural termination point of the IPsec SA. The load = balancer is essentially acting as a VPN gateway for tunnel mode or some kind = of front end proxy to the multiple servers behind it in transport = mode.
    2. My = understanding of a ‘pure’ load balancer is that it distributes = traffic streams to different resources available to it and this is typically based on = rules such as source / destination IP protocols, ports (e.g. TCP ports) = and potentially some other information. Furthermore, as some of the = upper layer protocols are stateful (e.g. TCP), it is desirable for the = load balancer to ensure that a higher layer ‘session’ (e.g. TCP = session) is ‘pegged’ to a resource (server) that has been handling the same session – = this allows efficient state maintenance on a given resource / server, instead = of all resources needing access to that state. Now if the traffic is = protected using IPsec, then the load balancer needs access to upper layer = payload data in the packet in order to apply the aforementioned rules for = load balancing decisions. The charter item on traffic visibility = provides for a clean solution where the load-balancer (as well as other network monitoring tools) is able to ascertain that the packet if not = encrypted and hence look inside the packet to analyze the protocol / ports to = make load balancing decisions. In this case, IPsec is still being = terminated on the server behind the load balancer, but the load balancer can = examine the IPsec protected packet en-route to ensure it gets to the right = server. In essence, this charter item allows the load balancer (and other = network tools) to continue to function in IPsec environments. =
    3. I agree = with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change = based on new protocols / payloads.

     

    Thanks, =

    - = Ken

     

    From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yaron Sheffer
    Sent: Tuesday, October 21, 2008 1:37 PM
    To: Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Identifying encrypted traffic (was: Reauthentication extension for IKEv2)

     

    OK. But if your load balancer is able to decrypt the traffic = (i.e. it has the credentials or secret keys), then it can do that with = today’s normal IKE/IPsec. There is no need in this case to modify the protocol to make = it easier to detect encrypted traffic.

     

    Thanks,

              &= nbsp; Yaron

     

    From:= Gary = Hemminger [mailto:ghemminger@foundrynet.com]
    Sent: Tuesday, October 21, 2008 19:02
    To: Yaron Sheffer; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: Identifying encrypted traffic (was: [IPsec] Reauthentication extension for IKEv2)

     

    The use case you are thinking about is probably pure = IPsec VPN, where an encrypted stream only lives across the WAN.  But what if = you are a load balancer and the IPsec traffic is end to end?  In this case, = you may have a load balancer that needs to terminate the traffic so it can = make the decision which server to handle the request.  All load balancers = today support SSL termination.  Same thing applies to IPsec = traffic.  We cannot make the decision which server to handle the request, nor can we maintain persistence without decrypting the traffic.  =

     

    Gary

     

    From:= Yaron = Sheffer [mailto:yaronf@checkpoint.com]
    Sent: Tuesday, October 21, 2008 6:10 AM
    To: Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Identifying encrypted traffic (was: [IPsec] = Reauthentication extension for IKEv2)

     

    Hi Gary,

     

    I’m puzzled by the scenario you are presenting. = I’ve been considering the work on ESP-null detection (e.g. = draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that want to look at the IPsec-protected = traffic, but do NOT want to terminate IPsec (i.e. decapsulate the traffic). In = general, if you can terminate IPsec, that means that you have access to the = encryption keys and you can easily differentiate protected and unprotected traffic, Can = you explain the use case that you have in mind?

     

    Thanks,

              &= nbsp; Yaron

     

    From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Gary Hemminger
    Sent: Monday, October 20, 2008 20:26
    To: Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Reauthentication extension for = IKEv2

     

    I was talking about how to make the determination that the = payload is encrypted.  Evidently there are two approaches:  one based = on a heuristic, another based on a payload wrapper that flags the payload is encrypted.  We would need some mechanism to determine the payload = is encryped if we need to terminate the IPSEC traffic and make a = determination of which server to send it to.  Sorry about the = confusion.

     

    Gary

     

    From: Yoav Nir = [mailto:ynir@checkpoint.com]
    Sent: Sat 10/18/2008 2:03 PM
    To: Gary Hemminger
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Reauthentication extension for = IKEv2

    Hi Gary.

     

    I'm not sure what heuristics you are talking about. = The problem of re-authentication is simply this. The owner of the remote = access gateway has a security policy that says that connections can be open for = only so long (say, 2 hours) without authenticating the user again. This is a favorite requirement by auditors, who believe that this is an important = part of risk management. If somebody steals your laptop (or mobile phone) or = sits down at the Internet Cafe station where you were logged on, we want to limit = the amount of time they are connected to the internal network. This = requirement makes sense if the user has to type in their password to authenticate. = It makes less sense if there are user certificates that are stored on the = computer, or if the client software has a "save password" = feature.

     

    Whether it makes sense or not, this is a = requirement by auditors and regulators. If the user does not re-authenticate within the specified time, the IKE SA and all dependent child SAs are = deleted.  This creates a usability problem, because the SA is deleted = without any advance warning to the user, so the user is likely to get a relatively = long time with no connectivity. This can break TCP connections such as FTP, = HTTP, and IMAP. Outlook tends to make accounts permanently offline when this = happens.

     

    RFC 4778 and the improvement that Martin Willi is = proposing, are aimed at solving this usability problem by informing the client = software in advance when the re-authentication needs to be done, and allowing them = to re-authenticate early enough, so that connections are not broken. The = heuristic does not affect the security or the IPsec streams.

     

    Yoav

     

    On Oct 18, 2008, at 2:35 AM, Gary Hemminger = wrote:

     

    One = comment on the heuristics approach.  As a hardware vendor of L4-7 ADC = boxes, I am a little concerned about having to terminate IPSEC streams based on the heuristics approach, because this is open ended.  What I mean is = that the heuristic may be easy to define now, but there is no certainty that it = would remain this way.  My past experience suggests that eventually the heuristic would become too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed = anyway.   

    While I like the idea of some “other” box having to solve this issue, = which prevents clients from having to be changed, as we are a vendor of the “other” = box, I think we should think about the long term, not the short term.  Just my = opinion, and I am certainly flexible, but the heuristics approach worries me a = bit.

     

    Gary

     

    [IPsec] Reauthentication extension for = IKEv2

    Martin Willi =
writes:
    > What do you think about such an extension? =
Already considered something
    > similar, or does your reauthentication =
procedure work hassle-free? I'm
    > wondering if we are the only ones facing =
these problems or if such an
    > extension would gain broader =
acceptance...
     
    The first question I have is why are you doing =
reauthentication at
    all?
     
    What is the benefits of the =
reauthentication?
     
    What is the benefits of the reauthentication that =
can be done WITHOUT
    user intervention (i.e. no user typing in password =
or pin code or
    fingerprint or =
similar)?
     
    I myself can only really see benefits from =
reauthentication when it
    does require that user is really sitting there on =
the machine, and
    gives something that the machine itself cannot =
give. In those cases
    the user is required to type in something or do =
something anyways,
    thus it does not really matter if the =
communications is interrupted
    for second if user must stop his work for much =
longer time to type in
    his passphrase or pin =
code.
     
    The RFC 4478 simply skips this question and says =
"With some IPsec
    peers, particularly in the remote access scenario, =
it is desirable to
    repeat the mutual authentication periodically. The =
purpose of this is
    to limit the time that security associations (SAs) =
can be used by a
    third party who has gained control of the IPsec =
peer."
     
    In most cases if third party has gained control of =
the IPsec peer he
    will also get control of all authentication =
information inside the
    peer, including private keys and pre shared keys. =
Only way to make
    sure that he does not get access to those is to =
protect them with
    passphrase, or pin code or similar that is only =
known by the user.
     
    This is also said out in the RFC 4478: =
"However, in the remote access
    scenario it is usually up to a human user to =
supply the
    authentication credentials =
..."
     
    Because of this I do not think there is that much =
requirement for
    reauthentication protocol that is faster than what =
we already have. 
    -- 
    kivinen at =
safenet-inc.com
    _______________________________________________
    IPsec mailing =
list
    IPsec at =
ietf.org
    https://www.ietf.org=
/mailman/listinfo/ipsec
     
     
    • Follow-Ups<= /span>: =
        • From: Martin = Willi
    • References<= /span>: =
        • From: Martin = Willi

    Note: Messages sent to this list are the = opinions of the senders and do not imply endorsement by the = IE

     



    Scanned by Check Point Total Security Gateway. 

    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org= /mailman/listinfo/ipsec

     



    Scanned by Check Point Total Security Gateway.



    Scanned by Check Point Total Security Gateway.



    Scanned by Check Point Total Security Gateway.

    ------_=_NextPart_001_01C93575.9F97F5D7-- --===============1463091998== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1463091998==-- From ipsec-bounces@ietf.org Thu Oct 23 23:16:30 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40E193A659A; Thu, 23 Oct 2008 23:16:30 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173A23A659A for ; Thu, 23 Oct 2008 23:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfQ8pCcgDj0T for ; Thu, 23 Oct 2008 23:16:28 -0700 (PDT) Received: from ns.64translator.com (ns.64translator.com [202.214.123.16]) by core3.amsl.com (Postfix) with ESMTP id CBC1E3A6358 for ; Thu, 23 Oct 2008 23:16:27 -0700 (PDT) Received: from bahamas.64translator.com (bahamas.64translator.com [10.21.32.3]) by ns.64translator.com (8.14.2/8.14.2) with ESMTP id m9O6GXst045181 for ; Fri, 24 Oct 2008 15:16:33 +0900 (JST) (envelope-from akisada@tahi.org) Received: from localhost (dhcp163.64translator.com [10.21.32.163]) by bahamas.64translator.com (8.13.6/8.13.6) with SMTP id m9O6GOrB086529 for ; Fri, 24 Oct 2008 15:16:24 +0900 (JST) (envelope-from akisada@tahi.org) Date: Fri, 24 Oct 2008 15:16:11 +0900 From: Yukiyo Akisada To: ipsec@ietf.org Message-Id: <20081024151611.0e2f46fc.akisada@tahi.org> Organization: TAHI Project X-Mailer: Sylpheed version 2.3.0beta5 (GTK+ 2.8.12; i386-portbld-freebsd4.11) Mime-Version: 1.0 Subject: [IPsec] [Camellia/IPsec] Call for Review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, all. This is the another announcement of the public review other than IKEv2. IPv6 Ready Logo Committee would like to call for review of IPv6 Ready Logo Program Phase-2 for "IPsec". IPsec Logo Program has been running since Sep., 2004. And in this time, we would like to support RFC 4312 Camellia as the optional encryption algorithm. Test specification and test scenario are available on . Test tool for dry-run will come soon. Please send any comments to by Nov. 23rd. Thanks for your feedback. -- Yukiyo Akisada _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 24 01:40:13 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147EB3A6A11; Fri, 24 Oct 2008 01:40:13 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170973A6A0F for ; Fri, 24 Oct 2008 01:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.415 X-Spam-Level: X-Spam-Status: No, score=-6.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdEkGGjMJTgF for ; Fri, 24 Oct 2008 01:40:11 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0746E3A696A for ; Fri, 24 Oct 2008 01:40:10 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9O8fGvw003549; Fri, 24 Oct 2008 11:41:29 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 11:41:14 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 11:41:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Oct 2008 11:41:13 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72020058D7@vaebe104.NOE.Nokia.com> In-Reply-To: <18679.20905.763167.3524@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA Thread-Index: AckvnMJvB2v6ZiKySlekv0emn/8KjQGFn5yQ References: <18648.62020.138458.908262@fireball.kivinen.iki.fi><18650.7814.808443.474300@fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB7201E72AFB@vaebe104.NOE.Nokia.com><18676.37638.443520.835980@fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB7201EEFF7D@vaebe104.NOE.Nokia.com> <18679.20905.763167.3524@fireball.kivinen.iki.fi> From: To: X-OriginalArrivalTime: 24 Oct 2008 08:41:14.0479 (UTC) FILETIME=[463147F0:01C935B4] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > > No, it does *not* match -- the block size is 128 bits (16 octets), > > while the IV length in Section 3.1 of RFC 3686 is 8 octets. > > True. > > But this is exactly same situation we have with AES-GCM (IV = 8 bytes, > block size is 16 bytes). Does that mean that we cannot use AES-GCM > regardless that we have rfc5282 as RFC 4306 mandates the IV to be same > as block length? > > I myself think that if the algorithm specific RFC (RFC 5282 for > AES-GCM and RFC 3686 for AES-CTR) specifies some other IV processing > rules those are used even when the RFC 4306 says that the iv length is > equal the block length of the underlying encryption algorithm. Note that AES-GCM was already specified in RFC 4106; RFC 5282 updates the necessary parts of RFC 4306 so that 4106 can actually be used. We couldn't just use RFC 4106 without RFC 5282; for similar reasons, we can't use RFC 3686 as-is, but need to slightly update RFC 4306 text on this point (either in IKEv2bis or in a separate draft). If you're suggesting doing it in IKEv2bis (sounds like a reasonable idea to me), please send text :) Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 24 01:48:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C17928B56A; Fri, 24 Oct 2008 01:48:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2C053A67D9 for ; Fri, 24 Oct 2008 01:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.418 X-Spam-Level: X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgJL3IM2S2wi for ; Fri, 24 Oct 2008 01:48:20 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id AF4BF3A6A0E for ; Fri, 24 Oct 2008 01:48:19 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9O8nT7n017404; Fri, 24 Oct 2008 11:49:38 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 11:48:59 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 11:48:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Oct 2008 11:48:54 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72020058F0@vaebe104.NOE.Nokia.com> In-Reply-To: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Roadmap doc Thread-Index: Ack1If8JUgXJOaK6QAijr3ACgZHeMwAkoVBA References: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov> From: To: , X-OriginalArrivalTime: 24 Oct 2008 08:48:55.0662 (UTC) FILETIME=[591438E0:01C935B5] X-Nokia-AV: Clean Subject: Re: [IPsec] Roadmap doc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org BTW, yesterday IESG approved a similar roadmap document about SIP: http://tools.ietf.org/html/draft-ietf-sip-hitchhikers-guide Also, TCPM WG did a roadmap about TCP specs a while ago: http://tools.ietf.org/html/rfc4614 You might want to take a look at these, and copy some of their ideas about organizing the document etc. IMHO we should include the "version 2" IPsec specs (RFC 24xx) since they're widely used (and perhaps even mention "version 1" IPSec, RFC 18xx, in a "Historical Documents" appendix or something, even if just saying "these are for historical interest only"). Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of ext Sheila Frankel > Sent: 23 October, 2008 18:14 > To: IPsec@ietf.org > Subject: [IPsec] Roadmap doc > > We expect to post a version of the roadmap doc before the > Minneapolis > IETF. Meanwhile, we wanted to request input from the list on > the doc's > contents. > > Here is the proposed TOC for the roadmap doc: > > 1. Introduction > 2. IPsec/IKE Background Information > 2.1. Interrelationship of IPsec/IKE Documents > 2.2 Versions of IPsec > 2.2.1. Differences between "old" IPsec and "new" IPsec > 2.3. Versions of IKE > 2.3.1. Differences between IKEv1 and IKEv2 > 3. IPsec Documents > 3.1. Base Documents > 3.1.1. "Old" IPsec > 3.1.2. "New" IPsec > 3.2. Policy > 3.3. MIBs > 3.4. Additions to IPsec > 3.5. General Considerations > 4. IKE Documents > 4.1. Base Documents > 4.1.1. IKEv1 (IKE) > 4.1.2. IKEv2 > 4.2. Additions and Extensions > 4.2.1. Peer Authentication Methods > 4.2.2. Certificate Contents and Management > 4.2.3. Dead Peer Detection > 5. Cryptographic Algorithms and Suites > 5.1. Encryption Algorithms > 5.2. Integrity-Protection (Authentication) Algorithms > 5.2.1. General Considerations > 5.3. Combined Algorithms > 5.2.1. General Considerations > 5.4. Pseudo-Random Functions (PRFs) > 5.5. Cryptographic Suites > 5.6. Diffie-Hellman Algorithms > 6. IPsec/IKE for Multicast > 7. Outgrowths of IPsec/IKE > 7.1. IPComp (Compression) > 7.2. IKEv2 Mobility and Multihoming (MobIKE) > 7.3. Better-than-Nothing Security (Btns) > 7.4. Kerberized Internet Negotiation of Keys (Kink) > 7.5. IPsec Secure Remote Access (IPSRA) > 7.6. IPsec Keying Information Resource Record (IPsecKEY) > 8. Other Protocols that use IPsec/IKE > 8.1. Mobile IP (MIPv4 and MIPv6) > 8.2. Open Shortest Path First (OSPF) > 8.3. Host Identity Protocol (HIP) > 8.4. Extensible Authentication Protocol (EAP) Method > Update (EMU) 10 > 8.5. Stream Control Transmission Protocol (SCTP) > 8.6. Fibre Channel > 9. Security Considerations > 10. IANA Considerations > 11. References > 11.1. Normative References > 11.2. Informative References > > Sections 1 and 2 will contain introductory material about IPsec and > IKE: their functions, placement in the stack, > inter-relationships, etc. > > The rest of the doc will basically be a list of RFCs, with a brief > description of each. For the cryptographic algorithms, each section > will describe where each type of algorithm is used within > IPsec and/or > IKE. For each algorithm, the following information will be included: > whether it applies to IPsec, IKE, or both; requirement level (MUST > etc.); special considerations (e.g. cannot be used with manual > keying); how widely/commonly it is deployed. Section 8 (other > protocols that use IPsec/IKE) will very briefly mention the > context in > which each protocol and/or RFC uses IPsec/IKE. > > Questions for the list: > 1) Are there any other topics that should be discussed? > 2) Are there other classes of RFCs that should be included? > 3) The doc currently includes "old" IPsec and IKEv1. Should they be > eliminated? > > Sheila and Suresh > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 24 02:00:52 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1903A69D4; Fri, 24 Oct 2008 02:00:52 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A358D3A69D4 for ; Fri, 24 Oct 2008 02:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsqEfCW6krOV for ; Fri, 24 Oct 2008 02:00:49 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 874EE3A68E5 for ; Fri, 24 Oct 2008 02:00:49 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9O920dX029194; Fri, 24 Oct 2008 12:02:07 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 12:02:01 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Oct 2008 12:02:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Oct 2008 12:01:59 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720200591A@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Resuming the session resumption discussion Thread-Index: AckopDzAomXWdSTRR92GCa0aYh3ZiwNEb4Zw References: <48EB97DD.2040305@qualcomm.com><4c5c7a6d0810070617q7816d710q2e96080a47057572@mail.gmail.com> From: To: , X-OriginalArrivalTime: 24 Oct 2008 09:02:01.0079 (UTC) FILETIME=[2D395870:01C935B7] X-Nokia-AV: Clean Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Based on a quick look, draft-tschofenig-ipsecme-ikev2-resumption looks like draft-sheffer-ipsec-failover minus the bits that went beyond the scope of this work item (like failover), so it would seem to fit the charter text "To the degree its content falls within the scope of this work item, text and ideas from draft-sheffer-ipsec-failover will be used as a starting point" pretty well. It's also similar to RFC 5077, also mentioned in the work item description -- unlike draft-xu-ike-sa-sync, which is closer to the original RFC 2246 session resumption than RFC 5077. Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of ext Paul Hoffman > Sent: 07 October, 2008 20:43 > To: ipsec@ietf.org > Subject: [IPsec] Resuming the session resumption discussion > > > > We now have revised drafts from the two parties who has > published earlier drafts on session resumption. The > (truncated) announcements are below. > > The WG should start discussing what we want from session > resumption and which of these two drafts (or what ideas from > each of these two drafts) is of interest to the WG. As a > reminder, I start off with what our charter says. > > Extra points are awarded for not copying this entire message > in your response. :-) > > --Paul Hoffman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 24 02:47:40 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CAFD3A67AB; Fri, 24 Oct 2008 02:47:40 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929BA3A6874; Fri, 24 Oct 2008 02:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFiL6lPlkY66; Fri, 24 Oct 2008 02:47:37 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 95A743A63D2; Fri, 24 Oct 2008 02:47:36 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D154B294005; Fri, 24 Oct 2008 11:48:56 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7895C294003; Fri, 24 Oct 2008 11:48:55 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9O9mske028393; Fri, 24 Oct 2008 11:48:54 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Fri, 24 Oct 2008 11:48:54 +0200 From: Yaron Sheffer To: Arnaud Ebalard , Sheila Frankel Date: Fri, 24 Oct 2008 11:48:50 +0200 Thread-Topic: [IPsec] Roadmap doc Thread-Index: Ack1LGRMyAD/vdBoTUy7kyh2AGIFdAAjt8Tw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CCA70@il-ex01.ad.checkpoint.com> References: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov> <87skqnl1oo.fsf@natisbad.org> In-Reply-To: <87skqnl1oo.fsf@natisbad.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "IPsec@ietf.org" , IETF MEXT WG ML Subject: Re: [IPsec] Roadmap doc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0289001390==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0289001390== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0012_01C935CE.7B08A8F0" ------=_NextPart_000_0012_01C935CE.7B08A8F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sheila, Arnaud, First, I am happy with the outline as presented here, including the 24XX documents. If anything, it may be too ambitious (i.e. lengthy). Regarding the interactions of MIP6 with IKE/IPsec: - The Roadmap document should cover these areas, just as it covers other consumers of this technology. But despite its (unfortunate) name, I don't see the document as a future-looking position statement of the WG, but rather as documentation of completed work. - As for the actual work on MIP6/IPsec dependencies: the ipsecme WG is busy today with documents that have far wider applicability to the IPsec community. _If_ there is strong interest in these issues from a specific community of people, perhaps the way to go about it is with a dedicated design team. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Arnaud Ebalard Sent: Thursday, October 23, 2008 18:24 To: Sheila Frankel Cc: IPsec@ietf.org; IETF MEXT WG ML Subject: Re: [IPsec] Roadmap doc Hi, [mext added in CC] "Sheila Frankel" writes: > 7. Outgrowths of IPsec/IKE > 7.1. IPComp (Compression) > 7.2. IKEv2 Mobility and Multihoming (MobIKE) > 7.3. Better-than-Nothing Security (Btns) > 7.4. Kerberized Internet Negotiation of Keys (Kink) > 7.5. IPsec Secure Remote Access (IPSRA) > 7.6. IPsec Keying Information Resource Record (IPsecKEY) > 8. Other Protocols that use IPsec/IKE > 8.1. Mobile IP (MIPv4 and MIPv6) IMHO, MIPv6 is user of IPsec/IKE but not a common user: it uses IPsec/IKE for its protection but it also has some very tight interactions with IKE/IPsec/[PF_KEY] and for that reason, specific requirements: - configuration via IKEv2 (various RFC) - bootstrapping and efficient handling of movement in IPsec/IKE context (see draft draft-ebalard-mext-pfkey-enhanced-migrate-00 which is a follow-up of draft-sugimoto-mip6-pfkey-migrate-04) The problem is that this last item sits in the middle of the field with IPsec WG on one side and MIPv6 on the other; each side considering that it should be handled by the other. At the moment, MIPv6 specification documents (3775, 3776, 4877, 5026, ...) have expectations on the behavior in IPsec/IKE environments but IPsec/IKE (and possibly PF_KEY) are missing the interfaces to support those requirements. This is currently making progress outside any working group. In the end, I am wondering where this item stand w.r.t the roadmap document. I know that it is not in the initial set of work items of the WG but this does not prevent clarifying the position of the WG on it in the doc, does it? > 8.2. Open Shortest Path First (OSPF) > 8.3. Host Identity Protocol (HIP) > 8.4. Extensible Authentication Protocol (EAP) Method Update (EMU) 10 > 8.5. Stream Control Transmission Protocol (SCTP) > 8.6. Fibre Channel > 9. Security Considerations > 10. IANA Considerations > 11. References > 11.1. Normative References > 11.2. Informative References > > Sections 1 and 2 will contain introductory material about IPsec and > IKE: their functions, placement in the stack, inter-relationships, > etc. > > The rest of the doc will basically be a list of RFCs, with a brief > description of each. For the cryptographic algorithms, each section > will describe where each type of algorithm is used within IPsec and/or > IKE. For each algorithm, the following information will be included: > whether it applies to IPsec, IKE, or both; requirement level (MUST > etc.); special considerations (e.g. cannot be used with manual > keying); how widely/commonly it is deployed. Section 8 (other > protocols that use IPsec/IKE) will very briefly mention the context in > which each protocol and/or RFC uses IPsec/IKE. > > Questions for the list: > 1) Are there any other topics that should be discussed? the one above, i.e. where should MIPv6 IPsec/IKE roadmap/work be handled ;-) Cheers, a+ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0012_01C935CE.7B08A8F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyNDA5NDg1MFowIwYJKoZIhvcNAQkEMRYEFMikrgKTRNng b8yjGEZpv2U2p8klMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA d2MdbG+X6IDeBW8w7ttJ2JeqUAqvMYo+ZeuD5tpQUHhcbgRCRDFFCtjTGtWgDXZ5hcKOde/CtykL WN4XXDJ2TWFD89Scy1bs9BBfvrUhNoIhV58oNF8/mbgco3b34JWXEbSuAwvnHcoJ5JwKVBwhAn0Z Gid6Dizt8d3kzT6Q7kMFUND4zbFHDxbg1p5GbykEXK6WjV9N4j8C710FpQIGwk+xDTLSgCf9u9pj Rw7HSkJIDsp0tDW5+bAQR3zSIVJu/2+LVHSdLilsL7wem5Mm80mjpJ7xT5Xf+MsbxZkxVaJK4ZuN wRdv2C/VdRa1MTbLfpz4n1xUn6753ecSHYvWHQAAAAAAAA== ------=_NextPart_000_0012_01C935CE.7B08A8F0-- --===============0289001390== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0289001390==-- From ipsec-bounces@ietf.org Fri Oct 24 05:06:00 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C06E03A6AC8; Fri, 24 Oct 2008 05:06:00 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524133A6AC8 for ; Fri, 24 Oct 2008 05:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJh6Kk0hEVg6 for ; Fri, 24 Oct 2008 05:05:59 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id D02913A6ABC for ; Fri, 24 Oct 2008 05:05:44 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m9OC72Cp000180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Oct 2008 15:07:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m9OC71On006857; Fri, 24 Oct 2008 15:07:01 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18689.47717.272145.396442@fireball.kivinen.iki.fi> Date: Fri, 24 Oct 2008 15:07:01 +0300 From: Tero Kivinen To: In-Reply-To: <1696498986EFEC4D9153717DA325CB72020058D7@vaebe104.NOE.Nokia.com> References: <18648.62020.138458.908262@fireball.kivinen.iki.fi> <18650.7814.808443.474300@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201E72AFB@vaebe104.NOE.Nokia.com> <18676.37638.443520.835980@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201EEFF7D@vaebe104.NOE.Nokia.com> <18679.20905.763167.3524@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72020058D7@vaebe104.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 24 min X-Total-Time: 24 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > Tero Kivinen wrote: > > But this is exactly same situation we have with AES-GCM (IV = 8 bytes, > > block size is 16 bytes). Does that mean that we cannot use AES-GCM > > regardless that we have rfc5282 as RFC 4306 mandates the IV to be same > > as block length? > > > > I myself think that if the algorithm specific RFC (RFC 5282 for > > AES-GCM and RFC 3686 for AES-CTR) specifies some other IV processing > > rules those are used even when the RFC 4306 says that the iv length is > > equal the block length of the underlying encryption algorithm. > > Note that AES-GCM was already specified in RFC 4106; RFC 5282 updates > the necessary parts of RFC 4306 so that 4106 can actually be used. Yes, that was needed as RFC4306 defined specific format for the encrypted payload, including the integrity checksum data field which is not present when using combined mode ciphers, and most imporantly RFC 5282 also specified what is the contents of the AAD. Those are not defined in the RFC4306 so thats why we did need RFC5282. > We couldn't just use RFC 4106 without RFC 5282; for similar reasons, We could not use RFC4106 as it only specied how to use combined modes with ESPv3, and it did specify completely different things to put to the AAD for the IKEv2. RFC 4106 specified that AAD contains SPI and sequence number. RFC 5282 specifies that AAD contains IKEv2 header, unencrypted IKE payloads and the payload header of the encrypted payloads. The need for the RFC5282 was not because the combined modes use different IV lengths, and it was not really because they do not have the integrity checksum data field at all (we could consider combined mode ciphers to have ICV field length of 0). It was needed to specify how to construct AAD. AES-CTR does not have that problem, as it still uses the exactly same normal integrity algorithms that are used also for CBC modes. > we can't use RFC 3686 as-is, but need to slightly update RFC 4306 > text on this point (either in IKEv2bis or in a separate draft). On the other hand RFC3686 do specify everything that is needed for the IKEv2 so that the AES-CTR cipher can be used to protect IKEv2 SA. The only thing that is slightly inconsistent is that the RFC4306 tells how IV field is used for CBC modes, which is not exactly same that what is used for the AES-CTR. But on the other hand the RFC3686 do have the replacement text for that telling what is the lenght of the IV field and how it is constructed. It cannot say that this text is supposed to replace RFC4306 section 3.14 IV description as there was no need to make forward reference to the RFC4306 from that document, but the text in RFC3686 is written based on the IKEv2 drafts available at that time, and it was supposed to be enough to allow AES-CTR mode to be used in IKEv2. We seem to have missed text in RFC4306 to explain that the IV text is only for CBC modes, and for other ciphers use the text from the document specifying them, but the RFC3686 do have the text specifying things anyways. > If you're suggesting doing it in IKEv2bis (sounds like a reasonable > idea to me), please send text :) Here is the new version suggested replacement text: ---------------------------------------------------------------------- o Initialization Vector - For CBC mode ciphers the length of the initialization vector (IV) is equal to the block length of the underlying encryption algorithm. Senders MUST select a new unpredictable IV for every message; recipients MUST accept any value. The reader is encouraged to consult [MODES] for advice on IV generation. In particular, using the final ciphertext block of the previous message is not considered unpredictable. For other modes than CBC the IV format and processing is specified in the document specifying the encryption algorithm and mode. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 24 08:03:41 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB60E28C1A0; Fri, 24 Oct 2008 08:03:41 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CDBD3A69F7 for ; Fri, 24 Oct 2008 08:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxzCltz4KJTM for ; Fri, 24 Oct 2008 08:03:39 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by core3.amsl.com (Postfix) with ESMTP id 72CDC28C1AB for ; Fri, 24 Oct 2008 08:03:38 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so401196nfh.39 for ; Fri, 24 Oct 2008 08:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=cZ9UeeKCggZlb8Hyz3db//Cgqbzb1yp82FHjpvByfR4=; b=vgE+427S9Prt/oNB9XnLoDbKk1Ytw9f+tcvojKH/swX2nSSvuHcH4ffVFACR8ApGU9 WuV+izPzvhyaNzXlv9kVVO+mT7MPZL5AQXQ844zq9h+FB/H7ucJoEckkHbKy2S2uSKYf YQqzxCs3Hnof85qYZeD2wUH7SMsIhd3cubRCM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=q6KulhzD8ITHafGFqC7cHpRp65ZUNWMn6aG8im/xnygnZ4IvQ3iLX1FC6IRoBbZGTP On/4X/OJa7lTvNhajoj0OOkwT+KrjKJ3qpDei6MDYpU61qylY17XUXplIsR9aQkW8m2f YKP8leOoUyGVXd5823rDQ4hh3JSHLZTk2o2zM= Received: by 10.210.134.5 with SMTP id h5mr2465798ebd.85.1224860673557; Fri, 24 Oct 2008 08:04:33 -0700 (PDT) Received: by 10.210.109.14 with HTTP; Fri, 24 Oct 2008 08:04:33 -0700 (PDT) Message-ID: <1d38a3350810240804n5cd50234pff959381102503b2@mail.gmail.com> Date: Fri, 24 Oct 2008 23:04:33 +0800 From: "Hui Deng" To: "Yaron Sheffer" In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CCA70@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 References: <20081023111335.93181fsvzkllr3q7@webmail.nist.gov> <87skqnl1oo.fsf@natisbad.org> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CCA70@il-ex01.ad.checkpoint.com> Cc: "IPsec@ietf.org" , Sheila Frankel , IETF MEXT WG ML Subject: Re: [IPsec] Roadmap doc X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0148127524==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0148127524== Content-Type: multipart/alternative; boundary="----=_Part_9373_6680290.1224860673543" ------=_Part_9373_6680290.1224860673543 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, all We also have wrote this draft http://tools.ietf.org/id/draft-qi-mip6-ikev2-interfacing-02.txt and present in mip6 working group before several time. and won the support from the floor, but no in the top priority list of the current mext WG. Regards, -Hui 2008/10/24 Yaron Sheffer > Hi Sheila, Arnaud, > > First, I am happy with the outline as presented here, including the 24XX > documents. If anything, it may be too ambitious (i.e. lengthy). > > Regarding the interactions of MIP6 with IKE/IPsec: > > - The Roadmap document should cover these areas, just as it covers other > consumers of this technology. But despite its (unfortunate) name, I don't > see the document as a future-looking position statement of the WG, but > rather as documentation of completed work. > > - As for the actual work on MIP6/IPsec dependencies: the ipsecme WG is busy > today with documents that have far wider applicability to the IPsec > community. _If_ there is strong interest in these issues from a specific > community of people, perhaps the way to go about it is with a dedicated > design team. > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Arnaud Ebalard > Sent: Thursday, October 23, 2008 18:24 > To: Sheila Frankel > Cc: IPsec@ietf.org; IETF MEXT WG ML > Subject: Re: [IPsec] Roadmap doc > > Hi, [mext added in CC] > > "Sheila Frankel" writes: > > > 7. Outgrowths of IPsec/IKE > > 7.1. IPComp (Compression) > > 7.2. IKEv2 Mobility and Multihoming (MobIKE) > > 7.3. Better-than-Nothing Security (Btns) > > 7.4. Kerberized Internet Negotiation of Keys (Kink) > > 7.5. IPsec Secure Remote Access (IPSRA) > > 7.6. IPsec Keying Information Resource Record (IPsecKEY) > > 8. Other Protocols that use IPsec/IKE > > 8.1. Mobile IP (MIPv4 and MIPv6) > > IMHO, MIPv6 is user of IPsec/IKE but not a common user: it uses > IPsec/IKE for its protection but it also has some very tight > interactions with IKE/IPsec/[PF_KEY] and for that reason, specific > requirements: > > - configuration via IKEv2 (various RFC) > - bootstrapping and efficient handling of movement in IPsec/IKE context > (see draft draft-ebalard-mext-pfkey-enhanced-migrate-00 which is a > follow-up of draft-sugimoto-mip6-pfkey-migrate-04) > > The problem is that this last item sits in the middle of the field with > IPsec WG on one side and MIPv6 on the other; each side considering that > it should be handled by the other. > > At the moment, MIPv6 specification documents (3775, 3776, 4877, 5026, > ...) have expectations on the behavior in IPsec/IKE environments but > IPsec/IKE (and possibly PF_KEY) are missing the interfaces to support > those requirements. This is currently making progress outside any > working group. > > In the end, I am wondering where this item stand w.r.t the roadmap > document. I know that it is not in the initial set of work items of the > WG but this does not prevent clarifying the position of the WG on it in > the doc, does it? > > > 8.2. Open Shortest Path First (OSPF) > > 8.3. Host Identity Protocol (HIP) > > 8.4. Extensible Authentication Protocol (EAP) Method Update (EMU) 10 > > 8.5. Stream Control Transmission Protocol (SCTP) > > 8.6. Fibre Channel > > 9. Security Considerations > > 10. IANA Considerations > > 11. References > > 11.1. Normative References > > 11.2. Informative References > > > > Sections 1 and 2 will contain introductory material about IPsec and > > IKE: their functions, placement in the stack, inter-relationships, > > etc. > > > > The rest of the doc will basically be a list of RFCs, with a brief > > description of each. For the cryptographic algorithms, each section > > will describe where each type of algorithm is used within IPsec and/or > > IKE. For each algorithm, the following information will be included: > > whether it applies to IPsec, IKE, or both; requirement level (MUST > > etc.); special considerations (e.g. cannot be used with manual > > keying); how widely/commonly it is deployed. Section 8 (other > > protocols that use IPsec/IKE) will very briefly mention the context in > > which each protocol and/or RFC uses IPsec/IKE. > > > > Questions for the list: > > 1) Are there any other topics that should be discussed? > > the one above, i.e. where should MIPv6 IPsec/IKE roadmap/work be > handled ;-) > > Cheers, > > a+ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > ------=_Part_9373_6680290.1224860673543 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
    Hello, all
     
    and present in mip6 working group before several time.
    and won the support from the floor, but no in the top priority list of the current mext WG.
     
    Regards,
     
    -Hui

    2008/10/24 Yaron Sheffer <yaronf@checkpoint.com>
    Hi Sheila, Arnaud,

    First, I am happy with the outline as presented here, including the 24XX
    documents. If anything, it may be too ambitious (i.e. lengthy).

    Regarding the interactions of MIP6 with IKE/IPsec:

    - The Roadmap document should cover these areas, just as it covers other
    consumers of this technology. But despite its (unfortunate) name, I don't
    see the document as a future-looking position statement of the WG, but
    rather as documentation of completed work.

    - As for the actual work on MIP6/IPsec dependencies: the ipsecme WG is busy
    today with documents that have far wider applicability to the IPsec
    community. _If_ there is strong interest in these issues from a specific
    community of people, perhaps the way to go about it is with a dedicated
    design team.

    Thanks,
           Yaron

    -----Original Message-----
    From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of
    Arnaud Ebalard
    Sent: Thursday, October 23, 2008 18:24
    To: Sheila Frankel
    Cc: IPsec@ietf.org; IETF MEXT WG ML
    Subject: Re: [IPsec] Roadmap doc

    Hi,                                                [mext added in CC]

    "Sheila Frankel" <sheila.frankel@nist.gov> writes:

    > 7.  Outgrowths of IPsec/IKE
    >    7.1.  IPComp (Compression)
    >    7.2.  IKEv2 Mobility and Multihoming (MobIKE)
    >    7.3.  Better-than-Nothing Security (Btns)
    >    7.4.  Kerberized Internet Negotiation of Keys (Kink)
    >    7.5.  IPsec Secure Remote Access (IPSRA)
    >    7.6.  IPsec Keying Information Resource Record (IPsecKEY)
    > 8.  Other Protocols that use IPsec/IKE
    >    8.1.  Mobile IP (MIPv4 and MIPv6)

    IMHO, MIPv6 is user of IPsec/IKE but not a common user: it uses
    IPsec/IKE for its protection but it also has some very tight
    interactions with IKE/IPsec/[PF_KEY] and for that reason, specific
    requirements:

    - configuration via IKEv2 (various RFC)
    - bootstrapping and efficient handling of movement in IPsec/IKE context
     (see draft draft-ebalard-mext-pfkey-enhanced-migrate-00 which is a
     follow-up of draft-sugimoto-mip6-pfkey-migrate-04)

    The problem is that this last item sits in the middle of the field with
    IPsec WG on one side and MIPv6 on the other; each side considering that
    it should be handled by the other.

    At the moment, MIPv6 specification documents (3775, 3776, 4877, 5026,
    ...) have expectations on the behavior in IPsec/IKE environments but
    IPsec/IKE (and possibly PF_KEY) are missing the interfaces to support
    those requirements. This is currently making progress outside any
    working group.

    In the end, I am wondering where this item stand w.r.t the roadmap
    document. I know that it is not in the initial set of work items of the
    WG but this does not prevent clarifying the position of the WG on it in
    the doc, does it?

    >    8.2.  Open Shortest Path First (OSPF)
    >    8.3.  Host Identity Protocol (HIP)
    >    8.4.  Extensible Authentication Protocol (EAP) Method Update (EMU) 10
    >    8.5.  Stream Control Transmission Protocol (SCTP)
    >    8.6.  Fibre Channel
    > 9.  Security Considerations
    > 10.  IANA Considerations
    > 11. References
    >    11.1. Normative References
    >    11.2. Informative References
    >
    > Sections 1 and 2 will contain introductory material about IPsec and
    > IKE: their functions, placement in the stack, inter-relationships,
    > etc.
    >
    > The rest of the doc will basically be a list of RFCs, with a brief
    > description of each. For the cryptographic algorithms, each section
    > will describe where each type of algorithm is used within IPsec and/or
    > IKE. For each algorithm, the following information will be included:
    > whether it applies to IPsec, IKE, or both; requirement level (MUST
    > etc.); special considerations (e.g. cannot be used with manual
    > keying); how widely/commonly it is deployed. Section 8 (other
    > protocols that use IPsec/IKE) will very briefly mention the context in
    > which each protocol and/or RFC uses IPsec/IKE.
    >
    > Questions for the list:
    > 1) Are there any other topics that should be discussed?

    the one above, i.e. where should MIPv6 IPsec/IKE roadmap/work be
    handled ;-)

    Cheers,

    a+

    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org/mailman/listinfo/ipsec

    Scanned by Check Point Total Security Gateway.

    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org/mailman/listinfo/ipsec


    ------=_Part_9373_6680290.1224860673543-- --===============0148127524== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0148127524==-- From ipsec-bounces@ietf.org Fri Oct 24 08:28:29 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5FCE28C1EC; Fri, 24 Oct 2008 08:28:29 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD31228C1E3 for ; Fri, 24 Oct 2008 08:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3HUzTY0-uvf for ; Fri, 24 Oct 2008 08:28:27 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 58E0528C133 for ; Fri, 24 Oct 2008 08:28:27 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so344202eyd.31 for ; Fri, 24 Oct 2008 08:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=cfi7LTBOpbQPI7a+eLR+tsv3EFi+7grVv8AAo25GEzA=; b=nSC9zsAb0BoMRcIgjn89LlJEWqcxZarnhb0CLaarE/rKHlyM7PDhEOCXtyP6HMs7ZR XZM/nWiWtgVDwyt0n+LTB2sWlna3izhAMS7kKE3PqX1kqi15GjoFO9lmgxV0er9hXzCL WvltwECYevjdd9X1OmJiCl/H4HrJaEd6c+f2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=wbS51w/lH5QtVpbWGcZCR+zoXasEYyuVihhHnEG8+DbQqUWKcg4p6InNfF8D2NvjCM OmEu2ppXU4wRawkJAGLGXXmQbKskn+oh6A6iUb6pPd2fNoHBbp1K8z9Upb1zacQANtwW hHXyRr5/0QzP4TkwUQ5UAlq3Ms1j3538x1/XU= Received: by 10.210.34.2 with SMTP id h2mr2501230ebh.82.1224862187527; Fri, 24 Oct 2008 08:29:47 -0700 (PDT) Received: by 10.210.109.14 with HTTP; Fri, 24 Oct 2008 08:29:47 -0700 (PDT) Message-ID: <1d38a3350810240829i4a518dccg4b5a4fdb7378d4bf@mail.gmail.com> Date: Fri, 24 Oct 2008 23:29:47 +0800 From: "Hui Deng" To: "Paul Hoffman" In-Reply-To: <1696498986EFEC4D9153717DA325CB720200591A@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 References: <48EB97DD.2040305@qualcomm.com> <4c5c7a6d0810070617q7816d710q2e96080a47057572@mail.gmail.com> <1696498986EFEC4D9153717DA325CB720200591A@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0672757404==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0672757404== Content-Type: multipart/alternative; boundary="----=_Part_9709_12469986.1224862187509" ------=_Part_9709_12469986.1224862187509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, all I guess most Guru here only had a quick look other than detail technology analogy. some also said that one is attractive, the other is not. other than detail analysis here. Based on my observation, it is quite clear that most technical comments favoriate draft-xu-ike-sa-sync, and sevearl critical issues have been raised for draft-tschofenig-ipsecme-ikev2-resumption. draft-xu-ike-sa-sync doesn't know what is RFC 2246 origianlly, we guess that the best solution is not based on who is more looks similar. One more comment is that draft-tschofenig-ipsecme-ikev2-resumption has removed failure over support, but name of draft and authors from failure over still there. Lastly speaking for our mobile operator, we are interested in draft-xu-ike-sa-sync, we don't want send so many SAs information to the terminal, and in the case of huge number of mobile subscriber experience, the air interface consumption is also quite criticial. and I have no idea that is there any other scale operator interesting in draft-tschofenig-ipsecme-ikev2-resumption and really consider to deploy it. Many thanks -Hui > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > On Behalf Of ext Paul Hoffman > > Sent: 07 October, 2008 20:43 > > To: ipsec@ietf.org > > Subject: [IPsec] Resuming the session resumption discussion > > > > > > > > We now have revised drafts from the two parties who has > > published earlier drafts on session resumption. The > > (truncated) announcements are below. > > > > The WG should start discussing what we want from session > > resumption and which of these two drafts (or what ideas from > > each of these two drafts) is of interest to the WG. As a > > reminder, I start off with what our charter says. > > > > Extra points are awarded for not copying this entire message > > in your response. :-) > > > > --Paul Hoffman > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ------=_Part_9709_12469986.1224862187509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
    Hello, all
     
    I guess most Guru here only had a quick look other than detail technology analogy.
    some also said that one is attractive, the other is not. other than detail analysis here.
     
    Based on my observation, it is quite clear that most technical comments favoriate draft-xu-ike-sa-sync, and sevearl critical issues have been raised for draft-tschofenig-ipsecme-ikev2-resumption.
     
    draft-xu-ike-sa-sync doesn't know what is RFC 2246 origianlly, we guess that the best solution is not based on who is more looks similar.
     
    One more comment is that draft-tschofenig-ipsecme-ikev2-resumption has removed failure over support, but name of draft and authors from failure over still there.
     
    Lastly speaking for our mobile operator, we are interested in draft-xu-ike-sa-sync, we don't want send so many SAs information to the terminal, and in the case of huge number of mobile subscriber experience, the air interface consumption is also quite criticial.  
    and I have no idea that is there any other scale operator interesting in draft-tschofenig-ipsecme-ikev2-resumption and really consider to deploy it.
     
    Many thanks
     
    -Hui
    > -----Original Message-----
    > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]
    > On Behalf Of ext Paul Hoffman
    > Sent: 07 October, 2008 20:43
    > To: ipsec@ietf.org
    > Subject: [IPsec] Resuming the session resumption discussion
    >
    > <co-chair hat on>
    >
    > We now have revised drafts from the two parties who has
    > published earlier drafts on session resumption. The
    > (truncated) announcements are below.
    >
    > The WG should start discussing what we want from session
    > resumption and which of these two drafts (or what ideas from
    > each of these two drafts) is of interest to the WG. As a
    > reminder, I start off with what our charter says.
    >
    > Extra points are awarded for not copying this entire message
    > in your response. :-)
    >
    > --Paul Hoffman
    <snip>
    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org/mailman/listinfo/ipsec

    ------=_Part_9709_12469986.1224862187509-- --===============0672757404== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0672757404==-- From ipsec-bounces@ietf.org Sat Oct 25 06:59:04 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C59CB3A69FE; Sat, 25 Oct 2008 06:59:04 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D933A69FE for ; Sat, 25 Oct 2008 06:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlZFh6TpA7Nu for ; Sat, 25 Oct 2008 06:59:01 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1D0A23A68A4 for ; Sat, 25 Oct 2008 06:59:01 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B38AF294005; Sat, 25 Oct 2008 16:00:24 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5CB6B294003; Sat, 25 Oct 2008 15:59:25 +0200 (IST) Received: from [172.31.24.21] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9PDxJQC018909; Sat, 25 Oct 2008 15:59:24 +0200 (IST) Message-Id: <627607BB-8934-4AC9-A1C3-0E3680D952EA@checkpoint.com> From: Yoav Nir To: Hui Deng In-Reply-To: <1d38a3350810240829i4a518dccg4b5a4fdb7378d4bf@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 25 Oct 2008 15:59:18 +0200 References: <48EB97DD.2040305@qualcomm.com> <4c5c7a6d0810070617q7816d710q2e96080a47057572@mail.gmail.com> <1696498986EFEC4D9153717DA325CB720200591A@vaebe104.NOE.Nokia.com> <1d38a3350810240829i4a518dccg4b5a4fdb7378d4bf@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org, Paul Hoffman Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0749504071==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0749504071== Content-Type: multipart/alternative; boundary=Apple-Mail-1--324660637 --Apple-Mail-1--324660637 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello Hui This is strange, because that is not the impression I got from the discussion here. There were basically two issues raised about draft-tschofenig. One was that pushing state to the handset was less secure that storing it on your own server farm. I don't think the case for that was made. The other issue was that it adds content to a message that is already bloated, which may lead to fragmentation, which may lead to dropped connections in environments with either high packet loss or defective middleboxes. That, however, is an inherent problem of IKE, that may appear even without session resumption because of certificates and/or large traffic selectors and CFG payloads. Draft-xu, on the other hand, requires new infrastructure (the stub bank) which was not required in IKE before that. I would be hesitant to add such a requirement. Adding a synchronization box may be acceptable to a mobile operator with a huge number of mobile subscribers, but it's not acceptable to an small- or medium-sized enterprise trying to run a remote access VPN. What's more, I don't see why such an infrastructure cannot be used for synchronizing the entire IKE SA rather than a stub. That would make failover even easier, and potentially transparent to the handset (and then there's no need for any new standard at all). That synchronization is fairly easy when the failover servers and the stub bank are just a rack away in the server room. It gets considerably harder when you want to have the different servers in different geographical locations, and maybe have two geographically-separated stub banks. That infrastructure, along with the communication channels between all those servers, becomes terribly expensive, whereas storing each clients ticket on the client costs just a little memory on each handset. I do not work in the mobile operator space, but it seems to me, that data traffic (whether voice, video or plain data) would far dominate signaling, and that signaling would far dominate IKE, so that adding 0.5K-1K to IKE (that's just my estimate of the ticket size) should be negligible, so IMO draft-tschofenig wins. Yoav On Oct 24, 2008, at 5:29 PM, Hui Deng wrote: > Hello, all > > I guess most Guru here only had a quick look other than detail > technology analogy. > some also said that one is attractive, the other is not. other than > detail analysis here. > > Based on my observation, it is quite clear that most technical > comments favoriate draft-xu-ike-sa-sync, and sevearl critical issues > have been raised for draft-tschofenig-ipsecme-ikev2-resumption. > > draft-xu-ike-sa-sync doesn't know what is RFC 2246 origianlly, we > guess that the best solution is not based on who is more looks > similar. > > One more comment is that draft-tschofenig-ipsecme-ikev2-resumption > has removed failure over support, but name of draft and authors from > failure over still there. > > Lastly speaking for our mobile operator, we are interested in draft- > xu-ike-sa-sync, we don't want send so many SAs information to the > terminal, and in the case of huge number of mobile subscriber > experience, the air interface consumption is also quite criticial. > and I have no idea that is there any other scale operator > interesting in draft-tschofenig-ipsecme-ikev2-resumption and really > consider to deploy it. > > Many thanks > > -Hui > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > > On Behalf Of ext Paul Hoffman > > Sent: 07 October, 2008 20:43 > > To: ipsec@ietf.org > > Subject: [IPsec] Resuming the session resumption discussion > > > > > > > > We now have revised drafts from the two parties who has > > published earlier drafts on session resumption. The > > (truncated) announcements are below. > > > > The WG should start discussing what we want from session > > resumption and which of these two drafts (or what ideas from > > each of these two drafts) is of interest to the WG. As a > > reminder, I start off with what our charter says. > > > > Extra points are awarded for not copying this entire message > > in your response. :-) > > > > --Paul Hoffman > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-1--324660637 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello = Hui

    This is strange, because that is not the = impression I got from the discussion = here.

    There were basically two issues raised = about draft-tschofenig. One was that pushing state to the handset was = less secure that storing it on your own server farm. I don't think the = case for that was made. The other issue was that it adds content to a = message that is already bloated, which may lead to fragmentation, which = may lead to dropped connections in environments with either high packet = loss or defective middleboxes. That, however, is an inherent problem of = IKE, that may appear even without session resumption because of = certificates and/or large traffic selectors and CFG = payloads.

    Draft-xu, on the other hand, requires = new infrastructure (the stub bank) which was not required in IKE before = that. I would be hesitant to add such a requirement. Adding a = synchronization box may be acceptable to a mobile operator with a huge = number of mobile subscribers, but it's not acceptable to an small- or = medium-sized enterprise trying to run a remote access VPN.  What's = more, I don't see why such an infrastructure cannot be used for = synchronizing the entire IKE SA rather than a stub. That would make = failover even easier, and potentially transparent to the handset (and = then there's no need for any new standard at all). That synchronization = is fairly easy when the failover servers and the stub bank are just a = rack away in the server room.  It gets considerably harder when you = want to have the different servers in different geographical locations, = and maybe have two geographically-separated stub banks.  That = infrastructure, along with the communication channels between all those = servers, becomes terribly expensive, whereas storing each clients ticket = on the client costs just a little memory on each = handset.

    I do not work in the mobile operator = space, but it seems to me, that data traffic (whether voice, video or = plain data) would far dominate signaling, and that signaling would = far dominate IKE, so that adding 0.5K-1K to IKE (that's just my estimate = of the ticket size) should be negligible, so IMO draft-tschofenig = wins.

    Yoav


    On Oct 24, 2008, at 5:29 PM, Hui Deng wrote:

    Hello, = all
     
    I guess most Guru here = only had a quick look other than detail technology analogy.
    =
    some also said that one is attractive, the other is not. other than = detail analysis here.
     
    Based on my = observation, it is quite clear that most technical comments favoriate = draft-xu-ike-sa-sync, and sevearl critical issues have been raised for = draft-tschofenig-ipsecme-ikev2-resumption.
     
    =
    draft-xu-ike-sa-sync doesn't know what is RFC 2246 = origianlly, we guess that the best solution is not based = on who is more looks similar.
     
    One more = comment is that draft-tschofenig-ipsecme-ikev2-resumption has removed = failure over support, but name of draft and authors from failure over = still there.
     
    Lastly speaking for our mobile = operator, we are interested in draft-xu-ike-sa-sync, we = don't want send so many SAs information to the terminal, = and in the case of huge number of mobile subscriber = experience, the air interface consumption is also quite = criticial.  
    and I have no idea that is = there any other scale operator interesting in = draft-tschofenig-ipsecme-ikev2-resumption and really consider to = deploy it.
     
    Many thanks
    =
     
    -Hui
    > -----Original Message-----
    > = From: ipsec-bounces@ietf.org= [mailto:ipsec-bounces@ietf.org]
    > On Behalf Of ext Paul Hoffman
    > = Sent: 07 October, 2008 20:43
    > To: ipsec@ietf.org
    > Subject: [IPsec] = Resuming the session resumption discussion
    >
    > <co-chair hat = on>
    >
    > We now have revised drafts from the two parties who = has
    > published earlier drafts on session resumption. The
    > = (truncated) announcements are below.
    >
    > The WG should start = discussing what we want from session
    > resumption and which of these = two drafts (or what ideas from
    > each of these two drafts) is of = interest to the WG. As a
    > reminder, I start off with what our = charter says.
    >
    > Extra points are awarded for not copying this = entire message
    > in your response. :-)
    >
    > --Paul = Hoffman
    <snip>
    _______________________________________________
    IPsec = mailing list
    IPsec@ietf.org
    https://www.ietf.org/mailman/listinfo/ipsec
    =

    = _______________________________________________
    IPsec mailing = list
    IPsec@ietf.org
    https://www.ietf.org/= mailman/listinfo/ipsec

    = --Apple-Mail-1--324660637-- --===============0749504071== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0749504071==-- From ipsec-bounces@ietf.org Sat Oct 25 08:33:10 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0251728C10A; Sat, 25 Oct 2008 08:33:10 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B9F28C10A for ; Sat, 25 Oct 2008 08:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZgUizlz93WZ for ; Sat, 25 Oct 2008 08:33:07 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id B3CBB3A6917 for ; Sat, 25 Oct 2008 08:33:06 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so609161eyd.31 for ; Sat, 25 Oct 2008 08:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=34KWx8QR7WfywWw3RDz95eSuzo1aSa+KqD04SRRnPEg=; b=EGsU8tA1Su8CZUlO+NbGIHPGxZkWzXB9c5P0pfiCmMWQnNpVPNtTuWeueNZdqPMt7X Lm1dtNtNP6RnKNpyfxhaBQj/Lrrsi4sTX4PX9OEsf12IXhmvWfo+R+khW3Y4wknmfnjD zzKmq1fPa7kjfnik+h62JapiQP/0t3Yad9uTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=pnOPLPCgWbEN6liv0PGoJwmtb2cbfnWX+rYqa69LhmdwejNORTNkxo7T8zO601ar68 FzRV9N1Nyk7zY8Bvj1WcpErxSyzM3KiTwxNDbMDqB4sZtVR4uEyFM4b4aasL3seTKC1D dGQvO7SxqO2/jKdbo+t6z1+bCoA+kXxYgjR9g= Received: by 10.210.105.20 with SMTP id d20mr3956121ebc.78.1224948869968; Sat, 25 Oct 2008 08:34:29 -0700 (PDT) Received: by 10.210.109.14 with HTTP; Sat, 25 Oct 2008 08:34:29 -0700 (PDT) Message-ID: <1d38a3350810250834uf4286cdhc3e5a7cd258c080e@mail.gmail.com> Date: Sat, 25 Oct 2008 23:34:29 +0800 From: "Hui Deng" To: "Yoav Nir" In-Reply-To: <627607BB-8934-4AC9-A1C3-0E3680D952EA@checkpoint.com> MIME-Version: 1.0 References: <48EB97DD.2040305@qualcomm.com> <4c5c7a6d0810070617q7816d710q2e96080a47057572@mail.gmail.com> <1696498986EFEC4D9153717DA325CB720200591A@vaebe104.NOE.Nokia.com> <1d38a3350810240829i4a518dccg4b5a4fdb7378d4bf@mail.gmail.com> <627607BB-8934-4AC9-A1C3-0E3680D952EA@checkpoint.com> Cc: ipsec@ietf.org, Paul Hoffman Subject: Re: [IPsec] Resuming the session resumption discussion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1433731722==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1433731722== Content-Type: multipart/alternative; boundary="----=_Part_8650_7089314.1224948869936" ------=_Part_8650_7089314.1224948869936 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, Yoav, Thanks for the discussion, reply inline. 2008/10/25 Yoav Nir > Hello Hui > This is strange, because that is not the impression I got from the > discussion here. > ==> Fine. > There were basically two issues raised about draft-tschofenig. One was > that pushing state to the handset was less secure that storing it on your > own server farm. I don't think the case for that was made. > ==> Replicated sim card has been a critical issue for mobile communication, this is the existed case that we can't igmore them. > The other issue was that it adds content to a message that is already > bloated, which may lead to fragmentation, which may lead to dropped > connections in environments with either high packet loss or defective > middleboxes. That, however, is an inherent problem of IKE, that may appear > even without session resumption because of certificates and/or large traffic > selectors and CFG payloads. > ==> Other cases listed here are not quite usual case, here we are discussing the usual scenario. That need special configuration, and this configuration may not always correct. > Draft-xu, on the other hand, requires new infrastructure (the stub bank) > which was not required in IKE before that. I would be hesitant to add such a > requirement. Adding a synchronization box may be acceptable to a mobile > operator with a huge number of mobile subscribers, but it's not acceptable > to an small- or medium-sized enterprise trying to run a remote access VPN. > ==> If it is small or medium sized enterprise, I guess cluster based server could work for them > What's more, I don't see why such an infrastructure cannot be used for > synchronizing the entire IKE SA rather than a stub. That would make failover > even easier, and potentially transparent to the handset (and then there's no > need for any new standard at all). > ==> but it cann't handle the geographically seperated solution, that will change the server IP address. > That synchronization is fairly easy when the failover servers and the > stub bank are just a rack away in the server room. It gets considerably > harder when you want to have the different servers in different geographical > locations, and maybe have two geographically-separated stub banks. That > infrastructure, along with the communication channels between all those > servers, becomes terribly expensive, whereas storing each clients ticket on > the client costs just a little memory on each handset. > that infrastrucutre is cost deservable. and not that much. but leave too many things to mobile make lots of technical potential issue, it also need cost additional expenditure to guarantee several issues. > I do not work in the mobile operator space, but it seems to me, that data > traffic (whether voice, video or plain data) would far dominate signaling, > and that signaling would far dominate IKE, so that adding 0.5K-1K to IKE > (that's just my estimate of the ticket size) should be negligible, so IMO > draft-tschofenig wins. > to save air interface, Hokey has been targeting to save this, especially in the special APN case. IKE fragmention will lead to more signalings, it really air cost. thanks again. -Hui Yoav > > > On Oct 24, 2008, at 5:29 PM, Hui Deng wrote: > > Hello, all > > I guess most Guru here only had a quick look other than detail technology > analogy. > some also said that one is attractive, the other is not. other than > detail analysis here. > > Based on my observation, it is quite clear that most technical comments > favoriate draft-xu-ike-sa-sync, and sevearl critical issues have been raised > for draft-tschofenig-ipsecme-ikev2-resumption. > > draft-xu-ike-sa-sync doesn't know what is RFC 2246 origianlly, we guess > that the best solution is not based on who is more looks similar. > > One more comment is that draft-tschofenig-ipsecme-ikev2-resumption has > removed failure over support, but name of draft and authors from failure > over still there. > > Lastly speaking for our mobile operator, we are interested in > draft-xu-ike-sa-sync, we don't want send so many SAs information to the > terminal, and in the case of huge number of mobile subscriber experience, > the air interface consumption is also quite criticial. > and I have no idea that is there any other scale operator interesting in > draft-tschofenig-ipsecme-ikev2-resumption and really consider to deploy it. > > Many thanks > > -Hui > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > >> > On Behalf Of ext Paul Hoffman >> > Sent: 07 October, 2008 20:43 >> > To: ipsec@ietf.org >> > Subject: [IPsec] Resuming the session resumption discussion >> > >> > >> > >> > We now have revised drafts from the two parties who has >> > published earlier drafts on session resumption. The >> > (truncated) announcements are below. >> > >> > The WG should start discussing what we want from session >> > resumption and which of these two drafts (or what ideas from >> > each of these two drafts) is of interest to the WG. As a >> > reminder, I start off with what our charter says. >> > >> > Extra points are awarded for not copying this entire message >> > in your response. :-) >> > >> > --Paul Hoffman >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > ------=_Part_8650_7089314.1224948869936 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
    Hello, Yoav,
     
    Thanks for the discussion, reply inline.
    2008/10/25 Yoav Nir <ynir@checkpoint.com>
    Hello Hui

    This is strange, because that is not the impression I got from the discussion here.
    ==> Fine.

     
    There were basically two issues raised about draft-tschofenig. One was that pushing state to the handset was less secure that storing it on your own server farm. I don't think the case for that was made.
    ==> Replicated sim card has been a critical issue for mobile communication, this is the existed case that we can't igmore them.
     
    The other issue was that it adds content to a message that is already bloated, which may lead to fragmentation, which may lead to dropped connections in environments with either high packet loss or defective middleboxes. That, however, is an inherent problem of IKE, that may appear even without session resumption because of certificates and/or large traffic selectors and CFG payloads.
    ==> Other cases listed here are not quite usual case, here we are discussing the usual scenario. That need special configuration, and this configuration may not always correct.
     
    Draft-xu, on the other hand, requires new infrastructure (the stub bank) which was not required in IKE before that. I would be hesitant to add such a requirement. Adding a synchronization box may be acceptable to a mobile operator with a huge number of mobile subscribers, but it's not acceptable to an small- or medium-sized enterprise trying to run a remote access VPN.  
    ==> If it is small or medium sized enterprise, I guess cluster based server could work for them
     
    What's more, I don't see why such an infrastructure cannot be used for synchronizing the entire IKE SA rather than a stub. That would make failover even easier, and potentially transparent to the handset (and then there's no need for any new standard at all).
    ==> but it cann't handle the geographically seperated solution, that will change the server IP address.
     
    That synchronization is fairly easy when the failover servers and the stub bank are just a rack away in the server room.  It gets considerably harder when you want to have the different servers in different geographical locations, and maybe have two geographically-separated stub banks.  That infrastructure, along with the communication channels between all those servers, becomes terribly expensive, whereas storing each clients ticket on the client costs just a little memory on each handset.
    that infrastrucutre is cost deservable. and not that much.
    but leave too many things to mobile make lots of technical potential issue, it also need cost additional expenditure to guarantee several issues.
     
    I do not work in the mobile operator space, but it seems to me, that data traffic (whether voice, video or plain data) would far dominate signaling, and that signaling would far dominate IKE, so that adding 0.5K-1K to IKE (that's just my estimate of the ticket size) should be negligible, so IMO draft-tschofenig wins.
    to save air interface, Hokey has been targeting to save this, especially in the special APN case. IKE fragmention will lead to more signalings, it really air cost.
     
    thanks again.
     
    -Hui

    Yoav


    On Oct 24, 2008, at 5:29 PM, Hui Deng wrote:

    Hello, all
     
    I guess most Guru here only had a quick look other than detail technology analogy.
    some also said that one is attractive, the other is not. other than detail analysis here.
     
    Based on my observation, it is quite clear that most technical comments favoriate draft-xu-ike-sa-sync, and sevearl critical issues have been raised for draft-tschofenig-ipsecme-ikev2-resumption.
     
    draft-xu-ike-sa-sync doesn't know what is RFC 2246 origianlly, we guess that the best solution is not based on who is more looks similar.
     
    One more comment is that draft-tschofenig-ipsecme-ikev2-resumption has removed failure over support, but name of draft and authors from failure over still there.
     
    Lastly speaking for our mobile operator, we are interested in draft-xu-ike-sa-sync, we don't want send so many SAs information to the terminal, and in the case of huge number of mobile subscriber experience, the air interface consumption is also quite criticial.  
    and I have no idea that is there any other scale operator interesting in draft-tschofenig-ipsecme-ikev2-resumption and really consider to deploy it.
     
    Many thanks
     
    -Hui
    > -----Original Message-----
    > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]
    > On Behalf Of ext Paul Hoffman
    > Sent: 07 October, 2008 20:43
    > To: ipsec@ietf.org
    > Subject: [IPsec] Resuming the session resumption discussion
    >
    > <co-chair hat on>
    >
    > We now have revised drafts from the two parties who has
    > published earlier drafts on session resumption. The
    > (truncated) announcements are below.
    >
    > The WG should start discussing what we want from session
    > resumption and which of these two drafts (or what ideas from
    > each of these two drafts) is of interest to the WG. As a
    > reminder, I start off with what our charter says.
    >
    > Extra points are awarded for not copying this entire message
    > in your response. :-)
    >
    > --Paul Hoffman
    <snip>
    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org/mailman/listinfo/ipsec

    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org/mailman/listinfo/ipsec


    ------=_Part_8650_7089314.1224948869936-- --===============1433731722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1433731722==-- From ipsec-bounces@ietf.org Mon Oct 27 05:20:59 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4B5C3A69D6; Mon, 27 Oct 2008 05:20:59 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0433A69D6 for ; Mon, 27 Oct 2008 05:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWPjPeUmpeGO for ; Mon, 27 Oct 2008 05:20:57 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 186853A6933 for ; Mon, 27 Oct 2008 05:20:56 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9RCKXWm002503; Mon, 27 Oct 2008 14:20:54 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 14:20:02 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Oct 2008 14:20:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 27 Oct 2008 14:20:06 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB72020538DA@vaebe104.NOE.Nokia.com> In-Reply-To: <18689.47717.272145.396442@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA Thread-Index: Ack10SXeDMYS8FW9SxCnIyGmqM/K8QCXQAiQ References: <18648.62020.138458.908262@fireball.kivinen.iki.fi><18650.7814.808443.474300@fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB7201E72AFB@vaebe104.NOE.Nokia.com><18676.37638.443520.835980@fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB7201EEFF7D@vaebe104.NOE.Nokia.com><18679.20905.763167.3524@fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB72020058D7@vaebe104.NOE.Nokia.com> <18689.47717.272145.396442@fireball.kivinen.iki.fi> From: To: X-OriginalArrivalTime: 27 Oct 2008 12:20:01.0869 (UTC) FILETIME=[55F747D0:01C9382E] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > Here is the new version suggested replacement text: > ---------------------------------------------------------------------- > o Initialization Vector - For CBC mode ciphers the length of the > initialization vector (IV) is equal to the block length of the > underlying encryption algorithm. Senders MUST select a new > unpredictable IV for every message; recipients MUST accept any > value. The reader is encouraged to consult [MODES] for advice on > IV generation. In particular, using the final ciphertext block > of the previous message is not considered unpredictable. For > other modes than CBC the IV format and processing is specified > in the document specifying the encryption algorithm and mode. Looks good to me! (We also need to update couple sentences earlier in ikev2bis, Section 3.14, to match this, though.) Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 27 06:25:30 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36A728C0E4; Mon, 27 Oct 2008 06:25:30 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD6C228C0E4 for ; Mon, 27 Oct 2008 06:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfd5l59oFgqy for ; Mon, 27 Oct 2008 06:25:27 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 2F0323A6AD3 for ; Mon, 27 Oct 2008 06:25:27 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so532172ywj.49 for ; Mon, 27 Oct 2008 06:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=XRo029WRA5xQpMAYs8zuGLl4yb9x6pqWRVkxlawVVKU=; b=I8ZW7R//EF9CBrXiXOkwzSqvbvL3NlUR4ATREnCNs20HMt1JNbl5kR7gd62lpU8+FE Q0afCAG3U11vlSDt1zrF+yr9pGIFDkDR3kYOtu1M3SV8ccZit2TUhmdoSeMm2Oug8vQ9 MlSObIsfXBw2+LVTrNeRfnAuORZPPT5msWS0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:references; b=acWNoc4Az5vnERQKS5zI/+h6Bjim5gkrya+kybARDyI7+lESpXZia+CntgfdbOwj9Z H3/BJH6/6keSGvltZPWICS0wxEfXwtbNwQGDYk/intYSWAWh6/xeMkA/5qVc7vwlqHcJ 4v+BytPSW+p2LX0LBrGs/G9P1GPHiMKNfcRIU= Received: by 10.90.67.10 with SMTP id p10mr4677537aga.51.1225113925199; Mon, 27 Oct 2008 06:25:25 -0700 (PDT) Received: by 10.90.66.4 with HTTP; Mon, 27 Oct 2008 06:25:25 -0700 (PDT) Message-ID: <850df0c40810270625q30fdf08cja2a04b967aaccb32@mail.gmail.com> Date: Mon, 27 Oct 2008 14:25:25 +0100 From: "balaji raghavan" To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB7201EEFF87@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <18648.62996.136882.689426@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201E72B2A@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB7201EEFF87@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, dharkins@lounge.org Subject: Re: [IPsec] Issue #32 Demoted SHOULD: EAP Identity Request X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balaji.raghavan.t@gmail.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Pasi, Although we have answered the question of how to communicate the EAP identity back to the IKEv2 responder , there is one question that hasn't been addressed. As Tero pointed out earlier, there is no way to match identities used in EAP to those used in IKEv2 ID payloads( i.e if they are different). There should be some explicit configuration on the IKEv2 responder about the EAP & IKEv2 identities, to be able to be sure that the authenticated identity is used by IKEv2, for policy selection etc. I ran into this ambiguity in the MIPv6-IKEv2 specs too.. (RFC 4877) --------- 8. The Use of EAP Authentication --------- carried inside EAP, invisible to the home agent. While IKEv2 does not allow an EAP Identity Request/Response message exchange, EAP methods may exchange identities within themselves. In this case, the home agent MUST acquire the mobile node's identity from the corresponding AAA server. How the home agent acquires the mobile node's identity is out of scope for this document. ------------ I agree that no one(=> no WG) wants to get into the nitty-gritty of specifying how to communicate with all possible AAA servers due to scoping issues.. But no where it's clarified on what is to be done by the responder after it obtains the EAP identity from the AAA server. For PKI Authentication type the MIPv6 spec (RFC 4877) explicitly requires the identity within the IDi payload and identity in the certificate to match. In that particular case the requirement that the authenticated identity is used for policy lookup, access control etc is satisfied. Atleast the security considerations section should be updated with this info, as Tero pointed out earlier, as the authenticated identity cannot be used to govern policy lookups etc, if the responder is unable to "match" the EAP identity to the one indicated by IDi. -Best Regards Balaji On Thu, Oct 16, 2008 at 11:16 AM, wrote: > > Dan Harkins wrote: > > > What AAA attribute is supposed to be used by the AAA server to > > communicate this information back to the IKEv2 responder? > > > > And it's a little more complicated too. Not only is the EAP server > > often implemented in a separate AAA server, in some EAP methods that > > server won't even me the one doing the actual client authentication! > > In a tunneled EAP method like PEAP or TTLS the "inner method" may be > > done by yet another AAA server. > > Currently, there's no RFC or Internet-Draft that describes AAA > attributes for IKEv2 at all -- but e.g. RFC 4072, Section 2.8.1, > talks about using the User-Name AVP for similar purpose. > > Best regards, > Pasi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Oct 27 14:30:04 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09B943A6BFD; Mon, 27 Oct 2008 14:30:04 -0700 (PDT) X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0BFB33A6BEE; Mon, 27 Oct 2008 14:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081027213002.0BFB33A6BEE@core3.amsl.com> Date: Mon, 27 Oct 2008 14:30:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, G. Montenegro Filename : draft-ietf-ipsecme-traffic-visibility-00.txt Pages : 10 Date : 2008-10-22 This document describes an ESP encapsulation for IPsec, allowing intermediate devices to ascertain if ESP-NULL is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ipsecme-traffic-visibility-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-27142633.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Tue Oct 28 04:32:32 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0AB3A6990; Tue, 28 Oct 2008 04:32:32 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38E7B3A6990 for ; Tue, 28 Oct 2008 04:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0K529i7WLh0z for ; Tue, 28 Oct 2008 04:32:29 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id BF7053A6983 for ; Tue, 28 Oct 2008 04:32:28 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4ADC9294005; Tue, 28 Oct 2008 13:32:26 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 46FC7294003 for ; Tue, 28 Oct 2008 13:32:25 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m9SBWNQC006648 for ; Tue, 28 Oct 2008 13:32:24 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 28 Oct 2008 13:32:23 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 28 Oct 2008 13:32:21 +0200 Thread-Topic: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt Thread-Index: Ack4e2kgPzoDMcYCSWuYQdXze5t6dwAc6GWQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CCDB0@il-ex01.ad.checkpoint.com> References: <20081027213002.0BFB33A6BEE@core3.amsl.com> In-Reply-To: <20081027213002.0BFB33A6BEE@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1870892093==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1870892093== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0088_01C93901.9B0E0E70" ------=_NextPart_000_0088_01C93901.9B0E0E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ken, Gabriel, thanks for posting this draft. I'd like to reopen the discussion about the "integrity only" bit, which disappeared since the previous version of this draft. Having this bit in the header means that Wrapped ESP (WESP) can encode both authenticated-only and authenticated-and-encrypted ESP. I see some benefits to allowing this option, and frankly, I don't see the drawbacks. - The main thing is extensibility. Existing ESP does not have any (which is why we're going through this exercise). WESP has at least a few unencrypted reserved bits which we can utilize for future needs. - Also, having the exact same semantics for WESP as for ESP might simplify code, test vectors etc. But complexity arguments are always weak :-) Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 27, 2008 23:30 To: i-d-announce@ietf.org Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, G. Montenegro Filename : draft-ietf-ipsecme-traffic-visibility-00.txt Pages : 10 Date : 2008-10-22 This document describes an ESP encapsulation for IPsec, allowing intermediate devices to ascertain if ESP-NULL is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-00 .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------=_NextPart_000_0088_01C93901.9B0E0E70 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTAyODExMzIyMVowIwYJKoZIhvcNAQkEMRYEFPd+e4LkZunz Ao4ATMBoqX2sBjgzMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA FAohNAtS9+K3O/7mmTWuK8v6hmSf1dNxS8UXbXVJpfL69Ic1SRj4TAz6GpFU90OTAjI0e1M1wx/i Y8q6zoK0PT8nJhDpU9Dd/thozGgbfMMWkgd+Nnwj2FXuiK4XUQM4KmvFydZnkD/Id0ZUoREs1wE3 ck0KlocAtvH2vgXQt1NqFzC4njjdYFFvUe4pbEvyWfg3kGyT9t8NEzSASUYCAql+pR33j/1X4K4A bmoCbLNYoOggBDYhy6Hu+u5cGUCeHts/9M0C0Y1d+5Z/c7d70RqIVabz9NpHkW1Wm5n+zE0sNgLY JPzHHpmwGivAIEBriEeoZx5yz32s/vxzSBz4kAAAAAAAAA== ------=_NextPart_000_0088_01C93901.9B0E0E70-- --===============1870892093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1870892093==-- From ipsec-bounces@ietf.org Tue Oct 28 06:52:39 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FC3128C2A5; Tue, 28 Oct 2008 06:52:39 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11A228C292 for ; Tue, 28 Oct 2008 06:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sjm6zrR4sb3i for ; Tue, 28 Oct 2008 06:52:36 -0700 (PDT) Received: from mail-07.primus.ca (mail6.primus.ca [216.254.141.173]) by core3.amsl.com (Postfix) with ESMTP id C38C928C283 for ; Tue, 28 Oct 2008 06:52:36 -0700 (PDT) Received: from ottawa-hs-209-217-122-41.s-ip.magma.ca ([209.217.122.41] helo=[192.168.8.177]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1KuozP-0005hP-27 for ipsec@ietf.org; Tue, 28 Oct 2008 09:52:07 -0400 Message-ID: <4907190B.70803@ellipticsemi.com> Date: Tue, 28 Oct 2008 09:52:11 -0400 From: Michael Bowler Organization: Elliptic Semiconductor User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.14eol) Gecko/20080911 Red Hat/1.0.9-26.el4 SeaMonkey/1.0.9 MIME-Version: 1.0 CC: "ipsec@ietf.org" References: <20081027213002.0BFB33A6BEE@core3.amsl.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CCDB0@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A77CCDB0@il-ex01.ad.checkpoint.com> X-Authenticated: elp104 - ottawa-hs-209-217-122-41.s-ip.magma.ca ([192.168.8.177]) [209.217.122.41] Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mbowler@ellipticsemi.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A few comments questions... - An 8 octet header would be much more friendly with IPv6. - HdrLen and TrailerLen should have units defined. - Is there any security concern by providing TrailerLen in the clear? Normal ESP encrypts this value. - I do not see how this header is useful if there is no flag indicating that the payload is encrypted or not. Regards, Michael -- Michael Bowler mbowler@ellipticsemi.com Sr. IC Designer/Architect (613) 254-5456x107 Elliptic Semiconductor www.ellipticsemi.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Oct 29 00:56:15 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB0C3A6CDC; Wed, 29 Oct 2008 00:56:15 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3224F3A6CDC for ; Wed, 29 Oct 2008 00:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHQ2ojyAwIq8 for ; Wed, 29 Oct 2008 00:56:13 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.190]) by core3.amsl.com (Postfix) with ESMTP id 8A4DF3A6ACD for ; Wed, 29 Oct 2008 00:56:12 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so1220417nfh.39 for ; Wed, 29 Oct 2008 00:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent :mime-version:cc:content-type:message-id:from; bh=1mWgRWoGJVbH9DNZS935xyFvGX1z1yE3MLnCwhtN77g=; b=uAW7wQ1g9sbVicO+oSoupbiNUQ4qs6RNK0amZAHLiwxDelWvqhgcIJRnTQAh7qEKEP hkzk9dM12eIv1ird3lnatDUa6CA5EWzeDxUqbJNCQtH18PVYIpVHEhiU0ESuhOL9vZfB ntoS1h0wGs/TeKAhT1Tp/4icAvfR+oeAAP2VE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:mime-version:cc:content-type:message-id :from; b=tmMqd1FNLM6g+eJ85nX+hyOEG15J15BLLE7BW0BKQfsDKoqHQ8YnHN3ekbC8YnTzEi VYFf3imXsw25eVi79FWe+g16UbUCK+ew0YX2EErZXY6QCk6NM2juGkl7fJNANxC7E0eM wPhOAuKRjmV+sl5GKEibKlQaviy+F1Kz4FJ4I= Received: by 10.103.239.10 with SMTP id q10mr3961061mur.82.1225266970107; Wed, 29 Oct 2008 00:56:10 -0700 (PDT) Received: from klee.local ([212.119.9.178]) by mx.google.com with ESMTPS id e8sm10597953muf.6.2008.10.29.00.56.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 29 Oct 2008 00:56:09 -0700 (PDT) To: ipsec@ietf.org Date: Wed, 29 Oct 2008 08:56:04 +0100 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_UcBCJG2SuR2ZIpX" Message-Id: <200810290856.05027.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: cmadson@cisco.com, Pasi.Eronen@nokia.com Subject: [IPsec] Fwd: I-D Action:draft-eronen-ipsec-ikev2-ipv6-config-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --Boundary-00=_UcBCJG2SuR2ZIpX Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Folks, For various reasons I wasn't able to submit as a WG draft a -00 of the IPv6 configuration for IKEv2 draft before Monday's cutoff, thus I submitted it yesterday as a revision (-05) of Pasi's initial draft. Your comments are welcome. The changes are: - decoupling of link and interface creation from IKEv2 message exchange. - possibility for an IKEv2 implementation to delay removal of the IPv6 addresses and prefixes for a period of time to allow upper layer protocol communications (e.g., a TCP connection) to survive an IKE SA re-authentication that would use the same addresses and prefixes. - recommendation that a client includes both the INTERNAL_IP6_LINK and the INTERNAL_IP6_ADDRESS attribute to handle the case where the VPN gateway does not support the extended IPv6 configuration mechanism. Along with that specifies that the INTERNAL_IP6_ADDRESS must be ignore by a gateway when the INTERNAL_IP6_LINK attribute is present and supported by the gateway. - changed the INTERNAL_IP6_LINK attribute to contain the *client* link local interface identifier, as a suggestion when sent by client, and as assignment when sent by gateway. Along with that, specification that that the gateway must choose for itself a link-local interface identifier different from that of the client, or fail the IPv6 address assingnment with NOTIFY payload with the INTERNAL_ADDRESS_FAILURE message. - specified that in the Prefix field of the INTERNAL_IP6_PREFIX, the low order bits of the prefix field which are not part of the prefix must be set to zero by the sender and must be ignored by the receiver. - Some editorials. --julien --Boundary-00=_UcBCJG2SuR2ZIpX Content-Type: message/rfc822; name="forwarded message" Content-Transfer-Encoding: 7bit Content-Description: Internet-Drafts@ietf.org: I-D Action:draft-eronen-ipsec-ikev2-ipv6-config-05.txt Content-Disposition: inline Delivered-To: julien.laganier.ietf@gmail.com Received: by 10.151.118.13 with SMTP id v13cs191441ybm; Tue, 28 Oct 2008 10:45:33 -0700 (PDT) Received: by 10.215.40.20 with SMTP id s20mr1222867qaj.146.1225215933308; Tue, 28 Oct 2008 10:45:33 -0700 (PDT) Return-Path: Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id 6si1418257ywi.1.2008.10.28.10.45.32; Tue, 28 Oct 2008 10:45:33 -0700 (PDT) Received-SPF: pass (google.com: domain of i-d-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of i-d-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=i-d-announce-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6BB28C2E0; Tue, 28 Oct 2008 10:45:03 -0700 (PDT) X-Original-To: i-d-announce@ietf.org Delivered-To: i-d-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 850D828C268; Tue, 28 Oct 2008 10:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-eronen-ipsec-ikev2-ipv6-config-05.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081028174501.850D828C268@core3.amsl.com> Date: Tue, 28 Oct 2008 10:45:01 -0700 (PDT) X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-Length: 4018 X-UID: 15727 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Configuration in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-eronen-ipsec-ikev2-ipv6-config-05.txt Pages : 36 Date : 2008-10-28 When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document describes the limitations of current IKEv2 configuration payloads for IPv6, and explores possible solutions that would allow IKEv2 to set up full- featured virtual IPv6 interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-ipv6-config-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-eronen-ipsec-ikev2-ipv6-config-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-28103013.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --NextPart-- --Boundary-00=_UcBCJG2SuR2ZIpX Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --Boundary-00=_UcBCJG2SuR2ZIpX-- From ipsec-bounces@ietf.org Thu Oct 30 04:00:26 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F8E3A6927; Thu, 30 Oct 2008 04:00:26 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5D2C3A6927 for ; Thu, 30 Oct 2008 04:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65ajq-MtKAPR for ; Thu, 30 Oct 2008 04:00:25 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 94A5F3A6891 for ; Thu, 30 Oct 2008 04:00:24 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9UAxRhv010242; Thu, 30 Oct 2008 12:59:42 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 12:59:22 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 12:59:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 12:59:19 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB72020F3AB0@vaebe104.NOE.Nokia.com> In-Reply-To: <850df0c40810270625q30fdf08cja2a04b967aaccb32@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Issue #32 Demoted SHOULD: EAP Identity Request Thread-Index: Ack4N3wDVpeR2Sa7RtWQbs7byX7kNQCRlpGQ References: <18648.62996.136882.689426@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB7201E72B2A@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB7201EEFF87@vaebe104.NOE.Nokia.com> <850df0c40810270625q30fdf08cja2a04b967aaccb32@mail.gmail.com> From: To: X-OriginalArrivalTime: 30 Oct 2008 10:59:21.0887 (UTC) FILETIME=[9059E2F0:01C93A7E] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #32 Demoted SHOULD: EAP Identity Request X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org balaji raghavan wrote: > But no where it's clarified on what is to be done by the responder > after it obtains the EAP identity from the AAA server. > > For PKI Authentication type the MIPv6 spec (RFC 4877) explicitly > requires the identity within the IDi payload and identity in the > certificate to match. In that particular case the requirement that the > authenticated identity is used for policy lookup, access control etc > is satisfied. > > Atleast the security considerations section should be updated with > this info, as Tero pointed out earlier, as the authenticated identity > cannot be used to govern policy lookups etc, if the responder is > unable to "match" the EAP identity to the one indicated by IDi. There's no requirement that IDi and the authenticated EAP identity have to match, and I don't think we should have one. I agree that adding a sentence or two to the security considerations text (giving a pointer to the last paragraph of Section 2.16) would be a good idea. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 30 09:00:04 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F47128C0E3; Thu, 30 Oct 2008 09:00:04 -0700 (PDT) X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 945D83A6982; Thu, 30 Oct 2008 09:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081030160001.945D83A6982@core3.amsl.com> Date: Thu, 30 Oct 2008 09:00:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2bis-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Internet Key Exchange Protocol: IKEv2 Author(s) : C. Kaufman, et al. Filename : draft-ietf-ipsecme-ikev2bis-01.txt Pages : 134 Date : 2008-10-30 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). It replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ipsecme-ikev2bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-30084610.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Thu Oct 30 09:15:00 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6113E3A6829; Thu, 30 Oct 2008 09:15:00 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B07393A6829 for ; Thu, 30 Oct 2008 09:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJH-5pEwA03U for ; Thu, 30 Oct 2008 09:14:57 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by core3.amsl.com (Postfix) with ESMTP id D6BEC3A67DF for ; Thu, 30 Oct 2008 09:14:57 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m9UGEsSs017900 for ; Thu, 30 Oct 2008 16:14:56 GMT Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.174.48]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m9UGEsHi032164 for ; Thu, 30 Oct 2008 12:14:54 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9UG7Pqw009086 for ; Thu, 30 Oct 2008 12:07:25 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9UG7Oqc009085 for ipsec@ietf.org; Thu, 30 Oct 2008 12:07:24 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Thu, 30 Oct 2008 12:07:24 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20081030160724.GC8534@kebe.east.sun.com> MIME-Version: 1.0 Content-Disposition: inline Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [IPsec] PF_KEY is NOT for IKEv1 only... X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org While checking for the -00 vs. -01 diffs, I saw this: Added a note in 2.9 that PFKEY applies only to IKEv1. Also added that unknown traffic selector types are not returned in narrowed responses. And then I see this: Maintenance of a system's SPD is outside the scope of IKE (see [PFKEY] for an example protocol, although it only applies to IKEv1) which isn't even CLOSE to accurate. Some PF_KEY implementations do implement SPD manipulation. PF_KEY was specifically DESIGNED to be KM-protocol independent. Witness Racoon2 as an example IKEv2 that continues to use PF_KEY. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 30 09:15:06 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8D843A6A2D; Thu, 30 Oct 2008 09:15:06 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD753A6A26 for ; Thu, 30 Oct 2008 09:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FnXyXKa1VUl for ; Thu, 30 Oct 2008 09:15:04 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id D4F693A689B for ; Thu, 30 Oct 2008 09:15:03 -0700 (PDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UGEuSC088753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 30 Oct 2008 09:14:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 30 Oct 2008 09:14:54 -0700 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] New IKEv2bis draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. draft-ietf-ipsecme-ikev2bis-01 is out, and the change list is pretty substantial. Please give a it a careful read. Yaron has entered all the new issues from the mailing list discussion of the -00 draft. If you want to comment on one of them, please put the issue number in the message subject. Also, if you think there is an open issue that is not listed in the tracker, by all means bring it up and we can enter it so that it can be tracked. I'm hoping that we have the -02 draft out in about six weeks, and that the tracker has many fewer open issues at that time. Let's see. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 30 09:21:33 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1FB83A694F; Thu, 30 Oct 2008 09:21:33 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB4C3A6982 for ; Thu, 30 Oct 2008 09:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmt6zi8Q95vu for ; Thu, 30 Oct 2008 09:21:31 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C6ADF3A687E for ; Thu, 30 Oct 2008 09:21:30 -0700 (PDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9UGLQpi090386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2008 09:21:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20081030160724.GC8534@kebe.east.sun.com> References: <20081030160724.GC8534@kebe.east.sun.com> Date: Thu, 30 Oct 2008 09:21:24 -0700 To: Dan McDonald , ipsec@ietf.org From: Paul Hoffman Subject: [IPsec] Issue #64: PF_KEY is NOT for IKEv1 only... X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Entered as a new issue. Proposed text would be appreciated. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 30 09:37:10 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 034A83A6829; Thu, 30 Oct 2008 09:37:10 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38B393A693E for ; Thu, 30 Oct 2008 09:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86bUMi2rYpwM for ; Thu, 30 Oct 2008 09:37:08 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 85C353A67DF for ; Thu, 30 Oct 2008 09:37:08 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m9UGb4rb002326 for ; Thu, 30 Oct 2008 16:37:05 GMT Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.174.48]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m9UGb4rX034291 for ; Thu, 30 Oct 2008 12:37:04 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m9UGTaED010173 for ; Thu, 30 Oct 2008 12:29:36 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m9UGTZkc010172 for ipsec@ietf.org; Thu, 30 Oct 2008 12:29:35 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Thu, 30 Oct 2008 12:29:35 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20081030162935.GE8534@kebe.east.sun.com> References: <20081030160724.GC8534@kebe.east.sun.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] Issue #64: PF_KEY is NOT for IKEv1 only... X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Thu, Oct 30, 2008 at 09:21:24AM -0700, Paul Hoffman wrote: > Proposed text would be appreciated. Sorry for not giving you some off the bat. How 'bout this: 2.9 Traffic Selector Negotiation When an RFC4301-compliant IPsec subsystem receives an IP packet that matches a "protect" selector in its Security Policy Database (SPD), the subsystem protects that packet with IPsec. When no SA exists | yet, it is the task of IKE to create it. Maintenance of a system's | SPD is outside the scope of IKE, but interaction between IKE and | the SPD needs to be considered. See [PFKEY] for an example | interaction between IKE and the SPD (as well as the SAD), and section | 1.1.3 contains an example of where IKE actually could update the | SPD. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Oct 30 09:43:41 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E253A6951; Thu, 30 Oct 2008 09:43:41 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07EF528C0E3 for ; Thu, 30 Oct 2008 09:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.512 X-Spam-Level: X-Spam-Status: No, score=-6.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIvJPP4cQQfe for ; Thu, 30 Oct 2008 09:43:39 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 0C10E3A6951 for ; Thu, 30 Oct 2008 09:43:38 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m9UGgp2g021017; Thu, 30 Oct 2008 11:43:35 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 18:43:16 +0200 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Oct 2008 18:43:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 30 Oct 2008 18:43:13 +0200 Message-ID: <1696498986EFEC4D9153717DA325CB72020F3E99@vaebe104.NOE.Nokia.com> In-Reply-To: <20081030162935.GE8534@kebe.east.sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Issue #64: PF_KEY is NOT for IKEv1 only... Thread-Index: Ack6rdAGJO9fZ5f3RyWUoPUsUxionQAAEMaQ References: <20081030160724.GC8534@kebe.east.sun.com> <20081030162935.GE8534@kebe.east.sun.com> From: To: , X-OriginalArrivalTime: 30 Oct 2008 16:43:13.0864 (UTC) FILETIME=[99F7BC80:01C93AAE] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #64: PF_KEY is NOT for IKEv1 only... X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I think it would be more accurate to say that interaction between IKE and the SPD relies on various implementation-specific mechanisms (protocols/interfaces and/or extensions to them) -- PF_KEY as specified in RFC 2367 doesn't do that. Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of ext Dan McDonald > Sent: 30 October, 2008 18:30 > To: ipsec@ietf.org > Subject: Re: [IPsec] Issue #64: PF_KEY is NOT for IKEv1 only... > > On Thu, Oct 30, 2008 at 09:21:24AM -0700, Paul Hoffman wrote: > > Proposed text would be appreciated. > > Sorry for not giving you some off the bat. How 'bout this: > > 2.9 Traffic Selector Negotiation > > When an RFC4301-compliant IPsec subsystem receives an > IP packet that > matches a "protect" selector in its Security Policy > Database (SPD), > the subsystem protects that packet with IPsec. When no > SA exists > | yet, it is the task of IKE to create it. Maintenance > of a system's > | SPD is outside the scope of IKE, but interaction between IKE and > | the SPD needs to be considered. See [PFKEY] for an example > | interaction between IKE and the SPD (as well as the > SAD), and section > | 1.1.3 contains an example of where IKE actually could update the > | SPD. > > Dan > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 31 06:55:28 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C8A3A6C08; Fri, 31 Oct 2008 06:55:28 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6CFB3A6C02 for ; Fri, 31 Oct 2008 06:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M95STdtEdvfB for ; Fri, 31 Oct 2008 06:55:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id BB61B3A6BFF for ; Fri, 31 Oct 2008 06:55:10 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m9VDt4pu019553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 31 Oct 2008 15:55:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m9VDt34B013352; Fri, 31 Oct 2008 15:55:03 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18699.3639.539516.953180@fireball.kivinen.iki.fi> Date: Fri, 31 Oct 2008 15:55:03 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 26 min X-Total-Time: 42 min Subject: [IPsec] Original initiator and rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I had another question about this from our customer and realized that the actual text in the rfc4306 or clarifications does not exactly specify when the message ids are reset and when the roles are changed. For me it was clear that of course the old IKE SA uses the old roles and old message IDs as otherwise it could not work at all, and the new IKE SA created by rekeying IKE SA will use the new message ID starting from 0, and new roles of the original initiator and responder (i.e. the Initiator flag in the header). After reading the RFC4306 and clarifications and latest draft, I think most of the text is there, but it is scattered so widely it is hard to find: RFC4718 section 5.1 and ikev2bis-01 section 1.3.2 says the new IKE_SA has its message countes set to 0, but does not specify what happens to old IKE_SA message IDs (for me it is clear they stay as they were). RFC4718 section 5.9 and ikev2bis-01 section 2.2 says that the "original initiator" always refers to the party who initiated the exachange that resulted in the current IKE_SA. For me that means only the new IKE SA has its roles changed, not old one, but some people have misinterpreted that. So I propose we add couple of more example sections showing the two cases, i.e. normal case where the original initiator does IKE SA rekey and another case where the original responder does the IKE SA rekey and the roles on the new IKE SA are changed. These sections should most likely be added between 1.3.2 and 1.3.3: ---------------------------------------------------------------------- x.x.x Example of IKE SA Rekey by Original Initiator Here is full example of the IKE SA rekey, including the IKE SPIs, message id, and the Initiator and Response bit on the header. SPIA* are IKE SA SPIs allocated by Alice, and SPIB* are IKE SA SPIs allocated by Bob. HDR(I,R,M,F) format is used to explain fields in the header. I, and R are the initiator and responder IKE SA SPIs, M is the message id (in this example we assume the next one to be used by initiator is 33, and the next one to be used by responder is 44). The F is the flags field of the header, having Initiator and/or Response if those flags are set in the header. In this first example the Alice is the original initiator, and Bob is the original responder, and the Alice starts the IKE SA rekey. SPIA1 and SPIB1 are the SPIs of the old IKE SA and SPIA2 and SPIB2 are the SPIs for the new IKE SA. Alice Bob ------------------------------------------------------------------- HDR(SPIA1,SPIB1,33,Initiator), SK {SA(SPIA2), Ni, [KEi]} --> <-- HDR(SPIA1,SPIB1,33,Response), SK {SA(SPIB2), Nr,[KEr]} Now the IKE SA is rekeyed, and next the party who started the rekey deletes the old IKE SA, i.e. in this case it will be Alice. The delete sent as last message to the old IKE SA. Alice Bob ------------------------------------------------------------------- HDR(SPIA1,SPIB1,34,Initiator), SK {D(Protocol ID=1,No SPI} --> <-- HDR(SPIA1,SPIB1,34,Response), SK {} The next request sent by the Alice and Bob will have headers as following, first the request from Alice and Bob's reply to it: Alice Bob ------------------------------------------------------------------- HDR(SPIA2,SPIB2,0,Initiator), ... --> <--- HDR(SPIA2,SPIB2,0,Response), ... The Bob's first request and Alice's reply to it will be like this: Alice Bob ------------------------------------------------------------------- <--- HDR(SPIA2,SPIB2,0,), ... HDR(SPIA2,SPIB2,0,Initiator Response), ... --> x.x.x Example of IKE SA Rekey by Original Responder In this second example the Alice is still original initiator, and Bob is the original responder, but now Bob starts the IKE SA rekey. Alice Bob ------------------------------------------------------------------- <-- HDR(SPIA1,SPIB1,44,), SK {SA(SPIB2), Nr,[KEr]} HDR(SPIA1,SPIB1,44,Initiator Response), SK {SA(SPIA2), Ni, [KEi]} --> After this the Bob deletes the old IKE SA, and send his delete request as last exchange for the old IKE SA. Note, that the old IKE SA still keeps the original initiator and responder roles, and the message ID is still incremented as normally. Alice Bob ------------------------------------------------------------------- <-- HDR(SPIA1,SPIB1,45,), SK {D(Protocol ID=1,No SPI} HDR(SPIA1,SPIB1,45,Initiator Response), SK {} --> The new IKE SA on the other hand will have original initiator roles reversed compared to the original IKE SA. The next request sent by Alice and Bob's reply to it will have following headers: Alice Bob ------------------------------------------------------------------- HDR(SPIB2,SPIA2,0,), ... --> <--- HDR(SPIB2,SPIA2,0,Initiator Response), ... Note, that the SPIs in the header are reversed (i.e. the SPI allocated by the Bob is first, and the Initiator bit is set on those packets sent by Bob, not those sent by Alice as it was in the old IKE SA). The Bob's first request and Alice's reply to it will be like this: Alice Bob ------------------------------------------------------------------- <--- HDR(SPIB2,SPIA2,0,Initiator), ... HDR(SPIB2,SPIA2,0,Response), ... --> -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Oct 31 08:11:22 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30EE628C26C; Fri, 31 Oct 2008 08:11:22 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4F03A6C18 for ; Fri, 31 Oct 2008 08:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnjylrZFVohI for ; Fri, 31 Oct 2008 08:11:20 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 24DAC3A677C for ; Fri, 31 Oct 2008 08:11:16 -0700 (PDT) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m9VFBC17042688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Oct 2008 08:11:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18699.3639.539516.953180@fireball.kivinen.iki.fi> References: <18699.3639.539516.953180@fireball.kivinen.iki.fi> Date: Fri, 31 Oct 2008 08:11:09 -0700 To: Tero Kivinen , ipsec@ietf.org From: Paul Hoffman Subject: [IPsec] Ticke #65: Re: Original initiator and rekeying X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I gave this a ticket number; we definitely need to make this clearer. IKEv2 implementers: please review Tero's text and comment. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

    Hi = Ken,

     

    This is obviously complex to = implement, as Gary = mentioned.

     

    Also, there are weird interactions = with ESP anti-replay. You are proposing in demultiplex one SPI between = multiple servers at the backend. The load balancer may be able to keep track of = the replay window for the whole SPI (which each server would not be able to = do on its own), but it will not be able to send back notifications if any = problems are detected.

     

    Thanks,

    =

          =       Yaron

     

    From: = Grewal, Ken [mailto:ken.grewal@intel.com]
    Sent: Wednesday, October = 22, 2008 19:04
    To: Yaron Sheffer; Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    Hi Yaron, =

    The scenario I was referring to = requires the servers behind the load balancer to act as a cluster and hence on = the first ESP packet, obtain the IPsec SA from another member of the cluster with = which the SA was negotiated (this may be inherently done on the completion of = an IKE SA also). I have seen this deployed using a back-end dedicated = management interface for state synchronization. Remember, as far as the client is concerned, it is talking to just one server and does not see a cluster, = so the cluster of servers have to act as one to some degree, including = synchronization between them.

     

    Now, state synchronization on the = first packet (e.g. of a new TCP connection) is one thing and achievable, but = the real benefit of the load balancer is to ‘peg’ all subsequent = packets for that TCP session to the same server. This ensures that within a given = TCP (or another stateful protocol) session, there is no need to continually = synchronize the TCP state between all members of the server cluster – if this = was to be done, then the management / synchronization port between the cluster = members would generate more traffic then being received into the cluster, which = is not desirable or practical.

     

    So, from a load balancer point of = view, it can look into the ESP (null) packet and see if this is a new connection = (i.e. no existing rules based on IP/port information). If a new connection, it = can use whatever internal rules to assign this packet to any server with the = least load. On doing this, the load balancer updates internal rules to ensure = any subsequent packets for the same stream as sent to the same server as the initial packet – that is the benefit (this is what load balancers = do today for clear text traffic).

     

    I have also seen alternative = solutions proposed – e.g. A given server completing an IKE negotiation can communicate 3-tuple (IP, SPI, protocol) information back to a load = balancer and the load balancer can utilize this for any subsequent decisions on = assigning load for IPsec encapsulated packet, but solutions like this require synchronization between the load balancer and the servers, which is less desirable. For any cluster of resources acting together to accommodate = load balancing solutions, a certain amount of inter-cluster communication is expected and that fits in with the former solution above. =

     

    Also remember, that IPsec E2E is = not widely deployed because of problems exactly like this one (loss of = visibility / control / functionality for intermediary devices) and this is what we = are trying to address.

     

    Thanks, =

    - Ken

     

    From: = Yaron Sheffer = [mailto:yaronf@checkpoint.com]
    Sent: Tuesday, October = 21, 2008 3:23 PM
    To: Grewal, Ken; Gary = Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    Hi = Ken,

     

    Thanks for the clarification. But I = still don’t understand how your scenario = works.

     

    Assume for simplicity an = environment where everybody uses ESP in transport mode, with null = encryption.

     

    Client C1 does an IKE negotiation = with a random server (as selected by the load balancer) S1. They negotiate some = ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the = load balancer cannot learn the SPI value.

     

    Now when the first ESP packet is = sent from C1 towards the load balancer, there is not enough information for it to = forward the packet to S1, regardless of its being able to look into the = cleartext packet! Only S1 has the ESP keying material, and if LB forwards the = packet elsewhere, the receiver will not be able to verify its = integrity.

     

    Regards,

          =       Yaron

     

    From: = Grewal, Ken [mailto:ken.grewal@intel.com]
    Sent: Tuesday, October = 21, 2008 23:56
    To: Yaron Sheffer; Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    Some observations = below:

     

    1. I agree with Yaron in that if a load balancer needs to ‘terminate’ the traffic before applying any rules to distribute the load, then it should have the keys to do so without = any modifications to the current protocol. In this case, the session = setup (via IKE) should have been negotiated with the load balancer and it = is the natural termination point of the IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel mode or some kind of = front end proxy to the multiple servers behind it in transport mode. =
    2. My understanding of a ‘pure’ load balancer is that it = distributes traffic streams to different resources available to it and this is = typically based on rules such as source / destination IP protocols, ports = (e.g. TCP ports) and potentially some other information. Furthermore, as some = of the upper layer protocols are stateful (e.g. TCP), it is desirable for = the load balancer to ensure that a higher layer ‘session’ = (e.g. TCP session) is ‘pegged’ to a resource (server) that = has been handling the same session – this allows efficient state = maintenance on a given resource / server, instead of all resources needing = access to that state. Now if the traffic is protected using IPsec, then the = load balancer needs access to upper layer payload data in the packet in = order to apply the aforementioned rules for load balancing decisions. The charter item on traffic visibility provides for a clean solution = where the load-balancer (as well as other network monitoring tools) is able = to ascertain that the packet if not encrypted and hence look inside = the packet to analyze the protocol / ports to make load balancing = decisions. In this case, IPsec is still being terminated on the server behind = the load balancer, but the load balancer can examine the IPsec = protected packet en-route to ensure it gets to the right server. In essence, = this charter item allows the load balancer (and other network tools) to continue to function in IPsec environments. =
    3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change = based on new protocols / payloads.

     

    Thanks, =

    - Ken

     

    From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer
    Sent: Tuesday, October = 21, 2008 1:37 PM
    To: Gary Hemminger; = Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    OK. But if your load balancer is = able to decrypt the traffic (i.e. it has the credentials or secret keys), then = it can do that with today’s normal IKE/IPsec. There is no need in this = case to modify the protocol to make it easier to detect encrypted = traffic.

     

    Thanks,

    =

          =       Yaron

     

    From: Gary = Hemminger [mailto:ghemminger@foundrynet.com]
    Sent: Tuesday, October = 21, 2008 19:02
    To: Yaron Sheffer; Yoav = Nir
    Cc: ipsec@ietf.org
    Subject: RE: Identifying = encrypted traffic (was: [IPsec] Reauthentication extension for = IKEv2)

     

    The use = case you are thinking about is probably pure IPsec VPN, where an encrypted stream = only lives across the WAN.  But what if you are a load balancer and the IPsec = traffic is end to end?  In this case, you may have a load balancer that = needs to terminate the traffic so it can make the decision which server to handle = the request.  All load balancers today support SSL termination.  = Same thing applies to IPsec traffic.  We cannot make the decision which = server to handle the request, nor can we maintain persistence without = decrypting the traffic. 

     <= /o:p>

    Gary

     <= /o:p>

    From: = Yaron Sheffer = [mailto:yaronf@checkpoint.com]
    Sent: Tuesday, October = 21, 2008 6:10 AM
    To: Gary Hemminger; = Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Identifying = encrypted traffic (was: [IPsec] Reauthentication extension for = IKEv2)

     

    Hi = Gary,

     

    I’m puzzled by the scenario = you are presenting. I’ve been considering the work on ESP-null detection = (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that = want to look at the IPsec-protected traffic, but do NOT want to terminate = IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, = that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use = case that you have in mind?

     

    Thanks,

    =

          =       Yaron

     

    From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger
    Sent: Monday, October 20, = 2008 20:26
    To: Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] = Reauthentication extension for IKEv2

     

    I was talking about how to make = the determination that the payload is encrypted.  Evidently there are = two approaches:  one based on a heuristic, another based on a payload = wrapper that flags the payload is encrypted.  We would need some mechanism = to determine the payload is encryped if we need to terminate the IPSEC = traffic and make a determination of which server to send it to.  Sorry about = the confusion.

     

    Gary

     

    From: Yoav Nir [mailto:ynir@checkpoint.com]
    Sent: Sat 10/18/2008 2:03 = PM
    To: Gary Hemminger
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Reauthentication extension for IKEv2

    Hi Gary.

     

    I'm not sure what heuristics you are talking about. The problem = of re-authentication is simply this. The owner of the remote access gateway = has a security policy that says that connections can be open for only so long = (say, 2 hours) without authenticating the user again. This is a favorite = requirement by auditors, who believe that this is an important part of risk management. = If somebody steals your laptop (or mobile phone) or sits down at the Internet Cafe = station where you were logged on, we want to limit the amount of time they are connected to the internal network. This requirement makes sense if the = user has to type in their password to authenticate. It makes less sense if there = are user certificates that are stored on the computer, or if the client = software has a "save password" feature.

     

    Whether it makes sense or not, this is a requirement by auditors = and regulators. If the user does not re-authenticate within the specified = time, the IKE SA and all dependent child SAs are deleted.  This = creates a usability problem, because the SA is deleted without any advance warning = to the user, so the user is likely to get a relatively long time with no = connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook = tends to make accounts permanently offline when this = happens.

     

    RFC 4778 and the improvement that Martin Willi is proposing, are = aimed at solving this usability problem by informing the client software in = advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The = heuristic does not affect the security or the IPsec = streams.

     

    Yoav

     

    On Oct 18, 2008, at 2:35 AM, Gary Hemminger = wrote:

     

    One comment on the heuristics approach.  As a hardware vendor of L4-7 ADC boxes, I am a little = concerned about having to terminate IPSEC streams based on the heuristics = approach, because this is open ended.  What I mean is that the heuristic may = be easy to define now, but there is no certainty that it would remain this = way.  My past experience suggests that eventually the heuristic would become = too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway.  =  

    While I like the idea of some “other” box having to solve this issue, which prevents = clients from having to be changed, as we are a vendor of the “other” box, = I think we should think about the long term, not the short term.  = Just my opinion, and I am certainly flexible, but the heuristics approach = worries me a bit.

     

    Gary

     

    [IPsec] Reauthentication extension for = IKEv2

    Martin Willi =
writes:
    > What do you think about such =
an extension? Already considered =
something
    > similar, or does your =
reauthentication procedure work hassle-free? =
I'm
    > wondering if we are the only =
ones facing these problems or if such =
an
    > extension would gain broader =
acceptance...
     
    The first question I have is why =
are you doing reauthentication =
at
    all?
     
    What is the benefits of the =
reauthentication?
     
    What is the benefits of the =
reauthentication that can be done =
WITHOUT
    user intervention (i.e. no user =
typing in password or pin code =
or
    fingerprint or =
similar)?
     
    I myself can only really see =
benefits from reauthentication when =
it
    does require that user is really =
sitting there on the machine, =
and
    gives something that the machine =
itself cannot give. In those =
cases
    the user is required to type in =
something or do something =
anyways,
    thus it does not really matter if =
the communications is =
interrupted
    for second if user must stop his =
work for much longer time to type =
in
    his passphrase or pin =
code.
     
    The RFC 4478 simply skips this =
question and says "With some =
IPsec
    peers, particularly in the remote =
access scenario, it is desirable =
to
    repeat the mutual authentication =
periodically. The purpose of this =
is
    to limit the time that security =
associations (SAs) can be used by =
a
    third party who has gained =
control of the IPsec =
peer."
     
    In most cases if third party has =
gained control of the IPsec peer =
he
    will also get control of all =
authentication information inside =
the
    peer, including private keys and =
pre shared keys. Only way to =
make
    sure that he does not get access =
to those is to protect them =
with
    passphrase, or pin code or =
similar that is only known by the =
user.
     
    This is also said out in the RFC =
4478: "However, in the remote =
access
    scenario it is usually up to a =
human user to supply the
    authentication credentials =
..."
     
    Because of this I do not think =
there is that much requirement =
for
    reauthentication protocol that is =
faster than what we already have. =

    -- =

    kivinen at =
safenet-inc.com
    __________________________________=
_____________
    IPsec mailing =
list
    IPsec at =
ietf.org
    https://www.ietf.org=
/mailman/listinfo/ipsec
     
     


    


    


    




      
 
    • Follow-Ups: =

      • 

    




      
 
        
  
          
   
        • From: Martin
       Willi
          • 
  
        
 
      

    


      
 
    • References: =

      • 

    




      
 
        
  
          
   
        • From: Martin
       Willi
          • 
  
        
 
      

    





    


    Note: Messages sent to this list are the opinions of =
the senders
and do not imply endorsement by the IE
    


    


     



    Scanned by Check Point Total Security Gateway. 

    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org= /mailman/listinfo/ipsec

     



    Scanned by Check Point Total Security Gateway. =



    Scanned by Check Point Total Security Gateway. =

    In that case, the load balancer can identify the traffic using the normal ESP SPI field, and knows exactly = what kind of traffic it is and whether it is encrypted. There is no need to = change the ESP protocol for this scenario.

     

    Thanks,

    =

          =       Yaron

     

    From: Gary = Hemminger [mailto:ghemminger@foundrynet.com]
    Sent: Wednesday, October = 22, 2008 2:00
    To: Yaron Sheffer; Grewal, Ken; Yoav = Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    The client = would negotiate IKE  with the load balancer and would not directly = negotiate with the Server.

     <= /o:p>

    Gary

     <= /o:p>

    From: = Yaron Sheffer = [mailto:yaronf@checkpoint.com]
    Sent: Tuesday, October = 21, 2008 3:23 PM
    To: Grewal, Ken; Gary = Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    Hi = Ken,

     

    Thanks for the clarification. But I = still don’t understand how your scenario = works.

     

    Assume for simplicity an = environment where everybody uses ESP in transport mode, with null = encryption.

     

    Client C1 does an IKE negotiation = with a random server (as selected by the load balancer) S1. They negotiate some = ESP traffic stream, denoted by an SPI. This whole thing is encrypted, so the = load balancer cannot learn the SPI value.

     

    Now when the first ESP packet is = sent from C1 towards the load balancer, there is not enough information for it to = forward the packet to S1, regardless of its being able to look into the = cleartext packet! Only S1 has the ESP keying material, and if LB forwards the = packet elsewhere, the receiver will not be able to verify its = integrity.

     

    Regards,

          =       Yaron

     

    From: = Grewal, Ken [mailto:ken.grewal@intel.com]
    Sent: Tuesday, October = 21, 2008 23:56
    To: Yaron Sheffer; Gary Hemminger; Yoav Nir
    Cc: ipsec@ietf.org
    Subject: RE: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    Some observations = below:

     

    1. I agree with Yaron in that if a load balancer needs to = ‘terminate’ the traffic before applying any rules to distribute the load, then it = should have the keys to do so without any modifications to the current = protocol. In this case, the session setup (via IKE) should have been = negotiated with the load balancer and it is the natural termination point of the = IPsec SA. The load balancer is essentially acting as a VPN gateway for tunnel = mode or some kind of front end proxy to the multiple servers behind it = in transport mode.
    2. My understanding of a ‘pure’ load balancer is that it = distributes traffic streams to different resources available to it and this is = typically based on rules such as source / destination IP protocols, ports (e.g. TCP = ports) and potentially some other information. Furthermore, as some of the = upper layer protocols are stateful (e.g. TCP), it is desirable for the = load balancer to ensure that a higher layer ‘session’ (e.g. = TCP session) is ‘pegged’ to a resource (server) that has been handling = the same session – this allows efficient state maintenance on a given resource / = server, instead of all resources needing access to that state. Now if the = traffic is protected using IPsec, then the load balancer needs access to = upper layer payload data in the packet in order to apply the = aforementioned rules for load balancing decisions. The charter item on traffic = visibility provides for a clean solution where the load-balancer (as well as = other network monitoring tools) is able to ascertain that the packet if = not encrypted and hence look inside the packet to analyze the protocol = / ports to make load balancing decisions. In this case, IPsec is still = being terminated on the server behind the load balancer, but the load = balancer can examine the IPsec protected packet en-route to ensure it gets = to the right server. In essence, this charter item allows the load balancer (and = other network tools) to continue to function in IPsec environments. =
    3. I agree with Gary on his observations about heuristics as being complex in HW, undeterministic and the associated parsing rules liable to change = based on new protocols / payloads.

     

    Thanks, =

    - Ken

     

    From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer
    Sent: Tuesday, October = 21, 2008 1:37 PM
    To: Gary Hemminger; = Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] = Identifying encrypted traffic (was: Reauthentication extension for = IKEv2)

     

    OK. But if your load balancer is = able to decrypt the traffic (i.e. it has the credentials or secret keys), then = it can do that with today’s normal IKE/IPsec. There is no need in this = case to modify the protocol to make it easier to detect encrypted = traffic.

     

    Thanks,

    =

          =       Yaron

     

    From: Gary = Hemminger [mailto:ghemminger@foundrynet.com]
    Sent: Tuesday, October = 21, 2008 19:02
    To: Yaron Sheffer; Yoav = Nir
    Cc: ipsec@ietf.org
    Subject: RE: Identifying = encrypted traffic (was: [IPsec] Reauthentication extension for = IKEv2)

     

    The use = case you are thinking about is probably pure IPsec VPN, where an encrypted stream = only lives across the WAN.  But what if you are a load balancer and the IPsec = traffic is end to end?  In this case, you may have a load balancer that = needs to terminate the traffic so it can make the decision which server to handle = the request.  All load balancers today support SSL termination.  = Same thing applies to IPsec traffic.  We cannot make the decision which = server to handle the request, nor can we maintain persistence without = decrypting the traffic. 

     <= /o:p>

    Gary

     <= /o:p>

    From: = Yaron Sheffer = [mailto:yaronf@checkpoint.com]
    Sent: Tuesday, October = 21, 2008 6:10 AM
    To: Gary Hemminger; = Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Identifying = encrypted traffic (was: [IPsec] Reauthentication extension for = IKEv2)

     

    Hi = Gary,

     

    I’m puzzled by the scenario = you are presenting. I’ve been considering the work on ESP-null detection = (e.g. draft-grewal-ipsec-traffic-visibility-01) as useful for middleboxes that = want to look at the IPsec-protected traffic, but do NOT want to terminate = IPsec (i.e. decapsulate the traffic). In general, if you can terminate IPsec, = that means that you have access to the encryption keys and you can easily differentiate protected and unprotected traffic, Can you explain the use = case that you have in mind?

     

    Thanks,

    =

          =       Yaron

     

    From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Gary Hemminger
    Sent: Monday, October 20, = 2008 20:26
    To: Yoav Nir
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Reauthentication extension for IKEv2

     

    I was talking about how to make = the determination that the payload is encrypted.  Evidently there are = two approaches:  one based on a heuristic, another based on a payload = wrapper that flags the payload is encrypted.  We would need some mechanism = to determine the payload is encryped if we need to terminate the IPSEC = traffic and make a determination of which server to send it to.  Sorry about = the confusion.

     

    Gary

     

    From: Yoav Nir [mailto:ynir@checkpoint.com]
    Sent: Sat 10/18/2008 2:03 = PM
    To: Gary Hemminger
    Cc: ipsec@ietf.org
    Subject: Re: [IPsec] Reauthentication extension for IKEv2

    Hi Gary.

     

    I'm not sure what heuristics you are talking about. The problem = of re-authentication is simply this. The owner of the remote access gateway = has a security policy that says that connections can be open for only so long = (say, 2 hours) without authenticating the user again. This is a favorite = requirement by auditors, who believe that this is an important part of risk management. = If somebody steals your laptop (or mobile phone) or sits down at the = Internet Cafe station where you were logged on, we want to limit the amount of time = they are connected to the internal network. This requirement makes sense if the = user has to type in their password to authenticate. It makes less sense if there = are user certificates that are stored on the computer, or if the client = software has a "save password" feature.

     

    Whether it makes sense or not, this is a requirement by auditors = and regulators. If the user does not re-authenticate within the specified = time, the IKE SA and all dependent child SAs are deleted.  This = creates a usability problem, because the SA is deleted without any advance warning = to the user, so the user is likely to get a relatively long time with no = connectivity. This can break TCP connections such as FTP, HTTP, and IMAP. Outlook = tends to make accounts permanently offline when this = happens.

     

    RFC 4778 and the improvement that Martin Willi is proposing, are = aimed at solving this usability problem by informing the client software in = advance when the re-authentication needs to be done, and allowing them to re-authenticate early enough, so that connections are not broken. The = heuristic does not affect the security or the IPsec = streams.

     

    Yoav

     

    On Oct 18, 2008, at 2:35 AM, Gary Hemminger = wrote:

     

    One comment on the heuristics approach.  As a hardware vendor of L4-7 ADC boxes, I am a little = concerned about having to terminate IPSEC streams based on the heuristics = approach, because this is open ended.  What I mean is that the heuristic may = be easy to define now, but there is no certainty that it would remain this = way.  My past experience suggests that eventually the heuristic would become = too complex, and a well defined mechanism for determining which payload is encrypted would need to be employed anyway.  =  

    While I like the idea of some = “other” box having to solve this issue, which prevents clients from having to be changed, as we are a vendor of the “other” box, I think we = should think about the long term, not the short term.  Just my opinion, and I am = certainly flexible, but the heuristics approach worries me a = bit.

     

    Gary

     

    [IPsec] Reauthentication extension for = IKEv2

     
    Martin Willi =
writes:
    > What do you think about such =
an extension? Already considered =
something
    > similar, or does your =
reauthentication procedure work hassle-free? =
I'm
    > wondering if we are the only =
ones facing these problems or if such =
an
    > extension would gain broader =
acceptance...
     
    The first question I have is why =
are you doing reauthentication =
at
    all?
     
    What is the benefits of the =
reauthentication?
     
    What is the benefits of the =
reauthentication that can be done =
WITHOUT
    user intervention (i.e. no user =
typing in password or pin code =
or
    fingerprint or =
similar)?
     
    I myself can only really see =
benefits from reauthentication when =
it
    does require that user is really =
sitting there on the machine, =
and
    gives something that the machine =
itself cannot give. In those =
cases
    the user is required to type in =
something or do something =
anyways,
    thus it does not really matter if =
the communications is =
interrupted
    for second if user must stop his =
work for much longer time to type =
in
    his passphrase or pin =
code.
     
    The RFC 4478 simply skips this =
question and says "With some =
IPsec
    peers, particularly in the remote =
access scenario, it is desirable =
to
    repeat the mutual authentication =
periodically. The purpose of this =
is
    to limit the time that security =
associations (SAs) can be used by =
a
    third party who has gained =
control of the IPsec =
peer."
     
    In most cases if third party has =
gained control of the IPsec peer =
he
    will also get control of all =
authentication information inside =
the
    peer, including private keys and =
pre shared keys. Only way to =
make
    sure that he does not get access =
to those is to protect them =
with
    passphrase, or pin code or =
similar that is only known by the =
user.
     
    This is also said out in the RFC =
4478: "However, in the remote =
access
    scenario it is usually up to a =
human user to supply the
    authentication credentials =
..."
     
    Because of this I do not think =
there is that much requirement =
for
    reauthentication protocol that is =
faster than what we already have. =

    -- =

    kivinen at =
safenet-inc.com
    __________________________________=
_____________
    IPsec mailing =
list
    IPsec at =
ietf.org
    https://www.ietf.org=
/mailman/listinfo/ipsec
     
     


    


    


    




      
 
    • Follow-Ups: =

      • 

    




      
 
        
  
          
   
        • From: Martin
       Willi
          • 
  
        
 
      

    


      
 
    • References: =

      • 

    




      
 
        
  
          
   
        • From: Martin
       Willi
          • 
  
        
 
      

    





    


    Note: Messages sent to this list are the opinions of =
the
senders and do not imply endorsement by the =
IE
    


    


     



    Scanned by Check Point Total Security Gateway. 

    _______________________________________________
    IPsec mailing list
    IPsec@ietf.org
    https://www.ietf.org= /mailman/listinfo/ipsec

     



    Scanned by Check Point Total Security Gateway. =



    Scanned by Check Point Total Security Gateway. =



    Scanned by Check Point Total Security Gateway. =