From ipsec-bounces@ietf.org Thu Jan 1 13:37:45 2009 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 07DE53A689F; Thu, 1 Jan 2009 13:37:45 -0800 (PST) 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 845363A6804 for ; Thu, 1 Jan 2009 13:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.234 X-Spam-Level: X-Spam-Status: No, score=-0.234 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_40=-0.185, 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 RZgmX8VHMxl0 for ; Thu, 1 Jan 2009 13:37:43 -0800 (PST) Received: from bay0-omc2-s5.bay0.hotmail.com (bay0-omc2-s5.bay0.hotmail.com [65.54.246.141]) by core3.amsl.com (Postfix) with ESMTP id D2E0C3A6AD1 for ; Thu, 1 Jan 2009 13:36:15 -0800 (PST) Received: from BAY106-DS2 ([65.54.161.91]) by bay0-omc2-s5.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jan 2009 13:36:04 -0800 X-Originating-IP: [67.183.153.81] X-Originating-Email: [paulmoore100@hotmail.com] Message-ID: From: "Paul Moore" To: Date: Thu, 1 Jan 2009 13:36:27 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 01 Jan 2009 21:36:04.0249 (UTC) FILETIME=[F2C1F890:01C96C58] Subject: [IPsec] SA port binding 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="===============1814226872==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1814226872== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0081_01C96C15.F24F8320" This is a multi-part message in MIME format. ------=_NextPart_000_0081_01C96C15.F24F8320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I see that the main WG is closed, hopefully this is the right place to = pose these questions =20 I am trying to setup multi platform transport mode on a large scale and = I am hitting several issues that come from different interpretations of = the specs by the ipsec implementations. Main one is this:- =20 =20 if an SA is established as the result of an SPD rule that specifies a = port (ie on this subnet I want esp to port 21) does the SA belong = exclusively to that port? In the above case this doesn't matter but if I = have 2 rules #1 on this subnet I want esp to port 21 #2 on this subnet I want esp to port 23 it does matter. =20 If I create an SA for rule #1 and then try to talk to port 23 on the = same machine what should happen? There are 2 possibilities. I reuse the = port 21 SA or I create a new SA for this flow. Either way works = (assuming the same key rules etc) but both ends have got to agree. = Windows and Solaris are in the 'this SA belongs to port 21' camp, and if = a packet for 23 is sent using the 21 SA then it will be discarded. Linux = is in the 'any SA will do' camp and tries to reuse the 21 SA. In fact in = transport mode the Linux kernel is unaware of port numbers. You can tell = Linux to create unique SAs (SA per flow) but thats overkill as it = creates a new SA for every flow (and I am not convinced that it interops = correctly either).=20 By majority voting Linux is the wrong one; but that is a bit simplistic = (have not got to AIX and HP-UX yet). My vote (if I had one) is that the = SA should not belong to the port, there is no reason for it to, and = there are good reasons for it not to So which is correct ------=_NextPart_000_0081_01C96C15.F24F8320 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I see that the main WG is closed, = hopefully=20 this is the right place to pose these questions
 
I am trying = to=20 setup multi platform transport mode on a large scale and I am hitting = several=20 issues that come from different interpretations of the specs by the = ipsec=20 implementations. Main one is this:-
 
 
if an SA = is=20 established as the result of an SPD rule that specifies a port (ie on = this=20 subnet I want esp to port 21) does the SA belong exclusively to that = port? In=20 the above case this doesn't matter but if I have 2 rules
#1 on this = subnet I=20 want esp to port 21
#2 on this subnet I want esp to port 23
it = does=20 matter.
 
If I create an SA for rule #1 and then try to talk = to port=20 23 on the same machine what should happen? There are 2 possibilities. I = reuse=20 the port 21 SA or I create a new SA for this flow. Either way works = (assuming the same key rules etc) but both ends have got to agree. = Windows and=20 Solaris are in the 'this SA belongs to port 21' camp, and if a = packet for=20 23 is sent using the 21 SA then it will be discarded. Linux is in = the 'any=20 SA will do' camp and tries to reuse the 21 SA. In fact in transport mode = the=20 Linux kernel is unaware of port numbers. You can tell Linux to create = unique SAs=20 (SA per flow)  but thats overkill as it creates a new SA for every = flow=20 (and I am not convinced that it interops correctly = either). 

By=20 majority voting Linux is the wrong one; but that is a bit simplistic = (have not=20 got to AIX and HP-UX yet). My vote (if I had one) is that the SA should = not=20 belong to the port, there is no reason for it to, and there are good = reasons for=20 it not to

So which is correct
------=_NextPart_000_0081_01C96C15.F24F8320-- --===============1814226872== 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 --===============1814226872==-- From ipsec-bounces@ietf.org Fri Jan 2 01:11:59 2009 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 3E94E3A6833; Fri, 2 Jan 2009 01:11:59 -0800 (PST) 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 154223A6833 for ; Fri, 2 Jan 2009 01:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 Crs3Pbyr6ehq for ; Fri, 2 Jan 2009 01:11:57 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B1B363A63CB for ; Fri, 2 Jan 2009 01:11:56 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 78A2929C002; Fri, 2 Jan 2009 11:11:43 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5379029C001; Fri, 2 Jan 2009 11:11:19 +0200 (IST) X-CheckPoint: {495DD86F-10000-88241DC2-7B6} Received: from [172.31.21.158] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n029BIfE018796; Fri, 2 Jan 2009 11:11:18 +0200 (IST) Message-Id: <0508AEA9-2639-4F20-A0A0-A41B2509CBC7@checkpoint.com> From: Yoav Nir To: Paul Moore In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) X-Priority: 3 Date: Fri, 2 Jan 2009 11:11:18 +0200 References: X-Mailer: Apple Mail (2.930.3) Cc: ipsec@ietf.org Subject: Re: [IPsec] SA port binding 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="===============1649188874==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1649188874== Content-Type: multipart/alternative; boundary=Apple-Mail-3--822791467 --Apple-Mail-3--822791467 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Paul. Windows and Solaris are correct not only because they are the majority. The question is what were the traffic selectors negotiated in IKE. If the IKE negotiation was about port 21, then the SA can only be used for port 21. If the SA was for any port then it can be used for both 21 and 23. Our implementation never negotiates protocols and ports, only subnets (or ranges in IKEv2). We still have a firewall that may or may not drop traffic becuase of its rulebase, but conceptually, that firewall is behind the VPN endpoint. On Jan 1, 2009, at 11:36 PM, Paul Moore wrote: > > I see that the main WG is closed, hopefully this is the right place > to pose these questions > > I am trying to setup multi platform transport mode on a large scale > and I am hitting several issues that come from different > interpretations of the specs by the ipsec implementations. Main one > is this:- > > > if an SA is established as the result of an SPD rule that specifies > a port (ie on this subnet I want esp to port 21) does the SA belong > exclusively to that port? In the above case this doesn't matter but > if I have 2 rules > #1 on this subnet I want esp to port 21 > #2 on this subnet I want esp to port 23 > it does matter. > > If I create an SA for rule #1 and then try to talk to port 23 on the > same machine what should happen? There are 2 possibilities. I reuse > the port 21 SA or I create a new SA for this flow. Either way works > (assuming the same key rules etc) but both ends have got to agree. > Windows and Solaris are in the 'this SA belongs to port 21' camp, > and if a packet for 23 is sent using the 21 SA then it will be > discarded. Linux is in the 'any SA will do' camp and tries to reuse > the 21 SA. In fact in transport mode the Linux kernel is unaware of > port numbers. You can tell Linux to create unique SAs (SA per flow) > but thats overkill as it creates a new SA for every flow (and I am > not convinced that it interops correctly either). > > By majority voting Linux is the wrong one; but that is a bit > simplistic (have not got to AIX and HP-UX yet). My vote (if I had > one) is that the SA should not belong to the port, there is no > reason for it to, and there are good reasons for it not to > > So which is correct > Email secured by Check Point --Apple-Mail-3--822791467 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Paul.

Windows and Solaris are correct not only = because they are the majority. The question is what were the traffic = selectors negotiated in IKE. If the IKE negotiation was about port 21, = then the SA can only be used for port 21. If the SA was for any port = then it can be used for both 21 and = 23. 

Our implementation never negotiates = protocols and ports, only subnets (or ranges in IKEv2). We still have a = firewall that may or may not drop traffic becuase of its rulebase, but = conceptually, that firewall is behind the VPN = endpoint.

On Jan 1, 2009, at 11:36 PM, Paul = Moore wrote:


I see that the = main WG is closed, hopefully this is the right place to pose these = questions
 
I am trying to setup multi platform transport = mode on a large scale and I am hitting several issues that come from = different interpretations of the specs by the ipsec = implementations. Main one is this:-
 
 
if an SA = is established as the result of an SPD rule that specifies a port (ie on = this subnet I want esp to port 21) does the SA belong exclusively to = that port? In the above case this doesn't matter but if I have 2 = rules
#1 on this subnet I want esp to port 21
#2 on this subnet I = want esp to port 23
it does matter.
 
If I create an SA = for rule #1 and then try to talk to port 23 on the same machine what = should happen? There are 2 possibilities. I reuse the port 21 SA or = I create a new SA for this flow. Either way works (assuming the = same key rules etc) but both ends have got to agree. Windows and = Solaris are in the 'this SA belongs to port 21' camp, and if a = packet for 23 is sent using the 21 SA then it will be discarded. = Linux is in the 'any SA will do' camp and tries to reuse the 21 SA. In = fact in transport mode the Linux kernel is unaware of port numbers. You = can tell Linux to create unique SAs (SA per flow)  but thats = overkill as it creates a new SA for every flow (and I am not convinced = that it interops correctly either). 

By majority voting = Linux is the wrong one; but that is a bit simplistic (have not got to = AIX and HP-UX yet). My vote (if I had one) is that the SA should not = belong to the port, there is no reason for it to, and there are good = reasons for it not to

So which is correct
=


= =0D=0A
Email secured by Check Point=0D=0A

= = --Apple-Mail-3--822791467-- --===============1649188874== 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 --===============1649188874==-- From ipsec-bounces@ietf.org Fri Jan 2 03:49:33 2009 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 68C1D3A67C1; Fri, 2 Jan 2009 03:49:33 -0800 (PST) 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 BF9FC3A67C1 for ; Fri, 2 Jan 2009 03:49:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 azxVaZoi4+cV for ; Fri, 2 Jan 2009 03:49:31 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1A87C3A63D2 for ; Fri, 2 Jan 2009 03:49:30 -0800 (PST) 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 n02BmGZb017737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Jan 2009 13:48:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n02BmE5A006223; Fri, 2 Jan 2009 13:48:14 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18781.65278.432552.976452@fireball.kivinen.iki.fi> Date: Fri, 2 Jan 2009 13:48:14 +0200 From: Tero Kivinen To: Herbert Xu In-Reply-To: <20081230030652.GA15620@gondor.apana.org.au> References: <20081218215625.GA1070@gondor.apana.org.au> <18767.36828.648842.596858@fireball.kivinen.iki.fi> <20081222223506.GA7267@gondor.apana.org.au> <18768.48999.480981.798652@fireball.kivinen.iki.fi> <20081223110512.GA12092@gondor.apana.org.au> <18776.50975.768573.828996@fireball.kivinen.iki.fi> <20081230030652.GA15620@gondor.apana.org.au> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 27 min X-Total-Time: 27 min Cc: ipsec@ietf.org Subject: Re: [IPsec] To UDP encapsulate or not 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 Herbert Xu writes: > The reason is that we're making a document that impelmentors will > rely on to determine the behaviour of their software. They often > don't have the time to fully investigate all the rationale of each > individual statement in the RFC. Therefore we should strive to > avoid statements which have the potential of creating "compliant" > implementations that cannot communicate with each other. If sender side is MUST NOT and server side is MAY/SHOULD/MUST be able to process regardless of encoding, that still means that all complient implementations can communicate with each other. It also means that non-complient implementations (which violate the first MUST NOT) may be able to communicate with the complient implementations (if they do follow the MUST be able to process part). That way does give us maximum interoperability. Saying that recipient MUST NOT process incoming packets if they have wrong encoding will NOT help interoperability. Only thing that might confuse the implementor is that implementor might read that "SHOULD/MUST be able to process" for the recipient might indicates something about what the sender part can do, when it does not say anything about that. If we have also separate MUST NOT for the sender part, that should clear that confusion. > As I have explained previously, the status quo would allow two > implementations that abide by the current draft documentation > but simply cannot communicate successfully when firewalls are > present. Can you explain that case once more, with proper examples, as I have not seen such case, where two implementations following the "MUST NOT" for both sender and recipient would be able to communicate, but where the two implementations where the sender follows MUST NOT and recipient follows "MUST be able to process" cannot communicate. > FWIW the thread that led me here was in fact caused by a MOBIKE > implementation which sent UDP encapsulated packets when NAT was > not detected. As I explained complient MOBIKE can only do that during the transition from one address pair to another, where the MOBIKE implementation guessed incorrectly whether there is NAT or not between peers before it has finished its NAT detection. > While such an implementation may be non-compliant as far MOBIKE > is concerned, it is unfortunately complaint with respect to IPsec > per the current draft document. Nothing in the currnt draft says complient implementation would be allowed to send UDP encapsulatated packets when NAT is not detected. Can you point me to that text? Current RFCs and drafts are silent about that, meaning it is unclear whether it is allowed or not. The ikev2bis draft adds text which says that if sender part follows that unclear behavior then you still MUST process the received packets, i.e. it tries to make it more interoperabile than before by adding the "Implementations MUST process received UDP-encapsulated ESP packets even when no NAT was detected.", but even it does not say whether sender is allowed to send such packets or not. > So essentially this mismatch of UDP encapsulation is allowed in > order to have the MOBIKE peers continue communication after an > address change and before both ends have agreed on the address > change. Yes. > I have to say that the current solution to this problem is rather > poor. On the one hand, it now explicitly allows bogus IPsec > implementations which weren't explictly allowed before, and on > the other hand, it doesn't solve the MOBIKE problem that well. Now you lost me again. Current solution is to be silent whether such is allowed or not in both sender and recipient part. > The target audience of MOBIKE clients are much more likely than > the average IPsec peer to be sitting behind a firewall of the > kind that I described earlier. As such the address update mechanism > as currently documented is going to cause a blackhole during the > address change anyway. There is nothing we can do for that, we can only go around the NAT box after we have been able to detect whether such exists or not. Before that is done we cannot go around it... We could of course drop all packets that come during the address change, but that would always cause black hole when such address update is in progress. Currently we try to guess whether there is NAT or not between, and use encapsulation based on that. If our guess was correct then packets will continue flowing during transition. If our guess was wrong so that we guessed there is NAT, but there wasn't, the packets still continued flowing, but we wasted few bytes. If we guessed it incorrectly that there was no NAT, but there was, then NAT dropped our packets and we created that temporary black hole. Note, that all this happens only if the original IP-address pair is not usable anymore when we start the transition. If the old address pair is still usable, we normally use that until we get the address update process done. > In other words, allowing UDP encapsulation mismatches have made > the IPsec specification worse while it's only making MOBIKE slightly > better. I disagree on that. > > > This is a pretty standard firewall configuration so the only thing > > > that's keeping MOBIKE working at all is NAT. As soon as you remove > > > the NAT while keeping the firewall, the whole thing falls apart. > > > > Yes, Standard IPsec (or MOBIKE) does not work through any firewall > > which is configured to drop all ESP packets, and not do NAT. > > No I'm not talking about a firewall which drops all ESP packets, > I'm talking about a firewall which only allows inbound ESP packets > which are associated with an outbound ESP flow. That is, it only > allows inbound ESP (src, dst) if it has seen outobund ESP packets > (dst, src). Hmm... haven't really seen such firewalls, and such firewalls would not be following the IPsec architecture, as the ESP flow is identified by the SPI and dst-address. Source address might not be part of the flow (for example for multicast traffic). I have seen lots of NATs trying to do that, i.e. they see ESP packet with SPI1, src, dst address going out and then they see incoming ESP packet with SPI2, and then they associate those SPI1 and SPI2 same flow, and try to do things on those. This does not work, and that was the reason we did implemented the UDP encapsulation in the first place. And as the NAT boxes broke things down by not doing the port translation for IKE packets, we needed to move to port 4500 instead of 500, just to get around those broken NAT boxes. I would myself consider such firewall broken and get proper firewall instead. I think we should discourage firewall vendors for making such assumptions which are not valid based on the IPsec architecture. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From luyang-millman@adcockconcrete.com Fri Jan 2 12:05:57 2009 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 9E0163A6879 for ; Fri, 2 Jan 2009 12:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.059 X-Spam-Level: X-Spam-Status: No, score=-31.059 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 GsPvNBmhsr6Z for ; Fri, 2 Jan 2009 12:05:57 -0800 (PST) Received: from 83-152-43-232.rev.libertysurf.net (83-152-43-232.rev.libertysurf.net [83.152.43.232]) by core3.amsl.com (Postfix) with SMTP id 608873A6979 for ; Fri, 2 Jan 2009 12:05:55 -0800 (PST) To: Subject: Your message could not be delivered From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090102200556.608873A6979@core3.amsl.com> Date: Fri, 2 Jan 2009 12:05:55 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From lizzette@ahora.net Sat Jan 3 23:59:40 2009 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 C70EB28C0DB for ; Sat, 3 Jan 2009 23:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -26.347 X-Spam-Level: X-Spam-Status: No, score=-26.347 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 cv-pOKLfi0nA for ; Sat, 3 Jan 2009 23:59:40 -0800 (PST) Received: from ppp-124-121-166-238.revip2.asianet.co.th (ppp-124-121-166-238.revip2.asianet.co.th [124.121.166.238]) by core3.amsl.com (Postfix) with SMTP id C0FEE28B56A for ; Sat, 3 Jan 2009 23:59:38 -0800 (PST) To: Subject: Undeliverable Mail From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090104075938.C0FEE28B56A@core3.amsl.com> Date: Sat, 3 Jan 2009 23:59:38 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From lwaited@amc.toshiba.co.jp Sun Jan 4 00:52:46 2009 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 886B43A69DE for ; Sun, 4 Jan 2009 00:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.73 X-Spam-Level: X-Spam-Status: No, score=-10.73 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, 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 iRp3Flls+tNn for ; Sun, 4 Jan 2009 00:52:45 -0800 (PST) Received: from pc-80-149-45-190.cm.vtr.net (pc-80-149-45-190.cm.vtr.net [190.45.149.80]) by core3.amsl.com (Postfix) with SMTP id E22453A69DD for ; Sun, 4 Jan 2009 00:52:43 -0800 (PST) To: Subject: Gain additional centimeters From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090104085244.E22453A69DD@core3.amsl.com> Date: Sun, 4 Jan 2009 00:52:43 -0800 (PST)

Give a stimulus to your love life with our help!


Please do not reply to this email. To contact Darkhorse Creative, please visit us

If you do not wish to receive further communications from Darkhorse Creative, click here to unsubscribe.

If you've experience any difficulty in being removed from a Darkhorse Creative email list, click here for personalized help.

Copyright © 2008 Darkhorse Creative, Inc. All rights reserved.
217- La Grange Rd, PEWEE VALLEY, KY 40056

From omez@afpprovida.cl Sun Jan 4 12:51:59 2009 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 06B9C3A6831 for ; Sun, 4 Jan 2009 12:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -37.821 X-Spam-Level: X-Spam-Status: No, score=-37.821 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DIALUP=0.862, HELO_EQ_DSL=1.129, HOST_EQ_DIALUP=0.862, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igMWfzhtkFRR for ; Sun, 4 Jan 2009 12:51:58 -0800 (PST) Received: from r190-135-36-13.dialup.adsl.anteldata.net.uy (r190-135-7-182.dialup.adsl.anteldata.net.uy [190.135.7.182]) by core3.amsl.com (Postfix) with SMTP id B73B13A682D for ; Sun, 4 Jan 2009 12:51:55 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090104205156.B73B13A682D@core3.amsl.com> Date: Sun, 4 Jan 2009 12:51:55 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From kondo@aic-j.com Sun Jan 4 18:28:38 2009 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 442CD3A6859 for ; Sun, 4 Jan 2009 18:28:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.835 X-Spam-Level: X-Spam-Status: No, score=-45.835 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 jZdvvuw7TKze for ; Sun, 4 Jan 2009 18:28:37 -0800 (PST) Received: from dbmdms.ddns.cablebg.net (dbmdms.ddns.cablebg.net [85.130.38.25]) by core3.amsl.com (Postfix) with SMTP id D55A53A67B3 for ; Sun, 4 Jan 2009 18:28:34 -0800 (PST) To: Subject: RE: Message 57355 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090105022835.D55A53A67B3@core3.amsl.com> Date: Sun, 4 Jan 2009 18:28:34 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 24639
From kellu@alcoa.com Mon Jan 5 02:32:17 2009 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 976473A6781 for ; Mon, 5 Jan 2009 02:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -36.744 X-Spam-Level: X-Spam-Status: No, score=-36.744 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 o-OYfuuqn6wB for ; Mon, 5 Jan 2009 02:32:15 -0800 (PST) Received: from amerigroupcorp.com (unknown [121.247.149.79]) by core3.amsl.com (Postfix) with SMTP id 49D9C3A63CB for ; Mon, 5 Jan 2009 02:32:13 -0800 (PST) To: Subject: RE: Message 26042 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090105103214.49D9C3A63CB@core3.amsl.com> Date: Mon, 5 Jan 2009 02:32:13 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 93062
From ipsec-bounces@ietf.org Mon Jan 5 10:02:19 2009 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 379C73A68EF; Mon, 5 Jan 2009 10:02:19 -0800 (PST) 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 0DFAC3A68EF for ; Mon, 5 Jan 2009 10:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.591 X-Spam-Level: X-Spam-Status: No, score=-0.591 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HEAD_XUNSENT=1.666] 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 aiiaiLaK-Kc2 for ; Mon, 5 Jan 2009 10:02:17 -0800 (PST) Received: from bay0-omc2-s2.bay0.hotmail.com (bay0-omc2-s2.bay0.hotmail.com [65.54.246.138]) by core3.amsl.com (Postfix) with ESMTP id F37153A687B for ; Mon, 5 Jan 2009 10:02:16 -0800 (PST) Received: from BAY106-DS3 ([65.54.161.92]) by bay0-omc2-s2.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jan 2009 10:02:04 -0800 X-Originating-IP: [64.122.109.42] X-Originating-Email: [paulmoore100@hotmail.com] Message-ID: From: "Paul Moore" In-Reply-To: <0508AEA9-2639-4F20-A0A0-A41B2509CBC7@checkpoint.com> To: "Yoav Nir" References: <0508AEA9-2639-4F20-A0A0-A41B2509CBC7@checkpoint.com> Date: Mon, 5 Jan 2009 10:02:04 -0800 MIME-Version: 1.0 X-Unsent: 1 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 05 Jan 2009 18:02:04.0487 (UTC) FILETIME=[B750C570:01C96F5F] Cc: ipsec@ietf.org Subject: Re: [IPsec] SA port binding 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="===============0973520377==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0973520377== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C96F1C.A92743E0" This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C96F1C.A92743E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable just to make sure I understand. 2409 says=20 " The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode." So if the qm exchange has an IDcx with a port number in it then the = resulting SA is only for that port.=20 So in my case the IDcr sent by the initiator contains 21. And thus that = SA is for port 21. Does the response from the responder have to contain a port number? Can I put a port number in even if the SPD entry doesn't specify a port. = And vice versa; can I leave out the port number even though the SPD does = specify a port From: Yoav Nir=20 Sent: Friday, January 02, 2009 1:11 AM To: Paul Moore=20 Cc: ipsec@ietf.org=20 Subject: Re: [IPsec] SA port binding Hi Paul.=20 Windows and Solaris are correct not only because they are the majority. = The question is what were the traffic selectors negotiated in IKE. If = the IKE negotiation was about port 21, then the SA can only be used for = port 21. If the SA was for any port then it can be used for both 21 and = 23.=20 Our implementation never negotiates protocols and ports, only subnets = (or ranges in IKEv2). We still have a firewall that may or may not drop = traffic becuase of its rulebase, but conceptually, that firewall is = behind the VPN endpoint. On Jan 1, 2009, at 11:36 PM, Paul Moore wrote: I see that the main WG is closed, hopefully this is the right place to = pose these questions =20 I am trying to setup multi platform transport mode on a large scale = and I am hitting several issues that come from different interpretations = of the specs by the ipsec implementations. Main one is this:- =20 =20 if an SA is established as the result of an SPD rule that specifies a = port (ie on this subnet I want esp to port 21) does the SA belong = exclusively to that port? In the above case this doesn't matter but if I = have 2 rules #1 on this subnet I want esp to port 21 #2 on this subnet I want esp to port 23 it does matter. =20 If I create an SA for rule #1 and then try to talk to port 23 on the = same machine what should happen? There are 2 possibilities. I reuse the = port 21 SA or I create a new SA for this flow. Either way works = (assuming the same key rules etc) but both ends have got to agree. = Windows and Solaris are in the 'this SA belongs to port 21' camp, and if = a packet for 23 is sent using the 21 SA then it will be discarded. Linux = is in the 'any SA will do' camp and tries to reuse the 21 SA. In fact in = transport mode the Linux kernel is unaware of port numbers. You can tell = Linux to create unique SAs (SA per flow) but thats overkill as it = creates a new SA for every flow (and I am not convinced that it interops = correctly either).=20 By majority voting Linux is the wrong one; but that is a bit = simplistic (have not got to AIX and HP-UX yet). My vote (if I had one) = is that the SA should not belong to the port, there is no reason for it = to, and there are good reasons for it not to So which is correct Email secured by Check Point=20 -------------------------------------------------------------------------= ------- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0014_01C96F1C.A92743E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
just to make sure I understand. 2409 = says=20
 
" The identities of the = SAs negotiated=20 in Quick Mode are implicitly
   assumed to be the IP = addresses of=20 the ISAKMP peers, without any
   implied constraints on the = protocol or port numbers allowed, unless
   client = identifiers are=20 specified in Quick Mode."
 
So if the qm exchange has an IDcx with a port = number in it=20 then the resulting SA is only for that port.
So in my case the IDcr sent by the initiator = contains 21.=20 And thus that SA is for port 21.
Does the response from the responder have to = contain a=20 port number?
Can I put a port number in even if the SPD entry = doesn=92t=20 specify a port. And vice versa; can I leave out the port number even = though the=20 SPD does specify a port
 
 
 
From: Yoav Nir
Sent: Friday, January 02, 2009 1:11 AM
Subject: Re: [IPsec] SA port binding

Hi Paul.=20

Windows and Solaris are correct not only because they are the = majority. The=20 question is what were the traffic selectors negotiated in IKE. If the = IKE=20 negotiation was about port 21, then the SA can only be used for port 21. = If the=20 SA was for any port then it can be used for both 21 and 23. 

Our implementation never negotiates protocols and ports, only = subnets (or=20 ranges in IKEv2). We still have a firewall that may or may not drop = traffic=20 becuase of its rulebase, but conceptually, that firewall is behind the = VPN=20 endpoint.

On Jan 1, 2009, at 11:36 PM, Paul Moore wrote:

I see that the main WG is closed, = hopefully=20 this is the right place to pose these questions
 
I am = trying to=20 setup multi platform transport mode on a large scale and I am hitting = several=20 issues that come from different interpretations of the specs by the = ipsec=20 implementations. Main one is this:-
 
 
if an = SA is=20 established as the result of an SPD rule that specifies a port (ie on = this=20 subnet I want esp to port 21) does the SA belong exclusively to that = port? In=20 the above case this doesn't matter but if I have 2 rules
#1 on this = subnet=20 I want esp to port 21
#2 on this subnet I want esp to port 23
it = does=20 matter.
 
If I create an SA for rule #1 and then try to = talk to=20 port 23 on the same machine what should happen? There are 2 = possibilities. I=20 reuse the port 21 SA or I create a new SA for this flow. Either = way works=20 (assuming the same key rules etc) but both ends have got to agree. = Windows and=20 Solaris are in the 'this SA belongs to port 21' camp, and if a = packet for=20 23 is sent using the 21 SA then it will be discarded. Linux is in = the=20 'any SA will do' camp and tries to reuse the 21 SA. In fact in = transport mode=20 the Linux kernel is unaware of port numbers. You can tell Linux to = create=20 unique SAs (SA per flow)  but thats overkill as it creates a new = SA for=20 every flow (and I am not convinced that it interops correctly=20 either). 

By majority voting Linux is the wrong one; but = that is a=20 bit simplistic (have not got to AIX and HP-UX yet). My vote (if I had = one) is=20 that the SA should not belong to the port, there is no reason for it = to, and=20 there are good reasons for it not to

So which is=20 = correct




Email = secured=20 by Check Point

_______________________________________________
IPsec mailing=20 list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_0014_01C96F1C.A92743E0-- --===============0973520377== 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 --===============0973520377==-- From ipsec-bounces@ietf.org Mon Jan 5 11:31:37 2009 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 3582A3A6A3A; Mon, 5 Jan 2009 11:31:37 -0800 (PST) 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 CC5783A68E1 for ; Mon, 5 Jan 2009 11:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HEAD_XUNSENT=1.666] 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 hGhx+nRf-8vA for ; Mon, 5 Jan 2009 11:31:34 -0800 (PST) Received: from bay0-omc1-s27.bay0.hotmail.com (bay0-omc1-s27.bay0.hotmail.com [65.54.246.99]) by core3.amsl.com (Postfix) with ESMTP id 2EEFE3A6A30 for ; Mon, 5 Jan 2009 11:31:10 -0800 (PST) Received: from BAY106-DS1 ([65.54.161.90]) by bay0-omc1-s27.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jan 2009 11:30:57 -0800 X-Originating-IP: [64.122.109.42] X-Originating-Email: [paulmoore100@hotmail.com] Message-ID: From: "Paul Moore" In-Reply-To: <0508AEA9-2639-4F20-A0A0-A41B2509CBC7@checkpoint.com> To: "Paul Moore" , "Yoav Nir" References: <0508AEA9-2639-4F20-A0A0-A41B2509CBC7@checkpoint.com> Date: Mon, 5 Jan 2009 11:30:57 -0800 MIME-Version: 1.0 X-Unsent: 1 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 05 Jan 2009 19:30:57.0436 (UTC) FILETIME=[220035C0:01C96F6C] Cc: ipsec@ietf.org Subject: Re: [IPsec] SA port binding 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="===============1202994431==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1202994431== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01C96F29.13B98F40" This is a multi-part message in MIME format. ------=_NextPart_000_002A_01C96F29.13B98F40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I can answer one of my questions. If I change racoon to not send the = port number in the IDcr attribute then Windows refuses to set up the SA. = From: Paul Moore=20 Sent: Monday, January 05, 2009 10:02 AM To: Yoav Nir=20 Cc: ipsec@ietf.org=20 Subject: Re: [IPsec] SA port binding just to make sure I understand. 2409 says=20 " The identities of the SAs negotiated in Quick Mode are implicitly assumed to be the IP addresses of the ISAKMP peers, without any implied constraints on the protocol or port numbers allowed, unless client identifiers are specified in Quick Mode." So if the qm exchange has an IDcx with a port number in it then the = resulting SA is only for that port.=20 So in my case the IDcr sent by the initiator contains 21. And thus that = SA is for port 21. Does the response from the responder have to contain a port number? Can I put a port number in even if the SPD entry doesn't specify a port. = And vice versa; can I leave out the port number even though the SPD does = specify a port From: Yoav Nir=20 Sent: Friday, January 02, 2009 1:11 AM To: Paul Moore=20 Cc: ipsec@ietf.org=20 Subject: Re: [IPsec] SA port binding Hi Paul.=20 Windows and Solaris are correct not only because they are the majority. = The question is what were the traffic selectors negotiated in IKE. If = the IKE negotiation was about port 21, then the SA can only be used for = port 21. If the SA was for any port then it can be used for both 21 and = 23.=20 Our implementation never negotiates protocols and ports, only subnets = (or ranges in IKEv2). We still have a firewall that may or may not drop = traffic becuase of its rulebase, but conceptually, that firewall is = behind the VPN endpoint. On Jan 1, 2009, at 11:36 PM, Paul Moore wrote: I see that the main WG is closed, hopefully this is the right place to = pose these questions =20 I am trying to setup multi platform transport mode on a large scale = and I am hitting several issues that come from different interpretations = of the specs by the ipsec implementations. Main one is this:- =20 =20 if an SA is established as the result of an SPD rule that specifies a = port (ie on this subnet I want esp to port 21) does the SA belong = exclusively to that port? In the above case this doesn't matter but if I = have 2 rules #1 on this subnet I want esp to port 21 #2 on this subnet I want esp to port 23 it does matter. =20 If I create an SA for rule #1 and then try to talk to port 23 on the = same machine what should happen? There are 2 possibilities. I reuse the = port 21 SA or I create a new SA for this flow. Either way works = (assuming the same key rules etc) but both ends have got to agree. = Windows and Solaris are in the 'this SA belongs to port 21' camp, and if = a packet for 23 is sent using the 21 SA then it will be discarded. Linux = is in the 'any SA will do' camp and tries to reuse the 21 SA. In fact in = transport mode the Linux kernel is unaware of port numbers. You can tell = Linux to create unique SAs (SA per flow) but thats overkill as it = creates a new SA for every flow (and I am not convinced that it interops = correctly either).=20 By majority voting Linux is the wrong one; but that is a bit = simplistic (have not got to AIX and HP-UX yet). My vote (if I had one) = is that the SA should not belong to the port, there is no reason for it = to, and there are good reasons for it not to So which is correct Email secured by Check Point=20 -------------------------------------------------------------------------= ------- _______________________________________________ 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 ------=_NextPart_000_002A_01C96F29.13B98F40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I can answer one of my questions. If I = change=20 racoon to not send the port number in the IDcr attribute then Windows = refuses to=20 set up the SA.

From: Paul Moore
Sent: Monday, January 05, 2009 10:02 AM
Subject: Re: [IPsec] SA port binding

just to make sure I understand. 2409 = says=20
 
" The identities of the = SAs negotiated=20 in Quick Mode are implicitly
   assumed to be the IP = addresses of=20 the ISAKMP peers, without any
   implied constraints on the = protocol or port numbers allowed, unless
   client = identifiers are=20 specified in Quick Mode."
 
So if the qm exchange has an IDcx with a port = number in it=20 then the resulting SA is only for that port.
So in my case the IDcr sent by the initiator = contains 21.=20 And thus that SA is for port 21.
Does the response from the responder have to = contain a=20 port number?
Can I put a port number in even if the SPD entry = doesn=92t=20 specify a port. And vice versa; can I leave out the port number even = though the=20 SPD does specify a port
 
 
 
From: Yoav Nir
Sent: Friday, January 02, 2009 1:11 AM
Subject: Re: [IPsec] SA port binding

Hi Paul.=20

Windows and Solaris are correct not only because they are the = majority. The=20 question is what were the traffic selectors negotiated in IKE. If the = IKE=20 negotiation was about port 21, then the SA can only be used for port 21. = If the=20 SA was for any port then it can be used for both 21 and 23. 

Our implementation never negotiates protocols and ports, only = subnets (or=20 ranges in IKEv2). We still have a firewall that may or may not drop = traffic=20 becuase of its rulebase, but conceptually, that firewall is behind the = VPN=20 endpoint.

On Jan 1, 2009, at 11:36 PM, Paul Moore wrote:

I see that the main WG is closed, = hopefully=20 this is the right place to pose these questions
 
I am = trying to=20 setup multi platform transport mode on a large scale and I am hitting = several=20 issues that come from different interpretations of the specs by the = ipsec=20 implementations. Main one is this:-
 
 
if an = SA is=20 established as the result of an SPD rule that specifies a port (ie on = this=20 subnet I want esp to port 21) does the SA belong exclusively to that = port? In=20 the above case this doesn't matter but if I have 2 rules
#1 on this = subnet=20 I want esp to port 21
#2 on this subnet I want esp to port 23
it = does=20 matter.
 
If I create an SA for rule #1 and then try to = talk to=20 port 23 on the same machine what should happen? There are 2 = possibilities. I=20 reuse the port 21 SA or I create a new SA for this flow. Either = way works=20 (assuming the same key rules etc) but both ends have got to agree. = Windows and=20 Solaris are in the 'this SA belongs to port 21' camp, and if a = packet for=20 23 is sent using the 21 SA then it will be discarded. Linux is in = the=20 'any SA will do' camp and tries to reuse the 21 SA. In fact in = transport mode=20 the Linux kernel is unaware of port numbers. You can tell Linux to = create=20 unique SAs (SA per flow)  but thats overkill as it creates a new = SA for=20 every flow (and I am not convinced that it interops correctly=20 either). 

By majority voting Linux is the wrong one; but = that is a=20 bit simplistic (have not got to AIX and HP-UX yet). My vote (if I had = one) is=20 that the SA should not belong to the port, there is no reason for it = to, and=20 there are good reasons for it not to

So which is=20 = correct




Email = secured=20 by Check Point

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

_______________________________________________
IPsec mailing=20 list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_002A_01C96F29.13B98F40-- --===============1202994431== 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 --===============1202994431==-- From ipsec-bounces@ietf.org Mon Jan 5 11:41:18 2009 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 3F5933A6925; Mon, 5 Jan 2009 11:41:18 -0800 (PST) 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 22C1D3A6925 for ; Mon, 5 Jan 2009 11:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_20=-0.74, 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 kHkvsGmrLoBp for ; Mon, 5 Jan 2009 11:41:16 -0800 (PST) Received: from bay0-omc2-s16.bay0.hotmail.com (bay0-omc2-s16.bay0.hotmail.com [65.54.246.152]) by core3.amsl.com (Postfix) with ESMTP id 6D2C03A68E1 for ; Mon, 5 Jan 2009 11:41:16 -0800 (PST) Received: from BAY106-DS4 ([65.54.161.93]) by bay0-omc2-s16.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jan 2009 11:41:04 -0800 X-Originating-IP: [64.122.109.42] X-Originating-Email: [paulmoore100@hotmail.com] Message-ID: From: "Paul Moore" To: , Date: Mon, 5 Jan 2009 11:41:03 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 05 Jan 2009 19:41:04.0109 (UTC) FILETIME=[8B9B29D0:01C96F6D] Subject: [IPsec] subnetted IDcr 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="===============1324497136==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1324497136== Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C96F2A.7D551F90" This is a multi-part message in MIME format. ------=_NextPart_000_003B_01C96F2A.7D551F90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 2409 does not specify when you can use subnets in IDcX. This has = resulted in a conflict between Windows and racoon If I define a rule like this spdadd [21] tcp -P in ipsec = esp/transport//require then racoon send an IDcr of type subnet in the QM exchange. Windows does = not like this; (stepping through the code you can see that the first = check it makes is that its not v4 or v6 subnet) It rejects the request. There is also another failure associated with this. When Windows is the = initiator then racoon checks that the IDcr it gets matches what it = expects, in this case it still checks against a subnet but Windows sent = a concrete address This is easy to fix in racoon but I copied it to the ipsec group too = because the protocol does not really say what IDcX should contain. And I = wanted to get consensus about the correct behavior Note that solaris send concrete adresses ------=_NextPart_000_003B_01C96F2A.7D551F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
2409 does not specify when you can use = subnets in=20 IDcX. This has resulted in a conflict between Windows and = racoon
 
If I define a rule like = this
 
spdadd <your subnet>[21] <yoursubnet> tcp  -P in = ipsec=20 esp/transport//require
 
then racoon send an IDcr of type subnet = in the QM=20 exchange. Windows does not like this; (stepping through the code you can = see=20 that the first check it makes is that its not v4 or v6 = subnet)
It rejects the request.
 
There is also another failure = associated with this.=20 When Windows is the initiator then racoon checks that the IDcr it gets = matches=20 what it expects, in this case it still checks against a subnet but = Windows sent=20 a concrete address
 
This is easy to fix in racoon but I = copied it to=20 the ipsec group too because the protocol does not really say what IDcX = should=20 contain. And I wanted to get consensus about the correct = behavior
 
Note that solaris send concrete=20 adresses
------=_NextPart_000_003B_01C96F2A.7D551F90-- --===============1324497136== 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 --===============1324497136==-- From maruyama@airpopsign.com Mon Jan 5 12:57:25 2009 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 400EE28C0EB for ; Mon, 5 Jan 2009 12:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.876 X-Spam-Level: X-Spam-Status: No, score=-19.876 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_RECV_IP_082154=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKyUO-jT85SZ for ; Mon, 5 Jan 2009 12:57:17 -0800 (PST) Received: from bl6-124-72.dsl.telepac.pt (bl6-124-72.dsl.telepac.pt [82.155.124.72]) by core3.amsl.com (Postfix) with SMTP id 1F3A528C10C for ; Mon, 5 Jan 2009 12:57:14 -0800 (PST) To: Subject: Re: Order status 38425 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090105205716.1F3A528C10C@core3.amsl.com> Date: Mon, 5 Jan 2009 12:57:14 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 33712
From ipsec-bounces@ietf.org Mon Jan 5 14:12:34 2009 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 26E5D3A6A43; Mon, 5 Jan 2009 14:12:34 -0800 (PST) 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 EF62B3A6A43 for ; Mon, 5 Jan 2009 14:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DZHRvF+d8Ng for ; Mon, 5 Jan 2009 14:12:32 -0800 (PST) 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 DEDCD3A6809 for ; Mon, 5 Jan 2009 14:12:31 -0800 (PST) Received: from [10.20.30.158] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05MCFRr055838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 15:12:15 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 5 Jan 2009 14:12:13 -0800 To: "Paul Moore" , , From: Paul Hoffman Subject: Re: [IPsec] subnetted IDcr 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 11:41 AM -0800 1/5/09, Paul Moore wrote: >2409 does not specify when you can use subnets in IDcX. This has resulted in a conflict between Windows and racoon You "can use" subnets only when both parties agree to using subnets. You cannot use it when the two parties do not agree to using subnets. This is the main reason we got rid of the different types of address specification in IKEv2. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 5 14:35:43 2009 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 2D9403A67A1; Mon, 5 Jan 2009 14:35:43 -0800 (PST) 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 69FDF3A67A1 for ; Mon, 5 Jan 2009 14:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXqW-HwD5z3K for ; Mon, 5 Jan 2009 14:35:40 -0800 (PST) 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 5A9E23A6784 for ; Mon, 5 Jan 2009 14:35:40 -0800 (PST) Received: from [10.20.30.158] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n05MZNjT056570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2009 15:35:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 5 Jan 2009 14:35:22 -0800 To: "Paul Moore" , "Paul Moore" , , From: Paul Hoffman Subject: Re: [IPsec] subnetted IDcr 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 2:31 PM -0800 1/5/09, Paul Moore wrote: >I think you are saying that racoon is wrong. I'm not saying that at all. >It should not use subnets >unless it knows (by some of out band mechanism) that the recipient will >accept them. Correct. >And for sure Windows does not accept them But there is no way for Racoon (or anyone) to know that. For example, some Windows IPsec software (such as the systems we have tested at VPNC) accept subnets just fine. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 5 15:38:13 2009 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 56EB73A65A5; Mon, 5 Jan 2009 15:38:13 -0800 (PST) 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 DEE2C3A63D2 for ; Mon, 5 Jan 2009 15:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.011, 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 kWtAILCBXVJJ for ; Mon, 5 Jan 2009 15:38:10 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 09E4B3A65A5 for ; Mon, 5 Jan 2009 15:38:10 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 869AE29C002; Tue, 6 Jan 2009 01:37:56 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 27C9129C001; Tue, 6 Jan 2009 01:37:35 +0200 (IST) X-CheckPoint: {496297D6-10000-88241DC2-7B6} Received: from [172.31.21.72] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n05NbYfE001633; Tue, 6 Jan 2009 01:37:34 +0200 (IST) Message-Id: From: Yoav Nir To: Paul Moore In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) X-Priority: 3 Date: Tue, 6 Jan 2009 01:37:34 +0200 References: <0508AEA9-2639-4F20-A0A0-A41B2509CBC7@checkpoint.com> X-Mailer: Apple Mail (2.930.3) Cc: ipsec@ietf.org Subject: Re: [IPsec] SA port binding 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="===============1902994520==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1902994520== Content-Type: multipart/alternative; boundary=Apple-Mail-2--511616294 --Apple-Mail-2--511616294 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable If we're talking IKEv1, then AFAICT the responder MUST send exactly =20 the same selectors (or ID payloads in IKEv1 terminology) as the =20 initiator sent. There's no real "negotiation" On Jan 5, 2009, at 8:02 PM, Paul Moore wrote: > just to make sure I understand. 2409 says > > " The identities of the SAs negotiated in Quick Mode are implicitly > assumed to be the IP addresses of the ISAKMP peers, without any > implied constraints on the protocol or port numbers allowed, unless > client identifiers are specified in Quick Mode." > > So if the qm exchange has an IDcx with a port number in it then the =20= > resulting SA is only for that port. > So in my case the IDcr sent by the initiator contains 21. And thus =20 > that SA is for port 21. > Does the response from the responder have to contain a port number? > Can I put a port number in even if the SPD entry doesn=92t specify a =20= > port. And vice versa; can I leave out the port number even though =20 > the SPD does specify a port > > > > From: Yoav Nir > Sent: Friday, January 02, 2009 1:11 AM > To: Paul Moore > Cc: ipsec@ietf.org > Subject: Re: [IPsec] SA port binding > > Hi Paul. > > Windows and Solaris are correct not only because they are the =20 > majority. The question is what were the traffic selectors negotiated =20= > in IKE. If the IKE negotiation was about port 21, then the SA can =20 > only be used for port 21. If the SA was for any port then it can be =20= > used for both 21 and 23. > > Our implementation never negotiates protocols and ports, only =20 > subnets (or ranges in IKEv2). We still have a firewall that may or =20 > may not drop traffic becuase of its rulebase, but conceptually, that =20= > firewall is behind the VPN endpoint. > > On Jan 1, 2009, at 11:36 PM, Paul Moore wrote: > >> >> I see that the main WG is closed, hopefully this is the right place =20= >> to pose these questions >> >> I am trying to setup multi platform transport mode on a large scale =20= >> and I am hitting several issues that come from different =20 >> interpretations of the specs by the ipsec implementations. Main one =20= >> is this:- >> >> >> if an SA is established as the result of an SPD rule that specifies =20= >> a port (ie on this subnet I want esp to port 21) does the SA belong =20= >> exclusively to that port? In the above case this doesn't matter but =20= >> if I have 2 rules >> #1 on this subnet I want esp to port 21 >> #2 on this subnet I want esp to port 23 >> it does matter. >> >> If I create an SA for rule #1 and then try to talk to port 23 on =20 >> the same machine what should happen? There are 2 possibilities. I =20 >> reuse the port 21 SA or I create a new SA for this flow. Either way =20= >> works (assuming the same key rules etc) but both ends have got to =20 >> agree. Windows and Solaris are in the 'this SA belongs to port 21' =20= >> camp, and if a packet for 23 is sent using the 21 SA then it will =20 >> be discarded. Linux is in the 'any SA will do' camp and tries to =20 >> reuse the 21 SA. In fact in transport mode the Linux kernel is =20 >> unaware of port numbers. You can tell Linux to create unique SAs =20 >> (SA per flow) but thats overkill as it creates a new SA for every =20= >> flow (and I am not convinced that it interops correctly either). >> >> By majority voting Linux is the wrong one; but that is a bit =20 >> simplistic (have not got to AIX and HP-UX yet). My vote (if I had =20 >> one) is that the SA should not belong to the port, there is no =20 >> reason for it to, and there are good reasons for it not to >> >> So which is correct >> > > > > Email secured by Check Point > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > Scanned by Check Point Total Security Gateway. > =0D=0A Email secured by Check Point=0D=0A --Apple-Mail-2--511616294 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable If we're talking IKEv1, then = AFAICT the responder MUST send exactly the same selectors (or ID = payloads in IKEv1 terminology) as the initiator sent.  There's no = real "negotiation"

On Jan 5, 2009, at 8:02 PM, Paul = Moore wrote:

=
just to make sure I understand. = 2409 says
 
" The identities of the SAs negotiated in Quick Mode are = implicitly
   assumed to be the IP addresses of the ISAKMP = peers, without any
   implied constraints on the protocol = or port numbers allowed, unless
   client identifiers are = specified in Quick Mode."
 
So if the = qm exchange has an IDcx with a port number in it then the resulting SA = is only for that port.
So in my = case the IDcr sent by the initiator contains 21. And thus that SA is for = port 21.
Does the response from = the responder have to contain a port number?
Can I put a port number in even if the SPD entry doesn=92t = specify a port. And vice versa; can I leave out the port number even = though the SPD does specify a port
 
 
 
=
From: Yoav = Nir
Sent: Friday, January 02, 2009 1:11 AM
= = =
Subject: Re: [IPsec] SA port binding
=

Hi Paul.

Windows and Solaris are = correct not only because they are the majority. The question is what = were the traffic selectors negotiated in IKE. If the IKE negotiation was = about port 21, then the SA can only be used for port 21. If the SA was = for any port then it can be used for both 21 and 23. 
=

Our implementation never negotiates protocols and = ports, only subnets (or ranges in IKEv2). We still have a firewall that = may or may not drop traffic becuase of its rulebase, but conceptually, = that firewall is behind the VPN endpoint.

On = Jan 1, 2009, at 11:36 PM, Paul Moore wrote:


I see that the main WG is closed, = hopefully this is the right place to pose these = questions
 
I am trying to setup multi platform transport = mode on a large scale and I am hitting several issues that come from = different interpretations of the specs by the ipsec = implementations. Main one is this:-
 
 
if an SA = is established as the result of an SPD rule that specifies a port (ie = on this subnet I want esp to port 21) does the SA belong exclusively = to that port? In the above case this doesn't matter but if I have 2 = rules
#1 on this subnet I want esp to port 21
#2 on this subnet = I want esp to port 23
it does matter.
 
If I create an = SA for rule #1 and then try to talk to port 23 on the same machine = what should happen? There are 2 possibilities. I reuse the port 21 SA = or I create a new SA for this flow. Either way works (assuming = the same key rules etc) but both ends have got to agree. Windows and = Solaris are in the 'this SA belongs to port 21' camp, and if a = packet for 23 is sent using the 21 SA then it will be discarded. = Linux is in the 'any SA will do' camp and tries to reuse the 21 SA. In = fact in transport mode the Linux kernel is unaware of port numbers. = You can tell Linux to create unique SAs (SA per flow)  but thats = overkill as it creates a new SA for every flow (and I am not convinced = that it interops correctly either). 

By majority voting = Linux is the wrong one; but that is a bit simplistic (have not got to = AIX and HP-UX yet). My vote (if I had one) is that the SA should not = belong to the port, there is no reason for it to, and there are good = reasons for it not to

So which is = correct




Email = secured by Check Point


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


Scanned by Check Point Total = Security Gateway.
=


= =0D=0A
Email secured by Check Point=0D=0A

= = --Apple-Mail-2--511616294-- --===============1902994520== 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 --===============1902994520==-- From mitchpittman@aennepress.it Mon Jan 5 16:44:12 2009 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 83A263A67D4 for ; Mon, 5 Jan 2009 16:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -53.044 X-Spam-Level: X-Spam-Status: No, score=-53.044 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69nL53HcGZw4 for ; Mon, 5 Jan 2009 16:44:11 -0800 (PST) Received: from uslec-66-255-79-114.cust.uslec.net (uslec-66-255-79-114.cust.uslec.net [66.255.79.114]) by core3.amsl.com (Postfix) with SMTP id 714CB3A63D2 for ; Mon, 5 Jan 2009 16:44:08 -0800 (PST) To: Subject: Re: Order status 30847 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090106004409.714CB3A63D2@core3.amsl.com> Date: Mon, 5 Jan 2009 16:44:08 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 20050
From ipsec-bounces@ietf.org Mon Jan 5 17:00:03 2009 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 8AC7C3A68D8; Mon, 5 Jan 2009 17:00:03 -0800 (PST) X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 030D43A65A5; Mon, 5 Jan 2009 17:00:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090106010002.030D43A65A5@core3.amsl.com> Date: Mon, 5 Jan 2009 17:00:02 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-roadmap-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 : IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap Author(s) : S. Frankel, S. Krishnan Filename : draft-ietf-ipsecme-roadmap-00.txt Pages : 41 Date : 2009-1-5 Over the past few years, the number of RFCs that define and use IPsec and IKE has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes the previous IPsec Document Roadmap [RFC2411]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-roadmap-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-roadmap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-1-5165327.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 novaktxkcqs@amocofcu.org Tue Jan 6 04:37:30 2009 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 152CE3A67AB for ; Tue, 6 Jan 2009 04:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.98 X-Spam-Level: X-Spam-Status: No, score=-20.98 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taFsqWpdmlMM for ; Tue, 6 Jan 2009 04:37:24 -0800 (PST) Received: from 263.net (unknown [201.29.4.100]) by core3.amsl.com (Postfix) with SMTP id 41C763A6768 for ; Tue, 6 Jan 2009 04:37:20 -0800 (PST) To: Subject: RE: Message 01649 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090106123721.41C763A6768@core3.amsl.com> Date: Tue, 6 Jan 2009 04:37:20 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 06254
From ipsec-bounces@ietf.org Tue Jan 6 07:17:57 2009 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 CD9DE3A67EA; Tue, 6 Jan 2009 07:17:57 -0800 (PST) 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 D04563A67EA for ; Tue, 6 Jan 2009 07:17:55 -0800 (PST) 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 hjT1+0QQEMXU for ; Tue, 6 Jan 2009 07:17:55 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id CB92A3A6807 for ; Tue, 6 Jan 2009 07:17:54 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n06FGRdQ005358 for ; Tue, 6 Jan 2009 10:16:27 -0500 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n06FHemq161922 for ; Tue, 6 Jan 2009 10:17:40 -0500 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id n06FHefs003587 for ; Tue, 6 Jan 2009 10:17:40 -0500 Received: from d01mc084.pok.ibm.com (d01mc084.pok.ibm.com [9.63.9.226]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id n06FHefS003584 for ; Tue, 6 Jan 2009 10:17:40 -0500 To: ipsec@ietf.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Tue, 6 Jan 2009 10:17:40 -0500 X-MIMETrack: Serialize by Router on D01MC084/01/M/IBM(Release 8.0.1|February 07, 2008) at 01/06/2009 10:17:40 MIME-Version: 1.0 Subject: [IPsec] NO_ADDITIONAL_SAS text in Conformance Requirements 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="===============1518719717==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1518719717== Content-type: multipart/alternative; Boundary="0__=0ABBFFA5DFC284638f9e8a93df938690918c0ABBFFA5DFC28463" Content-Disposition: inline --0__=0ABBFFA5DFC284638f9e8a93df938690918c0ABBFFA5DFC28463 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Section 4 of RFC 4306 (and draft-ietf-ipsecme-ikev2bis-01.txt) contains= the following text: A minimal implementation MAY support the CREATE_CHILD_SA exchange only = in so far as to recognize requests and reject them with a Notify payload o= f type NO_ADDITIONAL_SAS. A minimal implementation need not be able to initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA expir= es (based on locally configured values of either lifetime or octets passed= ), and implementation MAY either try to renew it with a CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and create a new one. If = the responder rejects the CREATE_CHILD_SA request with a NO_ADDITIONAL_SAS notification, the implementation MUST be capable of instead deleting th= e old SA and creating a new one. I have a few questions concerning the last sentence in that text: 1) Does this sentence only apply to CREATE_CHILD_SA exchanges used to r= ekey an existing SA (i.e. an attempt to rekey either an IKE SA or Child SA a= nd not an attempt to create a new child SA)? 2) Assume the CREATE_CHILD_SA exchange that resulted in the NO_ADDITIONAL_SAS notification was intended to rekey an existing child = SA. Does "old SA" refer to the existing child SA that was being rekeyed or = the IKE SA that was used when the NO_ADDITIONAL_SAS notify was returned? 3) What action should be taken if the NO_ADDITIONAL_SAS notify is recei= ved in a CREATE_CHILD_SA exchange intended to create a new child SA rather = than rekeying an existing SA? Dave Wierbowski z/OS Comm Server Developer = --0__=0ABBFFA5DFC284638f9e8a93df938690918c0ABBFFA5DFC28463 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Section 4 of RFC 4306 (and draft-ietf-ipsecme-ikev2bis-01.txt) conta= ins the following text:

A minimal implementation MAY support the CREATE_CHILD_SA exchange only = in so far as to recognize requests and reject them with a Notify payloa= d of type NO_ADDITIONAL_SAS. A minimal implementation need not be able= to initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA e= xpires (based on locally configured values of either lifetime or octets= passed), and implementation MAY either try to renew it with a CREATE_C= HILD_SA exchange or it MAY delete (close) the old SA and create a new o= ne. If the responder rejects the CREATE_CHILD_SA request with a NO_ADD= ITIONAL_SAS notification, the implementation MUST be capable of instead= deleting the old SA and creating a new one.

I have a few questions concerning the last sentence in that text:

1) Does this sentence only apply to CREATE_CHILD_SA exchanges used to r= ekey an existing SA (i.e. an attempt to rekey either an IKE SA or Child= SA and not an attempt to create a new child SA)?

2) Assume the CREATE_CHILD_SA exchange that resulted in the NO_ADDITION= AL_SAS notification was intended to rekey an existing child SA. Does &= quot;old SA" refer to the existing child SA that was being rekeyed= or the IKE SA that was used when the NO_ADDITIONAL_SAS notify was retu= rned?

3) What action should be taken if the NO_ADDITIONAL_SAS notify is recei= ved in a CREATE_CHILD_SA exchange intended to create a new child SA rat= her than rekeying an existing SA?

Dave Wierbowski


z/OS Comm Server Developer



= --0__=0ABBFFA5DFC284638f9e8a93df938690918c0ABBFFA5DFC28463-- --===============1518719717== 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 --===============1518719717==-- From mx@1.is Tue Jan 6 08:17:54 2009 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 A844928C113 for ; Tue, 6 Jan 2009 08:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.623 X-Spam-Level: X-Spam-Status: No, score=-17.623 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0XdmBAcjYtX for ; Tue, 6 Jan 2009 08:17:48 -0800 (PST) Received: from pool-70-19-176-126.bos.east.verizon.net (pool-70-19-176-126.bos.east.verizon.net [70.19.176.126]) by core3.amsl.com (Postfix) with SMTP id C99DB28C0FF for ; Tue, 6 Jan 2009 08:17:46 -0800 (PST) To: Subject: Your order 11076 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090106161746.C99DB28C0FF@core3.amsl.com> Date: Tue, 6 Jan 2009 08:17:46 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 44658
From ipsec-bounces@ietf.org Wed Jan 7 04:55:46 2009 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 386683A6921; Wed, 7 Jan 2009 04:55:46 -0800 (PST) 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 9F1F03A6921 for ; Wed, 7 Jan 2009 04:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 42bif30IT1r3 for ; Wed, 7 Jan 2009 04:55:44 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 46E163A6904 for ; Wed, 7 Jan 2009 04:55:43 -0800 (PST) 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 n07CtRbc002562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2009 14:55:27 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n07CtPHo012479; Wed, 7 Jan 2009 14:55:25 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18788.42557.933151.759757@fireball.kivinen.iki.fi> Date: Wed, 7 Jan 2009 14:55:25 +0200 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 13 min Cc: ipsec@ietf.org Subject: [IPsec] NO_ADDITIONAL_SAS text in Conformance Requirements 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 David Wierbowski writes: > > > > Section 4 of RFC 4306 (and draft-ietf-ipsecme-ikev2bis-01.txt) contains the > following text: > > A minimal implementation MAY support the CREATE_CHILD_SA exchange only in > so far as to recognize requests and reject them with a Notify payload of > type NO_ADDITIONAL_SAS. A minimal implementation need not be able to > initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA expires > (based on locally configured values of either lifetime or octets passed), > and implementation MAY either try to renew it with a CREATE_CHILD_SA > exchange or it MAY delete (close) the old SA and create a new one. If the > responder rejects the CREATE_CHILD_SA request with a NO_ADDITIONAL_SAS > notification, the implementation MUST be capable of instead deleting the > old SA and creating a new one. > > I have a few questions concerning the last sentence in that text: > > 1) Does this sentence only apply to CREATE_CHILD_SA exchanges used to rekey > an existing SA (i.e. an attempt to rekey either an IKE SA or Child SA and > not an attempt to create a new child SA)? No. It is clear that minimal implementation can return that error also for attemtps to create a new child SA. The text saying "MAY support the CREATE_CHILD_SA exchange only so far as to recognize requests and reject them" clearly is covers any CREATE_CHILD_SA exchanges, i.e. both rekeys and creating new child SA. > 2) Assume the CREATE_CHILD_SA exchange that resulted in the > NO_ADDITIONAL_SAS notification was intended to rekey an existing child SA. > Does "old SA" refer to the existing child SA that was being rekeyed or the > IKE SA that was used when the NO_ADDITIONAL_SAS notify was returned? I would say either. There might be implementations who do not support CREATE_CHILD_SA exchange at all, i.e. they will always return NO_ADDITIONAL_SAS for it, regardless whether it is rekey or creation of new SA. In those applications the rekey CREATE_CHILD_SA might result NO_ADDITIONAL_SAS and then after deleting the IPsec SA, and trying CREATE_CHILD_SA to create new child SA might still result NO_ADDITIONAL_SAS and in that case the only option left is to remove the IKE SA and start over. There might also be implementations who do support CREATE_CHILD_SA but only support exactly one IPsec SA, and that case the creation of child SA might succeed after the rekey CREATE_CHILD_SA was rejected with NO_ADDITIONAL_SAS. I.e. there the rekey CREATE_CHILD_SA will be rejected with NO_ADDITIONAL_SAS but after deleting the old child SA, new CREATE_CHILD_SA for creating new child SA might still succeed. The current text is not really clear whether we want to support both of those options, or whether only the first option is to be supported (i.e. where minimal implmenetation does not support CREATE_CHILD_SA at all, except recognize it and return NO_ADDITIONAL_SAS error). > 3) What action should be taken if the NO_ADDITIONAL_SAS notify is received > in a CREATE_CHILD_SA exchange intended to create a new child SA rather than > rekeying an existing SA? Good question. If there is still child SAs on the same IKE SA, then you could try to deleting those first, and then retrying. If there is no child SAs with the current IKE SA, and you get NO_ADDITIONAL_SAS as error telling no more child SAs can be created, then you need to delete the whole IKE SA and start over. That behavior would be complient with both of the cases I showed above. If you only want to cover first case then you can always delete IKE SA and start over when you get NO_ADDITIONAL_SAS. If the NO_ADDITIONAL_SAS was received during IKE_AUTH, that is completely different matter, and that is not defined in the current documents. My suggestion there was that if you receive NO_ADDITIONAL_SAS during IKE_AUTH, you put that IKE SA on hold for 60-120 seconds (i.e. do not trigger new exchanges for that IKE SA, but do process request from other end), and after that you remove that hold, and for the next packet that would trigger new SA you try CREATE_CHILD_SA and see if it works now. If it does not work now, you follow rules specified above, i.e. as you do not have child SAs and you receive NO_ADDITIONAL_SAS, you delete IKE SA and start over. This would be matching what I suggested for the redirect case or any other case when the server is out of resources to create new child SAs. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From krisspq@aerovironment.com Wed Jan 7 08:33:17 2009 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 551303A68AC for ; Wed, 7 Jan 2009 08:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.33 X-Spam-Level: X-Spam-Status: No, score=-33.33 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWnuSvwbflXW for ; Wed, 7 Jan 2009 08:33:16 -0800 (PST) Received: from eav250.neoplus.adsl.tpnet.pl (eav250.neoplus.adsl.tpnet.pl [83.22.185.250]) by core3.amsl.com (Postfix) with SMTP id 951963A6843 for ; Wed, 7 Jan 2009 08:33:13 -0800 (PST) To: Subject: Re: Order status 72965 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090107163314.951963A6843@core3.amsl.com> Date: Wed, 7 Jan 2009 08:33:13 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 66857
From len@alfa.com Wed Jan 7 15:33:40 2009 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 5E33A3A6AA2 for ; Wed, 7 Jan 2009 15:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.391 X-Spam-Level: X-Spam-Status: No, score=-46.391 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HOST_EQ_BROADBND=1.118, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+BW76neVU78 for ; Wed, 7 Jan 2009 15:33:39 -0800 (PST) Received: from spc2-bagu7-0-0-cust971.bagu.broadband.ntl.com (spc2-bagu7-0-0-cust971.bagu.broadband.ntl.com [80.3.119.204]) by core3.amsl.com (Postfix) with SMTP id 4807F3A68B4 for ; Wed, 7 Jan 2009 15:33:36 -0800 (PST) To: Subject: Re: Order status 03607 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090107233337.4807F3A68B4@core3.amsl.com> Date: Wed, 7 Jan 2009 15:33:36 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 19487
From ipsec-bounces@ietf.org Thu Jan 8 00:49:12 2009 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 75A6928C0CE; Thu, 8 Jan 2009 00:49:12 -0800 (PST) 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 6951D3A6A21 for ; Thu, 8 Jan 2009 00:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.768 X-Spam-Level: X-Spam-Status: No, score=-1.768 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] 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 oHeMSR85ki2L for ; Thu, 8 Jan 2009 00:49:03 -0800 (PST) Received: from arnor.apana.org.au (rhun.apana.org.au [64.62.148.172]) by core3.amsl.com (Postfix) with ESMTP id A0D7628C0F4 for ; Thu, 8 Jan 2009 00:49:02 -0800 (PST) Received: from gondolin.me.apana.org.au ([192.168.0.6]) by arnor.apana.org.au with esmtp (Exim 4.63 #1 (Debian)) id 1LKqZK-0002l0-D1; Thu, 08 Jan 2009 19:48:46 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.69) (envelope-from ) id 1LKqZF-0001A5-W9; Thu, 08 Jan 2009 19:48:42 +1100 Date: Thu, 8 Jan 2009 19:48:41 +1100 From: Herbert Xu To: Tero Kivinen Message-ID: <20090108084841.GA4390@gondor.apana.org.au> References: <20081218215625.GA1070@gondor.apana.org.au> <18767.36828.648842.596858@fireball.kivinen.iki.fi> <20081222223506.GA7267@gondor.apana.org.au> <18768.48999.480981.798652@fireball.kivinen.iki.fi> <20081223110512.GA12092@gondor.apana.org.au> <18776.50975.768573.828996@fireball.kivinen.iki.fi> <20081230030652.GA15620@gondor.apana.org.au> <18781.65278.432552.976452@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <18781.65278.432552.976452@fireball.kivinen.iki.fi> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ipsec@ietf.org Subject: Re: [IPsec] To UDP encapsulate or not 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 Fri, Jan 02, 2009 at 01:48:14PM +0200, Tero Kivinen wrote: > > If sender side is MUST NOT and server side is MAY/SHOULD/MUST be able > to process regardless of encoding, that still means that all complient > implementations can communicate with each other. It also means that > non-complient implementations (which violate the first MUST NOT) may > be able to communicate with the complient implementations (if they do > follow the MUST be able to process part). > > That way does give us maximum interoperability. Sure, I can live with MUST NOT for the sender and MAY/SHOULD for the receiver. I don't think MUST makes any sense for the receiver if we maintain MUST NOT on the sender. > Can you explain that case once more, with proper examples, as I have > not seen such case, where two implementations following the "MUST NOT" > for both sender and recipient would be able to communicate, but where > the two implementations where the sender follows MUST NOT and > recipient follows "MUST be able to process" cannot communicate. You've lost me, we currently don't have anything that says MUST NOT for the sender. > Nothing in the currnt draft says complient implementation would be > allowed to send UDP encapsulatated packets when NAT is not detected. > Can you point me to that text? Last time I checked just because something isn't in the RFC doesn't mean that it's forbidden. Moreover, the current draft has added a statement which implies that doing this will work by requiring all receivers to accept them. > Now you lost me again. Current solution is to be silent whether such > is allowed or not in both sender and recipient part. Being silent means leaving things in the hands of the implementor. As I said, the current draft may lead to implementations that are unable to interoperate. > There is nothing we can do for that, we can only go around the NAT box > after we have been able to detect whether such exists or not. Before > that is done we cannot go around it... We could of course drop all What you can do is continue to stick with the original decision. That is, if you started out with encapsulation then continue to use it, if you started out without encapsulation then continue to that until the address change negotiation decides otherwise. > > In other words, allowing UDP encapsulation mismatches have made > > the IPsec specification worse while it's only making MOBIKE slightly > > better. > > I disagree on that. Great, I agree that we disagree :) > Hmm... haven't really seen such firewalls, and such firewalls would > not be following the IPsec architecture, as the ESP flow is identified > by the SPI and dst-address. Source address might not be part of the > flow (for example for multicast traffic). This is a standard configuration on any stateful firewall which is not IPsec-aware. For instance, the Linux connection tracking system treats ESP packets as generic IP packets and the only information used to establish flows are the src/dst addresses. Many commercial firewall devices operate in the same way. > I have seen lots of NATs trying to do that, i.e. they see ESP packet Note that I'm talking about firewalls, not NAT. Everything I've stated so far applies equally to IPv4 and IPv6. > I would myself consider such firewall broken and get proper firewall > instead. I think we should discourage firewall vendors for making such > assumptions which are not valid based on the IPsec architecture. The problem is not IPsec-aware firewalls, it's stateful firewalls that know nothing about IPsec. Making every firewall on the Internet IPsec-aware is impossible. That's why the NAT-T protocol was invented in the first place. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 8 12:31:15 2009 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 DDDCC3A6937; Thu, 8 Jan 2009 12:31:15 -0800 (PST) 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 A562F3A6937 for ; Thu, 8 Jan 2009 12:31:14 -0800 (PST) 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 y5W7dMfga8IO for ; Thu, 8 Jan 2009 12:31:14 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id D20D73A6822 for ; Thu, 8 Jan 2009 12:31:13 -0800 (PST) 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 n08KUuqL018829 for ; Thu, 8 Jan 2009 15:30:56 -0500 Received: from apache by webmail.nist.gov with local (Exim 4.63) (envelope-from ) id 1LL1Wq-0005cK-Kv for ipsec@ietf.org; Thu, 08 Jan 2009 15:30:56 -0500 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, 08 Jan 2009 15:30:56 -0500 Message-ID: <20090108153056.67034rzcvccp75vk@webmail.nist.gov> Date: Thu, 08 Jan 2009 15:30:56 -0500 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] IPsec Roadmap 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-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 The Roadmap doc was announced earlier this week: IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-roadmap-00.txt We would appreciate comments, corrections and suggestions, in particular: - missing RFCs - additional topics or background material needed - level of detail in RFC descriptions: too little? too much? just right? In addition, we would appreciate if people would review the Requirements Levels for the cryptographic algorithms, and let us know if anyone disagrees. Sheila and Suresh _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 8 13:07:08 2009 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 62D133A69E2; Thu, 8 Jan 2009 13:07:08 -0800 (PST) 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 3626B3A69D1 for ; Thu, 8 Jan 2009 13:07:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 yDt3yUKYESsJ for ; Thu, 8 Jan 2009 13:07:06 -0800 (PST) Received: from ins1.sd.spawar.navy.mil (ins1.sd.spawar.navy.mil [IPv6:2001:480:10:4::2]) by core3.amsl.com (Postfix) with ESMTP id 9F21E3A6957 for ; Thu, 8 Jan 2009 13:07:05 -0800 (PST) Received: from pescado.nosc.mil (pescado.nosc.mil [128.49.4.90]) by ins1.sd.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id n08L6mTj008070 for ; Thu, 8 Jan 2009 13:06:48 -0800 Received: from [127.0.0.1] (alderon.sd.spawar.navy.mil [128.49.162.148]) by pescado.nosc.mil (Netscape Messaging Server 4.15) with ESMTP id KD67ZC00.JIO; Thu, 8 Jan 2009 13:06:48 -0800 Message-ID: <49666ADC.6030802@nkiconsulting.com> Date: Thu, 08 Jan 2009 13:06:36 -0800 From: Robert Stangarone User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Sheila Frankel References: <20090108153056.67034rzcvccp75vk@webmail.nist.gov> In-Reply-To: <20090108153056.67034rzcvccp75vk@webmail.nist.gov> Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec Roadmap 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Sheila, You might consider including references to RObust Header Compression (ROHC)(RFCs3095,4995,5225). The IETF ROHC WG is in the last call stages for 3 documents that provide specification for the use of ROHC within IPsec tunnels. http://www.ietf.org/internet-drafts/draft-ietf-rohc-hcoipsec-09.txt http://www.ietf.org/internet-drafts/draft-ietf-rohc-ikev2-extensions-hcoipsec-07.txt http://www.ietf.org/internet-drafts/draft-ietf-rohc-ipsec-extensions-hcoipsec-03.txt Cheers, Bob _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-337@ccp.com.au Thu Jan 8 13:39:35 2009 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 159C53A67A3 for ; Thu, 8 Jan 2009 13:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -64.344 X-Spam-Level: X-Spam-Status: No, score=-64.344 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_H_CANADIAN=0.5, GB_H_PHARMACY=1, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_MISMATCH_COM=0.553, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_SBL=20, 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 HNluxgom5avC for ; Thu, 8 Jan 2009 13:39:28 -0800 (PST) Received: from mta.email.webmd.com (unknown [195.244.133.184]) by core3.amsl.com (Postfix) with SMTP id B66503A67F8 for ; Thu, 8 Jan 2009 13:39:26 -0800 (PST) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Message-Id: <20090108133911.6967.qmail@mta.email.webmd.com> From: "Doctor Monte" To: ipsec-archive@lists.ietf.org Subject: RE: (Canadian Pharmacy Message) Girls want it hard as stone MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Thu, 8 Jan 2009 13:39:26 -0800 (PST) evi.WebMD - Daily Newsletter.dfvl
WebMD Daily Thu, 8 Jan 2009 11:39:11 +0200
You are subscribed as ipsec-archive@lists.ietf.org.
View and manage your WebMD newsletter preferences.
Subscribe to more newsletters. Change/update your email address.
To unsubscribe from this WebMD Daily newsletter, send a blank email to: no_daily@health.webmd.com.
To unsubscribe from ALL WebMD Health newsletters, send a blank email to: unsub@health.webmd.com.
WebMD Privacy Policy
WebMD Office of Privacy
1175 Peachtree Street, Suite 2400, Atlanta, GA 30361
© 2009 WebMD, LLC. All rights reserved.

From ipsec-bounces@ietf.org Fri Jan 9 14:53:57 2009 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 1925128C126; Fri, 9 Jan 2009 14:53:57 -0800 (PST) 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 0F2803A6A50 for ; Fri, 9 Jan 2009 14:53:56 -0800 (PST) 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 t6UJKG1Vm+SD for ; Fri, 9 Jan 2009 14:53:55 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id EAEB33A6923 for ; Fri, 9 Jan 2009 14:53:54 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n09MqMB8005300 for ; Fri, 9 Jan 2009 17:52:22 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n09MreOB196694 for ; Fri, 9 Jan 2009 17:53:40 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n09Mqr8n010526 for ; Fri, 9 Jan 2009 17:52:53 -0500 Received: from d01mc084.pok.ibm.com (d01mc084.pok.ibm.com [9.63.9.226]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n09MqrvR010523 for ; Fri, 9 Jan 2009 17:52:53 -0500 To: ipsec@ietf.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Fri, 9 Jan 2009 17:53:39 -0500 X-MIMETrack: Serialize by Router on D01MC084/01/M/IBM(Release 8.0.1|February 07, 2008) at 01/09/2009 17:53:39 MIME-Version: 1.0 Subject: [IPsec] Verification check for ID_DER_ASN1_DN IDs 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="===============1135720456==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1135720456== Content-type: multipart/alternative; Boundary="0__=0ABBFFAADFE881E68f9e8a93df938690918c0ABBFFAADFE881E6" Content-Disposition: inline --0__=0ABBFFAADFE881E68f9e8a93df938690918c0ABBFFAADFE881E6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Sections 3.1.1 through 3.1.3 of RFC 4945 state that "Implementations MA= Y provide a configuration option to (i.e., local policy configuration can= enable) skip that verification step, but that option MUST be off by default." This statement is made with regard to the requirement of verifying that the ID provided in an ID payload matches the contents of= the subjectAlt name in the certificate presented, Section 3.1.5 of RFC 4945 states that. "implementations MUST populate t= he contents of ID with the Subject field from the end-entity certificate, = and MUST do so such that a binary comparison of the two will succeed. If t= here is not a match, this MUST be treated as an error, and security associat= ion setup MUST be aborted." This statement is made with regard to the requirement of verifying that the ID provided in a ID payload matches t= he Subject field of the certificate presented, There is no text indicati= ng that implementations MAY provide a configuration option to skip that verification step. Was this an oversight or was there a reason to disa= llow such a configuration option when the ID payload is of type ID_DER_ASN1_= DN? It seems as if the check for ID_IPV4_ADDR, ID_IPV6_ADDR, ID_FQDN, and I= D USER_FQDN is optional that the check for ID_DER_ASN1_DN should also be optional. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 = --0__=0ABBFFAADFE881E68f9e8a93df938690918c0ABBFFAADFE881E6 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Sections 3.1.1 through 3.1.3 of RFC 4945 state that "Implementa= tions MAY provide a configuration option to (i.e., local policy configu= ration can enable) skip that verification step, but that option MUST be= off by default." This statement is made with regard to the requi= rement of verifying that the ID provided in an ID payload matches the c= ontents of the subjectAlt name in the certificate presented,

Section 3.1.5 of RFC 4945 states that. "implementations MUST popul= ate the contents of ID with the Subject field from the end-entity certi= ficate, and MUST do so such that a binary comparison of the two will s= ucceed. If there is not a match, this MUST be treated as an error, and= security association setup MUST be aborted." This statement is m= ade with regard to the requirement of verifying that the ID provided in= a ID payload matches the Subject field of the certificate presented, = There is no text indicating that implementations MAY provide a configu= ration option to skip that verification step. Was this an oversight or= was there a reason to disallow such a configuration option when the ID= payload is of type ID_DER_ASN1_DN?

It seems as if the check for ID_IPV4_ADDR, ID_IPV6_ADDR, ID_FQDN, and I= D USER_FQDN is optional that the check for ID_DER_ASN1_DN should also b= e optional.





Dave Wierbowski


z/OS Comm Server Developer

Phone:
Tie line: 620-4055
External: 607-429-4055


= --0__=0ABBFFAADFE881E68f9e8a93df938690918c0ABBFFAADFE881E6-- --===============1135720456== 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 --===============1135720456==-- From mctiffin@alexander-kreis.de Fri Jan 9 18:19:14 2009 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 398713A69E3 for ; Fri, 9 Jan 2009 18:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -40.201 X-Spam-Level: X-Spam-Status: No, score=-40.201 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93LZTV2dbPzQ for ; Fri, 9 Jan 2009 18:19:13 -0800 (PST) Received: from cable201-233-26-17.epm.net.co (cable201-233-26-17.epm.net.co [201.233.26.17]) by core3.amsl.com (Postfix) with SMTP id 086D83A63D3 for ; Fri, 9 Jan 2009 18:19:09 -0800 (PST) To: Subject: Re: Order status 69441 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090110021911.086D83A63D3@core3.amsl.com> Date: Fri, 9 Jan 2009 18:19:09 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 50912
From mauricio.alcalde.pa@allianz.es Sat Jan 10 02:20:21 2009 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 225843A6AD3 for ; Sat, 10 Jan 2009 02:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -35.936 X-Spam-Level: X-Spam-Status: No, score=-35.936 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_DSN=1.495, GB_I_LETTER=-2, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2332s3IRe0P for ; Sat, 10 Jan 2009 02:20:20 -0800 (PST) Received: from ip-122-252.zirzile.lt (ip-122-252.zirzile.lt [84.32.122.252]) by core3.amsl.com (Postfix) with SMTP id 456643A6A7A for ; Sat, 10 Jan 2009 02:20:18 -0800 (PST) To: Subject: Re: Order status 44766 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090110102019.456643A6A7A@core3.amsl.com> Date: Sat, 10 Jan 2009 02:20:18 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 20402
From murofusi@access.co.jp Sun Jan 11 03:46:09 2009 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 B37373A6993 for ; Sun, 11 Jan 2009 03:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.071 X-Spam-Level: X-Spam-Status: No, score=-32.071 tagged_above=-999 required=5 tests=[AWL=-4.673, BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT8-704dTuHf for ; Sun, 11 Jan 2009 03:46:08 -0800 (PST) Received: from afjrotc.net (unknown [121.247.42.59]) by core3.amsl.com (Postfix) with SMTP id 775FB3A6991 for ; Sun, 11 Jan 2009 03:46:06 -0800 (PST) To: Subject: RE: Message 15460 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090111114607.775FB3A6991@core3.amsl.com> Date: Sun, 11 Jan 2009 03:46:06 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 54190
From ljonesd@ag.auburn.edu Sun Jan 11 14:27:19 2009 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 4148E3A6A58 for ; Sun, 11 Jan 2009 14:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DYNAMIC=1.144, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6gSMV+nHJPM for ; Sun, 11 Jan 2009 14:27:18 -0800 (PST) Received: from 189-041-42-112.xd-dynamic.ctbcnetsuper.com.br (189-041-42-112.xd-dynamic.ctbcnetsuper.com.br [189.41.42.112]) by core3.amsl.com (Postfix) with SMTP id 4FED63A6A44 for ; Sun, 11 Jan 2009 14:27:15 -0800 (PST) To: Subject: RE: Message 85091 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090111222716.4FED63A6A44@core3.amsl.com> Date: Sun, 11 Jan 2009 14:27:15 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 84013
From ipsec-bounces@ietf.org Mon Jan 12 04:33:39 2009 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 2D7973A6B5C; Mon, 12 Jan 2009 04:33:39 -0800 (PST) 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 794AA28C114 for ; Mon, 12 Jan 2009 04:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 9g2i-mK9Sg91 for ; Mon, 12 Jan 2009 04:33:37 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 700603A6B5A for ; Mon, 12 Jan 2009 04:33:36 -0800 (PST) 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 n0CCXJj7000116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jan 2009 14:33:19 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0CCXIDk004961; Mon, 12 Jan 2009 14:33:18 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18795.14478.742278.73682@fireball.kivinen.iki.fi> Date: Mon, 12 Jan 2009 14:33:18 +0200 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Cc: ipsec@ietf.org Subject: [IPsec] Verification check for ID_DER_ASN1_DN IDs 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 David Wierbowski writes: > It seems as if the check for ID_IPV4_ADDR, ID_IPV6_ADDR, ID_FQDN, and ID > USER_FQDN is optional that the check for ID_DER_ASN1_DN should also be > optional. If you read the rationale for making the check optional ("We include the "option-to-skip- validation" in order to permit better interoperability, as current implementations vary greatly in how they behave on this topic.") that indicates that those ID_IPV4_ADDR, ID_IPV6_ADDR, ID_FQDN and ID_USER_FQDN do have that problem, but I do not think ID_DER_ASN1_DN has that problem. For ID_DER_ASN1_DN it has been very clear from the beginning how to match that against certificate, so there has not been reason to make check optional. For other types different implementations have done things differently (for example some implementations searched ID_FQDN from CN field of the Subject, not from the dNSName field of the SubjectAltName etc), and because of this it was seen necessary to make it possible to make those those checks optional for such implementations who want to keep backward compatibility for their own old versions. So I do not see reason for making ID_DER_ASN1_DN check optional. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 12 07:38:49 2009 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 146663A6955; Mon, 12 Jan 2009 07:38:49 -0800 (PST) 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 B03F53A6955 for ; Mon, 12 Jan 2009 07:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 154Sfu8RedKx for ; Mon, 12 Jan 2009 07:38:47 -0800 (PST) Received: from exch-one.centrify.com (mail.centrify.com [216.112.107.103]) by core3.amsl.com (Postfix) with ESMTP id 0FE8B3A67D4 for ; Mon, 12 Jan 2009 07:38:46 -0800 (PST) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jan 2009 07:37:25 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: optional SAs Thread-Index: Aclvnm8hapd8N71QR6+Y2mP7oUaeHwFLTwv0 References: From: "Paul Moore" To: Subject: [IPsec] optional SAs 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="===============1845237171==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1845237171== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C974CB.D06A08D2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C974CB.D06A08D2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (Transport mode) Is there a generally accepted requirement for and definition of optional = SAs? Linux has 'use' - this means (as far as i can see) that if racoon can = negotiate an SA then the kernel will use it, otherwise the kernel = behaves as though there was no SPD set and let the traffic flow. Windows has the same thing (I think its the same). But is this individual implementations deciding that this is a nice to = have or is there a spec for it somewhere? Is it a required feature for = conformance? ------_=_NextPart_001_01C974CB.D06A08D2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=

=0A=
(Transport mode)
=0A=
=0A=
=0A=

Is there a generally accepted requirement for and = definition of optional SAs?

=0A=

Linux has 'use' - this means (as far as i can see) = that if racoon can negotiate an SA then the kernel will use it, = otherwise the kernel behaves as though there was no SPD set and let the = traffic flow.

=0A=

Windows has the same thing (I think its the = same).

=0A=

But is this individual implementations deciding = that this is a nice to have or is there a spec for it somewhere? Is it a = required feature for conformance?

------_=_NextPart_001_01C974CB.D06A08D2-- --===============1845237171== 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 --===============1845237171==-- From ipsec-bounces@ietf.org Mon Jan 12 07:57:14 2009 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 4FA0B3A6AEE; Mon, 12 Jan 2009 07:57:14 -0800 (PST) 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 28B7B3A6AEE for ; Mon, 12 Jan 2009 07:57:13 -0800 (PST) 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 G8DLowgoL5mx for ; Mon, 12 Jan 2009 07:57:09 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 2CEF83A6969 for ; Mon, 12 Jan 2009 07:57:09 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0CFusPg023034 for ; Mon, 12 Jan 2009 15:56:55 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 n0CFus72062529 for ; Mon, 12 Jan 2009 10:56:54 -0500 (EST) 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 n0CFf3s8002353; Mon, 12 Jan 2009 10:41:03 -0500 (EST) Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0CFf3xY002352; Mon, 12 Jan 2009 10:41:03 -0500 (EST) X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to danmcd@sun.com using -f Date: Mon, 12 Jan 2009 10:41:03 -0500 From: Dan McDonald To: Paul Moore Message-ID: <20090112154103.GB2327@kebe.East.Sun.COM> References: 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) Cc: ipsec@ietf.org Subject: Re: [IPsec] optional SAs 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 Mon, Jan 12, 2009 at 07:37:25AM -0800, Paul Moore wrote: > Is there a generally accepted requirement for and definition of optional > SAs? I didn't think so, but maybe 4301 has text for it. Another example is 4301's "populate from packet" which is the formalization of the around-since-NRL "Unique SA" concept. > Linux has 'use' - this means (as far as i can see) that if racoon can > negotiate an SA then the kernel will use it, otherwise the kernel behaves > as though there was no SPD set and let the traffic flow. "use" is another NRL-original concept. Such a concept requires cooperation from key management on the initiating/transmitting side (or connection latching once an inbound packet has been accepted), but on the responder/receiving side is straightforward. > But is this individual implementations deciding that this is a nice to have > or is there a spec for it somewhere? Is it a required feature for > conformance? Unless it's been added in 4301, I don't believe it's required. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 12 08:29:13 2009 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 9EC3B28C14A; Mon, 12 Jan 2009 08:29:13 -0800 (PST) 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 8E1B128C316 for ; Mon, 12 Jan 2009 05:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eRQZqXWh0iN for ; Mon, 12 Jan 2009 05:13:57 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id BB80728C133 for ; Mon, 12 Jan 2009 05:13:57 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so4651365ywj.49 for ; Mon, 12 Jan 2009 05:13:42 -0800 (PST) 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=m907cvvABObxLZeHNHE+6OgZ0VO5MSnR8QuRhDig+7s=; b=gyi7nTptTqrAGhf6CrhfkseW6oZRi7jYgEP1CO1WAuUjiFPuQJc80AREuzLBjqr7X1 6kDDFnmhYOr6BVhEFc9IkrUq6NA6+HD0K5WhjkK+DNE+EPEZcHbpyKliKL7gUEsrdg5D g3SNIgdrK2p4MtcXY7zR0pXuP8gFgiiFgPfSU= 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=PSqbC+mfk9t3FVkn3DPY+e1IBfumYIhrEITjmwVok9vB1k98ZRULq54HXQux1Rnx6h Al87Vh0q+FGxTryx2zbvHO7CArYskaVE4EDCavHQG+sUZJ7cn0fEBQ8XPVZOjReIpx4t d82Zw8KrNrxNias0IucwnBVxL4qHajLjj9mLk= Received: by 10.90.100.20 with SMTP id x20mr9009635agb.12.1231766022177; Mon, 12 Jan 2009 05:13:42 -0800 (PST) Received: by 10.90.88.7 with HTTP; Mon, 12 Jan 2009 05:13:42 -0800 (PST) Message-ID: <45c8c21a0901120513jc116934n878143a1a493076d@mail.gmail.com> Date: Mon, 12 Jan 2009 08:13:42 -0500 From: "Richard Graveman" To: kilian.weniger@eu.panasonic.com, vijay@wichorus.com MIME-Version: 1.0 Content-Disposition: inline X-Mailman-Approved-At: Mon, 12 Jan 2009 08:29:12 -0800 Cc: ipsec@ietf.org Subject: [IPsec] question about IKEv2 Re-direct 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 just read this draft and think your idea is useful. I have one question (please excuse me if it's been answered): Is there anything special about VPNs (or MIPv6) that limits the use of this? Could you just say "IKEv2 Initiator" instead of "VPN client" and "IKEv2 Responder" instead of "VPN Gateway" everywhere? I have uses for IKEv2 that are neither VPNs nor MIPv6 and could possibly benefit from this, but the terminology is somewhat constraining. Thanks, Rich Graveman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 12 12:00:30 2009 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 C4D4D3A6B2F; Mon, 12 Jan 2009 12:00:30 -0800 (PST) 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 67CF43A696D for ; Mon, 12 Jan 2009 12:00:29 -0800 (PST) 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 2-jF8Jjlehzg for ; Mon, 12 Jan 2009 12:00:28 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id EFB593A6783 for ; Mon, 12 Jan 2009 12:00:22 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0CJwnKx001055 for ; Mon, 12 Jan 2009 14:58:49 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0CK07Q5196370 for ; Mon, 12 Jan 2009 15:00:07 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0CK07H5007736 for ; Mon, 12 Jan 2009 15:00:07 -0500 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.41.248.175]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0CK07h6007698; Mon, 12 Jan 2009 15:00:07 -0500 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id n0CK06Nh041500; Mon, 12 Jan 2009 14:00:06 -0600 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.14.2/8.12.8) with ESMTP id n0CJxwOv021475; Mon, 12 Jan 2009 13:59:58 -0600 Received: (from jml@localhost) by faith.austin.ibm.com (8.14.2/8.14.2/Submit) id n0CJxwsb021474; Mon, 12 Jan 2009 13:59:58 -0600 X-Authentication-Warning: faith.austin.ibm.com: jml set sender to latten@austin.ibm.com using -f From: Joy Latten To: ipsec@ietf.org Date: Mon, 12 Jan 2009 13:59:57 -0600 Message-Id: <1231790397.5251.40.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-3.fc8) Cc: serue@us.ibm.com, gcwilson@us.ibm.com, tjaeger@cse.psu.edu Subject: [IPsec] IPsec Security Context drafts 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 following IPsec Security Context drafts were announced last week. We would appreciate any comments, suggestions or reviews. Thanks!! regards, Joy http://www.ietf.org/internet-drafts/draft-jml-ipsec-ikev2-security-context-00.txt Filename: draft-jml-ipsec-ikev2-security-context Revision: 00 Title: Security Context Addendum to IPsec Creation_date: 2009-01-08 WG ID: Independent Submission Number_of_pages: 12 Abstract: This document describes the high-level requirements needed within IPsec to support Mandatory Access Control (MAC) on network communications. It describes the extensions to the Security Architecture for the Internet Protocol [RFC4301] and the Internet Key Exchange Protocol Version 2 [RFC4306]. It also describes the negotiation of the security context for a particular Authentication Header (AH) [RFC4302] and/or Encapsulating Security Payload (ESP) [RFC4303] security association. http://www.ietf.org/internet-drafts/draft-jml-ipsec-ikev1-security-context-00.txt Filename: draft-jml-ipsec-ikev1-security-context Revision: 00 Title: draft-jml-ipsec-ikev1-security-context-00 Creation_date: 2009-01-08 WG ID: Independent Submission Number_of_pages: 8 Abstract: This document describes the need for and use of a security context within IPsec. It describes the extension to the Internet IP Security Domain of Interpretation (IPsec DOI) [RFC2407] for the Internet Security Association and Key Management Protocol (ISAKMP) [RFC2408]. This extension supports the negotiation of the security context for a particular IP Authentication Header (AH) [RFC4302] or IP Encapsulating Security Payload (ESP) [RFC4303] security association. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From layne95@3vb.com Mon Jan 12 12:23:24 2009 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 247223A6857 for ; Mon, 12 Jan 2009 12:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.744 X-Spam-Level: X-Spam-Status: No, score=-46.744 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 px+crXpFmQTq for ; Mon, 12 Jan 2009 12:23:23 -0800 (PST) Received: from amoje.com (unknown [200.96.196.228]) by core3.amsl.com (Postfix) with SMTP id 6571F3A6836 for ; Mon, 12 Jan 2009 12:23:19 -0800 (PST) To: Subject: Up to 20% cashback on every purchase? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090112202321.6571F3A6836@core3.amsl.com> Date: Mon, 12 Jan 2009 12:23:19 -0800 (PST)
Microsoft respects your privacy. Please read our online Privacy Statement.

If you would prefer to no longer receive promotional offers or research emails from MSN or Windows Live, please click to "unsubscribe" or reply to this message with "UNSUBSCRIBE" in the subject line. To set your contact preferences for other Microsoft communications, see the communications preferences section of the Privacy Statement.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation One Microsoft Way Redmond, WA 39953
From ljuwtnazaehenson@altria.com Mon Jan 12 19:42:11 2009 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 BD4403A67FF for ; Mon, 12 Jan 2009 19:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.554 X-Spam-Level: X-Spam-Status: No, score=-16.554 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYjp6f-odXvD for ; Mon, 12 Jan 2009 19:42:11 -0800 (PST) Received: from 70-46-189-82.network.fdn.com (70-46-189-82.network.fdn.com [70.46.189.82]) by core3.amsl.com (Postfix) with SMTP id 1DFA93A67AD for ; Mon, 12 Jan 2009 19:42:09 -0800 (PST) To: Subject: RE: mail 78271 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090113034210.1DFA93A67AD@core3.amsl.com> Date: Mon, 12 Jan 2009 19:42:09 -0800 (PST)
Microsoft respects your privacy. Please read our online Privacy Statement.

If you would prefer to no longer receive promotional offers or research emails from MSN or Windows Live, please click to "unsubscribe" or reply to this message with "UNSUBSCRIBE" in the subject line. To set your contact preferences for other Microsoft communications, see the communications preferences section of the Privacy Statement.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation One Microsoft Way Redmond, WA 21505
From ipsec-bounces@ietf.org Tue Jan 13 08:15:38 2009 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 0233D3A6AA5; Tue, 13 Jan 2009 08:15:38 -0800 (PST) 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 5EB2E3A6846 for ; Tue, 13 Jan 2009 08:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=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 mjT9RdsjYTzK for ; Tue, 13 Jan 2009 08:15:35 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8A7553A6ABC for ; Tue, 13 Jan 2009 08:15:34 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4CA4929C002; Tue, 13 Jan 2009 18:15:19 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 68BFE29C001; Tue, 13 Jan 2009 18:14:48 +0200 (IST) X-CheckPoint: {496CBBCA-10000-88241DC2-7B6} 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 n0DGElfE028832; Tue, 13 Jan 2009 18:14:47 +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, 13 Jan 2009 18:14:47 +0200 From: Yaron Sheffer To: "sheila.frankel@nist.gov" , "suresh.krishnan@ericsson.com" Date: Tue, 13 Jan 2009 18:14:47 +0200 Thread-Topic: Comments on draft-ietf-ipsecme-roadmap-00 Thread-Index: Acl1mg2947x9TTILSQ2WswWjM2XZkQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7@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: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 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="===============1940007859==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1940007859== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7ilex01adcheck_" --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sheila, Suresh, Overall, this is a very impressive document, both clear and extensive. Than= ks so much! Here are some comments, and some suggested text. Everyone on the list is mo= st welcome to suggest text for their favorite RFCs. - 2.1: I suggest to unify the 3 Algorithm boxes in the figure into one, "Al= gorithms". There are also documents describing HMAC, and describing D-H gro= ups. - 2.2: for the "earlier version", please mention the RFC numbers (1825-1829= ). - 2.2.1: but in IPsec-v3 you still need the dest address to distinguish SAs= , e.g. if you're on a gateway. - 2.3.1: why use the older term "IPsec SA", instead of the newer "Child SA"= ? - 2.3.1: I think the incorporation of EAP is important enough to be on the = list of changes. - 2.4: suggest to remove the last 3 bullets, which are way outside the core= IPsec. - 3.2: RFC 3585, please add "this RFC has not been widely adopted". Similar= ly (AFAIK) for RFC 4807 in Sec. 3.3, and RFC 3884 in Sec. 3.4. - 3.4: suggested blurb for draft-ietf-ipsecme-traffic-visibility: ESP, as defined [RFC4303], does not allow a network device to easily determ= ine whether protected traffic that is passing through the device is encrypt= ed, or only integrity-protected. This document extends ESP to provide expli= cit notification of integrity-protected packets, and extends IKEv2 to negot= iate this capability between the IPsec peers. - 4.1.1: I suggest to add the following introductory paragraph. While historically IKEv1 was created by combining two security protocols, I= SAKMP and Oakley, in practice the combination (along with the IPsec DOI) ha= s commonly been viewed as one protocol, IKEv1. The protocol's origins can b= e seen in the organization of the documents that define it. - 4.1.2: suggested blurb for Bis: This document combines the original IKEv2 RFC with the Clarifications, and = resolves many implementation issues discovered by the community since the p= ublication of these two documents. - 4.2.3: the section number appears twice! - 4.2.3: DPD: mention that in IKEv2 this has been incorporated into the pro= tocol. - 5: typo: SA}s - 5.1: the note that claims "by inference" that RFC 4835 applies to IPsec-v= 2 seems debatable to me, in view of Sec. 6 of that document. - 5.2: I have an issue with the distinction we're making between stream cip= hers and block ciphers. We should not be sending the message that integrity= protection can be sometimes omitted. - 5.3: just because we don't like HMAC-MD5, this is no reason not to cover = RFC 2403. Moreover, it is still a MAY in RFC 4835, which also says, "Weakne= sses have become apparent in MD5 [MD5-COLL]; however, these should not affe= ct the use of MD5 with HMAC". - 5.4: please add an introductory note explaining combined algorithms. - 5.5: similarly, please add an introductory note explaining pseudo-random = functions. - 5.7: SMIME =3D> S/MIME. And you probably meant TLS/SSL, not SSH. - 7.4: we should point out that there are no known KINK implementations (AF= AIK). - 7.5: similarly, are there any implementations of DHCP as described in RFC= 3456? - 7.6: and IPsecKEY, too. Thanks, Yaron =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sheila, Suresh,

 

Overall, this is a very impressive document, both clear = and extensive. Thanks so much!

 

Here are some comments, and some suggested text. Everyon= e on the list is most welcome to suggest text for their favorite RFCs.

 

- 2.1: I suggest to unify the 3 Algorithm boxes in the figure into one, "Algorithms". There are also documents describin= g HMAC, and describing D-H groups.

- 2.2: for the "earlier version", please menti= on the RFC numbers (1825-1829).

- 2.2.1: but in IPsec-v3 you still need the dest address= to distinguish SAs, e.g. if you're on a gateway.

- 2.3.1: why use the older term "IPsec SA", in= stead of the newer "Child SA"?

- 2.3.1: I think the incorporation of EAP is important enough to be on the list of changes.

- 2.4: suggest to remove the last 3 bullets, which are w= ay outside the core IPsec.

- 3.2: RFC 3585, please add "this RFC has not been widely adopted". Similarly (AFAIK) for RFC 4807 in Sec. 3.3, and RFC 3= 884 in Sec. 3.4.

- 3.4: suggested blurb for draft-ietf-ipsecme-traffic-vi= sibility:

 

ESP, as defined [RFC4303], does not allow a network devi= ce to easily determine whether protected traffic that is passing through the device is encrypted, or only integrity-protected. This document extends ESP= to provide explicit notification of integrity-protected packets, and extends I= KEv2 to negotiate this capability between the IPsec peers.

 

- 4.1.1: I suggest to add the following introductory paragraph.

 

While historically IKEv1 was created by combining two security protocols, ISAKMP and Oakley, in practice the combination (along w= ith the IPsec DOI) has commonly been viewed as one protocol, IKEv1. The protoco= l's origins can be seen in the organization of the documents that define it.

 

- 4.1.2: suggested blurb for Bis:

 

This document combines the original IKEv2 RFC with the Clarifications, and resolves many implementation issues discovered by the community since the publication of these two documents.

 

- 4.2.3: the section number appears twice!

- 4.2.3: DPD: mention that in IKEv2 this has been incorporated into the protocol.

- 5: typo: SA}s

- 5.1: the note that claims "by inference" tha= t RFC 4835 applies to IPsec-v2 seems debatable to me, in view of Sec. 6 of th= at document.

- 5.2: I have an issue with the distinction we're making between stream ciphers and block ciphers. We should not be sending the mess= age that integrity protection can be sometimes omitted.

- 5.3: just because we don't like HMAC-MD5, this is no reason not to cover RFC 2403. Moreover, it is still a MAY in RFC 4835, whic= h also says, "Weaknesses have become apparent in MD5 [MD5-COLL]; however= , these should not affect the use of MD5 with HMAC".<= /p>

- 5.4: please add an introductory note explaining combin= ed algorithms.

- 5.5: similarly, please add an introductory note explai= ning pseudo-random functions.

- 5.7: SMIME =3D> S/MIME. And you probably meant TLS/= SSL, not SSH.

- 7.4: we should point out that there are no known KINK implementations (AFAIK).

- 7.5: similarly, are there any implementations of DHCP = as described in RFC 3456?

- 7.6: and IPsecKEY, too.

 

Thanks,

         &n= bsp;  Yaron


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7ilex01adcheck_-- --===============1940007859== 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 --===============1940007859==-- From majordomo@aehomebuilders.com Tue Jan 13 08:44:23 2009 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 BFC873A6A62 for ; Tue, 13 Jan 2009 08:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.165 X-Spam-Level: X-Spam-Status: No, score=-25.165 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_FR=0.35, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhF-+DkBdphg for ; Tue, 13 Jan 2009 08:44:23 -0800 (PST) Received: from advantech.fr (unknown [189.139.161.77]) by core3.amsl.com (Postfix) with SMTP id 298043A6944 for ; Tue, 13 Jan 2009 08:44:20 -0800 (PST) To: Subject: Up to 20% cashback on every purchase? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090113164422.298043A6944@core3.amsl.com> Date: Tue, 13 Jan 2009 08:44:20 -0800 (PST)
Microsoft respects your privacy. Please read our online Privacy Statement.

If you would prefer to no longer receive promotional offers or research emails from MSN or Windows Live, please click to "unsubscribe" or reply to this message with "UNSUBSCRIBE" in the subject line. To set your contact preferences for other Microsoft communications, see the communications preferences section of the Privacy Statement.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation One Microsoft Way Redmond, WA 37983
From ipsec-bounces@ietf.org Tue Jan 13 08:47:46 2009 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 232433A6A62; Tue, 13 Jan 2009 08:47:46 -0800 (PST) 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 0C2363A69F2 for ; Tue, 13 Jan 2009 08:47:45 -0800 (PST) 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=[AWL=-0.000, 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 JT9nVoqIbwzL for ; Tue, 13 Jan 2009 08:47:44 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id ED4313A6907 for ; Tue, 13 Jan 2009 08:47:43 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0DGkY9d019783 for ; Tue, 13 Jan 2009 09:46:34 -0700 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 n0DGlHpF166652 for ; Tue, 13 Jan 2009 09:47:20 -0700 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 n0DGlGDc016233 for ; Tue, 13 Jan 2009 09:47:16 -0700 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 n0DGlGN5016215 for ; Tue, 13 Jan 2009 09:47:16 -0700 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 90A64FC9:C2315336-8525753D:0058BCA5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/13/2009 11:42:03 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/13/2009 11:42:03 AM, Serialize complete at 01/13/2009 11:42:03 AM, S/MIME Sign failed at 01/13/2009 11:42:03 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 01/13/2009 09:47:15, Serialize complete at 01/13/2009 09:47:15 Message-ID: Date: Tue, 13 Jan 2009 11:47:15 -0500 Subject: [IPsec] Question on the use of a raw RSA key 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="===============0049875473==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0049875473== Content-Type: multipart/alternative; boundary="=_alternative 005BBDC78525753D_=" This is a multipart message in MIME format. --=_alternative 005BBDC78525753D_= Content-Type: text/plain; charset="US-ASCII" RFC 4306 documents the use of a raw RSA key, but neither it nor RFC 4301 make prescriptions about its use for authentication. If an IKEv2 implementation expects its peer to sign using a raw RSA key, is it expected that the implementation would configure on the PAD entry the expected public-key value for the peer (or a hash of the public-key value), and enforce that the key used matched the expected key? I think this is indirectly implied by the following MUST in RFC 4945, but I wonder if it would be good for us to make it more explicit in ikev2bis: Because implementations may use ID as a lookup key to determine which policy to use, all implementations MUST be especially careful to verify the truthfulness of the contents by verifying that they correspond to some keying material demonstrably held by the peer. Perhaps we could recommend that either the expected public key is explicitly configured on the PAD entry, or else allow for some sort of operator-intervention behavior as is commonly done with SSH and new or changed keys to be stored in known_hosts. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen --=_alternative 005BBDC78525753D_= Content-Type: text/html; charset="US-ASCII"
RFC 4306 documents the use of a raw RSA key, but neither it nor RFC 4301 make prescriptions about its use for authentication.  If an IKEv2 implementation expects its peer to sign using a raw RSA key, is it expected that the implementation would configure on the PAD entry the expected public-key value for the peer (or a hash of the public-key value), and enforce that the key used matched the expected key?

I think this is indirectly implied by the following MUST in RFC 4945, but I wonder if it would be good for us to make it more explicit in ikev2bis:

   Because implementations may use ID as a lookup key to determine which
   policy to use, all implementations MUST be especially careful to
   verify the truthfulness of the contents by verifying that they
   correspond to some keying material demonstrably held by the peer.

Perhaps we could recommend that either the expected public key is explicitly configured on the PAD entry, or else allow for some sort of operator-intervention behavior as is commonly done with SSH and new or changed keys to be stored in known_hosts.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen --=_alternative 005BBDC78525753D_=-- --===============0049875473== 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 --===============0049875473==-- From ipsec-bounces@ietf.org Tue Jan 13 09:00:54 2009 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 B69B83A69A6; Tue, 13 Jan 2009 09:00:54 -0800 (PST) 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 76D693A6ABC for ; Tue, 13 Jan 2009 09:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=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 Rxt8y5mqLkHN for ; Tue, 13 Jan 2009 09:00:52 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 56F7B3A69A6 for ; Tue, 13 Jan 2009 09:00:52 -0800 (PST) Received: from navigation.nist.gov (st7.ncsl.nist.gov [129.6.54.64]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n0DH0L1r007538; Tue, 13 Jan 2009 12:00:21 -0500 Message-Id: <7.0.1.0.2.20090113115924.025b4de0@nist.gov> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 13 Jan 2009 12:00:19 -0500 To: Yaron Sheffer , "suresh.krishnan@ericsson.com" From: Sheila Frankel In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7@il-ex01.ad.chec kpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7@il-ex01.ad.checkpoint.com> Mime-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 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 Thank you for your comments, Yaron. We'll incorporate them into the doc. Regards, Sheila At 11:14 AM 1/13/2009, Yaron Sheffer wrote: >Hi Sheila, Suresh, > >Overall, this is a very impressive document, both clear and >extensive. Thanks so much! > >Here are some comments, and some suggested text. Everyone on the >list is most welcome to suggest text for their favorite RFCs. > >- 2.1: I suggest to unify the 3 Algorithm boxes in the figure into >one, "Algorithms". There are also documents describing HMAC, and >describing D-H groups. >- 2.2: for the "earlier version", please mention the RFC numbers (1825-1829). >- 2.2.1: but in IPsec-v3 you still need the dest address to >distinguish SAs, e.g. if you're on a gateway. >- 2.3.1: why use the older term "IPsec SA", instead of the newer "Child SA"? >- 2.3.1: I think the incorporation of EAP is important enough to be >on the list of changes. >- 2.4: suggest to remove the last 3 bullets, which are way outside >the core IPsec. >- 3.2: RFC 3585, please add "this RFC has not been widely adopted". >Similarly (AFAIK) for RFC 4807 in Sec. 3.3, and RFC 3884 in Sec. 3.4. >- 3.4: suggested blurb for draft-ietf-ipsecme-traffic-visibility: > >ESP, as defined [RFC4303], does not allow a network device to easily >determine whether protected traffic that is passing through the >device is encrypted, or only integrity-protected. This document >extends ESP to provide explicit notification of integrity-protected >packets, and extends IKEv2 to negotiate this capability between the >IPsec peers. > >- 4.1.1: I suggest to add the following introductory paragraph. > >While historically IKEv1 was created by combining two security >protocols, ISAKMP and Oakley, in practice the combination (along >with the IPsec DOI) has commonly been viewed as one protocol, IKEv1. >The protocol's origins can be seen in the organization of the >documents that define it. > >- 4.1.2: suggested blurb for Bis: > >This document combines the original IKEv2 RFC with the >Clarifications, and resolves many implementation issues discovered >by the community since the publication of these two documents. > >- 4.2.3: the section number appears twice! >- 4.2.3: DPD: mention that in IKEv2 this has been incorporated into >the protocol. >- 5: typo: SA}s >- 5.1: the note that claims "by inference" that RFC 4835 applies to >IPsec-v2 seems debatable to me, in view of Sec. 6 of that document. >- 5.2: I have an issue with the distinction we're making between >stream ciphers and block ciphers. We should not be sending the >message that integrity protection can be sometimes omitted. >- 5.3: just because we don't like HMAC-MD5, this is no reason not to >cover RFC 2403. Moreover, it is still a MAY in RFC 4835, which also >says, "Weaknesses have become apparent in MD5 [MD5-COLL]; however, >these should not affect the use of MD5 with HMAC". >- 5.4: please add an introductory note explaining combined algorithms. >- 5.5: similarly, please add an introductory note explaining >pseudo-random functions. >- 5.7: SMIME => S/MIME. And you probably meant TLS/SSL, not SSH. >- 7.4: we should point out that there are no known KINK >implementations (AFAIK). >- 7.5: similarly, are there any implementations of DHCP as described >in RFC 3456? >- 7.6: and IPsecKEY, too. > >Thanks, > Yaron > > >Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 13 09:34:37 2009 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 EA40A28C191; Tue, 13 Jan 2009 09:34:36 -0800 (PST) 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 C867828C16F for ; Tue, 13 Jan 2009 09:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 DXBgLHL0hTe9 for ; Tue, 13 Jan 2009 09:34:35 -0800 (PST) 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 C80D93A67E2 for ; Tue, 13 Jan 2009 09:34:34 -0800 (PST) Received: from [10.20.30.158] (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 n0DHYGWK007040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Jan 2009 10:34:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18763.31814.743812.266472@fireball.kivinen.iki.fi> References: <18763.31814.743812.266472@fireball.kivinen.iki.fi> Date: Tue, 13 Jan 2009 09:34:15 -0800 To: ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] Redirect draft and REDIRECT_ACK notify 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 Yaron (without his co-chair hat on) has an opinion, and so does Tero; these two opinions are quite different technically. However, we are not hearing enough opinions on the list. I don't really care whether Yaron's opinion or Tero's gets WG consensus, but I do care if there is so little interest in this that they are not reading what is likely to be the first RFC out of this WG. The two choices so far are to include a NOTIFY in the response or to use a separate Informational exchange. I think there is agreement that they would both have the same semantics, but they are done quite differenty. If you have an opinion, please comment on the thread and state why you prefer a NOTIFY or a separate exchange. If you have thought about it and you truly don't care, please say that as well. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 13 12:20:16 2009 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 D76B43A6950; Tue, 13 Jan 2009 12:20:16 -0800 (PST) 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 DAD1B3A68DD for ; Tue, 13 Jan 2009 12:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.010, 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 B0oBWMAK4PXS for ; Tue, 13 Jan 2009 12:20:15 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 72BA53A6950 for ; Tue, 13 Jan 2009 12:20:14 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C518A29C005; Tue, 13 Jan 2009 22:19:58 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6E7A429C003; Tue, 13 Jan 2009 22:19:57 +0200 (IST) X-CheckPoint: {496CF53E-10000-88241DC2-7B6} Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id n0DKJvfF027115; Tue, 13 Jan 2009 22:19:57 +0200 (IST) Message-Id: <8FD12AB3-E7F1-453B-873D-212B56D3E1AA@checkpoint.com> From: Yoav Nir To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7@il-ex01.ad.checkpoint.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 13 Jan 2009 22:19:49 +0200 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7@il-ex01.ad.checkpoint.com> X-Mailer: Apple Mail (2.930.3) Cc: "ipsec@ietf.org" , "suresh.krishnan@ericsson.com" , "sheila.frankel@nist.gov" Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 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="===============0736951301==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0736951301== Content-Type: multipart/alternative; boundary=Apple-Mail-2-167718684 --Apple-Mail-2-167718684 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Yaron, Two comments about your comments. On Jan 13, 2009, at 6:14 PM, Yaron Sheffer wrote: > Hi Sheila, Suresh, > > - 2.3.1: why use the older term "IPsec SA", instead of the newer > "Child SA"? A child SA is not the same as an IPsec SA, so the latter term is not deprecated. A child SA is an SA that is created from the IKE SA and could be an IPsec SA, an IKE SA or something that we haven't yet defined. Note that in IKEv2 the way to rekey an IKE SA is through a Create Child SA exchange, so the new IKE SA is also a child SA. > > - 7.4: we should point out that there are no known KINK > implementations (AFAIK). Not so. Racoon2 supports KINK as well as both versions of IKE. Yoav Email secured by Check Point --Apple-Mail-2-167718684 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Yaron, 

Two comments about your = comments.

On Jan 13, 2009, at 6:14 PM, Yaron = Sheffer wrote:

Hi = Sheila, Suresh,

<snip/><= /div>

- = 2.3.1: why use the older term "IPsec SA", instead of the newer "Child = SA"?

A = child SA is not the same as an IPsec SA, so the latter term is not = deprecated. A child SA is an SA that is created from the IKE SA and = could be an IPsec SA, an IKE SA or something that we haven't yet = defined. Note that in IKEv2 the way to rekey an IKE SA is through a = Create Child SA exchange, so the new IKE SA is also a child = SA.

<snip/>

- 7.4: we should point out that there are no = known KINK implementations = (AFAIK).

Not so. Racoon2 supports KINK as well as both versions of = IKE.

Yoav

= =0D=0A
Email secured by Check Point=0D=0A

= = --Apple-Mail-2-167718684-- --===============0736951301== 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 --===============0736951301==-- From ipsec-bounces@ietf.org Tue Jan 13 12:20:48 2009 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 628783A6B1A; Tue, 13 Jan 2009 12:20:48 -0800 (PST) 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 DC8313A6B19 for ; Tue, 13 Jan 2009 12:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.010, 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 TNe98-8nnJoJ for ; Tue, 13 Jan 2009 12:20:46 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 917A13A6AD3 for ; Tue, 13 Jan 2009 12:20:45 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6A6AF29C005; Tue, 13 Jan 2009 22:20:30 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4A92D29C001; Tue, 13 Jan 2009 22:19:47 +0200 (IST) X-CheckPoint: {496CF534-10000-88241DC2-7B6} Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id n0DKJlfF027079; Tue, 13 Jan 2009 22:19:47 +0200 (IST) Message-Id: <69754111-5777-430F-A779-AC5D4FB6F16D@checkpoint.com> From: Yoav Nir To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7@il-ex01.ad.checkpoint.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 13 Jan 2009 22:15:43 +0200 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7@il-ex01.ad.checkpoint.com> X-Mailer: Apple Mail (2.930.3) Cc: "ipsec@ietf.org" , "suresh.krishnan@ericsson.com" , "sheila.frankel@nist.gov" Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 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="===============1103687350==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1103687350== Content-Type: multipart/alternative; boundary=Apple-Mail-1-167472819 --Apple-Mail-1-167472819 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Yaron, Two comments about your comments. On Jan 13, 2009, at 6:14 PM, Yaron Sheffer wrote: > Hi Sheila, Suresh, > > - 2.3.1: why use the older term "IPsec SA", instead of the newer > "Child SA"? A child SA is not the same as an IPsec SA, so the latter term is not deprecated. A child SA is an SA that is created from the IKE SA and could be an IPsec SA, an IKE SA or something that we haven't yet defined. Note that in IKEv2 the way to rekey an IKE SA is through a Create Child SA exchange, so the new IKE SA is also a child SA. > > - 7.4: we should point out that there are no known KINK > implementations (AFAIK). Not so. Racoon2 supports KINK as well as both versions of IKE. Yoav Email secured by Check Point --Apple-Mail-1-167472819 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Yaron, 

Two comments about your = comments.

On Jan 13, 2009, at 6:14 PM, Yaron = Sheffer wrote:

Hi = Sheila, Suresh,

<snip/><= /div>

- = 2.3.1: why use the older term "IPsec SA", instead of the newer "Child = SA"?

A = child SA is not the same as an IPsec SA, so the latter term is not = deprecated. A child SA is an SA that is created from the IKE SA and = could be an IPsec SA, an IKE SA or something that we haven't yet = defined. Note that in IKEv2 the way to rekey an IKE SA is through a = Create Child SA exchange, so the new IKE SA is also a child = SA.

<snip/>

- 7.4: we should point out that there are no = known KINK implementations = (AFAIK).

Not so. Racoon2 supports KINK as well as both versions of = IKE.

Yoav

= =0D=0A
Email secured by Check Point=0D=0A

= = --Apple-Mail-1-167472819-- --===============1103687350== 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 --===============1103687350==-- From ipsec-bounces@ietf.org Tue Jan 13 12:26:05 2009 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 6F2F23A68DD; Tue, 13 Jan 2009 12:26:05 -0800 (PST) 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 6B1E73A68DD for ; Tue, 13 Jan 2009 12:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 DHFvV922yqWX for ; Tue, 13 Jan 2009 12:26:03 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6DEDF3A67F5 for ; Tue, 13 Jan 2009 12:26:03 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 5422829C002; Tue, 13 Jan 2009 22:25:48 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6425129C001; Tue, 13 Jan 2009 22:25:47 +0200 (IST) X-CheckPoint: {496CF69C-10000-88241DC2-7B6} Received: from [172.31.21.177] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n0DKPkfE028370; Tue, 13 Jan 2009 22:25:47 +0200 (IST) Message-Id: <50F98467-2C53-4342-8B5C-C5AF5E4B2BEF@checkpoint.com> From: Yoav Nir To: Paul Hoffman In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 13 Jan 2009 22:25:45 +0200 References: <18763.31814.743812.266472@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.930.3) Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect draft and REDIRECT_ACK notify 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 Jan 13, 2009, at 7:34 PM, Paul Hoffman wrote: > Yaron (without his co-chair hat on) has an opinion, and so does > Tero; these two opinions are quite different technically. However, > we are not hearing enough opinions on the list. I don't really care > whether Yaron's opinion or Tero's gets WG consensus, but I do care > if there is so little interest in this that they are not reading > what is likely to be the first RFC out of this WG. > > The two choices so far are to include a NOTIFY in the response or to > use a separate Informational exchange. I think there is agreement > that they would both have the same semantics, but they are done > quite differenty. > > If you have an opinion, please comment on the thread and state why > you prefer a NOTIFY or a separate exchange. If you have thought > about it and you truly don't care, please say that as well. > > --Paul Hoffman, Director > --VPN Consortium I think that we don't need a REDIRECT_ACK, since the client cannot reject the REDIRECT. However, a DELETE should not be implied. If the gateway would also like to delete, it should send an explicit DELETE. It's also possible for the gateway to not send a DELETE, and simply go down and trust liveness checks to inform the client, but rejecting valid IPsec traffic due to invalid SA should be wrong. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 13 12:41:12 2009 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 D685928C146; Tue, 13 Jan 2009 12:41:12 -0800 (PST) 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 471A528C0E2 for ; Tue, 13 Jan 2009 12:41:12 -0800 (PST) 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 OrZORSX5ycko for ; Tue, 13 Jan 2009 12:41:04 -0800 (PST) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id 7B8EF28C148 for ; Tue, 13 Jan 2009 12:41:04 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e38.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0DKdLIc010686 for ; Tue, 13 Jan 2009 13:39:21 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0DKengY201876 for ; Tue, 13 Jan 2009 13:40:49 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0DKenVl019934 for ; Tue, 13 Jan 2009 13:40:49 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0DKenKt019931 for ; Tue, 13 Jan 2009 13:40:49 -0700 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: CEEB61D9:75377743-8525753D:005BC1ED; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/13/2009 03:40:14 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/13/2009 03:40:14 PM, Serialize complete at 01/13/2009 03:40:14 PM, S/MIME Sign failed at 01/13/2009 03:40:14 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 01/13/2009 13:40:49, Serialize complete at 01/13/2009 13:40:49 Message-ID: Date: Tue, 13 Jan 2009 15:40:48 -0500 Subject: [IPsec] Questions on RFC 4945's option to skip validation 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="===============1864882697==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1864882697== Content-Type: multipart/alternative; boundary="=_alternative 00718C468525753D_=" This is a multipart message in MIME format. --=_alternative 00718C468525753D_= Content-Type: text/plain; charset="US-ASCII" I'm confused about the use of RFC 4945's "option-to-skip-validation." According to footnote [b] in the table in section 3.1, "The ID in the ID payload MUST match the contents of the corresponding field (listed) in the certificate exactly." Earlier in section 3.1 the RFC states that "The only case where implementations may populate ID with information that is not contained in the end-entity certificate is when ID contains the peer source address (a single address, not a subnet or range)." (Although allowing for this contradicts the MUST in footnote [b] for IP*_ADDR.) This MUST in footnote [b] seems to make useless the "option-to-skip-validation" against the certificate as documented in the RFC. If the above is correct, then especially in the case of FQDN and USER_FQDN, the "option-to-skip-validation" is not applicable, because in those cases the ID field MUST have been populated from the certificate anyway. Yet the RFC allows for an option-to-skip-validation for these ID types. My specific questions are as follows: 1) What is the use case for enabling option-to-skip-validation for FQDN and USER_FQDN? Does that use case involve violating the MUST in footnote [b]? 2) In section 3.1, for IP*_ADDR, which of the following is correct -- the MUST in footnote [b], or the sentence beginning "The only case ..." a few paragraphs earlier? I'm inclined to trust the MUST more since it is capitalized, but that outright contradicts the earlier sentence. 3) What is the use case for enabling option-to-skip-validation against the certificate for IP*_ADDR? Does that use case involve violating the MUST in footnote [b]? 4) For IP*_ADDR, when option-to-skip-validation against the *certificate* is in effect, do/should we discourage the simultaneous use of option-to-skip-validation against the *address in the IP header*? I.e., is it ever envisioned that both of these options would be exercised at the same time? Disregarding the MUST in footnote [b], the earlier paragraph in section 3.1 seems to envision that the IP address in the ID payload would match the certificate or the IP header, or both, but not neither. 5) In general, is option-to-skip-validation something that would be discouraged for future implementations? It is described as an accommodation for existing implementations. Is it an accommodation because a) existing implementations may send ID payloads that don't match certificates, thereby violating section 3.1, or only because b) existing implementations offer the option to skip this check and we wanted to grandfather their options in, but not encourage it for future implementations? I have a hunch. I've been reading option-to-skip-validation as "I have an ID payload. What do I do with the cert?" But I wonder if it is more like "I have a cert. What do I do with the ID payload?" In other words, is option-to-skip-validation defined for use by implementations that want to use the certificate and pretty much ignore the ID payload for PAD lookup purposes? For implementations that use the ID payload for PAD lookup, option-to-skip-validation makes little sense to me, because, in the language of RFC 4945, those implementations still "MUST be especially careful to verify the truthfulness of the [ID payload]," and the certificate is the right way to do that. Thanks, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen --=_alternative 00718C468525753D_= Content-Type: text/html; charset="US-ASCII"
I'm confused about the use of RFC 4945's "option-to-skip-validation."

According to footnote [b] in the table in section 3.1, "The ID in the ID payload MUST match the contents of the corresponding field (listed) in the certificate exactly."  Earlier in section 3.1 the RFC states that "The only case where implementations may populate ID with information that is not contained in the end-entity certificate is when ID contains the peer source address (a single address, not a subnet or range)."  (Although allowing for this contradicts the MUST in footnote [b] for IP*_ADDR.)

This MUST in footnote [b] seems to make useless the "option-to-skip-validation" against the certificate as documented in the RFC.  If the above is correct, then especially in the case of FQDN and USER_FQDN, the "option-to-skip-validation" is not applicable, because in those cases the ID field MUST have been populated from the certificate anyway.  Yet the RFC allows for an option-to-skip-validation for these ID types.

My specific questions are as follows:

1) What is the use case for enabling option-to-skip-validation for FQDN and USER_FQDN?  Does that use case involve violating the MUST in footnote [b]?
2) In section 3.1, for IP*_ADDR, which of the following is correct -- the MUST in footnote [b], or the sentence beginning "The only case ..." a few paragraphs earlier?  I'm inclined to trust the MUST more since it is capitalized, but that outright contradicts the earlier sentence.
3) What is the use case for enabling option-to-skip-validation against the certificate for IP*_ADDR?  Does that use case involve violating the MUST in footnote [b]?
4) For IP*_ADDR, when option-to-skip-validation against the *certificate* is in effect, do/should we discourage the simultaneous use of option-to-skip-validation against the *address in the IP header*?  I.e., is it ever envisioned that both of these options would be exercised at the same time?  Disregarding the MUST in footnote [b], the earlier paragraph in section 3.1 seems to envision that the IP address in the ID payload would match the certificate or the IP header, or both, but not neither.
5) In general, is option-to-skip-validation something that would be discouraged for future implementations?  It is described as an accommodation for existing implementations.  Is it an accommodation because a) existing implementations may send ID payloads that don't match certificates, thereby violating section 3.1, or only because b) existing implementations offer the option to skip this check and we wanted to grandfather their options in, but not encourage it for future implementations?

I have a hunch.  I've been reading option-to-skip-validation as "I have an ID payload.  What do I do with the cert?"  But I wonder if it is more like "I have a cert.  What do I do with the ID payload?"  In other words, is option-to-skip-validation defined for use by implementations that want to use the certificate and pretty much ignore the ID payload for PAD lookup purposes?  For implementations that use the ID payload for PAD lookup, option-to-skip-validation makes little sense to me, because, in the language of RFC 4945, those implementations still "MUST be especially careful to verify the truthfulness of the [ID payload]," and the certificate is the right way to do that.

Thanks,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen --=_alternative 00718C468525753D_=-- --===============1864882697== 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 --===============1864882697==-- From nunez@alexmann.com Tue Jan 13 15:08:31 2009 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 601BC3A69A6 for ; Tue, 13 Jan 2009 15:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.943 X-Spam-Level: X-Spam-Status: No, score=-13.943 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHbrJWOKo4qG for ; Tue, 13 Jan 2009 15:08:30 -0800 (PST) Received: from 5ad528e1.bb.sky.com (5ad528e1.bb.sky.com [90.213.40.225]) by core3.amsl.com (Postfix) with SMTP id 97DE93A6A71 for ; Tue, 13 Jan 2009 15:08:29 -0800 (PST) To: Subject: Survey results From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090113230829.97DE93A6A71@core3.amsl.com> Date: Tue, 13 Jan 2009 15:08:29 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 01076
From mayeryuctztjum@altertrading.com Tue Jan 13 15:52:35 2009 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 2C5A33A68F8 for ; Tue, 13 Jan 2009 15:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.11 X-Spam-Level: X-Spam-Status: No, score=-9.11 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_EQ_DSL=1.129, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra487-bbeobf for ; Tue, 13 Jan 2009 15:52:29 -0800 (PST) Received: from adsl-dyn19.78-99-19.t-com.sk (adsl-dyn19.78-99-19.t-com.sk [78.99.19.19]) by core3.amsl.com (Postfix) with SMTP id DCAEE3A68FE for ; Tue, 13 Jan 2009 15:52:25 -0800 (PST) To: Subject: RE: Message 98173 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090113235227.DCAEE3A68FE@core3.amsl.com> Date: Tue, 13 Jan 2009 15:52:25 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 56180
From jungli@aldebarana.tk Tue Jan 13 16:24:41 2009 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 A2D9B3A68FE for ; Tue, 13 Jan 2009 16:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.925 X-Spam-Level: X-Spam-Status: No, score=-10.925 tagged_above=-999 required=5 tests=[AWL=14.094, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_3=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 LrYvXoeTvvUI for ; Tue, 13 Jan 2009 16:24:41 -0800 (PST) Received: from cable201-232-155-124.epm.net.co (cable201-232-155-124.epm.net.co [201.232.155.124]) by core3.amsl.com (Postfix) with SMTP id CB51E3A684D for ; Tue, 13 Jan 2009 16:24:38 -0800 (PST) To: Subject: Re: admin From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114002439.CB51E3A684D@core3.amsl.com> Date: Tue, 13 Jan 2009 16:24:38 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 28694
From mzakariya@advint.com Wed Jan 14 05:21:46 2009 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 9B0603A6880 for ; Wed, 14 Jan 2009 05:21:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -42.814 X-Spam-Level: X-Spam-Status: No, score=-42.814 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 lH30FZODckwM for ; Wed, 14 Jan 2009 05:21:46 -0800 (PST) Received: from ppp089210184160.dsl.hol.gr (ppp089210184160.dsl.hol.gr [89.210.184.160]) by core3.amsl.com (Postfix) with SMTP id C6CC73A63EC for ; Wed, 14 Jan 2009 05:21:43 -0800 (PST) To: Subject: Re: Order status 01320 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114132144.C6CC73A63EC@core3.amsl.com> Date: Wed, 14 Jan 2009 05:21:43 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 88671
From larry@advlearn.com Wed Jan 14 11:51:55 2009 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 0F6B528C1E9 for ; Wed, 14 Jan 2009 11:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.71 X-Spam-Level: X-Spam-Status: No, score=-8.71 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPWNRD3BGbPy for ; Wed, 14 Jan 2009 11:51:54 -0800 (PST) Received: from 201-3-122-65.fozit701.dsl.brasiltelecom.net.br (201-3-122-65.fozit701.dsl.brasiltelecom.net.br [201.3.122.65]) by core3.amsl.com (Postfix) with SMTP id 1C9533A686A for ; Wed, 14 Jan 2009 11:51:52 -0800 (PST) To: Subject: Your order 47740 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090114195153.1C9533A686A@core3.amsl.com> Date: Wed, 14 Jan 2009 11:51:52 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 97783
From ipsec-bounces@ietf.org Wed Jan 14 13:24:54 2009 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 524533A6AA8; Wed, 14 Jan 2009 13:24:54 -0800 (PST) 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 E927C3A6833 for ; Wed, 14 Jan 2009 13:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 f1klhJXWseyF for ; Wed, 14 Jan 2009 13:24:52 -0800 (PST) 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 D58A33A67F9 for ; Wed, 14 Jan 2009 13:24:51 -0800 (PST) Received: from [10.20.30.163] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0ELOYB9002164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Jan 2009 14:24:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 14 Jan 2009 13:24:32 -0800 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] RFC 5378 and this WG 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. If you are an author or contributor on in this WG, please read . It is important. The WG Chairs have been asked to make their WGs aware of this issue. This is a complicated subject, but the executive summary is that if you have an Internet-Draft that quotes substantially from one or more older RFCs (ones with a publication date pre-November 11, 2008), and you did not write this earlier work yourself (or you wrote it while with another company), you need to be aware of the likely difficulty of obtaining RFC 5378 clearances for your new work, and also to be aware that a work-around is on the way. The work-around should be in place to allow submissions to the San Francisco IETF well before the normal deadlines. See the attached text for more details. There is an open question about whether or not an Internet Draft that quotes from the WG discussion also needs clearance from the person who proposed text in the discussion. For example, IKEv2bis has a lot of material that has been proposed on this mailing list. If you feel that you have a draft for which this will be a problem, please contact me. With a chair hat on, I am not going to allow a general discussion about RFC 5378 on this list (as it is very off-topic). Please take such comments to the main IETF discussion list. Questions about specific WG drafts are of course on topic. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From llashoured@aamu.edu Thu Jan 15 00:09:04 2009 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 581563A6A39 for ; Thu, 15 Jan 2009 00:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.968 X-Spam-Level: X-Spam-Status: No, score=-32.968 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 L974ErC9OR-u for ; Thu, 15 Jan 2009 00:09:03 -0800 (PST) Received: from host86-157-static.4-79-b.business.telecomitalia.it (host86-157-static.4-79-b.business.telecomitalia.it [79.4.157.86]) by core3.amsl.com (Postfix) with SMTP id 624CC3A69A2 for ; Thu, 15 Jan 2009 00:09:01 -0800 (PST) To: Subject: Survey results From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090115080902.624CC3A69A2@core3.amsl.com> Date: Thu, 15 Jan 2009 00:09:01 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 79342
From ipsec-bounces@ietf.org Thu Jan 15 08:56:03 2009 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 2CECE3A6A3E; Thu, 15 Jan 2009 08:56:03 -0800 (PST) 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 124AF28C0F5 for ; Thu, 15 Jan 2009 08:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.057, 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 RIjraX43ORfz for ; Thu, 15 Jan 2009 08:55:58 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 27DA33A6A2D for ; Thu, 15 Jan 2009 08:55:57 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7AF8729C003; Thu, 15 Jan 2009 18:55:41 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8672129C001; Thu, 15 Jan 2009 18:55:40 +0200 (IST) X-CheckPoint: {496F684C-10000-88241DC2-7B6} 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 n0FGtdfE003563; Thu, 15 Jan 2009 18:55:40 +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, 15 Jan 2009 18:55:39 +0200 From: Yaron Sheffer To: Yoav Nir Date: Thu, 15 Jan 2009 18:55:37 +0200 Thread-Topic: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 Thread-Index: Acl1vGMlK1W/QGVoQ36j6yHW3fR1ewBdVtlg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63A2C7@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7@il-ex01.ad.checkpoint.com> <69754111-5777-430F-A779-AC5D4FB6F16D@checkpoint.com> In-Reply-To: <69754111-5777-430F-A779-AC5D4FB6F16D@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" , "suresh.krishnan@ericsson.com" , "sheila.frankel@nist.gov" Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 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="===============2001703635==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2001703635== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63A2C7ilex01adcheck_" --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63A2C7ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yoav, IKEv2 is quite clear on the definition of the Child SA. Quoting: "We call t= he IKE SA an "IKE_SA". The SAs for ESP and/or AH that get set up through t= hat IKE_SA we call "CHILD_SAs"." The name of the CREATE_CHILD_SA exchange is indeed unfortunate. Thanks, Yaron ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Tuesday, January 13, 2009 22:16 To: Yaron Sheffer Cc: sheila.frankel@nist.gov; suresh.krishnan@ericsson.com; ipsec@ietf.org Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 Hi Yaron, Two comments about your comments. On Jan 13, 2009, at 6:14 PM, Yaron Sheffer wrote: Hi Sheila, Suresh, - 2.3.1: why use the older term "IPsec SA", instead of the newer "Child SA"= ? A child SA is not the same as an IPsec SA, so the latter term is not deprec= ated. A child SA is an SA that is created from the IKE SA and could be an I= Psec SA, an IKE SA or something that we haven't yet defined. Note that in I= KEv2 the way to rekey an IKE SA is through a Create Child SA exchange, so t= he new IKE SA is also a child SA. - 7.4: we should point out that there are no known KINK implementations (AF= AIK). Not so. Racoon2 supports KINK as well as both versions of IKE. Yoav Email secured by Check Point =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63A2C7ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yoav,

 

IKEv2 is quite clear on the definition= of the Child SA. Quoting: “We call the IKE SA an "IKE_SA".&nbs= p; The SAs for ESP and/or AH that get set up through that IKE_SA we call "CHI= LD_SAs".”

 

The name of the CREATE_CHILD_SA exchan= ge is indeed unfortunate.

 

Thanks,

      &n= bsp;     Yaron

 

From: Yoav Nir [mailto:ynir@checkpoint.com]
Sent: Tuesday, January 13, 2= 009 22:16
To: Yaron Sheffer
Cc: sheila.frankel@nist.gov; suresh.krishnan@ericsson.com; ipsec@ietf.org
Subject: Re: [IPsec] Comment= s on draft-ietf-ipsecme-roadmap-00

 

Hi Yaron, 

 

Two comments about your comments.

 

On Jan 13, 2009, at 6:14 PM, Yaron Shef= fer wrote:



Hi Sheila, Suresh,

=  

<snip/>



- 2.3.1: why use the older term "IPsec SA", instead of the newer "Child SA"?

 

A child SA is not the same as an IPsec SA, so the latter term is no= t deprecated. A child SA is an SA that is created from the IKE SA and could b= e an IPsec SA, an IKE SA or something that we haven't yet defined. Note that in IKEv2 the way to rekey an IKE SA is through a Create Child SA exchange, so = the new IKE SA is also a child SA.

 

<snip/>

=  

- 7.4: we should point out that there= are no known KINK implementations (AFAIK).

 

Not so. Racoon2 supports KINK as well as both versions of IKE.=

 

Yoav



Email secured by Check Point


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63A2C7ilex01adcheck_-- --===============2001703635== 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 --===============2001703635==-- From lucile.cartwright@aebi.com Fri Jan 16 06:45:52 2009 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 77DB53A696F for ; Fri, 16 Jan 2009 06:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -37.961 X-Spam-Level: X-Spam-Status: No, score=-37.961 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 sTknWs+lL-K4 for ; Fri, 16 Jan 2009 06:45:51 -0800 (PST) Received: from host81-133-138-180.in-addr.btopenworld.com (host81-133-138-180.in-addr.btopenworld.com [81.133.138.180]) by core3.amsl.com (Postfix) with SMTP id C7C793A68EB for ; Fri, 16 Jan 2009 06:45:49 -0800 (PST) To: Subject: RE: Message 69922 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090116144550.C7C793A68EB@core3.amsl.com> Date: Fri, 16 Jan 2009 06:45:49 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 14925
From ipsec-bounces@ietf.org Fri Jan 16 15:54:31 2009 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 9DC813A694F; Fri, 16 Jan 2009 15:54:31 -0800 (PST) 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 ED7533A694F for ; Fri, 16 Jan 2009 15:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.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 qBkePIwMbRrd for ; Fri, 16 Jan 2009 15:54:29 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id 0CE7C3A6768 for ; Fri, 16 Jan 2009 15:54:28 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e8.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0GNmDUS012411 for ; Fri, 16 Jan 2009 18:48:13 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0GNsDqi191790 for ; Fri, 16 Jan 2009 18:54:13 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0GNsCuQ014424 for ; Fri, 16 Jan 2009 18:54:12 -0500 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.41.248.175]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0GNsC9B014420 for ; Fri, 16 Jan 2009 18:54:12 -0500 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id n0GNsCAI043842 for ; Fri, 16 Jan 2009 17:54:12 -0600 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.14.2/8.12.8) with ESMTP id n0GNqt1Y003098 for ; Fri, 16 Jan 2009 17:52:55 -0600 Received: (from jml@localhost) by faith.austin.ibm.com (8.14.2/8.14.2/Submit) id n0GNqtwp003097 for ipsec@ietf.org; Fri, 16 Jan 2009 17:52:55 -0600 X-Authentication-Warning: faith.austin.ibm.com: jml set sender to latten@austin.ibm.com using -f From: Joy Latten To: ipsec@ietf.org In-Reply-To: <50F98467-2C53-4342-8B5C-C5AF5E4B2BEF@checkpoint.com> References: <18763.31814.743812.266472@fireball.kivinen.iki.fi> <50F98467-2C53-4342-8B5C-C5AF5E4B2BEF@checkpoint.com> Date: Fri, 16 Jan 2009 17:52:55 -0600 Message-Id: <1232149975.5251.98.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-3.fc8) Subject: Re: [IPsec] Redirect draft and REDIRECT_ACK notify 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 Tue, 2009-01-13 at 22:25 +0200, Yoav Nir wrote: > On Jan 13, 2009, at 7:34 PM, Paul Hoffman wrote: > > > Yaron (without his co-chair hat on) has an opinion, and so does > > Tero; these two opinions are quite different technically. However, > > we are not hearing enough opinions on the list. I don't really care > > whether Yaron's opinion or Tero's gets WG consensus, but I do care > > if there is so little interest in this that they are not reading > > what is likely to be the first RFC out of this WG. > > > > The two choices so far are to include a NOTIFY in the response or to > > use a separate Informational exchange. I think there is agreement > > that they would both have the same semantics, but they are done > > quite differenty. > > > > If you have an opinion, please comment on the thread and state why > > you prefer a NOTIFY or a separate exchange. If you have thought > > about it and you truly don't care, please say that as well. > > > > --Paul Hoffman, Director > > --VPN Consortium > > I think that we don't need a REDIRECT_ACK, since the client cannot > reject the REDIRECT. However, a DELETE should not be implied. If the > gateway would also like to delete, it should send an explicit DELETE. > It's also possible for the gateway to not send a DELETE, and simply go > down and trust liveness checks to inform the client, but rejecting > valid IPsec traffic due to invalid SA should be wrong. > I've read the draft but am just reading this thread. I agree with this. It also made sense to me when someone mentioned the server including the DELETE with the REDIRECT to avoid possibility of server not getting a chance to send the DELETE. regards, Joy Latten _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 16 18:43:04 2009 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 8792E3A6A75; Fri, 16 Jan 2009 18:43:04 -0800 (PST) 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 D2A503A6A2F for ; Fri, 16 Jan 2009 18:43:02 -0800 (PST) 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 taw5L9+OHxhI for ; Fri, 16 Jan 2009 18:42:58 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 9D0AE3A689F for ; Fri, 16 Jan 2009 18:42:56 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,279,1231113600"; d="scan'208,217";a="39303940" Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 17 Jan 2009 02:42:19 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0H2gJEg019760; Sat, 17 Jan 2009 08:12:19 +0530 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0H2gI3V008410; Sat, 17 Jan 2009 02:42:18 GMT Received: from xmb-blr-418.apac.cisco.com ([64.104.140.147]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Jan 2009 08:12:18 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 17 Jan 2009 08:12:17 +0530 Message-ID: <7906EBB854491A438474875D1D737321068A2CA1@xmb-blr-418.apac.cisco.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63A2C7@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 Thread-Index: Acl1vGMlK1W/QGVoQ36j6yHW3fR1ewBdVtlgAEaFM4A= References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7@il-ex01.ad.checkpoint.com><69754111-5777-430F-A779-AC5D4FB6F16D@checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63A2C7@il-ex01.ad.checkpoint.com> From: "Rajeshwar Singh Jenwar (rsj)" To: "Yaron Sheffer" , "Yoav Nir" X-OriginalArrivalTime: 17 Jan 2009 02:42:18.0826 (UTC) FILETIME=[370E2AA0:01C9784D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15394; t=1232160139; x=1233024139; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rsj@cisco.com; z=From:=20=22Rajeshwar=20Singh=20Jenwar=20(rsj)=22=20 |Subject:=20RE=3A=20[IPsec]=20Comments=20on=20draft-ietf-ip secme-roadmap-00 |Sender:=20; bh=25ea0r2gFsG8+mQ3+cexIT5gImC+ejXB7ICWle7YHcw=; b=NUUvUBchbQLLMmYuNuaovWmBBrjYSngKGv0vqP6EyjcO3bd7XrjkbaK0N9 PQ4ByxGbrxMxIvxXKaDBAbfQ2yzHuSdvMepj3h10kbrmFbnwjO3jL0qPpzeB U0PXWWTnVn; Authentication-Results: ind-dkim-1; header.From=rsj@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); Cc: ipsec@ietf.org, suresh.krishnan@ericsson.com, sheila.frankel@nist.gov Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 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="===============1010403603==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1010403603== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9784D.369AD6C7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9784D.369AD6C7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yaron/Yoav, =20 If you see section 1 (Introduction) of RFC4306 and IKEv2bis, in IKEv2bis "We call the IKE SA an "IKE_SA" has been removed. I request IKEV2bis authors to comment on this.=20 Is above sentence has been removed to change the definition of CHILD_SAs to the definition as mentioned by Yoav in mail below ? =20 Thanks, Raj ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Thursday, January 15, 2009 10:26 PM To: Yoav Nir Cc: ipsec@ietf.org; suresh.krishnan@ericsson.com; sheila.frankel@nist.gov Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 Hi Yoav, =20 IKEv2 is quite clear on the definition of the Child SA. Quoting: "We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get set up through that IKE_SA we call "CHILD_SAs"." =20 The name of the CREATE_CHILD_SA exchange is indeed unfortunate. =20 Thanks, Yaron =20 ________________________________ From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Tuesday, January 13, 2009 22:16 To: Yaron Sheffer Cc: sheila.frankel@nist.gov; suresh.krishnan@ericsson.com; ipsec@ietf.org Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 =20 Hi Yaron,=20 =20 Two comments about your comments. =20 On Jan 13, 2009, at 6:14 PM, Yaron Sheffer wrote: Hi Sheila, Suresh, =20 - 2.3.1: why use the older term "IPsec SA", instead of the newer "Child SA"? =20 A child SA is not the same as an IPsec SA, so the latter term is not deprecated. A child SA is an SA that is created from the IKE SA and could be an IPsec SA, an IKE SA or something that we haven't yet defined. Note that in IKEv2 the way to rekey an IKE SA is through a Create Child SA exchange, so the new IKE SA is also a child SA. =20 =20 - 7.4: we should point out that there are no known KINK implementations (AFAIK). =20 Not so. Racoon2 supports KINK as well as both versions of IKE. =20 Yoav Email secured by Check Point=20 Email secured by Check Point=20 ------_=_NextPart_001_01C9784D.369AD6C7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Yaron/Yoav,
 
If you see section 1 (Introduction) of RFC4306 = and=20 IKEv2bis, in IKEv2bis "We call the IKE SA an "IKE_SA" = has been=20 removed.
I request IKEV2bis authors to comment on this.=20
Is above sentence has been removed to = change the=20 definition of CHILD_SAs to the definition as mentioned by Yoav = in mail=20 below ?
 
Thanks,
Raj

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron=20 Sheffer
Sent: Thursday, January 15, 2009 10:26 = PM
To: Yoav=20 Nir
Cc: ipsec@ietf.org; suresh.krishnan@ericsson.com;=20 sheila.frankel@nist.gov
Subject: Re: [IPsec] Comments on=20 draft-ietf-ipsecme-roadmap-00

Hi=20 Yoav,

 

IKEv2 is = quite clear on=20 the definition of the Child SA. Quoting: “We call the IKE SA an = "IKE_SA". =20 The SAs for ESP and/or AH that get set up through that IKE_SA we call=20 "CHILD_SAs".”

 

The name of = the=20 CREATE_CHILD_SA exchange is indeed = unfortunate.

 

Thanks,

           = =20 Yaron

 

From:=20 Yoav Nir = [mailto:ynir@checkpoint.com]=20
Sent: Tuesday, = January 13,=20 2009 22:16
To: = Yaron Sheffer
Cc: sheila.frankel@nist.gov;=20 suresh.krishnan@ericsson.com; ipsec@ietf.org
Subject: Re: [IPsec] Comments on=20 draft-ietf-ipsecme-roadmap-00

 

Hi Yaron, 

 

Two comments about your=20 comments.

 

On Jan 13, 2009, at 6:14 PM, Yaron Sheffer=20 wrote:



Hi Sheila,=20 Suresh,

 

<snip/>



- 2.3.1: why = use the=20 older term "IPsec SA", instead of the newer "Child = SA"?

 

A child SA is not the same as an IPsec SA, so = the latter=20 term is not deprecated. A child SA is an SA that is created from the IKE = SA and=20 could be an IPsec SA, an IKE SA or something that we haven't yet = defined. Note=20 that in IKEv2 the way to rekey an IKE SA is through a Create Child SA = exchange,=20 so the new IKE SA is also a child SA.

 

<snip/>

 

- 7.4: we = should point=20 out that there are no known KINK implementations = (AFAIK).

 

Not so. Racoon2 supports KINK as well as both = versions=20 of IKE.

 

Yoav



Email secured by Check = Point=20



Email secured by Check = Point=20

------_=_NextPart_001_01C9784D.369AD6C7-- --===============1010403603== 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 --===============1010403603==-- From lucie.durand@afnor.fr Fri Jan 16 19:08:44 2009 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 CABA43A6A5F for ; Fri, 16 Jan 2009 19:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.876 X-Spam-Level: X-Spam-Status: No, score=-12.876 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7o9YyOFBSFO2 for ; Fri, 16 Jan 2009 19:08:44 -0800 (PST) Received: from aaiworldmarket.com (200.220.134.2.nipcable.com [200.220.134.2]) by core3.amsl.com (Postfix) with SMTP id 269003A69DD for ; Fri, 16 Jan 2009 19:08:42 -0800 (PST) To: Subject: Email Administrator, Pfizer World Headquarters From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090117030843.269003A69DD@core3.amsl.com> Date: Fri, 16 Jan 2009 19:08:42 -0800 (PST)
January 16, 2009 | "SPECIAL OFFERS"-Pfizer Company!




Contact: Email Administrator, Pfizer World Headquarters 510 E. 42nd Street New York, NY 89191
® 2001-2009 Pfizer Inc. All rights reserved!
Pfizer is a licensee of the TRUSTe Privacy Program!, click here.

» Help  »Advertise  »Terms of Service  »Privacy Policy
From jobes@aic.gov.au Sat Jan 17 05:54:50 2009 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 B07343A6993 for ; Sat, 17 Jan 2009 05:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.444 X-Spam-Level: X-Spam-Status: No, score=-33.444 tagged_above=-999 required=5 tests=[AWL=-8.530, BAYES_99=3.5, HTML_IMAGE_ONLY_24=1.552, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPVyDHdjBT6T for ; Sat, 17 Jan 2009 05:54:44 -0800 (PST) Received: from 109-237.citylan.bg (109-237.citylan.bg [89.25.109.237]) by core3.amsl.com (Postfix) with SMTP id 2F2013A6781 for ; Sat, 17 Jan 2009 05:54:42 -0800 (PST) To: Subject: RE: Q&A Doctor Anita Graves From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090117135443.2F2013A6781@core3.amsl.com> Date: Sat, 17 Jan 2009 05:54:42 -0800 (PST)
January 16, 2009 | "SPECIAL OFFERS"-Pfizer Company!




Contact: Email Administrator, Pfizer World Headquarters 257 E. 42nd Street New York, NY 49756
® 2001-2009 Pfizer Inc. All rights reserved!
Pfizer is a licensee of the TRUSTe Privacy Program!, click here.

» Help  »Advertise  »Terms of Service  »Privacy Policy
From nja.kunnola@a-lehdet.fi Sat Jan 17 19:12:38 2009 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 A8BFE3A6B45 for ; Sat, 17 Jan 2009 19:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.962 X-Spam-Level: X-Spam-Status: No, score=-20.962 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIWoN2G3t7Ga for ; Sat, 17 Jan 2009 19:12:38 -0800 (PST) Received: from amazingformula.com (unknown [200.121.211.10]) by core3.amsl.com (Postfix) with SMTP id EF1FB3A6AAD for ; Sat, 17 Jan 2009 19:12:35 -0800 (PST) To: Subject: Survey results From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090118031235.EF1FB3A6AAD@core3.amsl.com> Date: Sat, 17 Jan 2009 19:12:35 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 69835
From mcummingsnn@advantageh.com Sun Jan 18 07:27:26 2009 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 1C0353A6839 for ; Sun, 18 Jan 2009 07:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.269 X-Spam-Level: X-Spam-Status: No, score=-22.269 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_DYNAMIC_CHELLO_NL=3.595, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id brWSEJGyWC39 for ; Sun, 18 Jan 2009 07:27:25 -0800 (PST) Received: from f46161.upc-f.chello.nl (f46161.upc-f.chello.nl [80.56.46.161]) by core3.amsl.com (Postfix) with SMTP id 1B7143A68F3 for ; Sun, 18 Jan 2009 07:27:22 -0800 (PST) To: Subject: Re: Order status 32417 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090118152723.1B7143A68F3@core3.amsl.com> Date: Sun, 18 Jan 2009 07:27:22 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 12429
From mattyhnh@4style.ru Sun Jan 18 14:19:24 2009 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 A10CC28C104 for ; Sun, 18 Jan 2009 14:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.717 X-Spam-Level: X-Spam-Status: No, score=-3.717 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_UNI=0.591, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrKvFYQVADCB for ; Sun, 18 Jan 2009 14:19:23 -0800 (PST) Received: from 201-24-234-85.ctame704.dsl.brasiltelecom.net.br (201-24-234-85.ctame704.dsl.brasiltelecom.net.br [201.24.234.85]) by core3.amsl.com (Postfix) with SMTP id A8D1C28C0E4 for ; Sun, 18 Jan 2009 14:19:22 -0800 (PST) To: Subject: RE: Message 17573 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090118221922.A8D1C28C0E4@core3.amsl.com> Date: Sun, 18 Jan 2009 14:19:22 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 90177
From ipsec-bounces@ietf.org Mon Jan 19 08:45:04 2009 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 122E328C0ED; Mon, 19 Jan 2009 08:45:04 -0800 (PST) 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 B6CC228B56A for ; Sun, 18 Jan 2009 22:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.437 X-Spam-Level: X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622] 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 oof6jQxY-kdf for ; Sun, 18 Jan 2009 22:39:19 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by core3.amsl.com (Postfix) with ESMTP id 5701B3A6B6E for ; Sun, 18 Jan 2009 22:39:19 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2975630wfd.31 for ; Sun, 18 Jan 2009 22:39:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from :content-type:content-transfer-encoding; bh=QKMmTFhAEMQNpY6OdUWKm02JOq/wN5XkOafOEfJbQuE=; b=ON1eHubqJGT+AXXOqRSvgrbHkwvXWcurMxQKUOIXhnzoiwn8ZM8HR5BcDPWH2TQ8Od I0r+b9QOuRS2a7yeX4JtHJhbu0bCIkF2gsnira+qYkDBY6qX7DIRoJ/eE8rTKQw+jjFy RAf07pdvCrU6i1kJNP2hik3v8Py4tOWuig2R8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:content-type :content-transfer-encoding; b=ql7c61ZTi0Rr4vfjfCeohAQ1GVmyK8azBOWTTusGnM5nKwYCD9qBO6nKucrinjchxT zfp0Epco2s6Xj5sT4hdpNfYntaI+wmevgVw1CrVq8rQ+ESwft0Fzcl9xhlAGMXj+IXsF SEEBf6InmPrMXPF6Biwwg3mYLEPYo7PYBRHME= MIME-Version: 1.0 Received: by 10.142.73.7 with HTTP; Sun, 18 Jan 2009 22:39:03 -0800 (PST) In-Reply-To: <57ae7b010901182227u6031a296odbc82a32155d3ef3@mail.gmail.com> References: <57ae7b010901080949j63f090f4o145f1ee59e59ac62@mail.gmail.com> <57ae7b010901182227u6031a296odbc82a32155d3ef3@mail.gmail.com> Date: Mon, 19 Jan 2009 01:39:03 -0500 X-Google-Sender-Auth: 8a89a71664347b35 Message-ID: <57ae7b010901182239m78585400idfb398a9dec1050e@mail.gmail.com> From: "Z. Morley Mao" To: undisclosed-recipients:; X-Mailman-Approved-At: Mon, 19 Jan 2009 08:45:01 -0800 Subject: [IPsec] CFP: SECURECOMM (Submission deadline: March 31) 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 apologize if you receive this announcement multiple times. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ SECURECOMM 2009 Fifth International ICST Conference on Security and Privacy for Communication Networks Athens, Greece, September 14-18, 2009 URL: http://www.securecomm.org Sponsored by: ICST (www.icst.org) Co-Sponsored By: CreateNet (www.create-net.it) PAPER SUBMISSION DEADLINE is March 31, 2009 (11:59 PM CDT) ===================================================================== Securecomm seeks high-quality research contributions in the form of well developed papers. Topics of interest encompass research advances in ALL areas of secure communications and networking. However, topics in other areas (e.g., formal methods, database security, secure software, foundations of cryptography) will be considered only if a clear connection to private or secure communications/networking is demonstrated. The aim of Securecomm is to bring together security and privacy experts in academia, industry and government as well as practitioners, standards developers and policy makers, in order to engage in a discussion about common goals and explore important research directions in the field. Securecomm also serves as a venue for learning about state-of-the-art in security and privacy research, giving attendees the opportunity to network with experts in the field. Presentations reporting on cutting-edge research results are supplemented by panels on controversial issues and invited talks on timely and important topics. PAPERS: Technical papers describing original research contributions are solicited. Submissions must not be concurrently under review by a conference, journal or any other venue that has proceedings. SUBMISSION INSTRUCTIONS: Only PDF formats are accepted for all submissions. Paper submissions must not exceed 10 pages in IEEE conference style, twocolumn format, not including the bibliography. Well-marked appendices of up to 2 pages are allowed but will be read only at the discretion of reviewers. All submitted papers will be judged based on their quality through *doubleblind* reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper. Complete paper submission instructions are available at the conference website. TOPICS of interest include, but are not limited to, the following: * Security & Privacy in Wired, Wireless, Mobile, Hybrid, Sensor, Ad Hoc networks * Network Intrusion Detection and Prevention, Firewalls, Packet Filters * Malware and botnets * Communication Privacy and Anonymity * Distributed denial of service * Public Key Infrastructures, key management, credentials * Web security * Secure Routing, Naming/Addressing, Network Management * Security & Privacy in Pervasive and Ubiquitous Computing, e.g., RFIDs * Security & Privacy for emerging technologies: VoIP, peer-to-peer and overlay network systems, Web 2.0 WORKSHOPS: Proposals for one-day workshops to be held in conjunction with the conference are solicited. A maximum of 2 pages should be submitted which include the workshop name, its scope and a list of topic of interests. Proposals should be submitted to the General Chair by April 1, 2009. DEMOS: Proposals for research and industrial demos are solicited. A maximum of 2 pages should be submitted which include a description of the demo and needed resources from the conference organizers. Proposals should be submitted to the General Chair by June 1, 2009. IMPORTANT DATES -------------------- Paper Submission: March 31, 2009 Notification of Acceptance: June 12, 2009 Camera-ready Version: July 9, 2009 ====================================================== CONFERENCE ORGANIZING COMMITTEE General Chair ------------- Peng Liu, Penn State Univeristy, USA TPC Chairs ---------- Yan Chen, Northwestern University, USA Tassos Dimitriou, Athens Information Technology, Greece Steering Commitee -------------------- Imrich Chlamtac (Chair), Create-Net, Italy Krishna Sivalingam (Co-chair), University of Maryland Baltimore County, USA / Indian Institute of Technology Madras _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From linn-gensch@ahkonline.com Mon Jan 19 13:05:17 2009 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 716713A68DE for ; Mon, 19 Jan 2009 13:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.839 X-Spam-Level: X-Spam-Status: No, score=-11.839 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m92JfDg9EGcI for ; Mon, 19 Jan 2009 13:05:16 -0800 (PST) Received: from adityabirla.com (unknown [189.60.47.143]) by core3.amsl.com (Postfix) with SMTP id DA0983A6856 for ; Mon, 19 Jan 2009 13:05:14 -0800 (PST) To: Subject: RE: Message 43455 From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090119210514.DA0983A6856@core3.amsl.com> Date: Mon, 19 Jan 2009 13:05:14 -0800 (PST)
About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 26217
From jperry@abf.com.didtheyreadit.com Mon Jan 19 17:12:26 2009 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 24B363A6A3E for ; Mon, 19 Jan 2009 17:12:26 -0800 (PST) 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=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bANVujQ59y6A for ; Mon, 19 Jan 2009 17:12:25 -0800 (PST) Received: from 201-69-216-93.dial-up.telesp.net.br (201-69-100-187.dial-up.telesp.net.br [201.69.100.187]) by core3.amsl.com (Postfix) with SMTP id 886473A6AA8 for ; Mon, 19 Jan 2009 17:12:20 -0800 (PST) To: Subject: Next: Getting the best results From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090120011221.886473A6AA8@core3.amsl.com> Date: Mon, 19 Jan 2009 17:12:20 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Not see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.dreamstrength.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://methoddegree.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 4, B836. 788 Clements Road. London. SE98 8DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From landa@ama-assn.org Tue Jan 20 01:24:43 2009 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 F25D83A6800 for ; Tue, 20 Jan 2009 01:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.352 X-Spam-Level: * X-Spam-Status: No, score=1.352 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_IP_ADDR=1.119, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3jn0Xnprigy for ; Tue, 20 Jan 2009 01:24:36 -0800 (PST) Received: from 250.122.121.70.cfl.res.rr.com (250.122.121.70.cfl.res.rr.com [70.121.122.250]) by core3.amsl.com (Postfix) with SMTP id E99533A6989 for ; Tue, 20 Jan 2009 01:24:32 -0800 (PST) To: Subject: Re: BRANDKEYWORD, Ltd From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090120092433.E99533A6989@core3.amsl.com> Date: Tue, 20 Jan 2009 01:24:32 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Not see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.dreamstrength.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://methoddegree.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 7, B854. 263 Clements Road. London. SE28 4DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From ipsec-bounces@ietf.org Tue Jan 20 05:18:25 2009 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 8C98E3A6BEB; Tue, 20 Jan 2009 05:18:25 -0800 (PST) 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 F1C313A6BE7 for ; Tue, 20 Jan 2009 05:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 9zDuAeHtdGwv for ; Tue, 20 Jan 2009 05:18:24 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id D9C4E3A67EC for ; Tue, 20 Jan 2009 05:18:23 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so2753366yxg.49 for ; Tue, 20 Jan 2009 05:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=EOmZOON2vXQ8qhwwfEyhdxk8iEghp7b8PhYBkd33OPY=; b=KYA1FaGh2Te1sjndbvzsd44XQOVulITS4ghOlz808pR6KxrE5MFZSgx63elrJSj0Co yvO5yNjOu3dNIfmK99oJrv1IhhK9cf2O5rYXzFvBfMWle9TbIEWyZ3XHj9Mal6yEg30i 1pI9fiP+B/TC5TUvb2YifchTMdohunloDwd0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=CReHy86wXw4CDpVQNmGIMkXJVFsDaYhHa0BzsfX3GakHZgGXqyT+D4mbXwou7JogaY HoHiFviCSYWKkQGhNnJqK3G7vud6X1gFsRcL2JLElPJtwxRMbdBYhrr0siQzSWx5sPhi NVYP/ArQJ8d/q/IiwRZuu3nC+BmL9RUGaUpaQ= MIME-Version: 1.0 Received: by 10.100.143.12 with SMTP id q12mr4787931and.22.1232457487058; Tue, 20 Jan 2009 05:18:07 -0800 (PST) Date: Tue, 20 Jan 2009 21:18:07 +0800 Message-ID: <4c5c7a6d0901200518o549d295fyc1cc8054f86e0fcb@mail.gmail.com> From: Peny Yang To: ipsec@ietf.org Cc: Hui Deng Subject: [IPsec] Proposed text for working items of IKE session resumption 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, IPsecme folks: We had quite a lot of discussion in the list and Minneapolis meeting. We collected the comments on the pros and cons of ticket-by-value/ticket-by-reference, and related protocols. Hereby, we proposed the text as below. Your comments are more than welcome. Thanks a lot BRG Peny Text Proposal ########################################### 1) Format of Ticket (TbV and TvR) Original text: none. Proposed text: 5.5 Format of TbV and TbR The TvV/TvR will be included in the ticket field of TICKET_OPAQUE (section 4.4) payload when it's requested by client or presented to gateway. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 01 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-++ !V!Rers! ! +-+-+-+- + ~ Encrypted Ticket ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ V bit: 0 - TbV, 1-TbR Rers (3 bit): Reserved. 2) Protocol of ticket presenting After section 4.3 Proposed Text: 4.2.2. Presenting a ticket by extension of IKE_SA_INIT This document also supports the way of utilizing the generic IKEv2 IKE_SA_INIT exchange for session resumption. The client may initialize a regular IKE exchange without enclosing the TbV/TbR in the IKE_SA_INIT message. The client SHOULD NOT enclose the payloads of N(TICKET_OPAQUE), [N+,] and SK {IDi, [IDr,]}, unless it knows that the gateway supports it. The client should decide when it can use the IKE_SA_INIT exchange to do the session resumption, after it detects the interruption of IKEv2 responder. The client's decision may be based on the local policies. The ticket is only for one-time use, on matter it's on network side or client. When IKEv2 client detects the interruption of IKEv2 responder and decides to use the extension of IKE_SA_INIT exchange for session resumption, It will send the IKE_SA_INIT message as below: Initiator Responder ----------- ----------- HDR, SAi, KEi, Ni, N(TICKET_OPAQUE), [N+,] SK {IDi, [IDr,], [Ticket ID]} --> Figure: Ticket presenting by client The exchange type in HDR is set to 'IKE_SA_INIT'. KEi value is collected from the the old unexpired IKE_SA in client. When the IKEv2 gateway receives a IKE_SA_INIT with the payload of N(TICKET_OPAQUE). It MUST check the Ticket type in the V bit. If it's a TbR, gateway will use the reference to get the full content of ticket from somewhere in the network side. How to retrieve the ticket by reference is out of the scope in this document. If it's a TbV, gateway can get the content of ticket from this IKE_SA_INIT message. After ticket validation, one of the following steps if it supports the extension defined in this document: o If this IKE_SA_INIT message for session resumption is valid for gateway, it will accept it and the follow-up CREATE_CHILD_SA exchanges can be initiated by client. Initiator Responder ----------- ----------- <-- HDR, SK {IDr} Figure: IKEv2 gateway accepts the ticket the exchange type in HDR is set to 'IKE_SA_INIT'. o It responds with an regular IKE_SA_INIT response as defined in RFC4306, if it rejects the ticket for any reason (such as the example mentioned in section 4.2.1). In that case, the initiator can fall back to the regular IKE procedure. 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. 4.2.2.1 Protection of the IKE_SA_INIT extension for session resumption. The way is the same as defined in section 4.2.1.1 4.2.2.2 DoS case for IKE_SA_INIT extension for session resumption. When receiving the first message of the IKE_SA_INIT exchange for session resumption, the gateway may decide that it is under a denial-of-service attack. This document relies on the anti-DoS mechanism of generic IKE_SA_INIT exchange in RFC4306. 3) Message Protection After section 7.8 Proposed text: 7.9 Protection in IKE_SA_INIT exchange for session resumption This document relies on the anti-DoS and reply protection mechanism of generic IKE_SA_INIT exchange in RFC4306. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 20 05:18:35 2009 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 0748928C143; Tue, 20 Jan 2009 05:18:35 -0800 (PST) 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 DEAE028C169 for ; Tue, 20 Jan 2009 05:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.390, 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 Pk1yB2axTe3H for ; Tue, 20 Jan 2009 05:18:32 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 973A828C13E for ; Tue, 20 Jan 2009 05:18:32 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so1853612wag.5 for ; Tue, 20 Jan 2009 05:18:15 -0800 (PST) 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=1r5Zt3D9aPOdDcgDb+ColWWSSdpuNSCY7B3iL5pMOKY=; b=pyNxFXLswhe/+lWg3sQ2tYd7slpg43J5TtH27iA1IPLePe67zM5TD7wLWrPjy6Kl08 pEJQz9xDrZ2QOMoE9kGSz7Yg3MRbzznoTWe9rus+JykyRurXlZj77i7qGxfVzrbKl/84 BDgHCH8AXx7huuwaCxS8O1SkChynH7A6RLfNo= 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=YepYBHod3Qe+TXFiYqsJuGUr6TPai7H3W13n4PAO04fu+QuKhcNtTBCIgx/dhpm0Qr K7uXV1qgqJCpk+UiWF3KrQQGCf8RYk0MksdO/bTOeI5Uq8Aoz3Pe9I8g5RydtyaGqbds 9QWyFKID1tDm9KxRY6IxusVj7ea5y7JLynwcs= Received: by 10.114.92.2 with SMTP id p2mr1927696wab.122.1232457493212; Tue, 20 Jan 2009 05:18:13 -0800 (PST) Received: by 10.115.16.13 with HTTP; Tue, 20 Jan 2009 05:18:13 -0800 (PST) Message-ID: <1d38a3350901200518u432e0df8n1efe9fa1b63e131b@mail.gmail.com> Date: Tue, 20 Jan 2009 21:18:13 +0800 From: "Hui Deng" To: ipsec@ietf.org In-Reply-To: <061.7ae35be7f65e375ae77802ad7cdff96b@tools.ietf.org> MIME-Version: 1.0 References: <061.7ae35be7f65e375ae77802ad7cdff96b@tools.ietf.org> Cc: hannes.tschofenig@nsn.com Subject: Re: [IPsec] [ipsecme] #73: Ticket location: prefer server-side ticket 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="===============0597493426==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0597493426== Content-Type: multipart/alternative; boundary="----=_Part_25993_7420421.1232457493192" ------=_Part_25993_7420421.1232457493192 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, all: As we discussed in Minneapolis on IKEv2 session resumption, hereby we propose some text to this work item. Please comment it. Thanks in advance -Hui Text Proposal *************************************************************** 1) Location of Ticket (a) Original text: In section 2: Terminology (line 10 of page 4): Ticket: An IKEv2 ticket is a data structure that contains all the necessary information that allows an IKEv2 responder to re- establish an IKEv2 security association. Proposed text 1 in section 2: Terminology (line 10 of page 4): Ticket: An IKEv2 ticket is a data structure that contains all the necessary information that allows an IKEv2 responder to re-establish an IKEv2 security association. The location of this data structure could be on the IKEv2 client or on the network side. If it's on IKEv2 client, it must be encrypted as specified in section 7. If it's on network side, it could be reachable for the IKEv2 gateway and referenced by Ticket-by-Reference (TbR) Ticket by Reference (TbR): A data structure presented to IKEv2 client with reference to uniqe IKEv2 ticket of current IKEv2 client stored on network side. Ticket by Value (TbV): A data structure presented to IKEv2 client with full-bodied data structure of ticket. (b) Proposed text 2 in section 5 after 5.2: 5.3 Location of ticket The full-bodied content of ticket could be stored on client or network side. If it's stored on client, it will be put in TbV. TbV presenting and requesting can be found in section 4. The way of TbV encryption can be found in section 7. If it's stored in the network side, the operators shall allocate the non-volatile memory space for gateways to store the tickets of all the clients. How to build the ticket storage is out of the scope. This ticket storage must be reachable for IKEv2 gateway. The reference of the ticket is defined in 5.4. 5.4 ticket reference. When ticket is stored in network side, it should be referenced by ticket reference. The content of ticket reference can be defined by operators. It could be following types, but not limited to them: o The operator specific ticket ID. o The combination of IDi, IDr and old SPIr. In this case, the ticket reference must be encrypted as defined in section 7 and put in TbR. TbR presenting and requesting can be found in section 4. 2) Protocol of ticket presenting (a) Proposed text: section 4.2. after the third paragraph The document supports two methods to present a ticket by client. o A new IKEv2 exchange type called IKE_SESSION_RESUME. It's defined in section 4.2.1 o A extension to generic IKEv2 IKE_SA_INIT exchange. It's defined in section 4.2.2 (b) Proposed text: section 4.2. before the fourth paragraph 4.2.1 Presenting a ticket by IKE_SESSION_RESUME (c) 4.2.1 ==> 4.2.1.1 (d) 4,2,2 Presenting a Ticket: The DoS Case ==> 4,2,1.2 Presenting a Ticket by IKE_SESSION_RESUME: The DoS Case (e) 4.2.3. Requesting a ticket during resumption ==> 4,2,1,3, Requesting a ticket by IKE_SESSION_RESUME during resumption 2008/12/7 ipsecme issue tracker > #73: Ticket location: prefer server-side ticket > > ---------------------------------+------------------------------------------ > Reporter: denghui02@gmail.com | Owner: hannes.tschofenig@nsn.com > Type: defect | Status: new > Priority: normal | Milestone: milestone1 > Component: ikev2-resumption | Severity: Active WG Document > Keywords: | > > ---------------------------------+------------------------------------------ > The document should recommend "by reference", in preference to "by value" > tickets; or make "by reference" a MUST, and "by value" a SHOULD/MAY. > Mainly for the following two reasons: > > - Less bandwidth, by not sending the ticket. > - IKEv2 messages, especially the first one, had better not be fragmented. > > See http://www.ietf.org/mail-archive/web/ipsec/current/msg03355.html and > numerous follow-ups. > > -- > Ticket URL: > ipsecme > > ------=_Part_25993_7420421.1232457493192 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi, all:

As we discussed in Minneapolis on IKEv2 session resumption, hereby we
propose some text to this work item.
Please comment it.

Thanks in advance

-Hui

Text Proposal
***************************************************************

1) Location of Ticket

(a)
Original text:
In section 2: Terminology (line 10 of page 4):
Ticket:  An IKEv2 ticket is a data structure that contains all the
    necessary information that allows an IKEv2 responder to re-
    establish an IKEv2 security association.

Proposed text 1 in section 2: Terminology (line 10 of page 4):
Ticket:
An IKEv2 ticket is a data structure that contains all the necessary
information that allows an IKEv2 responder to re-establish an IKEv2
security association. The location of this data structure could be on
the IKEv2 client or on the network side. If it's on IKEv2 client, it
must be encrypted as specified in section 7. If it's on network side,
it could be reachable for the IKEv2 gateway and referenced by
Ticket-by-Reference (TbR)

Ticket by Reference (TbR):
A data structure presented to IKEv2 client with reference to uniqe
IKEv2 ticket of current IKEv2 client stored on network side.

Ticket by Value (TbV):
A data structure presented to IKEv2 client with full-bodied data
structure of ticket.

(b)
Proposed text 2 in section 5 after 5.2:

5.3 Location of ticket
The full-bodied content of ticket could be stored on client or network side.
If it's stored on client, it will be put in TbV. TbV presenting and
requesting can be found in section 4.  The way of TbV encryption can
be found in section 7.
If it's stored in the network side, the operators shall allocate the
non-volatile memory space for gateways to store the tickets of all the
clients. How to build the ticket storage is out of the scope. This
ticket storage must be reachable for IKEv2 gateway. The reference of
the ticket is defined in 5.4.

5.4 ticket reference.
When ticket is stored in network side, it should be referenced by
ticket reference. The content of ticket reference can be defined by
operators. It could be following types, but not limited to them:
o The operator specific ticket ID.
o The combination of IDi, IDr and old SPIr.
In this case, the ticket reference must be encrypted as defined in
section 7 and put in TbR. TbR presenting and requesting can be found
in section 4.

2) Protocol of ticket presenting
(a)
Proposed text: section 4.2. after the third paragraph
The document supports two methods to present a ticket by client.
o A new IKEv2 exchange type called IKE_SESSION_RESUME. It's defined in
section 4.2.1
o A extension to generic IKEv2 IKE_SA_INIT exchange. It's defined in
section 4.2.2

(b)
Proposed text: section 4.2. before the fourth paragraph
4.2.1 Presenting a ticket by IKE_SESSION_RESUME

(c)
4.2.1 ==> 4.2.1.1

(d)
4,2,2 Presenting a Ticket: The DoS Case
==> 4,2,1.2 Presenting a Ticket by IKE_SESSION_RESUME: The DoS Case

(e)
4.2.3. Requesting a ticket during resumption
==> 4,2,1,3, Requesting a ticket by IKE_SESSION_RESUME during resumption

2008/12/7 ipsecme issue tracker <trac@tools.ietf.org>
#73: Ticket location: prefer server-side ticket
---------------------------------+------------------------------------------
 Reporter:  denghui02@gmail.com  |       Owner:  hannes.tschofenig@nsn.com
    Type:  defect               |      Status:  new
 Priority:  normal               |   Milestone:  milestone1
Component:  ikev2-resumption     |    Severity:  Active WG Document
 Keywords:                       |
---------------------------------+------------------------------------------
 The document should recommend "by reference", in preference to "by value"
 tickets; or make "by reference" a MUST, and "by value" a SHOULD/MAY.
 Mainly for the following two reasons:

 - Less bandwidth, by not sending the ticket.
 - IKEv2 messages, especially the first one, had better not be fragmented.

 See http://www.ietf.org/mail-archive/web/ipsec/current/msg03355.html and
 numerous follow-ups.

--
Ticket URL: <http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/73>
ipsecme <http://tools.ietf.org/ipsecme/>


------=_Part_25993_7420421.1232457493192-- --===============0597493426== 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 --===============0597493426==-- From ipsec-bounces@ietf.org Tue Jan 20 05:23:16 2009 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 A07DC3A6AE9; Tue, 20 Jan 2009 05:23:16 -0800 (PST) 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 E425A3A6AE9 for ; Tue, 20 Jan 2009 05:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 lbQ-C2RtWStm for ; Tue, 20 Jan 2009 05:23:15 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id C60463A67EC for ; Tue, 20 Jan 2009 05:23:14 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so2754915yxg.49 for ; Tue, 20 Jan 2009 05:22:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=+D6KL4vU/xm7uPRZGvaKsgOjnW03ZGl9IN1vz5Zi1H4=; b=QxdVBQe/JxAalTT9IDaYkQBzpiOtmqJr/9gv8Nsf5nxITjGbr1kaQgxS4/VwvypW7/ k7UHWRpBnVLt1DOjuq9c0r11CrJUCaSlDsjsdO38EGYPgrQ10wJOgj5iNVh0O+VDVvxP SH8r1j+0L2uVlxTXh8aYOKVTK8QW0ztNrAmjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=n8Ay7vUiEpwSnnJyL9nRqhOHd8kcNCnLj2HLIeDwsVN+imT6A/dm9X7AoFCc/S6iL+ zxS4VzL91UtapoIKjVl/8gdkO89EYjQR4OZpxqlvjgKpOsi/7DwkfozaAevlPhanMJp3 lHg/7cqUuhZgfzNXwrS53GqwYhr1Z7gdHoOFU= MIME-Version: 1.0 Received: by 10.100.126.19 with SMTP id y19mr4794641anc.2.1232457778357; Tue, 20 Jan 2009 05:22:58 -0800 (PST) In-Reply-To: <1d38a3350901100842x7b37805ayf60b61679f48e0bb@mail.gmail.com> References: <061.7ae35be7f65e375ae77802ad7cdff96b@tools.ietf.org> <1d38a3350901100842x7b37805ayf60b61679f48e0bb@mail.gmail.com> Date: Tue, 20 Jan 2009 21:22:58 +0800 Message-ID: <4c5c7a6d0901200522y53ab07f2ka74615f4483619be@mail.gmail.com> From: Peny Yang To: ipsec@ietf.org Subject: Re: [IPsec] [ipsecme] #73: Ticket location: prefer server-side ticket 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. I should propose the text following this issue tracking number. Please comment. Text Proposal ########################################### 1) Format of Ticket (TbV and TvR) Original text: none. Proposed text: 5.5 Format of TbV and TbR The TvV/TvR will be included in the ticket field of TICKET_OPAQUE (section 4.4) payload when it's requested by client or presented to gateway. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 01 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-++ !V!Rers! ! +-+-+-+- + ~ Encrypted Ticket ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++ V bit: 0 - TbV, 1-TbR Rers (3 bit): Reserved. 2) Protocol of ticket presenting After section 4.3 Proposed Text: 4.2.2. Presenting a ticket by extension of IKE_SA_INIT This document also supports the way of utilizing the generic IKEv2 IKE_SA_INIT exchange for session resumption. The client may initialize a regular IKE exchange without enclosing the TbV/TbR in the IKE_SA_INIT message. The client SHOULD NOT enclose the payloads of N(TICKET_OPAQUE), [N+,] and SK {IDi, [IDr,]}, unless it knows that the gateway supports it. The client should decide when it can use the IKE_SA_INIT exchange to do the session resumption, after it detects the interruption of IKEv2 responder. The client's decision may be based on the local policies. The ticket is only for one-time use, on matter it's on network side or client. When IKEv2 client detects the interruption of IKEv2 responder and decides to use the extension of IKE_SA_INIT exchange for session resumption, It will send the IKE_SA_INIT message as below: Initiator Responder ----------- ----------- HDR, SAi, KEi, Ni, N(TICKET_OPAQUE), [N+,] SK {IDi, [IDr,], [Ticket ID]} --> Figure: Ticket presenting by client The exchange type in HDR is set to 'IKE_SA_INIT'. KEi value is collected from the the old unexpired IKE_SA in client. When the IKEv2 gateway receives a IKE_SA_INIT with the payload of N(TICKET_OPAQUE). It MUST check the Ticket type in the V bit. If it's a TbR, gateway will use the reference to get the full content of ticket from somewhere in the network side. How to retrieve the ticket by reference is out of the scope in this document. If it's a TbV, gateway can get the content of ticket from this IKE_SA_INIT message. After ticket validation, one of the following steps if it supports the extension defined in this document: o If this IKE_SA_INIT message for session resumption is valid for gateway, it will accept it and the follow-up CREATE_CHILD_SA exchanges can be initiated by client. Initiator Responder ----------- ----------- <-- HDR, SK {IDr} Figure: IKEv2 gateway accepts the ticket the exchange type in HDR is set to 'IKE_SA_INIT'. o It responds with an regular IKE_SA_INIT response as defined in RFC4306, if it rejects the ticket for any reason (such as the example mentioned in section 4.2.1). In that case, the initiator can fall back to the regular IKE procedure. 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. 4.2.2.1 Protection of the IKE_SA_INIT extension for session resumption. The way is the same as defined in section 4.2.1.1 4.2.2.2 DoS case for IKE_SA_INIT extension for session resumption. When receiving the first message of the IKE_SA_INIT exchange for session resumption, the gateway may decide that it is under a denial-of-service attack. This document relies on the anti-DoS mechanism of generic IKE_SA_INIT exchange in RFC4306. 3) Message Protection After section 7.8 Proposed text: 7.9 Protection in IKE_SA_INIT exchange for session resumption This document relies on the anti-DoS and reply protection mechanism of generic IKE_SA_INIT exchange in RFC4306. > #73: Ticket location: prefer server-side ticket > ---------------------------------+------------------------------------------ > Reporter: denghui02@gmail.com | Owner: hannes.tschofenig@nsn.com > Type: defect | Status: new > Priority: normal | Milestone: milestone1 > Component: ikev2-resumption | Severity: Active WG Document > Keywords: | > ---------------------------------+------------------------------------------ > The document should recommend "by reference", in preference to "by value" > tickets; or make "by reference" a MUST, and "by value" a SHOULD/MAY. > Mainly for the following two reasons: > > - Less bandwidth, by not sending the ticket. > - IKEv2 messages, especially the first one, had better not be fragmented. > > See http://www.ietf.org/mail-archive/web/ipsec/current/msg03355.html and > numerous follow-ups. > > -- > Ticket URL: > ipsecme > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From mbelvin@aic-investments.com Tue Jan 20 05:43:27 2009 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 6D35D3A6BE3 for ; Tue, 20 Jan 2009 05:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.262 X-Spam-Level: X-Spam-Status: No, score=-13.262 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXqJfKkRuqZj for ; Tue, 20 Jan 2009 05:43:26 -0800 (PST) Received: from airbus.com (unknown [189.103.225.10]) by core3.amsl.com (Postfix) with SMTP id 9E9FB3A6AEC for ; Tue, 20 Jan 2009 05:43:25 -0800 (PST) To: Subject: Next: Getting the best results From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090120134325.9E9FB3A6AEC@core3.amsl.com> Date: Tue, 20 Jan 2009 05:43:25 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Dont see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.harmonymind.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://harmonymind.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 1, B133. 618 Clements Road. London. SE72 0DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From ipsec-bounces@ietf.org Tue Jan 20 14:58:40 2009 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 18C783A6A4B; Tue, 20 Jan 2009 14:58:40 -0800 (PST) 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 3AE103A6A4B for ; Tue, 20 Jan 2009 14:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 aRvH9JQn2ZpP for ; Tue, 20 Jan 2009 14:58:35 -0800 (PST) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by core3.amsl.com (Postfix) with ESMTP id 278E33A6A33 for ; Tue, 20 Jan 2009 14:58:35 -0800 (PST) Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44]) by g5t0007.atlanta.hp.com (Postfix) with ESMTP id 6225F14A26; Tue, 20 Jan 2009 22:58:18 +0000 (UTC) Received: from ldl.fc.hp.com (ldl.fc.hp.com [15.11.146.30]) by g1t0038.austin.hp.com (Postfix) with ESMTP id 437253007D; Tue, 20 Jan 2009 22:58:17 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl.fc.hp.com (Postfix) with ESMTP id CC6BE39C007; Tue, 20 Jan 2009 15:58:16 -0700 (MST) X-Virus-Scanned: Debian amavisd-new at ldl.fc.hp.com Received: from ldl.fc.hp.com ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEBcIngMEeLw; Tue, 20 Jan 2009 15:58:14 -0700 (MST) Received: from flek.lan (squirrel.fc.hp.com [15.11.146.57]) by ldl.fc.hp.com (Postfix) with ESMTP id C082139C011; Tue, 20 Jan 2009 15:58:13 -0700 (MST) From: Paul Moore Organization: Hewlett-Packard To: ipsec@ietf.org Date: Tue, 20 Jan 2009 17:58:08 -0500 User-Agent: KMail/1.9.10 References: <1231790397.5251.40.camel@faith.austin.ibm.com> In-Reply-To: <1231790397.5251.40.camel@faith.austin.ibm.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200901201758.08137.paul.moore@hp.com> Cc: serue@us.ibm.com, selinux@tycho.nsa.gov, gcwilson@us.ibm.com, tjaeger@cse.psu.edu, Joy Latten Subject: Re: [IPsec] IPsec Security Context drafts 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 Monday 12 January 2009 2:59:57 pm Joy Latten wrote: > The following IPsec Security Context drafts were announced last week. > > We would appreciate any comments, suggestions or reviews. [NOTE: I've CC'd the SELinux mailing list since this draft was also announced there] > http://www.ietf.org/internet-drafts/draft-jml-ipsec-ikev2-security-co >ntext-00.txt > > Filename: draft-jml-ipsec-ikev2-security-context > Revision: 00 > Title: Security Context Addendum to IPsec > Creation_date: 2009-01-08 > WG ID: Independent Submission > Number_of_pages: 12 Hello, I've only had a chance to read the IKEv2 version of the drafts but I believe that most of my comments apply to the IKEv1 version of the draft as well. My comments are below, ordered by section: * Section 1 (Introduction) - In paragraph two, second sentence it might be nice to mention that sensitivity levels are hierarchical and categories are not. - In paragraph three you mention that domain type enforcement is not hierarchical but fail to explain how it differs from the MLS concept of categories which is also a non-hierarchical security attribute. - In paragraph three you mention "exempt tasks" but it is not clear to me what you are referring to. - In paragraph five you mention how RFC1108 when used in conjunction with FIPS-188 would enable additional security attributes (assumed to be DTE attributes), why is RFC1108 needed? Why not just FIPS-188? * Section 3 (Labeled Networking) - In paragraph two you only mention data export, text on data import is missing. - In paragraph four and five you talk about using IPsec to protect both implicitly and explicitly labeled network traffic, it would be helpful if you could explain why implicit labeling is needed since the combination of IPsec and explicit labeling seems to address the issues you listed in section 1. * Section 3.1 (Relationship Between a Security Association ...) - It would be nice to mention in this section how to deal the potential for packets employing both AH and ESP with differing security contexts. * Section 3.2 (Security Context Selector) - In general I feel this section is not specific enough for implementation, e.g. in paragraph two how are traffic streams controlled via SPD security labels? - In paragraph three you don't mention how the security label assigned to a newly SA is determined. - In paragraph four you don't mention how the correct SA pair is determined. * Section 3.3 (Security Context Selector and PFP) - In this section you never mention how a SA created via PFP would arrive at the correct security label. In addition, while you describe SPD entries as "objects" from a security perspective it isn't clear if an SA's security label represents a "subject" or an "object". * Section 3.5 (Additional Outbound Processing) - What happens when an SA doesn't exist? Compare labeled versus unlabeled SPD entries and how a SA's security label is determined. - How are errors (unknown DOI, invalid label, etc.) and denials (access not allowed per security policy) handled? Is the sender notified, if so, how? * Section 3.6 (MAC Processing for Security Gateways) - In paragraph two you discuss the potential for forwarding packets with security attributes derived from either explicit labeling protocols, in this particular case how do you handle the traffic? Specifically, what happens to the explicit labeling information? What about security label translations? - In paragraph three you mention how outgoing forwarded traffic should be labeled using explicit labeling or security attributes of the destination, how is this determined and managed? - How are errors (unknown DOI, invalid label, etc.) and denials (access not allowed per security policy) handled? Is the sender notified, if so, how? * Section 4 (Security Context Transform) - I believe it should be a "MUST" that each SA in a bundle use the same security label. - The term "doi" should be capitalized since it is an acronym. - Is any part of the DOI space reserved for private use? * Section 4.1 (Attribute Negotiation) - On systems that support multiple DOIs, how is a DOI selected for outbound traffic? - More detail is needed on how the SA security label negotiation process works. * Section 4.3 - If a system's security policy for a given SPD entry only allows for a single SA with a specific security label, "MUST" is be willing to accept another SA? Why and how? -- paul moore linux @ hp _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 20 15:19:39 2009 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 D793428C0DE; Tue, 20 Jan 2009 15:19:39 -0800 (PST) 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 14FBA3A6A33 for ; Tue, 20 Jan 2009 15:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=-1.300, 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 U078D2eFK2Ms for ; Tue, 20 Jan 2009 15:19:37 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 3EB723A6866 for ; Tue, 20 Jan 2009 15:19:36 -0800 (PST) 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 n0KNJQ7A030822; Tue, 20 Jan 2009 18:19:26 -0500 Received: from apache by webmail.nist.gov with local (Exim 4.63) (envelope-from ) id 1LPPsK-0006ak-DD; Tue, 20 Jan 2009 18:19:16 -0500 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; Tue, 20 Jan 2009 18:19:16 -0500 Message-ID: <20090120181916.18552xfkjp2arvuc@webmail.nist.gov> Date: Tue, 20 Jan 2009 18:19:16 -0500 From: "Sheila Frankel" To: "gabriel montenegro" References: <596832.80321.qm@web82601.mail.mud.yahoo.com> In-Reply-To: <596832.80321.qm@web82601.mail.mud.yahoo.com> 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 Cc: ipsec@ietf.org Subject: Re: [IPsec] Question on draft-ietf-ipsecme-roadmap 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 felt that the area of cryptographic algorithms was one in which there's been a fair amount of confusion, so specifying Requirements Levels would be valuable. Are there other areas where you think this is the case? Sheila Quoting "gabriel montenegro" : > Overall good document. > I did notice that there are Requirements Levels specified quite > consistently in Section 4 > (Cryptographic Algorithms and Suites). > > What about the other sections? Is the intent to also specify > requirement levels in those sections as > well? > > Gabriel > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 21 04:17:35 2009 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 758923A67D8; Wed, 21 Jan 2009 04:17:35 -0800 (PST) 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 9B74C3A67D8 for ; Wed, 21 Jan 2009 04:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 SMCR37Jjz9QM for ; Wed, 21 Jan 2009 04:17:33 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9AFC03A677E for ; Wed, 21 Jan 2009 04:17:32 -0800 (PST) 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 n0LCH92l021407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 14:17:09 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0LCH9Xl025134; Wed, 21 Jan 2009 14:17:09 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18807.4677.574870.685258@fireball.kivinen.iki.fi> Date: Wed, 21 Jan 2009 14:17:09 +0200 From: Tero Kivinen To: Peny Yang In-Reply-To: <4c5c7a6d0901200518o549d295fyc1cc8054f86e0fcb@mail.gmail.com> References: <4c5c7a6d0901200518o549d295fyc1cc8054f86e0fcb@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: ipsec@ietf.org, Hui Deng Subject: [IPsec] Proposed text for working items of IKE session resumption 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 Peny Yang writes: > We collected the comments on the pros and cons of > ticket-by-value/ticket-by-reference, and related protocols. Hereby, we > proposed the text as below. Your comments are more than welcome. As the Ticket-by-reference vs Ticket-by-value is completely local matter for the gateway, I do not see any reason to make it visible for the client at all. The gateway can use any format it like to store that information, including using something like you propose (if it supports both), or just use value directly (if it only supports values, thus always knows it will get tickets by value all the time), or just use reference directly (in case it only supports that). Why is there any need to make standardized format for distinguishing ticket-by-reference and ticket-by-value? -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 21 04:33:37 2009 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 6000628C11B; Wed, 21 Jan 2009 04:33:37 -0800 (PST) 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 BADB428C11B for ; Wed, 21 Jan 2009 04:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 GXrfKXnLHhBg for ; Wed, 21 Jan 2009 04:33:36 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 988B728C0F6 for ; Wed, 21 Jan 2009 04:33:35 -0800 (PST) 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 n0LCXFSK010499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Jan 2009 14:33:15 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0LCXFXY009649; Wed, 21 Jan 2009 14:33:15 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18807.5643.444958.221999@fireball.kivinen.iki.fi> Date: Wed, 21 Jan 2009 14:33:15 +0200 From: Tero Kivinen To: "Hui Deng" In-Reply-To: <1d38a3350901200518u432e0df8n1efe9fa1b63e131b@mail.gmail.com> References: <061.7ae35be7f65e375ae77802ad7cdff96b@tools.ietf.org> <1d38a3350901200518u432e0df8n1efe9fa1b63e131b@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 12 min Cc: ipsec@ietf.org, hannes.tschofenig@nsn.com Subject: Re: [IPsec] [ipsecme] #73: Ticket location: prefer server-side ticket 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 Hui Deng writes: > 5.3 Location of ticket > The full-bodied content of ticket could be stored on client or network side. > If it's stored on client, it will be put in TbV. TbV presenting and > requesting can be found in section 4. The way of TbV encryption can > be found in section 7. > If it's stored in the network side, the operators shall allocate the > non-volatile memory space for gateways to store the tickets of all the > clients. How to build the ticket storage is out of the scope. This > ticket storage must be reachable for IKEv2 gateway. The reference of > the ticket is defined in 5.4. I am not really sure, how much this kind of implementation details is needed here. I think it would be better to just let this kind of details for the implementors to decide, not try to dictate something here. For example that text says that you cannot make implementation where the network crypto processors who normally take care of IKE SAs cannot offload unused IKE SAs to the slowpath central processor with much bigger RAM, as that RAM is not non-volatile. I think it is much better to just let that kind of implementation details to the implementors to decide, as they heavily depend on the scenario where the implementation is aimed for. I think it is good to say things that mandate that tickets by value MUST be encrypted, as that affects security. And it is good to say that tickets by reference does not need to be encrypted, as they do not contain any sensitive material (i.e all the sensitive material (i.e. crypto keys and so on) is stored on the location pointed by the reference), but that storage where that sensitive material is stored MUST be protected so that only unauthorized access is not allowed. > 2) Protocol of ticket presenting > (a) > Proposed text: section 4.2. after the third paragraph > The document supports two methods to present a ticket by client. > o A new IKEv2 exchange type called IKE_SESSION_RESUME. It's defined in > section 4.2.1 > o A extension to generic IKEv2 IKE_SA_INIT exchange. It's defined in > section 4.2.2 I do not think we want to add yet another complication to the IKE_SA_INIT by adding new extension for it. I think we should stick to the simple and understandable exchanges, meaning lets just use the separate IKE_SESSION_RESUME exchange. That allow modular building of new exchanges, and that offers simplier implementations, meaning less bugs... We already had earlier discussion about this, but wanted to just send my email telling that I am still against modifying IKE_SA_INIT exchange for session resumption, and want to use separate IKE_SESSION_RESUME exchange for it. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 21 05:25:27 2009 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 16BEB3A6A7C; Wed, 21 Jan 2009 05:25:27 -0800 (PST) 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 3776F28C0F6 for ; Wed, 21 Jan 2009 05:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 YtpI9wfqZ6mN for ; Wed, 21 Jan 2009 05:25:19 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id CC5673A677E for ; Wed, 21 Jan 2009 05:25:16 -0800 (PST) Received: (qmail invoked by alias); 21 Jan 2009 13:24:59 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp069) with SMTP; 21 Jan 2009 14:24:59 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19V8EVGRuRVRFm/Pr9vEhTYzaU+XSHeE7H1XLv1Fo CRyo/3VZ/aF52k From: "Hannes Tschofenig" To: "'Tero Kivinen'" , "'Peny Yang'" References: <4c5c7a6d0901200518o549d295fyc1cc8054f86e0fcb@mail.gmail.com> <18807.4677.574870.685258@fireball.kivinen.iki.fi> Date: Wed, 21 Jan 2009 15:25:37 +0200 Message-ID: <02fe01c97bcb$bfecbb30$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <18807.4677.574870.685258@fireball.kivinen.iki.fi> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl7wjYzOzNniAqNTr22NrI6XreD9gACYIYA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Cc: ipsec@ietf.org, 'Hui Deng' Subject: Re: [IPsec] Proposed text for working items of IKE session resumption 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 agree with you, Tero. Ciao Hannes >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >On Behalf Of Tero Kivinen >Sent: 21 January, 2009 14:17 >To: Peny Yang >Cc: ipsec@ietf.org; Hui Deng >Subject: [IPsec] Proposed text for working items of IKE >session resumption > >Peny Yang writes: >> We collected the comments on the pros and cons of >> ticket-by-value/ticket-by-reference, and related protocols. >Hereby, we >> proposed the text as below. Your comments are more than welcome. > >As the Ticket-by-reference vs Ticket-by-value is completely >local matter for the gateway, I do not see any reason to make >it visible for the client at all. > >The gateway can use any format it like to store that >information, including using something like you propose (if it >supports both), or just use value directly (if it only >supports values, thus always knows it will get tickets by >value all the time), or just use reference directly (in case >it only supports that). > >Why is there any need to make standardized format for >distinguishing ticket-by-reference and ticket-by-value? >-- >kivinen@iki.fi >_______________________________________________ >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 Wed Jan 21 05:38:02 2009 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 EE94728C127; Wed, 21 Jan 2009 05:38:01 -0800 (PST) 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 7B40628C127 for ; Wed, 21 Jan 2009 05:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, 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 MkSL4Qfaxjit for ; Wed, 21 Jan 2009 05:37:59 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2723328C0E4 for ; Wed, 21 Jan 2009 05:37:58 -0800 (PST) Received: (qmail invoked by alias); 21 Jan 2009 13:37:40 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp054) with SMTP; 21 Jan 2009 14:37:40 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18bZjsuU9obOj/LWVqCBGRZmQmq1v9C/+ffcV3n7Z TWU1iRPLHai4pB From: "Hannes Tschofenig" To: "'Tero Kivinen'" , "'Hui Deng'" References: <061.7ae35be7f65e375ae77802ad7cdff96b@tools.ietf.org><1d38a3350901200518u432e0df8n1efe9fa1b63e131b@mail.gmail.com> <18807.5643.444958.221999@fireball.kivinen.iki.fi> Date: Wed, 21 Jan 2009 15:38:18 +0200 Message-ID: <02ff01c97bcd$85a7d250$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <18807.5643.444958.221999@fireball.kivinen.iki.fi> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl7xHOZxuYFt8OCTKyQyUiV0CZraQAB4aGw X-Y-GMX-Trusted: 0 X-FuHaFi: 0.59 Cc: ipsec@ietf.org, "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [IPsec] [ipsecme] #73: Ticket location: preferserver-side ticket 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, Hui, >Hui Deng writes: >> 5.3 Location of ticket >> The full-bodied content of ticket could be stored on client >or network side. >> If it's stored on client, it will be put in TbV. TbV presenting and >> requesting can be found in section 4. The way of TbV encryption can >> be found in section 7. >> If it's stored in the network side, the operators shall allocate the >> non-volatile memory space for gateways to store the tickets >of all the >> clients. How to build the ticket storage is out of the scope. This >> ticket storage must be reachable for IKEv2 gateway. The reference of >> the ticket is defined in 5.4. > >I am not really sure, how much this kind of implementation >details is needed here. I think it would be better to just let >this kind of details for the implementors to decide, not try >to dictate something here. > >For example that text says that you cannot make implementation >where the network crypto processors who normally take care of >IKE SAs cannot offload unused IKE SAs to the slowpath central >processor with much bigger RAM, as that RAM is not non-volatile. > >I think it is much better to just let that kind of >implementation details to the implementors to decide, as they >heavily depend on the scenario where the implementation is aimed for. > >I think it is good to say things that mandate that tickets by >value MUST be encrypted, as that affects security. And it is >good to say that tickets by reference does not need to be >encrypted, as they do not contain any sensitive material (i.e >all the sensitive material (i.e. crypto keys and so on) is >stored on the location pointed by the reference), but that >storage where that sensitive material is stored MUST be >protected so that only unauthorized access is not allowed. > I again have to agree with Tero. These are nice details but go far too much into the implementation space. >> 2) Protocol of ticket presenting >> (a) >> Proposed text: section 4.2. after the third paragraph The document >> supports two methods to present a ticket by client. >> o A new IKEv2 exchange type called IKE_SESSION_RESUME. It's >defined in >> section 4.2.1 o A extension to generic IKEv2 IKE_SA_INIT exchange. >> It's defined in section 4.2.2 > >I do not think we want to add yet another complication to the >IKE_SA_INIT by adding new extension for it. I think we should >stick to the simple and understandable exchanges, meaning lets >just use the separate IKE_SESSION_RESUME exchange. That allow >modular building of new exchanges, and that offers simplier >implementations, meaning less bugs... > >We already had earlier discussion about this, but wanted to >just send my email telling that I am still against modifying >IKE_SA_INIT exchange for session resumption, and want to use >separate IKE_SESSION_RESUME exchange for it. I am not seeing any need to change the current approach outlined in the document. At http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/74 some arguments were provided by Peng for re-using the IKE_SA_INIT exchange, namely * simpler implementation * more efficient. As mentioned previously, Florian Tegeler has implemented the session resumption code and he did not find it complex to implement. Sure, there is a learning curve to get into the specific IKEv2 code but it is not a large enhance nor a large specification. For sure, the exact amount of time it takes to implement this extension depends on the specific implementation of IKEv2 and how easy it is to extend the code. I had a hard time to see the efficiency argument given that you are presenting the ticket to a server that has previously provided you that ticket. I am a bit reluctant to change the currently described approach just for the fun of it. Ciao Hannes >-- >kivinen@iki.fi >_______________________________________________ >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 khader@accuchex.com Wed Jan 21 05:49:48 2009 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 2A9E33A6A4C for ; Wed, 21 Jan 2009 05:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.262 X-Spam-Level: X-Spam-Status: No, score=-13.262 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwzsSZL3NBhf for ; Wed, 21 Jan 2009 05:49:46 -0800 (PST) Received: from alfains.com (unknown [88.224.132.227]) by core3.amsl.com (Postfix) with SMTP id 4B5EE3A694F for ; Wed, 21 Jan 2009 05:49:43 -0800 (PST) To: Subject: Welcome to eBay! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090121134944.4B5EE3A694F@core3.amsl.com> Date: Wed, 21 Jan 2009 05:49:43 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.witguess.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://witguess.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 3, B424. 682 Clements Road. London. SE73 1DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From ipsec-bounces@ietf.org Wed Jan 21 06:49:17 2009 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 E5FD528C143; Wed, 21 Jan 2009 06:49:17 -0800 (PST) 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 EEF6328C143 for ; Wed, 21 Jan 2009 06:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.364, 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 GigeHbIULd7o for ; Wed, 21 Jan 2009 06:49:15 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id CE0E03A6B4A for ; Wed, 21 Jan 2009 06:49:15 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so2168088wag.5 for ; Wed, 21 Jan 2009 06:48:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ypw+NtzxUKtalmpcYP4iqnwBu3iaD993fz1aqFYskNQ=; b=EhthtOxAby4PsInvV4xHSnkDSRu8hiOJw79VXiqpQqIuNvJgnGpH19xoetnfE1hEOw e6u1raW9hSVgPP/lqxGom19tLW2ywTqdekhEg81cS3kqjBFVOTxCEHneqkZonakI97vO WOFn0uEEE2w4+UVm4ZWTs+xLJcJ8fKWAK3Vr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sSFPlVQVOCp63aF+DnsWJUtjk1mAdtmSVtXjodz8Tb3Zq2ZdLgY+aC/EPj1bFOM3Ua UezLIyMbEfGQzG6IWEVA3KpZu58FtfqIg3ZhVdqxaSGU2iQI7r2ucjRQvVR+v3LMeV8w iboGEL1c1PYOvVEohcaPmp5YHmdLd/hH/LElU= MIME-Version: 1.0 Received: by 10.115.32.1 with SMTP id k1mr5775120waj.66.1232549339692; Wed, 21 Jan 2009 06:48:59 -0800 (PST) In-Reply-To: <18807.5643.444958.221999@fireball.kivinen.iki.fi> References: <061.7ae35be7f65e375ae77802ad7cdff96b@tools.ietf.org> <1d38a3350901200518u432e0df8n1efe9fa1b63e131b@mail.gmail.com> <18807.5643.444958.221999@fireball.kivinen.iki.fi> Date: Wed, 21 Jan 2009 22:48:59 +0800 Message-ID: <1d38a3350901210648v1b90f540tdbcdaa90459f9019@mail.gmail.com> From: Hui Deng To: Tero Kivinen Cc: ipsec@ietf.org, hannes.tschofenig@nsn.com Subject: Re: [IPsec] [ipsecme] #73: Ticket location: prefer server-side ticket 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="===============1413927294==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1413927294== Content-Type: multipart/alternative; boundary=0016364c600d8f7eb70460ff41d4 --0016364c600d8f7eb70460ff41d4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit thanks for your discussion, 2009/1/21 Tero Kivinen > Hui Deng writes: > > 5.3 Location of ticket > > The full-bodied content of ticket could be stored on client or network > side. > > If it's stored on client, it will be put in TbV. TbV presenting and > > requesting can be found in section 4. The way of TbV encryption can > > be found in section 7. > > If it's stored in the network side, the operators shall allocate the > > non-volatile memory space for gateways to store the tickets of all the > > clients. How to build the ticket storage is out of the scope. This > > ticket storage must be reachable for IKEv2 gateway. The reference of > > the ticket is defined in 5.4. > > I am not really sure, how much this kind of implementation details is > needed here. I think it would be better to just let this kind of > details for the implementors to decide, not try to dictate something > here. > > For example that text says that you cannot make implementation where > the network crypto processors who normally take care of IKE SAs cannot > offload unused IKE SAs to the slowpath central processor with much > bigger RAM, as that RAM is not non-volatile. > > I think it is much better to just let that kind of implementation > details to the implementors to decide, as they heavily depend on the > scenario where the implementation is aimed for. > > I think it is good to say things that mandate that tickets by value > MUST be encrypted, as that affects security. And it is good to say > that tickets by reference does not need to be encrypted, as they do > not contain any sensitive material (i.e all the sensitive material > (i.e. crypto keys and so on) is stored on the location pointed by the > reference), but that storage where that sensitive material is stored > MUST be protected so that only unauthorized access is not allowed. It looks good for me, thanks, > > > 2) Protocol of ticket presenting > > (a) > > Proposed text: section 4.2. after the third paragraph > > The document supports two methods to present a ticket by client. > > o A new IKEv2 exchange type called IKE_SESSION_RESUME. It's defined in > > section 4.2.1 > > o A extension to generic IKEv2 IKE_SA_INIT exchange. It's defined in > > section 4.2.2 > > I do not think we want to add yet another complication to the > IKE_SA_INIT by adding new extension for it. I think we should stick to > the simple and understandable exchanges, meaning lets just use the > separate IKE_SESSION_RESUME exchange. That allow modular building of > new exchanges, and that offers simplier implementations, meaning less > bugs... > > We already had earlier discussion about this, but wanted to just send > my email telling that I am still against modifying IKE_SA_INIT > exchange for session resumption, and want to use separate > IKE_SESSION_RESUME exchange for it. We've already discussed the pros and cons of both ways. I think both way could be added to the text. The implementors can choose one of way they like. We cann't refuse some customer's requirement. Thanks for your consideration. -Hui > > -- > kivinen@iki.fi > --0016364c600d8f7eb70460ff41d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable thanks for your discussion,

2009/1/21 Tero Kivinen <kivinen@iki.fi>
Hui Deng writes:
> 5.3 Location of ticket
&g= t; The full-bodied content of ticket could be stored on client or network s= ide.
> If it's stored on client, it will be put in TbV. TbV prese= nting and
> requesting can be found in section 4.  The way of TbV encryption = can
> be found in section 7.
> If it's stored in the networ= k side, the operators shall allocate the
> non-volatile memory space = for gateways to store the tickets of all the
> clients. How to build the ticket storage is out of the scope. This
= > ticket storage must be reachable for IKEv2 gateway. The reference of> the ticket is defined in 5.4.

I am not really sure, how= much this kind of implementation details is
needed here. I think it would be better to just let this kind of
details= for the implementors to decide, not try to dictate something
here.
<= br>For example that text says that you cannot make implementation where
the network crypto processors who normally take care of IKE SAs cannot
o= ffload unused IKE SAs to the slowpath central processor with much
bigger= RAM, as that RAM is not non-volatile.

I think it is much better to = just let that kind of implementation
details to the implementors to decide, as they heavily depend on the
sce= nario where the implementation is aimed for.

I think it is good to s= ay things that mandate that tickets by value
MUST be encrypted, as that = affects security. And it is good to say
that tickets by reference does not need to be encrypted, as they do
not = contain any sensitive material (i.e all the sensitive material
(i.e. cry= pto keys and so on) is stored on the location pointed by the
reference),= but that storage where that sensitive material is stored
MUST be protected so that only unauthorized access is not allowed.
It looks good for me, thanks,
 
 

> 2) Protocol of ticket p= resenting
> (a)
> Proposed text: section 4.2. after the third p= aragraph
> The document supports two methods to present a ticket by c= lient.
> o A new IKEv2 exchange type called IKE_SESSION_RESUME. It's define= d in
> section 4.2.1
> o A extension to generic IKEv2 IKE_SA_IN= IT exchange. It's defined in
> section 4.2.2

I do no= t think we want to add yet another complication to the
IKE_SA_INIT by adding new extension for it. I think we should stick to
t= he simple and understandable exchanges, meaning lets just use the
separa= te IKE_SESSION_RESUME exchange. That allow modular building of
new excha= nges, and that offers simplier implementations, meaning less
bugs...

We already had earlier discussion about this, but wanted to = just send
my email telling that I am still against modifying IKE_SA_INIT=
exchange for session resumption, and want to use separate
IKE_SESSIO= N_RESUME exchange for it.
We've already discussed the pros and cons of both ways. I thinkboth way could be added to the text. The implementors can choose one
of=  way they like. We cann't refuse some customer's requirement.<= /div>
 
Thanks for your consideration.
 
-Hui
 

--
kivinen@iki.fi=

--0016364c600d8f7eb70460ff41d4-- --===============1413927294== 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 --===============1413927294==-- From ipsec-bounces@ietf.org Wed Jan 21 07:27:17 2009 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 4E09E28C159; Wed, 21 Jan 2009 07:27:17 -0800 (PST) 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 11EB228C162 for ; Wed, 21 Jan 2009 07:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.383, 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 oCsqwsr5oREk for ; Wed, 21 Jan 2009 07:27:14 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id A1FA528C159 for ; Wed, 21 Jan 2009 07:27:14 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id n4so2175784wag.5 for ; Wed, 21 Jan 2009 07:26:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=99TPEgp7yybvpOon5HjNp+2Hrnc+Bv2ke92urHp8XCw=; b=o0gDBiXYdt5ijgM36ibLjGltsAhYf/2bJjdgB+/USDRu41an3eU9AloGhgMp8DFxIn zcV73aBhJSEIV33HHZXkXFyp6IRmY2R1CKR3vCJqmvXxJNXJMY5ns9jb+VV/6hAUWjMo hgiZmv0Mxnx+Gt29VdcXfM+FPM3dSqeYe4ljI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=X0+579u9uclgND7kEIXgt64z2TPsmWsh+yxrucV+vfMiYeF0zyG4phmOk+IZD1EnDZ KE66bD7LO9c0nH+jdpe/xnKtAk3qK0OSSplsi871d9HxKtUIZYtxegr3YtMQmnLHRDSr be7s4tMun4HkTpY+N+cC+vUKza+G6BRnCVvdE= MIME-Version: 1.0 Received: by 10.114.74.18 with SMTP id w18mr5775264waa.205.1232551617575; Wed, 21 Jan 2009 07:26:57 -0800 (PST) In-Reply-To: <02ff01c97bcd$85a7d250$0201a8c0@nsnintra.net> References: <061.7ae35be7f65e375ae77802ad7cdff96b@tools.ietf.org> <1d38a3350901200518u432e0df8n1efe9fa1b63e131b@mail.gmail.com> <18807.5643.444958.221999@fireball.kivinen.iki.fi> <02ff01c97bcd$85a7d250$0201a8c0@nsnintra.net> Date: Wed, 21 Jan 2009 23:26:57 +0800 Message-ID: <1d38a3350901210726s6601f1bfi81919ed4c2445400@mail.gmail.com> From: Hui Deng To: Hannes Tschofenig Cc: ipsec@ietf.org, "Tschofenig, Hannes \(NSN - FI/Espoo\)" , Tero Kivinen Subject: Re: [IPsec] [ipsecme] #73: Ticket location: preferserver-side ticket 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="===============0512365675==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0512365675== Content-Type: multipart/alternative; boundary=001636417931553dbc0460ffc95f --001636417931553dbc0460ffc95f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hannes, Thanks for pointing out one implementation example, let's not tightly coupled with simplicity and complexity. What we would like to raise is that one possible advantage of our proposed text has been missed is falling back to regular IKE session. Thanks for the discussion. -Hui 2009/1/21 Hannes Tschofenig > Tero, Hui, > > >Hui Deng writes: > >> 5.3 Location of ticket > >> The full-bodied content of ticket could be stored on client > >or network side. > >> If it's stored on client, it will be put in TbV. TbV presenting and > >> requesting can be found in section 4. The way of TbV encryption can > >> be found in section 7. > >> If it's stored in the network side, the operators shall allocate the > >> non-volatile memory space for gateways to store the tickets > >of all the > >> clients. How to build the ticket storage is out of the scope. This > >> ticket storage must be reachable for IKEv2 gateway. The reference of > >> the ticket is defined in 5.4. > > > >I am not really sure, how much this kind of implementation > >details is needed here. I think it would be better to just let > >this kind of details for the implementors to decide, not try > >to dictate something here. > > > >For example that text says that you cannot make implementation > >where the network crypto processors who normally take care of > >IKE SAs cannot offload unused IKE SAs to the slowpath central > >processor with much bigger RAM, as that RAM is not non-volatile. > > > >I think it is much better to just let that kind of > >implementation details to the implementors to decide, as they > >heavily depend on the scenario where the implementation is aimed for. > > > >I think it is good to say things that mandate that tickets by > >value MUST be encrypted, as that affects security. And it is > >good to say that tickets by reference does not need to be > >encrypted, as they do not contain any sensitive material (i.e > >all the sensitive material (i.e. crypto keys and so on) is > >stored on the location pointed by the reference), but that > >storage where that sensitive material is stored MUST be > >protected so that only unauthorized access is not allowed. > > > > I again have to agree with Tero. These are nice details but go far too much > into the implementation space. > > >> 2) Protocol of ticket presenting > >> (a) > >> Proposed text: section 4.2. after the third paragraph The document > >> supports two methods to present a ticket by client. > >> o A new IKEv2 exchange type called IKE_SESSION_RESUME. It's > >defined in > >> section 4.2.1 o A extension to generic IKEv2 IKE_SA_INIT exchange. > >> It's defined in section 4.2.2 > > > >I do not think we want to add yet another complication to the > >IKE_SA_INIT by adding new extension for it. I think we should > >stick to the simple and understandable exchanges, meaning lets > >just use the separate IKE_SESSION_RESUME exchange. That allow > >modular building of new exchanges, and that offers simplier > >implementations, meaning less bugs... > > > >We already had earlier discussion about this, but wanted to > >just send my email telling that I am still against modifying > >IKE_SA_INIT exchange for session resumption, and want to use > >separate IKE_SESSION_RESUME exchange for it. > > I am not seeing any need to change the current approach outlined in the > document. > > At http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/74 some arguments > were > provided by Peng for re-using the IKE_SA_INIT exchange, namely > * simpler implementation > * more efficient. > > As mentioned previously, Florian Tegeler has implemented the session > resumption code and he did not find it complex to implement. Sure, there > is > a learning curve to get into the specific IKEv2 code but it is not a large > enhance nor a large specification. For sure, the exact amount of time it > takes to implement this extension depends on the specific implementation of > IKEv2 and how easy it is to extend the code. > > I had a hard time to see the efficiency argument given that you are > presenting the ticket to a server that has previously provided you that > ticket. > > I am a bit reluctant to change the currently described approach just for > the > fun of it. > > Ciao > Hannes > > >-- > >kivinen@iki.fi > >_______________________________________________ > >IPsec mailing list > >IPsec@ietf.org > >https://www.ietf.org/mailman/listinfo/ipsec > > > > --001636417931553dbc0460ffc95f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hannes,
 
Thanks for pointing out one implementation example,
let's not tightly coupled with simplicity and complexity.
 
What we would like to raise is that one possible advantage of our prop= osed text has been missed is falling back to regular IKE session.
 
Thanks for the discussion.
 
-Hui
2009/1/21 Hannes Tschofenig &l= t;Hannes.Tschofenig@gmx.net>
Tero, Hui,

>Hui Deng writes:
>> 5.3 Location of = ticket
>> The full-bodied content of ticket could be stored on cli= ent
>or network side.
>> If it's stored on client, it wi= ll be put in TbV. TbV presenting and
>> requesting can be found in section 4.  The way of TbV encrypt= ion can
>> be found in section 7.
>> If it's stored i= n the network side, the operators shall allocate the
>> non-volati= le memory space for gateways to store the tickets
>of all the
>> clients. How to build the ticket storage is out = of the scope. This
>> ticket storage must be reachable for IKEv2 g= ateway. The reference of
>> the ticket is defined in 5.4.
><= br> >I am not really sure, how much this kind of implementation
>detai= ls is needed here. I think it would be better to just let
>this kind = of details for the implementors to decide, not try
>to dictate someth= ing here.
>
>For example that text says that you cannot make implementation<= br>>where the network crypto processors who normally take care of
>= ;IKE SAs cannot offload unused IKE SAs to the slowpath central
>proce= ssor with much bigger RAM, as that RAM is not non-volatile.
>
>I think it is much better to just let that kind of
>imple= mentation details to the implementors to decide, as they
>heavily dep= end on the scenario where the implementation is aimed for.
>
>I= think it is good to say things that mandate that tickets by
>value MUST be encrypted, as that affects security. And it is
>goo= d to say that tickets by reference does not need to be
>encrypted, as= they do not contain any sensitive material (i.e
>all the sensitive m= aterial (i.e. crypto keys and so on) is
>stored on the location pointed by the reference), but that
>stora= ge where that sensitive material is stored MUST be
>protected so that= only unauthorized access is not allowed.
>

I agai= n have to agree with Tero. These are nice details but go far too much
into the implementation space.

>> 2) Protocol of ticket presenting
>= > (a)
>> Proposed text: section 4.2. after the third paragraph = The document
>> supports two methods to present a ticket by client= .
>> o A new IKEv2 exchange type called IKE_SESSION_RESUME. It's>defined in
>> section 4.2.1 o A extension to generic IKEv2 IK= E_SA_INIT exchange.
>> It's defined in section 4.2.2
> >I do not think we want to add yet another complication to the
>IK= E_SA_INIT by adding new extension for it. I think we should
>stick to= the simple and understandable exchanges, meaning lets
>just use the = separate IKE_SESSION_RESUME exchange. That allow
>modular building of new exchanges, and that offers simplier
>impl= ementations, meaning less bugs...
>
>We already had earlier dis= cussion about this, but wanted to
>just send my email telling that I = am still against modifying
>IKE_SA_INIT exchange for session resumption, and want to use
>sep= arate IKE_SESSION_RESUME exchange for it.

I am not seeing any = need to change the current approach outlined in the
document.

At http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/74 some a= rguments were
provided by Peng for re-using the IKE_SA_INIT exchange, na= mely
* simpler implementation
* more efficient.

As mentioned previousl= y, Florian Tegeler has implemented the session
resumption code and  = ;he did not find it complex to implement. Sure, there is
a learning curv= e to get into the specific IKEv2 code but it is not a large
enhance nor a large specification. For sure, the exact amount of time ittakes to implement this extension depends on the specific implementation o= f
IKEv2 and how easy it is to extend the code.

I had a hard time = to see the efficiency argument given that you are
presenting the ticket to a server that has previously provided you that
= ticket.

I am a bit reluctant to change the currently described appro= ach just for the
fun of it.

Ciao
Hannes

>--
><= a href=3D"mailto:kivinen@iki.fi">kivinen@iki.fi
>_______________________________________________>IPsec mailing list
>IPsec@iet= f.org
>https://www.ietf.org/mailman/listinfo/ipsec
>


--001636417931553dbc0460ffc95f-- --===============0512365675== 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 --===============0512365675==-- From ipsec-bounces@ietf.org Wed Jan 21 07:32:16 2009 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 0A84C3A68C0; Wed, 21 Jan 2009 07:32:16 -0800 (PST) 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 DF15A3A68C0 for ; Wed, 21 Jan 2009 07:32:14 -0800 (PST) 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 RxQZir5n+T5R for ; Wed, 21 Jan 2009 07:32:14 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 1B0383A67F4 for ; Wed, 21 Jan 2009 07:32:14 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so3223300yxg.49 for ; Wed, 21 Jan 2009 07:31:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2XegPEQyeqmilXVejUI9N7xkPYtpbKBTcvWKCR+KgfY=; b=m3ijmupt3s9kRVQGqMONYQ7u1pJR4YOJKUyBQbEbMtwxFfJwCh+rSWo6oHRtjs5R4A 7YjYRdahmN459lLSsnfrdpFniqHwSHGAxnnfiVRTKHDIz8CbWy6IjAs/PMwYcFsUlxhp TK/VQ6YDY2KfrypUvodXYhbAHbkVSnahS4xSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=xmpZ15PXUxt1sF///LV2aYHjQCX8Ee5T8nPld6uDETUvHeQMqTkjdlDLlkTBAsbwP7 /6Kc6E9FEwdYrFvw15j3YfTQUFn28tKtaaNZvZ+x0nECTItFqSygNNS5Ym9PV98iv4im 2ehVIFa9ZUmLVnuJnvbVWm2+KlFtDEfVYEMbY= MIME-Version: 1.0 Received: by 10.100.133.2 with SMTP id g2mr2077618and.134.1232551917503; Wed, 21 Jan 2009 07:31:57 -0800 (PST) In-Reply-To: <18807.4677.574870.685258@fireball.kivinen.iki.fi> References: <4c5c7a6d0901200518o549d295fyc1cc8054f86e0fcb@mail.gmail.com> <18807.4677.574870.685258@fireball.kivinen.iki.fi> Date: Wed, 21 Jan 2009 23:31:57 +0800 Message-ID: <4c5c7a6d0901210731k5a94be08x898a3460d4db57fd@mail.gmail.com> From: Peny Yang To: Tero Kivinen Cc: ipsec@ietf.org, Hui Deng Subject: Re: [IPsec] Proposed text for working items of IKE session resumption 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 Wed, Jan 21, 2009 at 8:17 PM, Tero Kivinen wrote: > The gateway can use any format it like to store that information, > including using something like you propose (if it supports both), or > just use value directly (if it only supports values, thus always knows > it will get tickets by value all the time), or just use reference > directly (in case it only supports that). > > Why is there any need to make standardized format for distinguishing > ticket-by-reference and ticket-by-value? [Peny] We propose this, because some people gave the comments that it's better to have a format for TbV and TbR. And, we made the V bit visible because it's easier for the Gateway to decide the follow-up actions by this V bit, before de-cryption of ticket. And if some vendors would like to store the tickets and en/de-cryption functions in a separated equipment other than the gateway, this visible V bit provides more flexibility. Peny _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 21 08:13:52 2009 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 E3E683A6998; Wed, 21 Jan 2009 08:13:52 -0800 (PST) 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 43B0F28C15F for ; Wed, 21 Jan 2009 08:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.286, 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 0+4fcNr0I4Ks for ; Wed, 21 Jan 2009 08:13:48 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C3B843A67D8 for ; Wed, 21 Jan 2009 08:13:47 -0800 (PST) Received: (qmail invoked by alias); 21 Jan 2009 16:13:27 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp015) with SMTP; 21 Jan 2009 17:13:27 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/8FFdm8t78qOlwpYIDKTziANzfanA1db0I9RVy1B 9/In2lvGzjlRp5 From: "Hannes Tschofenig" To: "'ext Hui Deng'" , "'Hannes Tschofenig'" Date: Wed, 21 Jan 2009 18:14:02 +0200 Message-ID: <030301c97be3$48e6d5d0$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acl740YWr1vxovv6SpO0gl1PB3qObA== X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55,0.57 Cc: ipsec@ietf.org, 'Tero Kivinen' Subject: Re: [IPsec] [ipsecme] #73: Ticket location: preferserver-side ticket 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="===============0536194527==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0536194527== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0304_01C97BF4.0C6FA5D0" This is a multi-part message in MIME format. ------=_NextPart_000_0304_01C97BF4.0C6FA5D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Hui, I appreciate that you raise this issue. There are certainly different design directions that can be taken and I understand why you propose the usage of IKE_SA_INIT. I even believe that it was described in the former draft versions. The reason for not going along that path was the fact that you you are very unlikely going to observe this performance optimization by falling back to a regular IKEv2 exchange. The problem is just that this should not happen since you only provide the ticket to someone that previously gave it to you. You also know how long the ticket is considered to be valid. Hence, the "optimization" would only work in extremely rare cases when something went wong. Let's see what the other folks think. Ciao Hannes Hannes, Thanks for pointing out one implementation example, let's not tightly coupled with simplicity and complexity. What we would like to raise is that one possible advantage of our proposed text has been missed is falling back to regular IKE session. Thanks for the discussion. -Hui 2009/1/21 Hannes Tschofenig Tero, Hui, >Hui Deng writes: >> 5.3 Location of ticket >> The full-bodied content of ticket could be stored on client >or network side. >> If it's stored on client, it will be put in TbV. TbV presenting and >> requesting can be found in section 4. The way of TbV encryption can >> be found in section 7. >> If it's stored in the network side, the operators shall allocate the >> non-volatile memory space for gateways to store the tickets >of all the >> clients. How to build the ticket storage is out of the scope. This >> ticket storage must be reachable for IKEv2 gateway. The reference of >> the ticket is defined in 5.4. > >I am not really sure, how much this kind of implementation >details is needed here. I think it would be better to just let >this kind of details for the implementors to decide, not try >to dictate something here. > >For example that text says that you cannot make implementation >where the network crypto processors who normally take care of >IKE SAs cannot offload unused IKE SAs to the slowpath central >processor with much bigger RAM, as that RAM is not non-volatile. > >I think it is much better to just let that kind of >implementation details to the implementors to decide, as they >heavily depend on the scenario where the implementation is aimed for. > >I think it is good to say things that mandate that tickets by >value MUST be encrypted, as that affects security. And it is >good to say that tickets by reference does not need to be >encrypted, as they do not contain any sensitive material (i.e >all the sensitive material (i.e. crypto keys and so on) is >stored on the location pointed by the reference), but that >storage where that sensitive material is stored MUST be >protected so that only unauthorized access is not allowed. > I again have to agree with Tero. These are nice details but go far too much into the implementation space. >> 2) Protocol of ticket presenting >> (a) >> Proposed text: section 4.2. after the third paragraph The document >> supports two methods to present a ticket by client. >> o A new IKEv2 exchange type called IKE_SESSION_RESUME. It's >defined in >> section 4.2.1 o A extension to generic IKEv2 IKE_SA_INIT exchange. >> It's defined in section 4.2.2 > >I do not think we want to add yet another complication to the >IKE_SA_INIT by adding new extension for it. I think we should >stick to the simple and understandable exchanges, meaning lets >just use the separate IKE_SESSION_RESUME exchange. That allow >modular building of new exchanges, and that offers simplier >implementations, meaning less bugs... > >We already had earlier discussion about this, but wanted to >just send my email telling that I am still against modifying >IKE_SA_INIT exchange for session resumption, and want to use >separate IKE_SESSION_RESUME exchange for it. I am not seeing any need to change the current approach outlined in the document. At http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/74 some arguments were provided by Peng for re-using the IKE_SA_INIT exchange, namely * simpler implementation * more efficient. As mentioned previously, Florian Tegeler has implemented the session resumption code and he did not find it complex to implement. Sure, there is a learning curve to get into the specific IKEv2 code but it is not a large enhance nor a large specification. For sure, the exact amount of time it takes to implement this extension depends on the specific implementation of IKEv2 and how easy it is to extend the code. I had a hard time to see the efficiency argument given that you are presenting the ticket to a server that has previously provided you that ticket. I am a bit reluctant to change the currently described approach just for the fun of it. Ciao Hannes >-- >kivinen@iki.fi >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec > ------=_NextPart_000_0304_01C97BF4.0C6FA5D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [IPsec] [ipsecme] #73: Ticket location: preferserver-side = ticket

Hi Hui,
 
I appreciate that you raise this = issue. There are certainly different design directions that can be taken = and I understand why you propose the usage of IKE_SA_INIT. I even = believe that it was described in the former draft versions.

The reason for not going along = that path was the fact that you you are very unlikely going to observe = this performance optimization by falling back to a regular IKEv2 = exchange.

The problem is just that this = should not happen since you only provide the ticket to someone that = previously gave it to you. You also know how long the ticket is = considered to be valid. Hence, the "optimization" would only = work in extremely rare cases when something went wong.

Let's see what the other folks = think.
 
Ciao
Hannes
 


Hannes,

        
        Thanks for pointing out one implementation = example,
        let's not tightly coupled with simplicity and = complexity.
        
        What we would like to raise is that one possible = advantage of our proposed text has been missed is falling back to = regular IKE session.

        
        Thanks for the discussion.
        
        -Hui
        
        
       =20
        2009/1/21 Hannes Tschofenig = <Hannes.Tschofenig@gmx.net>
       =20

        =         Tero, Hui,
        =        =20

        =         >Hui Deng writes:
        =         >> 5.3 Location of ticket
        =         >> The full-bodied content of ticket could be = stored on client
        =         >or network side.
        =         >> If it's stored on client, it will be put = in TbV. TbV presenting and
        =         >> requesting can be found in section = 4.  The way of TbV encryption can
        =         >> be found in section 7.
        =         >> If it's stored in the network side, the = operators shall allocate the
        =         >> non-volatile memory space for gateways to = store the tickets
        =         >of all the
        =         >> clients. How to build the ticket storage = is out of the scope. This
        =         >> ticket storage must be reachable for IKEv2 = gateway. The reference of
        =         >> the ticket is defined in 5.4.
        =         >
        =         >I am not really sure, how much this kind of = implementation
        =         >details is needed here. I think it would be = better to just let
        =         >this kind of details for the implementors to = decide, not try
        =         >to dictate something here.
        =         >
        =         >For example that text says that you cannot make = implementation
        =         >where the network crypto processors who = normally take care of
        =         >IKE SAs cannot offload unused IKE SAs to the = slowpath central
        =         >processor with much bigger RAM, as that RAM is = not non-volatile.
        =         >
        =         >I think it is much better to just let that kind = of
        =         >implementation details to the implementors to = decide, as they
        =         >heavily depend on the scenario where the = implementation is aimed for.
        =         >
        =         >I think it is good to say things that mandate = that tickets by
        =         >value MUST be encrypted, as that affects = security. And it is
        =         >good to say that tickets by reference does not = need to be
        =         >encrypted, as they do not contain any sensitive = material (i.e
        =         >all the sensitive material (i.e. crypto keys = and so on) is
        =         >stored on the location pointed by the = reference), but that
        =         >storage where that sensitive material is stored = MUST be
        =         >protected so that only unauthorized access is = not allowed.
        =         >
        =        =20
        =        =20
        =         I again have to agree with Tero. These are nice = details but go far too much
        =         into the implementation space.
        =        =20

        =         >> 2) Protocol of ticket presenting
        =         >> (a)
        =         >> Proposed text: section 4.2. after the = third paragraph The document
        =         >> supports two methods to present a ticket = by client.
        =         >> o A new IKEv2 exchange type called = IKE_SESSION_RESUME. It's
        =         >defined in
        =         >> section 4.2.1 o A extension to generic = IKEv2 IKE_SA_INIT exchange.
        =         >> It's defined in section 4.2.2
        =         >
        =         >I do not think we want to add yet another = complication to the
        =         >IKE_SA_INIT by adding new extension for it. I = think we should
        =         >stick to the simple and understandable = exchanges, meaning lets
        =         >just use the separate IKE_SESSION_RESUME = exchange. That allow
        =         >modular building of new exchanges, and that = offers simplier
        =         >implementations, meaning less bugs...
        =         >
        =         >We already had earlier discussion about this, = but wanted to
        =         >just send my email telling that I am still = against modifying
        =         >IKE_SA_INIT exchange for session resumption, = and want to use
        =         >separate IKE_SESSION_RESUME exchange for = it.
        =        =20
        =        =20
        =         I am not seeing any need to change the current = approach outlined in the
        =         document.
        =        =20
        =         At http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/74<= FONT SIZE=3D4 FACE=3D"Courier New"> some arguments were
        =         provided by Peng for re-using the IKE_SA_INIT = exchange, namely
        =         * simpler implementation
        =         * more efficient.
        =        =20
        =         As mentioned previously, Florian Tegeler has = implemented the session
        =         resumption code and  he did not find it = complex to implement. Sure, there is
        =         a learning curve to get into the specific IKEv2 = code but it is not a large
        =         enhance nor a large specification. For sure, the = exact amount of time it
        =         takes to implement this extension depends on the = specific implementation of
        =         IKEv2 and how easy it is to extend the code.
        =        =20
        =         I had a hard time to see the efficiency argument = given that you are
        =         presenting the ticket to a server that has = previously provided you that
        =         ticket.
        =        =20
        =         I am a bit reluctant to change the currently = described approach just for the
        =         fun of it.
        =        =20
        =         Ciao
        =         Hannes
        =        =20
        =         >--
        =         >kivinen@iki.fi
        =        =20
        =         >_______________________________________________
        =         >IPsec mailing list
        =         >IPsec@ietf.org
        =         >https://www.ietf.org/mailman/listinfo/ipsec
        =         >
        =        =20
        =        =20




------=_NextPart_000_0304_01C97BF4.0C6FA5D0-- --===============0536194527== 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 --===============0536194527==-- From ipsec-bounces@ietf.org Wed Jan 21 08:19:35 2009 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 CF78028C1ED; Wed, 21 Jan 2009 08:19:35 -0800 (PST) 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 8529328C1ED for ; Wed, 21 Jan 2009 08:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.539 X-Spam-Level: X-Spam-Status: No, score=-5.539 tagged_above=-999 required=5 tests=[AWL=1.060, 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 d0OaA8GX63Th for ; Wed, 21 Jan 2009 08:19:33 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 8B6A73A699F for ; Wed, 21 Jan 2009 08:19:33 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0LGJFqZ021784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jan 2009 17:19:15 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0LGJE7i000756; Wed, 21 Jan 2009 17:19:14 +0100 Received: from FIESEXC007.nsn-intra.net ([10.159.0.15]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2009 17:19:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jan 2009 18:19:49 +0200 Message-ID: In-Reply-To: <1d38a3350901210648v1b90f540tdbcdaa90459f9019@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] [ipsecme] #73: Ticket location: prefer server-side ticket Thread-Index: Acl712a3p4mISw6oRYuNwD1SfAX3sAADGZQQ References: <061.7ae35be7f65e375ae77802ad7cdff96b@tools.ietf.org> <1d38a3350901200518u432e0df8n1efe9fa1b63e131b@mail.gmail.com> <18807.5643.444958.221999@fireball.kivinen.iki.fi> <1d38a3350901210648v1b90f540tdbcdaa90459f9019@mail.gmail.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Hui Deng" , "Tero Kivinen" X-OriginalArrivalTime: 21 Jan 2009 16:19:11.0146 (UTC) FILETIME=[FE53B0A0:01C97BE3] Cc: ipsec@ietf.org Subject: Re: [IPsec] [ipsecme] #73: Ticket location: prefer server-side ticket 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 Tero, Hi Hui, Tero wrote: I think it is good to say things that mandate that tickets by value MUST be encrypted, as that affects security. And it is good to say that tickets by reference does not need to be encrypted, as they do not contain any sensitive material (i.e all the sensitive material (i.e. crypto keys and so on) is stored on the location pointed by the reference), but that storage where that sensitive material is stored MUST be protected so that only unauthorized access is not allowed. Hui wrote: It looks good for me, thanks, I believe that it is a good idea to add this text to the document. I will make a text proposal. Thank you, Hui and Tero. Ciao Hannes _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 21 09:02:17 2009 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 162413A6BBC; Wed, 21 Jan 2009 09:02:17 -0800 (PST) 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 41F223A6BBC for ; Wed, 21 Jan 2009 09:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.043 X-Spam-Level: X-Spam-Status: No, score=-3.043 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97HHejj+ffi4 for ; Wed, 21 Jan 2009 09:02:14 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 267CF3A6839 for ; Wed, 21 Jan 2009 09:02:13 -0800 (PST) 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 n0LH1t5f028654 for ; Wed, 21 Jan 2009 19:01: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, 21 Jan 2009 19:01:55 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Wed, 21 Jan 2009 19:01:55 +0200 Thread-Topic: ipsecme - virtual interim meeting on Feb. 3 Thread-Index: Acl04ZpSkdolgYWNR9OpwcxbHbtsowAkpQBQAZCPb1AADCT20A== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63A89D@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 Subject: [IPsec] ipsecme - virtual interim meeting on Feb. 3 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 everyone, The ipsecme working group will hold a virtual interim meeting on Feb. 3, 16:00 GMT (18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), for 2 hours. Like the Minneapolis meeting, we will focus on getting IKEv2-bis issues closed. But there's lots of other fun stuff. Proposed agenda: - Agenda bash (0:05) - Session resumption update (0:15) - Visibility heuristics (0:15) - Redirect open issues (0:10) - Roadmap document (plus call for volunteers) (0:10) - Mandatory access control (off-charter item) (0:15) - IKEv2-bis open issues (0:50) We will send an update within the next week on the technicalities of the call. Document editors, please send me your slides by Jan. 29. Thanks, Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 21 09:25:39 2009 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 055D028C204; Wed, 21 Jan 2009 09:25:39 -0800 (PST) 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 CB15328C204 for ; Wed, 21 Jan 2009 09:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQWHDc59zIAi for ; Wed, 21 Jan 2009 09:25:36 -0800 (PST) Received: from web82606.mail.mud.yahoo.com (web82606.mail.mud.yahoo.com [68.142.201.123]) by core3.amsl.com (Postfix) with SMTP id AFBAE28C1F6 for ; Wed, 21 Jan 2009 09:25:36 -0800 (PST) Received: (qmail 8250 invoked by uid 60001); 21 Jan 2009 17:25:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=DlfT2i+uXJLdjt1DEaETwcJCaiSMMocHcwcMF6+iA6fDvJmPq1wYRLOjv97q+i52U9ETeOdqT1t64oZQ/i5D/4jTarlubBZRQ+wY/7GI2VQg6wKMUGgpAiTwOBM57iLbBDnBk8Kj1x/mOaJewjtcgkEmf29sHx2cmveCxcZMnzY=; X-YMail-OSG: .lbqusIVM1kY2pIzC5xNbu.NUiVz7t_OgmBKA1VwlwAmNelvS7sFJ_cj8OwHNQBulbnzvAkhSUtkqhvCZ4LrE5S0SBCQqWa4rNERpoLeqhZw7TvjxaldAMh33S0V..APKsy9u8WHZw8Mq0CXy0QmgFj8HUQfCrLIdyLU5G.GRw_LMLdEgP_p5GO0_O2DVmcb6GvEI7fxWJEuPqLNMGraj8E02A-- Received: from [24.16.92.42] by web82606.mail.mud.yahoo.com via HTTP; Wed, 21 Jan 2009 09:25:18 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <596832.80321.qm@web82601.mail.mud.yahoo.com> <20090120181916.18552xfkjp2arvuc@webmail.nist.gov> Date: Wed, 21 Jan 2009 09:25:18 -0800 (PST) From: gabriel montenegro To: Sheila Frankel MIME-Version: 1.0 Message-ID: <211522.7672.qm@web82606.mail.mud.yahoo.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] Question on draft-ietf-ipsecme-roadmap 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 Perhaps for crypto algorithms it is more needed, yes, but in general, it would help if this were the one document one went to to find out all requirement levels for IPsec/IKE (not just crypto). E.g., AH is a must/should/may, new proposals are must/should/may? So extending to all other sections would be consistent and helpful. ----- Original Message ---- > From: Sheila Frankel > To: gabriel montenegro > Cc: ipsec@ietf.org > Sent: Tuesday, January 20, 2009 3:19:16 PM > Subject: Re: [IPsec] Question on draft-ietf-ipsecme-roadmap > > We felt that the area of cryptographic algorithms was one in which there's been > a fair amount of confusion, so specifying Requirements Levels would be valuable. > > Are there other areas where you think this is the case? > > Sheila > > Quoting "gabriel montenegro" : > > > Overall good document. > > I did notice that there are Requirements Levels specified quite consistently > in Section 4 > > (Cryptographic Algorithms and Suites). > > > > What about the other sections? Is the intent to also specify requirement > levels in those sections as > > well? > > > > Gabriel > > > > > > > _______________________________________________ > 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 mv@alpe-srl.it Wed Jan 21 09:44:14 2009 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 DD1E53A6962 for ; Wed, 21 Jan 2009 09:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.329 X-Spam-Level: X-Spam-Status: No, score=-11.329 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_PH_SURBL=1.787, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4SEwK8ekWSX for ; Wed, 21 Jan 2009 09:44:14 -0800 (PST) Received: from 20151029156.user.veloxzone.com.br (20151029156.user.veloxzone.com.br [201.51.29.156]) by core3.amsl.com (Postfix) with SMTP id C53ED3A6BC6 for ; Wed, 21 Jan 2009 09:44:10 -0800 (PST) To: Subject: Great Finds From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090121174412.C53ED3A6BC6@core3.amsl.com> Date: Wed, 21 Jan 2009 09:44:10 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.segmentanimal.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://segmentanimal.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 5, B969. 381 Clements Road. London. SE13 7DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From lisilva@aliancadobrasil.com.br Wed Jan 21 11:37:52 2009 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 231C33A67F8 for ; Wed, 21 Jan 2009 11:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_DYNAMIC_SPLIT_IP=3.493, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_IP_ADDR=1.119, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RCVD_NUMERIC_HELO=2.067, RDNS_DYNAMIC=0.1, SARE_UNA=1.231, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-f4XbGGk+oK for ; Wed, 21 Jan 2009 11:37:48 -0800 (PST) Received: from 189.26.129.22.adsl.gvt.net.br (189.26.129.22.adsl.gvt.net.br [189.26.129.22]) by core3.amsl.com (Postfix) with SMTP id 858373A69ED for ; Wed, 21 Jan 2009 11:37:46 -0800 (PST) To: Subject: RE: Windows Live Team From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090121193747.858373A69ED@core3.amsl.com> Date: Wed, 21 Jan 2009 11:37:46 -0800 (PST)

Do not see a picture? Visit our site now!

*Offer expires January 31, 2009.

As a valued Windows Live Hotmail customer, we hope you find this Windows Vista Ultimate offer valuable. If you would prefer to no longer receive promotional offers about Windows Vista Ultimate please click here.

For general information about how to manage your Communication Preferences with Microsoft please click here.

If you have questions about Microsoft privacy policies, please read our online Privacy Statement.

Opting out of Microsoft e-mail offers will not affect any newsletters you have requested nor restrict important customer communications concerning your Microsoft products.

Microsoft Corporation
One Microsoft Way
Redmond, WA 06077

..
Message-Id: <20095878325180.1F1D.11973861-3412@cimail19.msn.com>
From mrbill@amel.tds.net Wed Jan 21 15:25:07 2009 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 E4FB03A6848 for ; Wed, 21 Jan 2009 15:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.139 X-Spam-Level: X-Spam-Status: No, score=-14.139 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ouj8QLVrnuTM for ; Wed, 21 Jan 2009 15:25:07 -0800 (PST) Received: from alssnowmobile.com (unknown [190.28.148.0]) by core3.amsl.com (Postfix) with SMTP id 52C993A69B2 for ; Wed, 21 Jan 2009 15:25:03 -0800 (PST) To: Subject: Your Payment Has Been Initiated From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090121232504.52C993A69B2@core3.amsl.com> Date: Wed, 21 Jan 2009 15:25:03 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.glassperson.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://glassperson.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 4, B304. 574 Clements Road. London. SE36 4DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From ipsec-bounces@ietf.org Thu Jan 22 02:18:25 2009 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 50BF73A69C7; Thu, 22 Jan 2009 02:18:25 -0800 (PST) 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 596C23A69C7 for ; Thu, 22 Jan 2009 02:18:24 -0800 (PST) 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 DBmuVdKlvJ9C for ; Thu, 22 Jan 2009 02:18:23 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 2E71C3A69C5 for ; Thu, 22 Jan 2009 02:18:21 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,305,1231113600"; d="scan'208,217";a="41298723" Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 22 Jan 2009 10:18:03 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0MAI2Ql012446; Thu, 22 Jan 2009 15:48:02 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0MAHq1k027054; Thu, 22 Jan 2009 10:17:59 GMT Received: from xmb-blr-418.apac.cisco.com ([64.104.140.147]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jan 2009 15:47:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 22 Jan 2009 15:47:55 +0530 Message-ID: <7906EBB854491A438474875D1D7373210697F965@xmb-blr-418.apac.cisco.com> In-Reply-To: <8FD12AB3-E7F1-453B-873D-212B56D3E1AA@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 Thread-Index: Acl1vFlBNqLJD/7DRRK3BQoBDmbd8QGvPcEw References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E639FB7@il-ex01.ad.checkpoint.com> <8FD12AB3-E7F1-453B-873D-212B56D3E1AA@checkpoint.com> From: "Rajeshwar Singh Jenwar (rsj)" To: "Yoav Nir" , "Yaron Sheffer" X-OriginalArrivalTime: 22 Jan 2009 10:17:56.0790 (UTC) FILETIME=[B1D12D60:01C97C7A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8666; t=1232619482; x=1233483482; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rsj@cisco.com; z=From:=20=22Rajeshwar=20Singh=20Jenwar=20(rsj)=22=20 |Subject:=20RE=3A=20[IPsec]=20Comments=20on=20draft-ietf-ip secme-roadmap-00 |Sender:=20; bh=K/94G1logqvaJ7yETA7yA2TEVx9chG8Qk7sb8QtF0B0=; b=ANXfqBsgHrsy8pBlWL7dwyA8pTAyJFhy9t9U6btg6NdRLLqL1GF19d11ZN pwNJlTPgJESiYqDW4HDm3VX1TpX9WDjpZ+CZe4BqThMlhw9wDqK3Ac865TDo haJ0YDSe8g; Authentication-Results: ind-dkim-1; header.From=rsj@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); Cc: ipsec@ietf.org, suresh.krishnan@ericsson.com, sheila.frankel@nist.gov Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 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="===============0168156642==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0168156642== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C97C7A.B1A51587" This is a multi-part message in MIME format. ------_=_NextPart_001_01C97C7A.B1A51587 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Youv, =20 I agree with your definition of CHILD SAs. Please update your definition of CHILD SA in IKEv2bis. IKEv2bis says clearly in 1. Introduction, "The SAs for ESP or AH that get set up though IKE SA we call 'CHILD SAs' ". It would be better as "The SAs that get set up though IKE SA we call 'CHILD SAs' ". The mention of only ESP or AH create a bit of confusion. =20 Regards, Raj ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Wednesday, January 14, 2009 1:50 AM To: Yaron Sheffer Cc: ipsec@ietf.org; suresh.krishnan@ericsson.com; sheila.frankel@nist.gov Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-roadmap-00 Hi Yaron, =20 Two comments about your comments. On Jan 13, 2009, at 6:14 PM, Yaron Sheffer wrote: =09 Hi Sheila, Suresh, =09 =09 =09 - 2.3.1: why use the older term "IPsec SA", instead of the newer "Child SA"? A child SA is not the same as an IPsec SA, so the latter term is not deprecated. A child SA is an SA that is created from the IKE SA and could be an IPsec SA, an IKE SA or something that we haven't yet defined. Note that in IKEv2 the way to rekey an IKE SA is through a Create Child SA exchange, so the new IKE SA is also a child SA. =09 =09 =09 =09 - 7.4: we should point out that there are no known KINK implementations (AFAIK). Not so. Racoon2 supports KINK as well as both versions of IKE. Yoav Email secured by Check Point=20 ------_=_NextPart_001_01C97C7A.B1A51587 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Youv,
 
I agree with your definition of CHILD=20 SAs.
Please update your definition of CHILD SA in=20 IKEv2bis.
IKEv2bis says clearly in 1. Introduction, = "The SAs for=20 ESP or AH that get set up though IKE SA we call 'CHILD = SAs'=20 ".
It would be better as "The SAs that get = set up=20 though IKE SA we call 'CHILD SAs' = ".
The=20 mention of only ESP or AH create a bit of confusion.
 
Regards,
Raj
From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav = Nir
Sent:=20 Wednesday, January 14, 2009 1:50 AM
To: Yaron = Sheffer
Cc:=20 ipsec@ietf.org; suresh.krishnan@ericsson.com;=20 sheila.frankel@nist.gov
Subject: Re: [IPsec] Comments on=20 draft-ietf-ipsecme-roadmap-00

Hi Yaron, 

Two comments about your comments.

On Jan 13, 2009, at 6:14 PM, Yaron Sheffer wrote:
Hi Sheila,=20 Suresh,

<snip/&g= t;

- 2.3.1:=20 why use the older term "IPsec SA", instead of the newer "Child=20 SA"?

A = child SA is not=20 the same as an IPsec SA, so the latter term is not deprecated. A child = SA is an=20 SA that is created from the IKE SA and could be an IPsec SA, an IKE SA = or=20 something that we haven't yet defined. Note that in IKEv2 the way to = rekey an=20 IKE SA is through a Create Child SA exchange, so the new IKE SA is also = a child=20 SA.

<snip/>

- 7.4: we=20 should point out that there are no known KINK implementations=20 (AFAIK).

Not so. Racoon2 supports KINK as well as both versions of = IKE.

Yoav


Email secured by Check Point =

------_=_NextPart_001_01C97C7A.B1A51587-- --===============0168156642== 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 --===============0168156642==-- From jeff_j_lee@acer.com.tw Thu Jan 22 04:46:53 2009 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 F333F28C1A9 for ; Thu, 22 Jan 2009 04:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -32.732 X-Spam-Level: X-Spam-Status: No, score=-32.732 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1NtAxvG3z6a for ; Thu, 22 Jan 2009 04:46:51 -0800 (PST) Received: from aktiv-sound.ch (unknown [189.24.8.140]) by core3.amsl.com (Postfix) with SMTP id 6B4EF28C21C for ; Thu, 22 Jan 2009 04:46:30 -0800 (PST) To: Subject: Receipt for Your Payment From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090122124632.6B4EF28C21C@core3.amsl.com> Date: Thu, 22 Jan 2009 04:46:30 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.achievementsimilar.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://achievementsimilar.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 7, B360. 430 Clements Road. London. SE05 2DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From ipsec-bounces@ietf.org Thu Jan 22 04:54:02 2009 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 021213A685B; Thu, 22 Jan 2009 04:54:02 -0800 (PST) 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 7430C3A6B71 for ; Thu, 22 Jan 2009 04:54:01 -0800 (PST) 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 Tz+j5yIucKMC for ; Thu, 22 Jan 2009 04:54:00 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A50723A68BA for ; Thu, 22 Jan 2009 04:53:59 -0800 (PST) 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 n0MCrYMq029385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2009 14:53:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0MCrWVn004639; Thu, 22 Jan 2009 14:53:32 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18808.27724.887106.68282@fireball.kivinen.iki.fi> Date: Thu, 22 Jan 2009 14:53:32 +0200 From: Tero Kivinen To: Peny Yang In-Reply-To: <4c5c7a6d0901210731k5a94be08x898a3460d4db57fd@mail.gmail.com> References: <4c5c7a6d0901200518o549d295fyc1cc8054f86e0fcb@mail.gmail.com> <18807.4677.574870.685258@fireball.kivinen.iki.fi> <4c5c7a6d0901210731k5a94be08x898a3460d4db57fd@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: ipsec@ietf.org, Hui Deng Subject: Re: [IPsec] Proposed text for working items of IKE session resumption 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 Peny Yang writes: > > Why is there any need to make standardized format for distinguishing > > ticket-by-reference and ticket-by-value? > [Peny] We propose this, because some people gave the comments that > it's better to have a format for TbV and TbR. And, we made the V bit > visible because it's easier for the Gateway to decide the follow-up > actions by this > V bit, before de-cryption of ticket. And if some vendors would like to > store the tickets and en/de-cryption functions in a separated > equipment other than the gateway, this visible V bit provides more > flexibility. There is no need to put anything like that to the draft. The gateway implementation can implement the format as it likes, and it can include V bit or whatever if it feels like it as the ticket format should be completely gateway local implementation matter. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 22 07:37:07 2009 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 C72E93A67E5; Thu, 22 Jan 2009 07:37:07 -0800 (PST) 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 A7D843A67E4 for ; Thu, 22 Jan 2009 07:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.728 X-Spam-Level: X-Spam-Status: No, score=-2.728 tagged_above=-999 required=5 tests=[AWL=-0.129, 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 GWLHnZAWw7nZ for ; Thu, 22 Jan 2009 07:37:01 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 58CB53A6938 for ; Thu, 22 Jan 2009 07:37:01 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.4]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1LQ1bk-0004dX-E0; Thu, 22 Jan 2009 10:36:40 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <18808.27724.887106.68282@fireball.kivinen.iki.fi> References: <4c5c7a6d0901200518o549d295fyc1cc8054f86e0fcb@mail.gmail.com> <18807.4677.574870.685258@fireball.kivinen.iki.fi> <4c5c7a6d0901210731k5a94be08x898a3460d4db57fd@mail.gmail.com> <18808.27724.887106.68282@fireball.kivinen.iki.fi> Date: Thu, 22 Jan 2009 10:36:36 -0500 To: Peny Yang , ipsec@ietf.org, Hui Deng From: Stephen Kent Subject: Re: [IPsec] Proposed text for working items of IKE session resumption 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 I agree with Tero's observations here. It is inappropriate to specify formats for either type of token, given that it is outside the scope of this work to enable interoperability among different SGs. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 22 07:53:06 2009 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 BE9C43A6939; Thu, 22 Jan 2009 07:53:06 -0800 (PST) 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 04AB73A67E4 for ; Thu, 22 Jan 2009 07:53:06 -0800 (PST) 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 ULlr5YHsV+sJ for ; Thu, 22 Jan 2009 07:53:05 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B218F3A6939 for ; Thu, 22 Jan 2009 07:53:04 -0800 (PST) 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 n0MFqb0M022956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Jan 2009 17:52:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0MFqbfa001088; Thu, 22 Jan 2009 17:52:37 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18808.38469.468999.662664@fireball.kivinen.iki.fi> Date: Thu, 22 Jan 2009 17:52:37 +0200 From: Tero Kivinen To: ipsec@ietf.org In-Reply-To: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets 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: > If you want this to be a serious consideration of the WG, we need > more than brief chimes. Asking us to look in the archives for > multiple messages listing some heuristics is a bit challenging. > Could one or both of you put together an Internet Draft that lists > all of the heuristics that you consider sufficient for detecting > most ESP-NULL traffic? That would help the WG greatly! It took bit longer than I expected, and the actual draft is also longer than what I expected, but now it is now submitted: ---------------------------------------------------------------------- From: Subject: I-D Action:draft-kivinen-ipsecme-esp-null-heuristics-00.txt Date: 2009-01-22 15:45:01 GMT A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Heuristics for Detecting ESP-NULL packets Author(s) : T. Kivinen, D. McDonald Filename : draft-kivinen-ipsecme-esp-null-heuristics-00.txt Pages : 33 Date : 2009-01-22 This document describes a heuristic approach for distinguishing ESP- NULL (Encapsulating Security Payload without encryption) packets from encrypted ESP packets. The reason for using heuristics instead of modifying ESP is to provide a solution that can be used now without updating all end nodes. With heuristic methods, only the intermediate devices wanting to find ESP-NULL packets need to be updated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-esp-null-heuristics-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 22 15:46:47 2009 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 5690B3A6994; Thu, 22 Jan 2009 15:46:47 -0800 (PST) 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 C90D13A685E for ; Thu, 22 Jan 2009 15:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 55pE6qHMwSBB for ; Thu, 22 Jan 2009 15:46:45 -0800 (PST) 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 740253A6806 for ; Thu, 22 Jan 2009 15:46:45 -0800 (PST) Received: from [10.20.30.158] (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 n0MNkOl6097540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 22 Jan 2009 16:46:26 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 22 Jan 2009 15:46:04 -0800 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] Resolution of some open issues 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 long delay here. We want to clear these off so we can start on the next batch before the interim call. --Paul Hoffman #9: Notification when creation of CHILD_SA fails No comments, but seems important. New text will say: - Failure of CHILD SA creation should not tear down IKE SA because there is no reason to lose the work done - When IKE SA is not created, and we need to send error message back about that, do not encrypt the message because it will not authenticate. #50: Change the SHOULD for KE in Section 1.3.2 to a MUST Accepted; easy change to 1.3.2. #22: Add section on simultaneous IKE SA rekey Accepted; need to come up with draft changes #30: Conflicts in DH proposals Accepted. In section 3.4: The DH Group # identifies the Diffie-Hellman group in which the Key Exchange Data was computed (see Section 3.3.2). If the selected proposal uses a different Diffie-Hellman group (other than NONE), the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD. becomes The DH Group # identifies the Diffie-Hellman group in which the Key Exchange Data was computed (see Section 3.3.2). This Group # MUST match a DH Group specified in a proposal in the SA payload that is sent in the same message, and SHOULD match the DH group in the first group in the first proposal, if such exists. If none of the proposals in that SA payload specifies a DH Group, the KE payload MUST NOT be present. If the selected proposal uses a different Diffie-Hellman group (other than NONE), the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD. #40: Floating to port 4500 'by default', and use of UDP when no NAT detected Accepted; need to come up with draft changes. Text will say something like: An initiator can float to port 4500, regardless whether or not there is NAT, even at the beginning of IKE. When either side is using port 4500, sending with UDP encapsulation is not required, but understanding received packets with UDP encapsulation is required. UDP encapsulation MUST NOT be done on port 500. If NAT-T is supported, all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. Either side can decide whether or not to use UDP encapsulation irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST send UDP encapsulated packets. #46: Exchange type for INVALID_IKE_SPI outside of an IKE_SA Accepted. In section 1.5, say that the the responder should copy the Exchange Type from the request for the one-way INVALID_IKE_SPI notification for an unrecognized SPI? #55: Exponential reuse - reference for section 2.12 We don't have a good model for what we mean by "secure" reuse (the new keys are related but not predictable), so we can skip this. #56: Address and config values lifetime No comment on this, so it is still open. There were two proposed solutions: - Gateway should try to renew DHCP leases, but nuke the SA if lease renewal fails - Lifetime of the first lease is the lifetime of the SA, no renewals #65: Original initiator and rekeying No comments, but is a clearly desired clarification. This will say: - The old SA uses the old roles and old message IDs - The new SA that is created by rekeying will use the roles of the original initiator and responder (never changed) and the mesage IDs are reset to 0 - Will add diagram #79: IKEv2 CP with CREATE-CHILD-SA exchange Accepted. Add to the end of the first paragraph of 2.19: Note, however, it is usual to only assign one IP address during the IKE_AUTH exchange. That address persists at least until the deletion of the IKE SA. #81: NO_PROPOSAL_CHOSEN and USE_TRANSPORT_MODE or IPCOMP_SUPPORTED Accepted. Tero's proposal for a change to "NO_PROPOSAL_CHOSEN" will be used: NO_PROPOSAL_CHOSEN 14 None of the proposed crypto suites was acceptable. This can be sent in any case where the offered proposal (including but not limited to SA payload values, USE_TRANSPORT_MODE notify, IPCOMP_SUPPORTED notify) are not acceptable for the responder. This can also be used as "generic" Child SA error when Child SA cannot be created for some other reason. See also Section 2.7. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 23 05:00:39 2009 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 586E53A68BC; Fri, 23 Jan 2009 05:00:39 -0800 (PST) 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 667333A6867; Fri, 23 Jan 2009 05:00:37 -0800 (PST) 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 NytwQw9FE2G9; Fri, 23 Jan 2009 05:00:30 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id B14193A68BC; Fri, 23 Jan 2009 05:00:29 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0NCxAHk026159; Fri, 23 Jan 2009 05:59:10 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0ND09GF193496; Fri, 23 Jan 2009 06:00:09 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0ND09MK019971; Fri, 23 Jan 2009 06:00:09 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0ND09dm019960; Fri, 23 Jan 2009 06:00:09 -0700 In-Reply-To: References: To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: B5E0EF17:7152B096-85257547:00458293; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/23/2009 07:43:51 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/23/2009 07:43:51 AM, Serialize complete at 01/23/2009 07:43:51 AM, S/MIME Sign failed at 01/23/2009 07:43:51 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 01/23/2009 06:00:09, Serialize complete at 01/23/2009 06:00:09 Message-ID: Date: Fri, 23 Jan 2009 08:00:08 -0500 Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] Resolution of some open issues 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="===============0921387364==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0921387364== Content-Type: multipart/alternative; boundary="=_alternative 0045EEB585257547_=" This is a multipart message in MIME format. --=_alternative 0045EEB585257547_= Content-Type: text/plain; charset="US-ASCII" Paul, regarding #40: > If NAT-T is supported, all devices MUST be able to receive and process > both UDP encapsulated and non-UDP encapsulated packets at any time. How should I read this statement in the context of multiple address families? If an implementation supports IPv4 and IPv6, but supports NAT-T only for IPv4, can I read this statement to say that the implementation MUST tolerate UDP-encapsulation in the absence of a NAT only for IPv4? Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Paul Hoffman To: IPsecme WG Date: 01/22/2009 06:46 PM Subject: [IPsec] Resolution of some open issues Sorry for the long delay here. We want to clear these off so we can start on the next batch before the interim call. --Paul Hoffman #9: Notification when creation of CHILD_SA fails No comments, but seems important. New text will say: - Failure of CHILD SA creation should not tear down IKE SA because there is no reason to lose the work done - When IKE SA is not created, and we need to send error message back about that, do not encrypt the message because it will not authenticate. #50: Change the SHOULD for KE in Section 1.3.2 to a MUST Accepted; easy change to 1.3.2. #22: Add section on simultaneous IKE SA rekey Accepted; need to come up with draft changes #30: Conflicts in DH proposals Accepted. In section 3.4: The DH Group # identifies the Diffie-Hellman group in which the Key Exchange Data was computed (see Section 3.3.2). If the selected proposal uses a different Diffie-Hellman group (other than NONE), the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD. becomes The DH Group # identifies the Diffie-Hellman group in which the Key Exchange Data was computed (see Section 3.3.2). This Group # MUST match a DH Group specified in a proposal in the SA payload that is sent in the same message, and SHOULD match the DH group in the first group in the first proposal, if such exists. If none of the proposals in that SA payload specifies a DH Group, the KE payload MUST NOT be present. If the selected proposal uses a different Diffie-Hellman group (other than NONE), the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD. #40: Floating to port 4500 'by default', and use of UDP when no NAT detected Accepted; need to come up with draft changes. Text will say something like: An initiator can float to port 4500, regardless whether or not there is NAT, even at the beginning of IKE. When either side is using port 4500, sending with UDP encapsulation is not required, but understanding received packets with UDP encapsulation is required. UDP encapsulation MUST NOT be done on port 500. If NAT-T is supported, all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. Either side can decide whether or not to use UDP encapsulation irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST send UDP encapsulated packets. #46: Exchange type for INVALID_IKE_SPI outside of an IKE_SA Accepted. In section 1.5, say that the the responder should copy the Exchange Type from the request for the one-way INVALID_IKE_SPI notification for an unrecognized SPI? #55: Exponential reuse - reference for section 2.12 We don't have a good model for what we mean by "secure" reuse (the new keys are related but not predictable), so we can skip this. #56: Address and config values lifetime No comment on this, so it is still open. There were two proposed solutions: - Gateway should try to renew DHCP leases, but nuke the SA if lease renewal fails - Lifetime of the first lease is the lifetime of the SA, no renewals #65: Original initiator and rekeying No comments, but is a clearly desired clarification. This will say: - The old SA uses the old roles and old message IDs - The new SA that is created by rekeying will use the roles of the original initiator and responder (never changed) and the mesage IDs are reset to 0 - Will add diagram #79: IKEv2 CP with CREATE-CHILD-SA exchange Accepted. Add to the end of the first paragraph of 2.19: Note, however, it is usual to only assign one IP address during the IKE_AUTH exchange. That address persists at least until the deletion of the IKE SA. #81: NO_PROPOSAL_CHOSEN and USE_TRANSPORT_MODE or IPCOMP_SUPPORTED Accepted. Tero's proposal for a change to "NO_PROPOSAL_CHOSEN" will be used: NO_PROPOSAL_CHOSEN 14 None of the proposed crypto suites was acceptable. This can be sent in any case where the offered proposal (including but not limited to SA payload values, USE_TRANSPORT_MODE notify, IPCOMP_SUPPORTED notify) are not acceptable for the responder. This can also be used as "generic" Child SA error when Child SA cannot be created for some other reason. See also Section 2.7. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0045EEB585257547_= Content-Type: text/html; charset="US-ASCII"
Paul, regarding #40:

        > If NAT-T is supported, all devices MUST be able to receive and process
        > both UDP encapsulated and non-UDP encapsulated packets at any time.

How should I read this statement in the context of multiple address families?  If an implementation supports IPv4 and IPv6, but supports NAT-T only for IPv4, can I read this statement to say that the implementation MUST tolerate UDP-encapsulation in the absence of a NAT only for IPv4?


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


From: Paul Hoffman <paul.hoffman@vpnc.org>
To: IPsecme WG <ipsec@ietf.org>
Date: 01/22/2009 06:46 PM
Subject: [IPsec] Resolution of some open issues




Sorry for the long delay here. We want to clear these off so we can start on the next batch before the interim call.

--Paul Hoffman

#9: Notification when creation of CHILD_SA fails
                No comments, but seems important. New text will say:
                - Failure of CHILD SA creation should not tear down IKE SA because
                  there is no reason to lose the work done
                - When IKE SA is not created, and we need to send error message back
                  about that, do not encrypt the message because it will not
                  authenticate.

#50: Change the SHOULD for KE in Section 1.3.2 to a MUST
                Accepted; easy change to 1.3.2.

#22: Add section on simultaneous IKE SA rekey
                Accepted; need to come up with draft changes

#30: Conflicts in DH proposals
                Accepted.

                In section 3.4:

                The DH Group # identifies the Diffie-Hellman group in which the Key
                Exchange Data was computed (see Section 3.3.2).  If the selected
                proposal uses a different Diffie-Hellman group (other than NONE), the
                message MUST be rejected with a Notify payload of type
                INVALID_KE_PAYLOAD.
               
                becomes
               
                The DH Group # identifies the Diffie-Hellman group in which the
                Key Exchange Data was computed (see Section 3.3.2).  This Group #
                MUST match a DH Group specified in a proposal in the SA payload
                that is sent in the same message, and SHOULD match the DH group in
                the first group in the first proposal, if such exists. If none of
                the proposals in that SA payload specifies a DH Group, the  KE
                payload MUST NOT be present. If the selected proposal uses a
                different Diffie-Hellman group (other than NONE), the message MUST
                be rejected with a Notify payload of type INVALID_KE_PAYLOAD.

#40: Floating to port 4500 'by default', and use of UDP when no NAT detected
                Accepted; need to come up with draft changes. Text will say something like:

                An initiator can float to port 4500, regardless whether or not
                there is NAT, even at the beginning of IKE. When either side is
                using port 4500, sending with UDP encapsulation is not required,
                but understanding received packets with UDP encapsulation is
                required. UDP encapsulation MUST NOT be done on port 500. If NAT-T
                is supported, all devices MUST be able to receive and process both
                UDP encapsulated and non-UDP encapsulated packets at any time.
                Either side can decide whether or not to use UDP encapsulation
                irrespective of the choice made by the other side. However, if a
                NAT is detected, both devices MUST send UDP encapsulated packets.

#46: Exchange type for INVALID_IKE_SPI outside of an IKE_SA
                Accepted. In section 1.5, say that the the responder should copy
                the Exchange Type from the request for the one-way INVALID_IKE_SPI
                notification for an unrecognized SPI?

#55: Exponential reuse - reference for section 2.12
                We don't have a good model for what we mean by "secure" reuse (the
                new keys are related but not predictable), so we can skip this.

#56: Address and config values lifetime
                No comment on this, so it is still open. There were two proposed
                solutions:
                - Gateway should try to renew DHCP leases, but nuke the SA if lease
                  renewal fails
                - Lifetime of the first lease is the lifetime of the SA, no renewals

#65: Original initiator and rekeying
                No comments, but is a clearly desired clarification. This will say:
                - The old SA uses the old roles and old message IDs
                - The new SA that is created by rekeying  will use the roles of the
                  original initiator and responder (never changed) and the mesage IDs are reset to 0
                - Will add diagram

#79: IKEv2 CP with CREATE-CHILD-SA exchange
                Accepted. Add to the end of the first paragraph of 2.19:
                Note, however, it is usual to only assign one IP address during
                the IKE_AUTH exchange.  That address persists at least until the
                deletion of the IKE SA.

#81: NO_PROPOSAL_CHOSEN and USE_TRANSPORT_MODE or IPCOMP_SUPPORTED
                Accepted. Tero's proposal for a change to "NO_PROPOSAL_CHOSEN"
                will be used:
  NO_PROPOSAL_CHOSEN                       14

      None of the proposed crypto suites was acceptable. This can be
      sent in any case where the offered proposal (including but not
      limited to SA payload values, USE_TRANSPORT_MODE notify,
      IPCOMP_SUPPORTED notify) are not acceptable for the responder.
      This can also be used as "generic" Child SA error when Child SA
      cannot be created for some other reason. See also Section 2.7.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 0045EEB585257547_=-- --===============0921387364== 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 --===============0921387364==-- From ipsec-bounces@ietf.org Fri Jan 23 05:37:36 2009 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 BA26F3A6A6B; Fri, 23 Jan 2009 05:37:36 -0800 (PST) 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 D86713A6A6B for ; Fri, 23 Jan 2009 05:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 tfGShDpiwBeB for ; Fri, 23 Jan 2009 05:37:34 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A94F03A6A4F for ; Fri, 23 Jan 2009 05:37:33 -0800 (PST) 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 n0NDbEdY007644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2009 15:37:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0NDbDAF021630; Fri, 23 Jan 2009 15:37:13 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18809.51209.570727.898337@fireball.kivinen.iki.fi> Date: Fri, 23 Jan 2009 15:37:13 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: IPsecme WG Subject: [IPsec] Resolution of some open issues 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: > Sorry for the long delay here. We want to clear these off so we can > start on the next batch before the interim call. So do any of these require any actions from us, or is this just informational mail listing the resolution for open issues, and ikev2bis document will be modified accordingly? > #9: Notification when creation of CHILD_SA fails > No comments, but seems important. New text will say: > - Failure of CHILD SA creation should not tear down IKE SA because > there is no reason to lose the work done > - When IKE SA is not created, and we need to send error message back > about that, do not encrypt the message because it will not > authenticate. Actually someone pointed out one benefit for the second case, i.e. when IKE SA cannot be created and we are sending error message back. If the error message is encrypted (even when it is unauthenticated) that proofs that the message was sent by the same peer who replied to the IKE_SA_INIT. Because of this I think it would be good to split the original #9 to two cases, one that I do not think anybody disagrees is that failure of CHILD SA creation should not tear down IKE SA. And the other is how is the fatal IKE SA creation errors sent back (i.e. whether to encrypt them or not). > #56: Address and config values lifetime > No comment on this, so it is still open. There were two proposed > solutions: > - Gateway should try to renew DHCP leases, but nuke the SA if lease > renewal fails > - Lifetime of the first lease is the lifetime of the SA, no renewals I think we should left that for implementations to decide. I.e. in some implementations the gateway can renew the DHCP lease, on some implementations it can simply delete the IKE SA (as there is no agreed upon lifetime of IKE SAs in IKEv2 anyways). > #79: IKEv2 CP with CREATE-CHILD-SA exchange > Accepted. Add to the end of the first paragraph of 2.19: > Note, however, it is usual to only assign one IP address during > the IKE_AUTH exchange. That address persists at least until the > deletion of the IKE SA. Note, that this might have connection to the draft-ietf-ipsecme-ikev2-ipv6-config draft too. The current solution in that draft works with this change, but for example Appendix "A.4 IPv4-like Sketch" would not be compatible with this change. This does not require any changes to the resolution of this item, but the connection needs to be kept in mind... Otherwise I do agree on your resolutions... -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 23 05:42:24 2009 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 5C18F3A6AA4; Fri, 23 Jan 2009 05:42:24 -0800 (PST) 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 57DA83A6AA4 for ; Fri, 23 Jan 2009 05:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 rIT0GOWw-RIq for ; Fri, 23 Jan 2009 05:42:22 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 360093A68D7 for ; Fri, 23 Jan 2009 05:42:22 -0800 (PST) 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 n0NDg3O1010365 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2009 15:42:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0NDg3Wa009872; Fri, 23 Jan 2009 15:42: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: <18809.51499.928855.243725@fireball.kivinen.iki.fi> Date: Fri, 23 Jan 2009 15:42:03 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Resolution of some open issues 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: > Paul, regarding #40: > > > If NAT-T is supported, all devices MUST be able to receive and > process > > both UDP encapsulated and non-UDP encapsulated packets at any > time. > > How should I read this statement in the context of multiple address > families? If an implementation supports IPv4 and IPv6, but supports NAT-T > only for IPv4, can I read this statement to say that the implementation > MUST tolerate UDP-encapsulation in the absence of a NAT only for IPv4? I would interpret it that if you support NAT-T only for IPv4, and you do not support NAT-T for IPv6, then you must be able to receive and process UDP encapsulated and non-UDP encapsulated packets only from IPv4. If you negotiated with IPv6 with a remote peer, the remote peer will only see that you do not support NAT-T, and that is the situation for him. He does not know that you support NAT-T for some other address family. This is also same if you have NAT-T support disabled by policy for some interfaces or IP-addresses. Perhaps the "If NAT-T is supported, ..." should be changed to "If NAT-T is supported (i.e. NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), ...". -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 23 08:37:12 2009 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 A67C03A69D9; Fri, 23 Jan 2009 08:37:12 -0800 (PST) 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 4860C3A69D9 for ; Fri, 23 Jan 2009 08:37:11 -0800 (PST) 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 9oErC8jkXy0Y for ; Fri, 23 Jan 2009 08:37:07 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 2305A3A6929 for ; Fri, 23 Jan 2009 08:37:07 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0NGZjSk028610 for ; Fri, 23 Jan 2009 09:35:45 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0NGadCr207140 for ; Fri, 23 Jan 2009 09:36:45 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n0NGadx6004596 for ; Fri, 23 Jan 2009 09:36:39 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n0NGadM4004593; Fri, 23 Jan 2009 09:36:39 -0700 In-Reply-To: <18809.51499.928855.243725@fireball.kivinen.iki.fi> References: <18809.51499.928855.243725@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 97BE7231:D24F7A96-85257547:00546222; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/23/2009 11:31:55 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/23/2009 11:31:55 AM, Serialize complete at 01/23/2009 11:31:55 AM, S/MIME Sign failed at 01/23/2009 11:31:55 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 01/23/2009 09:36:38, Serialize complete at 01/23/2009 09:36:38 Message-ID: Date: Fri, 23 Jan 2009 11:36:37 -0500 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Resolution of some open issues 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="===============1011721649==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1011721649== Content-Type: multipart/alternative; boundary="=_alternative 005AD03685257547_=" This is a multipart message in MIME format. --=_alternative 005AD03685257547_= Content-Type: text/plain; charset="US-ASCII" Thanks, Tero. One more comment -- the non-ESP marker is defined only for use on port 4500. When data is received on port 500, implementations do not expect it to be present. Consequently, to avoid any ambiguity, we should probably take care to stipulate here that if you unilaterally choose to float to port 4500, even in the absence of a NAT, you MUST send to port 4500. 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: Paul Hoffman , IPsecme WG Date: 01/23/2009 08:42 AM Subject: Re: [IPsec] Resolution of some open issues Scott C Moonen writes: > Paul, regarding #40: > > > If NAT-T is supported, all devices MUST be able to receive and > process > > both UDP encapsulated and non-UDP encapsulated packets at any > time. > > How should I read this statement in the context of multiple address > families? If an implementation supports IPv4 and IPv6, but supports NAT-T > only for IPv4, can I read this statement to say that the implementation > MUST tolerate UDP-encapsulation in the absence of a NAT only for IPv4? I would interpret it that if you support NAT-T only for IPv4, and you do not support NAT-T for IPv6, then you must be able to receive and process UDP encapsulated and non-UDP encapsulated packets only from IPv4. If you negotiated with IPv6 with a remote peer, the remote peer will only see that you do not support NAT-T, and that is the situation for him. He does not know that you support NAT-T for some other address family. This is also same if you have NAT-T support disabled by policy for some interfaces or IP-addresses. Perhaps the "If NAT-T is supported, ..." should be changed to "If NAT-T is supported (i.e. NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), ...". -- kivinen@iki.fi --=_alternative 005AD03685257547_= Content-Type: text/html; charset="US-ASCII"
Thanks, Tero.

One more comment -- the non-ESP marker is defined only for use on port 4500.  When data is received on port 500, implementations do not expect it to be present.  Consequently, to avoid any ambiguity, we should probably take care to stipulate here that if you unilaterally choose to float to port 4500, even in the absence of a NAT, you MUST send to port 4500.


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: Paul Hoffman <paul.hoffman@vpnc.org>, IPsecme WG <ipsec@ietf.org>
Date: 01/23/2009 08:42 AM
Subject: Re: [IPsec] Resolution of some open issues




Scott C Moonen writes:
> Paul, regarding #40:
>
>         > If NAT-T is supported, all devices MUST be able to receive and
> process
>         > both UDP encapsulated and non-UDP encapsulated packets at any
> time.
>
> How should I read this statement in the context of multiple address
> families?  If an implementation supports IPv4 and IPv6, but supports NAT-T
> only for IPv4, can I read this statement to say that the implementation
> MUST tolerate UDP-encapsulation in the absence of a NAT only for IPv4?

I would interpret it that if you support NAT-T only for IPv4, and you
do not support NAT-T for IPv6, then you must be able to receive and
process UDP encapsulated and non-UDP encapsulated packets only from
IPv4.

If you negotiated with IPv6 with a remote peer, the remote peer will
only see that you do not support NAT-T, and that is the situation for
him. He does not know that you support NAT-T for some other address
family.

This is also same if you have NAT-T support disabled by policy for
some interfaces or IP-addresses.

Perhaps the "If NAT-T is supported, ..." should be changed to "If
NAT-T is supported (i.e. NAT_DETECTION_*_IP payloads were exchanged
during IKE_SA_INIT), ...".
--
kivinen@iki.fi

--=_alternative 005AD03685257547_=-- --===============1011721649== 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 --===============1011721649==-- From kshibata@acculogix-usa.com Fri Jan 23 21:16:57 2009 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 BB15D3A6896 for ; Fri, 23 Jan 2009 21:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -45.099 X-Spam-Level: X-Spam-Status: No, score=-45.099 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_UK=1.749, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 U76thE9KlfMg for ; Fri, 23 Jan 2009 21:16:56 -0800 (PST) Received: from 777group.co.uk (unknown [122.169.14.77]) by core3.amsl.com (Postfix) with SMTP id CDA9C3A67A7 for ; Fri, 23 Jan 2009 21:16:54 -0800 (PST) To: Subject: You've received an answer to your question From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124051654.CDA9C3A67A7@core3.amsl.com> Date: Fri, 23 Jan 2009 21:16:54 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.bringdiscuss.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://bringdiscuss.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 2, B808. 831 Clements Road. London. SE57 5DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From lements@alfa.com Sat Jan 24 05:40:24 2009 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 BED8F28C2C6 for ; Sat, 24 Jan 2009 05:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -39.276 X-Spam-Level: X-Spam-Status: No, score=-39.276 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 HD1A20U+3tua for ; Sat, 24 Jan 2009 05:40:24 -0800 (PST) Received: from 5ad224ca.bb.sky.com (5aceed5a.bb.sky.com [90.206.237.90]) by core3.amsl.com (Postfix) with SMTP id A5B5328C2BA for ; Sat, 24 Jan 2009 05:40:22 -0800 (PST) To: Subject: Check out hot deals From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124134022.A5B5328C2BA@core3.amsl.com> Date: Sat, 24 Jan 2009 05:40:22 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.rockintuition.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://rockintuition.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 5, B256. 846 Clements Road. London. SE65 8DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From ipsec-bounces@ietf.org Sat Jan 24 07:28:50 2009 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 B1C8128C148; Sat, 24 Jan 2009 07:28:50 -0800 (PST) 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 564BF28C148 for ; Sat, 24 Jan 2009 07:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=-0.979, 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 trS2GoC7ksD5 for ; Sat, 24 Jan 2009 07:28:49 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 246EA28C0F4 for ; Sat, 24 Jan 2009 07:28:48 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0OFSR49010506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 24 Jan 2009 16:28:27 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0OFSRdR014429; Sat, 24 Jan 2009 16:28:27 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Jan 2009 16:28:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 24 Jan 2009 17:29:08 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45F7FD41@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) Thread-Index: Acl+OH/UAaJSgBpmTfOZ3yiNJ3+o1g== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 24 Jan 2009 15:28:27.0504 (UTC) FILETIME=[676A0700:01C97E38] Cc: kivinen@iki.fi Subject: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) 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, Hi Tero, I would like to close issue #70: http://tools.ietf.org/wg/ipsecme/trac/ticket/70 Here is a copy-and-paste from the page: " What is the reason for sending the lifetime of the ticket along with ticket? We have mostly tried to get rid of lifetimes visible on protocol level on the IKEv2 and made all those local policy matters, so why do we need externally visible lifetime for the ticket? What purpose does it serve? Why does the client need to know the ticket lifetime? It would be much simplier if this was left as local matter, i.e. client would always use the latest ticket is has, and every time if he has ticket (i.e. the last IKE SA was NOT deleted, but was interrupted), it would send that to the server (i.e. use the IKE_SESSION_RESUME). If ticket is no longer valid in the server, server will reply with N(TICKET_NACK) and client will restart with full exchange. In most of the cases the resumption happens quite quickly after the connection was interrupted, so most likely the ticket is still valid. Then for the server side when the ticket is about expire, it would simply push new ticket to the client using informational message (this is set as one of the requirements "o Allowing a gateway to push state to clients.", but I do not see the actual description how to do it in document). This way server could use also non-time based policies for the ticket lifetimes, i.e. it could for example decide to change the ticket encryption key every now and then, and then slowly generate new tickets for those sessions using old key, and when all sessions have been sent new ticket, it can forget the old ticket encryption key. Also what is the meaning of the lifetime field of the N(TICKET_OPAQUE) in IKE_SESSION_RESUME? Does it need to be copied from the original notification or what? " There are obviously design choices one can make about the way how the ticket lifecycle looks like. The authors thought it would make sense to give the client a clue how long the ticket would be valid. Instead of letting the client know one could also generate an error message as you indicated. One way is as good as the other one. When we change it in the way someone else will come along and argue that it should be done similar to RFC 5077 or to the way Kerberos does it. Subsequently, someone will come along to tell us that RFC 4962 says that authorization decisions (including the lifetime) should be synchronized between all involved parties. Etc. etc. I don't believe that the argument regarding changing the encryption algorithm is super realistic as the lifetime of the ticket is in the order of hours and not weeks or months where switching of algorithm makes sense. In short, one can always make other design choices and in most cases there is very little difference between the various mechanisms. Regarding "o Allowing a gateway to push state to clients.": I meant this a bit differently. The ticket per value is a way for the gateway to push state information to the client. In fact it does so without server-side state. I added a sentence regarding the lifetime field of the N(TICKET_OPAQUE) payload. The value of the Lifetime field in the TICKET_OPAQUE payload is set to the value that was received when requesting the ticket. Is this OK for you? Ciao Hannes _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Jan 24 07:30:08 2009 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 359CD28C2D9; Sat, 24 Jan 2009 07:30:08 -0800 (PST) X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id CB38F28C14D; Sat, 24 Jan 2009 07:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090124153005.CB38F28C14D@core3.amsl.com> Date: Sat, 24 Jan 2009 07:30:02 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-resumption-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 : IKEv2 Session Resumption Author(s) : Y. Sheffer, et al. Filename : draft-ietf-ipsecme-ikev2-resumption-01.txt Pages : 21 Date : 2009-01-24 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 (SAs) 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 requires passing opaque data from the IKEv2 responder to the IKEv2 initiator, which is later made available to the IKEv2 responder for re-authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but recommendations are provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-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-ikev2-resumption-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-01-24072654.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 Sat Jan 24 07:30:08 2009 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 9A44F28C2DE; Sat, 24 Jan 2009 07:30:08 -0800 (PST) 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 841AA28C14D for ; Sat, 24 Jan 2009 07:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.565 X-Spam-Level: X-Spam-Status: No, score=-5.565 tagged_above=-999 required=5 tests=[AWL=1.034, 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 RmfsbCexYBCC for ; Sat, 24 Jan 2009 07:30:05 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 6EF0728C0F4 for ; Sat, 24 Jan 2009 07:30:04 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0OFTj9T026303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 24 Jan 2009 16:29:45 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0OFTjXG020456; Sat, 24 Jan 2009 16:29:45 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Jan 2009 16:29:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 24 Jan 2009 17:30:25 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45F7FD42@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ticket #74: Extend IKE_SA_INIT instead of new exchange type Thread-Index: Acl+OK36f9CRYvU7SO6ztSEcSU5Pig== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 24 Jan 2009 15:29:44.0829 (UTC) FILETIME=[9580E2D0:01C97E38] Cc: peng.yang.chn@gmail.com Subject: [IPsec] Ticket #74: Extend IKE_SA_INIT instead of new exchange type 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, Hi Peng, I would like to close issue #74: http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/74 Here is a copy-and-paste from the page: " Use IKE_SA_INIT with a ticket payload, instead of defining a new exchange type. Main reasons: - Simpler implementation, adding a new exchange requires a lot of new code. - More efficient protocol of the responder *does not* implement this extension. - Similar to RFC 5077 (TLS stateless resumption). See http://www.ietf.org/mail-archive/web/ipsec/current/msg03356.html and follow ups. " We had a couple of mail exchanges on the list with regard to this issue and so far we had a few folks being in favor of using the IKE_SA_INIT exchange and some others to use the IKE_SESSION_RESUME exchange. Here is the current status of the discussion (at least what I got from the mailing list and from the IETF#73 IPSECME WG recording): IKE_SA_INIT exchange: * Hui Deng * Peng Yang IKE_SESSION_RESUME exchange: * Yaron Sheffer * Tero Kivinen * Stephen Kent * Hannes Tschofenig * Lakshminath Dondeti * Vidya Narayanan Please let me know if the above list is incomplete or incorrect. I guess we need a few other folks to join the discussion and to state their opinion. Ciao Hannes _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Jan 24 07:32:15 2009 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 1A2FA28C2DD; Sat, 24 Jan 2009 07:32:15 -0800 (PST) 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 38E3228C2DD for ; Sat, 24 Jan 2009 07:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.578 X-Spam-Level: X-Spam-Status: No, score=-3.578 tagged_above=-999 required=5 tests=[AWL=-0.979, 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 je8cLzPgoHUk for ; Sat, 24 Jan 2009 07:32:13 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 8203428C144 for ; Sat, 24 Jan 2009 07:32:00 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0OFVenA012262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 24 Jan 2009 16:31:40 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0OFVe9h021842; Sat, 24 Jan 2009 16:31:40 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Jan 2009 16:31:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 24 Jan 2009 17:32:20 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45F7FD43@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ticket #73: Ticket location: prefer server-side ticket Thread-Index: Acl+OPKUmzNhdBk7TkGiizDfvCplWw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 24 Jan 2009 15:31:40.0115 (UTC) FILETIME=[DA382230:01C97E38] Cc: ext Hui Deng Subject: [IPsec] Ticket #73: Ticket location: prefer server-side ticket 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, Hi Hui, I would like to close issue #73: http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/73 Here is a copy-and-paste from the page: " The document should recommend "by reference", in preference to "by value" tickets; or make "by reference" a MUST, and "by value" a SHOULD/MAY. Mainly for the following two reasons: - Less bandwidth, by not sending the ticket. - IKEv2 messages, especially the first one, had better not be fragmented. See http://www.ietf.org/mail-archive/web/ipsec/current/msg03355.html and numerous follow-ups. " We need to differentiate IKEv2 initiator and IKEv2 responder with regard to the RFC 2119 requirements: * For the IKEv2 initiator there are no implementation requirements with regard to the ticket format. That's easy. * For the IKEv2 responder we cannot require any specific format either as we are currently only recommending a possible format in the appendix. As such, the usage of a ticket by value or by reference is a purely deployment specific consideration. For example, imagine that you deploy VPN gateways and want to use ticket by references only then you could do that via configuration settings and the clients served by your VPN gateway would only receives ticket per references and no ticket by values. For the client there is no impact and at the server side it is just a configuration setting (one among many). Ciao Hannes _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Jan 24 07:32:54 2009 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 8ABA128C2CE; Sat, 24 Jan 2009 07:32:54 -0800 (PST) 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 1BFA728C144 for ; Sat, 24 Jan 2009 07:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.566 X-Spam-Level: X-Spam-Status: No, score=-5.566 tagged_above=-999 required=5 tests=[AWL=1.033, 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 MrhAS-k+18Ft for ; Sat, 24 Jan 2009 07:32:52 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id F3E1028C163 for ; Sat, 24 Jan 2009 07:32:51 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0OFWX55027578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 24 Jan 2009 16:32:33 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0OFWXao022344; Sat, 24 Jan 2009 16:32:33 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Jan 2009 16:32:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 24 Jan 2009 17:33:14 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45F7FD44@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ticket #75: Make "by reference" a first class citizen Thread-Index: Acl+ORJwmzQ3XWVGStGm3xyg7wf09g== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 24 Jan 2009 15:32:33.0274 (UTC) FILETIME=[F9E78DA0:01C97E38] Cc: ext Ahmad Muhanna Subject: [IPsec] Ticket #75: Make "by reference" a first class citizen 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, Hi Ahmad, I would like to close issue #75: http://tools.ietf.org/wg/ipsecme/trac/ticket/75 Here is a copy-and-paste from the page: " All the text you captured assumed the ticket contain a value NOT a reference. Basically in order to be clear enough and reduce a lot of exchange, the draft is written with one type of ticket is in mind, "TICKET with VALUE". I suggest that the draft be rewritten with both types of tickets in mind as the draft itself allows. See http://www.ietf.org/mail-archive/web/ipsec/current/msg03369.html and related posts. " I went through the document and made a number of editorial changes. Please take a look at the updated document and at the diff to ensure that I addressed your comment appropriately. Please let us know as soon as possible so that we can close this issue. Here is the updated document: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption- 01.txt Ciao Hannes _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kerrs@alexmo.com Sat Jan 24 08:32:57 2009 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 7799628C0F1 for ; Sat, 24 Jan 2009 08:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.308 X-Spam-Level: X-Spam-Status: No, score=-23.308 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bcPYdfRZqna for ; Sat, 24 Jan 2009 08:32:56 -0800 (PST) Received: from host35-133-static.15-79-b.business.telecomitalia.it (host35-133-static.15-79-b.business.telecomitalia.it [79.15.133.35]) by core3.amsl.com (Postfix) with SMTP id A005C28C15F for ; Sat, 24 Jan 2009 08:32:54 -0800 (PST) To: Subject: Check out hot deals From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124163255.A005C28C15F@core3.amsl.com> Date: Sat, 24 Jan 2009 08:32:54 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.bringdiscuss.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://bringdiscuss.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 4, B951. 987 Clements Road. London. SE30 5DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From nister@alexlee.com Sat Jan 24 08:42:12 2009 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 1C1D728C11C for ; Sat, 24 Jan 2009 08:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.062 X-Spam-Level: X-Spam-Status: No, score=-25.062 tagged_above=-999 required=5 tests=[BAYES_99=3.5, GB_I_LETTER=-2, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3D-G0Ot4Mxt for ; Sat, 24 Jan 2009 08:42:11 -0800 (PST) Received: from public46945.xdsl.centertel.pl (public46945.xdsl.centertel.pl [79.163.183.97]) by core3.amsl.com (Postfix) with SMTP id 848F23A694F for ; Sat, 24 Jan 2009 08:42:07 -0800 (PST) To: Subject: Great Finds From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124164209.848F23A694F@core3.amsl.com> Date: Sat, 24 Jan 2009 08:42:07 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.appreciationnine.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://appreciationnine.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 8, B546. 886 Clements Road. London. SE55 6DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From melton@alphasan.com Sat Jan 24 09:17:48 2009 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 221483A6B11 for ; Sat, 24 Jan 2009 09:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.161 X-Spam-Level: X-Spam-Status: No, score=-31.161 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, SUBJ_YOUR_DEBT=2.622, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plHVwoumkz7Z for ; Sat, 24 Jan 2009 09:17:47 -0800 (PST) Received: from optimismness-arrival.volia.net (optimismness-arrival.volia.net [77.121.143.126]) by core3.amsl.com (Postfix) with SMTP id C9C743A684C for ; Sat, 24 Jan 2009 09:17:44 -0800 (PST) To: Subject: Administrator: 7 days to save your credit From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124171745.C9C743A684C@core3.amsl.com> Date: Sat, 24 Jan 2009 09:17:44 -0800 (PST)

Having trouble viewing this email? Click here to view as a webpage.

Best prices! Go to Our Site!

This email was sent to:

This email was sent by: Canadian Internet Services, Inc.
2042 Amphitheatre Parkway, Mountain View, CA, 39945, USA.


We respect your right to privacy - view our policy

Manage Subscriptions | Update Profile | One-Click Unsubscribe
From lari@ajinfo.com.br Sat Jan 24 11:28:14 2009 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 095853A69AA for ; Sat, 24 Jan 2009 11:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.774 X-Spam-Level: X-Spam-Status: No, score=-29.774 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_IMAGE_ONLY_28=1.561, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb19XWAjr3Dc for ; Sat, 24 Jan 2009 11:28:13 -0800 (PST) Received: from ahost.de (unknown [88.238.209.243]) by core3.amsl.com (Postfix) with SMTP id C7ADE3A6809 for ; Sat, 24 Jan 2009 11:28:01 -0800 (PST) To: Subject: Mail could not be delivered From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124192803.C7ADE3A6809@core3.amsl.com> Date: Sat, 24 Jan 2009 11:28:01 -0800 (PST)

Having trouble viewing this email? Click here to view as a webpage.

Best prices! Go to Our Site!

This email was sent to:

This email was sent by: Canadian Internet Services, Inc.
4669 Amphitheatre Parkway, Mountain View, CA, 61459, USA.


We respect your right to privacy - view our policy

Manage Subscriptions | Update Profile | One-Click Unsubscribe
From lake@alro.com Sat Jan 24 12:14:32 2009 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 E29853A6AEC for ; Sat, 24 Jan 2009 12:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -31.466 X-Spam-Level: X-Spam-Status: No, score=-31.466 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_EQ_CZ=0.445, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 FNFBz3iRWAFB for ; Sat, 24 Jan 2009 12:14:32 -0800 (PST) Received: from aipsafe.cz (89-180-85-179.net.novis.pt [89.180.85.179]) by core3.amsl.com (Postfix) with SMTP id F10F63A6967 for ; Sat, 24 Jan 2009 12:14:30 -0800 (PST) To: Subject: Re: Message from President From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090124201430.F10F63A6967@core3.amsl.com> Date: Sat, 24 Jan 2009 12:14:30 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.traditiontail.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://traditiontail.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 6, B771. 667 Clements Road. London. SE63 8DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From katrineijgun@amccabe.com Sat Jan 24 17:12:32 2009 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 6ADB53A6850 for ; Sat, 24 Jan 2009 17:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.465 X-Spam-Level: X-Spam-Status: No, score=-22.465 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aJfNO3l+vmh for ; Sat, 24 Jan 2009 17:12:31 -0800 (PST) Received: from alro.com (unknown [190.14.205.197]) by core3.amsl.com (Postfix) with SMTP id C6A2D3A6848 for ; Sat, 24 Jan 2009 17:12:30 -0800 (PST) To: Subject: Your Payment Has Been Initiated From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090125011230.C6A2D3A6848@core3.amsl.com> Date: Sat, 24 Jan 2009 17:12:30 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.funintuition.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://funintuition.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BRANDKEYWORD Ltd.
Tower Bridge Business Complex. Unit 3, B886. 166 Clements Road. London. SE25 3DG

© 2006-2008 BRANDKEYWORD, Ltd. All Rights Reserved

From janus@alum.mit.edu Sat Jan 24 18:05:30 2009 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 C27643A6A5D for ; Sat, 24 Jan 2009 18:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -46.672 X-Spam-Level: X-Spam-Status: No, score=-46.672 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 7VLZj9zmJcSN for ; Sat, 24 Jan 2009 18:05:30 -0800 (PST) Received: from advantagelc.com (unknown [190.71.163.12]) by core3.amsl.com (Postfix) with SMTP id 287683A6784 for ; Sat, 24 Jan 2009 18:05:26 -0800 (PST) To: Subject: Message from InterScan Messaging Security Suite From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090125020527.287683A6784@core3.amsl.com> Date: Sat, 24 Jan 2009 18:05:26 -0800 (PST)

Having trouble viewing this email? Click here to view as a webpage.

Best prices! Go to Our Site!

This email was sent to:

This email was sent by: Canadian Internet Services, Inc.
3203 Amphitheatre Parkway, Mountain View, CA, 21468, USA.


We respect your right to privacy - view our policy

Manage Subscriptions | Update Profile | One-Click Unsubscribe
From mutilators@aeclassic.com Sun Jan 25 04:27:07 2009 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 7B33E3A682F for ; Sun, 25 Jan 2009 04:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -42.143 X-Spam-Level: X-Spam-Status: No, score=-42.143 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGD3ARoFKDPk for ; Sun, 25 Jan 2009 04:27:06 -0800 (PST) Received: from 3cint.com (unknown [93.177.128.31]) by core3.amsl.com (Postfix) with SMTP id 84E6C3A69A3 for ; Sun, 25 Jan 2009 04:27:03 -0800 (PST) To: Subject: Notification Type: All OK From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090125122704.84E6C3A69A3@core3.amsl.com> Date: Sun, 25 Jan 2009 04:27:03 -0800 (PST)

Having trouble viewing this email? Click here to view as a webpage.

Best prices! Go to Our Site!

This email was sent to:

This email was sent by: Canadian Internet Services, Inc.
4057 W. Abram St. City, Arlington


We respect your right to privacy - view our policy

Manage Subscriptions | Update Profile | One-Click Unsubscribe
From ipsec-bounces@ietf.org Sun Jan 25 07:46:33 2009 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 D58C63A6972; Sun, 25 Jan 2009 07:46:33 -0800 (PST) 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 134DF28C158 for ; Sun, 25 Jan 2009 07:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.085 X-Spam-Level: X-Spam-Status: No, score=-3.085 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdvLfxWVpQlr for ; Sun, 25 Jan 2009 07:46:31 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id EECE43A68ED for ; Sun, 25 Jan 2009 07:46:30 -0800 (PST) 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 n0PFkB5f014724; Sun, 25 Jan 2009 17:46:12 +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; Sun, 25 Jan 2009 17:46:11 +0200 From: Yaron Sheffer To: Tero Kivinen , Paul Hoffman Date: Sun, 25 Jan 2009 17:46:10 +0200 Thread-Topic: [IPsec] Resolution of some open issues Thread-Index: Acl9X727QJ9eYSbCTe6qfXisqzJnUwBpAdbQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63ABD0@il-ex01.ad.checkpoint.com> References: <18809.51209.570727.898337@fireball.kivinen.iki.fi> In-Reply-To: <18809.51209.570727.898337@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Resolution of some open issues 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 > > > #56: Address and config values lifetime > > No comment on this, so it is still open. There were two proposed > > solutions: > > - Gateway should try to renew DHCP leases, but nuke the SA if > lease > > renewal fails > > - Lifetime of the first lease is the lifetime of the SA, no > renewals > > I think we should left that for implementations to decide. I.e. in > some implementations the gateway can renew the DHCP lease, on some > implementations it can simply delete the IKE SA (as there is no agreed > upon lifetime of IKE SAs in IKEv2 anyways). > I agree with Tero. But in any case, we need to clarify that config values (and in particular the IP address) are valid exactly for the lifetime of the IKE SA. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 25 08:01:03 2009 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 3067E3A6AFF; Sun, 25 Jan 2009 08:01:03 -0800 (PST) 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 9EFB03A6AFF for ; Sun, 25 Jan 2009 08:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.102 X-Spam-Level: X-Spam-Status: No, score=-3.102 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH8JkzPrRlSK for ; Sun, 25 Jan 2009 08:01:01 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 78ACE3A6829 for ; Sun, 25 Jan 2009 08:01:01 -0800 (PST) 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 n0PG0g5f017739; Sun, 25 Jan 2009 18:00:43 +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; Sun, 25 Jan 2009 18:00:42 +0200 From: Yaron Sheffer To: Paul Hoffman , IPsecme WG Date: Sun, 25 Jan 2009 18:00:41 +0200 Thread-Topic: [IPsec] Resolution of some open issues Thread-Index: Acl8669sHoz6cvu7SgmgpaI+z9HSXwCGGqRA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63ABD5@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] Resolution of some open issues 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="===============0740161642==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0740161642== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63ABD5ilex01adcheck_" --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63ABD5ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, I propose to append the following text to Sec. 2.12: The reader is referred to Sec. 5 of [1] for a security analysis of this pra= ctice, and for additional security considerations when reusing ephemeral EC= DH keys. [1] On reusing ephemeral public keys in Diffie-Hellman key agreement protoc= ols, http://www.cacr.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf= (preprint). Thanks, Yaron > > #55: Exponential reuse - reference for section 2.12 > We don't have a good model for what we mean by "secure" reuse (th= e > new keys are related but not predictable), so we can skip this. > --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63ABD5ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

I propose to append the following text to Sec. 2.12:

 

The reader is referred to Sec. 5 of [1] for a se= curity analysis of this practice, and for additional security considerations when reusing ephemeral ECDH keys.

 

[1] On reusing ephemeral public keys in Diffie-H= ellman key agreement protocols, http://www.cacr.math.uwaterloo.ca/~ajmeneze/publications/ephemeral.pdf= (preprint).

 

Thanks,

      Yaron

>

> #55: Exponential reuse - reference for section 2.12

>         We don't have = a good model for what we mean by "secure" reuse (the<= /p>

>         new keys are related but not predictable), so we can skip this.

>

 

--_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63ABD5ilex01adcheck_-- --===============0740161642== 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 --===============0740161642==-- From mvandevelde@aib-vincotte.be Sun Jan 25 10:23:12 2009 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 E9D2F28C0F7 for ; Sun, 25 Jan 2009 10:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.664 X-Spam-Level: X-Spam-Status: No, score=-20.664 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, SUBJ_YOUR_DEBT=2.622, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVn+-WfeDl8n for ; Sun, 25 Jan 2009 10:23:12 -0800 (PST) Received: from esc26.neoplus.adsl.tpnet.pl (euu163.neoplus.adsl.tpnet.pl [83.20.192.163]) by core3.amsl.com (Postfix) with SMTP id BD11A3A6B57 for ; Sun, 25 Jan 2009 10:23:07 -0800 (PST) To: Subject: Administrator: 7 days to save your credit From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090125182309.BD11A3A6B57@core3.amsl.com> Date: Sun, 25 Jan 2009 10:23:07 -0800 (PST)

Having trouble viewing this email? Click here to view as a webpage.

Best prices! Go to Our Site!

This email was sent to:

This email was sent by: Canadian Internet Services, Inc.
371 Taylor Road P.O. Box 3621


We respect your right to privacy - view our policy

Manage Subscriptions | Update Profile | One-Click Unsubscribe
From ipsec-bounces@ietf.org Sun Jan 25 12:27:15 2009 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 AD71E28C0FD; Sun, 25 Jan 2009 12:27:15 -0800 (PST) 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 391623A6B6C for ; Sun, 25 Jan 2009 12:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 2CoZx41-RRBF for ; Sun, 25 Jan 2009 12:27:13 -0800 (PST) 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 177EF3A680E for ; Sun, 25 Jan 2009 12:27:12 -0800 (PST) Received: from [165.227.249.206] (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 n0PKQp2Z070233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2009 13:26:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18809.51499.928855.243725@fireball.kivinen.iki.fi> References: <18809.51499.928855.243725@fireball.kivinen.iki.fi> Date: Sun, 25 Jan 2009 12:26:49 -0800 To: Tero Kivinen , Scott C Moonen From: Paul Hoffman Cc: IPsecme WG Subject: [IPsec] Wording for issue #40 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 3:42 PM +0200 1/23/09, Tero Kivinen wrote: >Scott C Moonen writes: >> Paul, regarding #40: >> >> > If NAT-T is supported, all devices MUST be able to receive and >> process >> > both UDP encapsulated and non-UDP encapsulated packets at any >> time. >> >> How should I read this statement in the context of multiple address >> families? If an implementation supports IPv4 and IPv6, but supports NAT-T >> only for IPv4, can I read this statement to say that the implementation >> MUST tolerate UDP-encapsulation in the absence of a NAT only for IPv4? > >I would interpret it that if you support NAT-T only for IPv4, and you >do not support NAT-T for IPv6, then you must be able to receive and >process UDP encapsulated and non-UDP encapsulated packets only from >IPv4. > >If you negotiated with IPv6 with a remote peer, the remote peer will >only see that you do not support NAT-T, and that is the situation for >him. He does not know that you support NAT-T for some other address >family. > >This is also same if you have NAT-T support disabled by policy for >some interfaces or IP-addresses. > >Perhaps the "If NAT-T is supported, ..." should be changed to "If >NAT-T is supported (i.e. NAT_DETECTION_*_IP payloads were exchanged >during IKE_SA_INIT), ...". I like that wording. Scott, does that clear it up for you? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 25 12:36:38 2009 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 690C13A6B6F; Sun, 25 Jan 2009 12:36:38 -0800 (PST) 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 B0B753A6B66 for ; Sun, 25 Jan 2009 12:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 8+sU87aL4Spv for ; Sun, 25 Jan 2009 12:36:36 -0800 (PST) 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 956FA3A6B6E for ; Sun, 25 Jan 2009 12:36:35 -0800 (PST) Received: from [165.227.249.206] (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 n0PKaFd1070480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2009 13:36:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <18809.51499.928855.243725@fireball.kivinen.iki.fi> Date: Sun, 25 Jan 2009 12:36:13 -0800 To: Scott C Moonen , Tero Kivinen From: Paul Hoffman Cc: IPsecme WG Subject: Re: [IPsec] Resolution of some open issues 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 11:36 AM -0500 1/23/09, Scott C Moonen wrote: >One more comment -- the non-ESP marker is defined only for use on port 4500. When data is received on port 500, implementations do not expect it to be present. Consequently, to avoid any ambiguity, we should probably take care to stipulate here that if you unilaterally choose to float to port 4500, even in the absence of a NAT, you MUST send to port 4500. This seems gratuitous. Only ports 500 and 4500 are listed in the document, and there are statements like "IKE runs over UDP ports 500 and 4500" in a few places. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 25 12:47:15 2009 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 1410D3A68FD; Sun, 25 Jan 2009 12:47:15 -0800 (PST) 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 B374B3A6834 for ; Sun, 25 Jan 2009 12:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 KXqyOcaXt5hA for ; Sun, 25 Jan 2009 12:47:13 -0800 (PST) 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 61C583A68FD for ; Sun, 25 Jan 2009 12:47:13 -0800 (PST) Received: from [165.227.249.206] (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 n0PKkq45070727 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2009 13:46:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45F7FD41@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD41@FIESEXC015.nsn-intra.net> Date: Sun, 25 Jan 2009 12:46:48 -0800 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , From: Paul Hoffman Cc: kivinen@iki.fi Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) 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 5:29 PM +0200 1/24/09, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >I would like to close issue #70: >http://tools.ietf.org/wg/ipsecme/trac/ticket/70 > >Here is a copy-and-paste from the page: >" >What is the reason for sending the lifetime of the ticket along with >ticket? We have mostly tried to get rid of lifetimes visible on protocol >level on the IKEv2 and made all those local policy matters, so why do we >need externally visible lifetime for the ticket? > >What purpose does it serve? Why does the client need to know the ticket >lifetime? > >It would be much simplier if this was left as local matter, i.e. client >would always use the latest ticket is has, and every time if he has >ticket (i.e. the last IKE SA was NOT deleted, but was interrupted), it >would send that to the server (i.e. use the IKE_SESSION_RESUME). If >ticket is no longer valid in the server, server will reply with >N(TICKET_NACK) and client will restart with full exchange. In most of >the cases the resumption happens quite quickly after the connection was >interrupted, so most likely the ticket is still valid. > >Then for the server side when the ticket is about expire, it would >simply push new ticket to the client using informational message (this >is set as one of the requirements "o Allowing a gateway to push state to >clients.", but I do not see the actual description how to do it in >document). > >This way server could use also non-time based policies for the ticket >lifetimes, i.e. it could for example decide to change the ticket >encryption key every now and then, and then slowly generate new tickets >for those sessions using old key, and when all sessions have been sent >new ticket, it can forget the old ticket encryption key. > >Also what is the meaning of the lifetime field of the N(TICKET_OPAQUE) >in IKE_SESSION_RESUME? Does it need to be copied from the original >notification or what? >" > >There are obviously design choices one can make about the way how the >ticket lifecycle looks like. The authors thought it would make sense to >give the client a clue how long the ticket would be valid. Then you should say why that clue is useful in the document. Given what is currently in the document, I would agree with Tero: it is violating the design principle of IKEv2 to get rid of lifetimes. >One way is as good as the other one. Without more justification, I would disagree. The current document requires the client to track the lifetime and pre-emptively get a new ticket when it is "about to expire" and so on. At least to me, that seems like more overhead for both parties than requiring them to keep watching the clock and acting when the countdown gets close. >When we change it in the way >someone else will come along and argue that it should be done similar to >RFC 5077 or to the way Kerberos does it. Subsequently, someone will come >along to tell us that RFC 4962 says that authorization decisions >(including the lifetime) should be synchronized between all involved >parties. Etc. etc. Sure, but you still have to justify your choice, not just say "seems good". >I don't believe that the argument regarding changing the encryption >algorithm is super realistic as the lifetime of the ticket is in the >order of hours and not weeks or months where switching of algorithm >makes sense. The issue is changing the encryption *key*, not the algorithm. I can see definite reasons to change a key periodically, particularly in systems that stay up for months (or hopefully years) at a time. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 25 12:49:09 2009 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 99D143A6906; Sun, 25 Jan 2009 12:49:09 -0800 (PST) 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 4B0AA3A6906 for ; Sun, 25 Jan 2009 12:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 K8UfzwJebeuq for ; Sun, 25 Jan 2009 12:49:07 -0800 (PST) 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 320B63A6834 for ; Sun, 25 Jan 2009 12:49:06 -0800 (PST) Received: from [165.227.249.206] (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 n0PKmkb3070770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 25 Jan 2009 13:48:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45F7FD42@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD42@FIESEXC015.nsn-intra.net> Date: Sun, 25 Jan 2009 12:48:44 -0800 To: From: Paul Hoffman Subject: Re: [IPsec] Ticket #74: Extend IKE_SA_INIT instead of new exchange type 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 5:30 PM +0200 1/24/09, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >Here is a copy-and-paste from the page: >" >Use IKE_SA_INIT with a ticket payload, instead of defining a new >exchange type. > >Main reasons: - Simpler implementation, adding a new exchange requires a >lot of new code. - More efficient protocol of the responder *does not* >implement this extension. - Similar to RFC 5077 (TLS stateless >resumption). > >See http://www.ietf.org/mail-archive/web/ipsec/current/msg03356.html and >follow ups. >" > >I guess we need a few other folks to join the discussion and to state >their opinion. Yes, definitely. At this point, we have heard from two groups of authors; hearing from the wider implementers community would be valuable. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 25 12:51:19 2009 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 0DAD73A6B71; Sun, 25 Jan 2009 12:51:19 -0800 (PST) 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 776B93A6B71 for ; Sun, 25 Jan 2009 12:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 cHO15lQ7riyq for ; Sun, 25 Jan 2009 12:51:16 -0800 (PST) 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 1F8833A6B73 for ; Sun, 25 Jan 2009 12:51:15 -0800 (PST) Received: from [165.227.249.206] (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 n0PKos78070850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2009 13:50:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45F7FD43@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD43@FIESEXC015.nsn-intra.net> Date: Sun, 25 Jan 2009 12:50:51 -0800 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , From: Paul Hoffman Cc: ext Hui Deng Subject: Re: [IPsec] Ticket #73: Ticket location: prefer server-side ticket 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 5:32 PM +0200 1/24/09, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >I would like to close issue #73: >http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/73 > >Here is a copy-and-paste from the page: >" >The document should recommend "by reference", in preference to "by >value" tickets; or make "by reference" a MUST, and "by value" a >SHOULD/MAY. Mainly for the following two reasons: > >- Less bandwidth, by not sending the ticket. - IKEv2 messages, >especially the first one, had better not be fragmented. > >See http://www.ietf.org/mail-archive/web/ipsec/current/msg03355.html and >numerous follow-ups. >" > >We need to differentiate IKEv2 initiator and IKEv2 responder with regard >to the RFC 2119 requirements: > >* For the IKEv2 initiator there are no implementation requirements with >regard to the ticket format. That's easy. > >* For the IKEv2 responder we cannot require any specific format either >as we are currently only recommending a possible format in the appendix. > > >As such, the usage of a ticket by value or by reference is a purely >deployment specific consideration. For example, imagine that you deploy >VPN gateways and want to use ticket by references only then you could do >that via configuration settings and the clients served by your VPN >gateway would only receives ticket per references and no ticket by >values. For the client there is no impact and at the server side it is >just a configuration setting (one among many). Wearing my co-chair hat and looking at the charter, I agree with Hannes. This issue can be closed. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 25 13:24:55 2009 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 5186D28C1BD; Sun, 25 Jan 2009 13:24:55 -0800 (PST) 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 AFAA028C1BD for ; Sun, 25 Jan 2009 13:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 znwVk7Hbmnn0 for ; Sun, 25 Jan 2009 13:24:53 -0800 (PST) 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 94DA028C199 for ; Sun, 25 Jan 2009 13:24:52 -0800 (PST) Received: from [165.227.249.206] (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 n0PLOWrx071966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2009 14:24:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18809.51209.570727.898337@fireball.kivinen.iki.fi> References: <18809.51209.570727.898337@fireball.kivinen.iki.fi> Date: Sun, 25 Jan 2009 13:24:30 -0800 To: Tero Kivinen From: Paul Hoffman Cc: IPsecme WG Subject: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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 3:37 PM +0200 1/23/09, Tero Kivinen wrote: > > #9: Notification when creation of CHILD_SA fails >> No comments, but seems important. New text will say: >> - Failure of CHILD SA creation should not tear down IKE SA because >> there is no reason to lose the work done >> - When IKE SA is not created, and we need to send error message back >> about that, do not encrypt the message because it will not >> authenticate. > >Actually someone pointed out one benefit for the second case, i.e. >when IKE SA cannot be created and we are sending error message back. >If the error message is encrypted (even when it is unauthenticated) >that proofs that the message was sent by the same peer who replied to >the IKE_SA_INIT. It does, but it also forces all implementations to keep around keys they know are unauthenticated. That might violate some security policies. >Because of this I think it would be good to split the original #9 to >two cases, one that I do not think anybody disagrees is that failure >of CHILD SA creation should not tear down IKE SA. > >And the other is how is the fatal IKE SA creation errors sent back >(i.e. whether to encrypt them or not). I agree that we should be focusing on the second issue. However, I disagree with the idea that we should support unauthenticated encryption, even for this one error message. How do others feel? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 25 13:31:34 2009 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 EF89428C1CB; Sun, 25 Jan 2009 13:31:33 -0800 (PST) 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 730DD28C1CB for ; Sun, 25 Jan 2009 13:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=-0.977, 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 HdOn48EBKuSI for ; Sun, 25 Jan 2009 13:31:32 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 26AD428C1C9 for ; Sun, 25 Jan 2009 13:31:31 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0PLVDOJ025278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 25 Jan 2009 22:31:13 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0PLVDEU024270; Sun, 25 Jan 2009 22:31:13 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Jan 2009 22:31:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 25 Jan 2009 23:31:50 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45F7FF42@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) Thread-Index: Acl/LhU96DJUnb2MTpOe4Ao8WxrflwABVXMg References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD41@FIESEXC015.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Paul Hoffman" , X-OriginalArrivalTime: 25 Jan 2009 21:31:10.0551 (UTC) FILETIME=[3D9D3670:01C97F34] Cc: kivinen@iki.fi Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) 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 5:29 PM +0200 1/24/09, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >>I would like to close issue #70: >>http://tools.ietf.org/wg/ipsecme/trac/ticket/70 >> >>Here is a copy-and-paste from the page: >>" >>What is the reason for sending the lifetime of the ticket along with >>ticket? We have mostly tried to get rid of lifetimes visible on >>protocol level on the IKEv2 and made all those local policy >matters, so >>why do we need externally visible lifetime for the ticket? >> >>What purpose does it serve? Why does the client need to know >the ticket >>lifetime? >> >>It would be much simplier if this was left as local matter, >i.e. client >>would always use the latest ticket is has, and every time if he has >>ticket (i.e. the last IKE SA was NOT deleted, but was >interrupted), it >>would send that to the server (i.e. use the IKE_SESSION_RESUME). If >>ticket is no longer valid in the server, server will reply with >>N(TICKET_NACK) and client will restart with full exchange. In most of >>the cases the resumption happens quite quickly after the >connection was >>interrupted, so most likely the ticket is still valid. >> >>Then for the server side when the ticket is about expire, it would >>simply push new ticket to the client using informational >message (this >>is set as one of the requirements "o Allowing a gateway to push state >>to clients.", but I do not see the actual description how to do it in >>document). >> >>This way server could use also non-time based policies for the ticket >>lifetimes, i.e. it could for example decide to change the ticket >>encryption key every now and then, and then slowly generate >new tickets >>for those sessions using old key, and when all sessions have >been sent >>new ticket, it can forget the old ticket encryption key. >> >>Also what is the meaning of the lifetime field of the >N(TICKET_OPAQUE) >>in IKE_SESSION_RESUME? Does it need to be copied from the original >>notification or what? >>" >> >>There are obviously design choices one can make about the way how the >>ticket lifecycle looks like. The authors thought it would >make sense to >>give the client a clue how long the ticket would be valid. > >Then you should say why that clue is useful in the document. >Given what is currently in the document, I would agree with >Tero: it is violating the design principle of IKEv2 to get rid >of lifetimes. > >>One way is as good as the other one. > >Without more justification, I would disagree. The current >document requires the client to track the lifetime and >pre-emptively get a new ticket when it is "about to expire" >and so on. At least to me, that seems like more overhead for >both parties than requiring them to keep watching the clock >and acting when the countdown gets close. > >>When we change it in the way >>someone else will come along and argue that it should be done similar >>to RFC 5077 or to the way Kerberos does it. Subsequently, >someone will >>come along to tell us that RFC 4962 says that authorization decisions >>(including the lifetime) should be synchronized between all involved >>parties. Etc. etc. > >Sure, but you still have to justify your choice, not just say >"seems good". The client would know how long the ticket is valid. It can therefore easily make an informed decision of when one of the tickets became invalid rather than probing the server. RFC 5077 follows a similar approach in the sense that the lifetime is communicated as a hint. >>I don't believe that the argument regarding changing the encryption >>algorithm is super realistic as the lifetime of the ticket is in the >>order of hours and not weeks or months where switching of algorithm >>makes sense. > >The issue is changing the encryption *key*, not the algorithm. >I can see definite reasons to change a key periodically, >particularly in systems that stay up for months (or hopefully >years) at a time. But the VPN gateway will be able to change the key that is used to protect the ticket anyway. This is pretty much independent of the mechanism of how the client presents the ticket to the VPN gateway. There will be a period where the two or more keys will be active as the VPN gatewy starts handing out tickets protected with the new key whereas some tickets are still with some clients utlizing the old key. Am I missing the point here a bit? Ciao Hannes > >--Paul Hoffman, Director >--VPN Consortium >_______________________________________________ >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 Sun Jan 25 13:47:31 2009 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 E863028C1DF; Sun, 25 Jan 2009 13:47:30 -0800 (PST) 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 730DE28C1DF for ; Sun, 25 Jan 2009 13:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 uKE8kCJNufxO for ; Sun, 25 Jan 2009 13:47:28 -0800 (PST) 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 54BF628C193 for ; Sun, 25 Jan 2009 13:47:28 -0800 (PST) Received: from [165.227.249.206] (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 n0PLl8ML072667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 25 Jan 2009 14:47:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45F7FF42@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD41@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45F7FF42@FIESEXC015.nsn-intra.net> Date: Sun, 25 Jan 2009 13:47:06 -0800 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , From: Paul Hoffman Cc: kivinen@iki.fi Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) 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 11:31 PM +0200 1/25/09, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >The client would know how long the ticket is valid. It can therefore >easily make an informed decision of when one of the tickets became >invalid rather than probing the server. > >RFC 5077 follows a similar approach in the sense that the lifetime is >communicated as a hint. True. Are you saying that you consider the lifetime in draft-ietf-ipsecme-ikev2-resumption to be a hint, not a hard expiry? I did not get that impression from the draft. >Am I missing the point here a bit? Possibly. My point (and I think Tero's point) is that having the two sides need to keep watching the time is possibly more fragile than periodic rechecks. On the other hand, if you are now saying that the lifetime is a hint and not definitive, then the two sides don't really need to keep track that closely. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jan 25 23:45:01 2009 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 E76E03A69FD; Sun, 25 Jan 2009 23:45:01 -0800 (PST) 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 ADCD03A682E for ; Sun, 25 Jan 2009 23:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 cIxawf-1o3bK for ; Sun, 25 Jan 2009 23:44:57 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8B7623A69F0 for ; Sun, 25 Jan 2009 23:44:56 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 5F99629C003; Mon, 26 Jan 2009 09:44:38 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4B3A929C001; Mon, 26 Jan 2009 09:44:37 +0200 (IST) X-CheckPoint: {497D6746-10000-88241DC2-7B6} 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 n0Q7ia5f018723; Mon, 26 Jan 2009 09:44:36 +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, 26 Jan 2009 09:44:36 +0200 From: Yoav Nir To: Paul Hoffman , "ipsec@ietf.org" Date: Mon, 26 Jan 2009 09:44:37 +0200 Thread-Topic: [IPsec] Ticket #74: Extend IKE_SA_INIT instead of new exchange type Thread-Index: Acl/LlfIha1I5PHTRBOsC4/1kOp/UQAWNlFQ Message-ID: <9FB7C7CE79B84449B52622B506C78036130846AE97@il-ex01.ad.checkpoint.com> References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD42@FIESEXC015.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] Ticket #74: Extend IKE_SA_INIT instead of new exchange type 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 said: > > At 5:30 PM +0200 1/24/09, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >Here is a copy-and-paste from the page: > >" > >Use IKE_SA_INIT with a ticket payload, instead of defining a new > >exchange type. > > > >Main reasons: - Simpler implementation, adding a new exchange requires a > >lot of new code. - More efficient protocol of the responder *does not* > >implement this extension. - Similar to RFC 5077 (TLS stateless > >resumption). > > > >See http://www.ietf.org/mail-archive/web/ipsec/current/msg03356.html and > >follow ups. > >" > > > >I guess we need a few other folks to join the discussion and to state > >their opinion. > > Yes, definitely. At this point, we have heard from two groups of authors; > hearing from the wider implementers community would be valuable. IMO it's six of one, half a dozen of another. The choice here is between making the IKE_SA_INIT exchange more complex and adding a new, rather simple exchange. Adding the ticket to the IKE_SA_INIT means that there are two paths in the IKE_SA_INIT code, and state must be kept to keep the two apart. This choice has the advantage, as Hui pointed out, that if the ticket is in the IKE_SA_INIT, you can fall back to regular IKE, saving us one round-trip in the weird and rare case that the gateway cannot use the ticket (the ticket store died? Key rolled over while the connection was down?) A new exchange will involve more new lines of code, but the difference is not great, and this has the advantage of having both the IKE_SA_INIT and the IKE_RESUMPTION exchanges remain simple. So I think both options are good, but if I have to choose, I would go with adding a new exchange, because two simple exchanges have a lesser potential for problems than one complex exchange. Yoav Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 26 02:35:41 2009 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 6B3013A6A47; Mon, 26 Jan 2009 02:35:41 -0800 (PST) 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 D401E3A6A47 for ; Mon, 26 Jan 2009 02:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 jrM+NjMEQTEq for ; Mon, 26 Jan 2009 02:35:39 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B95A53A69AD for ; Mon, 26 Jan 2009 02:35:38 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 38EB329C004; Mon, 26 Jan 2009 12:35:20 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id DC61A29C003 for ; Mon, 26 Jan 2009 12:35:18 +0200 (IST) X-CheckPoint: {497D8F46-10000-88241DC2-7B6} 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 n0QAZG5g003833 for ; Mon, 26 Jan 2009 12:35:18 +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, 26 Jan 2009 12:35:17 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Mon, 26 Jan 2009 12:35:10 +0200 Thread-Topic: virtual interim meeting on Feb. 3 - additional details Thread-Index: Acl04ZpSkdolgYWNR9OpwcxbHbtsowAkpQBQAZCPb1AADCT20ADufM+A Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63ACA6@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63A89D@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63A89D@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 Subject: [IPsec] virtual interim meeting on Feb. 3 - additional details 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 everyone, The meeting is on for next week, and authors are reminded to send their slides on time. We are planning to use the TeamSpeak application for both voice conferencing and IM. Paul has kindly set up a private server for our use, and the full details are on the wiki: http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls Please make sure to download and try the client at least one day in advance. The server is already available. Let us know if you have any problems. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Yaron Sheffer > Sent: Wednesday, January 21, 2009 19:02 > To: ipsec@ietf.org > Subject: [IPsec] ipsecme - virtual interim meeting on Feb. 3 > > Hi everyone, > > The ipsecme working group will hold a virtual interim meeting on Feb. 3, > 16:00 GMT (18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), for 2 hours. > Like the Minneapolis meeting, we will focus on getting IKEv2-bis issues > closed. But there's lots of other fun stuff. > > Proposed agenda: > > - Agenda bash (0:05) > - Session resumption update (0:15) > - Visibility heuristics (0:15) > - Redirect open issues (0:10) > - Roadmap document (plus call for volunteers) (0:10) > - Mandatory access control (off-charter item) (0:15) > - IKEv2-bis open issues (0:50) > > We will send an update within the next week on the technicalities of the > call. > > Document editors, please send me your slides by Jan. 29. > > Thanks, > Yaron Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 26 03:29:34 2009 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 D3B0D3A69DE; Mon, 26 Jan 2009 03:29:34 -0800 (PST) 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 87B1E3A69DE for ; Mon, 26 Jan 2009 03:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 vTaXWgKkBFkx for ; Mon, 26 Jan 2009 03:29:32 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 49A7A3A6920 for ; Mon, 26 Jan 2009 03:29:32 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2EAC529C003; Mon, 26 Jan 2009 13:29:14 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1B87A29C001; Mon, 26 Jan 2009 13:29:13 +0200 (IST) X-CheckPoint: {497D9BE8-10000-88241DC2-7B6} 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 n0QBTC5f017357; Mon, 26 Jan 2009 13:29:12 +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, 26 Jan 2009 13:29:12 +0200 From: Yoav Nir To: IPsecme WG Date: Mon, 26 Jan 2009 13:29:12 +0200 Thread-Topic: [IPsec] Issue #9: Notification when creation of CHILD_SA fails Thread-Index: Acl/M1g2sOJG5bS4Qeal3llTe22VbwAc1Jbg Message-ID: <9FB7C7CE79B84449B52622B506C78036130846AEF7@il-ex01.ad.checkpoint.com> References: <18809.51209.570727.898337@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Paul Hoffman , Tero Kivinen Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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: > > At 3:37 PM +0200 1/23/09, Tero Kivinen wrote: > > > #9: Notification when creation of CHILD_SA fails > >> No comments, but seems important. New text will say: > >> - Failure of CHILD SA creation should not tear down IKE SA because > >> there is no reason to lose the work done > >> - When IKE SA is not created, and we need to send error message > back > >> about that, do not encrypt the message because it will not > >> authenticate. > > > >Actually someone pointed out one benefit for the second case, i.e. > >when IKE SA cannot be created and we are sending error message back. > >If the error message is encrypted (even when it is unauthenticated) > >that proofs that the message was sent by the same peer who replied to > >the IKE_SA_INIT. > > It does, but it also forces all implementations to keep around keys they > know are unauthenticated. That might violate some security policies. Maybe, but I'm not aware of any such policies. Besides, the keys are only kept long enough to produce an error message (at the time, the initiator thinks everything is going well) > >Because of this I think it would be good to split the original #9 to > >two cases, one that I do not think anybody disagrees is that failure > >of CHILD SA creation should not tear down IKE SA. > > > >And the other is how is the fatal IKE SA creation errors sent back > >(i.e. whether to encrypt them or not). > > I agree that we should be focusing on the second issue. However, I > disagree with the idea that we should support unauthenticated encryption, > even for this one error message. How do others feel? The IKE_AUTH exchange is encrypted but not authenticated. I don't see any problem with sending an encrypted message after authentication has failed. OTOH I see plenty wrong with allowing IKE-SA-destroying messages in the clear after IKE_AUTH has ended. Sure you can get around this problem with liveness check and waiting before believing the failure message, but requiring it to be encrypted and protected foils such DoS attacks much more effectively. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 26 04:00:59 2009 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 E992F3A6A9F; Mon, 26 Jan 2009 04:00:58 -0800 (PST) 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 5AB8D3A6B3F for ; Mon, 26 Jan 2009 04:00:57 -0800 (PST) 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 ByviLcaSCbOn for ; Mon, 26 Jan 2009 04:00:56 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id 217843A6AF7 for ; Mon, 26 Jan 2009 04:00:56 -0800 (PST) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e31.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0QBwZ1d032350 for ; Mon, 26 Jan 2009 04:58:35 -0700 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0QC0a6o163104 for ; Mon, 26 Jan 2009 05:00:36 -0700 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n0QC0Rmi023621 for ; Mon, 26 Jan 2009 05:00:27 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n0QC0RGE023618; Mon, 26 Jan 2009 05:00:27 -0700 In-Reply-To: References: <18809.51499.928855.243725@fireball.kivinen.iki.fi> To: Paul Hoffman MIME-Version: 1.0 X-KeepSent: E0070755:CA8F08B6-8525754A:0041B884; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/26/2009 06:58:01 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/26/2009 06:58:01 AM, Serialize complete at 01/26/2009 06:58:01 AM, S/MIME Sign failed at 01/26/2009 06:58:01 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 01/26/2009 05:00:26, Serialize complete at 01/26/2009 05:00:26 Message-ID: Date: Mon, 26 Jan 2009 07:00:26 -0500 Cc: IPsecme WG , Tero Kivinen Subject: Re: [IPsec] Wording for issue #40 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="===============0254662174==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0254662174== Content-Type: multipart/alternative; boundary="=_alternative 0041BCA98525754A_=" This is a multipart message in MIME format. --=_alternative 0041BCA98525754A_= Content-Type: text/plain; charset="US-ASCII" Paul, Tero, that sounds good. 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: Paul Hoffman To: Tero Kivinen , Scott C Moonen/Raleigh/IBM@IBMUS Cc: IPsecme WG Date: 01/25/2009 03:27 PM Subject: Wording for issue #40 At 3:42 PM +0200 1/23/09, Tero Kivinen wrote: >Scott C Moonen writes: >> Paul, regarding #40: >> >> > If NAT-T is supported, all devices MUST be able to receive and >> process >> > both UDP encapsulated and non-UDP encapsulated packets at any >> time. >> >> How should I read this statement in the context of multiple address >> families? If an implementation supports IPv4 and IPv6, but supports NAT-T >> only for IPv4, can I read this statement to say that the implementation >> MUST tolerate UDP-encapsulation in the absence of a NAT only for IPv4? > >I would interpret it that if you support NAT-T only for IPv4, and you >do not support NAT-T for IPv6, then you must be able to receive and >process UDP encapsulated and non-UDP encapsulated packets only from >IPv4. > >If you negotiated with IPv6 with a remote peer, the remote peer will >only see that you do not support NAT-T, and that is the situation for >him. He does not know that you support NAT-T for some other address >family. > >This is also same if you have NAT-T support disabled by policy for >some interfaces or IP-addresses. > >Perhaps the "If NAT-T is supported, ..." should be changed to "If >NAT-T is supported (i.e. NAT_DETECTION_*_IP payloads were exchanged >during IKE_SA_INIT), ...". I like that wording. Scott, does that clear it up for you? --Paul Hoffman, Director --VPN Consortium --=_alternative 0041BCA98525754A_= Content-Type: text/html; charset="US-ASCII"
Paul, Tero, that sounds good.  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: Paul Hoffman <paul.hoffman@vpnc.org>
To: Tero Kivinen <kivinen@iki.fi>, Scott C Moonen/Raleigh/IBM@IBMUS
Cc: IPsecme WG <ipsec@ietf.org>
Date: 01/25/2009 03:27 PM
Subject: Wording for issue #40




At 3:42 PM +0200 1/23/09, Tero Kivinen wrote:
>Scott C Moonen writes:
>> Paul, regarding #40:
>>
>>         > If NAT-T is supported, all devices MUST be able to receive and
>> process
>>         > both UDP encapsulated and non-UDP encapsulated packets at any
>> time.
>>
>> How should I read this statement in the context of multiple address
>> families?  If an implementation supports IPv4 and IPv6, but supports NAT-T
>> only for IPv4, can I read this statement to say that the implementation
>> MUST tolerate UDP-encapsulation in the absence of a NAT only for IPv4?
>
>I would interpret it that if you support NAT-T only for IPv4, and you
>do not support NAT-T for IPv6, then you must be able to receive and
>process UDP encapsulated and non-UDP encapsulated packets only from
>IPv4.
>
>If you negotiated with IPv6 with a remote peer, the remote peer will
>only see that you do not support NAT-T, and that is the situation for
>him. He does not know that you support NAT-T for some other address
>family.
>
>This is also same if you have NAT-T support disabled by policy for
>some interfaces or IP-addresses.
>
>Perhaps the "If NAT-T is supported, ..." should be changed to "If
>NAT-T is supported (i.e. NAT_DETECTION_*_IP payloads were exchanged
>during IKE_SA_INIT), ...".

I like that wording. Scott, does that clear it up for you?

--Paul Hoffman, Director
--VPN Consortium

--=_alternative 0041BCA98525754A_=-- --===============0254662174== 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 --===============0254662174==-- From ipsec-bounces@ietf.org Mon Jan 26 05:37:50 2009 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 2BFA33A6BA5; Mon, 26 Jan 2009 05:37:50 -0800 (PST) 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 710C53A6A6A for ; Mon, 26 Jan 2009 05:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 qc6qW0UDQG7v for ; Mon, 26 Jan 2009 05:37:44 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 2B01F3A6A70 for ; Mon, 26 Jan 2009 05:37:44 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B543B29C004; Mon, 26 Jan 2009 15:37:25 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 34B2329C001; Mon, 26 Jan 2009 15:37:24 +0200 (IST) X-CheckPoint: {497DB9F2-10000-88241DC2-7B6} 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 n0QDbN5f021322; Mon, 26 Jan 2009 15:37:23 +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, 26 Jan 2009 15:37:23 +0200 From: Yaron Sheffer To: Paul Hoffman , "Tschofenig, Hannes (NSN - FI/Espoo)" , "ipsec@ietf.org" Date: Mon, 26 Jan 2009 15:37:19 +0200 Thread-Topic: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) Thread-Index: Acl/Nn88zQs3AihXRvajOyNqh/c9eQAg0nzw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63AD0E@il-ex01.ad.checkpoint.com> References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD41@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45F7FF42@FIESEXC015.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "kivinen@iki.fi" Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) 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 It seems to me we are splitting hairs here: what is the different between "hard expiry" and a hint? The protocol as it is today can handle the case when the gateway doesn't like the ticket it receives. And any reasonable client implementation will never send a stale ticket, regardless if this is "expiry" or a "hint". So the behavior is really the same. If we go for periodic checks, who decides what is a reasonable period? I think one periodic keep-alive per protocol (DPD) is sufficient. And why is it easier to maintain a periodic timer than a timer preset to the value received in the ticket? Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Sunday, January 25, 2009 23:47 > To: Tschofenig, Hannes (NSN - FI/Espoo); ipsec@ietf.org > Cc: kivinen@iki.fi > Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and > ticket push from gateway) > > At 11:31 PM +0200 1/25/09, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >The client would know how long the ticket is valid. It can therefore > >easily make an informed decision of when one of the tickets became > >invalid rather than probing the server. > > > >RFC 5077 follows a similar approach in the sense that the lifetime is > >communicated as a hint. > > True. Are you saying that you consider the lifetime in draft-ietf-ipsecme- > ikev2-resumption to be a hint, not a hard expiry? I did not get that > impression from the draft. > > >Am I missing the point here a bit? > > Possibly. My point (and I think Tero's point) is that having the two sides > need to keep watching the time is possibly more fragile than periodic > rechecks. On the other hand, if you are now saying that the lifetime is a > hint and not definitive, then the two sides don't really need to keep > track that closely. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > 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. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 26 05:47:59 2009 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 C48D528C181; Mon, 26 Jan 2009 05:47:59 -0800 (PST) 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 F19B828C1FB for ; Mon, 26 Jan 2009 05:47:57 -0800 (PST) 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 4uel3K7uyUyP for ; Mon, 26 Jan 2009 05:47:57 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C293128C181 for ; Mon, 26 Jan 2009 05:47:56 -0800 (PST) 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 n0QDla7C004545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 15:47:36 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0QDlZ4O029345; Mon, 26 Jan 2009 15:47:35 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18813.48887.81890.13253@fireball.kivinen.iki.fi> Date: Mon, 26 Jan 2009 15:47:35 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <18809.51499.928855.243725@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Resolution of some open issues 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: > One more comment -- the non-ESP marker is defined only for use on port > 4500. When data is received on port 500, implementations do not expect it > to be present. Yes, and I think this is well specified in the RFC (section 2.23 says that IKE header has four octects of zero prepended if IKE is run over port 4500). > Consequently, to avoid any ambiguity, we should probably take care > to stipulate here that if you unilaterally choose to float to port > 4500, even in the absence of a NAT, you MUST send to port 4500. The generic text says that you MUST reply back with port numbers reversed, so initial requests are processed correctly. The question is when the responder wants to initiate exchange himself. I think the current document is missing the text saying whether responder MUST use the port 4500 in such cases where there is no NAT (i.e. where initiator decides to float to port 4500 even when there is no NAT). I agree that such text should be added. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 26 06:13:17 2009 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 2BC8728C206; Mon, 26 Jan 2009 06:13:17 -0800 (PST) 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 512A428C206 for ; Mon, 26 Jan 2009 06:13:15 -0800 (PST) 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 oHX954psIrmR for ; Mon, 26 Jan 2009 06:13:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A23B13A69F4 for ; Mon, 26 Jan 2009 06:13:13 -0800 (PST) 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 n0QECsAn003358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 16:12:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0QECs6Z026485; Mon, 26 Jan 2009 16:12:54 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18813.50406.242743.604131@fireball.kivinen.iki.fi> Date: Mon, 26 Jan 2009 16:12:54 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD41@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45F7FF42@FIESEXC015.nsn-intra.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 20 min X-Total-Time: 19 min Cc: ipsec@ietf.org, "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) 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: > At 11:31 PM +0200 1/25/09, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >The client would know how long the ticket is valid. It can therefore > >easily make an informed decision of when one of the tickets became > >invalid rather than probing the server. > > > >RFC 5077 follows a similar approach in the sense that the lifetime is > >communicated as a hint. > > True. Are you saying that you consider the lifetime in > draft-ietf-ipsecme-ikev2-resumption to be a hint, not a hard expiry? > I did not get that impression from the draft. Same here, and I still do not understand why client would be sending the lifetime to the server when it is presenting the ticket. That does not make any sense as lifetime isn't expressed as absolute time. Also what does server does if the lifetime client gives when it presents ticket is different than what was sent before. Is that fatal error? Is that silently ignored? > >Am I missing the point here a bit? > > Possibly. My point (and I think Tero's point) is that having the two > sides need to keep watching the time is possibly more fragile than > periodic rechecks. On the other hand, if you are now saying that the > lifetime is a hint and not definitive, then the two sides don't > really need to keep track that closely. Another problem with lifetimes is that they do have explicit policy limits, meaning they will cause negotiations to fail. This happened a lot in the IKEv1 environment, and in the end it was always mandatory to make sure that both client and server used EXACTLY same lifetimes, as otherwise you most likely didn't interop. This will mean that if client is configured for minimal lifetime of ticket of 3600 seconds, and server offers ticket which have lifetime of 3599 seconds, client will fail the negotiation. On the other hand if we say that there MUST NOT be any policy limitation checks for the lifetimes, then there is no point of tell them really, as server can simply start new INFORMATIONAL exchange and send new N(TICKET_OPAQUE) when the previous one is about to expire. In general I do not really see that much need for expiring tickets ever as long as the IKE SA associated to it exists. The expiry only comes to the play when the IKE SA is removed, and should really be counted from that point forward. That of course offers a problem that there is no agreed upon time when the connection between server and client was lost. I.e. if we have IKE SA which is set up at and has been active for 5 days. There is no point of setting the ticket lifetime to something like 1 hour or so and get new tickets every hour during that 5 days. On the other hand when the IKE SA connection is broken, then it would be useful to start timer on the server. If it was just network problem then connection will come back quite quickly, thus 1 hour ticket lifetime is understandable. If client hasn't resumpted the connection during that 1 hour timeframe, then it either crashed, or someone digged up the network cable, and the situation will take so long to get fixed, that new IKE SA negotiation does not matter. If we mandate lifetime upkeeping to the protocol that will cause extra adminstrative work all the time, as both ends needs to keep track of lifetimes, and request new tickets (or just send them if needed). If the lifetimes are left to the local policy then server can do whatever it likes, and client always tries to resumption first if he has ticket (client usually only have very few tickets, so it really does not need to delete them to gain more resources). It seems I completely misunderstood the "Allowing a gateway to push state to clients." text. I read it as so that gateway can initiate ticket pushing operations, i.e. it can do following: Client Gateway ------- ---------- <-- HDR, SK {N(TICKET_OPAQUE)} HDR, SK {} --> I.e. the server can at any time push new ticket to the client, and client will replace previous ticket with this new one. Most likely server will always need to push new ticket every time IKE SA is rekeyed, as the keying material used to calculate the SK_d2, SK_ai, SK_ar, SK_ei, SK_er changes when SK_d changes, and rekeying IKE SA changes SK_d. On the other hand the draft does not say which SK_d is used after rekey. If you do rekey so you can forget the keying material used before the rekey, it would not be good to keep the old SK_d still after rekey, so I assume the SK_d should come from the current IKE SA, i.e. it is recreated after each rekey. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 26 06:35:07 2009 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 98F893A6BA3; Mon, 26 Jan 2009 06:35:07 -0800 (PST) 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 BC55D3A6BA3 for ; Mon, 26 Jan 2009 06:35:05 -0800 (PST) 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 CImq2Ypo+2k1 for ; Mon, 26 Jan 2009 06:35:04 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 856CD3A6A88 for ; Mon, 26 Jan 2009 06:35:04 -0800 (PST) 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 n0QEYMNP007360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 16:34:22 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0QEYMEw024980; Mon, 26 Jan 2009 16:34:22 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18813.51694.70577.795946@fireball.kivinen.iki.fi> Date: Mon, 26 Jan 2009 16:34:22 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130846AEF7@il-ex01.ad.checkpoint.com> References: <18809.51209.570727.898337@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846AEF7@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 11 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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 Yoav Nir writes: > > >Because of this I think it would be good to split the original #9 to > > >two cases, one that I do not think anybody disagrees is that failure > > >of CHILD SA creation should not tear down IKE SA. > > > > > >And the other is how is the fatal IKE SA creation errors sent back > > >(i.e. whether to encrypt them or not). > > > > I agree that we should be focusing on the second issue. However, I > > disagree with the idea that we should support unauthenticated encryption, > > even for this one error message. How do others feel? > > The IKE_AUTH exchange is encrypted but not authenticated. I don't > see any problem with sending an encrypted message after > authentication has failed. Actually there will be message authentication check done for that packet too, as we do have SK_a* keys already after we finished the diffie-hellman, and we already did verify the MAC of the incoming message (if that MAC check fails, implementation will most likely silently drop that packet without any messages sent back). The problem is that if we cannot verify the AUTH payload in the message, we are not sure that we are really talking to the peer we think we are talking, and that means we are really doing anonymous Diffie-Hellman. The packet format will be exactly same than normally, only thing is that as responder could not verify the AUTH payload, it does not know that the initiator really was who he claimed to be, and as it does not include AUTH payload at all, the initiator does not have any way to verify identity of the responder. On the other hand only entity who can send those error messages using the SK_e* and SK_a* generated by the Diffie-Hellman must be either the other end or the man-in-the-middle. If there was man-in-the-middle then the exchange will fail anyways, so no harm is done by trusting the man-in-the-middle claiming he was there... :-) So in the end I am myself more starting to think that the encrypted and mac'ed but not authenticated error message might be better. > OTOH I see plenty wrong with allowing IKE-SA-destroying messages in > the clear after IKE_AUTH has ended. We are now talking message coming back to the IKE_AUTH request, this means IKE_AUTH is not ended yet. > Sure you can get around this problem with liveness check and waiting > before believing the failure message, but requiring it to be > encrypted and protected foils such DoS attacks much more > effectively. You need to do that anyways, as there are errors where timeout is only option. Also old implementations might still send error messages in clear, or even skip them completely, so you still need to have code to cope with them. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 26 06:39:07 2009 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 18B8028C173; Mon, 26 Jan 2009 06:39:07 -0800 (PST) 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 D724E3A6A88 for ; Mon, 26 Jan 2009 06:39:05 -0800 (PST) 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 BqJugirP0cYm for ; Mon, 26 Jan 2009 06:39:05 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8F7433A6909 for ; Mon, 26 Jan 2009 06:39:03 -0800 (PST) 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 n0QEch8Q007370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 16:38:43 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0QEcgHn019187; Mon, 26 Jan 2009 16:38:42 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18813.51954.748038.750214@fireball.kivinen.iki.fi> Date: Mon, 26 Jan 2009 16:38:42 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63ACA6@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63A89D@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63ACA6@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: "ipsec@ietf.org" Subject: [IPsec] virtual interim meeting on Feb. 3 - additional details 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 Yaron Sheffer writes: > We are planning to use the TeamSpeak application for both voice > conferencing and IM. Paul has kindly set up a private server for our > use, and the full details are on the wiki: > http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls Also make sure the destination UDP port 8767 is open in your firewall for outgoing connections. If that port is blocked then the teamspeak does not work: http://www.teamspeak.com/?page=faq&cat=client&rate=41#client_ports Which ports does the client use? The TeamSpeak 2 client uses RANDOM ports from the whole 1024-65535 range for source port and sends to port 8767 (UDP) unless indicated otherwise. The client doesn't usually require any configuration of routers or firewalls. Do NOT setup your router to do port-forwarding or similar, as this is only needed when running the server. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 26 06:40:50 2009 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 BF31B28C219; Mon, 26 Jan 2009 06:40:50 -0800 (PST) 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 53AB328C208 for ; Mon, 26 Jan 2009 06:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.576 X-Spam-Level: X-Spam-Status: No, score=-5.576 tagged_above=-999 required=5 tests=[AWL=1.023, 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 iqZl5Dk5rEJK for ; Mon, 26 Jan 2009 06:40:48 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id B06783A6909 for ; Mon, 26 Jan 2009 06:40:47 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0QEeSTh007203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Jan 2009 15:40:28 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0QEeSf0013102; Mon, 26 Jan 2009 15:40:28 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jan 2009 15:40:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Jan 2009 16:41:09 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45F80700@FIESEXC015.nsn-intra.net> In-Reply-To: <18813.50406.242743.604131@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) Thread-Index: Acl/wDKMNRb9s7lkSA+5h1xd66JpEQAAZqGw References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD41@FIESEXC015.nsn-intra.net><3D3C75174CB95F42AD6BCC56E5555B45F7FF42@FIESEXC015.nsn-intra.net> <18813.50406.242743.604131@fireball.kivinen.iki.fi> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Tero Kivinen" , "Paul Hoffman" X-OriginalArrivalTime: 26 Jan 2009 14:40:27.0943 (UTC) FILETIME=[07E36370:01C97FC4] Cc: ipsec@ietf.org Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) 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 Tero, >Paul Hoffman writes: >> At 11:31 PM +0200 1/25/09, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> >The client would know how long the ticket is valid. It can >therefore >> >easily make an informed decision of when one of the tickets became >> >invalid rather than probing the server. >> > >> >RFC 5077 follows a similar approach in the sense that the >lifetime is >> >communicated as a hint. >> >> True. Are you saying that you consider the lifetime in >> draft-ietf-ipsecme-ikev2-resumption to be a hint, not a hard expiry? >> I did not get that impression from the draft. > >Same here, and I still do not understand why client would be >sending the lifetime to the server when it is presenting the >ticket. That does not make any sense as lifetime isn't >expressed as absolute time. We reused the same payload format for both directions. I added text that the lifetime in the C->S direction is set to the lifetime previously received. Alternatively, I could also introduce an additional payload format and exclude the lifetime. Do you prefer the latter? > >Also what does server does if the lifetime client gives when >it presents ticket is different than what was sent before. Is >that fatal error? Is that silently ignored? The draft says: " The four octet lifetime field contains the number of seconds until the ticket expires (encoded as an unsigned integer). " > >> >Am I missing the point here a bit? >> >> Possibly. My point (and I think Tero's point) is that having the two >> sides need to keep watching the time is possibly more fragile than >> periodic rechecks. On the other hand, if you are now saying that the >> lifetime is a hint and not definitive, then the two sides >don't really >> need to keep track that closely. > >Another problem with lifetimes is that they do have explicit >policy limits, meaning they will cause negotiations to fail. >This happened a lot in the IKEv1 environment, and in the end >it was always mandatory to make sure that both client and >server used EXACTLY same lifetimes, as otherwise you most >likely didn't interop. Not an issue here as absolute time isn't used. > >This will mean that if client is configured for minimal >lifetime of ticket of 3600 seconds, and server offers ticket >which have lifetime of 3599 seconds, client will fail the >negotiation. On the other hand if we say that there MUST NOT >be any policy limitation checks for the lifetimes, then there >is no point of tell them really, as server can simply start >new INFORMATIONAL exchange and send new N(TICKET_OPAQUE) when >the previous one is about to expire. We can certainly add text to the draft discussing such a case. If the client is not happy with what it gets then it can always start a full exchange. I don't see a problem with that. This is also a policy issue. In this specific case this is appropriate for the client todo. Sending a new message from the server to the client when the ticket is to expire is also possible and supported by the document. I do, however, agree that more text could/should be added. >In general I do not really see that much need for expiring >tickets ever as long as the IKE SA associated to it exists. >The expiry only comes to the play when the IKE SA is removed, >and should really be counted from that point forward. That of >course offers a problem that there is no agreed upon time when >the connection between server and client was lost. > >I.e. if we have IKE SA which is set up at and has been active >for 5 days. There is no point of setting the ticket lifetime >to something like 1 hour or so and get new tickets every hour >during that 5 days. >On the other hand when the IKE SA connection is broken, then >it would be useful to start timer on the server. If it was >just network problem then connection will come back quite >quickly, thus 1 hour ticket lifetime is understandable. If >client hasn't resumpted the connection during that 1 hour >timeframe, then it either crashed, or someone digged up the >network cable, and the situation will take so long to get >fixed, that new IKE SA negotiation does not matter. It would be good to always sent the client the ticket right before the connectivity fades away :-) Having tickets with a very short lifetime is probably not such a good idea. > >If we mandate lifetime upkeeping to the protocol that will >cause extra adminstrative work all the time, as both ends >needs to keep track of lifetimes, and request new tickets (or >just send them if needed). If the lifetimes are left to the >local policy then server can do whatever it likes, and client >always tries to resumption first if he has ticket (client >usually only have very few tickets, so it really does not need >to delete them to gain more resources). > >It seems I completely misunderstood the "Allowing a gateway to >push state to clients." text. I read it as so that gateway can >initiate ticket pushing operations, i.e. it can do following: > > Client Gateway > ------- ---------- > <-- HDR, SK {N(TICKET_OPAQUE)} > HDR, SK {} --> > >I.e. the server can at any time push new ticket to the client, >and client will replace previous ticket with this new one. >Most likely server will always need to push new ticket every >time IKE SA is rekeyed, as the keying material used to >calculate the SK_d2, SK_ai, SK_ar, SK_ei, SK_er changes when >SK_d changes, and rekeying IKE SA changes SK_d. The document does say that the ticket may be exchanged using an informational exchange but the specific requirement you mention is in my view not related to this aspect. Btw, I don't think requirements in a solution document are particularly useful. >On the other >hand the draft does not say which SK_d is used after rekey. If >you do rekey so you can forget the keying material used before >the rekey, it would not be good to keep the old SK_d still >after rekey, so I assume the SK_d should come from the current >IKE SA, i.e. it is recreated after each rekey. Making a new ticket available to the client after rekeying sounds useful to me. Ciao Hannes >-- >kivinen@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 26 06:47:11 2009 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 730A43A6909; Mon, 26 Jan 2009 06:47:11 -0800 (PST) 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 69AEE3A6909 for ; Mon, 26 Jan 2009 06:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 ubEkKnduwyqA for ; Mon, 26 Jan 2009 06:47:08 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 504B23A67EC for ; Mon, 26 Jan 2009 06:47:08 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2463A29C003; Mon, 26 Jan 2009 16:46:50 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 35FC129C001; Mon, 26 Jan 2009 16:46:49 +0200 (IST) X-CheckPoint: {497DCA37-10000-88241DC2-7B6} 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 n0QEkm5f010537; Mon, 26 Jan 2009 16:46:48 +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, 26 Jan 2009 16:46:48 +0200 From: Yoav Nir To: Tero Kivinen Date: Mon, 26 Jan 2009 16:46:50 +0200 Thread-Topic: [IPsec] Issue #9: Notification when creation of CHILD_SA fails Thread-Index: Acl/wz7t7dRGe1srTzS0hM2evb6M7QAAD1Sg Message-ID: <9FB7C7CE79B84449B52622B506C78036130846AF50@il-ex01.ad.checkpoint.com> References: <18809.51209.570727.898337@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846AEF7@il-ex01.ad.checkpoint.com> <18813.51694.70577.795946@fireball.kivinen.iki.fi> In-Reply-To: <18813.51694.70577.795946@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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: > Yoav Nir writes: > > > >Because of this I think it would be good to split the original #9 to > > > >two cases, one that I do not think anybody disagrees is that failure > > > >of CHILD SA creation should not tear down IKE SA. > > > > > > > >And the other is how is the fatal IKE SA creation errors sent back > > > >(i.e. whether to encrypt them or not). > > > > > > I agree that we should be focusing on the second issue. However, I > > > disagree with the idea that we should support unauthenticated > encryption, > > > even for this one error message. How do others feel? > > > > The IKE_AUTH exchange is encrypted but not authenticated. I don't > > see any problem with sending an encrypted message after > > authentication has failed. > > Actually there will be message authentication check done for that > packet too, as we do have SK_a* keys already after we finished the > diffie-hellman, and we already did verify the MAC of the incoming > message (if that MAC check fails, implementation will most likely > silently drop that packet without any messages sent back). What I meant was that we are willing to do the IKE_AUTH exchange when the peer is not authenticated, so doing the same for the error message should not matter. > > OTOH I see plenty wrong with allowing IKE-SA-destroying messages in > > the clear after IKE_AUTH has ended. > > We are now talking message coming back to the IKE_AUTH request, this > means IKE_AUTH is not ended yet. We are talking about two cases: one is when the responder failed to authenticate the initiator, the other is when the responder authenticated the initiator, but the initiator hasn't authenticated the responder. In the latter case, the responder thinks the IKE SA succeeded, while the initiator knows it hasn't. IMO the error message should be encrypted and MAC'ed (*not* authenticated!) in both cases. > > Sure you can get around this problem with liveness check and waiting > > before believing the failure message, but requiring it to be > > encrypted and protected foils such DoS attacks much more > > effectively. > > You need to do that anyways, as there are errors where timeout is only > option. Also old implementations might still send error messages in > clear, or even skip them completely, so you still need to have code to > cope with them. Yes, you have to have the code, but if the message is encrypted and MAC'ed you can delete the IKE SA (and log/display a message) immediately. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 26 06:48:52 2009 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 869D13A6BB1; Mon, 26 Jan 2009 06:48:52 -0800 (PST) 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 048B43A6BBA for ; Mon, 26 Jan 2009 06:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=-0.989, 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 EbwrFdlnv9ZC for ; Mon, 26 Jan 2009 06:48:51 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id B5FDC3A6974 for ; Mon, 26 Jan 2009 06:48:50 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n0QEmRRd011285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Jan 2009 15:48:27 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n0QEmRpI001167; Mon, 26 Jan 2009 15:48:27 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jan 2009 15:48:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Jan 2009 16:49:09 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45F80715@FIESEXC015.nsn-intra.net> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63AD0E@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) Thread-Index: Acl/Nn88zQs3AihXRvajOyNqh/c9eQAg0nzwAAKbpaA= References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD41@FIESEXC015.nsn-intra.net><3D3C75174CB95F42AD6BCC56E5555B45F7FF42@FIESEXC015.nsn-intra.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63AD0E@il-ex01.ad.checkpoint.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Yaron Sheffer" , "Paul Hoffman" , X-OriginalArrivalTime: 26 Jan 2009 14:48:27.0447 (UTC) FILETIME=[25B1E470:01C97FC5] Cc: kivinen@iki.fi Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) 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 believe that the "hard expiry" vs. the hint comes from RFC 5077. There the text says from Section 5.6 of RFC 5077: " 5.6. Ticket Lifetime The TLS server controls the lifetime of the ticket. Servers determine the acceptable lifetime based on the operational and security requirements of the environments in which they are deployed. The ticket lifetime may be longer than the 24-hour lifetime recommended in [RFC4346]. TLS clients may be given a hint of the lifetime of the ticket. Since the lifetime of a ticket may be unspecified, a client has its own local policy that determines when it discards tickets. " The lifetime field in http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption- 01.txt is mandatory and we don't indicate that it may be set to specific value to indicate it is not further specified. So, Tero, Paul and group: What behavior would you prefer? Ciao Hannes >-----Original Message----- >From: ext Yaron Sheffer [mailto:yaronf@checkpoint.com] >Sent: 26 January, 2009 15:37 >To: Paul Hoffman; Tschofenig, Hannes (NSN - FI/Espoo); ipsec@ietf.org >Cc: kivinen@iki.fi >Subject: RE: [IPsec] Ticket #70: Ticket lifetime - explicit or >not? (and ticket push from gateway) > >It seems to me we are splitting hairs here: what is the >different between "hard expiry" and a hint? The protocol as it >is today can handle the case when the gateway doesn't like the >ticket it receives. And any reasonable client implementation >will never send a stale ticket, regardless if this is "expiry" >or a "hint". So the behavior is really the same. > >If we go for periodic checks, who decides what is a reasonable >period? I think one periodic keep-alive per protocol (DPD) is >sufficient. And why is it easier to maintain a periodic timer >than a timer preset to the value received in the ticket? > >Thanks, > Yaron > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >On Behalf >> Of Paul Hoffman >> Sent: Sunday, January 25, 2009 23:47 >> To: Tschofenig, Hannes (NSN - FI/Espoo); ipsec@ietf.org >> Cc: kivinen@iki.fi >> Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? >> (and ticket push from gateway) >> >> At 11:31 PM +0200 1/25/09, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> >The client would know how long the ticket is valid. It can >therefore >> >easily make an informed decision of when one of the tickets became >> >invalid rather than probing the server. >> > >> >RFC 5077 follows a similar approach in the sense that the >lifetime is >> >communicated as a hint. >> >> True. Are you saying that you consider the lifetime in >> draft-ietf-ipsecme- ikev2-resumption to be a hint, not a >hard expiry? >> I did not get that impression from the draft. >> >> >Am I missing the point here a bit? >> >> Possibly. My point (and I think Tero's point) is that having the two >> sides need to keep watching the time is possibly more fragile than >> periodic rechecks. On the other hand, if you are now saying that the >> lifetime is a hint and not definitive, then the two sides >don't really >> need to keep track that closely. >> >> --Paul Hoffman, Director >> --VPN Consortium >> _______________________________________________ >> 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. > >Email secured by Check Point > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 26 07:04:25 2009 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 1CC7D3A6A84; Mon, 26 Jan 2009 07:04:25 -0800 (PST) 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 2D9063A6A84; Mon, 26 Jan 2009 07:04:24 -0800 (PST) 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 YCCJzTTq8GnN; Mon, 26 Jan 2009 07:04:23 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 27BCF3A6A07; Mon, 26 Jan 2009 07:04:23 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0QF4S1J009884; Mon, 26 Jan 2009 10:04:28 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0QF447V173788; Mon, 26 Jan 2009 10:04:04 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0QF4440003054; Mon, 26 Jan 2009 10:04:04 -0500 Received: from d01mc084.pok.ibm.com (d01mc084.pok.ibm.com [9.63.9.226]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0QF4430003035; Mon, 26 Jan 2009 10:04:04 -0500 In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130846AEF7@il-ex01.ad.checkpoint.com> To: Yoav Nir X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Mon, 26 Jan 2009 10:04:03 -0500 X-MIMETrack: Serialize by Router on D01MC084/01/M/IBM(Release 8.0.1|February 07, 2008) at 01/26/2009 10:04:04 MIME-Version: 1.0 Cc: IPsecme WG , ipsec-bounces@ietf.org, Paul Hoffman , Tero Kivinen Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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="===============1701828106==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1701828106== Content-type: multipart/alternative; Boundary="0__=0ABBFFD9DFC125A58f9e8a93df938690918c0ABBFFD9DFC125A5" Content-Disposition: inline --0__=0ABBFFD9DFC125A58f9e8a93df938690918c0ABBFFD9DFC125A5 Content-type: text/plain; charset=US-ASCII >>>Because of this I think it would be good to split the original #9 to >>>two cases, one that I do not think anybody disagrees is that failure >>>of CHILD SA creation should not tear down IKE SA. >>> >>>And the other is how is the fatal IKE SA creation errors sent back >>>(i.e. whether to encrypt them or not). >>> >>I agree that we should be focusing on the second issue. However, I >>disagree with the idea that we should support unauthenticated encryption, >>even for this one error message. How do others feel? >> >The IKE_AUTH exchange is encrypted but not authenticated. I don't see any, >problem with sending an encrypted message after authentication has failed. > >OTOH I see plenty wrong with allowing IKE-SA-destroying messages in the >clear after IKE_AUTH has ended. > >Sure you can get around this problem with liveness check and waiting >before believing the failure message, but requiring it to be encrypted >and protected foils such DoS attacks much more effectively. I agree. Sending an unauthenticated but encrypted message allows the SA to be disposed of in a more timely fashion. I see nothing wrong with sending an unauthenticated encrypted response if the IKE AUTH exchange fails due to an authentication error on the responder side. If the authentication error occurred on the initiator side I would expect the initiator to initiate an encrypted info exchange to delete the IKE SA. Dave Wierbowski z/OS Comm Server Developer Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 --0__=0ABBFFD9DFC125A58f9e8a93df938690918c0ABBFFD9DFC125A5 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

>>>Because of this I think it would be good to split the original #9 to
>>>two cases, one that I do not think anybody disagrees is that failure
>>>of CHILD SA creation should not tear down IKE SA.
>>>
>>>And the other is how is the fatal IKE SA creation errors sent back
>>>(i.e. whether to encrypt them or not).
>>
>>I agree that we should be focusing on the second issue. However, I
>>disagree with the idea that we should support unauthenticated encryption,
>>even for this one error message. How do others feel?
>
>The IKE_AUTH exchange is encrypted but not authenticated. I don't see any
>problem with sending an encrypted message after authentication has failed.
>
>OTOH I see plenty wrong with allowing IKE-SA-destroying messages in the
>clear after IKE_AUTH has ended.
>
>Sure you can get around this problem with liveness check and waiting
>before believing the failure message, but requiring it to be encrypted
>and protected foils such DoS attacks much more effectively.

I agree. Sending an unauthenticated but encrypted message allows the SA
to be disposed of in a more timely fashion.

I see nothing wrong with sending an unauthenticated encrypted response if the IKE AUTH
exchange fails due to an authentication error on the responder side.

If the authentication error occurred on the initiator side I would expect the initiator to
initiate an encrypted info exchange to delete the IKE SA.

Dave Wierbowski


z/OS Comm Server Developer

Dave Wierbowski


z/OS Comm Server Developer

Phone:
Tie line: 620-4055
External: 607-429-4055


--0__=0ABBFFD9DFC125A58f9e8a93df938690918c0ABBFFD9DFC125A5-- --===============1701828106== 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 --===============1701828106==-- From ipsec-bounces@ietf.org Mon Jan 26 09:14:55 2009 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 0ACB628C248; Mon, 26 Jan 2009 09:14:55 -0800 (PST) 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 2C52828C248 for ; Mon, 26 Jan 2009 09:14:54 -0800 (PST) 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 u3gB7mRRGUz1 for ; Mon, 26 Jan 2009 09:14:53 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 8E7D428C13B for ; Mon, 26 Jan 2009 09:14:52 -0800 (PST) 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 n0QHESF4025880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 19:14:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0QHEQml000538; Mon, 26 Jan 2009 19:14:26 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18813.61298.384022.41032@fireball.kivinen.iki.fi> Date: Mon, 26 Jan 2009 19:14:26 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130846AF50@il-ex01.ad.checkpoint.com> References: <18809.51209.570727.898337@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846AEF7@il-ex01.ad.checkpoint.com> <18813.51694.70577.795946@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846AF50@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 10 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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 Yoav Nir writes: > We are talking about two cases: one is when the responder failed to > authenticate the initiator, the other is when the responder > authenticated the initiator, but the initiator hasn't authenticated > the responder. In the latter case, the responder thinks the IKE SA > succeeded, while the initiator knows it hasn't. I was only talking the case where the responder failed to authenticate the initiator and send error message back, i.e: (1) Initiator Responder ----------- ----------- HDR(IKE_SA_INIT), SAi1, KEi, Ni --> <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ] HDR(IKE_AUTH), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR(IKE_AUTH), SK {N(AUTHENTICATION_FAILED)} The question is whether the N(AUTHENTICATION_FAILED) is encrypted (i.e. inside SK {}), or just sent as plain text reply or whether it is just not set at all. I do not think there is anything in the document that says the initiator could or could not send N(AUTHENTICATION_FAILED) error message after the exchange, i.e. your second case would be: (2) Initiator Responder ----------- ----------- HDR(IKE_SA_INIT), SAi1, KEi, Ni --> <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ] HDR(IKE_AUTH), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR(IKE_AUTH), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} HDR(INFORMATIONAL), SK {N(AUTHENTICATION_FAILED)} --> <-- HDR(INFORMATIONAL), SK {} At least our implementations do consider AUTHENTICATION_FAILED error as fatal error to IKE SA, so sending it as INFORMATIONAL exchange after will also work and it does cause IKE SA to be deleted. The question is whether following be accepted: (3) Initiator Responder ----------- ----------- HDR(IKE_SA_INIT), SAi1, KEi, Ni --> <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, [CERTREQ] HDR(IKE_AUTH), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR(IKE_AUTH), N(AUTHENTICATION_FAILED) I.e. where the N(AUTHENTICATION_FAILED) is not encrypted in the reply from responder. It is clear it MUST NOT be accepted in the (2) case, i.e. the last INFORMATINAL request having N(AUTHENTICATION_FAILED) notify must be encrypted, as responder belives the IKE SA is up and working, thus it will throw away all messages which come without encryption and MAC. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jan 26 10:57:04 2009 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 ACAD828C27B; Mon, 26 Jan 2009 10:57:04 -0800 (PST) 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 7085728C290 for ; Mon, 26 Jan 2009 10:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 I54idRHtHxC4 for ; Mon, 26 Jan 2009 10:57:02 -0800 (PST) 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 7E9D628C27B for ; Mon, 26 Jan 2009 10:57:01 -0800 (PST) Received: from [10.20.30.158] (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 n0QIuaLX030212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jan 2009 11:56:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45F80715@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD41@FIESEXC015.nsn-intra.net><3D3C75174CB95F42AD6BCC56E5555B45F7FF42@FI ESEXC015.nsn-intra.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63AD0E@il-ex01.ad.checkpoint.com> <3D3C75174CB95F42AD6BCC56E5555B45F80715@FIESEXC015.nsn-intra.net> Date: Mon, 26 Jan 2009 10:56:34 -0800 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Yaron Sheffer" , From: Paul Hoffman Cc: kivinen@iki.fi Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) 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:49 PM +0200 1/26/09, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >I believe that the "hard expiry" vs. the hint comes from RFC 5077. ...which is not part of this document. >There the text says from Section 5.6 of RFC 5077: > >" >5.6. Ticket Lifetime > > The TLS server controls the lifetime of the ticket. Servers > determine the acceptable lifetime based on the operational and > security requirements of the environments in which they are deployed. > The ticket lifetime may be longer than the 24-hour lifetime > recommended in [RFC4346]. TLS clients may be given a hint of the > lifetime of the ticket. Since the lifetime of a ticket may be > unspecified, a client has its own local policy that determines when > it discards tickets. >" > >The lifetime field in >http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption- >01.txt is mandatory and we don't indicate that it may be set to specific >value to indicate it is not further specified. > >So, Tero, Paul and group: What behavior would you prefer? If you believe that that the lifetime really is advisory, say that explicitly in the document, and take it out of the negotiations where it can break interoperability. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From jgutierrezh@amag.edu.pe Mon Jan 26 11:32:04 2009 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 65AC53A6B96 for ; Mon, 26 Jan 2009 11:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.55 X-Spam-Level: X-Spam-Status: No, score=-12.55 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvLf4MxBD7vb for ; Mon, 26 Jan 2009 11:32:02 -0800 (PST) Received: from amtote.com (unknown [189.60.72.244]) by core3.amsl.com (Postfix) with SMTP id 0990D3A690E for ; Mon, 26 Jan 2009 11:30:55 -0800 (PST) To: Subject: You've received an answer to your question From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090126193058.0990D3A690E@core3.amsl.com> Date: Mon, 26 Jan 2009 11:30:55 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.strengthreach.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://strengthreach.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 8, B759. 510 Clements Road. London. SE09 9DG

© 2006-2008 BBCMEDIA, Ltd. All Rights Reserved

From kontoskd@aget.gr Mon Jan 26 14:18:47 2009 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 A055E3A6AFB for ; Mon, 26 Jan 2009 14:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.707 X-Spam-Level: X-Spam-Status: No, score=-11.707 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, GB_I_LETTER=-2, HELO_MISMATCH_NET=0.611, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgC7EEFEqNLf for ; Mon, 26 Jan 2009 14:18:46 -0800 (PST) Received: from afo.net (187-26-134-93.3g.claro.net.br [187.26.134.93]) by core3.amsl.com (Postfix) with SMTP id E234D3A6A53 for ; Mon, 26 Jan 2009 14:18:43 -0800 (PST) To: Subject: Payment Accepted! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090126221844.E234D3A6A53@core3.amsl.com> Date: Mon, 26 Jan 2009 14:18:43 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.meetgarden.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://meetgarden.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 0, B537. 245 Clements Road. London. SE14 0DG

© 2006-2008 BBCMEDIA, Ltd. All Rights Reserved

From ipsec-bounces@ietf.org Mon Jan 26 22:02:48 2009 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 1A04C3A69FB; Mon, 26 Jan 2009 22:02:48 -0800 (PST) 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 4A6553A6AD6 for ; Mon, 26 Jan 2009 22:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 qP6+uJfoRaAW for ; Mon, 26 Jan 2009 22:02:45 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0B0263A69AC for ; Mon, 26 Jan 2009 22:02:44 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7161F29C005; Tue, 27 Jan 2009 08:02:26 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C29FA29C004; Tue, 27 Jan 2009 08:02:24 +0200 (IST) X-CheckPoint: {497EA0C9-10000-88241DC2-7B6} 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 n0R62O5f009115; Tue, 27 Jan 2009 08:02: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, 27 Jan 2009 08:02:23 +0200 From: Yoav Nir To: Tero Kivinen Date: Tue, 27 Jan 2009 08:02:28 +0200 Thread-Topic: [IPsec] Issue #9: Notification when creation of CHILD_SA fails Thread-Index: Acl/2Y9jkl0wW+k2Qs+wwOp7fVpKuwAaunaA Message-ID: <9FB7C7CE79B84449B52622B506C78036130846AFB2@il-ex01.ad.checkpoint.com> References: <18809.51209.570727.898337@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846AEF7@il-ex01.ad.checkpoint.com> <18813.51694.70577.795946@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846AF50@il-ex01.ad.checkpoint.com> <18813.61298.384022.41032@fireball.kivinen.iki.fi> In-Reply-To: <18813.61298.384022.41032@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Issue #9: Notification when creation of CHILD_SA fails 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: > Yoav Nir writes: > > We are talking about two cases: one is when the responder failed to > > authenticate the initiator, the other is when the responder > > authenticated the initiator, but the initiator hasn't authenticated > > the responder. In the latter case, the responder thinks the IKE SA > > succeeded, while the initiator knows it hasn't. > > I was only talking the case where the responder failed to authenticate > the initiator and send error message back, i.e: > > (1) > Initiator Responder > ----------- ----------- > HDR(IKE_SA_INIT), SAi1, KEi, Ni --> > <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, > [CERTREQ] > > HDR(IKE_AUTH), SK {IDi, [CERT,] [CERTREQ,] [IDr,] > AUTH, SAi2, TSi, TSr} --> > <-- HDR(IKE_AUTH), SK > {N(AUTHENTICATION_FAILED)} > > The question is whether the N(AUTHENTICATION_FAILED) is encrypted > (i.e. inside SK {}), or just sent as plain text reply or whether it is > just not set at all. > > I do not think there is anything in the document that says the > initiator could or could not send N(AUTHENTICATION_FAILED) error > message after the exchange, i.e. your second case would be: > > (2) > Initiator Responder > ----------- ----------- > HDR(IKE_SA_INIT), SAi1, KEi, Ni --> > <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, > [CERTREQ] > > HDR(IKE_AUTH), SK {IDi, [CERT,] [CERTREQ,] [IDr,] > AUTH, SAi2, TSi, TSr} --> > <-- HDR(IKE_AUTH), SK {IDr, [CERT,] > AUTH, > SAr2, TSi, TSr} > > HDR(INFORMATIONAL), SK {N(AUTHENTICATION_FAILED)} --> > <-- HDR(INFORMATIONAL), SK {} > > At least our implementations do consider AUTHENTICATION_FAILED error > as fatal error to IKE SA, so sending it as INFORMATIONAL exchange > after will also work and it does cause IKE SA to be deleted. > > The question is whether following be accepted: > > (3) > Initiator Responder > ----------- ----------- > HDR(IKE_SA_INIT), SAi1, KEi, Ni --> > <-- HDR(IKE_SA_INIT), SAr1, KEr, Nr, > [CERTREQ] > > HDR(IKE_AUTH), SK {IDi, [CERT,] [CERTREQ,] [IDr,] > AUTH, SAi2, TSi, TSr} --> > <-- HDR(IKE_AUTH), N(AUTHENTICATION_FAILED) > > I.e. where the N(AUTHENTICATION_FAILED) is not encrypted in the reply > from responder. > > It is clear it MUST NOT be accepted in the (2) case, i.e. the last > INFORMATINAL request having N(AUTHENTICATION_FAILED) notify must be > encrypted, as responder belives the IKE SA is up and working, thus it > will throw away all messages which come without encryption and MAC. I think the (1) and (2) case are similar enough and an un-MAC'ed AUTHENTICATION_FAILED should be rejected in both cases. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From jurgen@adam.com Tue Jan 27 03:56:30 2009 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 34D983A682C for ; Tue, 27 Jan 2009 03:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.382 X-Spam-Level: X-Spam-Status: No, score=-22.382 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_EQ_FR=0.35, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wSd35CBi2uV for ; Tue, 27 Jan 2009 03:56:26 -0800 (PST) Received: from alexandrie.fr (unknown [189.30.242.29]) by core3.amsl.com (Postfix) with SMTP id D2CE93A6A8B for ; Tue, 27 Jan 2009 03:55:56 -0800 (PST) To: Subject: Payment Accepted! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090127115557.D2CE93A6A8B@core3.amsl.com> Date: Tue, 27 Jan 2009 03:55:56 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.clotheingenuity.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://clotheingenuity.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 9, B470. 791 Clements Road. London. SE43 5DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

From ipsec-bounces@ietf.org Tue Jan 27 07:29:16 2009 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 5E2BC3A681F; Tue, 27 Jan 2009 07:29:16 -0800 (PST) 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 6AF2D3A688D for ; Tue, 27 Jan 2009 07:29:15 -0800 (PST) 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 dTOKrUFB8cdq for ; Tue, 27 Jan 2009 07:29:14 -0800 (PST) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 6B72D3A6781 for ; Tue, 27 Jan 2009 07:29:14 -0800 (PST) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0RFR72e000582 for ; Tue, 27 Jan 2009 10:27:07 -0500 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0RFSndn975076 for ; Tue, 27 Jan 2009 10:28:49 -0500 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n0RFSj8g008958 for ; Tue, 27 Jan 2009 08:28:45 -0700 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av05.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n0RFSjHa008950 for ; Tue, 27 Jan 2009 08:28:45 -0700 To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Christopher Meyer Message-ID: Date: Tue, 27 Jan 2009 10:28:44 -0500 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 8.5|December 05, 2008) at 01/27/2009 08:28:45, Serialize complete at 01/27/2009 08:28:45 Subject: [IPsec] Question on RFC 4109 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="===============1176047843==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1176047843== Content-Type: multipart/alternative; boundary="=_alternative 0054AD918525754B_=" This is a multipart message in MIME format. --=_alternative 0054AD918525754B_= Content-Type: text/plain; charset="US-ASCII" I have a question about RFC 4109. In section 3, it says that "AES-128 in XCBC mode for PRF functions ([RFC3566] and [RFC3664]) SHOULD be supported." However, it's not clear to me how to accomplish this with IKEv1 since the PRF is implied by the authentication algorithm and AES-XCBC-MAC-96 is not included in this section of the RFC (although it is listed in section 4 as described below). Also, section 4 (the summary section) says that "AES-XCBC-MAC-96 for PRF" SHOULD be supported, but I don't see it listed anywhere else in this RFC. This is also strange because AES-XCBC-MAC-96 is an authentication algorithm - not a PRF. Furthermore, AES-XCBC-PRF-128 is NOT listed in this section at all. Can someone please clarify the SHOULD for AES-XCBC based algorithms for IKEv1? Was the intent to list both AES-XCBC-MAC-96 and AES-XCBC-PRF-128 as SHOULDs and then have the MAC algorithm imply this PRF? If not, how is the AES-XCBC-PRF-128 algorithm supposed to be specified during negotiation? Thanks, Chris Meyer IBM z/OS Communications Server --=_alternative 0054AD918525754B_= Content-Type: text/html; charset="US-ASCII"
I have a question about RFC 4109.  In section 3, it says that

 "AES-128 in XCBC mode for PRF functions ([RFC3566] and [RFC3664]) SHOULD be supported."  

However, it's not clear to me how to accomplish this with IKEv1 since the PRF is implied by the authentication algorithm and AES-XCBC-MAC-96 is not included in this section of the RFC (although it is listed in section 4 as described below).      

Also, section 4  (the summary section) says that "AES-XCBC-MAC-96 for PRF" SHOULD be supported, but I don't see it listed anywhere else in this RFC.   This is also strange because AES-XCBC-MAC-96 is an authentication algorithm - not a PRF.    Furthermore, AES-XCBC-PRF-128 is NOT listed in this section at all.    

Can someone please clarify the SHOULD for AES-XCBC based algorithms for IKEv1?    Was the intent to list both AES-XCBC-MAC-96 and AES-XCBC-PRF-128 as SHOULDs and then have the MAC algorithm imply this PRF?   If not, how is the AES-XCBC-PRF-128 algorithm supposed to be specified during negotiation?

Thanks,

Chris Meyer

IBM z/OS Communications Server --=_alternative 0054AD918525754B_=-- --===============1176047843== 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 --===============1176047843==-- From jebleyp@aacps.org Tue Jan 27 09:44:40 2009 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 794CE3A6B47 for ; Tue, 27 Jan 2009 09:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -33.711 X-Spam-Level: X-Spam-Status: No, score=-33.711 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_VERIZON_P=2.144, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HELO_EQ_VERIZON_POOL=1.495, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 r3W3nTVRkre0 for ; Tue, 27 Jan 2009 09:44:39 -0800 (PST) Received: from pool-72-69-248-6.chi01.dsl-w.verizon.net (pool-72-69-248-6.chi01.dsl-w.verizon.net [72.69.248.6]) by core3.amsl.com (Postfix) with SMTP id 130DD3A68F3 for ; Tue, 27 Jan 2009 09:44:37 -0800 (PST) To: Subject: Payment Accepted! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090127174438.130DD3A68F3@core3.amsl.com> Date: Tue, 27 Jan 2009 09:44:37 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.ageeven.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://ageeven.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 1, B147. 055 Clements Road. London. SE11 5DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

From majordomo@absitalia.net Tue Jan 27 12:32:50 2009 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 A3F8628C128 for ; Tue, 27 Jan 2009 12:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.29 X-Spam-Level: X-Spam-Status: No, score=-11.29 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSt+RsNCmL1M for ; Tue, 27 Jan 2009 12:32:48 -0800 (PST) Received: from host-738.ibselektronics.pl (host-738.ibselektronics.pl [81.15.142.226]) by core3.amsl.com (Postfix) with SMTP id 391A23A6942 for ; Tue, 27 Jan 2009 12:32:44 -0800 (PST) To: Subject: January 71% OFF From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090127203246.391A23A6942@core3.amsl.com> Date: Tue, 27 Jan 2009 12:32:44 -0800 (PST)
Tell a friend · Download latest version See this email as a webpage

Hello ipsec-archive

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

© 2003-2009 SASI Limited. SASi Communications S.a.r.l., 22/24 Green St, Amsterdam L0541.

SASi, SASiIn, SASiOut, SASicasts, SASi Certified, SASiMe!, SASi Pro, SASiFind, SASi Prime, SASi To Go, associated logos and the ‘S’-symbol are trademarks of SASi Limited.
From ipsec-bounces@ietf.org Tue Jan 27 14:50:08 2009 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 BDC083A6B7B; Tue, 27 Jan 2009 14:50:08 -0800 (PST) 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 1DB6F3A6B58 for ; Tue, 27 Jan 2009 14:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 8wlVNMvawJsP for ; Tue, 27 Jan 2009 14:50:07 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3CAFB3A6B2C for ; Tue, 27 Jan 2009 14:50:07 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6068629C004; Wed, 28 Jan 2009 00:49:48 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7155229C002 for ; Wed, 28 Jan 2009 00:49:47 +0200 (IST) X-CheckPoint: {497F8CDD-10000-88241DC2-7B6} 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 n0RMnk5f000490 for ; Wed, 28 Jan 2009 00:49:47 +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, 28 Jan 2009 00:49:46 +0200 From: Yaron Sheffer To: IPsecme WG Date: Wed, 28 Jan 2009 00:49:45 +0200 Thread-Topic: IKEv2-bis issues - another batch Thread-Index: AclYZEMDrT/XCYkmRyeeyK8fmyJ2+AoZiVzg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C2@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950174@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950174@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 Subject: [IPsec] IKEv2-bis issues - another batch 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 everyone, We did rather well on the last set of issues, so here's the next one. Let's start the discussion on the list, and then have a go at the bigger issues during the conf call next week. This time around we haven't had any WG discussion of most issues, so silence doesn't count as anything. If you are in favor of, or against any particular change, please raise your voice. Thanks, Yaron Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jan 27 14:50:10 2009 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 26D1A3A6B84; Tue, 27 Jan 2009 14:50:10 -0800 (PST) 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 722FD3A6B84 for ; Tue, 27 Jan 2009 14:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 BDswcQA6BEYg for ; Tue, 27 Jan 2009 14:50:08 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 30F223A6B2C for ; Tue, 27 Jan 2009 14:50:08 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 100CF29C007; Wed, 28 Jan 2009 00:49:50 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6DC1E29C005 for ; Wed, 28 Jan 2009 00:49:48 +0200 (IST) X-CheckPoint: {497F8CDE-10000-88241DC2-7B6} 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 n0RMnl5f000496 for ; Wed, 28 Jan 2009 00:49:48 +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, 28 Jan 2009 00:49:47 +0200 From: Yaron Sheffer To: IPsecme WG Date: Wed, 28 Jan 2009 00:49:46 +0200 Thread-Topic: Bis issue #11: Clarify which traffic selectors to use in rekeying Thread-Index: AcmAzRc2mcYmmDBBSqS1KgnLSyrNWw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3@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 Subject: [IPsec] Bis issue #11: Clarify which traffic selectors to use in 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: multipart/mixed; boundary="===============1681290214==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1681290214== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3ilex01adcheck_" --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Existing text (sec. 1.3.1) The CREATE_CHILD_SA response for creating a new Child SA is: <-- HDR, SK {SA, Nr, [KEr], TSi, TSr} The responder replies (using the same Message ID to respond) with the accep= ted offer in an SA payload, and a Diffie-Hellman value in the KEr payload i= f KEi was included in the request and the selected cryptographic suite incl= udes that group. The traffic selectors for traffic to be sent on that SA are specified in th= e TS payloads in the response, which may be a subset of what the initiator = of the Child SA proposed. Tero: Add comment about which traffic selectors to use in the rekeying: When doing rekeying the traffic selectors SHOULD come from the original dec= orrelated policy, i.e. not the same traffic selectors which the old SA had = in case the responder narrowed them, but from the policy which initiator us= ed originally to create the IPsec SA. This allows the SA to expand to full = traffic selector set allowed by latest (perhaps changed) policy. Paul: Not done. This is interesting, but should be discussed on the list. =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Existing text (sec. 1.3.1)

The CREATE_CHILD_SA response for creating a new Child SA is:<= /font>

            &n= bsp;            = ;       <--  HDR, <= st1:State w:st=3D"on">SK {SA, Nr, [KEr],

            &n= bsp;            = ;            &n= bsp;   TSi, TSr}

The responder replies (using the same Message ID to respond) with the accepted offer in an SA payload, and a Diffie-Hellman value in the KEr payload if KE= i was included in the request and the selected cryptographic suite includes t= hat group.

The traffic selectors for traffic to be sent on that SA are specified in the TS payloads in the response, which may be a subset of what the initiator of th= e Child SA proposed.

Tero:

Add comment about which traffic selectors to use in the rekeying:

When doing rekeying the traffic selectors SHOULD come from the original decorrel= ated policy, i.e. not the same traffic selectors which the old SA had in case th= e responder narrowed them, but from the policy which initiator used originall= y to create the IPsec SA. This allows the SA to expand to full traffic selector = set allowed by latest (perhaps changed) policy.

Paul:

Not done. This is interesting, but should be discussed on the list.


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3ilex01adcheck_-- --===============1681290214== 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 --===============1681290214==-- From ipsec-bounces@ietf.org Tue Jan 27 14:50:15 2009 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 933C33A6B8E; Tue, 27 Jan 2009 14:50:15 -0800 (PST) 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 19A653A6B94 for ; Tue, 27 Jan 2009 14:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 TfvoADLoPX0h for ; Tue, 27 Jan 2009 14:50:09 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 2A9863A6B83 for ; Tue, 27 Jan 2009 14:50:09 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0138029C008; Wed, 28 Jan 2009 00:49:50 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B766429C002 for ; Wed, 28 Jan 2009 00:49:48 +0200 (IST) X-CheckPoint: {497F8CDF-10000-88241DC2-7B6} 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 n0RMnl5g000496 for ; Wed, 28 Jan 2009 00:49:48 +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, 28 Jan 2009 00:49:47 +0200 From: Yaron Sheffer To: IPsecme WG Date: Wed, 28 Jan 2009 00:49:47 +0200 Thread-Topic: Bis issue #14: Bounding the retransmit time Thread-Index: AcmAzcIBxkaPjM7vSp6FcaJolJCsIQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C4@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 Subject: [IPsec] Bis issue #14: Bounding the retransmit time 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="===============0585109993==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0585109993== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C4ilex01adcheck_" --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C4ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 2.1. Use of Retransmission Timers ... For every pair of IKE messages, the initiator is responsible for retransmis= sion in the event of a timeout. The responder MUST never retransmit a respo= nse unless it receives a retransmission of the request. In that event, the = responder MUST ignore the retransmitted request except insofar as it trigge= rs a retransmission of the response. The initiator MUST remember each reque= st until it receives the corresponding response. The responder MUST remembe= r each response until it receives a request whose sequence number is larger= than or equal to the sequence number in the response plus its window size = (see Section 2.3). Tero: One of the problems here is that if we are using large window size, we have= to keep that many messages for ever. It would be nice, we the responder of= the request, could forget the response packet after lets say 10 minutes af= ter it sent it out to requestor. There is no reason why the other end shoul= d be allowed to resend his request 4 hours later and expect that other end = can still resend reply back. So suggest adding: Responder are allowed to forget response after long timeout for the memory = saving purposes. The timeout must be longer than several minutes that could= be used for the retransmission timers of the other end. Paul: Not done. This is a change to the protocol. The WG might want it, but= it will have to be an explicit decision from the WG. Yaron: I support Tero's proposal. Although strictly speaking this is changi= ng the protocol, it can be seen as a reasonable clarification. =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C4ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

2.1. Use of Retransmission Timers

...

For every pair of IKE messages, the initiator is responsible for retransmission in th= e event of a timeout. The responder MUST never retransmit a response unless i= t receives a retransmission of the request. In that event, the responder MUST ignore the retransmitted request except insofar as it triggers a retransmis= sion of the response. The initiator MUST remember each request until it receives= the corresponding response. The responder MUST remember each response until it receives a request whose sequence number is larger than or equal to the sequence number in the response plus its window size (see Section 2.3).

Tero:

One of the problems here is that if we are using large window size, we have to kee= p that many messages for ever. It would be nice, we the responder of the requ= est, could forget the response packet after lets say 10 minutes after it sent it= out to requestor. There is no reason why the other end should be allowed to res= end his request 4 hours later and expect that other end can still resend reply back. So suggest adding:

Responder are allowed to forget response after l= ong timeout for the memory saving purposes. The timeout must be longer than sev= eral minutes that could be used for the retransmission timers of the other end. =

Paul: Not done. This is a change to the protocol. The WG might want it, but it will h= ave to be an explicit decision from the WG.

Yaron: I support Tero’s proposal. Although strictl= y speaking this is changing the protocol, it can be seen as a reasonable clarification= .


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C4ilex01adcheck_-- --===============0585109993== 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 --===============0585109993==-- From ipsec-bounces@ietf.org Tue Jan 27 15:20:23 2009 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 F261B3A6897; Tue, 27 Jan 2009 15:20:22 -0800 (PST) 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 A571E3A6897 for ; Tue, 27 Jan 2009 15:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 xRnEQw23795n for ; Tue, 27 Jan 2009 15:20:20 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6687F3A67D9 for ; Tue, 27 Jan 2009 15:20:20 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0853A29C00C; Wed, 28 Jan 2009 00:49:53 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B1AA929C005 for ; Wed, 28 Jan 2009 00:49:50 +0200 (IST) X-CheckPoint: {497F8CE1-10000-88241DC2-7B6} 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 n0RMnn5g000510 for ; Wed, 28 Jan 2009 00:49:50 +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, 28 Jan 2009 00:49:49 +0200 From: Yaron Sheffer To: IPsecme WG Date: Wed, 28 Jan 2009 00:49:49 +0200 Thread-Topic: Bis issue #36: Interaction of IKE_SA_INIT retransmissions with specific notifies Thread-Index: AcmAz7dQExyIWFwpRMy+KkruO2rSXw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C7@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 Subject: [IPsec] Bis issue #36: Interaction of IKE_SA_INIT retransmissions with specific notifies 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="===============0278660551==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0278660551== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C7ilex01adcheck_" --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C7ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Current text (sec. 2.1) IKE is a reliable protocol, in the sense that the initiator MUST retransmit= a request until either it receives a corresponding reply OR it deems the I= KE security association to have failed and it discards all state associated= with the IKE_SA and any CHILD_SAs negotiated using that IKE_SA. {{ Clarif-= 2.3 }} Retransmissions of the IKE_SA_INIT request require some special hand= ling. When a responder receives an IKE_SA_INIT request, it has to determine= whether the packet is retransmission belonging to an existing 'half-open' = IKE_SA (in which case the responder retransmits the same response), or a ne= w request (in which case the responder creates a new IKE_SA and sends a fre= sh response), or it belongs to an existing IKE_SA where the IKE_AUTH reques= t has been already received (in which case the responder ignores it). Tero: There is also the case of the invalid ke and cookie notifies, i.e we need t= o add comment about those too: ... or it belongs to an existing IKE_SA where the IKE_AUTH request has been= already received (in which case the responder ignores it), or it is INVALI= D_KE_PAYLOAD or COOKIE notify responses to the IKE_SA_INIT request. Paul: Not done. This is interesting, but should be discussed on the list. =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C7ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Current text (sec. 2.1)

IKE is a reliable protocol, in the sense that the initiator MUST retransmit a reques= t until either it receives a corresponding reply OR it deems the IKE security association to have failed and it discards all state associated with the IK= E_SA and any CHILD_SAs negotiated using that IKE_SA. {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require some special handling. W= hen a responder receives an IKE_SA_INIT request, it has to determine whether th= e packet is retransmission belonging to an existing 'half-open' IKE_SA (in wh= ich case the responder retransmits the same response), or a new request (in whi= ch case the responder creates a new IKE_SA and sends a fresh response), or it belongs to an existing IKE_SA where the IKE_AUTH request has been already received (in which case the responder ignores it).

Tero:

There is also the case of the invalid ke and cookie notifies, i.e we need to add com= ment about those too:

... or it belongs to an existing IKE_SA where th= e IKE_AUTH request has been already received (in which case the responder ign= ores it), or it is INVALID_KE_PAYLOAD or COOKIE notify responses to the IKE_SA_I= NIT request.

Paul: Not done. This is interesting, but should be discussed on the list. =

 


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C7ilex01adcheck_-- --===============0278660551== 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 --===============0278660551==-- From ipsec-bounces@ietf.org Tue Jan 27 15:53:47 2009 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 A479D3A6AA6; Tue, 27 Jan 2009 15:53:47 -0800 (PST) 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 0E1683A695F for ; Tue, 27 Jan 2009 15:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 ibFbuvngHjOl for ; Tue, 27 Jan 2009 15:53:42 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C957A3A67EF for ; Tue, 27 Jan 2009 15:53:41 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id DCF1C29C006; Wed, 28 Jan 2009 00:49:53 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5A0BB29C00B for ; Wed, 28 Jan 2009 00:49:51 +0200 (IST) X-CheckPoint: {497F8CE1-10006-88241DC2-7B6} 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 n0RMnn5i000510 for ; Wed, 28 Jan 2009 00:49:51 +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, 28 Jan 2009 00:49:50 +0200 From: Yaron Sheffer To: IPsecme WG Date: Wed, 28 Jan 2009 00:45:55 +0200 Thread-Topic: Bis issue #68: Counter mode ciphers in IKEv2 to protect IKE SA Thread-Index: AcmA0QPRxLmCt6LnSnG1q8gfbgw4ig== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@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 Subject: [IPsec] Bis issue #68: 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: multipart/mixed; boundary="===============1872159067==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1872159067== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9ilex01adcheck_" --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tero: Here is the new version suggested replacement text [to sec. 3.14]: o Initia= lization Vector - For CBC mode ciphers the length of the initialization vec= tor (IV) is equal to the block length of the underlying encryption algorith= m. Senders MUST select a new unpredictable IV for every message; recipients= MUST accept any value. The reader is encouraged to consult [MODES] for adv= ice on IV generation. In particular, using the final ciphertext block of th= e previous message is not considered unpredictable. For other modes than CB= C the IV format and processing is specified in the document specifying the = encryption algorithm and mode. Pasi: Looks good to me! (We also need to update couple sentences earlier in ikev2= bis, Section 3.14, to match this, though.) =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tero:

Here is the new version suggested replacement text [to sec. 3.14]: 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 M= UST select a new unpredictable IV for every message; recipients MUST accept any value. The reader is encouraged to consult [MODES] for advice on IV generat= ion. In particular, using the final ciphertext block of the previous message is = not considered unpredictable. For other mod= es than CBC the IV format and processing is specified in the document specifyi= ng the encryption algorithm and mode.

Pasi:

Looks good to me! (We also need to update couple sentences earlier in ikev2bis, Section 3.14, to match this, though.)


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9ilex01adcheck_-- --===============1872159067== 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 --===============1872159067==-- From ipsec-bounces@ietf.org Tue Jan 27 17:00:23 2009 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 B631628C103; Tue, 27 Jan 2009 17:00:23 -0800 (PST) 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 8BE593A68A6 for ; Tue, 27 Jan 2009 17:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=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 2dLJ3VF2TGTJ for ; Tue, 27 Jan 2009 17:00:21 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1CD5A28C0D6 for ; Tue, 27 Jan 2009 17:00:21 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EB4FA29C007; Wed, 28 Jan 2009 00:49:53 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5FD9F29C004 for ; Wed, 28 Jan 2009 00:49:50 +0200 (IST) X-CheckPoint: {497F8CE0-10001-88241DC2-7B6} 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 n0RMnn5f000510 for ; Wed, 28 Jan 2009 00:49:50 +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, 28 Jan 2009 00:49:49 +0200 From: Yaron Sheffer To: IPsecme WG Date: Wed, 28 Jan 2009 00:49:48 +0200 Thread-Topic: Bis issue #19: Motivation for including SPIs in the cookie Thread-Index: AcmAz2pE6oaz3iDHQt6FK1Kl5m5i9Q== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C6@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 Subject: [IPsec] Bis issue #19: Motivation for including SPIs in the cookie 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="===============1480139746==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1480139746== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C6ilex01adcheck_" --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C6ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Current text (sec. 2.6): A good way to do this is to set the responder cookie to be: Cookie =3D | Hash(Ni | IPi | SPIi | ) where is a randomly generated secret known only to the responder a= nd periodically changed and | indicates concatenation. = should be changed whenever is regenerated. The cookie can be recom= puted when the IKE_SA_INIT arrives the second time and compared to the cook= ie in the received message. If it matches, the responder knows that the coo= kie was generated since the last change to and that IPi must be th= e same as the source address it saw the first time. Incorporating SPIi into= the calculation ensures that if multiple IKE_SAs are being set up in paral= lel they will all get different cookies (assuming the initiator chooses uni= que SPIi's). Tero: The real reason to hash the SPIs to the cookie is to make sure that attacke= r cannot fetch one cookie from the other end, and then initiate 100 IKE_SA_= INIT exchanges all with different initiator SPIs (and perhaps port numbers)= so that the for the responder it looked like there is lots of machines beh= ind one NAT box who are all trying to connect. As the cookie is tied to the= SPIi the attacker cannot use cookie multiple times. Paul: Not done. This is interesting, but should be discussed on the list. =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C6ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Current text (sec. 2.6):

A good way to do this is to set the responder cookie to be:

Cookie =3D <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

where <secret> is a randomly generated secret known only to the responder a= nd periodically changed and | indicates concatenation. <VersionIDofSecret&g= t; should be changed whenever <secret> is regenerated. The cookie can be recomputed when the IKE_SA_INIT arrives the second time and compared to the cookie in the received message. If it matches, the responder knows that the cookie was generated since the last change to <secret> and that IPi m= ust be the same as the source address it saw the first time. Incorporating SPIi into the calculation ensures that if multiple IKE_SAs are being set up in parallel they will all get different cookies (assuming the initiator choose= s unique SPIi's).

Tero:

The real reason to hash the SPIs to the cookie is to make sure that attacker cannot fetch one cookie from the other end, and then initiate 100 IKE_SA_INIT exchanges all with different initiator SPIs (and perhaps port numbers) so t= hat the for the responder it looked like there is lots of machines behind one N= AT box who are all trying to connect. As the cookie is tied to the SPIi the attacker cannot use cookie multiple times.

Paul: Not done. This is interesting, but should be discussed on the list. =

 


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C6ilex01adcheck_-- --===============1480139746== 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 --===============1480139746==-- From ipsec-bounces@ietf.org Tue Jan 27 18:07:03 2009 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 888553A6B08; Tue, 27 Jan 2009 18:07:03 -0800 (PST) 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 3E50D3A6B2E for ; Tue, 27 Jan 2009 18:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 PuycJHAlI-Pp for ; Tue, 27 Jan 2009 18:07:01 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0C2A53A6B08 for ; Tue, 27 Jan 2009 18:07:00 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id F2B2029C008; Wed, 28 Jan 2009 00:49:53 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0AEC629C009 for ; Wed, 28 Jan 2009 00:49:51 +0200 (IST) X-CheckPoint: {497F8CE1-10002-88241DC2-7B6} 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 n0RMnn5h000510 for ; Wed, 28 Jan 2009 00:49:50 +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, 28 Jan 2009 00:49:49 +0200 From: Yaron Sheffer To: IPsecme WG Date: Wed, 28 Jan 2009 00:49:49 +0200 Thread-Topic: Bis issue #62: Security considerations - implementation robustness Thread-Index: AcmA0IUUQwrEIyU5QpWogJtVoQef/A== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C8@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 Subject: [IPsec] Bis issue #62: Security considerations - implementation robustness 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="===============1539142115==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1539142115== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C8ilex01adcheck_" --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C8ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yaron: Additional proposed text for the Security Considerations: Both IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator is auth= enticated. As a result, an implementation of this protocol (all 100-odd pag= es!) must be highly robust when deployed on any insecure network. Any imple= mentation vulnerability can and will be exploited by unauthenticated peers.= This applies in particular to denial of service attacks, and we note the p= articular issue with the potentially unbounded number of messages in EAP-ba= sed authentication. [Note: I made minor changes to the text from the version on the issue track= er.] =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C8ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yaron:

Additional proposed text for the Security Considerations:

Both IKE_SA_INIT and IKE_AUTH exchanges happen b= efore the initiator is authenticated. As a result, an implementation of this prot= ocol (all 100-odd pages!) must be highly 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 atta= cks, and we note the particular issue with the potentially unbounded number of messages in EAP-based authentication.

[Note: I made minor changes to the text from the version= on the issue tracker.]


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C8ilex01adcheck_-- --===============1539142115== 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 --===============1539142115==-- From ipsec-bounces@ietf.org Tue Jan 27 19:13:44 2009 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 30E8B28B56A; Tue, 27 Jan 2009 19:13:44 -0800 (PST) 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 171A328C0F6 for ; Tue, 27 Jan 2009 19:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 rNS4Qjnmm-YZ for ; Tue, 27 Jan 2009 19:13:42 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D3A0E3A6978 for ; Tue, 27 Jan 2009 19:13:41 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 14C1329C00A; Wed, 28 Jan 2009 00:49:50 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1435729C006 for ; Wed, 28 Jan 2009 00:49:49 +0200 (IST) X-CheckPoint: {497F8CDF-10003-88241DC2-7B6} 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 n0RMnl5h000496 for ; Wed, 28 Jan 2009 00:49:48 +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, 28 Jan 2009 00:49:48 +0200 From: Yaron Sheffer To: IPsecme WG Date: Wed, 28 Jan 2009 00:49:47 +0200 Thread-Topic: Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!) Thread-Index: AcmAzidHMDDzbkzpRY2Z5JpVjgu0WA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C5@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 Subject: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!) 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="===============0341982747==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0341982747== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C5ilex01adcheck_" --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C5ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Current text: NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the order= shown in the figures in Section 2? Can we eliminate the requirement in the= following paragraph? If not, we will probably have to add a new appendix w= ith the order, but there is no reason to do that if no one actually cares. = {{ Remove this paragraph before the document is finalized, of course. }} Tero: Our implementation do not care about the order of the payloads except= in some specific places (CERT payloads and so on). Paul: Not done. We still need to hear from others. Current text (sec. 2.5): {{ Demoted the SHOULD in the second clause }}Although new payload types may= be added in the future and may appear interleaved with the fields defined = in this specification, implementations MUST send the payloads defined in th= is specification in the order shown in the figures in Section 2; implementa= tions are explicitly allowed to reject as invalid a message with those payl= oads in any other order. Tero: I would really like to change this to say that payloads must be accep= ted in any order, but implementations should try to send them out in the or= der shown in the figures. Exceptions to this is the CERT payloads (the end = entity cert MUST be first), and REKEY and COOKIE notifies. Paul: Not done. This is interesting, but should be discussed on the list. Yaron: this really is a major protocol change, we cannot guarantee that no = existing implementation cares about payload order. I suggest to leave the p= rotocol as-is, although nobody likes this constraint. =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C5ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Current text:

NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the order shown i= n the figures in Section 2? Can we eliminate the requirement in the following paragraph? If not, we will probably have to add a new appendix with the ord= er, but there is no reason to do that if no one actually cares. {{ Remove this paragraph before the document is finalized, of course. }}

Tero: Our implementation do not care about the order of the payloads except in some specific places (CERT payloads and so on).

{{ Demoted the SHOULD in the second clause }}Although new payload types may be added in the future and may appear interleaved with the fields defined in t= his specification, implementations MUST send the payloads defined in this speci= fication in the order shown in the figures in Section 2; implementations are explici= tly allowed to reject as invalid a message with those payloads in any other ord= er.

Tero: I would really like to change this to say that payloads must be accepted in a= ny order, but implementations should try to send them out in the order shown i= n the figures. Exceptions to this is the CERT payloads (the end entity cert M= UST be first), and REKEY and COOKIE notifies.

Paul: Not done. This is interesting, but should be discussed on the list. =

Yaron: this really i= s a major protocol change, we cannot guarantee that no existing implementatio= n cares about payload order. I suggest to leave the protocol as-is, although nobody likes this constraint.


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C5ilex01adcheck_-- --===============0341982747== 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 --===============0341982747==-- From ipsec-bounces@ietf.org Tue Jan 27 20:19:41 2009 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 A90723A6B9A; Tue, 27 Jan 2009 20:19:41 -0800 (PST) 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 8A3783A6B99 for ; Tue, 27 Jan 2009 20:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 zD+oHA7HME3m for ; Tue, 27 Jan 2009 20:19:39 -0800 (PST) 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 630EA3A6B9F for ; Tue, 27 Jan 2009 20:19:39 -0800 (PST) Received: from [10.20.30.158] (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 n0S4JIVg019189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Jan 2009 21:19:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63ACA6@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63A89D@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63ACA6@il-ex01.ad.checkpoint.com> Date: Tue, 27 Jan 2009 20:19:16 -0800 To: ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] virtual interim meeting on Feb. 3 - additional details 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 12:35 PM +0200 1/26/09, Yaron Sheffer wrote: >Hi everyone, > >The meeting is on for next week, and authors are reminded to send their slides on time. > >We are planning to use the TeamSpeak application for both voice conferencing and IM. Paul has kindly set up a private server for our use, and the full details are on the wiki: http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/ConferenceCalls > >Please make sure to download and try the client at least one day in advance. The server is already available. Let us know if you have any problems. Just to be clear: the VPNC TeamSpeak server is up now so you can test connecting to it. However, if no one is there, you can't really test speaking. Given that, we will have at least one "dry run" test on Thursday Jan 29 starting at the same clock time as the meeting will be next week: 16:00 GMT (18:00 Israel, 17:00 CET, 11:00 EST, 8:00 PST), but only for 30 minutes. If needed, we can schedule a second test. Alternately, send Yaron or I off-list mail if you want to do a one-on-one test. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 28 00:18:09 2009 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 543A73A69DC; Wed, 28 Jan 2009 00:18:09 -0800 (PST) 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 111303A69BB for ; Wed, 28 Jan 2009 00:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 zge+XGKj+KOb for ; Wed, 28 Jan 2009 00:18:07 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id CC2B23A6910 for ; Wed, 28 Jan 2009 00:18:06 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2CEB229C004; Wed, 28 Jan 2009 10:17:48 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 440B729C002 for ; Wed, 28 Jan 2009 10:17:47 +0200 (IST) X-CheckPoint: {498011FA-10000-88241DC2-7B6} 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 n0S8Hk5f006700 for ; Wed, 28 Jan 2009 10:17:46 +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, 28 Jan 2009 10:17:46 +0200 From: Yoav Nir To: Yaron Sheffer , IPsecme WG Date: Wed, 28 Jan 2009 10:17:55 +0200 Thread-Topic: [IPsec] Bis issue #11: Clarify which traffic selectors to use in rekeying Thread-Index: AcmAzRc2mcYmmDBBSqS1KgnLSyrNWwAUaZmw Message-ID: <9FB7C7CE79B84449B52622B506C78036130846B0F9@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3@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 Subject: Re: [IPsec] Bis issue #11: Clarify which traffic selectors to use in 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 Yaron Sheffer wrote: > Existing text (sec. 1.3.1) > The CREATE_CHILD_SA response for creating a new Child SA is: > <-- HDR, SK {SA, Nr, [KEr], > TSi, TSr} > > The responder replies (using the same Message ID to respond) with the accepted offer in an SA > payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the > selected cryptographic suite includes that group. > > The traffic selectors for traffic to be sent on that SA are specified > in the TS payloads in the response, which may be a subset of what the > initiator of the Child SA proposed. > > Tero: > Add comment about which traffic selectors to use in the rekeying: > When doing rekeying the traffic selectors SHOULD come from the original decorrelated policy, i.e. > not the same traffic selectors which the old SA had in case the responder narrowed them, but from > the policy which initiator used originally to create the IPsec SA. This allows the SA to expand to > full traffic selector set allowed by latest (perhaps changed) policy. > > Paul: > Not done. This is interesting, but should be discussed on the list. It can be done as Tero suggests, as long as the policy hasn't changed, and as long as the new initiator is the same as the old initiator. But what if the original decorrelated policy is no longer valid, but the current SPD cache entry still is? What if the new initiator (formerly the responder) does not have the same decorrelated policy? I suggest that the (new) initiator be able to rekey with any traffic selectors, as long as they are a superset of the old SA selectors. IOW as long as the (new) responder can narrow the selectors down to the selectors from the old SA, it should be fine. Here's some proposed text for the end of section 1.3.3. The traffic selectors for traffic to be sent on that SA are specified in the TS payloads in the response, which may be a subset of what the initiator of the Child SA proposed. When rekeying a Child SA, the proposal of the initiator MUST be a superset of the selectors of the old SA. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 28 00:28:06 2009 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 EC6233A69BB; Wed, 28 Jan 2009 00:28:05 -0800 (PST) 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 A55953A6BE2 for ; Wed, 28 Jan 2009 00:28:04 -0800 (PST) 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 YOM9I6YKP3Zi for ; Wed, 28 Jan 2009 00:28:03 -0800 (PST) Received: from el-out-1112.google.com (el-out-1112.google.com [209.85.162.182]) by core3.amsl.com (Postfix) with ESMTP id 77F623A6910 for ; Wed, 28 Jan 2009 00:28:00 -0800 (PST) Received: by el-out-1112.google.com with SMTP id r27so2236173ele.13 for ; Wed, 28 Jan 2009 00:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=ymSpilhH6uio6Rcoi1ZcSqlnd7OIDPHBuYSrXSqwrJY=; b=D5X9cPidmg00r79MpXxCdUsW54gJeXBPhxhsgyQDUqLGNLh9ryaZ0sHILUBTAkB4mf gMCEVaHgFQpPOczpcJ4GnAybodk+9C85LarzZjQZ3iwtup0sx0ED3eFJrsRToncR4czQ 4IjmwKWo+3eSSGt2YXh7ybo1/ZrviClnOgAIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NsNimnJ9ev/jUcWiAiZMzRmrQ63MJNw3TCZuO4lKa7Hj2sXShbinciOCSbUBtHq8uX 1WHP1E38tufWAFmgLMSsh7Npf9F878NtdYOQiB/FPst0z0IZKgJmTzmgRdaat3B6uelu 7nrnIztNAYxWL1L9DZpSmIHVngQGuExG7eas4= MIME-Version: 1.0 Received: by 10.231.11.137 with SMTP id t9mr780286ibt.49.1233131261424; Wed, 28 Jan 2009 00:27:41 -0800 (PST) Date: Wed, 28 Jan 2009 00:27:41 -0800 Message-ID: <7d660a970901280027s3ab8a6a3qad4f84cfd1122803@mail.gmail.com> From: Jeff Sun To: IPsec@ietf.org Subject: [IPsec] Traffic Selectors - CHILD_SAs that do not allow TSi[1] & TSr[1] 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="===============1395565039==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1395565039== Content-Type: multipart/alternative; boundary=000325574c3ecc73e5046186be7b --000325574c3ecc73e5046186be7b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, According to RFC 4306 Section 2.9, an implementation SHOULD include specific traffic selectors for the first traffic selectors in the TSi and TSr Payloads. The reason that this specification is a SHOULD and not a MUST is because (as stated in Section 2.9), upon start-up, some implementations may try recover previous CHILD_SA state in response to an unexpected device crash. However, RFC 4718 goes on to clarify traffic selector negotiation by defining the narrowing process more clearly. Specifically, it states that if the union of all subsets is not acceptable by policy, then the subset that contains the first traffic selectors (TSi[1], TSr[1]) take precedence over the subsets that do not contain these first traffic selectors. Furthermore, the section also details a case where no subsets contain TSi[1] and TSr[1] - in this case the responder arbitrarily chooses a subset. I assume that TSi[1] and TSr[1] in context of RFC 4718-Section 2.9 speaks of the specific traffic selectors (the traffic selectors of the packet that triggered the Initial Exchange/CREATE_CHILD_SA Exchange). Note, RFC 4718-Section 2.9 never speaks of the start-up case, thus it seems that the TSi[1] and TSr[1] (the specific traffic selectors) cases are only scoped now. If this indeed is the case, perhaps the last case (where TSi[1] and TSr[1] are not encompassed) should be re-considered. Specifically, what is the benefit of establishing a CHILD_SA such that the specific traffic selectors are not encompassed? The CHILD_SA establishment exchange was triggered by that packet and generally speaking, it seems that subsequent traffic flow would be of the same specific traffic selectors, not the other traffic selectors associated with the specific SPD Rule Entry hit. In nutshell, it's probably better suited that the responder simply send back a Notify Payload - Error Message (i.e, FIRST_TRAFFIC_SELECTORS_PROHIBITED), thus refusing to establish the CHILD_SA. If by chance, different traffic flow (with different specific traffic selector) hits the same SPD Rule entry, a new CHILD_SA establishement exchange would simply initiate and establish a new CHILD_SA. Thanks, Jeff Sun -- For relaxing times, make it Suntory time. - Bob Harris, Lost in Translation --000325574c3ecc73e5046186be7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,
  According to RFC 4306 Section 2.9, an implementation SHOULD i= nclude specific traffic selectors for the first traffic selectors in the TS= i and TSr Payloads.  The reason that this specification is a SHOULD an= d not a MUST is because (as stated in Section 2.9), upon start-up, some imp= lementations may try recover previous CHILD_SA state in response to an unex= pected device crash.  However, RFC 4718 goes on to clarify traffic sel= ector negotiation by defining the narrowing process more clearly.

  Specifically, it states that if the union of all subsets is not = acceptable by policy, then the subset that contains the first traffic selec= tors (TSi[1], TSr[1]) take precedence over the subsets that do not contain = these first traffic selectors.  Furthermore, the section also details = a case where no subsets contain TSi[1] and TSr[1] - in this case the respon= der arbitrarily chooses a subset.  I assume that TSi[1] and TSr[1] in = context of RFC 4718-Section 2.9 speaks of the specific traffic selectors (the traffic selectors of the packet that triggered the Initial Exchange/CREATE_CHILD_SA Exchange). = Note, RFC 4718-Section 2.9 never speaks of the start-up case, thus it seem= s that the TSi[1] and TSr[1] (the specific traffic selectors) cases are onl= y scoped now.

  If this indeed is the case, perhaps the last case (where TSi[1] = and TSr[1] are not encompassed) should be re-considered.  Specifically= , what is the benefit of establishing a CHILD_SA such that the specific tra= ffic selectors are not encompassed?  The CHILD_SA establishment exchan= ge was triggered by that packet and generally speaking, it seems that subse= quent traffic flow would be of the same specific traffic selectors, not the= other traffic selectors associated with the specific SPD Rule Entry hit.
  In nutshell, it's probably better suited that the responder = simply send back a Notify Payload - Error Message (i.e, FIRST_TRAFFIC_SELEC= TORS_PROHIBITED), thus refusing to establish the CHILD_SA.  If by chan= ce, different traffic flow (with different specific traffic selector) hits = the same SPD Rule entry, a new CHILD_SA establishement exchange would simpl= y initiate and establish a new CHILD_SA. 

Thanks,
  Jeff Sun
--
For relaxing times, make it Suntor= y time. - Bob Harris, Lost in Translation
--000325574c3ecc73e5046186be7b-- --===============1395565039== 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 --===============1395565039==-- From ipsec-bounces@ietf.org Wed Jan 28 00:38:57 2009 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 F19563A6BE1; Wed, 28 Jan 2009 00:38:56 -0800 (PST) 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 4DE113A6BE1 for ; Wed, 28 Jan 2009 00:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 qOBS9NUa6Js4 for ; Wed, 28 Jan 2009 00:38:54 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E50063A6982 for ; Wed, 28 Jan 2009 00:38:53 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B37AD29C005; Wed, 28 Jan 2009 10:38:35 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6B8DB29C004 for ; Wed, 28 Jan 2009 10:38:34 +0200 (IST) X-CheckPoint: {498016D9-10000-88241DC2-7B6} 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 n0S8cX5f014148 for ; Wed, 28 Jan 2009 10:38:33 +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, 28 Jan 2009 10:38:33 +0200 From: Yoav Nir To: Yaron Sheffer , IPsecme WG Date: Wed, 28 Jan 2009 10:38:41 +0200 Thread-Topic: Bis issue #14: Bounding the retransmit time Thread-Index: AcmAzcIBxkaPjM7vSp6FcaJolJCsIQAVICYQ Message-ID: <9FB7C7CE79B84449B52622B506C78036130846B100@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C4@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C4@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 Subject: Re: [IPsec] Bis issue #14: Bounding the retransmit time 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 Yaron Sheffer wrote: > 2.1. Use of Retransmission Timers > ... > For every pair of IKE messages, the initiator is responsible for > retransmission in the event of a timeout. The responder MUST never > retransmit a response unless it receives a retransmission of the > request. In that event, the responder MUST ignore the retransmitted > request except insofar as it triggers a retransmission of the > response. The initiator MUST remember each request until it receives > the corresponding response. The responder MUST remember each > response until it receives a request whose sequence number is larger > than or equal to the sequence number in the response plus its window > size (see Section 2.3). > Tero: > One of the problems here is that if we are using large window size, we have to keep that many > messages for ever. It would be nice, we the responder of the request, could forget the response > packet after lets say 10 minutes after it sent it out to requestor. There is no reason why the > other end should be allowed to resend his request 4 hours later and expect that other end can still > resend reply back. So suggest adding: > > Responder are allowed to forget response after long timeout for the memory saving purposes. The > timeout must be longer than several minutes that could be used for the retransmission timers of the > other end. > > Paul: Not done. This is a change to the protocol. The WG might want it, but it will have to be an > explicit decision from the WG. > > Yaron: I support Tero's proposal. Although strictly speaking this is changing the protocol, it can > be seen as a reasonable clarification. I'm not sure about this. Supporting a large window size is only necessary if there are a lot of concurrent exchanges. In that case, the responses expire from the cache before the 10 minutes (or one) are up. On the other hand, even with a window size of 1, the current text seems to suggest that the last packet should be retained indefinitely. This doesn't make sense, as the initiator of that packet is also bound by the "at least a dozen times over a period of at least several minutes", so four hours later, the initiator has either given up on the IKE SA, or has received the response. So I'm with Tero on this one. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nfk@advocaten-dhooghe.be Wed Jan 28 01:41:53 2009 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 28AE628C246 for ; Wed, 28 Jan 2009 01:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.474 X-Spam-Level: X-Spam-Status: No, score=-12.474 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMoBqEI4PRz6 for ; Wed, 28 Jan 2009 01:41:51 -0800 (PST) Received: from agenatramp.fr (unknown [81.214.70.77]) by core3.amsl.com (Postfix) with SMTP id 731BA28C0CF for ; Wed, 28 Jan 2009 01:41:48 -0800 (PST) To: Subject: New products everyday at our chemists. From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090128094150.731BA28C0CF@core3.amsl.com> Date: Wed, 28 Jan 2009 01:41:48 -0800 (PST)
Tell a friend · Download latest version See this email as a webpage

Hello ipsec-archive

Shipped Privately And Discreetly To Your Door!
See this email as a webpage
  We want to put a great big grin on your face in 2009. You'll be to rejoice all year.  

Unsubscribe · Lost Password · Account Settings · Help · Terms of Service · Privacy

© 2003-2009 SASI Limited. SASi Communications S.a.r.l., 22/24 Green St, Amsterdam L8493.

SASi, SASiIn, SASiOut, SASicasts, SASi Certified, SASiMe!, SASi Pro, SASiFind, SASi Prime, SASi To Go, associated logos and the ‘S’-symbol are trademarks of SASi Limited.
From ipsec-bounces@ietf.org Wed Jan 28 04:05:14 2009 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 5D80C28C264; Wed, 28 Jan 2009 04:05:14 -0800 (PST) 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 DA64B28C264 for ; Wed, 28 Jan 2009 04:05:13 -0800 (PST) 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 i+9654k2pz8e for ; Wed, 28 Jan 2009 04:05:13 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C2C4628C262 for ; Wed, 28 Jan 2009 04:05:12 -0800 (PST) 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 n0SC4prV026291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Jan 2009 14:04:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0SC4oGi026929; Wed, 28 Jan 2009 14:04:50 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18816.18914.790078.914350@fireball.kivinen.iki.fi> Date: Wed, 28 Jan 2009 14:04:50 +0200 From: Tero Kivinen To: IPsecme WG X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 136 min Subject: [IPsec] Suggestion text for #41 Interaction of MOBIKE with 'simple' IKE mobility 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 Here is the suggested additional paragraph for the NAT-T section (2.23). This should be after the paragraph listed in the ticket explaining the dynamic address update. o If MOBIKE [RFC4555] is in use, then rules for the dynamic updates are different. If MOBIKE is enabled then the host not behind a NAT MUST NOT dynamically update address for IKEv2 packets. MOBIKE address update mechanism will take care of the updates. The MOBIKE host not behind a NAT MAY dynamically update address for ESP packets. See IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555] section 3.8 for more information. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 28 04:12:11 2009 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 1D7A93A69E7; Wed, 28 Jan 2009 04:12:11 -0800 (PST) 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 A26533A69E7 for ; Wed, 28 Jan 2009 04:12:09 -0800 (PST) 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 kSsR7ruy1VZF for ; Wed, 28 Jan 2009 04:12:09 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9C4963A6952 for ; Wed, 28 Jan 2009 04:12:08 -0800 (PST) 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 n0SCBje4012169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 14:11:45 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0SCBiGb001419; Wed, 28 Jan 2009 14:11:44 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18816.19328.561690.224974@fireball.kivinen.iki.fi> Date: Wed, 28 Jan 2009 14:11:44 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C8@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C8@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: IPsecme WG Subject: [IPsec] Bis issue #62: Security considerations - implementation robustness 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 Yaron Sheffer writes: > Yaron: > Additional proposed text for the Security Considerations: > > 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 highly 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 issue with the > potentially unbounded number of messages in EAP-based > authentication. > > [Note: I made minor changes to the text from the version on the issue tracker.] I support adding that text to security considerations section. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 28 04:36:40 2009 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 67BDC3A68F9; Wed, 28 Jan 2009 04:36:40 -0800 (PST) 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 95CE13A68F9 for ; Wed, 28 Jan 2009 04:36:39 -0800 (PST) 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 HDGr46NDO8R2 for ; Wed, 28 Jan 2009 04:36:38 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 059353A68F0 for ; Wed, 28 Jan 2009 04:36:37 -0800 (PST) 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 n0SCaEKP003648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 14:36:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0SCaDC9025722; Wed, 28 Jan 2009 14:36:13 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18816.20797.955883.82254@fireball.kivinen.iki.fi> Date: Wed, 28 Jan 2009 14:36:13 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130846B0F9@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036130846B0F9@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 22 min X-Total-Time: 22 min Cc: IPsecme WG Subject: Re: [IPsec] Bis issue #11: Clarify which traffic selectors to use in 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 Yoav Nir writes: > Yaron Sheffer wrote: > > > Existing text (sec. 1.3.1) > > The CREATE_CHILD_SA response for creating a new Child SA is: > > <-- HDR, SK {SA, Nr, [KEr], > > TSi, TSr} > > > > The responder replies (using the same Message ID to respond) with the accepted offer in an SA > > payload, and a Diffie-Hellman value in the KEr payload if KEi was included in the request and the > > selected cryptographic suite includes that group. > > > > The traffic selectors for traffic to be sent on that SA are specified > > in the TS payloads in the response, which may be a subset of what the > > initiator of the Child SA proposed. > > > > Tero: > > Add comment about which traffic selectors to use in the rekeying: > > When doing rekeying the traffic selectors SHOULD come from the original decorrelated policy, i.e. > > not the same traffic selectors which the old SA had in case the responder narrowed them, but from > > the policy which initiator used originally to create the IPsec SA. This allows the SA to expand to > > full traffic selector set allowed by latest (perhaps changed) policy. > > > > Paul: > > Not done. This is interesting, but should be discussed on the list. > > It can be done as Tero suggests, as long as the policy hasn't > changed, and as long as the new initiator is the same as the old > initiator. But what if the original decorrelated policy is no longer > valid, but the current SPD cache entry still is? If the policy has changed so that old SA is no longer valid (and cannot be rekeyed because of that), then that is even more reason to use the new policy and create new SA which is allowed by policy and delete the old SA which after the reconfigruation would be against the current policy. If policy is not changed then they should get same narrowing happening again, meaning they will get new SA with same traffic selectors. If policy has been changed so it affects the resulting SA, then the new SA MUST follow new policy and reusing old traffic selectors (which are against current policy) would be violation of policy. > What if the new initiator (formerly the responder) does not have the > same decorrelated policy? If the policies re different in both ends, then it is possible the traffic selectors will be different depending which end created the SA. I do not think that really matters. > I suggest that the (new) initiator be able to rekey with any traffic > selectors, as long as they are a superset of the old SA selectors. > IOW as long as the (new) responder can narrow the selectors down to > the selectors from the old SA, it should be fine. Here's some > proposed text for the end of section 1.3.3. So you propose that is not necessarely to take traffic selectors directly from policy, but initiator starting rekey can take any superset of current traffic selectors, even when it would not be subset of its own policy? That would mean initiator of the rekey could be violating his own policy, and I do not think we want to allow that. > The traffic selectors for traffic to be sent on that SA are specified > in the TS payloads in the response, which may be a subset of what the > initiator of the Child SA proposed. When rekeying a Child SA, the > proposal of the initiator MUST be a superset of the selectors of the > old SA. This would mean that if initiators policy has changed so that some addresses are no longer acceptable by policy he cannot use rekey to create new SA with that set of traffic selectors, but he must delete the old IPsec SA and create new. I.e. lets take example: Host A has policy of local = 192.168.11.0-192.168.11.64 remote = any Host B has policy of remote = 192.168.11.1-192.168.11.99 local = 10.0.0.0 - 10.255.255.255 Host A initiates first and proposes traffic selectors: TSi = 192.168.11.0-192.168.11.64 TSr = 0.0.0.0-255.255.255.255 Host B narrows them down to: reply TSi = 192.168.11.1-192.168.11.64 reply TSr = 10.0.0.0 - 10.255.255.255 Now if host A would start rekey the TSi, TSr, and reply TSi, and TSr would be exactly same. If Host B starts rekey the traffic selectors would be: TSi = 10.0.0.0 - 10.255.255.255 TSr = 192.168.11.1-192.168.11.99 reply TSi = 10.0.0.0 - 10.255.255.255 reply TSr = 192.168.11.1-192.168.11.64 i.e. resulting exactly same traffic selectors.. Now if host B is reconfigured with new policy: remote = 192.168.11.1-192.168.11.99 local = 10.10.0.0 - 10.10.255.255 With your proposal host B cannot anymore rekey the old SA at all as it cannot propose the new local IP address range 10.10.0.0 - 10.10.255.255 as it is not superset of the negotiated traffic selector 10.0.0.0 - 10.255.255.255. Host A could still rekey as he could offer remote = any, and host B could then narrow it down to new smaller range. In my proposal both ends could still rekey the old SA with new traffic selectors. Hmm... perhaps the "original policy" word in my text was misleading. I do not mean the exact policy values the node had when the SA was created, but that the same policy entry that caused the SA to be created is looked up and the current policy values are then fetched. I.e. get the same SPD entry (or its successor if it has been changed) and derive traffic selectors from there again. In essence this means doing policy lookup based on the any packet going to the IPsec SA and finding the SPD entry that should be used for that packet. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 28 05:18:01 2009 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 A6E6E28C26B; Wed, 28 Jan 2009 05:18:01 -0800 (PST) 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 7955528C1D2 for ; Wed, 28 Jan 2009 05:18:00 -0800 (PST) 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 2pUJ8VZwtijM for ; Wed, 28 Jan 2009 05:17:59 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BE8203A682F for ; Wed, 28 Jan 2009 05:17:58 -0800 (PST) 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 n0SDHZNG018539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 15:17:35 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0SDHYww013942; Wed, 28 Jan 2009 15:17:34 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18816.23278.909620.417319@fireball.kivinen.iki.fi> Date: Wed, 28 Jan 2009 15:17:34 +0200 From: Tero Kivinen To: Jeff Sun In-Reply-To: <7d660a970901280027s3ab8a6a3qad4f84cfd1122803@mail.gmail.com> References: <7d660a970901280027s3ab8a6a3qad4f84cfd1122803@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 23 min X-Total-Time: 38 min Cc: IPsec@ietf.org Subject: [IPsec] Traffic Selectors - CHILD_SAs that do not allow TSi[1] & TSr[1] 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 Jeff Sun writes: > Hi, > According to RFC 4306 Section 2.9, an implementation SHOULD include > specific traffic selectors for the first traffic selectors in the TSi and > TSr Payloads. The reason that this specification is a SHOULD and not a MUST > is because (as stated in Section 2.9), upon start-up, some implementations > may try recover previous CHILD_SA state in response to an unexpected device > crash. However, RFC 4718 goes on to clarify traffic selector negotiation by > defining the narrowing process more clearly. > > Specifically, it states that if the union of all subsets is not acceptable > by policy, then the subset that contains the first traffic selectors > (TSi[1], TSr[1]) take precedence over the subsets that do not contain these > first traffic selectors. Furthermore, the section also details a case where > no subsets contain TSi[1] and TSr[1] - in this case the responder > arbitrarily chooses a subset. I assume that TSi[1] and TSr[1] in context of > RFC 4718-Section 2.9 speaks of the specific traffic selectors (the traffic > selectors of the packet that triggered the Initial Exchange/CREATE_CHILD_SA > Exchange). Note, RFC 4718-Section 2.9 never speaks of the start-up case, > thus it seems that the TSi[1] and TSr[1] (the specific traffic selectors) > cases are only scoped now. The rule saying that you select arbitrary subset if first traffic selectors cannot be fit to the policy, is just there to work with the startup case. As there is no indication from the initiator whether this is startup case or not, the responder cannot know whether the first traffic selector is from the packet or whether it is from the policy. The rules in rfc 4718 are written as they are so that they will work in both cases. I.e if the first traffic selector is from the packet (i.e. the 3rd bullet point in the 4.10 of RFC4718) then narrowing is done so that first traffic selector is included to the returned range. Note, that usually in this case one of the remaining traffic selectors is superset of the first traffic selector (i.e. the actual policy entry). If the first traffic selector is not from the packet but from policy then is possible that it is not completely allowed by local policy. In that case there is nothing responder can do better than guess what initiator meant, i.e. it will narrow down to any acceptable subset (4th bullet point). Note, that the last paragraph of 4.10 which says that responder arbitrarily chooses one of them cannot apply for the 3rd bullet in case the first traffic selector is really from packet. If the first traffic selector has exact values taken from the packet, then there cannot be multiple subsets which include that (as the SPD is ordered). The last paragraph only include 3rd bullet because it might happen that the first traffic selector is not from packet but from policy but the whole range is still acceptable by local policy. > If this indeed is the case, perhaps the last case (where TSi[1] and TSr[1] > are not encompassed) should be re-considered. Specifically, what is the > benefit of establishing a CHILD_SA such that the specific traffic selectors > are not encompassed? The CHILD_SA establishment exchange was triggered by > that packet and generally speaking, it seems that subsequent traffic flow > would be of the same specific traffic selectors, not the other traffic > selectors associated with the specific SPD Rule Entry hit. That case is really meant for cases where the first traffic selectors do not come from the packet. I agree that in case the first traffic selector happens to be from packet and it cannot be fitted in, then creating some other SA which do not include first traffic selector does not really help for transmitting that packet. On the other hand if that packet is not allowed at all by the remote ends policy that packet will never be transmitted anyways. One of the problems is that there is still lots of broken IKEv2 implementations who do not send first traffic selector with data from the packet at all. In the last IKEv2 interoperability event there were few implementations who didn't work at all if other end decided to send traffic selector containing triggering packet data (i.e. we had to add flag that allowed us to disable sending that data). Most of the implementations accepted such traffic selectors, but only half of the implementations actually sent such traffic selectors. Because of this implementations wanting to work properly with other vendors, need to do some compatibility code to work with those broken implementations. > In nutshell, it's probably better suited that the responder simply send > back a Notify Payload - Error Message (i.e, > FIRST_TRAFFIC_SELECTORS_PROHIBITED), thus refusing to establish the > CHILD_SA. If by chance, different traffic flow (with different specific > traffic selector) hits the same SPD Rule entry, a new CHILD_SA > establishement exchange would simply initiate and establish a new CHILD_SA. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From organ@aeat.es Wed Jan 28 06:01:51 2009 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 46E963A681D for ; Wed, 28 Jan 2009 06:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.396 X-Spam-Level: X-Spam-Status: No, score=-7.396 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGYMNSLM7YQB for ; Wed, 28 Jan 2009 06:01:50 -0800 (PST) Received: from HFA62-0-132-134.bb.netvision.net.il (HFA62-0-132-134.bb.netvision.net.il [62.0.132.134]) by core3.amsl.com (Postfix) with SMTP id 609CA3A6831 for ; Wed, 28 Jan 2009 06:01:16 -0800 (PST) To: Subject: You've received an answer to your question From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090128140128.609CA3A6831@core3.amsl.com> Date: Wed, 28 Jan 2009 06:01:16 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.whetherwit.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://whetherwit.com/faq.php

Privacy Statement | Terms & Conditions | Contact

KEYWORD Ltd.
Tower Bridge Business Complex. Unit 3, B218. 259 Clements Road. London. SE57 4DG

© 2006-2008 KEYWORD, Ltd. All Rights Reserved

From ipsec-bounces@ietf.org Wed Jan 28 06:41:21 2009 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 A37DB3A6A8E; Wed, 28 Jan 2009 06:41:21 -0800 (PST) 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 7E46F3A6A8E for ; Wed, 28 Jan 2009 06:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 3apV+ku3k4Lw for ; Wed, 28 Jan 2009 06:41:16 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id EDE663A68EF for ; Wed, 28 Jan 2009 06:41:15 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KE600095RFZ18@szxga03-in.huawei.com> for ipsec@ietf.org; Wed, 28 Jan 2009 22:40:47 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KE600FJERFZXN@szxga03-in.huawei.com> for ipsec@ietf.org; Wed, 28 Jan 2009 22:40:47 +0800 (CST) Received: from Syed ([10.18.23.200]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KE6009SFRFY1D@szxml04-in.huawei.com> for ipsec@ietf.org; Wed, 28 Jan 2009 22:40:47 +0800 (CST) Date: Wed, 28 Jan 2009 20:10:43 +0530 From: Syed Ajim Hussain In-reply-to: To: ipsec@ietf.org Message-id: <002d01c98156$66dba110$c817120a@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: AcmBStsWZfnkBqW0SQiTwgXlpPSNZwACTxIw Subject: [IPsec] RFC2409 :Sec 5.2 (Hash of Public-Key or Hash of CERT ?) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: syedah@huawei.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1547476888==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1547476888== Content-type: multipart/alternative; boundary="Boundary_(ID_kkYfrqiKoR0tLU/OwrdK5g)" This is a multi-part message in MIME format. --Boundary_(ID_kkYfrqiKoR0tLU/OwrdK5g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT RFC 2409 : Sec 5.2 : Phase 1 Authenticated With Public Key Encryption "Using public key encryption to authenticate the exchange, the ancillary information exchanged is encrypted nonces. Each party's ability to reconstruct a hash (proving that the other party decrypted the nonce) authenticates the exchange. In order to perform the public key encryption, the initiator must already have the responder's public key. In the case where the responder has multiple public keys, a hash of the certificate the initiator is using to encrypt the ancillary information is passed as part of the third message. In this way the responder can determine which corresponding private key to use to decrypt the encrypted payloads and identity protection is retained." Question : In the case where the peer has multiple public keys, We need to include a Hash payload, Now Hash of public key or Hash of Certificate itself ? Many Document/Implementation says it is Hash of Public Key , But according RFC it is Hash of CERT. Can any one please Clarify this point? ============================================================================ ======================================= This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_kkYfrqiKoR0tLU/OwrdK5g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

RFC 2409 : Sec 5.2 :  Phase 1 Authenticated With Public Key Encryption

   “Using public key encryption to authenticate the exchange, the

   ancillary information exchanged is encrypted nonces. Each party's

   ability to reconstruct a hash (proving that the other party decrypted

   the nonce) authenticates the exchange.

   In order to perform the public key encryption, the initiator must

   already have the responder's public key. In the case where the

   responder has multiple public keys, a hash of the certificate the

   initiator is using to encrypt the ancillary information is passed as

   part of the third message. In this way the responder can determine

   which corresponding private key to use to decrypt the encrypted

   payloads and identity protection is retained.”

 

Question :   In the case where the peer has multiple public keys, We need to include a Hash payload,

             Now Hash of public key or Hash of Certificate itself ? Many Document/Implementation

             says it is Hash of Public Key , But according  RFC it is Hash of CERT. Can any one please

             Clarify this point?

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

 This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure,  reproduction, or dissemination) by persons other than the intended

recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email

 immediately and delete it!

--Boundary_(ID_kkYfrqiKoR0tLU/OwrdK5g)-- --===============1547476888== 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 --===============1547476888==-- From ipsec-bounces@ietf.org Wed Jan 28 06:43:59 2009 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 3628C3A6BE2; Wed, 28 Jan 2009 06:43:59 -0800 (PST) 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 2C19828C0F4 for ; Wed, 28 Jan 2009 06:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 7hJCZjMaqEjS for ; Wed, 28 Jan 2009 06:43:57 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B32973A6B94 for ; Wed, 28 Jan 2009 06:43:56 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3586729C006; Wed, 28 Jan 2009 16:43:38 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 37C2E29C004; Wed, 28 Jan 2009 16:43:36 +0200 (IST) X-CheckPoint: {49806C64-10000-88241DC2-7B6} 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 n0SEhZ5f002058; Wed, 28 Jan 2009 16:43:35 +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, 28 Jan 2009 16:43:35 +0200 From: Yoav Nir To: Tero Kivinen Date: Wed, 28 Jan 2009 16:43:44 +0200 Thread-Topic: [IPsec] Bis issue #11: Clarify which traffic selectors to use in rekeying Thread-Index: AcmBRQVXpk/XlsoDQf+AgU68vwImywAEL/fA Message-ID: <9FB7C7CE79B84449B52622B506C78036130846B19D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036130846B0F9@il-ex01.ad.checkpoint.com> <18816.20797.955883.82254@fireball.kivinen.iki.fi> In-Reply-To: <18816.20797.955883.82254@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Bis issue #11: Clarify which traffic selectors to use in 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 Tero Kivinen writes: > > > > It can be done as Tero suggests, as long as the policy hasn't > > changed, and as long as the new initiator is the same as the old > > initiator. But what if the original decorrelated policy is no longer > > valid, but the current SPD cache entry still is? > > If the policy has changed so that old SA is no longer valid (and > cannot be rekeyed because of that), then that is even more reason to > use the new policy and create new SA which is allowed by policy and > delete the old SA which after the reconfigruation would be against the > current policy. I was referring to the case where the old SA is still valid (it is a subset of some (new) SPD entry) but that SPD entry is no longer the same as the old SPD entry that was the basis for the proposal form the original initiator. > If policy is not changed then they should get same narrowing happening > again, meaning they will get new SA with same traffic selectors. If > policy has been changed so it affects the resulting SA, then the new > SA MUST follow new policy and reusing old traffic selectors (which are > against current policy) would be violation of policy. > > > What if the new initiator (formerly the responder) does not have the > > same decorrelated policy? > > If the policies re different in both ends, then it is possible the > traffic selectors will be different depending which end created the > SA. I do not think that really matters. > > > I suggest that the (new) initiator be able to rekey with any traffic > > selectors, as long as they are a superset of the old SA selectors. > > IOW as long as the (new) responder can narrow the selectors down to > > the selectors from the old SA, it should be fine. Here's some > > proposed text for the end of section 1.3.3. > > So you propose that is not necessarely to take traffic selectors > directly from policy, but initiator starting rekey can take any > superset of current traffic selectors, even when it would not be > subset of its own policy? The (new) initiator should, of course, make a proposal based on its (new) policy, but it can only count as a rekey if it is a superset of the existing SA selectors. > That would mean initiator of the rekey could be violating his own > policy, and I do not think we want to allow that. > > > The traffic selectors for traffic to be sent on that SA are specified > > in the TS payloads in the response, which may be a subset of what the > > initiator of the Child SA proposed. When rekeying a Child SA, the > > proposal of the initiator MUST be a superset of the selectors of the > > old SA. > > This would mean that if initiators policy has changed so that some > addresses are no longer acceptable by policy he cannot use rekey to > create new SA with that set of traffic selectors, but he must delete > the old IPsec SA and create new. Yes. > I.e. lets take example: > > Host A has policy of > > local = 192.168.11.0-192.168.11.64 > remote = any > > Host B has policy of > > remote = 192.168.11.1-192.168.11.99 > local = 10.0.0.0 - 10.255.255.255 > > Host A initiates first and proposes traffic selectors: > > TSi = 192.168.11.0-192.168.11.64 > TSr = 0.0.0.0-255.255.255.255 > > Host B narrows them down to: > > reply TSi = 192.168.11.1-192.168.11.64 > reply TSr = 10.0.0.0 - 10.255.255.255 > > Now if host A would start rekey the TSi, TSr, and reply TSi, and TSr > would be exactly same. If Host B starts rekey the traffic selectors > would be: > > TSi = 10.0.0.0 - 10.255.255.255 > TSr = 192.168.11.1-192.168.11.99 > reply TSi = 10.0.0.0 - 10.255.255.255 > reply TSr = 192.168.11.1-192.168.11.64 > > i.e. resulting exactly same traffic selectors.. > > Now if host B is reconfigured with new policy: > > remote = 192.168.11.1-192.168.11.99 > local = 10.10.0.0 - 10.10.255.255 > > With your proposal host B cannot anymore rekey the old SA at all as it > cannot propose the new local IP address range 10.10.0.0 - > 10.10.255.255 as it is not superset of the negotiated traffic > selector 10.0.0.0 - 10.255.255.255. Host A could still rekey as he > could offer remote = any, and host B could then narrow it down to new > smaller range. > > In my proposal both ends could still rekey the old SA with new traffic > selectors. > > Hmm... perhaps the "original policy" word in my text was misleading. I > do not mean the exact policy values the node had when the SA was > created, but that the same policy entry that caused the SA to be > created is looked up and the current policy values are then fetched. > > I.e. get the same SPD entry (or its successor if it has been changed) > and derive traffic selectors from there again. In essence this means > doing policy lookup based on the any packet going to the IPsec SA and > finding the SPD entry that should be used for that packet. I think that SA should have been deleted the moment host B was reconfigured, as it violates host B's policy. In any case it requires a new SA, not a rekey of the old SA. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 28 07:19:40 2009 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 E57343A69D2; Wed, 28 Jan 2009 07:19:40 -0800 (PST) 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 E6FEF3A69D2 for ; Wed, 28 Jan 2009 07:19:39 -0800 (PST) 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 eyBdsA0Vdy-M for ; Wed, 28 Jan 2009 07:19:39 -0800 (PST) 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 185F83A68EF for ; Wed, 28 Jan 2009 07:19:39 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0SFJIZ6020487 for ; Wed, 28 Jan 2009 15:19:19 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n0SFJIFl003401 for ; Wed, 28 Jan 2009 10:19:18 -0500 (EST) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0SFBkYv006137 for ; Wed, 28 Jan 2009 10:11:46 -0500 (EST) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n0SFBhOd006136 for ipsec@ietf.org; Wed, 28 Jan 2009 10:11:43 -0500 (EST) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Wed, 28 Jan 2009 10:11:43 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20090128151143.GE4754@sun.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036130846B0F9@il-ex01.ad.checkpoint.com> <18816.20797.955883.82254@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846B19D@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130846B19D@il-ex01.ad.checkpoint.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] Bis issue #11: Clarify which traffic selectors to use in 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 On Wed, Jan 28, 2009 at 04:43:44PM +0200, Yoav Nir wrote: > > I.e. get the same SPD entry (or its successor if it has been changed) > > and derive traffic selectors from there again. In essence this means > > doing policy lookup based on the any packet going to the IPsec SA and > > finding the SPD entry that should be used for that packet. > > I think that SA should have been deleted the moment host B was > reconfigured, as it violates host B's policy. In any case it requires a > new SA, not a rekey of the old SA. What if the triggering packet is from a connection-latched TCP session? If the SPD gets reconfigured, the connected session still inherits the policy from its creation. I suspect I would, upon rekey, send the specific 5-tuple. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 28 08:41:49 2009 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 3BEC13A6A5C; Wed, 28 Jan 2009 08:41:49 -0800 (PST) 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 35E383A6A5C; Wed, 28 Jan 2009 08:41:48 -0800 (PST) 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=[AWL=-0.000, 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 etQVIqeunMbg; Wed, 28 Jan 2009 08:41:47 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id E9B1A3A6925; Wed, 28 Jan 2009 08:41:46 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0SGdPNo023290; Wed, 28 Jan 2009 09:39:25 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0SGfJi3206668; Wed, 28 Jan 2009 09:41:20 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n0SGfIPn014670; Wed, 28 Jan 2009 09:41:18 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n0SGfItk014667; Wed, 28 Jan 2009 09:41:18 -0700 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@il-ex01.ad.checkpoint.com> To: Yaron Sheffer MIME-Version: 1.0 X-KeepSent: 1816C12E:D91214EA-8525754C:00580DCD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/28/2009 11:28:17 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/28/2009 11:28:17 AM, Serialize complete at 01/28/2009 11:28:17 AM, S/MIME Sign failed at 01/28/2009 11:28:17 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 01/28/2009 09:41:17, Serialize complete at 01/28/2009 09:41:17 Message-ID: Date: Wed, 28 Jan 2009 11:41:17 -0500 Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] Bis issue #68: 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: multipart/mixed; boundary="===============1642149684==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1642149684== Content-Type: multipart/alternative; boundary="=_alternative 005A7B278525754C_=" This is a multipart message in MIME format. --=_alternative 005A7B278525754C_= Content-Type: text/plain; charset="US-ASCII" Is it the intention of this text to discourage using the "final ciphertext block of the previous [sent] message" for all modes, including CBC? While the original ikev2bis text was a little ambiguous, it seemed to apply this statement only to "modes other than CBC," whereas this replacement text more clearly applies it to all modes. I expect that many implementations are currently using the final ciphertext block as the next IV for CBC, especially as this practice is required for IKEv1 (IVs are implicit) and sanctioned by RFC 4306 for IKEv2. If this statement is in fact intended to apply to CBC, is there a reference we could cite in justification? [MODES] lists "two recommended methods" for generating an IV, but it does not itself proscribe the use of the final ciphertext block for CBC. In fact, the use of the final ciphertext block is consistent with how CBC operates within a given message. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: IPsecme WG Date: 01/27/2009 06:55 PM Subject: [IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to protect IKE SA Tero: Here is the new version suggested replacement text [to sec. 3.14]: 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. Pasi: Looks good to me! (We also need to update couple sentences earlier in ikev2bis, Section 3.14, to match this, though.) Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 005A7B278525754C_= Content-Type: text/html; charset="US-ASCII"
Is it the intention of this text to discourage using the "final ciphertext block of the previous [sent] message" for all modes, including CBC?  While the original ikev2bis text was a little ambiguous, it seemed to apply this statement only to "modes other than CBC," whereas this replacement text more clearly applies it to all modes.

I expect that many implementations are currently using the final ciphertext block as the next IV for CBC, especially as this practice is required for IKEv1 (IVs are implicit) and sanctioned by RFC 4306 for IKEv2.  If this statement is in fact intended to apply to CBC, is there a reference we could cite in justification?  [MODES] lists "two recommended methods" for generating an IV, but it does not itself proscribe the use of the final ciphertext block for CBC.  In fact, the use of the final ciphertext block is consistent with how CBC operates within a given message.


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


From: Yaron Sheffer <yaronf@checkpoint.com>
To: IPsecme WG <ipsec@ietf.org>
Date: 01/27/2009 06:55 PM
Subject: [IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to protect IKE        SA




Tero:

Here is the new version suggested replacement text [to sec. 3.14]: 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.

Pasi:

Looks good to me! (We also need to update couple sentences earlier in ikev2bis, Section 3.14, to match this, though.)



Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 005A7B278525754C_=-- --===============1642149684== 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 --===============1642149684==-- From ipsec-bounces@ietf.org Wed Jan 28 09:45:32 2009 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 C185E3A6A74; Wed, 28 Jan 2009 09:45:32 -0800 (PST) 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 697B43A6A74; Wed, 28 Jan 2009 09:45:31 -0800 (PST) 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 6i6M3L5gB3yJ; Wed, 28 Jan 2009 09:45:30 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 0B92D3A67DA; Wed, 28 Jan 2009 09:45:29 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0SHh8ok007617; Wed, 28 Jan 2009 10:43:08 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0SHj4E0156506; Wed, 28 Jan 2009 10:45:05 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0SHj48B028315; Wed, 28 Jan 2009 10:45:04 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0SHj4WX028311; Wed, 28 Jan 2009 10:45:04 -0700 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C5@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C5@il-ex01.ad.checkpoint.com> To: Yaron Sheffer MIME-Version: 1.0 X-KeepSent: 3CA4AC10:931309FC-8525754C:0060CCFE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/28/2009 12:39:24 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/28/2009 12:39:24 PM, Serialize complete at 01/28/2009 12:39:24 PM, S/MIME Sign failed at 01/28/2009 12:39:24 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 01/28/2009 10:45:04, Serialize complete at 01/28/2009 10:45:04 Message-ID: Date: Wed, 28 Jan 2009 12:45:03 -0500 Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!) 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="===============1357443982==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1357443982== Content-Type: multipart/alternative; boundary="=_alternative 0060FDF48525754C_=" This is a multipart message in MIME format. --=_alternative 0060FDF48525754C_= Content-Type: text/plain; charset="US-ASCII" I am comfortable saying that you SHOULD send the payloads in the indicated order and MUST accept them in any order (except where the order implies meaning, as with CERT and CERTREQ). Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: IPsecme WG Date: 01/27/2009 10:13 PM Subject: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!) Current text: NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the order shown in the figures in Section 2? Can we eliminate the requirement in the following paragraph? If not, we will probably have to add a new appendix with the order, but there is no reason to do that if no one actually cares. {{ Remove this paragraph before the document is finalized, of course. }} Tero: Our implementation do not care about the order of the payloads except in some specific places (CERT payloads and so on). Paul: Not done. We still need to hear from others. Current text (sec. 2.5): {{ Demoted the SHOULD in the second clause }}Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations MUST send the payloads defined in this specification in the order shown in the figures in Section 2; implementations are explicitly allowed to reject as invalid a message with those payloads in any other order. Tero: I would really like to change this to say that payloads must be accepted in any order, but implementations should try to send them out in the order shown in the figures. Exceptions to this is the CERT payloads (the end entity cert MUST be first), and REKEY and COOKIE notifies. Paul: Not done. This is interesting, but should be discussed on the list. Yaron: this really is a major protocol change, we cannot guarantee that no existing implementation cares about payload order. I suggest to leave the protocol as-is, although nobody likes this constraint. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0060FDF48525754C_= Content-Type: text/html; charset="US-ASCII"
I am comfortable saying that you SHOULD send the payloads in the indicated order and MUST accept them in any order (except where the order implies meaning, as with CERT and CERTREQ).


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


From: Yaron Sheffer <yaronf@checkpoint.com>
To: IPsecme WG <ipsec@ietf.org>
Date: 01/27/2009 10:13 PM
Subject: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!)




Current text:

NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the order shown in the figures in Section 2? Can we eliminate the requirement in the following paragraph? If not, we will probably have to add a new appendix with the order, but there is no reason to do that if no one actually cares. {{ Remove this paragraph before the document is finalized, of course. }}

Tero: Our implementation do not care about the order of the payloads except in some specific places (CERT payloads and so on).

Paul: Not done. We still need to hear from others.
Current text (sec. 2.5):

{{ Demoted the SHOULD in the second clause }}Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations MUST send the payloads defined in this specification in the order shown in the figures in Section 2; implementations are explicitly allowed to reject as invalid a message with those payloads in any other order.

Tero: I would really like to change this to say that payloads must be accepted in any order, but implementations should try to send them out in the order shown in the figures. Exceptions to this is the CERT payloads (the end entity cert MUST be first), and REKEY and COOKIE notifies.

Paul: Not done. This is interesting, but should be discussed on the list.
Yaron: this really is a major protocol change, we cannot guarantee that no existing implementation cares about payload order. I suggest to leave the protocol as-is, although nobody likes this constraint.



Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 0060FDF48525754C_=-- --===============1357443982== 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 --===============1357443982==-- From ipsec-bounces@ietf.org Wed Jan 28 11:44:20 2009 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 CDEC53A6988; Wed, 28 Jan 2009 11:44:20 -0800 (PST) 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 61E5F3A693C; Wed, 28 Jan 2009 11:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 UqpxlNqHdEFn; Wed, 28 Jan 2009 11:44:18 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0A9E63A67DF; Wed, 28 Jan 2009 11:44:17 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4F9A329C004; Wed, 28 Jan 2009 21:43:58 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2FB5529C002; Wed, 28 Jan 2009 21:43:57 +0200 (IST) X-CheckPoint: {4980B2C7-10003-88241DC2-7B6} 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 n0SJhu5f018043; Wed, 28 Jan 2009 21:43: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, 28 Jan 2009 21:43:56 +0200 From: Yaron Sheffer To: Scott C Moonen Date: Wed, 28 Jan 2009 21:43:50 +0200 Thread-Topic: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!) Thread-Index: AcmBcCw8s1Z6bsG6RvKMlWVJuCsHpQAEDjLQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F50D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C5@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IPsecme WG , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!) 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="===============1080575629==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1080575629== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F50Dilex01adcheck_" --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F50Dilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Except that your proposal would make existing implementations (that assume = a specific payload order as a responder) noncompliant. Yaron ________________________________ From: Scott C Moonen [mailto:smoonen@us.ibm.com] Sent: Wednesday, January 28, 2009 19:45 To: Yaron Sheffer Cc: IPsecme WG; ipsec-bounces@ietf.org Subject: Re: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here'= s a controversial one!) I am comfortable saying that you SHOULD send the payloads in the indicated = order and MUST accept them in any order (except where the order implies mea= ning, as with CERT and CERTREQ). Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: IPsecme WG Date: 01/27/2009 10:13 PM Subject: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controver= sial one!) ________________________________ Current text: NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the order= shown in the figures in Section 2? Can we eliminate the requirement in the= following paragraph? If not, we will probably have to add a new appendix w= ith the order, but there is no reason to do that if no one actually cares. = {{ Remove this paragraph before the document is finalized, of course. }} Tero: Our implementation do not care about the order of the payloads except= in some specific places (CERT payloads and so on). Paul: Not done. We still need to hear from others. Current text (sec. 2.5): {{ Demoted the SHOULD in the second clause }}Although new payload types may= be added in the future and may appear interleaved with the fields defined = in this specification, implementations MUST send the payloads defined in th= is specification in the order shown in the figures in Section 2; implementa= tions are explicitly allowed to reject as invalid a message with those payl= oads in any other order. Tero: I would really like to change this to say that payloads must be accep= ted in any order, but implementations should try to send them out in the or= der shown in the figures. Exceptions to this is the CERT payloads (the end = entity cert MUST be first), and REKEY and COOKIE notifies. Paul: Not done. This is interesting, but should be discussed on the list. Yaron: this really is a major protocol change, we cannot guarantee that no = existing implementation cares about payload order. I suggest to leave the p= rotocol as-is, although nobody likes this constraint. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F50Dilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Except that your proposal would make existing implementations (that assume a specific payload order as a respond= er) noncompliant.

 

      &n= bsp;     Yaron

 

From: Scott C Moonen [mailto:smoonen@us.ibm.com] Sent: Wednesday, January 28,= 2009 19:45
To: Yaron Sheffer
Cc: IPsecme WG; ipsec-bounces@ietf.org
Subject: Re: [IPsec] Bis iss= ues 16 and 45: order of IKE payloads (now here's a controversial one!)

 


I am comfortable saying that you SHOULD send the payloads in the indicated order and MUST accept them in any order (except w= here the order implies meaning, as with CERT and CERTREQ).


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

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>From:

Yaron Sheffer <yaronf@checkpoint.com>

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>To:=

IPsecme WG <ipsec@ietf.org>

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>Date:

01/27/2009 10:13 PM

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>Subject:

[IPsec] Bis issues 16 and 45: order of IKE payloa= ds (now here's a controversial one!)

 




Current text:

NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the order shown i= n the figures in Section 2? Can we eliminate the requirement in the following paragraph? If not, we will probably have to add a new appendix with the ord= er, but there is no reason to do that if no one actually cares. {{ Remove this paragraph before the document is finalized, of course. }}

Tero: Our implementation do not care about the order of the payloads except in some specific places (CERT payloads and so on).

Paul: Not done. We still need to hear from others.
Current text (sec. 2.5):

{{ Demoted the SHOULD in the second clause }}Although new payload types may be added in the future and may appear interleaved with the fields defined in t= his specification, implementations MUST send the payloads defined in this specification in the order shown in the figures in Section 2; implementatio= ns are explicitly allowed to reject as invalid a message with those payloads i= n any other order.

Tero: I would really like to change this to say that payloads must be accepted in a= ny order, but implementations should try to send them out in the order shown i= n the figures. Exceptions to this is the CERT payloads (the end entity cert M= UST be first), and REKEY and COOKIE notifies.

Paul: Not done. This is interesting, but should be discussed on the list.
Yaron: t= his really is a major protocol c= hange, we cannot guarantee that no existing implementation cares about payload ord= er. I suggest to leave the protocol as-is, although nobody likes this constrain= t.



Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec@ietf.org
<= font size=3D2 face=3D"Courier New">https://www.= ietf.org/mailman/listinfo/ipsec


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F50Dilex01adcheck_-- --===============1080575629== 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 --===============1080575629==-- From ipsec-bounces@ietf.org Wed Jan 28 12:06:52 2009 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 D64CB3A6960; Wed, 28 Jan 2009 12:06:52 -0800 (PST) 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 7694A3A6960; Wed, 28 Jan 2009 12:06:52 -0800 (PST) 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=[AWL=0.000, 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 A5P8rS4MNOOq; Wed, 28 Jan 2009 12:06:51 -0800 (PST) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 918583A6956; Wed, 28 Jan 2009 12:06:51 -0800 (PST) Received: by machshav.com (Postfix, from userid 512) id 46C7A3298C5; Wed, 28 Jan 2009 15:06:29 -0500 (EST) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E8C573298BF; Wed, 28 Jan 2009 15:06:27 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 430D5296375; Wed, 28 Jan 2009 11:52:48 -0500 (EST) Date: Wed, 28 Jan 2009 11:52:47 -0500 From: "Steven M. Bellovin" To: Scott C Moonen Message-ID: <20090128115247.70ecf395@cs.columbia.edu> In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@il-ex01.ad.checkpoint.com> Organization: Columbia University X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64--netbsd) Mime-Version: 1.0 Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] Bis issue #68: 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 On Wed, 28 Jan 2009 11:41:17 -0500 Scott C Moonen wrote: > [MODES] lists "two > recommended methods" for generating an IV, but it does not itself > proscribe the use of the final ciphertext block for CBC. In fact, > the use of the final ciphertext block is consistent with how CBC > operates within a given message. > There are attacks on CBC if you can predict the previous block of ciphertext -- or, of course, the IV. They don't apply within a single message, but when you use the last block as the IV for the next packet the enemy has time to play. (All this came up on the mailing list a few years ago, though it would take me a while to dig up the messages.) --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 28 12:36:43 2009 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 5A72F3A6B54; Wed, 28 Jan 2009 12:36:43 -0800 (PST) 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 61BAC3A6B61; Wed, 28 Jan 2009 12:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-2.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 esPVmAFC8po2; Wed, 28 Jan 2009 12:36:40 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id B4F8B3A6A80; Wed, 28 Jan 2009 12:36:39 -0800 (PST) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e8.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0SKTwww007160; Wed, 28 Jan 2009 15:29:58 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0SKa8Uf954402; Wed, 28 Jan 2009 15:36:13 -0500 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0SKZnJE005660; Wed, 28 Jan 2009 13:35:50 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0SKZnjo005644; Wed, 28 Jan 2009 13:35:49 -0700 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F50D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C5@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F50D@il-ex01.ad.checkpoint.com> To: Yaron Sheffer MIME-Version: 1.0 X-KeepSent: A667D6B4:1D3B1ED0-8525754C:006F96F6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/28/2009 03:22:41 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/28/2009 03:22:41 PM, Serialize complete at 01/28/2009 03:22:41 PM, S/MIME Sign failed at 01/28/2009 03:22:41 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 01/28/2009 13:35:49, Serialize complete at 01/28/2009 13:35:49 Message-ID: Date: Wed, 28 Jan 2009 15:35:48 -0500 Cc: IPsecme WG , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!) 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="===============1679486007==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1679486007== Content-Type: multipart/alternative; boundary="=_alternative 006FF0BB8525754C_=" This is a multipart message in MIME format. --=_alternative 006FF0BB8525754C_= Content-Type: text/plain; charset="US-ASCII" Certainly -- sorry, to clarify, I'm not advocating it, just stepping up for the roll call and observing that it would not be a hardship for me. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: IPsecme WG , "ipsec-bounces@ietf.org" Date: 01/28/2009 02:44 PM Subject: RE: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!) Except that your proposal would make existing implementations (that assume a specific payload order as a responder) noncompliant. Yaron From: Scott C Moonen [mailto:smoonen@us.ibm.com] Sent: Wednesday, January 28, 2009 19:45 To: Yaron Sheffer Cc: IPsecme WG; ipsec-bounces@ietf.org Subject: Re: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!) I am comfortable saying that you SHOULD send the payloads in the indicated order and MUST accept them in any order (except where the order implies meaning, as with CERT and CERTREQ). Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: IPsecme WG Date: 01/27/2009 10:13 PM Subject: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!) Current text: NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the order shown in the figures in Section 2? Can we eliminate the requirement in the following paragraph? If not, we will probably have to add a new appendix with the order, but there is no reason to do that if no one actually cares. {{ Remove this paragraph before the document is finalized, of course. }} Tero: Our implementation do not care about the order of the payloads except in some specific places (CERT payloads and so on). Paul: Not done. We still need to hear from others. Current text (sec. 2.5): {{ Demoted the SHOULD in the second clause }}Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations MUST send the payloads defined in this specification in the order shown in the figures in Section 2; implementations are explicitly allowed to reject as invalid a message with those payloads in any other order. Tero: I would really like to change this to say that payloads must be accepted in any order, but implementations should try to send them out in the order shown in the figures. Exceptions to this is the CERT payloads (the end entity cert MUST be first), and REKEY and COOKIE notifies. Paul: Not done. This is interesting, but should be discussed on the list. Yaron: this really is a major protocol change, we cannot guarantee that no existing implementation cares about payload order. I suggest to leave the protocol as-is, although nobody likes this constraint. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Email secured by Check Point --=_alternative 006FF0BB8525754C_= Content-Type: text/html; charset="US-ASCII"
Certainly -- sorry, to clarify, I'm not advocating it, just stepping up for the roll call and observing that it would not be a hardship for me.

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


From: Yaron Sheffer <yaronf@checkpoint.com>
To: Scott C Moonen/Raleigh/IBM@IBMUS
Cc: IPsecme WG <ipsec@ietf.org>, "ipsec-bounces@ietf.org" <ipsec-bounces@ietf.org>
Date: 01/28/2009 02:44 PM
Subject: RE: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!)




Except that your proposal would make existing implementations (that assume a specific payload order as a responder) noncompliant.
 
            Yaron
 


From: Scott C Moonen [mailto:smoonen@us.ibm.com]
Sent: Wednesday, January 28, 2009 19:45
To: Yaron Sheffer
Cc: IPsecme WG; ipsec-bounces@ietf.org
Subject: Re: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!)
 

I am comfortable saying that you SHOULD send the payloads in the indicated order and MUST accept them in any order (except where the order implies meaning, as with CERT and CERTREQ).


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

From: Yaron Sheffer <yaronf@checkpoint.com>
To: IPsecme WG <ipsec@ietf.org>
Date: 01/27/2009 10:13 PM
Subject: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!)

 






Current text:

NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the order shown in the figures in Section 2? Can we eliminate the requirement in the following paragraph? If not, we will probably have to add a new appendix with the order, but there is no reason to do that if no one actually cares. {{ Remove this paragraph before the document is finalized, of course. }}

Tero: Our implementation do not care about the order of the payloads except in some specific places (CERT payloads and so on).

Paul: Not done. We still need to hear from others.
Current text (sec. 2.5):

{{ Demoted the SHOULD in the second clause }}Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations MUST send the payloads defined in this specification in the order shown in the figures in Section 2; implementations are explicitly allowed to reject as invalid a message with those payloads in any other order.

Tero: I would really like to change this to say that payloads must be accepted in any order, but implementations should try to send them out in the order shown in the figures. Exceptions to this is the CERT payloads (the end entity cert MUST be first), and REKEY and COOKIE notifies.

Paul: Not done. This is interesting, but should be discussed on the list.
Yaron: this really is a major protocol change, we cannot guarantee that no existing implementation cares about payload order. I suggest to leave the protocol as-is, although nobody likes this constraint.



Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



Email secured by Check Point

--=_alternative 006FF0BB8525754C_=-- --===============1679486007== 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 --===============1679486007==-- From marion@airecampingcar.com Wed Jan 28 12:41:37 2009 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 8E30728C10F for ; Wed, 28 Jan 2009 12:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.302 X-Spam-Level: X-Spam-Status: No, score=-11.302 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmlCMsDuqiMs for ; Wed, 28 Jan 2009 12:41:36 -0800 (PST) Received: from 123bingo.com (unknown [200.222.210.88]) by core3.amsl.com (Postfix) with SMTP id 2945128C158 for ; Wed, 28 Jan 2009 12:41:18 -0800 (PST) To: Subject: Great Finds From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090128204121.2945128C158@core3.amsl.com> Date: Wed, 28 Jan 2009 12:41:18 -0800 (PST)

We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.fishstraight.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://fishstraight.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 6, B117. 797 Clements Road. London. SE69 9DG

© 2006-2008 BBCMEDIA, Ltd. All Rights Reserved

From ipsec-bounces@ietf.org Wed Jan 28 12:47:26 2009 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 549213A6B61; Wed, 28 Jan 2009 12:47:26 -0800 (PST) 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 3A5EC3A6A74; Wed, 28 Jan 2009 12:47:25 -0800 (PST) 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 fNTx1RQxUKjM; Wed, 28 Jan 2009 12:47:24 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9AE713A68D0; Wed, 28 Jan 2009 12:47:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,339,1231113600"; d="scan'208";a="35144371" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 28 Jan 2009 20:47:05 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0SKl5Ib012324; Wed, 28 Jan 2009 15:47:05 -0500 Received: from sfluhrerwxp (dhcp-161-44-183-82.cisco.com [161.44.183.82]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n0SKl5Eb017377; Wed, 28 Jan 2009 20:47:05 GMT From: "Scott Fluhrer" To: "'Steven M. Bellovin'" , "'Scott C Moonen'" References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@il-ex01.ad.checkpoint.com> <20090128115247.70ecf395@cs.columbia.edu> Date: Wed, 28 Jan 2009 15:47:04 -0500 Message-ID: <00a101c98189$94290a30$52b72ca1@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcmBg+1gF7DFUWB9ROa4ES5tD/tvKwABNLGQ In-reply-to: <20090128115247.70ecf395@cs.columbia.edu> DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1356; t=1233175625; x=1234039625; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sfluhrer@cisco.com; z=From:=20=22Scott=20Fluhrer=22=20 |Subject:=20RE=3A=20[IPsec]=20Bis=20issue=20#68=3A=20Counte r=20mode=20ciphers=20in=20IKEv2=20to=20protect=20IKE=09SA |Sender:=20 |To:=20=22'Steven=20M.=20Bellovin'=22=20,=0A=20=20=20=20=20=20=20=20=22'Scott=20C=20Moonen'=22=20< smoonen@us.ibm.com>; bh=cUhFuLP0CsmNZin00VGQDdIKaaoVMIOeTf+c+ildR68=; b=RHlM8EeZMcvYE8e8P/7T4c1SsV3h13QcdMI4gKinH/T2xhnsB+BIfKYlYg L38e/37Y08s8xg1H6P8rk57MtsZ/gil4QRbKKhx5Highs2kDyx98T+1JdCOy blD1vZVBGy; Authentication-Results: rtp-dkim-2; header.From=sfluhrer@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: 'IPsecme WG' , ipsec-bounces@ietf.org Subject: Re: [IPsec] Bis issue #68: 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 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Steven M. Bellovin > Sent: Wednesday, January 28, 2009 11:53 AM > To: Scott C Moonen > Cc: IPsecme WG; ipsec-bounces@ietf.org > Subject: Re: [IPsec] Bis issue #68: Counter mode ciphers in > IKEv2 to protect IKE SA > > On Wed, 28 Jan 2009 11:41:17 -0500 > Scott C Moonen wrote: > > > [MODES] lists "two > > recommended methods" for generating an IV, but it does not itself > > proscribe the use of the final ciphertext block for CBC. > In fact, the > > use of the final ciphertext block is consistent with how > CBC operates > > within a given message. > > > > There are attacks on CBC if you can predict the previous > block of ciphertext -- or, of course, the IV. They don't > apply within a single message, but when you use the last > block as the IV for the next packet the enemy has time to > play. (All this came up on the mailing list a few years ago, > though it would take me a while to dig up the messages.) Found it: http://www.sandelman.ottawa.on.ca/ipsec/2002/01/msg00003.html (and following messages in the thread) See also http://www.samivaarala.com/publications/espiv/index.html where they actually performed the attack (in a test setting) -- scott _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 28 13:12:17 2009 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 59FD53A6BD0; Wed, 28 Jan 2009 13:12:17 -0800 (PST) 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 2312F28C10F for ; Wed, 28 Jan 2009 13:12:16 -0800 (PST) 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 N-s1jE1ir40U for ; Wed, 28 Jan 2009 13:12:14 -0800 (PST) Received: from yw-out-1516.google.com (yw-out-1516.google.com [74.125.46.163]) by core3.amsl.com (Postfix) with ESMTP id 773AF3A6BD0 for ; Wed, 28 Jan 2009 13:12:14 -0800 (PST) Received: by yw-out-1516.google.com with SMTP id 7so6030208ywc.4 for ; Wed, 28 Jan 2009 13:11:55 -0800 (PST) MIME-Version: 1.0 In-Reply-To: Received: by 10.90.105.6 with SMTP id d6mr4968646agc.24.1233177115179; Wed, 28 Jan 2009 13:11:55 -0800 (PST) Message-ID: <0016361643a9e5424c0461916b5a@google.com> Date: Wed, 28 Jan 2009 21:11:55 +0000 From: jsun2501@gmail.com To: Scott C Moonen , Yaron Sheffer , IPsecme WG , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!) 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="===============1090408954==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1090408954== Content-Type: multipart/alternative; boundary=0016361643a9e5422d0461916bf4 --0016361643a9e5422d0461916bf4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit All, It seems to me that implementations should be able to handle out of order payloads - and as Scott noted, exceptions being where specific orderings are specified and required. Reason for this - if you don't allow for out of ordering payloads, then you'll probably have to account for all payloads which may not be very scalable due to future feature support. Of course, for backwards compatibility to account for devices that send canned messages, we could specify a base fixed message format and allow for out of order payloads hence forth. But in general, shouldn't ALL devices be able to handle unknown payload types? If so, older devices shouldn't really care where you place one of the newer/unknown type payload in a message. I guess what I am saying is this: if All devices can handle unknown payload types, than out of order packets should not be an issue. - Jeff Sun On Jan 28, 2009 12:35pm, Scott C Moonen wrote: > > Certainly -- sorry, to clarify, I'm > not advocating it, just stepping up for the roll call and observing that > it would not be a hardship for me. > > > > Scott Moonen (smoonen@us.ibm.com) > > z/OS Communications Server TCP/IP Development > > http://scott.andstuff.org/ > > http://www.linkedin.com/in/smoonen > > > > > > > > > From: > Yaron Sheffer yaronf@checkpoint.com> > > To: > Scott C Moonen/Raleigh/IBM@IBMUS > > Cc: > IPsecme WG ipsec@ietf.org>, "ipsec-bounces@ietf.org" > ipsec-bounces@ietf.org> > > Date: > 01/28/2009 02:44 PM > > Subject: > RE: [IPsec] Bis issues 16 and 45: order > of IKE payloads (now here's a controversial one!) > > > > > > > > > Except that your proposal would > make existing implementations (that assume a specific payload order as > a responder) noncompliant. > > > > > Yaron > > > > > > > > > From: Scott C Moonen [mailto:smoonen@us.ibm.com] > > > Sent: Wednesday, January 28, 2009 19:45 > > To: Yaron Sheffer > > Cc: IPsecme WG; ipsec-bounces@ietf.org > > Subject: Re: [IPsec] Bis issues 16 and 45: order of IKE payloads (now > here's a controversial one!) > > > > > > I am comfortable saying that you SHOULD send the payloads in the indicated > order and MUST accept them in any order (except where the order implies > meaning, as with CERT and CERTREQ). > > > > > > > Scott Moonen (smoonen@us.ibm.com) > > z/OS Communications Server TCP/IP Development > > http://scott.andstuff.org/ > > http://www.linkedin.com/in/smoonen > > > > > > > > From: > > Yaron Sheffer yaronf@checkpoint.com> > > > To: > > IPsecme WG ipsec@ietf.org> > > > Date: > > 01/27/2009 10:13 PM > > > Subject: > > [IPsec] Bis issues 16 and 45: order > of IKE payloads (now here's a controversial one!) > > > > > > > > > > > > > > > Current text: > > NOTE TO IMPLEMENTERS: Does anyone > require that the payloads be in the order shown in the figures in Section > 2? Can we eliminate the requirement in the following paragraph? If not, > we will probably have to add a new appendix with the order, but there is > no reason to do that if no one actually cares. {{ Remove this paragraph > before the document is finalized, of course. }} > > Tero: Our implementation do not > care about the order of the payloads except in some specific places (CERT > payloads and so on). > > Paul: Not done. We still need to > hear from others. > > Current text (sec. 2.5): > > {{ Demoted the SHOULD in the second > clause }}Although new payload types may be added in the future and may > appear interleaved with the fields defined in this specification, implementations > MUST send the payloads defined in this specification in the order shown > in the figures in Section 2; implementations are explicitly allowed to > reject as invalid a message with those payloads in any other order. > > Tero: I would really like to change > this to say that payloads must be accepted in any order, but implementations > should try to send them out in the order shown in the figures. Exceptions > to this is the CERT payloads (the end entity cert MUST be first), and REKEY > and COOKIE notifies. > > Paul: Not done. This is interesting, > but should be discussed on the list. > > Yaron: this really is a major protocol change, we cannot guarantee > that no existing implementation cares about payload order. I suggest to > leave the protocol as-is, although nobody likes this constraint. > > > > > > > Email secured by Check Point > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > Email secured by Check Point > > > > > > --0016361643a9e5422d0461916bf4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,
It seems to me that implementations should be able to handle ou= t of order payloads - and as Scott noted, exceptions being where specific o= rderings are specified and required. Reason for this - if you don't al= low for out of ordering payloads, then you'll probably have to account = for all payloads which may not be very scalable due to future feature suppo= rt. Of course, for backwards compatibility to account for devices that sen= d canned messages, we could specify a base fixed message format and allow f= or out of order payloads hence forth. But in general, shouldn't ALL de= vices be able to handle unknown payload types? If so, older devices should= n't really care where you place one of the newer/unknown type payload i= n a message. I guess what I am saying is this: if All devices can handle = unknown payload types, than out of order packets should not be an issue.
- Jeff Sun

On Jan 28, 2009 12:35pm, Scott C Moonen <= smoonen@us.ibm.com> wrote:
>
> Certainly -- sorry, to c= larify, I'm
> not advocating it, just stepping up for the roll = call and observing that
> it would not be a hardship for me.
&= gt;
>
>
> Scott Moonen (smoonen@us.ibm.com)
>
> z/OS Communications Server TCP/IP Development
> > http://scott.andstuff.org/
>
> http://www.linkedi= n.com/in/smoonen
>
>
>
>
>
>
>
>
> From:
> Yaron Sheffer yaron= f@checkpoint.com>
>
> To:
> Scott C Moonen/Rale= igh/IBM@IBMUS
>
> Cc:
> IPsecme WG ipsec@ietf.org&= gt;, "ipsec-bounces@ietf.org"
> ipsec-bounces@ietf.org>= ;
>
> Date:
> 01/28/2009 02:44 PM
>
= > Subject:
> RE: [IPsec] Bis issues 16 and 45: order
> o= f IKE payloads (now here's a controversial one!)
>
> <= br />>
>
>
>
>
>
>= Except that your proposal would
> make existing implementations (t= hat assume a specific payload order as
> a responder) noncompliant.=
>
> =A0
>
> =A0 =A0 =A0 =A0
> = =A0 =A0 Yaron
>
> =A0
>
>
>
>
>
>
> From: Scott C Moonen [mailto:smoone= n@us.ibm.com]
>
>
> Sent: Wednesday, January 28, = 2009 19:45
>
> To: Yaron Sheffer
>
> Cc: = IPsecme WG; ipsec-bounces@ietf.org
>
> Subject: Re: [IPsec= ] Bis issues 16 and 45: order of IKE payloads (now
> here's a c= ontroversial one!)
>
> =A0
>
>
>=
> I am comfortable saying that you SHOULD send the payloads in th= e indicated
> order and MUST accept them in any order (except where= the order implies
> meaning, as with CERT and CERTREQ).
> =
>
>
>
>
>
> Scott Moo= nen (smoonen@us.ibm.com)
>
> z/OS Communications Server TC= P/IP Development
>
> http://scott.andstuff.org/
> =
> http://www.linkedin.com/in/smoonen
>
>
&g= t;
>
>
>
>
> From:
> <= br />> Yaron Sheffer yaronf@checkpoint.com>
>
>
> To:
>
> IPsecme WG ipsec@ietf.org>
> >
> Date:
>
> 01/27/2009 10:13 PM
>=
>
> Subject:
>
> [IPsec] Bis issues 16 = and 45: order
> of IKE payloads (now here's a controversial one= !)
>
> =A0
>
>
>
>
>
>
>
>
>
>
> >
> Current text:
>
> NOTE TO IMPLEMENTER= S: Does anyone
> require that the payloads be in the order shown in= the figures in Section
> 2? Can we eliminate the requirement in th= e following paragraph? If not,
> we will probably have to add a new= appendix with the order, but there is
> no reason to do that if no= one actually cares. {{ Remove this paragraph
> before the document= is finalized, of course. }}
>
> Tero: Our implementation= do not
> care about the order of the payloads except in some speci= fic places (CERT
> payloads and so on).
>
> Paul:= Not done. We still need to
> hear from others.
>
&g= t; Current text (sec. 2.5):
>
> {{ Demoted the SHOULD in = the second
> clause }}Although new payload types may be added in th= e future and may
> appear interleaved with the fields defined in th= is specification, implementations
> MUST send the payloads defined = in this specification in the order shown
> in the figures in Sectio= n 2; implementations are explicitly allowed to
> reject as invalid = a message with those payloads in any other order.
>
> Ter= o: I would really like to change
> this to say that payloads must b= e accepted in any order, but implementations
> should try to send t= hem out in the order shown in the figures. Exceptions
> to this is = the CERT payloads (the end entity cert MUST be first), and REKEY
> = and COOKIE notifies.
>
> Paul: Not done. This is interest= ing,
> but should be discussed on the list.
>
> Y= aron: this really is a major protocol change, we cannot guarantee
>= that no existing implementation cares about payload order. I suggest to> leave the protocol as-is, although nobody likes this constraint.>
>
>
>
>
>
> E= mail secured by Check Point
>
> _________________________= ______________________
>
> IPsec mailing list
> > IPsec@ietf.org
>
> https://www.ietf.org/mailman/l= istinfo/ipsec
>
>
>
>
>
&= gt; Email secured by Check Point
>
>
>
>= ;
>
> --0016361643a9e5422d0461916bf4-- --===============1090408954== 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 --===============1090408954==-- From ipsec-bounces@ietf.org Wed Jan 28 13:48:34 2009 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 A51AD28C180; Wed, 28 Jan 2009 13:48:34 -0800 (PST) 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 0632128C180; Wed, 28 Jan 2009 13:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.154, 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 FZB1RQQIKwiF; Wed, 28 Jan 2009 13:48:32 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id 9E00B28C16C; Wed, 28 Jan 2009 13:48:32 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0SLjGFh032417; Wed, 28 Jan 2009 14:45:16 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0SLmDPW182186; Wed, 28 Jan 2009 14:48:13 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0SLmCgS005057; Wed, 28 Jan 2009 14:48:12 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0SLmCKT005052; Wed, 28 Jan 2009 14:48:12 -0700 In-Reply-To: <00a101c98189$94290a30$52b72ca1@amer.cisco.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@il-ex01.ad.checkpoint.com> <20090128115247.70ecf395@cs.columbia.edu> <00a101c98189$94290a30$52b72ca1@amer.cisco.com> To: "Scott Fluhrer" MIME-Version: 1.0 X-KeepSent: 03A38EDA:A75A645D-8525754C:00762D4E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/28/2009 04:47:49 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/28/2009 04:47:49 PM, Serialize complete at 01/28/2009 04:47:49 PM, S/MIME Sign failed at 01/28/2009 04:47:49 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 01/28/2009 14:48:12, Serialize complete at 01/28/2009 14:48:12 Message-ID: Date: Wed, 28 Jan 2009 16:48:11 -0500 Cc: 'IPsecme WG' , ipsec-bounces@ietf.org, "'Steven M. Bellovin'" Subject: Re: [IPsec] Bis issue #68: 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: multipart/mixed; boundary="===============2099989613==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============2099989613== Content-Type: multipart/alternative; boundary="=_alternative 0077BBFE8525754C_=" This is a multipart message in MIME format. --=_alternative 0077BBFE8525754C_= Content-Type: text/plain; charset="US-ASCII" Scott Fluhrer writes: > Found it: http://www.sandelman.ottawa.on.ca/ipsec/2002/01/msg00003.html (and > following messages in the thread) > > See also http://www.samivaarala.com/publications/espiv/index.html where they > actually performed the attack (in a test setting) Thanks, Scott, that is interesting. IKEv2 is a different story than ESP, however, since there is really very little external influence on the messages exchanged. Assuming that this wording change for IKEv2 is deliberate and is related to these ESP citations, has anyone actually sketched out a hypothetical attack vector for IKEv2? Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: "Scott Fluhrer" To: "'Steven M. Bellovin'" , Scott C Moonen/Raleigh/IBM@IBMUS Cc: "'IPsecme WG'" , Date: 01/28/2009 03:47 PM Subject: RE: [IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to protect IKE SA > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Steven M. Bellovin > Sent: Wednesday, January 28, 2009 11:53 AM > To: Scott C Moonen > Cc: IPsecme WG; ipsec-bounces@ietf.org > Subject: Re: [IPsec] Bis issue #68: Counter mode ciphers in > IKEv2 to protect IKE SA > > On Wed, 28 Jan 2009 11:41:17 -0500 > Scott C Moonen wrote: > > > [MODES] lists "two > > recommended methods" for generating an IV, but it does not itself > > proscribe the use of the final ciphertext block for CBC. > In fact, the > > use of the final ciphertext block is consistent with how > CBC operates > > within a given message. > > > > There are attacks on CBC if you can predict the previous > block of ciphertext -- or, of course, the IV. They don't > apply within a single message, but when you use the last > block as the IV for the next packet the enemy has time to > play. (All this came up on the mailing list a few years ago, > though it would take me a while to dig up the messages.) Found it: http://www.sandelman.ottawa.on.ca/ipsec/2002/01/msg00003.html (and following messages in the thread) See also http://www.samivaarala.com/publications/espiv/index.html where they actually performed the attack (in a test setting) -- scott --=_alternative 0077BBFE8525754C_= Content-Type: text/html; charset="US-ASCII"
Scott Fluhrer writes:
> Found it: http://www.sandelman.ottawa.on.ca/ipsec/2002/01/msg00003.html (and
> following messages in the thread)
>
> See also http://www.samivaarala.com/publications/espiv/index.html where they
> actually performed the attack (in a test setting)

Thanks, Scott, that is interesting.  IKEv2 is a different story than ESP, however, since there is really very little external influence on the messages exchanged.  Assuming that this wording change for IKEv2 is deliberate and is related to these ESP citations, has anyone actually sketched out a hypothetical attack vector for IKEv2?


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


From: "Scott Fluhrer" <sfluhrer@cisco.com>
To: "'Steven M. Bellovin'" <smb@cs.columbia.edu>, Scott C Moonen/Raleigh/IBM@IBMUS
Cc: "'IPsecme WG'" <ipsec@ietf.org>, <ipsec-bounces@ietf.org>
Date: 01/28/2009 03:47 PM
Subject: RE: [IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to protect IKE        SA




 

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]
> On Behalf Of Steven M. Bellovin
> Sent: Wednesday, January 28, 2009 11:53 AM
> To: Scott C Moonen
> Cc: IPsecme WG; ipsec-bounces@ietf.org
> Subject: Re: [IPsec] Bis issue #68: Counter mode ciphers in
> IKEv2 to protect IKE SA
>
> On Wed, 28 Jan 2009 11:41:17 -0500
> Scott C Moonen <smoonen@us.ibm.com> wrote:
>
> > [MODES] lists "two
> > recommended methods" for generating an IV, but it does not itself
> > proscribe the use of the final ciphertext block for CBC.  
> In fact, the
> > use of the final ciphertext block is consistent with how
> CBC operates
> > within a given message.
> >
>
> There are attacks on CBC if you can predict the previous
> block of ciphertext -- or, of course, the IV.  They don't
> apply within a single message, but when you use the last
> block as the IV for the next packet the enemy has time to
> play.  (All this came up on the mailing list a few years ago,
> though it would take me a while to dig up the messages.)

Found it: http://www.sandelman.ottawa.on.ca/ipsec/2002/01/msg00003.html (and
following messages in the thread)

See also http://www.samivaarala.com/publications/espiv/index.html where they
actually performed the attack (in a test setting)

--
scott

--=_alternative 0077BBFE8525754C_=-- --===============2099989613== 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 --===============2099989613==-- From ipsec-bounces@ietf.org Wed Jan 28 13:55:04 2009 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 3AEFB28C1C9; Wed, 28 Jan 2009 13:55:04 -0800 (PST) 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 7389C28C1C1; Wed, 28 Jan 2009 13:55:02 -0800 (PST) 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 x1LC-DBdYhVq; Wed, 28 Jan 2009 13:55:01 -0800 (PST) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 8153E28C1BA; Wed, 28 Jan 2009 13:55:01 -0800 (PST) Received: by machshav.com (Postfix, from userid 512) id 809D332997C; Wed, 28 Jan 2009 16:54:43 -0500 (EST) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ED76E32997A; Wed, 28 Jan 2009 16:54:41 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 5651229629D; Wed, 28 Jan 2009 16:54:34 -0500 (EST) Date: Wed, 28 Jan 2009 16:54:33 -0500 From: "Steven M. Bellovin" To: Scott C Moonen Message-ID: <20090128165433.77946d89@cs.columbia.edu> In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@il-ex01.ad.checkpoint.com> <20090128115247.70ecf395@cs.columbia.edu> <00a101c98189$94290a30$52b72ca1@amer.cisco.com> Organization: Columbia University X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64--netbsd) Mime-Version: 1.0 Cc: 'IPsecme WG' , ipsec-bounces@ietf.org, Scott Fluhrer Subject: Re: [IPsec] Bis issue #68: 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 On Wed, 28 Jan 2009 16:48:11 -0500 Scott C Moonen wrote: > Scott Fluhrer writes: > > Found it: > > http://www.sandelman.ottawa.on.ca/ipsec/2002/01/msg00003.html > (and > > following messages in the thread) > > > > See also http://www.samivaarala.com/publications/espiv/index.html > > where > they > > actually performed the attack (in a test setting) > > Thanks, Scott, that is interesting. IKEv2 is a different story than > ESP, however, since there is really very little external influence on > the messages exchanged. Assuming that this wording change for IKEv2 > is deliberate and is related to these ESP citations, has anyone > actually sketched out a hypothetical attack vector for IKEv2? > I'd rather turn it around. Given that we know there's a weakness in this general area, is there any reason not to avoid it? Is there a real cost to using good IVs? --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 28 19:32:24 2009 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 6F5673A6939; Wed, 28 Jan 2009 19:32:24 -0800 (PST) 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 542043A6939 for ; Wed, 28 Jan 2009 19:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.864 X-Spam-Level: X-Spam-Status: No, score=-1.864 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 mX5T5wcUO6I9 for ; Wed, 28 Jan 2009 19:32:22 -0800 (PST) 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 486903A6872 for ; Wed, 28 Jan 2009 19:32:22 -0800 (PST) Received: from [10.20.30.158] (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 n0T3VeVX084813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jan 2009 20:31:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <002d01c98156$66dba110$c817120a@china.huawei.com> References: <002d01c98156$66dba110$c817120a@china.huawei.com> Date: Wed, 28 Jan 2009 19:31:35 -0800 To: syedah@huawei.com, ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] RFC2409 :Sec 5.2 (Hash of Public-Key or Hash of CERT ?) 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="===============0777002740==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0777002740== Content-Type: text/html; charset="us-ascii" Re: [IPsec] RFC2409 :Sec 5.2 (Hash of Public-Key or Hash
At 8:10 PM +0530 1/28/09, Syed Ajim Hussain wrote:
RFC 2409 : Sec 5.2 :  Phase 1 Authenticated With Public Key Encryption
   "Using public key encryption to authenticate the exchange, the
   ancillary information exchanged is encrypted nonces. Each party's
   ability to reconstruct a hash (proving that the other party decrypted
   the nonce) authenticates the exchange.
   In order to perform the public key encryption, the initiator must
   already have the responder's public key. In the case where the
   responder has multiple public keys, a hash of the certificate the
   initiator is using to encrypt the ancillary information is passed as
   part of the third message. In this way the responder can determine
   which corresponding private key to use to decrypt the encrypted
   payloads and identity protection is retained."
 
Question :   In the case where the peer has multiple public keys, We need to include a Hash payload,
             Now Hash of public key or Hash of Certificate itself ? Many Document/Implementation
             says it is Hash of Public Key , But according  RFC it is Hash of CERT. Can any one please
             Clarify this point?

I think the spec is completely clear here. Can you show documents that says that this section instead means "hash of key"?

--Paul Hoffman, Director
--VPN Consortium
--===============0777002740== 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 --===============0777002740==-- From ipsec-bounces@ietf.org Wed Jan 28 23:10:11 2009 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 984F928C0E0; Wed, 28 Jan 2009 23:10:11 -0800 (PST) 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 7CFBD28C0DE for ; Wed, 28 Jan 2009 23:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=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 hFhzTix2XFuO for ; Wed, 28 Jan 2009 23:10:06 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B2EBE3A67E5 for ; Wed, 28 Jan 2009 23:10:05 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1063C29C004; Thu, 29 Jan 2009 09:09:47 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1BACA29C002 for ; Thu, 29 Jan 2009 09:09:46 +0200 (IST) X-CheckPoint: {49815380-10001-88241DC2-7B6} 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 n0T79j5g013354 for ; Thu, 29 Jan 2009 09: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; Thu, 29 Jan 2009 09:09:44 +0200 From: Yoav Nir To: Yaron Sheffer , IPsecme WG Date: Thu, 29 Jan 2009 09:09:53 +0200 Thread-Topic: Bis issue #19: Motivation for including SPIs in the cookie Thread-Index: AcmAz2pE6oaz3iDHQt6FK1Kl5m5i9QBERGtA Message-ID: <9FB7C7CE79B84449B52622B506C78036130846B221@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C6@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C6@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 Subject: Re: [IPsec] Bis issue #19: Motivation for including SPIs in the cookie 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="===============0593061512==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0593061512== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_9FB7C7CE79B84449B52622B506C78036130846B221ilex01adcheck_" --_000_9FB7C7CE79B84449B52622B506C78036130846B221ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Current text (sec. 2.6): A good way to do this is to set the responder cookie to be: Cookie =3D | Hash(Ni | IPi | SPIi | ) where is a randomly generated secret known only to the responder a= nd periodically changed and | indicates concatenation. = should be changed whenever is regenerated. The cookie can be recom= puted when the IKE_SA_INIT arrives the second time and compared to the cook= ie in the received message. If it matches, the responder knows that the coo= kie was generated since the last change to and that IPi must be th= e same as the source address it saw the first time. Incorporating SPIi into= the calculation ensures that if multiple IKE_SAs are being set up in paral= lel they will all get different cookies (assuming the initiator chooses uni= que SPIi's). Tero: The real reason to hash the SPIs to the cookie is to make sure that attacke= r cannot fetch one cookie from the other end, and then initiate 100 IKE_SA_= INIT exchanges all with different initiator SPIs (and perhaps port numbers)= so that the for the responder it looked like there is lots of machines beh= ind one NAT box who are all trying to connect. As the cookie is tied to the= SPIi the attacker cannot use cookie multiple times. Paul: Not done. This is interesting, but should be discussed on the list. I agree with Tero =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C78036130846B221ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Current text (sec. 2.6):

A good way to do this is to set the responder cookie to be:

Cookie =3D <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

where <secret> is a randomly generated secret known only to the responder a= nd periodically changed and | indicates concatenation. <VersionIDofSecret> should be changed whenever <secret> is regenerated. The cookie can be recompute= d when the IKE_SA_INIT arrives the second time and compared to the cookie in = the received message. If it matches, the responder knows that the cookie was generated since the last change to <secret> and that IPi must be the = same as the source address it saw the first time. Incorporating SPIi into the calculation ensures that if multiple IKE_SAs are being set up in parallel t= hey will all get different cookies (assuming the initiator chooses unique SPIi'= s).

Tero:

The real reason to hash the SPIs to the cookie is to make sure that attacker cannot fetch one cookie from the other end, and then initiate 100 IKE_SA_INIT exchanges all with different initiator SPIs (and perhaps port numbers) so t= hat the for the responder it looked like there is lots of machines behind one N= AT box who are all trying to connect. As the cookie is tied to the SPIi the attacker cannot use cookie multiple times.

Paul: Not done. This is interesting, but should be discussed on the list.

 

 

I agree with Tero


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_9FB7C7CE79B84449B52622B506C78036130846B221ilex01adcheck_-- --===============0593061512== 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 --===============0593061512==-- From ipsec-bounces@ietf.org Wed Jan 28 23:12:50 2009 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 3001B3A684A; Wed, 28 Jan 2009 23:12:50 -0800 (PST) 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 56BF428C0D7 for ; Wed, 28 Jan 2009 23:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.014, 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 3sYagCVkqvBQ for ; Wed, 28 Jan 2009 23:12:48 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1882B3A67E5 for ; Wed, 28 Jan 2009 23:12:48 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A6E1229C004; Thu, 29 Jan 2009 09:12:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B164729C002 for ; Thu, 29 Jan 2009 09:12:28 +0200 (IST) X-CheckPoint: {49815422-10000-88241DC2-7B6} 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 n0T7CS5f013922 for ; Thu, 29 Jan 2009 09:12:28 +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, 29 Jan 2009 09:12:27 +0200 From: Yoav Nir To: Yaron Sheffer , IPsecme WG Date: Thu, 29 Jan 2009 09:12:38 +0200 Thread-Topic: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!) Thread-Index: AcmAzidHMDDzbkzpRY2Z5JpVjgu0WABEp+qw Message-ID: <9FB7C7CE79B84449B52622B506C78036130846B222@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C5@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C5@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 Subject: Re: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a controversial one!) 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="===============0782725651==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0782725651== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_9FB7C7CE79B84449B52622B506C78036130846B222ilex01adcheck_" --_000_9FB7C7CE79B84449B52622B506C78036130846B222ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Wednesday, January 28, 2009 12:50 AM To: IPsecme WG Subject: [IPsec] Bis issues 16 and 45: order of IKE payloads (now here's a = controversial one!) Current text: NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the order= shown in the figures in Section 2? Can we eliminate the requirement in the= following paragraph? If not, we will probably have to add a new appendix w= ith the order, but there is no reason to do that if no one actually cares. = {{ Remove this paragraph before the document is finalized, of course. }} Tero: Our implementation do not care about the order of the payloads except= in some specific places (CERT payloads and so on). Paul: Not done. We still need to hear from others. I may have replied to this before, but our implementation behaves like Tero= 's. We don't even require that all IKE SA payloads precede all Child SA pay= loads in the IKE_AUTH exchange. =0D=0A Email secured by Check Point=0D=0A --_000_9FB7C7CE79B84449B52622B506C78036130846B222ilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer
Sent: Wednesday, January 28,= 2009 12:50 AM
To: IPsecme WG
Subject: [IPsec] Bis issues = 16 and 45: order of IKE payloads (now here's a controversial one!)

 

Current text:

NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the order shown i= n the figures in Section 2? Can we eliminate the requirement in the following paragraph? If not, we will probably have to add a new appendix with the ord= er, but there is no reason to do that if no one actually cares. {{ Remove this paragraph before the document is finalized, of course. }}

Tero: Our implementation do not care about the order of the payloads except in some specific places (CERT payloads and so on).

Paul: Not done. We still need to hear from others.  

 

I may have replied to this before, but= our implementation behaves like Tero's. We don't even require that all IKE SA payloads precede all Child SA payloads in the IKE_AUTH exchange.=


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_9FB7C7CE79B84449B52622B506C78036130846B222ilex01adcheck_-- --===============0782725651== 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 --===============0782725651==-- From ipsec-bounces@ietf.org Wed Jan 28 23:13:50 2009 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 D467528C0EB; Wed, 28 Jan 2009 23:13:50 -0800 (PST) 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 0DDE228C0EB for ; Wed, 28 Jan 2009 23:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 ciMAMAtrVr50 for ; Wed, 28 Jan 2009 23:13:48 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3204628C0D7 for ; Wed, 28 Jan 2009 23:13:48 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C1A6A29C004; Thu, 29 Jan 2009 09:13:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id BBB8A29C002; Thu, 29 Jan 2009 09:13:28 +0200 (IST) X-CheckPoint: {4981545E-10000-88241DC2-7B6} 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 n0T7DS5f014104; Thu, 29 Jan 2009 09:13:28 +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, 29 Jan 2009 09:13:27 +0200 From: Yoav Nir To: Tero Kivinen , Yaron Sheffer Date: Thu, 29 Jan 2009 09:13:38 +0200 Thread-Topic: [IPsec] Bis issue #62: Security considerations - implementation robustness Thread-Index: AcmBQZ45GHzuGPQ6RRa96rEfNR8tjAAn3QqA Message-ID: <9FB7C7CE79B84449B52622B506C78036130846B224@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C8@il-ex01.ad.checkpoint.com> <18816.19328.561690.224974@fireball.kivinen.iki.fi> In-Reply-To: <18816.19328.561690.224974@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Bis issue #62: Security considerations - implementation robustness 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 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen > Sent: Wednesday, January 28, 2009 2:12 PM > To: Yaron Sheffer > Cc: IPsecme WG > Subject: [IPsec] Bis issue #62: Security considerations - implementation robustness > > Yaron Sheffer writes: > > Yaron: > > Additional proposed text for the Security Considerations: > > > > 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 highly 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 issue with the > > potentially unbounded number of messages in EAP-based > > authentication. > > > > [Note: I made minor changes to the text from the version on the issue tracker.] > > I support adding that text to security considerations section. +1 Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jan 28 23:38:45 2009 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 B931A3A69AF; Wed, 28 Jan 2009 23:38:45 -0800 (PST) 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 9C6923A69AF for ; Wed, 28 Jan 2009 23:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=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 OO-J-VnEvquL for ; Wed, 28 Jan 2009 23:38:39 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id EAA683A68D4 for ; Wed, 28 Jan 2009 23:38:38 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9DF1729C004; Thu, 29 Jan 2009 09:38:19 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0C7C029C002 for ; Thu, 29 Jan 2009 09:37:31 +0200 (IST) X-CheckPoint: {49815A01-10000-88241DC2-7B6} 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 n0T7bU5f019450 for ; Thu, 29 Jan 2009 09:37:30 +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, 29 Jan 2009 09:37:30 +0200 From: Yaron Sheffer To: Yoav Nir , IPsecme WG Date: Thu, 29 Jan 2009 09:37:29 +0200 Thread-Topic: Bis issue #19: Motivation for including SPIs in the cookie Thread-Index: AcmAz2pE6oaz3iDHQt6FK1Kl5m5i9QBERGtAAACycaA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F53D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C6@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036130846B221@il-ex01.ad.checkpoint.com> In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130846B221@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 Subject: Re: [IPsec] Bis issue #19: Motivation for including SPIs in the cookie 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="===============0250656388==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0250656388== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F53Dilex01adcheck_" --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F53Dilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First, I would remove "responder knows that the cookie was generated since = the last change to " since the responder can rollover the secret pe= riodically, as explained in the following paragraph. Which version of is used simply doesn't matter. Also, we talking of the initiator's SPI, not "the SPIs". And in principle, = all 100 initiators behind the NAT can use the same SPIi. So an attacker can= very well use the same SPIi repeatedly. Thanks, Yaron ________________________________ From: Yoav Nir Sent: Thursday, January 29, 2009 9:10 To: Yaron Sheffer; IPsecme WG Subject: RE: Bis issue #19: Motivation for including SPIs in the cookie Current text (sec. 2.6): A good way to do this is to set the responder cookie to be: Cookie =3D | Hash(Ni | IPi | SPIi | ) where is a randomly generated secret known only to the responder a= nd periodically changed and | indicates concatenation. = should be changed whenever is regenerated. The cookie can be recom= puted when the IKE_SA_INIT arrives the second time and compared to the cook= ie in the received message. If it matches, the responder knows that the coo= kie was generated since the last change to and that IPi must be th= e same as the source address it saw the first time. Incorporating SPIi into= the calculation ensures that if multiple IKE_SAs are being set up in paral= lel they will all get different cookies (assuming the initiator chooses uni= que SPIi's). Tero: The real reason to hash the SPIs to the cookie is to make sure that attacke= r cannot fetch one cookie from the other end, and then initiate 100 IKE_SA_= INIT exchanges all with different initiator SPIs (and perhaps port numbers)= so that the for the responder it looked like there is lots of machines beh= ind one NAT box who are all trying to connect. As the cookie is tied to the= SPIi the attacker cannot use cookie multiple times. Paul: Not done. This is interesting, but should be discussed on the list. I agree with Tero =0D=0A Email secured by Check Point=0D=0A --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F53Dilex01adcheck_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

First, I would remove “responder knows that the cookie was generated since the last change to <secret>= ” since the responder can rollover the secret periodically, as explained in t= he following paragraph. Which version of <secret> is used simply doesn&#= 8217;t matter.

 

Also, we talking of the initiator̵= 7;s SPI, not “the SPIs”. And in principle, all 100 initiators behin= d the NAT can use the same SPIi. So an attacker can very well use the same SP= Ii repeatedly.

 

Thanks,

      &n= bsp;     Yaron

 

From: Yoav Nir
Sent: Thursday, January 29, = 2009 9:10
To: Yaron Sheffer; IPsecme WG
Subject: RE: Bis issue #19: Motivation for including SPIs in the cookie

 

Current text (sec. 2.6):

A good way to do this is to set the responder cookie to be:

Cookie =3D <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

where <secret> is a randomly generated secret known only to the responder a= nd periodically changed and | indicates concatenation. <VersionIDofSecret&g= t; should be changed whenever <secret> is regenerated. The cookie can be recomputed when the IKE_SA_INIT arrives the second time and compared to the cookie in the received message. If it matches, the responder knows that the cookie was generated since the last change to <secret> and that IPi m= ust be the same as the source address it saw the first time. Incorporating SPIi into the calculation ensures that if multiple IKE_SAs are being set up in parallel they will all get different cookies (assuming the initiator choose= s unique SPIi's).

Tero:

The real reason to hash the SPIs to the cookie is to make sure that attacker cannot fetch one cookie from the other end, and then initiate 100 IKE_SA_INIT exchanges all with different initiator SPIs (and perhaps port numbers) so t= hat the for the responder it looked like there is lots of machines behind one N= AT box who are all trying to connect. As the cookie is tied to the SPIi the attacker cannot use cookie multiple times.

Paul: Not done. This is interesting, but should be discussed on the list.

 

 

I agree with Tero


= =0D=0A
Email secured by Check Point=0D=0A

= --_000_7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F53Dilex01adcheck_-- --===============0250656388== 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 --===============0250656388==-- From ipsec-bounces@ietf.org Thu Jan 29 00:08:33 2009 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 AE2A73A6905; Thu, 29 Jan 2009 00:08:33 -0800 (PST) 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 D0B7F3A6905 for ; Thu, 29 Jan 2009 00:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 KOKylBhTQGlf for ; Thu, 29 Jan 2009 00:08:31 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A98043A689C for ; Thu, 29 Jan 2009 00:08:30 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 18F7729C004; Thu, 29 Jan 2009 10:08:12 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2B47A29C002; Thu, 29 Jan 2009 10:08:11 +0200 (IST) X-CheckPoint: {49816131-10000-88241DC2-7B6} 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 n0T88A5f026797; Thu, 29 Jan 2009 10:08:10 +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, 29 Jan 2009 10:08:09 +0200 From: Yoav Nir To: Dan McDonald , "ipsec@ietf.org" Date: Thu, 29 Jan 2009 10:08:21 +0200 Thread-Topic: [IPsec] Bis issue #11: Clarify which traffic selectors to use in rekeying Thread-Index: AcmBW91G+QOaRuchRgirT48E7J9/8wAh9Emg Message-ID: <9FB7C7CE79B84449B52622B506C78036130846B235@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036130846B0F9@il-ex01.ad.checkpoint.com> <18816.20797.955883.82254@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846B19D@il-ex01.ad.checkpoint.com> <20090128151143.GE4754@sun.com> In-Reply-To: <20090128151143.GE4754@sun.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] Bis issue #11: Clarify which traffic selectors to use in 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 Dan McDonald wrote: > > On Wed, Jan 28, 2009 at 04:43:44PM +0200, Yoav Nir wrote: > > > > I.e. get the same SPD entry (or its successor if it has been changed) > > > and derive traffic selectors from there again. In essence this means > > > doing policy lookup based on the any packet going to the IPsec SA and > > > finding the SPD entry that should be used for that packet. > > > > I think that SA should have been deleted the moment host B was > > reconfigured, as it violates host B's policy. In any case it requires a > > new SA, not a rekey of the old SA. > > What if the triggering packet is from a connection-latched TCP session? If > the SPD gets reconfigured, the connected session still inherits the policy > from its creation. I suspect I would, upon rekey, send the specific 5-tuple. > I don't understand this scenario. If the policy changed for this connection from PROTECT to DROP, do you keep the connection? If it remained PROTECT for this connection, but the SA covers 5-tuples that should now be DROPped, it's a tougher question. IMO the SA should be deleted, not rekeyed, and a new SA created. If for a particular implementation this causes a TCP connection to break rather than just get a minor delay while the next packet triggers a new Child SA creation, then that is a limitation of that particular implementation. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 29 00:20:43 2009 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 6F8233A6C3F; Thu, 29 Jan 2009 00:20:43 -0800 (PST) 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 052383A6C3F; Thu, 29 Jan 2009 00:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.014, 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 3pzddNfSiRr3; Thu, 29 Jan 2009 00:20:41 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C79493A6C3E; Thu, 29 Jan 2009 00:20:40 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id F356929C004; Thu, 29 Jan 2009 10:20:21 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1748529C002; Thu, 29 Jan 2009 10:19:38 +0200 (IST) X-CheckPoint: {498163DF-10003-88241DC2-7B6} 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 n0T8Jb5f029773; Thu, 29 Jan 2009 10:19:37 +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, 29 Jan 2009 10:19:36 +0200 From: Yoav Nir To: "Steven M. Bellovin" , Scott C Moonen Date: Thu, 29 Jan 2009 10:19:47 +0200 Thread-Topic: [IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to protect IKE SA Thread-Index: AcmBkwvNy2/93Bq5TLGJyYPBfmpclwAVqkUQ Message-ID: <9FB7C7CE79B84449B52622B506C78036130846B23A@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@il-ex01.ad.checkpoint.com> <20090128115247.70ecf395@cs.columbia.edu> <00a101c98189$94290a30$52b72ca1@amer.cisco.com> <20090128165433.77946d89@cs.columbia.edu> In-Reply-To: <20090128165433.77946d89@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: 'IPsecme WG' , "ipsec-bounces@ietf.org" , Scott Fluhrer Subject: Re: [IPsec] Bis issue #68: 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 Steven M. Bellovin wrote: > > On Wed, 28 Jan 2009 16:48:11 -0500 > Scott C Moonen wrote: > > > Scott Fluhrer writes: > > > Found it: > > > http://www.sandelman.ottawa.on.ca/ipsec/2002/01/msg00003.html > > (and > > > following messages in the thread) > > > > > > See also http://www.samivaarala.com/publications/espiv/index.html > > > where > > they > > > actually performed the attack (in a test setting) > > > > Thanks, Scott, that is interesting. IKEv2 is a different story than > > ESP, however, since there is really very little external influence on > > the messages exchanged. Assuming that this wording change for IKEv2 > > is deliberate and is related to these ESP citations, has anyone > > actually sketched out a hypothetical attack vector for IKEv2? > > > I'd rather turn it around. Given that we know there's a weakness in > this general area, is there any reason not to avoid it? Is there a > real cost to using good IVs? There's a tradition of treating random bits as a scarce resource, and requiring as little of them as possible. That's probably because revealing too many random bits on the network may lead to attacks on your PRNG. You could also use a counter for the IV, but then you still get the predictability. I still like the idea of using the PRNG to generate good IVs, but it does have some drawbacks. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From mail@1jian.com Thu Jan 29 00:29:07 2009 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 3FA7828C0F3 for ; Thu, 29 Jan 2009 00:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.179 X-Spam-Level: X-Spam-Status: No, score=-22.179 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsrcwM7Xzjtb for ; Thu, 29 Jan 2009 00:29:06 -0800 (PST) Received: from alfains.com (unknown [88.250.180.213]) by core3.amsl.com (Postfix) with SMTP id 1F7D028C0D7 for ; Thu, 29 Jan 2009 00:29:04 -0800 (PST) To: Subject: Payment Accepted! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090129082905.1F7D028C0D7@core3.amsl.com> Date: Thu, 29 Jan 2009 00:29:04 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.independenceisland.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://independenceisland.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 8, B791. 547 Clements Road. London. SE58 4DG

© 2006-2008 BBCMEDIA, Ltd. All Rights Reserved

From ipsec-bounces@ietf.org Thu Jan 29 05:00:29 2009 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 8C8253A69CE; Thu, 29 Jan 2009 05:00:29 -0800 (PST) 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 427EE3A69CE; Thu, 29 Jan 2009 05:00:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.155 X-Spam-Level: X-Spam-Status: No, score=-6.155 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=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 kZzuE77J1MBe; Thu, 29 Jan 2009 05:00:27 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 007983A6941; Thu, 29 Jan 2009 05:00:26 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0TCx63F024170; Thu, 29 Jan 2009 05:59:06 -0700 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0TD08DN203712; Thu, 29 Jan 2009 06:00:08 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0TD07VS027415; Thu, 29 Jan 2009 06:00:08 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0TD03mK027057; Thu, 29 Jan 2009 06:00:05 -0700 In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130846B221@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C6@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036130846B221@il-ex01.ad.checkpoint.com> To: Yoav Nir MIME-Version: 1.0 X-KeepSent: 91BD0053:221B79A3-8525754D:004734A4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/29/2009 07:59:13 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/29/2009 07:59:13 AM, Serialize complete at 01/29/2009 07:59:13 AM, S/MIME Sign failed at 01/29/2009 07:59:13 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 01/29/2009 06:00:04, Serialize complete at 01/29/2009 06:00:04 Message-ID: Date: Thu, 29 Jan 2009 08:00:01 -0500 Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] Bis issue #19: Motivation for including SPIs in the cookie 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="===============2133090502==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============2133090502== Content-Type: multipart/alternative; boundary="=_alternative 0047573B8525754D_=" This is a multipart message in MIME format. --=_alternative 0047573B8525754D_= Content-Type: text/plain; charset="US-ASCII" > > The real reason to hash the SPIs to the cookie is to make sure that attacker cannot fetch one cookie from the other end . . > I agree with Tero Me too. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yoav Nir To: Yaron Sheffer , IPsecme WG Date: 01/29/2009 02:12 AM Subject: Re: [IPsec] Bis issue #19: Motivation for including SPIs in the cookie Current text (sec. 2.6): A good way to do this is to set the responder cookie to be: Cookie = | Hash(Ni | IPi | SPIi | ) where is a randomly generated secret known only to the responder and periodically changed and | indicates concatenation. should be changed whenever is regenerated. The cookie can be recomputed when the IKE_SA_INIT arrives the second time and compared to the cookie in the received message. If it matches, the responder knows that the cookie was generated since the last change to and that IPi must be the same as the source address it saw the first time. Incorporating SPIi into the calculation ensures that if multiple IKE_SAs are being set up in parallel they will all get different cookies (assuming the initiator chooses unique SPIi's). Tero: The real reason to hash the SPIs to the cookie is to make sure that attacker cannot fetch one cookie from the other end, and then initiate 100 IKE_SA_INIT exchanges all with different initiator SPIs (and perhaps port numbers) so that the for the responder it looked like there is lots of machines behind one NAT box who are all trying to connect. As the cookie is tied to the SPIi the attacker cannot use cookie multiple times. Paul: Not done. This is interesting, but should be discussed on the list. I agree with Tero Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0047573B8525754D_= Content-Type: text/html; charset="US-ASCII"
> > The real reason to hash the SPIs to the cookie is to make sure that attacker cannot fetch one cookie from the other end . .
> I agree with Tero

Me too.


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


From: Yoav Nir <ynir@checkpoint.com>
To: Yaron Sheffer <yaronf@checkpoint.com>, IPsecme WG <ipsec@ietf.org>
Date: 01/29/2009 02:12 AM
Subject: Re: [IPsec] Bis issue #19: Motivation for including SPIs in the        cookie




Current text (sec. 2.6):

A good way to do this is to set the responder cookie to be:

Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

where <secret> is a randomly generated secret known only to the responder and periodically changed and | indicates concatenation. <VersionIDofSecret> should be changed whenever <secret> is regenerated. The cookie can be recomputed when the IKE_SA_INIT arrives the second time and compared to the cookie in the received message. If it matches, the responder knows that the cookie was generated since the last change to <secret> and that IPi must be the same as the source address it saw the first time. Incorporating SPIi into the calculation ensures that if multiple IKE_SAs are being set up in parallel they will all get different cookies (assuming the initiator chooses unique SPIi's).

Tero:

The real reason to hash the SPIs to the cookie is to make sure that attacker cannot fetch one cookie from the other end, and then initiate 100 IKE_SA_INIT exchanges all with different initiator SPIs (and perhaps port numbers) so that the for the responder it looked like there is lots of machines behind one NAT box who are all trying to connect. As the cookie is tied to the SPIi the attacker cannot use cookie multiple times.

Paul: Not done. This is interesting, but should be discussed on the list.
 
 
I agree with Tero



Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 0047573B8525754D_=-- --===============2133090502== 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 --===============2133090502==-- From ipsec-bounces@ietf.org Thu Jan 29 05:20:29 2009 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 C5A703A6A3A; Thu, 29 Jan 2009 05:20:29 -0800 (PST) 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 17A873A6A2D; Thu, 29 Jan 2009 05:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.153, 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 7+Myjp0MK4n3; Thu, 29 Jan 2009 05:20:27 -0800 (PST) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id C77F23A68D4; Thu, 29 Jan 2009 05:20:27 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0TDIjxq009615; Thu, 29 Jan 2009 06:18:45 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0TDK9Rg199436; Thu, 29 Jan 2009 06:20:09 -0700 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 n0TDK8TT013293; Thu, 29 Jan 2009 06:20:09 -0700 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 n0TDK8wb013285; Thu, 29 Jan 2009 06:20:08 -0700 In-Reply-To: <20090128165433.77946d89@cs.columbia.edu> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@il-ex01.ad.checkpoint.com> <20090128115247.70ecf395@cs.columbia.edu> <00a101c98189$94290a30$52b72ca1@amer.cisco.com> <20090128165433.77946d89@cs.columbia.edu> To: "Steven M. Bellovin" MIME-Version: 1.0 X-KeepSent: D6291522:33270937-8525754D:0046849C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/29/2009 08:08:08 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 01/29/2009 08:08:08 AM, Serialize complete at 01/29/2009 08:08:08 AM, S/MIME Sign failed at 01/29/2009 08:08:08 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 01/29/2009 06:20:08, Serialize complete at 01/29/2009 06:20:08 Message-ID: Date: Thu, 29 Jan 2009 08:20:07 -0500 Cc: 'IPsecme WG' , ipsec-bounces@ietf.org, Scott Fluhrer Subject: Re: [IPsec] Bis issue #68: 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: multipart/mixed; boundary="===============0660219082==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0660219082== Content-Type: multipart/alternative; boundary="=_alternative 004828108525754D_=" This is a multipart message in MIME format. --=_alternative 004828108525754D_= Content-Type: text/plain; charset="US-ASCII" Steven Bellovin writes: > I'd rather turn it around. Given that we know there's a weakness in > this general area, is there any reason not to avoid it? Is there a > real cost to using good IVs? Inertia is the reason I'm thinking of. I agree with your sentiment in principle, but the draft doesn't exist in a vacuum. I suspect many implementations took the easy route and did it the way they were used to doing it in IKEv1, and which RFC 4306 explicitly allowed for IKEv2. These implementations are non-compliant with the draft's MUST out of the starting gate. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: "Steven M. Bellovin" To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: "Scott Fluhrer" , "'IPsecme WG'" , ipsec-bounces@ietf.org Date: 01/28/2009 04:54 PM Subject: Re: [IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to protect IKE SA On Wed, 28 Jan 2009 16:48:11 -0500 Scott C Moonen wrote: > Scott Fluhrer writes: > > Found it: > > http://www.sandelman.ottawa.on.ca/ipsec/2002/01/msg00003.html > (and > > following messages in the thread) > > > > See also http://www.samivaarala.com/publications/espiv/index.html > > where > they > > actually performed the attack (in a test setting) > > Thanks, Scott, that is interesting. IKEv2 is a different story than > ESP, however, since there is really very little external influence on > the messages exchanged. Assuming that this wording change for IKEv2 > is deliberate and is related to these ESP citations, has anyone > actually sketched out a hypothetical attack vector for IKEv2? > I'd rather turn it around. Given that we know there's a weakness in this general area, is there any reason not to avoid it? Is there a real cost to using good IVs? --Steve Bellovin, http://www.cs.columbia.edu/~smb --=_alternative 004828108525754D_= Content-Type: text/html; charset="US-ASCII"
Steven Bellovin writes:
> I'd rather turn it around.  Given that we know there's a weakness in
> this general area, is there any reason not to avoid it?  Is there a
> real cost to using good IVs?

Inertia is the reason I'm thinking of.  I agree with your sentiment in principle, but the draft doesn't exist in a vacuum.  I suspect many implementations took the easy route and did it the way they were used to doing it in IKEv1, and which RFC 4306 explicitly allowed for IKEv2.  These implementations are non-compliant with the draft's MUST out of the starting gate.


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


From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: Scott C Moonen/Raleigh/IBM@IBMUS
Cc: "Scott Fluhrer" <sfluhrer@cisco.com>, "'IPsecme WG'" <ipsec@ietf.org>, ipsec-bounces@ietf.org
Date: 01/28/2009 04:54 PM
Subject: Re: [IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to protect IKE        SA




On Wed, 28 Jan 2009 16:48:11 -0500
Scott C Moonen <smoonen@us.ibm.com> wrote:

> Scott Fluhrer writes:
> > Found it:
> > http://www.sandelman.ottawa.on.ca/ipsec/2002/01/msg00003.html
> (and
> > following messages in the thread)
> >
> > See also http://www.samivaarala.com/publications/espiv/index.html
> > where
> they
> > actually performed the attack (in a test setting)
>
> Thanks, Scott, that is interesting.  IKEv2 is a different story than
> ESP, however, since there is really very little external influence on
> the messages exchanged.  Assuming that this wording change for IKEv2
> is deliberate and is related to these ESP citations, has anyone
> actually sketched out a hypothetical attack vector for IKEv2?
>
I'd rather turn it around.  Given that we know there's a weakness in
this general area, is there any reason not to avoid it?  Is there a
real cost to using good IVs?


                                 --Steve Bellovin, http://www.cs.columbia.edu/~smb

--=_alternative 004828108525754D_=-- --===============0660219082== 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 --===============0660219082==-- From ipsec-bounces@ietf.org Thu Jan 29 06:00:09 2009 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 E2FA73A6AA6; Thu, 29 Jan 2009 06:00:09 -0800 (PST) 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 1808F3A6AA7 for ; Thu, 29 Jan 2009 06:00:08 -0800 (PST) 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 421A1z3rXwO0 for ; Thu, 29 Jan 2009 06:00:07 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 2B6A23A6A71 for ; Thu, 29 Jan 2009 06:00:07 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0TDxmn2016595 for ; Thu, 29 Jan 2009 13:59:48 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n0TDxlIm003346 for ; Thu, 29 Jan 2009 08:59:48 -0500 (EST) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n0TDqFHI008726 for ; Thu, 29 Jan 2009 08:52:15 -0500 (EST) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n0TDqEfP008725 for ipsec@ietf.org; Thu, 29 Jan 2009 08:52:14 -0500 (EST) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Thu, 29 Jan 2009 08:52:14 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20090129135214.GF7250@sun.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036130846B0F9@il-ex01.ad.checkpoint.com> <18816.20797.955883.82254@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846B19D@il-ex01.ad.checkpoint.com> <20090128151143.GE4754@sun.com> <9FB7C7CE79B84449B52622B506C78036130846B235@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130846B235@il-ex01.ad.checkpoint.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] Bis issue #11: Clarify which traffic selectors to use in 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 On Thu, Jan 29, 2009 at 10:08:21AM +0200, Yoav Nir wrote: > > What if the triggering packet is from a connection-latched TCP session? If > > the SPD gets reconfigured, the connected session still inherits the policy > > from its creation. I suspect I would, upon rekey, send the specific 5-tuple. > > > I don't understand this scenario. If the policy changed for this connection > from PROTECT to DROP, do you keep the connection? That's why it's called connection latching. Once a socket is connect()ed, the specific policy actions stay latched for the connection. > IMO the SA should be deleted, not rekeyed, and a new SA created. If for a > particular implementation this causes a TCP connection to break rather than > just get a minor delay while the next packet triggers a new Child SA > creation, then that is a limitation of that particular implementation. Disallowing a rekey is fine, actually, because a latched connection can narrow any previous SPD entry's selector set to the precise 5-tuple if the SPD no longer covers the latched connection's 5-tuple. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 29 06:24:25 2009 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 B3ED53A6AA4; Thu, 29 Jan 2009 06:24:25 -0800 (PST) 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 A9C253A6AA4 for ; Thu, 29 Jan 2009 06:24:24 -0800 (PST) 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 XHKvwRrswR5U for ; Thu, 29 Jan 2009 06:24:23 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7593D3A69DE for ; Thu, 29 Jan 2009 06:24:22 -0800 (PST) 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 n0TENsxw015472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 16:23:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0TENsr0004600; Thu, 29 Jan 2009 16:23:54 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18817.48122.116119.435030@fireball.kivinen.iki.fi> Date: Thu, 29 Jan 2009 16:23:54 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <9FB7C7CE79B84449B52622B506C78036130846B19D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036130846B0F9@il-ex01.ad.checkpoint.com> <18816.20797.955883.82254@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846B19D@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 11 min Cc: IPsecme WG Subject: Re: [IPsec] Bis issue #11: Clarify which traffic selectors to use in 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 Yoav Nir writes: > I think that SA should have been deleted the moment host B was > reconfigured, as it violates host B's policy. In any case it > requires a new SA, not a rekey of the old SA. True, but I think B should also be allowed to rekey it and make it narrower for the old SA, and then delete the old SA. Rekeying allows traffic counters and so on to keep running, and also does not cause packets to be dropped. If the B immediately deletes the old SA and then starts creating new SA when the next triggering packet comes, that will cause cause packets to be dropped. If the B will start creating new SA and only deletes old SA when new one is created, there is no difference in the rekeying case for the policy point of view (the old policy is still allowed during that transition period), but that will reset traffic counters. What is the benefit for disallowing rekeys with narrower traffic selectors? -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 29 06:28:05 2009 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 90D343A6B37; Thu, 29 Jan 2009 06:28:05 -0800 (PST) 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 2477728C134 for ; Thu, 29 Jan 2009 06:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 GZLje0K9ZPFE for ; Thu, 29 Jan 2009 06:27:58 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7CF073A69DE for ; Thu, 29 Jan 2009 06:27:58 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9BA8829C004; Thu, 29 Jan 2009 16:27:39 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id E0D5229C002; Thu, 29 Jan 2009 16:26:51 +0200 (IST) X-CheckPoint: {4981B9EF-10002-88241DC2-7B6} 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 n0TEQp5f009803; Thu, 29 Jan 2009 16:26:51 +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, 29 Jan 2009 16:26:50 +0200 From: Yoav Nir To: Dan McDonald , "ipsec@ietf.org" Date: Thu, 29 Jan 2009 16:27:02 +0200 Thread-Topic: [IPsec] Bis issue #11: Clarify which traffic selectors to use in rekeying Thread-Index: AcmCGewklijz5/yJQAyngqWFdSwUaAAA07Qg Message-ID: <9FB7C7CE79B84449B52622B506C78036130846B2D6@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C3@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036130846B0F9@il-ex01.ad.checkpoint.com> <18816.20797.955883.82254@fireball.kivinen.iki.fi> <9FB7C7CE79B84449B52622B506C78036130846B19D@il-ex01.ad.checkpoint.com> <20090128151143.GE4754@sun.com> <9FB7C7CE79B84449B52622B506C78036130846B235@il-ex01.ad.checkpoint.com> <20090129135214.GF7250@sun.com> In-Reply-To: <20090129135214.GF7250@sun.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] Bis issue #11: Clarify which traffic selectors to use in 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 Dan McDonald wrote: > > > What if the triggering packet is from a connection-latched TCP session? If > > > the SPD gets reconfigured, the connected session still inherits the policy > > > from its creation. I suspect I would, upon rekey, send the specific 5-tuple. > > > > > I don't understand this scenario. If the policy changed for this connection > > from PROTECT to DROP, do you keep the connection? > > That's why it's called connection latching. Once a socket is connect()ed, > the specific policy actions stay latched for the connection. So I guess in that case, you won't want to rekey, because the old SA is no longer acceptable, but you can get a new SA for the that covers only this connection (or all latched connections) > > IMO the SA should be deleted, not rekeyed, and a new SA created. If for a > > particular implementation this causes a TCP connection to break rather than > > just get a minor delay while the next packet triggers a new Child SA > > creation, then that is a limitation of that particular implementation. > > Disallowing a rekey is fine, actually, because a latched connection can > narrow any previous SPD entry's selector set to the precise 5-tuple if the > SPD no longer covers the latched connection's 5-tuple. I agree Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 29 06:40:07 2009 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 7CF3928C1AA; Thu, 29 Jan 2009 06:40:07 -0800 (PST) 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 5874528C1AA; Thu, 29 Jan 2009 06:40:01 -0800 (PST) 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 NM0WluooGeoj; Thu, 29 Jan 2009 06:40:00 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2B9CB28C159; Thu, 29 Jan 2009 06:39:59 -0800 (PST) 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 n0TEdD0p025696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 16:39:13 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0TEdBXl027525; Thu, 29 Jan 2009 16:39:11 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18817.49039.740994.100829@fireball.kivinen.iki.fi> Date: Thu, 29 Jan 2009 16:39:11 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@il-ex01.ad.checkpoint.com> <20090128115247.70ecf395@cs.columbia.edu> <00a101c98189$94290a30$52b72ca1@amer.cisco.com> <20090128165433.77946d89@cs.columbia.edu> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: 'IPsecme WG' , ipsec-bounces@ietf.org, Scott Fluhrer , "Steven M. Bellovin" Subject: Re: [IPsec] Bis issue #68: 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 Scott C Moonen writes: > Steven Bellovin writes: > > I'd rather turn it around. Given that we know there's a weakness in > > this general area, is there any reason not to avoid it? Is there a > > real cost to using good IVs? > > Inertia is the reason I'm thinking of. I agree with your sentiment in > principle, but the draft doesn't exist in a vacuum. I suspect many > implementations took the easy route and did it the way they were used to > doing it in IKEv1, and which RFC 4306 explicitly allowed for IKEv2. These > implementations are non-compliant with the draft's MUST out of the > starting gate. The change is intentional, the original -00 text applied the "new unpredictable IV for every message" for all modes. The #68 changes that to say that unpredictable IV is only needed for CBC mode and for all other modes the document specifying the mode does need to specify the IV format and generation etc. Using final ciphertext block of previous message is dangerous, and I do not want to see us waiting for someone to create attack before we take actions against that. Creating unpredictable IVs isn't too expensive (for example I think you can just take counter and encrypt it with some random key, or just use PRNG), they do not need to be really random, just unpredictable. We are already doing other protocol changes too, so adding new MUST to fix a security hole is something we must do at the same time. Especially as it will not really affect interoperability, as recipients MUST still accept any IVs the other non-complient old versions generated (i.e. the final ciphertext block of previous message). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 29 06:47:57 2009 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 C34443A69F4; Thu, 29 Jan 2009 06:47:57 -0800 (PST) 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 5DD3D28C15A for ; Thu, 29 Jan 2009 06:47:56 -0800 (PST) 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 JdKpANn7eJeC for ; Thu, 29 Jan 2009 06:47:55 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 48AAE3A69B4 for ; Thu, 29 Jan 2009 06:47:55 -0800 (PST) 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 n0TElW18012461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Jan 2009 16:47:32 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0TElWLL028207; Thu, 29 Jan 2009 16:47:32 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18817.49539.998748.85549@fireball.kivinen.iki.fi> Date: Thu, 29 Jan 2009 16:47:31 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F53D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C6@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036130846B221@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F53D@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min Cc: IPsecme WG , Yoav Nir Subject: Re: [IPsec] Bis issue #19: Motivation for including SPIs in the cookie 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 Yaron Sheffer writes: > Also, we talking of the initiator's SPI, not "the SPIs". And in > principle, all 100 initiators behind the NAT can use the same SPIi. > So an attacker can very well use the same SPIi repeatedly. If attacker uses same IP, and same SPIi, then initiator will simply reject those duplicate messages as retransmissions of the previous message, no special handing is done. If attacker uses several different SPIis then unless the cookie contains SPIi then the cookie will match for all SPIis attacker decides to use, and as the SPIi will be different server will process all of the messages. So to get the security right the SPIi needs to be included, but the reason listed in the original text is not really the real reason. It is the effect caused by inclusion of the SPIi to the cookie, not the reason behind it. > where is a randomly generated secret known only to the > responder and periodically changed and | indicates concatenation. > should be changed whenever is > regenerated. The cookie can be recomputed when the IKE_SA_INIT > arrives the second time and compared to the cookie in the received > message. If it matches, the responder knows that the cookie was > generated since the last change to and that IPi must be the > same as the source address it saw the first time. Incorporating SPIi > into the calculation ensures that if multiple IKE_SAs are being set > up in parallel they will all get different cookies (assuming the > initiator chooses unique SPIi's). > > Tero: > > The real reason to hash the SPIs to the cookie is to make sure that > attacker cannot fetch one cookie from the other end, and then > initiate 100 IKE_SA_INIT exchanges all with different initiator SPIs > (and perhaps port numbers) so that the for the responder it looked > like there is lots of machines behind one NAT box who are all trying > to connect. As the cookie is tied to the SPIi the attacker cannot > use cookie multiple times. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 29 07:00:37 2009 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 1332E28C0DE; Thu, 29 Jan 2009 07:00:37 -0800 (PST) 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 6BF6A3A6A22; Thu, 29 Jan 2009 07:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 TKEME2y8l6AG; Thu, 29 Jan 2009 07:00:34 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 38D253A6B55; Thu, 29 Jan 2009 07:00:34 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2330C29C005; Thu, 29 Jan 2009 17:00:15 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 09FD829C002; Thu, 29 Jan 2009 17:00:14 +0200 (IST) X-CheckPoint: {4981C1C1-10002-88241DC2-7B6} 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 n0TF0D5f018912; Thu, 29 Jan 2009 17:00:13 +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, 29 Jan 2009 17:00:12 +0200 From: Yaron Sheffer To: Tero Kivinen , Scott C Moonen Date: Thu, 29 Jan 2009 17:00:10 +0200 Thread-Topic: [IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to protect IKE SA Thread-Index: AcmCH3RQuNWg+PtgRYqNN7sP/BhfhgAAsUeg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F644@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@il-ex01.ad.checkpoint.com> <20090128115247.70ecf395@cs.columbia.edu> <00a101c98189$94290a30$52b72ca1@amer.cisco.com> <20090128165433.77946d89@cs.columbia.edu> <18817.49039.740994.100829@fireball.kivinen.iki.fi> In-Reply-To: <18817.49039.740994.100829@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: 'IPsecme WG' , "ipsec-bounces@ietf.org" , "Steven M. Bellovin" , Scott Fluhrer Subject: Re: [IPsec] Bis issue #68: 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 I agree with Tero. Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Tero Kivinen > Sent: Thursday, January 29, 2009 16:39 > To: Scott C Moonen > Cc: 'IPsecme WG'; ipsec-bounces@ietf.org; Scott Fluhrer; Steven M. > Bellovin > Subject: Re: [IPsec] Bis issue #68: Counter mode ciphers in IKEv2 to > protect IKE SA > > Scott C Moonen writes: > > Steven Bellovin writes: > > > I'd rather turn it around. Given that we know there's a weakness in > > > this general area, is there any reason not to avoid it? Is there a > > > real cost to using good IVs? > > > > Inertia is the reason I'm thinking of. I agree with your sentiment in > > principle, but the draft doesn't exist in a vacuum. I suspect many > > implementations took the easy route and did it the way they were used to > > doing it in IKEv1, and which RFC 4306 explicitly allowed for IKEv2. > These > > implementations are non-compliant with the draft's MUST out of the > > starting gate. > > The change is intentional, the original -00 text applied the "new > unpredictable IV for every message" for all modes. The #68 changes > that to say that unpredictable IV is only needed for CBC mode and for > all other modes the document specifying the mode does need to specify > the IV format and generation etc. > > Using final ciphertext block of previous message is dangerous, and I > do not want to see us waiting for someone to create attack before we > take actions against that. > > Creating unpredictable IVs isn't too expensive (for example I think > you can just take counter and encrypt it with some random key, or just > use PRNG), they do not need to be really random, just unpredictable. > > We are already doing other protocol changes too, so adding new MUST to > fix a security hole is something we must do at the same time. > Especially as it will not really affect interoperability, as > recipients MUST still accept any IVs the other non-complient old > versions generated (i.e. the final ciphertext block of previous > message). > -- > kivinen@iki.fi > _______________________________________________ > 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. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 29 09:47:22 2009 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 256113A6936; Thu, 29 Jan 2009 09:47:22 -0800 (PST) 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 645173A6936; Thu, 29 Jan 2009 09:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 559GsHaXHl6T; Thu, 29 Jan 2009 09:47:20 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id A6F303A689F; Thu, 29 Jan 2009 09:47:20 -0800 (PST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1LSayc-0002PJ-CQ; Thu, 29 Jan 2009 12:46:55 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <18817.49039.740994.100829@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@il-ex01.ad.checkpoint.com> <20090128115247.70ecf395@cs.columbia.edu> <00a101c98189$94290a30$52b72ca1@amer.cisco.com> <20090128165433.77946d89@cs.columbia.edu> <18817.49039.740994.100829@fireball.kivinen.iki.fi> Date: Thu, 29 Jan 2009 11:18:41 -0500 To: Tero Kivinen From: Stephen Kent Cc: 'IPsecme WG' , ipsec-bounces@ietf.org, "Steven M. Bellovin" , Scott Fluhrer Subject: Re: [IPsec] Bis issue #68: 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I agree with Tero here. The cost of generating an IV is relatively small. As he noted, one can use a counter as plaintext input and encrypt that value in block mode to yield an IV. This approach has been vetted for a long time and I believe NIST publications have recommended it. A recipient ought not be confused by this, in the IKEv2 context. Packets may arrive out of order and and thus every packet needs to carry its own IV. It would be inappropriate for a recipient to try to hold onto the last ciphertext block from a prior IKE packet to use it as an IV, given the need for an explicit IV. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 29 11:11:56 2009 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 1DC643A6832; Thu, 29 Jan 2009 11:11:56 -0800 (PST) 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 0D5C23A6832; Thu, 29 Jan 2009 11:11:55 -0800 (PST) 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=[AWL=0.000, 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 ocemMOJ5Tf8X; Thu, 29 Jan 2009 11:11:54 -0800 (PST) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 178C73A682B; Thu, 29 Jan 2009 11:11:54 -0800 (PST) Received: by machshav.com (Postfix, from userid 512) id 6B9A53293BF; Thu, 29 Jan 2009 14:11:31 -0500 (EST) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7CB853293BD; Thu, 29 Jan 2009 14:11:29 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id B02172963EF; Thu, 29 Jan 2009 14:11:25 -0500 (EST) Date: Thu, 29 Jan 2009 14:11:25 -0500 From: "Steven M. Bellovin" To: Stephen Kent Message-ID: <20090129141125.58611b80@cs.columbia.edu> In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@il-ex01.ad.checkpoint.com> <20090128115247.70ecf395@cs.columbia.edu> <00a101c98189$94290a30$52b72ca1@amer.cisco.com> <20090128165433.77946d89@cs.columbia.edu> <18817.49039.740994.100829@fireball.kivinen.iki.fi> Organization: Columbia University X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64--netbsd) Mime-Version: 1.0 Cc: 'IPsecme WG' , ipsec-bounces@ietf.org, Tero Kivinen , Scott Fluhrer Subject: Re: [IPsec] Bis issue #68: 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 On Thu, 29 Jan 2009 11:18:41 -0500 Stephen Kent wrote: > I agree with Tero here. > > The cost of generating an IV is relatively small. As he noted, one > can use a counter as plaintext input and encrypt that value in block > mode to yield an IV. This approach has been vetted for a long time > and I believe NIST publications have recommended it. > Right. Leaving aside the mythology that we need a true-random value for anything (insisting on trying to get one can actually be harmful), all we need here is unpredictability. And the notion that randomness is in short supply dates back a dozen years or so in the IPsec group; technology has changed and we can reexamine it. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jan 29 11:36:48 2009 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 7CE603A6872; Thu, 29 Jan 2009 11:36:48 -0800 (PST) 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 4B43C3A6872; Thu, 29 Jan 2009 11:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.013, 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 D0kUTBU9WSFD; Thu, 29 Jan 2009 11:36:46 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 9FFBA3A683D; Thu, 29 Jan 2009 11:36:46 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9D58C3E0156; Thu, 29 Jan 2009 11:36:27 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 29 Jan 2009 11:36:27 -0800 (PST) Message-ID: <1596ddaac431a2b7c4e79f99feb786fe.squirrel@www.trepanning.net> In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E66F3C9@il-ex01.ad.checkpoint.com> <20090128115247.70ecf395@cs.columbia.edu> <00a101c98189$94290a30$52b72ca1@amer.cisco.com> <20090128165433.77946d89@cs.columbia.edu> Date: Thu, 29 Jan 2009 11:36:27 -0800 (PST) From: "Dan Harkins" To: "Scott C Moonen" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: 'IPsecme WG' , ipsec-bounces@ietf.org, Scott Fluhrer , "Steven M. Bellovin" Subject: Re: [IPsec] Bis issue #68: 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 Hi Scott, On Thu, January 29, 2009 5:20 am, Scott C Moonen wrote: > Steven Bellovin writes: >> I'd rather turn it around. Given that we know there's a weakness in >> this general area, is there any reason not to avoid it? Is there a >> real cost to using good IVs? > > Inertia is the reason I'm thinking of. I agree with your sentiment in > principle, but the draft doesn't exist in a vacuum. I suspect many > implementations took the easy route and did it the way they were used to > doing it in IKEv1, and which RFC 4306 explicitly allowed for IKEv2. These > implementations are non-compliant with the draft's MUST out of the > starting gate. But that's all goodness. It will force implementations to do the Right Thing. All that's needed is a random function. Something whose output is indistinguishable from random, even given knowledge of the input. A truncated hash is a candidate (see Bellare and Rogaway's "Random Oracles are Practical: A Paradigm for Designing Efficient Protocols" for a good discussion). A PRNG can get a seed that is repeatedly hashed with a counter, and the hash output is truncated to create the IV. Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 30 00:46:21 2009 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 0C5423A68CF; Fri, 30 Jan 2009 00:46:21 -0800 (PST) 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 127B03A68CF for ; Fri, 30 Jan 2009 00:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.352, 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 SR2N3wMhftpf for ; Fri, 30 Jan 2009 00:46:19 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id 98BEE3A6800 for ; Fri, 30 Jan 2009 00:46:18 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so257051fga.41 for ; Fri, 30 Jan 2009 00:45:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=jHndP9+aKTMAwxiZsARazGA8wK9fX/NY785WCR7wshQ=; b=NfoTR+8b+tAORt60h0JldlI6Hlu2bAbHb++tnxSJiqeytAADrZ8O6ZxEYe3V+O6of5 fcSTArSjHzg30HKMfrNnledbLWD1awpK58c0fr9H0Bxo8c41m5wkQixFQCfC7M8jgNgM +Fp7TYQZ07XPSlEJtV8/MrvSeh8slSU6kq3to= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=A2uTit7ozPuACC+wjw7d8UbvHGAOluC/NQmStyCPRPTgwexoGHINNB+bylsJsKR63l NwdGz0H9OXnslAcJU0xHremkPGK3bqNeF7Hw2xKM9Xxn5WMtLaztFrahX+PYZLxlVmlT /vXEXf5zq9xogi+/fuypN8TLOy0pSnb5c0PJE= MIME-Version: 1.0 Received: by 10.223.116.77 with SMTP id l13mr795697faq.106.1233305158216; Fri, 30 Jan 2009 00:45:58 -0800 (PST) In-Reply-To: <99043b4a0901300044y383fffcmb3066924e32bd3f3@mail.gmail.com> References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD42@FIESEXC015.nsn-intra.net> <9FB7C7CE79B84449B52622B506C78036130846AE97@il-ex01.ad.checkpoint.com> <99043b4a0901300044y383fffcmb3066924e32bd3f3@mail.gmail.com> Date: Fri, 30 Jan 2009 09:45:58 +0100 Message-ID: <99043b4a0901300045k2425d0b8r6130371912f86e3c@mail.gmail.com> From: Matthew Cini Sarreo To: ipsec@ietf.org Subject: Re: [IPsec] Ticket #74: Extend IKE_SA_INIT instead of new exchange type 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="===============1323855945==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1323855945== Content-Type: multipart/alternative; boundary=001636c5afb6daeab50461af3be7 --001636c5afb6daeab50461af3be7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think that adding a new exchange would be better. This would allow an implementation to just use a resumption exchange, and not use IKE_SA_INIT and decide if it is to be used to create a new SA or for reconnection purposes .This will require far more lines of code as it was previously stated, but I feel that this would be similar in structure to existing exchanges (how the code is written to implement their functionality) and would be simple. This way, implementers will "just" have to add a new exchange to their existing code and not have to change an existing exchange. I would say that keeping simple exchanges would be beneficial for IKE. Regards, Matthew > > Paul Hoffman said: >> > >> > At 5:30 PM +0200 1/24/09, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> > >Here is a copy-and-paste from the page: >> > >" >> > >Use IKE_SA_INIT with a ticket payload, instead of defining a new >> > >exchange type. >> > > >> > >Main reasons: - Simpler implementation, adding a new exchange requires >> a >> > >lot of new code. - More efficient protocol of the responder *does not* >> > >implement this extension. - Similar to RFC 5077 (TLS stateless >> > >resumption). >> > > >> > >See http://www.ietf.org/mail-archive/web/ipsec/current/msg03356.htmland >> > >follow ups. >> > >" >> > > >> > >I guess we need a few other folks to join the discussion and to state >> > >their opinion. >> > >> > Yes, definitely. At this point, we have heard from two groups of >> authors; >> > hearing from the wider implementers community would be valuable. >> >> IMO it's six of one, half a dozen of another. The choice here is between >> making the IKE_SA_INIT exchange more complex and adding a new, rather simple >> exchange. >> >> Adding the ticket to the IKE_SA_INIT means that there are two paths in the >> IKE_SA_INIT code, and state must be kept to keep the two apart. This choice >> has the advantage, as Hui pointed out, that if the ticket is in the >> IKE_SA_INIT, you can fall back to regular IKE, saving us one round-trip in >> the weird and rare case that the gateway cannot use the ticket (the ticket >> store died? Key rolled over while the connection was down?) >> >> A new exchange will involve more new lines of code, but the difference is >> not great, and this has the advantage of having both the IKE_SA_INIT and the >> IKE_RESUMPTION exchanges remain simple. >> >> So I think both options are good, but if I have to choose, I would go with >> adding a new exchange, because two simple exchanges have a lesser potential >> for problems than one complex exchange. >> >> Yoav >> >> Email secured by Check Point >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > --001636c5afb6daeab50461af3be7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think that adding a new exchange would be bett= er. This would allow an implementation to just use a resumption exchange, a= nd not use IKE_SA_INIT and decide if it is to be used to create a new SA or= for reconnection purposes

.This will require far more lines of code as it was previously stated, = but I feel that this would be similar in structure to existing exchanges (h= ow the code is written to implement their functionality) and would be simpl= e. This way, implementers will "just" have to add a new exchange = to their existing code and not have to change an existing exchange.

I would say that keeping simple exchanges would be beneficial for IKE.<= br>
Regards,

Matthew

Paul Hoffman said:
>
> At 5:30 PM +0200 1/24/09, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > >Here is a copy-and-paste from the page:
> >"
> >Use IKE_SA_INIT with a ticket payload, instead of defining a new > >exchange type.
> >
> >Main reasons: - Simpler implementation, adding a new exchange requ= ires a
> >lot of new code. - More efficient protocol of the responder *does = not*
> >implement this extension. - Similar to RFC 5077 (TLS stateless
> >resumption).
> >
> >See http://www.ietf.org/mail-archive/web/ipsec= /current/msg03356.html and
> >follow ups.
> >"
> >
> >I guess we need a few other folks to join the discussion and to st= ate
> >their opinion.
>
> Yes, definitely. At this point, we have heard from two groups of autho= rs;
> hearing from the wider implementers community would be valuable.

IMO it's six of one, half a dozen of another.  The choice he= re is between making the IKE_SA_INIT exchange more complex and adding a new= , rather simple exchange.

Adding the ticket to the IKE_SA_INIT means that there are two paths in the = IKE_SA_INIT code, and state must be kept to keep the two apart. This choice= has the advantage, as Hui pointed out, that if the ticket is in the IKE_SA= _INIT, you can fall back to regular IKE, saving us one round-trip in the we= ird and rare case that the gateway cannot use the ticket (the ticket store = died? Key rolled over while the connection was down?)

A new exchange will involve more new lines of code, but the difference is n= ot great, and this has the advantage of having both the IKE_SA_INIT and the= IKE_RESUMPTION exchanges remain simple.

So I think both options are good, but if I have to choose, I would go with = adding a new exchange, because two simple exchanges have a lesser potential= for problems than one complex exchange.

Yoav

Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec


--001636c5afb6daeab50461af3be7-- --===============1323855945== 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 --===============1323855945==-- From na6264129@agimedia.com Fri Jan 30 00:55:03 2009 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 1B1393A6AD6 for ; Fri, 30 Jan 2009 00:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_I_LETTER=-2, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7s+RhmqGC6lv for ; Fri, 30 Jan 2009 00:55:02 -0800 (PST) Received: from ppp-58-10-152-89.revip2.asianet.co.th (ppp-58-10-152-89.revip2.asianet.co.th [58.10.152.89]) by core3.amsl.com (Postfix) with SMTP id EA5603A689F for ; Fri, 30 Jan 2009 00:55:00 -0800 (PST) To: Subject: Sales Receipt from Amazon From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090130085500.EA5603A689F@core3.amsl.com> Date: Fri, 30 Jan 2009 00:55:00 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.wisejuicy.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://wisejuicy.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 7, B803. 192 Clements Road. London. SE71 6DG

© 2006-2008 BBCMEDIA, Ltd. All Rights Reserved

From kehuoj@777.sh Fri Jan 30 03:13:24 2009 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 37FAB28C1F0 for ; Fri, 30 Jan 2009 03:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.179 X-Spam-Level: X-Spam-Status: No, score=-12.179 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNOWNyiCiWSr for ; Fri, 30 Jan 2009 03:13:23 -0800 (PST) Received: from advest.com (unknown [88.247.135.215]) by core3.amsl.com (Postfix) with SMTP id 410923A685F for ; Fri, 30 Jan 2009 03:13:21 -0800 (PST) To: Subject: Sales Order from walmart.com From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090130111322.410923A685F@core3.amsl.com> Date: Fri, 30 Jan 2009 03:13:21 -0800 (PST)
We ship Worldwide! To all countries! To all destinations!
Cant see a picture? Click Here!

To unsubscribe from this mailing list, please log in to www.wisejuicy.com, click on "My Account", click "Update" to edit your registration details and uncheck the "Receive Newsletter?" check box.
Or unsubscribe at http://wisejuicy.com/faq.php

Privacy Statement | Terms & Conditions | Contact

BBCMEDIA Ltd.
Tower Bridge Business Complex. Unit 8, B076. 288 Clements Road. London. SE67 1DG

© 2006-2008 BBCMEDIA, Ltd. All Rights Reserved

From ipsec-bounces@ietf.org Fri Jan 30 05:54:30 2009 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 5A1B13A6B5E; Fri, 30 Jan 2009 05:54:30 -0800 (PST) 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 723F73A67A4 for ; Fri, 30 Jan 2009 05:54:29 -0800 (PST) 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 yc0c8HeWGO1V for ; Fri, 30 Jan 2009 05:54:28 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 36DDA3A6B3D for ; Fri, 30 Jan 2009 05:54:27 -0800 (PST) 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 n0UDs5XJ020874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 15:54:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0UDs46B009095; Fri, 30 Jan 2009 15:54:04 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18819.1659.997941.776700@fireball.kivinen.iki.fi> Date: Fri, 30 Jan 2009 15:54:03 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63AD0E@il-ex01.ad.checkpoint.com> References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD41@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45F7FF42@FIESEXC015.nsn-intra.net> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D97E63AD0E@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 10 min Cc: "ipsec@ietf.org" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" , Paul Hoffman Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) 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 Yaron Sheffer writes: > It seems to me we are splitting hairs here: what is the different > between "hard expiry" and a hint? The protocol as it is today can > handle the case when the gateway doesn't like the ticket it > receives. And any reasonable client implementation will never send a > stale ticket, regardless if this is "expiry" or a "hint". So the > behavior is really the same. Hard expiry means that when it expires then client cannot use the ticket anymore, which means it will most likely need to get new ticket before this happens. I.e. client needs to have timer that will expire before the ticket expires, and do INFORMATIONAL exchange with N(TICKET_OPAQUE) and server replies to that with N(TICKET_OPAQUE). This means that there is yet another thing we need to keep up and running all the time we have IKE SA set up. So I do not want to have protocol which does following: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr, N(TICKET_OPAQUE lifetime=600) [,N(TICKET_GATEWAY_LIST)]} HDR, SK {N(TICKET_REQUEST)} --> <-- HDR, SK {N(TICKET_OPAQUE lifetime=600) [,N(TICKET_GATEWAY_LIST)]} HDR, SK {N(TICKET_REQUEST)} --> <-- HDR, SK {N(TICKET_OPAQUE lifetime=600) [,N(TICKET_GATEWAY_LIST)]} HDR, SK {N(TICKET_REQUEST)} --> <-- HDR, SK {N(TICKET_OPAQUE lifetime=600) [,N(TICKET_GATEWAY_LIST)]} HDR, SK {N(TICKET_REQUEST)} --> <-- HDR, SK {N(TICKET_OPAQUE lifetime=600) [,N(TICKET_GATEWAY_LIST)]} I would much prefer following protocol: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} --> <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]}
choose the=20 certificate authority to use ?  
In = ikev1 this case=20 is specified in
 http://www.ietf.org/rfc/rfc2= 408.txt section=20 3.10.
"This would be included to assist the = responder=20 in
       determining how much of the=20 certificate chain would need to = be
       sent=20 in response to this request.  If there is no=20 specific
       certificate authority=20 requested, this field SHOULD not = be
      =20 included." 
  ------_=_NextPart_001_01C982E4.E6EBE999-- --===============0280641437== 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 --===============0280641437==-- From ipsec-bounces@ietf.org Fri Jan 30 06:19:00 2009 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 A25443A6ABA; Fri, 30 Jan 2009 06:19:00 -0800 (PST) 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 856033A6ABA for ; Fri, 30 Jan 2009 06:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 GAlPHF67w0PK for ; Fri, 30 Jan 2009 06:18:58 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E1FFA3A68FE for ; Fri, 30 Jan 2009 06:18:57 -0800 (PST) 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 n0UEIc4s002490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Jan 2009 16:18:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n0UEIbKP027674; Fri, 30 Jan 2009 16:18:37 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18819.3133.843142.291735@fireball.kivinen.iki.fi> Date: Fri, 30 Jan 2009 16:18:37 +0200 From: Tero Kivinen To: "Tschofenig, Hannes (NSN - FI/Espoo)" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45F80700@FIESEXC015.nsn-intra.net> References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD41@FIESEXC015.nsn-intra.net> <3D3C75174CB95F42AD6BCC56E5555B45F7FF42@FIESEXC015.nsn-intra.net> <18813.50406.242743.604131@fireball.kivinen.iki.fi> <3D3C75174CB95F42AD6BCC56E5555B45F80700@FIESEXC015.nsn-intra.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 23 min X-Total-Time: 24 min Cc: ipsec@ietf.org, Paul Hoffman Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not? (and ticket push from gateway) 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 Tschofenig, Hannes (NSN - FI/Espoo) writes: > We reused the same payload format for both directions. I added text that > the lifetime in the C->S direction is set to the lifetime previously > received. > > Alternatively, I could also introduce an additional payload format and > exclude the lifetime. > > Do you prefer the latter? I would prefer to remove lifetime completely. I.e. keep the same payload format for both uses, but do not include lifetime at all. > >Also what does server does if the lifetime client gives when > >it presents ticket is different than what was sent before. Is > >that fatal error? Is that silently ignored? > > The draft says: > " > The four > octet lifetime field contains the number of seconds until the ticket > expires (encoded as an unsigned integer). > " This does not tell anything whether client is allowed or not allowed to mess around with the lifetime field of the ticket. It is clear that if client modifies the ticket data the ticket will not work, but can it for example send lifetime as zero when it is sending it to the server at IKE_SESSON_RESUME. For example implementation which only stores the ticket data, and sets timer to expire before the lifetime expires (to get request ticket), might not need to store the original lifetime value at all. So I can see such implementation sending different values in the lifetime field than what was originally sent. I can also see some server implementations which might consider it an error if not same value is not sent. Thus if lifetimes are left in to the draft, then it either needs to say that lifetime is ignored in the IKE_SESSON_RESUME when client presents the ticket, or it needs to say that client must keep the same value that was sent to it. > >Another problem with lifetimes is that they do have explicit > >policy limits, meaning they will cause negotiations to fail. > >This happened a lot in the IKEv1 environment, and in the end > >it was always mandatory to make sure that both client and > >server used EXACTLY same lifetimes, as otherwise you most > >likely didn't interop. > > Not an issue here as absolute time isn't used. I do not think absolute time has anything to do with this. In IKEv1 the lifetimes were presented in the same way as in your draft, and there was lots of problems with them, i.e. other end rejecting the exchange because the lifetime given in the exchange wasn't something it was willing to accept. > >This will mean that if client is configured for minimal > >lifetime of ticket of 3600 seconds, and server offers ticket > >which have lifetime of 3599 seconds, client will fail the > >negotiation. On the other hand if we say that there MUST NOT > >be any policy limitation checks for the lifetimes, then there > >is no point of tell them really, as server can simply start > >new INFORMATIONAL exchange and send new N(TICKET_OPAQUE) when > >the previous one is about to expire. > > We can certainly add text to the draft discussing such a case. > If the client is not happy with what it gets then it can always start a > full exchange. I don't see a problem with that. This is also a policy > issue. In this specific case this is appropriate for the client todo. It can only do full exchange after the IKE SA has been deleted, but for most of the time the IKE SA will still be there for long time. I.e. when the IKE SA is first created and the ticket is given a 600 second lifetime, then during the 8 hours of working the ticket needs to be requested again 48 times, and then when IKE SA goes away, then 10 minutes after that both server and client will know that ticket is no longer valid. > Having tickets with a very short lifetime is probably not such a good > idea. But for loaded server it might want to use short lifetime, just so that it does not need to store too much data for too long time, for no real benefit. Lets take example of big www-server protected by IPsec using resumption. The web server might have million users connecting to it every day, and each user usually requests a page (and the images on it) and then reads for it for 5 minutes, and then gets next page and so on for 30 minutes or so and then comes again next day (lets say this is some newpaper or similar). For this usage the lifetime of the ticket on the server end would most likely be short, around 30 min - 60 min, as if client is away for more than an hour, then it usually means it comes back only next day. If server uses tickets by reference, meaning that the server stores the actual ticket data (0.5 kB each), then storing tickets for all million users would require 488 MB of storage space. Storing tickets for those 100 000 users that come every hour requires 48 MB. If the server only tries to recover for cases where user connection is lost for less than 10 minutes (i.e. it expires tickets 10 minutes after last packet has been received from the user), then it only needs to store 8 MB of tickets. Is the session resumption only meant for very long lived SAs or is it also meant for this kind of short lived connections? -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jan 30 06:50:30 2009 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 37E5228C0DD; Fri, 30 Jan 2009 06:50:30 -0800 (PST) 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 825D428C0DD for ; Fri, 30 Jan 2009 06:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.335 X-Spam-Level: X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 Hd4IUWCtm1zF for ; Fri, 30 Jan 2009 06:50:27 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 07A1B3A6B14 for ; Fri, 30 Jan 2009 06:50:26 -0800 (PST) Received: (qmail invoked by alias); 30 Jan 2009 14:50:06 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp009) with SMTP; 30 Jan 2009 15:50:06 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18/o9lvlQ4/dwVMzPOXaiGOXvQBiC0s17PBhzFQve s/gaO7ypVUFxMB From: "Hannes Tschofenig" To: "'Tero Kivinen'" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" References: <3D3C75174CB95F42AD6BCC56E5555B45F7FD41@FIESEXC015.nsn-intra.net><3D3C75174CB95F42AD6BCC56E5555B45F7FF42@FIESEXC015.nsn-intra.net><18813.50406.242743.604131@fireball.kivinen.iki.fi><3D3C75174CB95F42AD6BCC56E5555B45F80700@FIESEXC015.nsn-intra.net> <18819.3133.843142.291735@fireball.kivinen.iki.fi> Date: Fri, 30 Jan 2009 16:50:49 +0200 Message-ID: <030d01c982ea$25036f30$0201a8c0@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: <18819.3133.843142.291735@fireball.kivinen.iki.fi> Thread-Index: AcmC5ahU+0chhXOwRP2AJJM6M4pu+AAAPXuQ X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: ipsec@ietf.org, 'Paul Hoffman' Subject: Re: [IPsec] Ticket #70: Ticket lifetime - explicit or not?(and ticket push from gateway) 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 Tero, >Tschofenig, Hannes (NSN - FI/Espoo) writes: >> We reused the same payload format for both directions. I added text >> that the lifetime in the C->S direction is set to the lifetime >> previously received. >> >> Alternatively, I could also introduce an additional payload >format and >> exclude the lifetime. >> >> Do you prefer the latter? > >I would prefer to remove lifetime completely. I.e. keep the >same payload format for both uses, but do not include lifetime at all. Ok. > >> >Also what does server does if the lifetime client gives when it >> >presents ticket is different than what was sent before. Is >that fatal >> >error? Is that silently ignored? >> >> The draft says: >> " >> The four >> octet lifetime field contains the number of seconds until >the ticket >> expires (encoded as an unsigned integer). >> " > >This does not tell anything whether client is allowed or not >allowed to mess around with the lifetime field of the ticket. >It is clear that if client modifies the ticket data the ticket >will not work, but can it for example send lifetime as zero >when it is sending it to the server at IKE_SESSON_RESUME. For >example implementation which only stores the ticket data, and >sets timer to expire before the lifetime expires (to get >request ticket), might not need to store the original lifetime >value at all. > >So I can see such implementation sending different values in >the lifetime field than what was originally sent. I can also >see some server implementations which might consider it an >error if not same value is not sent. > >Thus if lifetimes are left in to the draft, then it either >needs to say that lifetime is ignored in the IKE_SESSON_RESUME >when client presents the ticket, or it needs to say that >client must keep the same value that was sent to it. I agree with you and Paul that this aspect needs to be clarified. My intention was that the client does not mess around with the value of the lifetime field. > >> >Another problem with lifetimes is that they do have explicit policy >> >limits, meaning they will cause negotiations to fail. >> >This happened a lot in the IKEv1 environment, and in the end it was >> >always mandatory to make sure that both client and server used >> >EXACTLY same lifetimes, as otherwise you most likely didn't interop. >> >> Not an issue here as absolute time isn't used. > >I do not think absolute time has anything to do with this. In >IKEv1 the lifetimes were presented in the same way as in your >draft, and there was lots of problems with them, i.e. other >end rejecting the exchange because the lifetime given in the >exchange wasn't something it was willing to accept. I have asked Joe and Hao about their implementation experience with RFC 5077. They did not mention anything along these lines. Sure, there is less experience with RFC 5077 than with IKEv1. I would, however, expect that an entity rejects something if it does not comply with the local policy. > >> >This will mean that if client is configured for minimal lifetime of >> >ticket of 3600 seconds, and server offers ticket which have >lifetime >> >of 3599 seconds, client will fail the negotiation. On the >other hand >> >if we say that there MUST NOT be any policy limitation >checks for the >> >lifetimes, then there is no point of tell them really, as >server can >> >simply start new INFORMATIONAL exchange and send new >N(TICKET_OPAQUE) >> >when the previous one is about to expire. >> >> We can certainly add text to the draft discussing such a case. >> If the client is not happy with what it gets then it can >always start >> a full exchange. I don't see a problem with that. This is also a >> policy issue. In this specific case this is appropriate for >the client todo. > >It can only do full exchange after the IKE SA has been >deleted, but for most of the time the IKE SA will still be >there for long time. >I.e. when the IKE SA is first created and the ticket is given >a 600 second lifetime, then during the 8 hours of working the >ticket needs to be requested again 48 times, and then when IKE >SA goes away, then 10 minutes after that both server and >client will know that ticket is no longer valid. > >> Having tickets with a very short lifetime is probably not >such a good >> idea. > >But for loaded server it might want to use short lifetime, >just so that it does not need to store too much data for too >long time, for no real benefit. > >Lets take example of big www-server protected by IPsec using >resumption. The web server might have million users connecting >to it every day, and each user usually requests a page (and >the images on >it) and then reads for it for 5 minutes, and then gets next >page and so on for 30 minutes or so and then comes again next >day (lets say this is some newpaper or similar). > >For this usage the lifetime of the ticket on the server end >would most likely be short, around 30 min - 60 min, as if >client is away for more than an hour, then it usually means it >comes back only next day. If server uses tickets by reference, >meaning that the server stores the actual ticket data (0.5 kB >each), then storing tickets for all million users would >require 488 MB of storage space. > >Storing tickets for those 100 000 users that come every hour requires >48 MB. If the server only tries to recover for cases where >user connection is lost for less than 10 minutes (i.e. it >expires tickets 10 minutes after last packet has been received >from the user), then it only needs to store 8 MB of tickets. > >Is the session resumption only meant for very long lived SAs >or is it also meant for this kind of short lived connections? >-- I personally was thinking more of IPsec usage in a VPN gateway scenario rather than IPsec/IKEv2 usage with a webserver for webbrowsing. Ciao Hannes >kivinen@iki.fi >_______________________________________________ >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