From nobody Thu Jun 2 07:57:54 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA1712D1CD for ; Thu, 2 Jun 2016 07:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7o421GqFtYqS for ; Thu, 2 Jun 2016 07:57:50 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 500B212D14D for ; Thu, 2 Jun 2016 07:57:50 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id b73so35782681lfb.3 for ; Thu, 02 Jun 2016 07:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=RxjoGHPoeW2PTA5fmKghSupMExRwJcQe9dr10LlCPAA=; b=bHMjf2/wSv4nOOabpBCzVVk7765zV185GY7X5taxCglOW0lzQFFZP7hEOLso3HaW0n j8GJA7muxCmNJRGvlwBEC8A5KbDvjQMaGnPqp++9vmd0mXQt7pIRsAnixUlhfHnfFH8J rN3bMCxsaUyR3zLW+/eqZy8CITD7hXBtKkPlHXlZpBQNnjxCTtgM15gB14Iclr2h2pgY bOSOqWv86xdFV5KsVZVRCanFZbDDAb8sCatRp4sufgABRc+n0ofzl6m9oLFrgFnp3wi3 iqtL/C42NH71osQwm57LW54/lO/HnkatDH/ZKERSR5C9J7aUYdGl7A/u6nIsP2xulvJ/ 88mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=RxjoGHPoeW2PTA5fmKghSupMExRwJcQe9dr10LlCPAA=; b=KONp9oJxYJTK9yNrenAmVWUV8CIeBNj+yOyBaCq3is5fvyo5a7P+u1un4/sYYQPrQF uQj5oHwzQ8ZjExFpM8wBvJymYCJA00gqZTw5QV4oFhqo+qhtBKqBc4vI0Ul7C6ayY2kY 37RTpvBmWIXZmb+oTFX1XA6amO5CvCkIRCKH263w8dJhV4bb+Sp8s6ROIXpkfsm1kbrd k64/QJGMVYEqG5bDsA6DrawPDGNfb+LdygsiHieFqFF0HfXw1uJRuvYw2QhX6J2e9lsz slro6VrdgZRWahrr93Yjc4qWS1t8duSY1YnSpKieZX7AweflHtGdiNWGU+S19Is67eLn doNg== X-Gm-Message-State: ALyK8tIJmYCYSPwxs6HbPN70cmTDZQ+SsyOxQV2M3WX/YHjHaNmeispzicjChcSrGul8SQ== X-Received: by 10.25.210.144 with SMTP id j138mr4243296lfg.77.1464879468322; Thu, 02 Jun 2016 07:57:48 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g69sm4087638lji.20.2016.06.02.07.57.47 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Jun 2016 07:57:47 -0700 (PDT) Message-ID: <4200F5373D5542C985F3D4C51609213C@buildpc> From: "Valery Smyslov" To: "Paul Wouters" , References: Date: Thu, 2 Jun 2016 17:57:40 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: Yoav Nir Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 14:57:53 -0000 Hi Paul, thank you for the very thorough review (and especially - for the nits). > This is a partial review of draft-ietf-ipsecme-ddos-protection-06 > up to Section 6. I hope to complete the rest in the next few days. > > I think this document needs another revision before continuing. > (and I would prefer it to be split in two) > > Issues / Questions: > > An obvious defense, which is described in Section 4.2, is limiting > the number of half-open SAs opened by a single peer. However, since > all that is required is a single packet, an attacker can use multiple > spoofed source IP addresses. > > I am not sure why this is mentioned here in this way, because the attack > of spoofed source IP is already handled effectively with DOS cookies. I > think it is better to state "bot-nets are large enough that they have > enough unique IP addresses" and avoid talking about spoofing in this > section altogether. Here are some general observations of IKEv2 vulnerabilities, regardless of the existing and proposed defense mechanisms, which are described in subsequent sections. > Stage #3 includes public key operations, typically more than one. > > It seems this sentence needs to say something that these operations are > very expensive, similar to describing the "effort" in the previous > sentences of stage #1 and stage #2. OK. How about: Stage #3 may include public key operations if certificates are involved. These operations are often more computationly expensive than those performed at stage #2. > It seems that the first thing cannot be dealt with at the IKE level. > It's probably better left to Intrusion Prevention System (IPS) > technology. > > I would rewrite this more authoritively, and not use the word "seems" OK. How about: If an attacker is so powerfull that it is able to overwhelm the Responder's CPU that deals with generating cookies, then the attack cannot be dealt with at the IKE level and must be handled by means of the Intrusion Prevention System (IPS) technology. > Depending on the Responder implementation, this can be repeated with > the same half-open SA. > > I don't think this "depends on the implemention". Since any on-path > attacker can spoof rubbish, a Responder MUST ignore the failed packet > and remain ready to accept the real one for a certain about of time. "Depending on the Responder implementation" means here that if along with discarding the failed packet the Responder also discards the computed SK_* keys, then it will need to re-calculate them again when the next IKE_AUTH packet is received, so the attack can be repeated. The SK_* keys don't depend on IKE_AUTH messages, so in general there is no need to discard them even if the received IKE_AUTH packet failed to decrypt properly, and the draft advises to keep them in this case. However, implementations may have good reasons to do this (e.g. to free hardware resources if crypto is performed in HW). > And this also applies to this later section in the document: > > If the received IKE_AUTH message failed to decrypt correctly (or > failed to pass ICV check), then the Responder SHOULD still keep the > computed SK_* keys, so that if it happened to be an attack, then the > malicious Initiator cannot get advantage of repeating the attack > multiple times on a single IKE SA. Please, see above. Do you think more explanationa are needed here? > Retransmission policies in practice wait at least one or two seconds > before retransmitting for the first time. > > I'm not sure if this is still true. Libreswan starts at 0.5s and doubles, > and I know that iOS was faster too. Well, there are different implementations and each has its own retransmission policy. The Responder should take into account the slowest sensible retransmission policy, which seems to be the one described in the draft. Will the following text make you happy? Many retransmission policies in practice wait one or two seconds before retransmitting for the first time. > When not under attack, the half-open SA timeout SHOULD be set high > enough that the Initiator will have enough time to send multiple > retransmissions, minimizing the chance of transient network > congestion causing IKE failure. > > I agree, but I'd like to note that this and the text just above mentioning > "several minutes" is kind of archaic. We found a limit of 30 seconds on That's what RFC 7296 recommends (Section 2.4). > other implementations so common as a timeout, that we see no more value in > keeping an IKE exchange around for more then 30 seconds. (we do re-start > and try a new exchange from scratch for longer, in some configurations we > try that forever) > > For IPv6, ISPs assign between a /48 and a /64, so it makes sense to use > a 64-bit prefix as the basis for rate limiting in IPv6. > > Why does that make sense over using /48 ? Wouldn't you rather rate limit > some innocent neighbours over not actually defending against the attack? > If puzzles work as advertised, real clients on that /48 should still be > able to connect. Well, I'm not an IPv6 expert. Probably Michael Richardson (who suggested this change) or somebody else will comment on this. > Regardless of the type of rate-limiting used, there is a huge > advantage in blocking the DoS attack using rate-limiting for > legitimate clients that are away from the attacking nodes. In such > cases, adverse impacts caused by the attack or by the measures used > to counteract the attack can be avoided. > > I don't understand this paragraph at all. I guess "rate-limiting for > legitimate clients" just confuses me. I think it might attempt to be > saying "not blocking ranges with no attackers helps real clients", but > it is very unclear. Yoav? > to calculate the PRF > > One does not "calculate" a PRF. One uses a PRF to calculate something. OK. > The section that starts with "Upon receiving this challenge," seems to > be discussing the pros and conns of this method before it has explained > the method. The reader is forced to skip this or forward to section 7 > and getting back to this part. I suggest to re-order some text to avoid > this, or to give a better short summary of the puzzle nature just before > this paragraph. It describes the puzzles mechanism in general, while Sections 7 & 8 describe the particular instantiation of puzzles in IKEv2. I'd rather to keep some background about puzzles here, so that all possible defenses are described in one place. > When the Responder is under attack, it MAY choose to prefer > previously authenticated peers who present a Session Resumption > ticket (see [RFC5723] for details). > > Why is this only a MAY? Why is it not a SHOULD or MUST? A good question. I think the idea was not to force the Responder to serve only resumed clients and to let him(her) prioterize clients according to its own policy. In my opinion MUST is too strong, but SHOULD is probably OK. > The Responder MAY require such > Initiators to pass a return routability check by including the COOKIE > notification in the IKE_SESSION_RESUME response message, as allowed > by Section 4.3.2. of [RFC5723]. > > Perhaps this should say the responder SHOULD require COOKIEs for resumed > sessions if it also requires COOKIEs for IKE_INIT requests. That is, it > should not give preference to resumed sessions as those could be equally > forged as IKE_INIT requests. A good point. I tend to agree. Yoav? > With a typical setup and typical Child SA lifetimes, there > are typically no more than a few such exchanges, often less. > > (ignoring the language) I do not believe this is true. This goes back to > the discussion on how often people deploy liveness probes. Implementors > seem to think 30s, while endusers want and do configure things like 1s. > I don't think the text about the amount of IKE exchanges are typical > are needed because the text below talks about specific abuse anyway, > and not in terms of just number of exchanges. Are you suggesting to remove it? > If the peer creates too many Child SA with the same or overlapping > Traffic Selectors, implementations can respond with the > NO_ADDITIONAL_SAS notification. > > I think this requires normative language, eg: implementations MUST respond > with a NO_ADDITIONAL_SAS notification. The same for the next bullet item > where it says "implementations can introduce an artificial delay", which > should be like: "MAY introduce an artificial delay" (or even SHOULD, or > rewrite "too many" to "many" and use MAY) I'd use MAY and keep "too many". "Too many" means here that a peer is at least misbehaved, while just "many" doesn't imply this (in my reading). > Section 5 switchs from talking about "the Responder" to "the implementation". > I think it should be "the Responder" throughout the document. OK. > the retransmitted messages should be silently discarded. > > That should be normative too, MUST be discarded. Agree. I won't comment the nits. Thank you, Valery. From nobody Thu Jun 2 14:13:53 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C1112D8A1; Thu, 2 Jun 2016 14:13:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160602211351.8789.27516.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2016 14:13:51 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, david.waltermire@nist.gov Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 96 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 21:13:52 -0000 A new meeting session request has just been submitted by David Waltermire, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: D. Waltermire Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: saag tls curdle tcpinc sacm mile Second Priority: 6tisch lwig ace httpauth Third Priority: uta 6lo dane tcpm netmod Special Requests: --------------------------------------------------------- From nobody Thu Jun 2 19:06:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB0312D144 for ; Thu, 2 Jun 2016 19:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEtUONV1kETU for ; Thu, 2 Jun 2016 19:06:11 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0612812D7E3 for ; Thu, 2 Jun 2016 19:06:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rLSB75kG4zw1; Fri, 3 Jun 2016 04:06:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id WzEx6hfXhLA2; Fri, 3 Jun 2016 04:06:05 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 3 Jun 2016 04:06:05 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4EE81677A54; Thu, 2 Jun 2016 22:06:04 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 4EE81677A54 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 36D9F406B809; Thu, 2 Jun 2016 22:06:04 -0400 (EDT) Date: Thu, 2 Jun 2016 22:06:04 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <4200F5373D5542C985F3D4C51609213C@buildpc> Message-ID: References: <4200F5373D5542C985F3D4C51609213C@buildpc> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 02:06:13 -0000 On Thu, 2 Jun 2016, Valery Smyslov wrote: >> An obvious defense, which is described in Section 4.2, is limiting >> the number of half-open SAs opened by a single peer. However, since >> all that is required is a single packet, an attacker can use multiple >> spoofed source IP addresses. >> >> I am not sure why this is mentioned here in this way, because the attack >> of spoofed source IP is already handled effectively with DOS cookies. I >> think it is better to state "bot-nets are large enough that they have >> enough unique IP addresses" and avoid talking about spoofing in this >> section altogether. > > Here are some general observations of IKEv2 vulnerabilities, > regardless of the existing and proposed defense mechanisms, which are > described in subsequent sections. But it is incomplete and out of place. Section is is about The Vulnerability. It talks about vulnerabilities, then this one solution to one thing, then goes into detail about the work that makes it vulnerable. That is why I suggest to just remove the paragraph. >> Stage #3 includes public key operations, typically more than one. >> >> It seems this sentence needs to say something that these operations are >> very expensive, similar to describing the "effort" in the previous >> sentences of stage #1 and stage #2. > > OK. How about: > > Stage #3 may include public key operations if certificates are involved. > These operations are often more computationly expensive than those > performed at stage #2. Looks good. >> It seems that the first thing cannot be dealt with at the IKE level. >> It's probably better left to Intrusion Prevention System (IPS) >> technology. >> >> I would rewrite this more authoritively, and not use the word "seems" > > OK. How about: > > If an attacker is so powerfull that it is able to overwhelm > the Responder's CPU that deals with generating cookies, > then the attack cannot be dealt with at the IKE level and > must be handled by means of the Intrusion Prevention System (IPS) > technology. Looks good. >> Depending on the Responder implementation, this can be repeated with >> the same half-open SA. >> >> I don't think this "depends on the implemention". Since any on-path >> attacker can spoof rubbish, a Responder MUST ignore the failed packet >> and remain ready to accept the real one for a certain about of time. > > "Depending on the Responder implementation" means here that if along with > discarding the failed packet the Responder also discards the computed SK_* > keys, then it will need to re-calculate them again > when the next IKE_AUTH packet is received, so the attack can be > repeated. The SK_* keys don't depend on IKE_AUTH messages, > so in general there is no need to discard them even if the received > IKE_AUTH packet failed to decrypt properly, and the draft advises to keep > them in this case. However, implementations may have good reasons to do this > (e.g. to free hardware resources if crypto is performed in HW). Oh, I didnt realise you talked about re-using DH components. Ok, in that case it makes sense but you might want to say it only applies to those who re-use DH calculations between different IKE peers. Our software never does that (and I think FIPS also puts additional constraints on this) > Please, see above. > > Do you think more explanationa are needed here? No I guess it is fine. >> Retransmission policies in practice wait at least one or two seconds >> before retransmitting for the first time. >> >> I'm not sure if this is still true. Libreswan starts at 0.5s and doubles, >> and I know that iOS was faster too. > > Well, there are different implementations and each has its own > retransmission policy. The Responder should take into account > the slowest sensible retransmission policy, which seems to be the one > described in the draft. > > Will the following text make you happy? > > Many retransmission policies in practice wait one or two seconds > before retransmitting for the first time. It would be nicer to rewrite it without mentioning any absolute times. That way the text will also remain more relevant in the future if/when these timings change. >> When not under attack, the half-open SA timeout SHOULD be set high >> enough that the Initiator will have enough time to send multiple >> retransmissions, minimizing the chance of transient network >> congestion causing IKE failure. >> >> I agree, but I'd like to note that this and the text just above mentioning >> "several minutes" is kind of archaic. We found a limit of 30 seconds on > > That's what RFC 7296 recommends (Section 2.4). Okay, fair enough. I guess you mention shortening it while under attack, so it's all okay. >> other implementations so common as a timeout, that we see no more value in >> keeping an IKE exchange around for more then 30 seconds. (we do re-start >> and try a new exchange from scratch for longer, in some configurations we >> try that forever) >> >> For IPv6, ISPs assign between a /48 and a /64, so it makes sense to use >> a 64-bit prefix as the basis for rate limiting in IPv6. >> >> Why does that make sense over using /48 ? Wouldn't you rather rate limit >> some innocent neighbours over not actually defending against the attack? >> If puzzles work as advertised, real clients on that /48 should still be >> able to connect. > > Well, I'm not an IPv6 expert. Probably Michael Richardson (who suggested this > change) or somebody else will comment on this. This does not so much relate to IPv6 but to whether you rather overestimate or underestimate the attacker's IP space. If you underestimate, you will take longer to punish the attacking IPs. If you overestimate you will needlessly slow down legitimate clients. I don't know which of the two is better, hence my objection to "it makes sense" because I don't see that. >> Regardless of the type of rate-limiting used, there is a huge >> advantage in blocking the DoS attack using rate-limiting for >> legitimate clients that are away from the attacking nodes. In such >> cases, adverse impacts caused by the attack or by the measures used >> to counteract the attack can be avoided. >> >> I don't understand this paragraph at all. I guess "rate-limiting for >> legitimate clients" just confuses me. I think it might attempt to be >> saying "not blocking ranges with no attackers helps real clients", but >> it is very unclear. > > Yoav? > >> to calculate the PRF >> >> One does not "calculate" a PRF. One uses a PRF to calculate something. > > OK. You didn't provide text but I assume you changed it somehow. >> The section that starts with "Upon receiving this challenge," seems to >> be discussing the pros and conns of this method before it has explained >> the method. The reader is forced to skip this or forward to section 7 >> and getting back to this part. I suggest to re-order some text to avoid >> this, or to give a better short summary of the puzzle nature just before >> this paragraph. > > It describes the puzzles mechanism in general, while Sections 7 & 8 > describe the particular instantiation of puzzles in IKEv2. > I'd rather to keep some background about puzzles here, > so that all possible defenses are described in one place. Then I think it still requires a one-line introduction to puzzles. >> When the Responder is under attack, it MAY choose to prefer >> previously authenticated peers who present a Session Resumption >> ticket (see [RFC5723] for details). >> >> Why is this only a MAY? Why is it not a SHOULD or MUST? > > A good question. I think the idea was not to force the Responder > to serve only resumed clients and to let him(her) prioterize > clients according to its own policy. In my opinion MUST is too strong, but > SHOULD is probably OK. In the famous words of Steve Kent, if you say SHOULD instead of MUST, explain when the Responder should not. >> The Responder MAY require such >> Initiators to pass a return routability check by including the COOKIE >> notification in the IKE_SESSION_RESUME response message, as allowed >> by Section 4.3.2. of [RFC5723]. >> >> Perhaps this should say the responder SHOULD require COOKIEs for resumed >> sessions if it also requires COOKIEs for IKE_INIT requests. That is, it >> should not give preference to resumed sessions as those could be equally >> forged as IKE_INIT requests. > > A good point. I tend to agree. Yoav? > >> With a typical setup and typical Child SA lifetimes, there >> are typically no more than a few such exchanges, often less. >> >> (ignoring the language) I do not believe this is true. This goes back to >> the discussion on how often people deploy liveness probes. Implementors >> seem to think 30s, while endusers want and do configure things like 1s. >> I don't think the text about the amount of IKE exchanges are typical >> are needed because the text below talks about specific abuse anyway, >> and not in terms of just number of exchanges. > > Are you suggesting to remove it? Yes. You can just talk about something like "If an abusive amount of (otherwise) valid IKE messages are received, ....." and let the implemetor decide how many IKE messages counts as abusive? That also avoids what to do when rekey's happen because that would likely reset the counter because it is a new state? >> If the peer creates too many Child SA with the same or overlapping >> Traffic Selectors, implementations can respond with the >> NO_ADDITIONAL_SAS notification. >> >> I think this requires normative language, eg: implementations MUST respond >> with a NO_ADDITIONAL_SAS notification. The same for the next bullet item >> where it says "implementations can introduce an artificial delay", which >> should be like: "MAY introduce an artificial delay" (or even SHOULD, or >> rewrite "too many" to "many" and use MAY) > > I'd use MAY and keep "too many". "Too many" means here that a peer is at > least misbehaved, while just "many" doesn't imply this > (in my reading). You cannot say "too many" and "MAY". If it is too many, it is abusive. So you MUST take action. On the other hand if you say "many", then you leave it open to interpretation whether it is abuse or not, and you can use "MAY". >> Section 5 switchs from talking about "the Responder" to "the >> implementation". >> I think it should be "the Responder" throughout the document. > > OK. > >> the retransmitted messages should be silently discarded. >> >> That should be normative too, MUST be discarded. > > Agree. Paul From nobody Fri Jun 3 06:24:05 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF51812D188 for ; Fri, 3 Jun 2016 06:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47Og0dBc5XLW for ; Fri, 3 Jun 2016 06:24:00 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D169E12D127 for ; Fri, 3 Jun 2016 06:23:59 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id b73so54392383lfb.3 for ; Fri, 03 Jun 2016 06:23:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=vCR6+NhevaRPqB8Lqq5aOko3E1wdJRHvSxVUJjJ6m/4=; b=u6tSAYut28n4pOZQbYoph583hmsToVpEiHXQUJee0ekgbb4HKT6ABjXSqnmoFTA2gF s7vBsol9xNXhq3YYAZ+A8stnMPHo+Pg99lRZ/eqVinL+LoppIJIANn7ioYC+SGQZggXu Kk7eXGekd0WDmzMcijTnVSQTZ2JfJfy7/d7NumKGuPvgvzFBkHkAiwEucZhIj5+FHnoA yDN/0DV9CWI67oEX42MpEKNYFR1xFDH11pLxJZdlJqGOOkb7Pj7P8Y5QY7K/i9LVk+Nb fPIFCjNbDch2VGTfSUA7TI1tjRm9JFK5WpkzAv9hlSG9/GeIn/FaOIhY2UHoen4e/8KG S8mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=vCR6+NhevaRPqB8Lqq5aOko3E1wdJRHvSxVUJjJ6m/4=; b=Mn5CJRgQcIaZTDLGiZV8Y8/Gb3Oabxcvy764bVD7PSUSKVdUHc0BStLeexfulpcRv4 Yt0IsTZ8Gy3o74dqBQQJj7vUjsJRLqk3JW3wctV1BV7KpEKum583+ZRos+iH1hEmjcaH XHe51nk8O0nuk2mW0csxDoeN1TDBldOlux50li6YAXLGzbuqrA72T0bQCFsZWqXPcMG9 fYIgEl55MbZYD1tn768srlKOZXuzNFI6dhSM34wUx/Tw3ZrcvrFah6bXVxH6hV6NdE8l zfF2U76jSjhHUgA20SnFjFPUIoGrGxnOjoh85eGodvMOa6dJhrgq8YmXrMNOXv7aqc5V W69w== X-Gm-Message-State: ALyK8tLipq3R6RskMT5oaCigwWZTeZyTc/mJbEGKC36RlkNzVO2rulDTG7M1u1Q9W3moEw== X-Received: by 10.25.201.132 with SMTP id z126mr1141278lff.158.1464960237789; Fri, 03 Jun 2016 06:23:57 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id j81sm528894lfg.1.2016.06.03.06.23.56 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Jun 2016 06:23:56 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <4200F5373D5542C985F3D4C51609213C@buildpc> Date: Fri, 3 Jun 2016 16:23:48 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 13:24:03 -0000 Hi Paul, >>> An obvious defense, which is described in Section 4.2, is limiting >>> the number of half-open SAs opened by a single peer. However, since >>> all that is required is a single packet, an attacker can use multiple >>> spoofed source IP addresses. >>> >>> I am not sure why this is mentioned here in this way, because the attack >>> of spoofed source IP is already handled effectively with DOS cookies. I >>> think it is better to state "bot-nets are large enough that they have >>> enough unique IP addresses" and avoid talking about spoofing in this >>> section altogether. >> >> Here are some general observations of IKEv2 vulnerabilities, >> regardless of the existing and proposed defense mechanisms, which are >> described in subsequent sections. > > But it is incomplete and out of place. Section is is about The > Vulnerability. It talks about vulnerabilities, then this one solution to > one thing, then goes into detail about the work that makes it > vulnerable. That is why I suggest to just remove the paragraph. Ok, I see your point. >>> Stage #3 includes public key operations, typically more than one. >>> >>> It seems this sentence needs to say something that these operations are >>> very expensive, similar to describing the "effort" in the previous >>> sentences of stage #1 and stage #2. >> >> OK. How about: >> >> Stage #3 may include public key operations if certificates are involved. >> These operations are often more computationly expensive than those >> performed at stage #2. > > Looks good. > >>> It seems that the first thing cannot be dealt with at the IKE level. >>> It's probably better left to Intrusion Prevention System (IPS) >>> technology. >>> >>> I would rewrite this more authoritively, and not use the word "seems" >> >> OK. How about: >> >> If an attacker is so powerfull that it is able to overwhelm >> the Responder's CPU that deals with generating cookies, >> then the attack cannot be dealt with at the IKE level and >> must be handled by means of the Intrusion Prevention System (IPS) >> technology. > > Looks good. > >>> Depending on the Responder implementation, this can be repeated with >>> the same half-open SA. >>> >>> I don't think this "depends on the implemention". Since any on-path >>> attacker can spoof rubbish, a Responder MUST ignore the failed packet >>> and remain ready to accept the real one for a certain about of time. >> >> "Depending on the Responder implementation" means here that if along with >> discarding the failed packet the Responder also discards the computed SK_* >> keys, then it will need to re-calculate them again >> when the next IKE_AUTH packet is received, so the attack can be >> repeated. The SK_* keys don't depend on IKE_AUTH messages, >> so in general there is no need to discard them even if the received >> IKE_AUTH packet failed to decrypt properly, and the draft advises to keep >> them in this case. However, implementations may have good reasons to do this >> (e.g. to free hardware resources if crypto is performed in HW). > > Oh, I didnt realise you talked about re-using DH components. Ok, in that > case it makes sense but you might want to say it only applies to those > who re-use DH calculations between different IKE peers. Our software > never does that (and I think FIPS also puts additional constraints on > this) No, it is not about re-using DH private key with different peers. I probably poorly explained. Let me try again. Once the IKE_SA_INIT is complete the responder has all needed data to calculate SKEYSEED and SK_* keys. However, it is a CPU consuming operations, so the responder may want to postpone them until the keys are really needed, i.e. until it receives the IKE_AUTH request from the initiator. This behaviour allows responder not to waste resources in case IKE_SA_INIT was from an attacker and IKE_AUTH request never comes. Once IKE_AUTH request arrives the responder performs DH, calculates SKEYSEED and SK_* keys that allows him to decrypt and verify this request. In case it fails to decrypt IKE_AUTH request, the responder has two possibilities - keep just calculated SK_* keys until the next (hopely proper) IKE_AUTH request is received or discard them (e.g. to save crypto resources) and recalculate them again once the next IKE_AUTH request is received (note that re-calculating will result in EXACTLY the same keys, since they don't depent on any data from IKE_AUTH). The draft recommends to keep the keys until the proper IKE_AUTH request is received (or until the exchange timed out). This advise may look obvious, but I think is still worth to mention. I recall we've already discussed this while reviewing the -05 version... >> Please, see above. >> >> Do you think more explanationa are needed here? > > No I guess it is fine. Are you sure after the above explanation? >>> Retransmission policies in practice wait at least one or two seconds >>> before retransmitting for the first time. >>> >>> I'm not sure if this is still true. Libreswan starts at 0.5s and doubles, >>> and I know that iOS was faster too. >> >> Well, there are different implementations and each has its own >> retransmission policy. The Responder should take into account >> the slowest sensible retransmission policy, which seems to be the one >> described in the draft. >> >> Will the following text make you happy? >> >> Many retransmission policies in practice wait one or two seconds >> before retransmitting for the first time. > > It would be nicer to rewrite it without mentioning any absolute times. > That way the text will also remain more relevant in the future if/when > these timings change. I don't think it is a good idea. The draft should give implementers some estimate timings. "One or two seconds" is here a "worst case". If Implementers take this data into consideration when selecting the short timeout, they'll always be on the safe side, because if some implementations retransmit more aggressively, then they'll always fit within this time period. So I'd rather keep the text as above. >>> When not under attack, the half-open SA timeout SHOULD be set high >>> enough that the Initiator will have enough time to send multiple >>> retransmissions, minimizing the chance of transient network >>> congestion causing IKE failure. >>> >>> I agree, but I'd like to note that this and the text just above mentioning >>> "several minutes" is kind of archaic. We found a limit of 30 seconds on >> >> That's what RFC 7296 recommends (Section 2.4). > > Okay, fair enough. I guess you mention shortening it while under attack, > so it's all okay. > >>> other implementations so common as a timeout, that we see no more value in >>> keeping an IKE exchange around for more then 30 seconds. (we do re-start >>> and try a new exchange from scratch for longer, in some configurations we >>> try that forever) >>> >>> For IPv6, ISPs assign between a /48 and a /64, so it makes sense to use >>> a 64-bit prefix as the basis for rate limiting in IPv6. >>> >>> Why does that make sense over using /48 ? Wouldn't you rather rate limit >>> some innocent neighbours over not actually defending against the attack? >>> If puzzles work as advertised, real clients on that /48 should still be >>> able to connect. >> >> Well, I'm not an IPv6 expert. Probably Michael Richardson (who suggested this >> change) or somebody else will comment on this. > > This does not so much relate to IPv6 but to whether you rather > overestimate or underestimate the attacker's IP space. If you > underestimate, you will take longer to punish the attacking IPs. If you > overestimate you will needlessly slow down legitimate clients. > > I don't know which of the two is better, hence my objection to "it makes > sense" because I don't see that. What's your suggestion for this text? Just remove "it make sense" or completely rewrite the para? If the latter, please provide the text. >>> Regardless of the type of rate-limiting used, there is a huge >>> advantage in blocking the DoS attack using rate-limiting for >>> legitimate clients that are away from the attacking nodes. In such >>> cases, adverse impacts caused by the attack or by the measures used >>> to counteract the attack can be avoided. >>> >>> I don't understand this paragraph at all. I guess "rate-limiting for >>> legitimate clients" just confuses me. I think it might attempt to be >>> saying "not blocking ranges with no attackers helps real clients", but >>> it is very unclear. >> >> Yoav? >> >>> to calculate the PRF >>> >>> One does not "calculate" a PRF. One uses a PRF to calculate something. >> >> OK. > > You didn't provide text but I assume you changed it somehow. s/PRF/"output of PRF" or s/PRF/"the result of PRF" Is it OK? >>> The section that starts with "Upon receiving this challenge," seems to >>> be discussing the pros and conns of this method before it has explained >>> the method. The reader is forced to skip this or forward to section 7 >>> and getting back to this part. I suggest to re-order some text to avoid >>> this, or to give a better short summary of the puzzle nature just before >>> this paragraph. >> >> It describes the puzzles mechanism in general, while Sections 7 & 8 >> describe the particular instantiation of puzzles in IKEv2. >> I'd rather to keep some background about puzzles here, >> so that all possible defenses are described in one place. > > Then I think it still requires a one-line introduction to puzzles. I'm a bit confused. I've been thinking that the whole Section 4.4 is a high-level description of the puzzles. Where do you want to insert the one-line introduction? >>> When the Responder is under attack, it MAY choose to prefer >>> previously authenticated peers who present a Session Resumption >>> ticket (see [RFC5723] for details). >>> >>> Why is this only a MAY? Why is it not a SHOULD or MUST? >> >> A good question. I think the idea was not to force the Responder >> to serve only resumed clients and to let him(her) prioterize >> clients according to its own policy. In my opinion MUST is too strong, but >> SHOULD is probably OK. > > In the famous words of Steve Kent, if you say SHOULD instead of MUST, > explain when the Responder should not. When it has good reasons :-) Seriously, consider the situation when the responder finds itself under attack and switches to only respond to IKE_SA_RESUME requests. In this case it will leave legitimate clients without resumption tickets (e.g. ticket expired) out of scope. I think there is no reasom to put MUST here, since in any case it is a local policy which dictates the responder's behaviour, and ther are no interoperability issues whether is is MAY, SHOULD or MUST, it is just the responder's local policy matter. So SHOULD is just good advise. >>> The Responder MAY require such >>> Initiators to pass a return routability check by including the COOKIE >>> notification in the IKE_SESSION_RESUME response message, as allowed >>> by Section 4.3.2. of [RFC5723]. >>> >>> Perhaps this should say the responder SHOULD require COOKIEs for resumed >>> sessions if it also requires COOKIEs for IKE_INIT requests. That is, it >>> should not give preference to resumed sessions as those could be equally >>> forged as IKE_INIT requests. >> >> A good point. I tend to agree. Yoav? >> >>> With a typical setup and typical Child SA lifetimes, there >>> are typically no more than a few such exchanges, often less. >>> >>> (ignoring the language) I do not believe this is true. This goes back to >>> the discussion on how often people deploy liveness probes. Implementors >>> seem to think 30s, while endusers want and do configure things like 1s. >>> I don't think the text about the amount of IKE exchanges are typical >>> are needed because the text below talks about specific abuse anyway, >>> and not in terms of just number of exchanges. >> >> Are you suggesting to remove it? > > Yes. You can just talk about something like "If an abusive amount of > (otherwise) valid IKE messages are received, ....." and let the > implemetor decide how many IKE messages counts as abusive? OK, I see your point. > That also > avoids what to do when rekey's happen because that would likely reset > the counter because it is a new state? Well, I think the proper approach is to measure the rate of such exchanges (per SA or course). So, just reset the counter every second and measure how many exchanges happened within the second. If the number looks abusive, take measures. >>> If the peer creates too many Child SA with the same or overlapping >>> Traffic Selectors, implementations can respond with the >>> NO_ADDITIONAL_SAS notification. >>> >>> I think this requires normative language, eg: implementations MUST respond >>> with a NO_ADDITIONAL_SAS notification. The same for the next bullet item >>> where it says "implementations can introduce an artificial delay", which >>> should be like: "MAY introduce an artificial delay" (or even SHOULD, or >>> rewrite "too many" to "many" and use MAY) >> >> I'd use MAY and keep "too many". "Too many" means here that a peer is at >> least misbehaved, while just "many" doesn't imply this >> (in my reading). > > You cannot say "too many" and "MAY". If it is too many, it is abusive. > So you MUST take action. On the other hand if you say "many", then you > leave it open to interpretation whether it is abuse or not, and you can > use "MAY". I see. Language differences :-) Ok, let's remove "too". >>> Section 5 switchs from talking about "the Responder" to "the >>> implementation". >>> I think it should be "the Responder" throughout the document. >> >> OK. >> >>> the retransmitted messages should be silently discarded. >>> >>> That should be normative too, MUST be discarded. >> >> Agree. > > Paul Thank you, Valery. From nobody Fri Jun 3 07:29:51 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFEB12D510; Fri, 3 Jun 2016 07:29:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160603142950.1484.39480.idtracker@ietfa.amsl.com> Date: Fri, 03 Jun 2016 07:29:50 -0700 Archived-At: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, Kathleen.Moriarty.ietf@gmail.com, david.waltermire@nist.gov Subject: [IPsec] ipsecme - Update to a Meeting Session Request for IETF 96 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 14:29:50 -0000 An update to a meeting session request has just been submitted by David Waltermire, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: D. Waltermire Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: saag tls curdle tcpinc sacm mile cfrg Second Priority: 6tisch lwig ace httpauth Third Priority: uta 6lo dane tcpm netmod Special Requests: --------------------------------------------------------- From nobody Fri Jun 3 09:24:32 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9707712D0BB for ; Fri, 3 Jun 2016 09:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiOUaiN5xwjf for ; Fri, 3 Jun 2016 09:24:29 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE7512D6FB for ; Fri, 3 Jun 2016 09:14:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rLq0j1M7nz5Bm; Fri, 3 Jun 2016 18:14:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id upfZuUs3o7eE; Fri, 3 Jun 2016 18:14:11 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 3 Jun 2016 18:14:11 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C9566322DC8; Fri, 3 Jun 2016 12:14:10 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca C9566322DC8 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C3875406B71E; Fri, 3 Jun 2016 12:14:10 -0400 (EDT) Date: Fri, 3 Jun 2016 12:14:10 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: Message-ID: References: <4200F5373D5542C985F3D4C51609213C@buildpc> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 16:24:30 -0000 On Fri, 3 Jun 2016, Valery Smyslov wrote: [ cut everything we agreed ] >> > > Depending on the Responder implementation, this can be repeated >> > > with >> > > the same half-open SA. >> > > >> > > I don't think this "depends on the implemention". Since any on-path >> > > attacker can spoof rubbish, a Responder MUST ignore the failed packet >> > > and remain ready to accept the real one for a certain about of time. >> > >> > "Depending on the Responder implementation" means here that if along >> > with discarding the failed packet the Responder also discards the >> > computed SK_* keys, then it will need to re-calculate them again >> > when the next IKE_AUTH packet is received, so the attack can be >> > repeated. The SK_* keys don't depend on IKE_AUTH messages, >> > so in general there is no need to discard them even if the received >> > IKE_AUTH packet failed to decrypt properly, and the draft advises to >> > keep them in this case. However, implementations may have good reasons >> > to do this (e.g. to free hardware resources if crypto is performed in >> > HW). >> >> Oh, I didnt realise you talked about re-using DH components. Ok, in that >> case it makes sense but you might want to say it only applies to those >> who re-use DH calculations between different IKE peers. Our software >> never does that (and I think FIPS also puts additional constraints on >> this) > > No, it is not about re-using DH private key with different peers. I probably > poorly explained. Let me try again. > > Once the IKE_SA_INIT is complete the responder has all needed data > to calculate SKEYSEED and SK_* keys. However, it is a CPU consuming > operations, so the responder may want to postpone them until the keys are > really needed, i.e. until it receives the IKE_AUTH request from the > initiator. > This behaviour allows responder not to waste resources in case IKE_SA_INIT > was from an attacker and IKE_AUTH request never comes. > Once IKE_AUTH request arrives the responder performs DH, calculates SKEYSEED > and SK_* keys that allows him to decrypt and verify this request. In case it > fails > to decrypt IKE_AUTH request, the responder has two possibilities - keep just > calculated SK_* keys until the next (hopely proper) IKE_AUTH > request is received or discard them (e.g. to save crypto resources) and > recalculate them again once the next IKE_AUTH request is received (note > that re-calculating will result in EXACTLY the same keys, since they don't > depent on any data from IKE_AUTH). The draft recommends to keep the keys > until the proper IKE_AUTH request is received (or until the exchange timed > out). This advise may look obvious, but I think is still worth to mention. > > I recall we've already discussed this while reviewing the -05 version... Ohh okay. I vaguely remember. I guess reading this explanation, I would say it should not be needed to mention it in this document, but it you want to do it anyway, how about: OLD: Depending on the Responder implementation, this can be repeated with the same half-open SA. NEW: If a Responder does not hold on to the calculated SKEYSEED and SK_* keys (which it should in case a valid IKE_AUTH comes in later) this attack might be repeated on the same half-open SA. >> > Please, see above. >> > >> > Do you think more explanationa are needed here? >> >> No I guess it is fine. > > Are you sure after the above explanation? No, see above :) >> > Will the following text make you happy? >> > >> > Many retransmission policies in practice wait one or two seconds >> > before retransmitting for the first time. >> >> It would be nicer to rewrite it without mentioning any absolute times. >> That way the text will also remain more relevant in the future if/when >> these timings change. > > I don't think it is a good idea. The draft should give implementers some > estimate timings. "One or two seconds" is here a "worst case". If > Implementers > take this data into consideration when selecting the short timeout, > they'll always be on the safe side, because if some implementations > retransmit > more aggressively, then they'll always fit within this time period. > > So I'd rather keep the text as above. I'm okay with that. >> > > For IPv6, ISPs assign between a /48 and a /64, so it makes sense >> > > to use >> > > a 64-bit prefix as the basis for rate limiting in IPv6. >> > > >> > > Why does that make sense over using /48 ? Wouldn't you rather rate >> > > limit >> > > some innocent neighbours over not actually defending against the >> > > attack? >> > > If puzzles work as advertised, real clients on that /48 should still >> > > be >> > > able to connect. >> > >> > Well, I'm not an IPv6 expert. Probably Michael Richardson (who suggested >> > this change) or somebody else will comment on this. >> >> This does not so much relate to IPv6 but to whether you rather >> overestimate or underestimate the attacker's IP space. If you >> underestimate, you will take longer to punish the attacking IPs. If you >> overestimate you will needlessly slow down legitimate clients. >> >> I don't know which of the two is better, hence my objection to "it makes >> sense" because I don't see that. > > What's your suggestion for this text? Just remove "it make sense" or > completely rewrite the para? If the latter, please provide the text. Something like: For IPv6, ISPs assign between a /48 and a /64, so it does not make sense for rate-limiting to work on single IPv6 IPs. Instead, ratelimits should be done based on either the /48 or /64 of the misbehaving IPv6 address observed. >> > > Regardless of the type of rate-limiting used, there is a huge >> > > advantage in blocking the DoS attack using rate-limiting for >> > > legitimate clients that are away from the attacking nodes. In >> > > such >> > > cases, adverse impacts caused by the attack or by the measures >> > > used >> > > to counteract the attack can be avoided. >> > > >> > > I don't understand this paragraph at all. I guess "rate-limiting for >> > > legitimate clients" just confuses me. I think it might attempt to be >> > > saying "not blocking ranges with no attackers helps real clients", >> > > but >> > > it is very unclear. >> > >> > Yoav? So this is still pending. >> > > to calculate the PRF >> > > >> > > One does not "calculate" a PRF. One uses a PRF to calculate >> > > something. >> > >> > OK. >> >> You didn't provide text but I assume you changed it somehow. > > s/PRF/"output of PRF" or s/PRF/"the result of PRF" Is it OK? Sure. >> > > The section that starts with "Upon receiving this challenge," seems >> > > to >> > > be discussing the pros and conns of this method before it has >> > > explained >> > > the method. The reader is forced to skip this or forward to section 7 >> > > and getting back to this part. I suggest to re-order some text to >> > > avoid >> > > this, or to give a better short summary of the puzzle nature just >> > > before >> > > this paragraph. >> > >> > It describes the puzzles mechanism in general, while Sections 7 & 8 >> > describe the particular instantiation of puzzles in IKEv2. >> > I'd rather to keep some background about puzzles here, >> > so that all possible defenses are described in one place. >> >> Then I think it still requires a one-line introduction to puzzles. > > I'm a bit confused. I've been thinking that the whole Section 4.4 is a > high-level description of the puzzles. Where do you want to insert > the one-line introduction? Re-reading the section I agree with you. I guess in reviewing the document I lost toe flow of information. No change needed. >> > > When the Responder is under attack, it MAY choose to prefer >> > > previously authenticated peers who present a Session Resumption >> > > ticket (see [RFC5723] for details). >> > > >> > > Why is this only a MAY? Why is it not a SHOULD or MUST? >> > >> > A good question. I think the idea was not to force the Responder >> > to serve only resumed clients and to let him(her) prioterize >> > clients according to its own policy. In my opinion MUST is too strong, >> > but SHOULD is probably OK. >> >> In the famous words of Steve Kent, if you say SHOULD instead of MUST, >> explain when the Responder should not. > > When it has good reasons :-) > > Seriously, consider the situation when the responder finds itself > under attack and switches to only respond to IKE_SA_RESUME > requests. In this case it will leave legitimate clients without > resumption tickets (e.g. ticket expired) out of scope. > I think there is no reasom to put MUST here, since in any case > it is a local policy which dictates the responder's behaviour, > and ther are no interoperability issues whether is is MAY, SHOULD or MUST, it > is just the responder's local policy matter. > So SHOULD is just good advise. Actually, what you are describing is something else: When the Responder is under attack, it MUST NOT prefer previously authenticated peers who present a Session Resumption ticket [RFC5723] as that could cause a complete lock-out of legitimate clients that have no session to resume. Although that is probably better rewritten a bit: When the Responder is under attack, it SHOULD prefer previously authenticated peers who present a Session Resumption ticket [RFC5723] unless the attack itself consists of sending bogus resumption requests, in which case it SHOULD treat resumption and new session requests equally to avoid locking out a class of legitimate clients. >> That also >> avoids what to do when rekey's happen because that would likely reset >> the counter because it is a new state? > > Well, I think the proper approach is to measure the rate of such > exchanges (per SA or course). So, just reset the counter every second and > measure how many exchanges happened within > the second. If the number looks abusive, take measures. >From our implementation point of view "per SA" is difficult, because we delete failed SA states, and then lose the count of those. So in that sense, using global counters makes more sense. For us, a rekey means that the old state is replaced with a new state. so perhaps it is useful to elaborate a little more? Paul From nobody Sun Jun 5 09:03:24 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC8512D731 for ; Sun, 5 Jun 2016 09:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7xFOqo-V0M2 for ; Sun, 5 Jun 2016 09:03:20 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0127.outbound.protection.outlook.com [23.103.201.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 877F912D753 for ; Sun, 5 Jun 2016 09:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=au+bfuKUu2OAgk1rcmbCJMV5C1rrdWV85kbUjJ/0e5Q=; b=EVlKjffvrI73eqr/t7bfMJprga+ZXpxyafep/W1PdJ175Igd2uYjDu4typGPv+MzlMvx0CKQBMyOmGhl4tWaIsRjS81ow+NV2svNm0jlOvTYbDDNhnK65CZC3/HG5seXhaJyT44MUHzes+kceRMTX/ml3shUcaXnWHH9I/+CpTA= Received: from DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) by DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) with Microsoft SMTP Server (TLS) id 15.1.506.9; Sun, 5 Jun 2016 16:02:38 +0000 Received: from DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) by DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) with mapi id 15.01.0506.014; Sun, 5 Jun 2016 16:02:38 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document Thread-Index: AdG/QdJ7yDaA38r6SPqACsa9vNxuhQ== Date: Sun, 5 Jun 2016 16:02:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 9c67e8ca-2bce-4d9c-38e0-08d38d5ad12c x-microsoft-exchange-diagnostics: 1; DM2PR09MB0365; 5:R2j3eYJuhdsQ7gVz7cC6t0MaXlIKa25GLmpDq8XIdkdjdXj0l2ZA7ZGmA05+cz3gpXJPC9q1jd5cCTCewjxoCTLYfQCU/syMyZuALLawyygLz+4fMqDCe7Y5OB0u+0Tmx8htczeTnO+uZNlK6Kt0RA==; 24:0r2c16HJFmjDbR+a4MSBTN7Xwuk+xef01j6br8wDDxH8dOJLsrijDiJ4fWF/UG74JCP11Pu09XEfA29QLPB9f9uUggRO7scgY2tvKZdkFIE=; 7:tf+s2+wqoJeOD0gjtTBTFoQD4PxhHYseZAPcb3fJqDfmHdbC8jyeehOJyB5QMG54RMTNJVq2caXTb87Rld6KIHyflJOA6zFAveeXeM1VirzCID51hEuYjs9ezAyhVMN3vbXLT59U7vT4u3rE1xuDxccLpT+ljTjutsP2vpteENCNBA0od1W3kch5PVFVYKUMf1qJityhmJGi+6fchmFAeyJ0A8x8aCxHV3bL0SYjnpw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0365; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:DM2PR09MB0365; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0365; x-forefront-prvs: 09645BAC66 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2906002)(8936002)(9686002)(3280700002)(3660700001)(81166006)(77096005)(2900100001)(10400500002)(8676002)(5003600100002)(11100500001)(230783001)(122556002)(229853001)(15975445007)(450100001)(5004730100002)(66066001)(107886002)(76576001)(586003)(50986999)(189998001)(92566002)(3846002)(6116002)(86362001)(102836003)(5002640100001)(99286002)(19580395003)(54356999)(110136002)(87936001)(5008740100001)(33656002)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0365; H:DM2PR09MB0365.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2016 16:02:37.9343 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0365 Archived-At: Subject: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 16:03:22 -0000 This is the official call for adoption of https://datatracker.ietf.org/doc/= draft-pauly-ipsecme-tcp-encaps/ as an IPSecME working group (WG) document.= =20 By adopting this draft the WG is agreeing to take this on as an official WG= item to continue work on the draft. Please reply with any comments support= ing or concerns against adopting to the mailing list. This call will run un= til Friday, June 17th UTC 23:59. Thanks, Dave and Tero From nobody Sun Jun 5 09:59:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA70812D135 for ; Sun, 5 Jun 2016 09:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.326 X-Spam-Level: X-Spam-Status: No, score=-0.326 tagged_above=-999 required=5 tests=[DKIM_ADSP_ALL=1.1, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJwNrJAUunlN for ; Sun, 5 Jun 2016 09:59:00 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22C012B010 for ; Sun, 5 Jun 2016 09:59:00 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rN3vP2pPxz3Cj for ; Sun, 5 Jun 2016 18:58:57 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yVy9Cz_iazP2 for ; Sun, 5 Jun 2016 18:58:55 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Sun, 5 Jun 2016 18:58:55 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DD0FB677A7E; Sun, 5 Jun 2016 12:58:54 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca DD0FB677A7E Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D7D3542D0FB3 for ; Sun, 5 Jun 2016 12:58:54 -0400 (EDT) Date: Sun, 5 Jun 2016 12:58:54 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 16:59:02 -0000 On Sun, 5 Jun 2016, Waltermire, David A. (Fed) wrote: > > This is the official call for adoption of https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ as an IPSecME working group (WG) document. > > By adopting this draft the WG is agreeing to take this on as an official WG item to continue work on the draft. Please reply with any comments supporting or concerns against adopting to the mailing list. This call will run until Friday, June 17th UTC 23:59. I am in favour of adoption, and will continue to review the document. Paul From nobody Sun Jun 5 10:21:25 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DE612B040 for ; Sun, 5 Jun 2016 10:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38NJO6FHLsDc for ; Sun, 5 Jun 2016 10:21:21 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8383112B010 for ; Sun, 5 Jun 2016 10:21:21 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id n184so61399403wmn.1 for ; Sun, 05 Jun 2016 10:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Ddvd7PoKx/B2okcbQ79eONmvwh75OtRtDgu3txGo4M=; b=ho+KrH6fqc6Abp6Mg5kUzt+nWWOraqhkSqqr3oTXD551oaiKqBcJYnd7rmXkqUPtLP ZMD/JLScoUR+8KSelyU8y9X3LiTlg5S0knkDOl+RFn47rygTgQMSSgHnmRlMM15tVkL5 Op599frW+s2jq5JI4Se2LiWdH4M1MzFPVs0U2OHjND6lTvRMMnXx3wWX8YwnwgKpYv69 kGn777irbErjRJtd3EtQbNIdryn/K9zScvtTrDTkPtR6c7bmlUyVo3iwJj9FqIvJZQzy wxt972cfgiFpLg9AIVy0ZbB2O7O0BJx+05BGZhhKxV5j4fy+1SJGL4nObs9+24SKJu4F Jpiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Ddvd7PoKx/B2okcbQ79eONmvwh75OtRtDgu3txGo4M=; b=KgbMEWJUoCOu1Tv9XijC8Q0p7WJwGkbhTy3ff8PPvpXY+KpD4NYxjtcElOHKcE8JuB NeZBIkK7XCnqc9qPg5KahNgkG9DmuhbBnI2bJTUfiTU52D1WGONWGHyp23RGTXVEqh9X dy7cD6K9X0Vdv81dTot0y6sgzO6Usk1HDd2G+5p9WiHgTBDZ1CdVzk4033++WkPIQoUW yGeXS0pjQWwBiGsWuhNgbtdSKZCXqB2dkVGQKbXvORxG+legejzuDmISwgbnxCN0YQCB j2wGaLJ5qF9naGLhDq2m+D4HGiT5W9qeQIIrxtjUfAuuCJGSf9L1s60vko2t6vpc7emk GtnQ== X-Gm-Message-State: ALyK8tKzCsdDhmfF5TRGblgo1JZaYzNMqyM9yHy/Y6x3OLshPSuBvkP5tOLqJxqJDyIJ4g== X-Received: by 10.194.206.39 with SMTP id ll7mr11689872wjc.179.1465147280022; Sun, 05 Jun 2016 10:21:20 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id v125sm10028765wmv.17.2016.06.05.10.21.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 05 Jun 2016 10:21:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Sun, 5 Jun 2016 20:21:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Wouters X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2016 17:21:23 -0000 > On 5 Jun 2016, at 7:58 PM, Paul Wouters wrote: >=20 > On Sun, 5 Jun 2016, Waltermire, David A. (Fed) wrote: >=20 >> This is the official call for adoption of = https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ as an = IPSecME working group (WG) document. >>=20 >> By adopting this draft the WG is agreeing to take this on as an = official WG item to continue work on the draft. Please reply with any = comments supporting or concerns against adopting to the mailing list. = This call will run until Friday, June 17th UTC 23:59. >=20 > I am in favour of adoption, and will continue to review the document. As will I. And although I do not speak for my company, we are very interested in = implementing a mechanism such as this in our remote access client and = server when we add IKEv2 support. We already have a similar mechanism = for our IKEv1 client. Yoav From nobody Sun Jun 5 23:33:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AE412D1A2 for ; Sun, 5 Jun 2016 23:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.209 X-Spam-Level: * X-Spam-Status: No, score=1.209 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpemQh0PbSAG for ; Sun, 5 Jun 2016 23:33:01 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A25C12D0E9 for ; Sun, 5 Jun 2016 23:33:00 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id w16so87883324lfd.2 for ; Sun, 05 Jun 2016 23:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-transfer-encoding; bh=5NZso0SFIUAkFlzpkPA/CeGSIXcMUu8cdY7UwPdoc2U=; b=nG8G9xgD7qhqx9BXWbTBKzTmYfD0KAhRzSCWKzLlIxNzI/7sqaCNFE2nPDaev9Dcv9 mNTKefDScCojaIOWQ39oB+OcSwV5mFAoi1QSdxvOoIGJYqvB6l1Q4y/pNEKGQxSliyDH boGwtE71zfe2l6zra7S8mv31QxHijSR4V1985CP98y+7MOPAjjyygX0SDdce+MMEZDlU BXfE6zz5+WcHFHw6p/uUocN/fmO+4aD48GZ5XNGBJF/ivY4kMoE2OZW3ZkLrJdPaGFPm MkYvJtGm8OmlpXsFPotbVeQuglJywinG6H+vyGklwkHXyB+q376q8KeK7Y01pIaHipbT 2Ing== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=5NZso0SFIUAkFlzpkPA/CeGSIXcMUu8cdY7UwPdoc2U=; b=EYnirXeqCYVaLTcaQs2oYpVagdw/wStyzzJnPLHXZB6gsSqDP1WTJTzA1CPca1M9mp FTm8zLPQgOXe73SmTOB8yKaTOqYPt9SECw6lfsb415EDsWYiB+gnYJI5/P/SsEo4ZMM2 wGG3zzImhFEhPnZcE/OY1TNlm+TxE2TXJfZ3lf958HwwLs6B/fAJyUO2vOp1ZTVGQPEM o7NylMoRuRLpUSGJOtEoAf0HcFX6ZKYKID/AgNHivdqJgX3FQ75VYEKcXYh31n+lMMJb OoIwqd4Y+cfE8Xnx401MDNmGimoxhSNiBAZvy7b6OredjOdyuMHY0Pzxjq6hVvTJj67m SOvQ== X-Gm-Message-State: ALyK8tIT1e63wHr0lRtP2xFSZ3W6MQP8MJ6uabJV4tcjN5nSNRCunk6V0EtfAeGWRxZW5A== X-Received: by 10.25.145.140 with SMTP id t134mr653898lfd.231.1465194778725; Sun, 05 Jun 2016 23:32:58 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id m4sm1696175lfg.16.2016.06.05.23.32.57 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Jun 2016 23:32:57 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Waltermire, David A. \(Fed\)" , "IPsecME WG" References: Date: Mon, 6 Jun 2016 09:32:48 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 06:33:03 -0000 > This is the official call for adoption of https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ as an > IPSecME working group (WG) document. > > By adopting this draft the WG is agreeing to take this on as an official WG item to continue work on the draft. Please > reply with any comments supporting or concerns against adopting to the mailing list. This call will run until Friday, > June 17th UTC 23:59. > > Thanks, > Dave and Tero I think that if there is some interest in using stream transport for IKE, then it is better to have a standard solution than to have a set of proprietary ones. So, I support adopting the draft. Regards, Valery. From nobody Mon Jun 6 00:26:34 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A6212B078 for ; Mon, 6 Jun 2016 00:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNJiObWQH1_t for ; Mon, 6 Jun 2016 00:26:31 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6699712B02E for ; Mon, 6 Jun 2016 00:26:30 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id b73so88588867lfb.3 for ; Mon, 06 Jun 2016 00:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=2yufaZrzbJTq5enXRlmg9QnPLn9rmOybpm3kbNr38TA=; b=op/6YWHt5dC3w2bfncb76CMiALY7cpc7WuKrhqTokRKOVLThRTD3VmxHYTE8PVF4qA lceGDcSA9SH0USkGq1WfFI4J6yshvV3iKTdS6CT55lKJBwrlGbnIx2l/9AqliRS45Amw YbdmwnrCeEWdQU1pJt0FE5QkAwS7v19swsVn2M3knLHLGbybOOhcVtd31/U2qHGUrkLp 8XNsvhArcxrh6IHio7eCS5cKclB32R9aQrI3pft11/NzLs0IzbUse7ulRz+jBm8B36Ke BMHw6jRCo/4J9IyRTfNq/u2cNUbbEpeDfbXxtXStPTu7VWJ/LGNJxZX7tzmbLPA0vPk9 QQ3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=2yufaZrzbJTq5enXRlmg9QnPLn9rmOybpm3kbNr38TA=; b=lUCGz+2zdysOYttzjCncoWWgNKRcpy4l+E9A1KSzfHhwD7SD9pYaFg+INMiuLVhtIs 78NvtZFN65+//10wgQ3A5gHtr8EleAxmIUhnvA3IyNoxCunTFk5oJRW+Xrf2tXjpR67i m2m2cRJVCBHuAs5K0CuQ0uBbnvsGzqIxv20Ri+7+90wcnpD8ANtfkX0eZ6ZdcxZu+olx D4ASbjPA1Ym6h5YgoSsW3sPQWREb8WqoSR5DC9qyJNc27F66jCV41WAx8+Nam2psHYPq fvTc1FTg8n/xjPxDg47vAelIWmpgBGEjD2qlbVq1aGNvCSJVokLHP9yCoVB68QcmDBLv wQ9w== X-Gm-Message-State: ALyK8tKhE+0Y4lev5hRwGIGDWfL5kSDiekSXj4WJGWgr8MS2ZSXlwUnzyNjZppj1nQeT3w== X-Received: by 10.25.25.2 with SMTP id 2mr1064810lfz.149.1465197988412; Mon, 06 Jun 2016 00:26:28 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id m8sm1749007lfe.15.2016.06.06.00.26.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2016 00:26:27 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <4200F5373D5542C985F3D4C51609213C@buildpc> Date: Mon, 6 Jun 2016 10:26:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 07:26:33 -0000 > [ cut everything we agreed ] > >>> > > Depending on the Responder implementation, this can be repeated >>> > > with >>> > > the same half-open SA. >>> > > >>> > > I don't think this "depends on the implemention". Since any on-path >>> > > attacker can spoof rubbish, a Responder MUST ignore the failed packet >>> > > and remain ready to accept the real one for a certain about of time. >>> > >>> > "Depending on the Responder implementation" means here that if along >>> > with discarding the failed packet the Responder also discards the >>> > computed SK_* keys, then it will need to re-calculate them again >>> > when the next IKE_AUTH packet is received, so the attack can be >>> > repeated. The SK_* keys don't depend on IKE_AUTH messages, >>> > so in general there is no need to discard them even if the received >>> > IKE_AUTH packet failed to decrypt properly, and the draft advises to >>> > keep them in this case. However, implementations may have good reasons >>> > to do this (e.g. to free hardware resources if crypto is performed in >>> > HW). >>> >>> Oh, I didnt realise you talked about re-using DH components. Ok, in that >>> case it makes sense but you might want to say it only applies to those >>> who re-use DH calculations between different IKE peers. Our software >>> never does that (and I think FIPS also puts additional constraints on >>> this) >> >> No, it is not about re-using DH private key with different peers. I probably >> poorly explained. Let me try again. >> >> Once the IKE_SA_INIT is complete the responder has all needed data >> to calculate SKEYSEED and SK_* keys. However, it is a CPU consuming >> operations, so the responder may want to postpone them until the keys are >> really needed, i.e. until it receives the IKE_AUTH request from the >> initiator. >> This behaviour allows responder not to waste resources in case IKE_SA_INIT >> was from an attacker and IKE_AUTH request never comes. >> Once IKE_AUTH request arrives the responder performs DH, calculates SKEYSEED >> and SK_* keys that allows him to decrypt and verify this request. In case it >> fails >> to decrypt IKE_AUTH request, the responder has two possibilities - keep just >> calculated SK_* keys until the next (hopely proper) IKE_AUTH >> request is received or discard them (e.g. to save crypto resources) and >> recalculate them again once the next IKE_AUTH request is received (note >> that re-calculating will result in EXACTLY the same keys, since they don't >> depent on any data from IKE_AUTH). The draft recommends to keep the keys >> until the proper IKE_AUTH request is received (or until the exchange timed >> out). This advise may look obvious, but I think is still worth to mention. >> >> I recall we've already discussed this while reviewing the -05 version... > > Ohh okay. I vaguely remember. I guess reading this explanation, I would > say it should not be needed to mention it in this document, but it you > want to do it anyway, how about: > > OLD: > > Depending on the Responder implementation, this can be repeated with > the same half-open SA. > > NEW: > > If a Responder does not hold on to the calculated SKEYSEED and SK_* > keys (which it should in case a valid IKE_AUTH comes in later) this > attack might be repeated on the same half-open SA. OK. >>> This does not so much relate to IPv6 but to whether you rather >>> overestimate or underestimate the attacker's IP space. If you >>> underestimate, you will take longer to punish the attacking IPs. If you >>> overestimate you will needlessly slow down legitimate clients. >>> >>> I don't know which of the two is better, hence my objection to "it makes >>> sense" because I don't see that. >> >> What's your suggestion for this text? Just remove "it make sense" or >> completely rewrite the para? If the latter, please provide the text. > > Something like: > > For IPv6, ISPs assign between a /48 and a /64, so it does not make sense > for rate-limiting to work on single IPv6 IPs. Instead, ratelimits should > be done based on either the /48 or /64 of the misbehaving IPv6 address > observed. OK. >>> > > When the Responder is under attack, it MAY choose to prefer >>> > > previously authenticated peers who present a Session Resumption >>> > > ticket (see [RFC5723] for details). >>> > > >>> > > Why is this only a MAY? Why is it not a SHOULD or MUST? >>> > >>> > A good question. I think the idea was not to force the Responder >>> > to serve only resumed clients and to let him(her) prioterize >>> > clients according to its own policy. In my opinion MUST is too strong, >>> > but SHOULD is probably OK. >>> >>> In the famous words of Steve Kent, if you say SHOULD instead of MUST, >>> explain when the Responder should not. >> >> When it has good reasons :-) >> >> Seriously, consider the situation when the responder finds itself >> under attack and switches to only respond to IKE_SA_RESUME >> requests. In this case it will leave legitimate clients without >> resumption tickets (e.g. ticket expired) out of scope. >> I think there is no reasom to put MUST here, since in any case >> it is a local policy which dictates the responder's behaviour, >> and ther are no interoperability issues whether is is MAY, SHOULD or MUST, it >> is just the responder's local policy matter. >> So SHOULD is just good advise. > > Actually, what you are describing is something else: > > When the Responder is under attack, it MUST NOT prefer previously > authenticated peers who present a Session Resumption ticket [RFC5723] > as that could cause a complete lock-out of legitimate clients that > have no session to resume. > > Although that is probably better rewritten a bit: > > When the Responder is under attack, it SHOULD prefer previously > authenticated peers who present a Session Resumption ticket [RFC5723] > unless the attack itself consists of sending bogus resumption requests, > in which case it SHOULD treat resumption and new session requests > equally to avoid locking out a class of legitimate clients. I'd rather change it a bit: When the Responder is under attack, it SHOULD prefer previously authenticated peers who present a Session Resumption ticket [RFC5723]. However, the Responder SHOULD NOT swich to resumed clients completely (and thus refuse every IKE_SA_INIT request), so that legitimate initiators without resumption tickets still have chances to connect. >>> That also >>> avoids what to do when rekey's happen because that would likely reset >>> the counter because it is a new state? >> >> Well, I think the proper approach is to measure the rate of such >> exchanges (per SA or course). So, just reset the counter every second and >> measure how many exchanges happened within >> the second. If the number looks abusive, take measures. > > From our implementation point of view "per SA" is difficult, because we > delete failed SA states, and then lose the count of those. So in that > sense, using global counters makes more sense. For us, a rekey means > that the old state is replaced with a new state. I don't see any problem here. We are talking not about failed exchanges (after which the SA must be deleted), but about an abusive number of unnecessary exchanges, which are successful from IKEv2 point of view. You can very well count their number per SA and it is not a big deal to reset counters when IKE SA is rekeyed. > so perhaps it is useful to elaborate a little more? Isn't all this a local matter of implementation? I don't think we need to mandate how implementations decide whether they are under attack. > Paul Regards, Valery. From nobody Mon Jun 6 04:18:36 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E761C12D11F; Mon, 6 Jun 2016 04:18:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160606111834.20866.53924.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 04:18:34 -0700 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-pauly-ipsecme-tcp-encaps in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 11:18:35 -0000 The IPSECME WG has placed draft-pauly-ipsecme-tcp-encaps in state Call For Adoption By WG Issued (entered by D. Waltermire) The document is available at https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ From nobody Mon Jun 6 09:35:24 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D9812D82A for ; Mon, 6 Jun 2016 09:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.537 X-Spam-Level: X-Spam-Status: No, score=-5.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pargsPsdv1l for ; Mon, 6 Jun 2016 09:35:21 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2FB12D853 for ; Mon, 6 Jun 2016 09:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1465230498; x=2329144098; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=JAqMOIFDCwNEoRE/5TBE4Qyau/u50TbAHgSBoLGXcQQ=; b=MDMPNzReY/u/wnkFBnwQPi9zaFJqIUgdzI54C3cpItWloPclQ3mI/8m2qCIeXfFI qi4Au8R44/szjdc1Z81gnbMj6EcdHlzJWPDuHzsQr82Fd1uPRxz4r6T8K4gBqxYq bRO/oMDjN+3IpjIbqSYbfk7kY5odoJDFoOm1yp2TtKo4MC3P9Kn5xhWslxFpFonR fV0zOk6bS0PNQIRCFhwAiJHaEW73Fvy/plNYILpzjNSJcklbjgFIHEazHHkkqa1c zFfUKeuSks6E7lDZ6CXv0yiwH3VXI9bk6rpIyaljUwgqLueUbJnFHu9/zy38R5f/ syIcuI6BnXYW9rBh/BywTg==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 0E.AD.21445.1A4A5575; Mon, 6 Jun 2016 09:28:18 -0700 (PDT) X-AuditID: 11973e12-f79796d0000053c5-27-5755a4a12aef Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 6F.C6.09064.F94A5575; Mon, 6 Jun 2016 09:28:16 -0700 (PDT) Received: from da0602a-dhcp199.apple.com (da0602a-dhcp199.apple.com [17.226.23.199]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O8C00MW5Z33W250@nwk-mmpp-sz09.apple.com> for ipsec@ietf.org; Mon, 06 Jun 2016 09:28:15 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.0 \(3186\)) From: Tommy Pauly In-reply-to: Date: Mon, 06 Jun 2016 09:28:16 -0700 Content-transfer-encoding: quoted-printable Message-id: <0F2BC705-BF55-4DBC-9A8C-336C15A2D26F@apple.com> References: To: "Waltermire, David A. (Fed)" X-Mailer: Apple Mail (2.3186) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUi2FAYobtoSWi4waNNLBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuSDL9kKLnNUNOyZwNLA2MrexcjJISFgInH88Xo2CFtM4sI9 EJuLQ0hgL6PEp7PvWWGKNq7vYoFILGOS2L/sDxOEs4tJ4vWZA0AOB4ewgITE5j2JIA3MAloS 63ceZwKxeQX0JebP/c8MYgsLpEjsfHgJbBubgIrE8W8bwOKcAvESb1regsVZBFQlJs7/yQ4x R16i9/9GRghbW+LJuwusEDNtJM40zQGzhQTiJObeOsECYosAxS9MfsAKco6EgKzElcUSIGdK CCxhkzj15CTzBEaRWUjOm4XkvFlIVixgZF7FKJSbmJmjm5lnopdYUJCTqpecn7uJERTe0+2E djCeWmV1iFGAg1GJh3dFfki4EGtiWXFl7iFGaQ4WJXFedt/gcCGB9MSS1OzU1ILUovii0pzU 4kOMTBycUg2Mro+Wu+mqBFgwyORMWSnaed7fJk3tR77YuodBS+8xrVdVL/vueGt6hNPx+6xc SjkVr6fFqWnue6X12/6BrZma8FrDJ3dLbGdUTNMq6P4eoq1yXVWrdarVQvmJp2W27avUitu+ 8u8NkeKJEqsfm202kFiq7bTGYbZI2Dup886TjyVxiz1cFrNYiaU4I9FQi7moOBEAbVWgeFAC AAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUi2FAcoLtgSWi4wcFzFhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuSDL9kKLnNUNOyZwNLA2MrexcjJISFgIrFxfRcLhC0mceHe erYuRi4OIYFlTBL7l/1hgnB2MUm8PnMAyOHgEBaQkNi8JxGkgVlAS2L9zuNMIDavgL7E/Ln/ mUFsYYEUiZ0PL7GB2GwCKhLHv20Ai3MKxEu8aXkLFmcRUJWYOP8nO8QceYne/xsZIWxtiSfv LrBCzLSRONM0B8wWEoiTmHvrBNihIkDxC5MfsIKcIyEgK3FlscQERsFZSC6aheSiWUimLmBk XsUoUJSak1hpqpdYUJCTqpecn7uJERyOhRE7GP8vszrEKMDBqMTDy1AUEi7EmlhWXJl7iFGC g1lJhNdhYWi4EG9KYmVValF+fFFpTmrxIcZkoF8mMkuJJucDYyWvJN7QxMTAxNjYzNjY3MSc NGElcd7z9/3ChQTSE0tSs1NTC1KLYLYwcXBKNTA28nSd+Mplxbrw3K0ddr+lpzon7lvKfc5o X+VZ172VfIfkbhSarj3xvn/n0tMG6j2znjxm+vFvQsTDjNkzlmiINm1hXmlRxRlbN60/Z/Jz /QnKAp9eL1zz5cXbVU8/MF9exiRT3yz5/M7ECLvTt6PmTJl9Y+1NIXUFufqU6i1LjudkHmS+ WfMmVImlOCPRUIu5qDgRAIlJqdKLAgAA Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 16:35:22 -0000 As an author, I support the adoption of this draft. We do plan on = incorporating the feedback from previous versions of the draft into the = first working group version of the document, if adopted. We are also = want to get this feature implemented for iOS and Mac OS X, and would = love to work with other implementations to do interoperability testing. Thanks, Tommy > On Jun 5, 2016, at 9:02 AM, Waltermire, David A. (Fed) = wrote: >=20 > This is the official call for adoption of = https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ as an = IPSecME working group (WG) document.=20 >=20 > By adopting this draft the WG is agreeing to take this on as an = official WG item to continue work on the draft. Please reply with any = comments supporting or concerns against adopting to the mailing list. = This call will run until Friday, June 17th UTC 23:59. >=20 > Thanks, > Dave and Tero >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jun 6 14:25:27 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7714612B00D for ; Mon, 6 Jun 2016 14:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7jHRDRw7oot for ; Mon, 6 Jun 2016 14:25:23 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768C412D92F for ; Mon, 6 Jun 2016 14:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7550; q=dns/txt; s=iport; t=1465248322; x=1466457922; h=from:to:subject:date:message-id:mime-version; bh=x1sWQ7xBVsg20s8KEhSgWm0SWgnxL59ceDnxJi97dHY=; b=mKLfxgTxLgS2dtmd+pg/uvFL9GIQWi4JmuZ1n8AmI+H1sGwtcxOhHDnf RfsE2i/YPeujwNuVy+RGl4bYSCPwhinkKbEKDSQZE28QHm3vQ6xEwoaJ+ kDQJUUWetc052K9hbcDraFYtKJktE/lT/DE8rrCiOqrAAeH21yBYu9mxm 0=; X-Files: smime.p7s : 4557 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAgBR6VVX/5FdJa1bgztWfQa6VoF5F?= =?us-ascii?q?wuFcYE5OBQBAQEBAQEBZSeERgEBBAEBARpRHQEISCULJwQBEg6IIQ67EwEBAQE?= =?us-ascii?q?BAQEDAQEBAQEBAQERCQWGJ4RNhFeFJxwFjh6KKgGDLIFpbYgjgWmEUIhlj1kBH?= =?us-ascii?q?jaCOYE1bokafwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,429,1459814400"; d="p7s'?scan'208";a="112225816" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jun 2016 21:25:21 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u56LPLFX024482 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 6 Jun 2016 21:25:21 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 6 Jun 2016 16:25:20 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.009; Mon, 6 Jun 2016 16:25:20 -0500 From: "Graham Bartlett (grbartle)" To: "Waltermire, David A. (Fed)" , "ipsec@ietf.org WG" Thread-Topic: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document Thread-Index: AQHRwDntyDaA38r6SPqACsa9vNxuhQ== Date: Mon, 6 Jun 2016 21:25:20 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.4.160422 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.146.100] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3548096718_5672950" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 21:25:25 -0000 --B_3548096718_5672950 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi The views below are personal and don=B9t reflect the company I am employed by; I=B9m in favour of this document, I believe that this will increase the adoption of IKEv2 and secure communication for mobile devices. cheers On 05/06/2016 17:02, "IPsec on behalf of Waltermire, David A. (Fed)" wrote: >This is the official call for adoption of >https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ as an >IPSecME working group (WG) document. > >By adopting this draft the WG is agreeing to take this on as an official >WG item to continue work on the draft. Please reply with any comments >supporting or concerns against adopting to the mailing list. This call >will run until Friday, June 17th UTC 23:59. > >Thanks, >Dave and Tero > > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec --B_3548096718_5672950 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIRyQYJKoZIhvcNAQcCoIIRujCCEbYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg9+MIIFbTCCBFWgAwIBAgIQDZu2aTrsxkrY+ilxZLyNgTANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTYw NTE2MDAwMDAwWhcNMTgwNTE2MTIwMDAwWjCBkDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMRwwGgYDVQQKExNDaXNjbyBTeXN0ZW1zLCBJ bmMuMRgwFgYDVQQDEw9HcmFoYW0gQmFydGxldHQxITAfBgkqhkiG9w0BCQEWEmdyYmFydGxl QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMqOS+hfMCqvKj+e gZdgQIEPbPvc6Mv9fJvK/hNbeOiOwBepKx73eSUh+gABrR8i7ui5/V7XlyMPg/OgQr/6UZX2 QGaqBNkiVkOqNDjwjDz6+voKVS2MNU0cCvxP5Xwb9VXgw2JzFAMMshknhP7G+9V6qxda7e5m fmBzYgCgewiITHD83tGiS/YuoOogmPfYnpQyCcnSdwj8MqnlvVfBQVdAOg+a7hv8zPcTA4mH H0Y3dqCIdNtj1QEm9D9YbDlCS1MZl/7byqLpEZA+la8Pva/r/lydbVuM7BXygqI+itXM9963 8kZim8zTh4r/wCi8uklBSeMRUHSmgocw5BpnIk8CAwEAAaOCAeswggHnMB8GA1UdIwQYMBaA FOcCI4AAT9jXvJQL2T90OUkyPIp5MB0GA1UdDgQWBBQmnj6AyXbjUyNRGN6Y2JOK17/CkzAM BgNVHRMBAf8EAjAAMB0GA1UdEQQWMBSBEmdyYmFydGxlQGNpc2NvLmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZI AYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUH MAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2Vy dHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0B AQsFAAOCAQEAna7Ws4vfNhrcm0Od6wb6xiOBURSSXAgX7LE8chrD7UfTF+b7DKits6QY1Vvo 5s0ryCy2T4ikMMKzpAnQ9O0vvF5wbb2iF9zTyKv2M36uY6L6EbMC7QoQAihAiOGnLy4wwhsB qtoGHPL8f1ROW2xpK3twQm2jthhv7fzHRPnFFh4bwWLLISHsw7JKzaL1GuxghNr9W9CN7o2r OtnnvoSwdkPBlMmquWrUgCZ06UQfsD6nbVDvqlBlJGBsrfXk3y8yg3q+rN6LTqHccW4Rk1KS OkE8i/8NKTo8QXHSOa+jcK0o7mnjGXERklDnFGMiNVLbVhVa9CJynUpLjNct3q6+ATCCBk4w ggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMC VVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoX DTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZ MBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1 cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kb LQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAf JUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ 9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1x GOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgw BgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0 LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1s AAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQG CCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAA dABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAA UwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIA ZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQA eQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUA aQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEL BQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mg VgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0 k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEy br1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3MIIC n6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVT MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0z MTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAX BgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQg Um9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5 cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+Y MjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nY Lxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGY M2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSS plazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8G A1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQY MBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43Jz emSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS 2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1 bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/ N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHS oyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYICDzCCAgsCAQEweTBlMQswCQYDVQQG EwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t MSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA2btmk67MZK2PopcWS8 jYEwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgzhcAew9zfiwxCWTEQqBg3GDl CyPnSdLF3keuxftO5LswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTYwNjA2MjEyNTE4WjANBgkqhkiG9w0BAQEFAASCAQCxsbwzponE2hfS929aOBrFpRcf FPL0aR5zV2GeT81HO4eTv44VxLHFYd1/wzfgqpDKUVryvbyGYwA3MTVLvQyXWRyHi87XDKJ0 ODpzLs/h8n5Ufv/m9uB13qqRvAgyYZMjhTDLmolDi9EesgX39kHDZMwfLyJY+Ym9FyfopktB EQ0p6jRf1vgo0VvTKzytBkjRuNVW2j62MrBh2N5FjSJYOrsBuWJj+MHhHKBQ/bw8aLXKFLvf Njib1cqETyywbQxgePXnjLYWJNAUou+nWNtHwKmDz1kkQhGkN0lU/VMYaEXx9HSP/uIK5+bJ tjdw/N20ynyzo8r6Mq5DdlhJ9kqg --B_3548096718_5672950-- From nobody Mon Jun 6 19:37:08 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5F312D511 for ; Mon, 6 Jun 2016 19:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzRMiu6ycc1P for ; Mon, 6 Jun 2016 19:37:05 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AD912D14F for ; Mon, 6 Jun 2016 19:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=841; q=dns/txt; s=iport; t=1465267025; x=1466476625; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=HX5KoLYjsxz0PFXze8DtTBhS/C/ceAiodyf5N5LOIks=; b=dlN4tM6VJnKM94qe1Jfybf4zS49f2/1DIuOzAswO4MyVseIbFADSEKi7 BujsXDNQTSRJWpXYMjRz0JpYAbn63/hzK64W7F2INR636MSiVasO/FlYO CRht1lqRXv1W/gKTSgirKy0bvH+xlVvHIU33swDO9xDfTTp26h3WqWbrk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgCPMlZX/5JdJa1bgzxWfQa6WoF5I?= =?us-ascii?q?oVxAoE4OBQBAQEBAQEBZSeERgEBBB0dNBsCAQgYHhAyJQIEARKILw66dwEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARcFhieETYl+HAWYSQGGAogjgWmEUohkj1sBHjaCO?= =?us-ascii?q?YE1bokQfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,431,1459814400"; d="scan'208";a="281001666" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jun 2016 02:37:04 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u572b45Y013809 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 7 Jun 2016 02:37:04 GMT Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 6 Jun 2016 21:37:03 -0500 Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1104.009; Mon, 6 Jun 2016 21:37:03 -0500 From: "Ravi Shankar Mantha (ramantha)" To: "Waltermire, David A. (Fed)" , "ipsec@ietf.org WG" Thread-Topic: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document Thread-Index: AQHRwGV5sppZa75TRkiQ2eRW1PRxoQ== Date: Tue, 7 Jun 2016 02:37:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.93.188] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 02:37:07 -0000 I am in favour of this adoption. We are planning to implement this draft in cisco mobility gateway products. We also want to work with other mobile device implementation for interoperability. Thanks, Ravi Mantha > >On 05/06/2016 17:02, "IPsec on behalf of Waltermire, David A. (Fed)" > wrote: > >>This is the official call for adoption of >>https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ as an >>IPSecME working group (WG) document. >> >>By adopting this draft the WG is agreeing to take this on as an official >>WG item to continue work on the draft. Please reply with any comments >>supporting or concerns against adopting to the mailing list. This call >>will run until Friday, June 17th UTC 23:59. >> >>Thanks, >>Dave and Tero From nobody Mon Jun 6 20:03:20 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BB212D62D for ; Mon, 6 Jun 2016 20:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5N4Uf2ku10H for ; Mon, 6 Jun 2016 20:03:17 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9439912D0C7 for ; Mon, 6 Jun 2016 20:03:17 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-c8-5756393bb3dc Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id DF.DC.03614.B3936575; Tue, 7 Jun 2016 05:02:19 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0294.000; Mon, 6 Jun 2016 23:03:15 -0400 From: Samy Touati To: "Waltermire, David A. (Fed)" , "ipsec@ietf.org WG" Thread-Topic: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document Thread-Index: AQHRwDntyDaA38r6SPqACsa9vNxuhZ/djYyA///EP4A= Date: Tue, 7 Jun 2016 03:03:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.16.0.160506 x-originating-ip: [147.117.188.11] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3548098991_1131364064" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyuXSPn661ZVi4wZwH1hYbe/6xWezf8oLN gcljyZKfTB7XTv5lDWCK4rJJSc3JLEst0rdL4Mq4cGkjU8Fp5YorS1+zNzC+Uehi5OSQEDCR +Ld/OyOELSZx4d56ti5GLg4hgaOMEnPu7odyljFKnDp8lB2kik1AR+Ly5hksILaIQIrEsvYN zF2MHBzCQPba+cwQ4VSJefOPsYGERQSsJL5PywQJswioSGz6Po0NxOYVsJe4++gRI0iJkECo xKIdviBhTgEDie/Hb4KdwyggK7H77HUmEJtZQFzi1pP5TBBnikg8vHiaDcIWlXj5+B8riC0q oCdx6t4TZoi4ksTH3/PZIXorJfquLWSBWCsocXLmE5YJjKKzkIydhaRsFpIyiLi2xJ5bW5kh bHmJzWveQtnWEjN+HWSDsBUlpnQ/ZIewTSVeH/3IuICRYxUjR2lxQU5uupHhJkZgpB2TYHPc wbi31/MQowAHoxIP7wKtsHAh1sSy4srcQ4wqQK2PNqy+wCjFkpefl6okwlusB5TmTUmsrEot yo8vKs1JLT7EKM3BoiTOq/9SMVxIID2xJDU7NbUgtQgmy8TBKdXAWPpAK2TV5/uLnnw2P53j bTXJpDY56kjLJDaDNec5Nr9ymyL3O0hDaJ1ws0z87kaPiRL1b1nTlQKf35quXVLAnaFYZWJt naw58+9jfjaHwK59vdO+LN8mqvfx038V8SUu173dQmOObljfEj0361yvCf8T4RPhZVlyudnL 1NSSbnPtULmy+7GwEktxRqKhFnNRcSIANyc9HrwCAAA= Archived-At: Subject: Re: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 03:03:19 -0000 --B_3548098991_1131364064 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Hi, I do support the adoption of this draft by the WG. Ericsson is implementing the IPSEC TCP encapsulation as described in this draft in the Wireless Mobile Gateway (WMG) node. We would like to engage with device vendors for conducting interoperability testing. Thanks Samy. On 6/6/16, 10:37 PM, "IPsec on behalf of Ravi Shankar Mantha (ramantha)" wrote: >I am in favour of this adoption. We are planning to implement this draft >in cisco mobility gateway products. >We also want to work with other mobile device implementation for >interoperability. > >Thanks, >Ravi Mantha > > > >> >>On 05/06/2016 17:02, "IPsec on behalf of Waltermire, David A. (Fed)" >> wrote: >> >>>This is the official call for adoption of >>>https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ as an >>>IPSecME working group (WG) document. >>> >>>By adopting this draft the WG is agreeing to take this on as an official >>>WG item to continue work on the draft. Please reply with any comments >>>supporting or concerns against adopting to the mailing list. This call >>>will run until Friday, June 17th UTC 23:59. >>> >>>Thanks, >>>Dave and Tero > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec --B_3548098991_1131364064 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIH+gYJKoZIhvcNAQcCoIIH6zCCB+cCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Be0wggXpMIID0aADAgECAhEAzxzmCopx75U64hFk/UYzGzANBgkqhkiG9w0BAQUFADA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MjAeFw0xNDExMTAxODMyMTRaFw0xNzExMTAxODMyMTNaMGQxETAPBgNVBAoMCEVyaWNzc29u MRQwEgYDVQQDDAtTYW15IFRvdWF0aTEnMCUGCSqGSIb3DQEJARYYc2FteS50b3VhdGlAZXJp Y3Nzb24uY29tMRAwDgYDVQQFEwdsbWNzYXRvMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAtTzHN2e42IspS2LTetBYT1X297J5UERFKNlGu1pG2pcGU/NBSwsizw/RDI/q+c42 EkEAWzJ4usb2oO4//CLw5Foboonf8N2qhwRx5O7gEEIjjSCt2Q7O4mToKM4xoNSTmRrF2war 3mnRc3g0A9T69MD2ipYU3/l7HVnAH4z+95t8FrL/oeFXuc/XgWfBGBSYY6uiyLujAZckgwWV FPN4ZMdGAZJ1AgU8tTLWafREHu3stvWcVniIQoOvJVNLHfYcnW8r/Lh0zaTSDCxusleG+YY3 aKtXGF6CyaxuI8i3GmXWI+LEjNeJUesb/WKnZAubl51efuDJvQ+MDA7dNJaDdQIDAQABo4IB vjCCAbowSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJp Y3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzAB hhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2Eu dHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIwYD VR0RBBwwGoEYc2FteS50b3VhdGlAZXJpY3Nzb24uY29tMFUGA1UdIAROMEwwSgYMKwYBBAGC DwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNv bmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU rvTqPsDyVm3LeP+8KcedI3WxmhIwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9vBsoOdnF/Szcw DgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBCT4SQnpZQ7Ur2tRXshjkw2pJJ dHA70enikN4bx2cLmhaRlPfS4/SVEXYMLiTRb58jD0N7/wobI7UAWSRlj5zHn21La1HIE0Mt dsJutSPckZWbguCAl9TgEIGdGIVXKhsanr107KLIyrSu+DwgxOLE5kx6JqgcVV2e3ZockG6s hOGXy1O83yP3muINapuuIdY6qtvPTUJ5zZqNPTCHIDrQLwNx07HVflUkS0G/Ac6W6qdfDnu8 qAE0YAxe1dajdphQK/c3pskR5X7M39t7TlZfnFIxOWco3N7odbZo/8fmjxxvfqtcHa1qBrLr qHz9Itfrn+r5KEMqQG/2WUotU6XuBSuNiDQvLt0VH324IOmlLJpTOG5pWbwIKm0Vz65NcP38 S6Qg3k1XmSYa3Nd/eBDM2S7xsx9gxlxqcGtB0HX7lRFCqNtPd1U7YqPag+fKFgs2rbkrNm9T U0jN95UnrJn0lM4zJgL2Xel2keiuySOQzI9r7NOyaEZXwtnhV3BgcIPZit3D4W6awzI/3HaZ Ub2Cr7HbrHBQAGknGpZZd00a/waLeolL5CvALtUt0KpNz1Jqk5dKGfWLJNNxy2iNFrTThVkU YDEIyyqHLSzxj+W0vq8imtNDvul+8WK/1hCw+XJb9mVb3gpXONrneo5d5oj6SolE/O46eq6+ 2jcfWcwATTGCAdUwggHRAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVy aWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDPHOYKinHvlTriEWT9RjMbMAkGBSsOAwIa BQCgXTAjBgkqhkiG9w0BCQQxFgQU25L+6aAFRPAC2+8fUmjA9bRaKmQwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNjA3MDMwMzExWjANBgkqhkiG9w0B AQEFAASCAQBg0j7S9AkOVk9a8W1JWg8IXsgPV9cyTYEPZEtbuv6gwe2+zjYWKjaqUoBdiiTf 0wV9NteUTEfyB9r8IFdtBFBl3Y5TTSIFKczpIOxNv/9KsH9+Jh8q3l5u46DAlPXOssi8bLaX iiOpCA3a2+8kBgffqREuiBTGKL7dmq7P8e4zQYpoAfphg+cv8epE2XsPvlUkQUWLyh9CRpH6 BOlefPMNs14GJxA3U1cy/l6PPq95//DKjJ9pqGfrCIG8E1bR0I/0U2yc5IcSU6ET/TA2dcVf T6jUPiOUJgtFjki1RGazYy3xoWKpHigcIMKhl6uZzizYhkt1HTU7a/NyznDMkYag --B_3548098991_1131364064-- From nobody Thu Jun 9 09:20:05 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0774012D6B8 for ; Thu, 9 Jun 2016 09:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sejVXUsUICf for ; Thu, 9 Jun 2016 09:20:01 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42F012D698 for ; Thu, 9 Jun 2016 09:20:00 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-15-57598ddec5c6 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id AD.44.09012.FDD89575; Thu, 9 Jun 2016 17:40:15 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0294.000; Thu, 9 Jun 2016 12:19:59 -0400 From: Daniel Migault To: IPsecME WG Thread-Topic: New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt Thread-Index: AQHRwmmkX06+QOUhUkeYzqC6qFN3AJ/hUEhQ Date: Thu, 9 Jun 2016 16:19:58 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> In-Reply-To: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyuXRPgu793shwg/0LhC32b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPeNS5gKdilVfPzg08B4QrGLkZNDQsBE4uLMrcwQtpjEhXvr 2boYuTiEBI4ySjR+XsQK4SxjlGhd+wOsik3ASKLtUD97FyMHh4iAvMTMG5kgYWGBQIk3S76y gNgiAkESZ69/YYMoMZL4+sAaJMwioCLx7OwRNhCbV8BXYmvLN7ApQgKOEkdW5YOEOQWcJBYs nwG2iBHonO+n1jCB2MwC4hK3nsxngjhTQGLJnvNQJ4tKvHz8jxXCVpTY1z8dbCSzgKbE+l36 EK2KElO6H7JDbBWUODnzCcsERtFZSKbOQuiYhaRjFpKOBYwsqxg5SosLcnLTjQw2MQLD/ZgE m+4OxvvTPQ8xCnAwKvHwKsRGhAuxJpYVV+YeYpTgYFYS4TXtjgwX4k1JrKxKLcqPLyrNSS0+ xCjNwaIkziv2SDFcSCA9sSQ1OzW1ILUIJsvEwSnVwGjNc9Jx6/6yiaGGmelbnY4+eMHrEpYf X7yqinPpWaZT80NPRsuffbUktj/PvHfXDt87shbs/iFvNBy6NIOOP7XI8w2a6b0ieEaIXfyf yfJT6gwl9A/eeJO44G6URNXVDy1XTt29kytweYrRpiV9EQ9lc2LWMEqm1y+ZsCl0+RGNy13N C4137VZiKc5INNRiLipOBAAa1GB8cwIAAA== Archived-At: Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 16:20:03 -0000 SGksDQoNClBsZWFzZSBmaW5kIG91ciBuZXcgcHJvcG9zYWwgd2l0aCBFU1AgdXNpbmcgaW1wbGlj aXQgSVYgWzFdLiBXZSB3b3VsZCBsaWtlIHRvIHByZXNlbnQgYW5kIGRpc2N1c3MgaXQgYXQgdGhl IG5leHQgSUVURiBtZWV0aW5nLg0KDQpXZSB3b3VsZCBiZSBoYXBweSB0byBoYXZlIHRoZSBXRyBv cGluaW9uIG9uIHdoaWNoIHlvdSB0aGluayBpcyB0aGUgYmV0dGVyIHdheSB0byBuZWdvdGlhdGUg dGhlIGltcGxpY2l0IElWIGJldHdlZW4gdHdvIHBlZXJzLiBUaGUgZGlmZmVyZW50IG9wdGlvbnMg YXJlIGRldGFpbGVkIGluIHNlY3Rpb24gNSBhbmQgY29weSBwYXN0ZSBoZXJlIGluIHRoZSBlbWFp bDoNCg0KIiIiDQogICBOZWdvdGlhdGlvbiBvZiB0aGUgdXNlIG9mIGltcGxpY2l0IElWIGNhbiBi ZSBkb25lIGluIDMgZGlmZmVyZW50DQogICB3YXlzOg0KDQogICBvICBBbiBJTVBMSUNJVCBJViBU cmFuc2Zvcm0gVHlwZS4gIEEgcHJvcG9zYWwgdGhhdCBjb250YWlucyB0aGlzDQogICAgICB0cmFu c2Zvcm0gdHlwZSByZXF1aXJlcyAoaWYgYWNjZXB0ZWQpIHRoYXQgSVBzZWMgdXNlIHRoZSBpbXBs aWNpdA0KICAgICAgSVYgYW5kIG5vdCBpbmNsdWRlIGFuIGV4cGxpY2l0IElWIGluIHRoZSBwYWNr ZXRzLiAgVG8gZmFjaWxpdGF0ZQ0KICAgICAgYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRoIG5v bi1zdXBwb3J0aW5nIGltcGxlbWVudGF0aW9ucyB0aGUNCiAgICAgIEluaXRpYXRvciBTSE9VTEQg YWRkIGFub3RoZXIgcHJvcG9zYWwgdGhhdCBkb2VzIG5vdCBpbmNsdWRlIHRoaXMNCiAgICAgIHRy YW5zZm9ybSB0eXBlIGFzIHdlbGwgYXMgY3J5cHRvZ3JhcGhpYyBzdWl0ZSB0aGUgSW5pdGlhdG9y IGRvZXMNCiAgICAgIG5vdCBzdXBwb3J0IHRoZSBpbXBsaWNpdCBJVi4NCg0KICAgbyAgQW4gSU1Q TElDSVQgSVYgVHJhbnNmb3JtIElELiAgVGhpcyBkb3VibGVzIHRoZSBudW1iZXIgb2YgRU5DUg0K ICAgICAgdHJhbnNmb3JtIElEcyBieSBjcmVhdGluZyBhbiBFTkNSX0FFU19DQ01fMTZfSUlWIGZv ciBlYWNoDQogICAgICBFTkNSX0FFU19DQ01fMTYuDQoNCiAgIG8gIEFuIElNUExJQ0lUIElWIFRy YW5zZm9ybSBBdHRyaWJ1dGUsIHdoaWNoIHdvdWxkIGJlIGFzc29jaWF0ZWQgdG8gYQ0KICAgICAg VHJhbnNmb3JtIFR5cGUgSUQsIHNwZWNpZnlpbmcgdGhlIHVzZSBvZiBhbiBpbXBsaWNpdCBJVi4g bWFya3MgYQ0KICAgICAgcGFydGljdWxhciBFTkNSIHRyYW5zZm9ybSBhcyB1c2luZyBpbXBsaWNp dCBJVnMuICBUbyBmYWNpbGl0YXRlDQogICAgICBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IHdpdGgg bm9uLXN1cHBvcnRpbmcgaW1wbGVtZW50YXRpb25zIHRoZQ0KICAgICAgSW5pdGlhdG9yIFNIT1VM RCBhZGQgYW5vdGhlciBFTkNSIHRyYW5zZm9ybSBmb3IgZWFjaCBhbGdvcml0aG0gc28NCiAgICAg IG1hcmtlZC4gIEluIG90aGVyIHdvcmRzLCBmb3IgZWFjaCBFTkNSX0FFU19DQ01fMTYgd2l0aA0K ICAgICAga2V5bGVuZ3RoPTI1NiBhbmQgSUlWPTEsIHRoZXJlIHdpbGwgbmVlZCB0byBiZSBhbiBF TkNSX0FFU19DQ01fMTYNCiAgICAgIHdpdGgga2V5bGVuZ3RoPTI1NiBhbmQgbm8gSUlWIGF0dHJp YnV0ZS4NCg0KIiIiICANCg0KWzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LW1nbHQtaXBzZWNtZS1pbXBsaWNpdC1pdi8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiBUaHVyc2RheSwgSnVuZSAwOSwgMjAxNiAxMjoxMiBQTQ0KVG86 IFRvYmlhcyBHdWdnZW1vczsgWW9hdiBOaXI7IERhbmllbCBNaWdhdWx0DQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1nbHQtaXBzZWNtZS1pbXBsaWNpdC1pdi0w MC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWdsdC1pcHNlY21lLWltcGxp Y2l0LWl2LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBEYW5pZWwg TWlnYXVsdCBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFm dC1tZ2x0LWlwc2VjbWUtaW1wbGljaXQtaXYNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlJbXBsaWNp dCBJViBmb3IgQ291bnRlci1iYXNlZCBDaXBoZXJzIGluIElQc2VjDQpEb2N1bWVudCBkYXRlOgky MDE2LTA2LTA5DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk3DQpVUkw6 ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1n bHQtaXBzZWNtZS1pbXBsaWNpdC1pdi0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZ2x0LWlwc2VjbWUtaW1wbGljaXQtaXYvDQpI dG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1nbHQtaXBz ZWNtZS1pbXBsaWNpdC1pdi0wMA0KDQoNCkFic3RyYWN0Og0KICAgSVBzZWMgRVNQIHNlbmRzIGFu IGluaXRpYWxpemF0aW9uIHZlY3RvciAoSVYpIG9yIG5vbmNlIGluIGVhY2gNCiAgIHBhY2tldCwg YWRkaW5nIDggb3IgMTYgb2N0ZXRzLiAgU29tZSBhbGdvcml0aG1zIHN1Y2ggYXMgQUVTLUdDTSwg QUVTLQ0KICAgQ0NNLCBBRVMtQ1RSIGFuZCBDaGFDaGEyMC1Qb2x5MTMwNSByZXF1aXJlIGEgdW5p cXVlIG5vbmNlIGJ1dCBkbyBub3QNCiAgIHJlcXVpcmUgYW4gdW5wcmVkaWN0YWJsZSBub25jZS4g IFdoZW4gdXNpbmcgc3VjaCBhbGdvcml0aG1zIHRoZQ0KICAgcGFja2V0IGNvdW50ZXIgdmFsdWUg Y2FuIGJlIHVzZWQgdG8gZ2VuZXJhdGUgYSBub25jZSwgc2F2aW5nIDggb2N0ZXRzDQogICBwZXIg cGFja2V0LiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRvIGRvIHRoaXMuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Thu Jun 9 19:42:34 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678DE12D675 for ; Thu, 9 Jun 2016 19:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww68UZdXW3fd for ; Thu, 9 Jun 2016 19:42:31 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2FD12D621 for ; Thu, 9 Jun 2016 19:42:31 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rQmfq0WJ5z3FD; Fri, 10 Jun 2016 04:42:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id L7_prMuUBDar; Fri, 10 Jun 2016 04:42:13 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 10 Jun 2016 04:42:13 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D2DF08DB9E; Thu, 9 Jun 2016 22:42:12 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D2DF08DB9E Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B974040BDBD5; Thu, 9 Jun 2016 22:42:12 -0400 (EDT) Date: Thu, 9 Jun 2016 22:42:12 -0400 (EDT) From: Paul Wouters To: Daniel Migault In-Reply-To: <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> Message-ID: References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 02:42:33 -0000 On Thu, 9 Jun 2016, Daniel Migault wrote: > Please find our new proposal with ESP using implicit IV [1]. We would like to present and discuss it at the next IETF meeting. I must understand it wrong... Aren't these IVs different per ESP packet? And unrelated to IKE values? How do both parties calculate the IV if it is not send as part of the packet? >From what I understand, only part of that comes from IKE (aka the salt values that are taken from the IKE KEYMAT). As far as I understand, it still needs to be unpredictable? If this IV somehow comes from IKE, it might be very tricky for FIPS certifications, because the security of the ESP IV then depends on the IKE userland. Paul From nobody Thu Jun 9 23:01:42 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE7512D151 for ; Thu, 9 Jun 2016 23:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJx_WBhK3LO3 for ; Thu, 9 Jun 2016 23:01:38 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B641A12D140 for ; Thu, 9 Jun 2016 23:01:37 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id n184so252086781wmn.1 for ; Thu, 09 Jun 2016 23:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VBzINUgfnyYKcEjFh9Tu8Jvx6lEYtj7mHEaYMJLq1XA=; b=OLGMDGRAHG37HcrgVCmVR41L3BP8qN7F15QLyjGsCLusIzwP2e5KtKMoYKGme0OpPz dxcKZgbi6RKk5W1K/otXOrgDWJhxffFbeUtQsM7ktBh4LVKHMHakKslPUFYlH8zcKXAz KbRfryo8nLmnypAJiKstKOmA0mTsUOyVOQaWK5ajfsyOeV1Rz1CsL1178Nv9NZwBpdyG Lp2jmagkI2HCMF+nIMgAH5BbCZqLM4Fd//r5LFK+hb/kzUrCXt/lg3cdo2BecCLQiwMB Wr10C+dTZZCXPn2rblA9m1ZXRYKaDB25IWMFoyKIfVzd3od+2Ri9I2W9Cr/dX2Km24as L+jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VBzINUgfnyYKcEjFh9Tu8Jvx6lEYtj7mHEaYMJLq1XA=; b=VEPlLq78i0PnRRJc2nA9riGfWgPwEK4y+YmFBnoG6kHxO25Gv31E7fiT8/pmSSUiW3 e1GrcfQClUklTxsP2VQm9p/mlSfpLAo8sUcjXpXOVOjn3Uvy6oJC6sdJBai5rQukBVjl MU24RRgCXhHi3ou4U3WuF55CPyZXlu0ceRmQEb7z4rFj99YhqeI0/JLApD/cmyQKqnEE p2PDN+8GAcNwKqs8FG0Ew/I7bc0J0Ymg17DNl4GYqowyORzGKBk6XLTEcT9b6mNSWCX9 kkXkD8VPqUK4yNTqbK7Ej7MYN3BiPleIzb3RrOk+m6ME/KI1iniDart4J5DrkjkPYFup sxGw== X-Gm-Message-State: ALyK8tJeZqCeBLqP0IRAl4KmCxD46TVqXQNfDGDR+0mVNEsdHj1suzILiQdgL4R2N1v3VA== X-Received: by 10.194.102.202 with SMTP id fq10mr252981wjb.156.1465538496196; Thu, 09 Jun 2016 23:01:36 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id x128sm8575857wmf.6.2016.06.09.23.01.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Jun 2016 23:01:35 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Fri, 10 Jun 2016 09:01:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> To: Paul Wouters X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG , Daniel Migault Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 06:01:41 -0000 Hi, Paul On 10 Jun 2016, at 5:42 AM, Paul Wouters wrote: > On Thu, 9 Jun 2016, Daniel Migault wrote: >=20 >> Please find our new proposal with ESP using implicit IV [1]. We would = like to present and discuss it at the next IETF meeting. >=20 > I must understand it wrong... >=20 > Aren't these IVs different per ESP packet? And unrelated to IKE > values? How do both parties calculate the IV if it is not send as part > of the packet? >=20 >> =46rom what I understand, only part of that comes from IKE (aka the = salt > values that are taken from the IKE KEYMAT). As far as I understand, it > still needs to be unpredictable? >=20 > If this IV somehow comes from IKE, it might be very tricky for FIPS > certifications, because the security of the ESP IV then depends on > the IKE userland. >=20 All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CCM, = ChaCha20-Poly1305) require a nonce that is given in the IV field of an = ESP packet. For all of those algorithms, the respective RFC recommends to use a = counter to guarantee nonce uniqueness. Yes, you can use an LFSR instead, = but a counter is simpler. ESP already has a counter - the packet sequence. If you follow the = advice in the RFCs the ESP header will look like this: 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 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- | Security Parameters Index (SPI) | ^Int. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- | Sequence Number | |ered +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- | IV | | =20 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- And the Sequence Number and IV fields will hold the exact same number, = except that one is 32-bit while the other is 64-bit. Our draft simply negotiates omitting the IV field since it is redundant. Hope this helps Yoav From nobody Fri Jun 10 00:18:08 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6191F12B046 for ; Fri, 10 Jun 2016 00:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rV1b6pdEW_fW for ; Fri, 10 Jun 2016 00:18:03 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F5F12D94A for ; Fri, 10 Jun 2016 00:18:02 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id u74so40451895lff.2 for ; Fri, 10 Jun 2016 00:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-transfer-encoding; bh=7XjGZZURAr27Ky+DPpXyPi1Dcc/EVIOBpWl77pSIcEI=; b=qhBO5RTaF7kw6AA3zv8Q6NQRMgdj2K/sA9VLFJ4qE/wKz10c5RNQjCtfTSWvsNFQiq vmu+9MQ/+hSPbEHoVaG6ni1mi2KtIkCPzxDSwWFTGPbuMDn1EGjwUuAsBqSVDtJ8MDKX 2u9SRneRE7ZyjbAnDyEoJ2s34WcFM76Bi146zVGgrn5WI8V/Q+hOTPwcz3v4FNz7tdMw N6WDUL3o7VJjrgoW8+hsARVgFTeZrlamymHxf6LXLaDzBUUqeFHCswoRbg2UFr7/T7Ad TpWCC5MEupQEMPlP+ZWBmXlJRySHI1Z90QxYH8qmq2Wkh3U3KxAOXZYnmFO/J5TnXtUz FtFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=7XjGZZURAr27Ky+DPpXyPi1Dcc/EVIOBpWl77pSIcEI=; b=dYwnZ1rPAOE384ozSpU8osXskaWfKHc61CvPQifsL6HFx7dQHHe9N5Sp/F0HuRfjXl oRVyFK6nYhwZT+cHUcpz8D38aRbvND0+irrUyKxGmrCt40w0fK0kuYBQOcSxJIVDAtJ9 gqK9wp0EnBGLddI5Hf3+NzGt8DIyAJlDPcd6lK4j32Du+O9oc0XKXdqmcJGMgpeQ6bq4 Lqvcn/0KQXH6m18RXnAJI/+EmYTRyQn/oKGLE/kYPsRfE0KJp7BDl1bOZW/fuvzD7AOk iDOEMhAEBDiZIiPh0nDLHyXVij2VeQY5jKf1gyX19M6ZAubiUW6nhKpjXGTnZfWLlalF q9pQ== X-Gm-Message-State: ALyK8tI6zoGopD0IbxxKrctvRzzLdHUYpCrDh6rQXpQU+INtggVa09CgVp9fwDUW5/J2XQ== X-Received: by 10.25.216.104 with SMTP id p101mr176363lfg.198.1465543080988; Fri, 10 Jun 2016 00:18:00 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 135sm1113099ljf.9.2016.06.10.00.18.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 00:18:00 -0700 (PDT) Message-ID: <1E256828227C472DAC974F996555AE2B@buildpc> From: "Valery Smyslov" To: "Daniel Migault" , "IPsecME WG" References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> Date: Fri, 10 Jun 2016 10:17:50 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] New Version Notification fordraft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 07:18:06 -0000 Hi Daniel, a couple of comments. RFC 3686 Section 6 provides design rationale for making an IV explicit. I think it will be good if your draft also gives some design rationale why you came to the opposite conclusion (just to give readers an insight why in IoT world the weight of different factors might change dramatically comparing to "big" world). > Hi, > > Please find our new proposal with ESP using implicit IV [1]. We would like to present and discuss it at the next IETF > meeting. > > We would be happy to have the WG opinion on which you think is the better way to negotiate the implicit IV between two > peers. The different options are detailed in section 5 and copy paste here in the email: > > """ > Negotiation of the use of implicit IV can be done in 3 different > ways: > > o An IMPLICIT IV Transform Type. A proposal that contains this > transform type requires (if accepted) that IPsec use the implicit > IV and not include an explicit IV in the packets. To facilitate > backward compatibility with non-supporting implementations the > Initiator SHOULD add another proposal that does not include this > transform type as well as cryptographic suite the Initiator does > not support the implicit IV. The problems with this option is that it adds additional interdependence between Transforms presenting in the Proposal. We already have this for AEAD algorithms, which requires them to be placed in a separate Proposal from non-AEAD ciphers. This complicates both encoders and parses (I'd rather have separate Transform Type for AEAD ciphers, but that is that). With new Transform Type which is only applicable to some of Transform IDs the things become even more complicated for no practical reason. > o An IMPLICIT IV Transform ID. This doubles the number of ENCR > transform IDs by creating an ENCR_AES_CCM_16_IIV for each > ENCR_AES_CCM_16. > > o An IMPLICIT IV Transform Attribute, which would be associated to a > Transform Type ID, specifying the use of an implicit IV. marks a > particular ENCR transform as using implicit IVs. To facilitate > backward compatibility with non-supporting implementations the > Initiator SHOULD add another ENCR transform for each algorithm so > marked. In other words, for each ENCR_AES_CCM_16 with > keylength=256 and IIV=1, there will need to be an ENCR_AES_CCM_16 > with keylength=256 and no IIV attribute. > > """ These two options are similar in terms of complexity. I slightly prefer new Transform IDs over an Implicit IV Attribute since in this case it is very clear from the IANA registry which ciphers can be used with Implicit IV. Regards, Valery. > [1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, June 09, 2016 12:12 PM > To: Tobias Guggemos; Yoav Nir; Daniel Migault > Subject: New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt > > > A new version of I-D, draft-mglt-ipsecme-implicit-iv-00.txt > has been successfully submitted by Daniel Migault and posted to the IETF repository. > > Name: draft-mglt-ipsecme-implicit-iv > Revision: 00 > Title: Implicit IV for Counter-based Ciphers in IPsec > Document date: 2016-06-09 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-00.txt > Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > Htmlized: https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-00 > > > Abstract: > IPsec ESP sends an initialization vector (IV) or nonce in each > packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, AES- > CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not > require an unpredictable nonce. When using such algorithms the > packet counter value can be used to generate a nonce, saving 8 octets > per packet. This document describes how to do this. > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are > available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Jun 10 07:15:53 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1DA12D600 for ; Fri, 10 Jun 2016 07:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJE3WDwzfagL for ; Fri, 10 Jun 2016 07:15:51 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6EC12D0B1 for ; Fri, 10 Jun 2016 07:15:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rR42s5x92z3Fm; Fri, 10 Jun 2016 16:15:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 7K9xarnVx1Km; Fri, 10 Jun 2016 16:15:49 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 10 Jun 2016 16:15:48 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0E054378B49; Fri, 10 Jun 2016 10:15:47 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 0E054378B49 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id E8DBA40BDBD5; Fri, 10 Jun 2016 10:15:47 -0400 (EDT) Date: Fri, 10 Jun 2016 10:15:47 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> Message-ID: References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Cc: IPsecME WG , Daniel Migault Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 14:15:52 -0000 On Fri, 10 Jun 2016, Yoav Nir wrote: > All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CCM, ChaCha20-Poly1305) require a nonce that is given in the IV field of an ESP packet. > > For all of those algorithms, the respective RFC recommends to use a counter to guarantee nonce uniqueness. Yes, you can use an LFSR instead, but a counter is simpler. > > ESP already has a counter - the packet sequence. If you follow the advice in the RFCs the ESP header will look like this: Ok, now I understand. Thanks. I'm with Valery about using a new algorithm number. The proposal parser is already pretty ugly as-is without adding more complexity. It also allows to re-use the existing userland -> kernel infrastructure as no new options need to be added to that communication layer. Just another algorithm number. Paul From nobody Fri Jun 10 07:39:16 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B64F12D5C2 for ; Fri, 10 Jun 2016 07:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11Ig1xDsHmvS for ; Fri, 10 Jun 2016 07:39:13 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F13BA12D0E9 for ; Fri, 10 Jun 2016 07:39:12 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id v199so151646155wmv.0 for ; Fri, 10 Jun 2016 07:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=KqVkz4pBtgC0Z0SfxM4Gm+x0MbFFmJnQjSdlRKCdDBM=; b=SaxXSn05ZwqFUgTHNcAFBhRDM9Mb2+YZ41psQtLU0mfSoUjZiuWIayzSBryVVJQ/lj alSGQNzpEqFN63irUvDW+CklK0Wp18usSKihzZBEO5qEWo5lWjGZamO8mSjT++rG8Gsc 7qiNBOuOHHpoqFsDoOKhaN7QzkKrguZ5bCFPLBHfJRLDC+3nG9W0Wo/byOGxI50LS130 V3kU3TP5TgFT68NxChoEilBAX9isrjIdUSI/3AMOV9lQ+YfLSW/CqSDCNtENH2fJAgAp L1/BOXtGed6U+t3S3zggcdgx2F9XCrV4YUuOZOMH9EH65HIwkqlHKNaWugMqB/JXmxjJ vo4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=KqVkz4pBtgC0Z0SfxM4Gm+x0MbFFmJnQjSdlRKCdDBM=; b=LCiYxjhNQgaOI0Pr4h5RafP8CTXb8Ecm/0UI8oJUPFjOQDW3M7liodXE36pmTVK1Qe DA6X0G0GQNmD+Na55qdR/2MniCmp9Zik9m9sWFlb3WdM4s4ZCwekcvbAMcOG0AEgy+eV brehMEri0JkU7CMgsQcqnuDjokFErRj0HcFOyU5U3CJCka9D8/LuDe1nG9ffHzt1oyW1 zZy4PB1+6ZmbyI9yJ8n3YSDiRRDKi7cX5ELcgsNVRHzgXPps3p0DzsX2bsT0c1RQZp01 SdAAP5iZka/x4yxO9UDN6Yw7xoupWul4xUvBdmE2EXw5WYhl+wkCqPBMXzfG6x2uyXMT pYJw== X-Gm-Message-State: ALyK8tKbBnHk6+0U0QRxFLdYUc3K8gyHeTGtjfVdcEiYfpUftK9RgQzq/d9mEMEatT4Cpg== X-Received: by 10.194.22.169 with SMTP id e9mr2597164wjf.128.1465569551409; Fri, 10 Jun 2016 07:39:11 -0700 (PDT) Received: from [10.0.0.1] (bzq-109-67-2-59.red.bezeqint.net. [109.67.2.59]) by smtp.googlemail.com with ESMTPSA id vu10sm3134483wjb.27.2016.06.10.07.39.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 07:39:10 -0700 (PDT) To: Paul Wouters , Yoav Nir References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> From: Yaron Sheffer Message-ID: Date: Fri, 10 Jun 2016 17:39:08 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F13A28A2F3FBD7005B7F323D" Archived-At: Cc: IPsecME WG , Daniel Migault Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 14:39:14 -0000 This is a multi-part message in MIME format. --------------F13A28A2F3FBD7005B7F323D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi, The document takes care to not define Implicit IV for AES-CBC, and I believe the underlying reason is malleability of the encryption. The same would apply to AES-CTR. So I would suggest to: * Exclude AES-CTR from this draft, or... * Better yet, restrict the draft to AEAD algorithms. BTW, the reference for AES-GCM is incorrect. Should be 4106. Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key material. Is that kept intact by the current proposal? Thanks, Yaron --------------F13A28A2F3FBD7005B7F323D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi,

The document takes care to not define Implicit IV for AES-CBC, and I believe the underlying reason is malleability of the encryption. The same would apply to AES-CTR. So I would suggest to:
  • Exclude AES-CTR from this draft, or...
  • Better yet, restrict the draft to AEAD algorithms.

BTW, the reference for AES-GCM is incorrect. Should be 4106.

Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key material. Is that kept intact by the current proposal?

Thanks,

Yaron

--------------F13A28A2F3FBD7005B7F323D-- From nobody Fri Jun 10 09:28:25 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049DE12B009 for ; Fri, 10 Jun 2016 09:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.747 X-Spam-Level: X-Spam-Status: No, score=-5.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4yL1WaW7otu for ; Fri, 10 Jun 2016 09:28:20 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F25412B03A for ; Fri, 10 Jun 2016 09:28:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1465576100; x=2329489700; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iucwP8zWdzoqdqN5AcVMwLNEQ4enaklmbnp+NQ0YqOs=; b=S7NalBwJeJvhbJYEIXPxOopfNsdqS3Qx9T0zBlxS927uTwYKw/vLJ2aF31TP383g RIYF0uclex63GrszODfBQJ1ZeGjzquYMA68UzAt1ZoVl6WLiUJ+SURvG5FfMwwi3 04M3UxGb0uDPw0Y5NkxW3mkcaC4/+8FyvFPPwMaQXwv8Xx6spkp4syxZLvgPjfFp tctjeeOhp1IHHY2263Mwl4+BrSGNjIYTqJj5cmkoawxcRJnLxmCe9AXjKkeSHkom yVEhNrA3EKRPWEvw0Ru5iMx0ByE9dmL4FgI4TvNtJpOJg0TKG0hWZrTF2RimZis4 HGy0eCBj53Ij2oLtuxNhfw==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id C9.96.21445.4AAEA575; Fri, 10 Jun 2016 09:28:20 -0700 (PDT) X-AuditID: 11973e12-f79796d0000053c5-ea-575aeaa42f49 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 8D.BC.28643.4AAEA575; Fri, 10 Jun 2016 09:28:20 -0700 (PDT) Received: from da0602a-dhcp205.apple.com (da0602a-dhcp205.apple.com [17.226.23.205]) by chive.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O8K00ILXDR7PA40@chive.apple.com> for ipsec@ietf.org; Fri, 10 Jun 2016 09:28:20 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 10.0 \(3186\)) From: Tommy Pauly In-reply-to: <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> Date: Fri, 10 Jun 2016 09:28:19 -0700 Content-transfer-encoding: quoted-printable Message-id: <57CE723E-2B3D-4600-B142-53AD8CC5C4D3@apple.com> References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> To: Daniel Migault X-Mailer: Apple Mail (2.3186) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUi2FAYpbvkVVS4weVPvBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxszJL1gK7qhX7F1wnb2B8bB8FyMnh4SAicTPdVeZIGwxiQv3 1rN1MXJxCAnsZZT42fuJGa7oYgcTRGIak8S8KzegqlYxSVw4dxioioNDWEBCYvOeRJAGZgEt ifU7j4NN5RXQl5g/9z/YIGGBSIn7s+awgthsAioSx79tAItzCvhJHGzoB6tnEVCVaPjRwwwx R16i9/9GRghbW+LJuwusEDNtJDpmH2GHuKGVUWLp8uVgCREBA4mXE3aygdwjISArcWWxBEiN hMASNokvXw+xTWAUmYXkvllI7puFZMcCRuZVjEK5iZk5upl5JnqJBQU5qXrJ+bmbGEEBPt1O aAfjqVVWhxgFOBiVeHgZdkSGC7EmlhVX5h5ilOZgURLn3XM9KlxIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QDY+eUGT/36twsnSzcabXqrHSFy+dDMpvY83OM3jRMzM4uvjU3Ut+f9ZMxP6OT 0kwRyV8hmldWmqdZ2H1TkExgeD5h9Ryl/t/3KsPey9f+Y93Y7bnyRYdKUMjV7zMu9dX8P75y wpN1IU1XZ5580eKxSnJ2+Bvxk+X7pCIUjik+3jb7wUezC1y7XiqxFGckGmoxFxUnAgDMNrtd UQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUi2FDMr7vkVVS4wd5ebov9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoErY+bkFywFd9Qr9i64zt7AeFi+i5GTQ0LAROLnxQ4mCFtM4sK9 9WxdjFwcQgLTmCTmXbkB5axikrhw7jBzFyMHh7CAhMTmPYkgDcwCWhLrdx4Ha+YV0JeYP/c/ M4gtLBApcX/WHFYQm01AReL4tw1gcU4BP4mDDf1g9SwCqhINP3qYIebIS/T+38gIYWtLPHl3 gRVipo1Ex+wj7BA3tDJKLF2+HCwhImAg8XLCTjaQeyQEZCWuLJaYwCg4C8lJs5CcNAvJ2AWM zKsYBYpScxIrzfQSCwpyUvWS83M3MYIDsjBqB2PDcqtDjAIcjEo8vBG7IsOFWBPLiitzDzFK cDArifB2P48KF+JNSaysSi3Kjy8qzUktPsSYDPTMRGYp0eR8YLTklcQbmpgYmBgbmxkbm5uY kyasJM578RXQVoH0xJLU7NTUgtQimC1MHJxSDYy8ViYTsporNoa6dWod+mG48oVEY2vknb+H 5br7+aY0aRxxTiiRNI8wYPpZJLBhqkr30lc5xT/+uC5fvi02aFaLxbXmVMZ3V//s65w+o9+e X2nR3zPms0/e37zr8bWW/jf6MxY7KX2f7f9llWFO/wUTR5f/sWx3dT2PcPTuuvEkUytAK1bc 66USS3FGoqEWc1FxIgD9M0kDjAIAAA== Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 16:28:22 -0000 Here are my thoughts on the options for communicating the Implicit IV = option in the proposal: - A new transform type is problematic, as pointed out by Valery and Paul = already, because it adds complexity to the proposal structure for = configuring and parsing. This seems to be the least desirable option. - The new transform ID is easy to add to implementations because it is = just another value for an existing field. There is a slight downside in = needing new ID allocations for what will be essentially a duplicate = algorithm, but numbers are cheap. I think this is the easiest option to = adopt and pass between implementation layers (userspace, kernel, etc), = but once the layer doing encryption is using the value, it will probably = want to flatten the information out into the original algorithm value = and a flag that the IV is implicit. - A new transform attribute is attractive as a clean protocol design, = since it seems to be the type of information that transform attributes = are meant to hold. There aren't many uses of transform attributes = currently, so this may add work to protocol parsers. This may require = passing the flag for implicit IVs separately throughout the = implementation, rather than as part of the transform ID, but I would be = willing to do this as an implementer for the sake of a cleaner protocol. As such, I vote for either option 2 or 3: 2 for ease of implementation, = 3 for clean protocol design. Thanks, Tommy > On Jun 9, 2016, at 9:19 AM, Daniel Migault = wrote: >=20 > Hi, >=20 > Please find our new proposal with ESP using implicit IV [1]. We would = like to present and discuss it at the next IETF meeting. >=20 > We would be happy to have the WG opinion on which you think is the = better way to negotiate the implicit IV between two peers. The different = options are detailed in section 5 and copy paste here in the email: >=20 > """ > Negotiation of the use of implicit IV can be done in 3 different > ways: >=20 > o An IMPLICIT IV Transform Type. A proposal that contains this > transform type requires (if accepted) that IPsec use the implicit > IV and not include an explicit IV in the packets. To facilitate > backward compatibility with non-supporting implementations the > Initiator SHOULD add another proposal that does not include this > transform type as well as cryptographic suite the Initiator does > not support the implicit IV. >=20 > o An IMPLICIT IV Transform ID. This doubles the number of ENCR > transform IDs by creating an ENCR_AES_CCM_16_IIV for each > ENCR_AES_CCM_16. >=20 > o An IMPLICIT IV Transform Attribute, which would be associated to = a > Transform Type ID, specifying the use of an implicit IV. marks a > particular ENCR transform as using implicit IVs. To facilitate > backward compatibility with non-supporting implementations the > Initiator SHOULD add another ENCR transform for each algorithm so > marked. In other words, for each ENCR_AES_CCM_16 with > keylength=3D256 and IIV=3D1, there will need to be an = ENCR_AES_CCM_16 > with keylength=3D256 and no IIV attribute. >=20 > """ =20 >=20 > [1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Thursday, June 09, 2016 12:12 PM > To: Tobias Guggemos; Yoav Nir; Daniel Migault > Subject: New Version Notification for = draft-mglt-ipsecme-implicit-iv-00.txt >=20 >=20 > A new version of I-D, draft-mglt-ipsecme-implicit-iv-00.txt > has been successfully submitted by Daniel Migault and posted to the = IETF repository. >=20 > Name: draft-mglt-ipsecme-implicit-iv > Revision: 00 > Title: Implicit IV for Counter-based Ciphers in IPsec > Document date: 2016-06-09 > Group: Individual Submission > Pages: 7 > URL: = https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-00.txt= > Status: = https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > Htmlized: = https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-00 >=20 >=20 > Abstract: > IPsec ESP sends an initialization vector (IV) or nonce in each > packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, = AES- > CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not > require an unpredictable nonce. When using such algorithms the > packet counter value can be used to generate a nonce, saving 8 = octets > per packet. This document describes how to do this. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jun 13 03:00:45 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A5112D1AE for ; Mon, 13 Jun 2016 03:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWJGJTp9iSF7 for ; Mon, 13 Jun 2016 03:00:42 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8369312D1A7 for ; Mon, 13 Jun 2016 03:00:41 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id v199so70599728wmv.0 for ; Mon, 13 Jun 2016 03:00:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=AbGL6asCAjtH9F8gFw7FZtp2kfGtURCZAgT5udtxMpg=; b=U/NTyUoo117UgFa5B8GCzy7ibN/iGk2Sajy8ZHjlm7HFG4JjrKFFJUji+Vut7+9Gwf pvRSHUul1aGV1CcqtGF0HEfMyP5ZLkUHDY5BWHnaBxk55rGLVdhfKJ9zCuudfJuh4xxi BwWuQBYyto/pgPZCRLEQi7stEm658FBsrpTejtcyJt8u9lBVrABUtAtzQv809/R+DMph gdhVFj8lTo4OiVbn+5FK6aw13T+eUpfZsmEqJcLgPP8v3MEZYH6rQiJu//Gg6jnrncaz QDUSR06VuCPbYzHx+Py8P6HAcJ5402gzaPJotgr2wCojb5S1Z8Ib2oBLbfI/tmxnKsto 0hLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=AbGL6asCAjtH9F8gFw7FZtp2kfGtURCZAgT5udtxMpg=; b=mLVfyyxrAlUi6v04GKRu0AxG5LtmG62eBzuA/KZho9m9ViMKfLCLGyYXk1rdr3ewH0 GOC3kCK2VpNnEq0kEExDuhAi/eAXdoAdQ9Hfeka/vs3i11CI1xkOrB96Sd/Pf5yMw6Va 5MgMbpAkSeiP7ThqmH+EpUeKgqofO6sMTtrPIKrdX1NpuSi/hOsp+vkBCMK4T0QQRTUz D+c4YKcd3G0Q3vp9jGYJIqWBvK0BnZ9NJETFe8uNA2KTuscSy7/wf6QQB9JSNC/Azqbo 3CR45OwoHwBvm1sEUpIjKWidvcVkyatY9///Yyhbu1TmrveZ3EpEEgmS4GC7Hw6oioHB qI/A== X-Gm-Message-State: ALyK8tKf5feYSVmRL1LePPc0wF99ItpJwKxriYxrv6UBJxjFil0VZDTYeL1rkMWMqmHT1g== X-Received: by 10.28.63.134 with SMTP id m128mr198638wma.97.1465812039971; Mon, 13 Jun 2016 03:00:39 -0700 (PDT) Received: from [172.24.249.196] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id g3sm26696423wjb.47.2016.06.13.03.00.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Jun 2016 03:00:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D007ABD5-8F99-4B05-B265-367E9C9365DA" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Mon, 13 Jun 2016 13:00:37 +0300 Message-Id: <38026197-8DCE-4F23-866D-83BB3777745F@gmail.com> References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG , Daniel Migault , Paul Wouters Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 10:00:43 -0000 --Apple-Mail=_D007ABD5-8F99-4B05-B265-367E9C9365DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On 10 Jun 2016, at 5:39 PM, Yaron Sheffer = wrote: >=20 > Hi, >=20 > The document takes care to not define Implicit IV for AES-CBC, and I = believe the underlying reason is malleability of the encryption. The = same would apply to AES-CTR. So I would suggest to: > Exclude AES-CTR from this draft, or... > Better yet, restrict the draft to AEAD algorithms. > BTW, the reference for AES-GCM is incorrect. Should be 4106. >=20 > Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key = material. Is that kept intact by the current proposal? >=20 Hi, Yaron AES-CTR is pretty similar to AES-GCM and AES-CCM, except for the = confusing terminology: The 32-bit per-SA value derived from IKE is called =93nonce=94 in RFC = 3686 and =93salt=94 in RFC 4106 (thanks for the corrected reference). The concatenation of 32-bit per-SA value and IV is called =93nonce=94 in = RFC 4106 and doesn=92t have a name in RFC 3686. The concatenation of 32-bit per-SA value, IV, and block counter is = called =93counter block=94 in RFC 3686, but isn=92t explicitly = mentioned in RFC 4106. The GCM spec also calls it =93counter block=94. AFAICT it is not malleable like CBC. In CBC the issue was that an = attacker knowing the next IV would be able to generate the first block = of the next message such that IV xor Block0 would be whatever the = attacker wanted. That block would be the input to the encryption = function and thus the attacker could force the encryptor to encrypt = whatever block it wanted. With counter mode (or GCM or CCM) the attacker = has no control on the inputs to the encryption function. That is why RFC = 3686 has text similar to the other documents: The same IV and key combination MUST NOT be used more than once. The encryptor can generate the IV in any manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs). So I think CTR belongs in this draft as much as the others. And yes, the GCM salt or the CTR nonce are derived in the same way and = used in the same way. Yoav --Apple-Mail=_D007ABD5-8F99-4B05-B265-367E9C9365DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 10 Jun 2016, at 5:39 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

=20 =20
Hi,

The document takes care to not define Implicit IV for AES-CBC, and I believe the underlying reason is malleability of the encryption. The same would apply to AES-CTR. So I would suggest to:
  • Exclude AES-CTR from this draft, or...
  • Better yet, restrict the draft to AEAD = algorithms.

BTW, the reference for AES-GCM is incorrect. = Should be 4106.

Speaking of which, AES-GCM in ESP has a = "salt" derived from IKE key material. Is that kept intact by the current = proposal?


Hi, = Yaron

AES-CTR is pretty similar to = AES-GCM and AES-CCM, except for the confusing terminology:
  • The 32-bit per-SA value derived = from IKE is called =93nonce=94 in RFC 3686 and =93salt=94 in RFC 4106 = (thanks for the corrected reference).
  • The = concatenation of 32-bit per-SA value and IV is called =93nonce=94 in RFC = 4106 and doesn=92t have a name in RFC 3686.
  • The = concatenation of 32-bit per-SA value, IV, and block counter is called = =93counter block=94  in RFC 3686, but isn=92t explicitly mentioned = in RFC 4106. The GCM spec also calls it =93counter block=94.

AFAICT it is not = malleable like CBC. In CBC the issue was that an attacker knowing the = next IV would be able to generate the first block of the next message = such that IV xor Block0 would be whatever the attacker wanted. That = block would be the input to the encryption function and thus the = attacker could force the encryptor to encrypt whatever block it wanted. = With counter mode (or GCM or CCM) the attacker has no control on the = inputs to the encryption function. That is why RFC 3686 has text similar = to the other documents:

  =                     =                     =                     =  The same
   IV and key combination MUST NOT be used more = than once.  The
   encryptor can generate the IV in any manner = that ensures uniqueness.
   Common approaches to IV generation include = incrementing a counter for
   each = packet and linear feedback shift registers = (LFSRs).

So I think CTR belongs in this draft as much as the = others.

And = yes, the GCM salt or the CTR nonce are derived in the same way and used = in the same way.

Yoav

= --Apple-Mail=_D007ABD5-8F99-4B05-B265-367E9C9365DA-- From nobody Mon Jun 13 03:27:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A5F12D0FC for ; Mon, 13 Jun 2016 03:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vomV5zlw2ulg for ; Mon, 13 Jun 2016 03:27:51 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D4212D125 for ; Mon, 13 Jun 2016 03:27:51 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id k204so72861393wmk.0 for ; Mon, 13 Jun 2016 03:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Iqsr1Hx7mhNRmCaDmPgokLoAZ3RzqJkshEbvwV2tFKs=; b=CgcT3n5gRTgo9/witMK6rpucFWbMo0RrA+mke+yXSRwNcFOUkmzli2wDZP6s+C3B6Q 1pnjVOsCOCHiJdbkgxpzBoBfRJ/22vf2IDSmB4dSWZfb24hBVkugrr2zElSv5hAR71+X CUiytgKR8OJsNvCyBmtphMQZc4F0XVK6Zit440qlP6RMoeSCkM0JLlfYsA/qDf0A8CpB cBnVUdurV3QGmju9qoBLlbPSYJmI9hiznErGXXqMZoonBYjQKibxIpa9Z5Ck7luj6/DB UEIE/4UMFfQvPgPDT9Q39Fd0Bi8S4Mz7vZxR14R/AneZC6ZhcdaWy7+wnEF1l147haGd zDsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Iqsr1Hx7mhNRmCaDmPgokLoAZ3RzqJkshEbvwV2tFKs=; b=EfSgrSCO1Amuv/tByIBMi7HueCLhXip2/zn5rcuqd1e32jdfb+CyZaSb9uraEr1GHY CGKXLT4R47Zu452JFiwF6of6N0QIPpbTW3tZ9gAlJOTT3t+0xZWds7aeIxqYEKEcPpO0 9n/U1m9NYlucdoAS78UgppNcC+BTB3NibFqGA4H2UaU1x+ffMnwaYr1ZyPkK8kcWn2Az cZB9IZ+bs8OjZhXwY+OlaOvYV/qkO1aZMr7UOha8l/wafkfhzt9yPHP3sRBBu+slv32Z pPPSxsEMmQy3LVq4wjV9DeETYKfumNaWwBNumgs0DB68DoUKKrbXEywYx+BE2JIS9u1w CXNA== X-Gm-Message-State: ALyK8tKnK0ZaddMoRBvr1CXDWSS6PxG4xlI9V+Qh3Xon+bqMCq91LGQ1NjkGADH/FW1bUw== X-Received: by 10.194.203.105 with SMTP id kp9mr414551wjc.70.1465813669613; Mon, 13 Jun 2016 03:27:49 -0700 (PDT) Received: from [172.24.249.196] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id z1sm23409847wju.32.2016.06.13.03.27.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Jun 2016 03:27:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <57CE723E-2B3D-4600-B142-53AD8CC5C4D3@apple.com> Date: Mon, 13 Jun 2016 13:27:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <86D08F7D-06B6-4362-B30E-4A9A1093AA2F@gmail.com> References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <57CE723E-2B3D-4600-B142-53AD8CC5C4D3@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG , Daniel Migault Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 10:27:54 -0000 I=E2=80=99ve been looking at the history of TLS interop issues. It seems = that the one constant is that anything that doesn=E2=80=99t change all = the time is surprising, and for anything surprising there are = implementations that die on receiving it: - If the version field has always been 0x0300 or 0x0301 and somebody = suddenly sends 0x0302 some implementation will close the connection even = though the spec for 0301 was explicit on how to handle this. - If a 16-bit length field describes the ClientHello message that is = always under 256 octets, the higher length octet is always zero. When it = suddenly became 1 some implementation closed the connection. So what can we take away from this to IKE? Perhaps the principle of = =E2=80=9CDon=E2=80=99t be surprising on the Internet=E2=80=9D.=20 Since the publication of RFC 4306 we=E2=80=99ve added one exchange type, = but we negotiate its use so it=E2=80=99s not surprising. We=E2=80=99ve = added two payload types, but their use is also negotiated. Same is true = for ID types. A few other extensions assume support on both sides and = happily fail otherwise. We=E2=80=99ve added no transform types and no transform attributes. The only things that we routinely surprise peers with are new = notifications and new algorithms or transform IDs. So if our main goal is to reduce surprising interoperability failures, = we should probably negotiate this with either notifications or transform = IDs. The question is, of course, which is uglier: negotiation with = notifications, or duplicating transform IDs. I tend to think the former = is uglier, but it kind of resembles the way TFC is negotiated or = non-first fragments. Yoav > On 10 Jun 2016, at 7:28 PM, Tommy Pauly wrote: >=20 > Here are my thoughts on the options for communicating the Implicit IV = option in the proposal: >=20 > - A new transform type is problematic, as pointed out by Valery and = Paul already, because it adds complexity to the proposal structure for = configuring and parsing. This seems to be the least desirable option. >=20 > - The new transform ID is easy to add to implementations because it is = just another value for an existing field. There is a slight downside in = needing new ID allocations for what will be essentially a duplicate = algorithm, but numbers are cheap. I think this is the easiest option to = adopt and pass between implementation layers (userspace, kernel, etc), = but once the layer doing encryption is using the value, it will probably = want to flatten the information out into the original algorithm value = and a flag that the IV is implicit. >=20 > - A new transform attribute is attractive as a clean protocol design, = since it seems to be the type of information that transform attributes = are meant to hold. There aren't many uses of transform attributes = currently, so this may add work to protocol parsers. This may require = passing the flag for implicit IVs separately throughout the = implementation, rather than as part of the transform ID, but I would be = willing to do this as an implementer for the sake of a cleaner protocol. >=20 > As such, I vote for either option 2 or 3: 2 for ease of = implementation, 3 for clean protocol design. >=20 > Thanks, > Tommy >=20 >> On Jun 9, 2016, at 9:19 AM, Daniel Migault = wrote: >>=20 >> Hi, >>=20 >> Please find our new proposal with ESP using implicit IV [1]. We would = like to present and discuss it at the next IETF meeting. >>=20 >> We would be happy to have the WG opinion on which you think is the = better way to negotiate the implicit IV between two peers. The different = options are detailed in section 5 and copy paste here in the email: >>=20 >> """ >> Negotiation of the use of implicit IV can be done in 3 different >> ways: >>=20 >> o An IMPLICIT IV Transform Type. A proposal that contains this >> transform type requires (if accepted) that IPsec use the implicit >> IV and not include an explicit IV in the packets. To facilitate >> backward compatibility with non-supporting implementations the >> Initiator SHOULD add another proposal that does not include this >> transform type as well as cryptographic suite the Initiator does >> not support the implicit IV. >>=20 >> o An IMPLICIT IV Transform ID. This doubles the number of ENCR >> transform IDs by creating an ENCR_AES_CCM_16_IIV for each >> ENCR_AES_CCM_16. >>=20 >> o An IMPLICIT IV Transform Attribute, which would be associated to = a >> Transform Type ID, specifying the use of an implicit IV. marks a >> particular ENCR transform as using implicit IVs. To facilitate >> backward compatibility with non-supporting implementations the >> Initiator SHOULD add another ENCR transform for each algorithm so >> marked. In other words, for each ENCR_AES_CCM_16 with >> keylength=3D256 and IIV=3D1, there will need to be an = ENCR_AES_CCM_16 >> with keylength=3D256 and no IIV attribute. >>=20 >> """ =20 >>=20 >> [1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 >> Sent: Thursday, June 09, 2016 12:12 PM >> To: Tobias Guggemos; Yoav Nir; Daniel Migault >> Subject: New Version Notification for = draft-mglt-ipsecme-implicit-iv-00.txt >>=20 >>=20 >> A new version of I-D, draft-mglt-ipsecme-implicit-iv-00.txt >> has been successfully submitted by Daniel Migault and posted to the = IETF repository. >>=20 >> Name: draft-mglt-ipsecme-implicit-iv >> Revision: 00 >> Title: Implicit IV for Counter-based Ciphers in IPsec >> Document date: 2016-06-09 >> Group: Individual Submission >> Pages: 7 >> URL: = https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-00.txt= >> Status: = https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ >> Htmlized: = https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-00 >>=20 >>=20 >> Abstract: >> IPsec ESP sends an initialization vector (IV) or nonce in each >> packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, = AES- >> CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not >> require an unpredictable nonce. When using such algorithms the >> packet counter value can be used to generate a nonce, saving 8 = octets >> per packet. This document describes how to do this. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jun 13 14:43:11 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FA812DA74 for ; Mon, 13 Jun 2016 14:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-RfeG9Ik1tZ for ; Mon, 13 Jun 2016 14:42:55 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39DF112D82F for ; Mon, 13 Jun 2016 14:42:55 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id h190so53200857ith.1 for ; Mon, 13 Jun 2016 14:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=XTl6izgKgRD/gynZr3qSZxZkfxOqKl32uDy3PjqofxI=; b=FqvfbrcByjcmIvgYqKRdjDgahmOZj/Ey8pcN0QnGFU8JB+1FZYgHYC2HpmcAXvRkDD kFLKWfQufmz3O+BHhKnb6wnbyXuId8jH7p9miZ6FEyZSE2rPyJa7KCYR9p4jwnGvbxQ3 n/mPiWSxzPKwebVL+cDAy29T1P1GXvsndhvPtvAQsEwMsYvy5NfUjArbbG79aRqNnxM8 4ujygK5rxL/Vr5PM/fiLv1KK9Wbg67iArnbVLetLDgM2QoZJVwth4VWVRDA+XgN1WX/y cCCFHdZ5tzvUTPwSY+2R6Lxo5mQOMUTtj5/QoeDsHkEUab8a9h9RTg/q+rEtR67qKec7 AB8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=XTl6izgKgRD/gynZr3qSZxZkfxOqKl32uDy3PjqofxI=; b=LnKLQu8COnfXFw+SDqLvR+Fombq6AVjjYEfyVORz6JrELGaLaFDxoLtsqvk9VOYOOk 2NY9N1I7XzG6g15a8Dx9ncr71o9DKa7YQq9O6a+aNzjGEj8/PM8c9DApxR5iPpWvFTvw 8XoeWqCnuECau481LoJIw8Y+pxpnCTD2WzWb+iTRE04PNgMyGKfY+pqIjAI3cN34bD5s Es8sGvNvdjxg+/NfM/o6x8q9kd25XjNIYinp5Do9tbFSb5c7WLxdCtwYvX5aIdq05Lil suN+3XU3LRTaO33JWtuaNyGmrwXvLiPKOUUCHAZDPZgAqmZEy5Fqw1JCXoFkRsAaACfw 92oQ== X-Gm-Message-State: ALyK8tK1FiR/YxbICmZI0SqGcR0D9JVyB1R9jKS+JLT1oL/MO/lF1Lsv9h74orVvUFOaKg== X-Received: by 10.36.64.8 with SMTP id n8mr20728289ita.21.1465854174558; Mon, 13 Jun 2016 14:42:54 -0700 (PDT) Received: from [10.255.246.194] ([207.164.2.187]) by smtp.gmail.com with ESMTPSA id h125sm13260676ioa.20.2016.06.13.14.42.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jun 2016 14:42:53 -0700 (PDT) To: Yoav Nir References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> <38026197-8DCE-4F23-866D-83BB3777745F@gmail.com> From: Yaron Sheffer Message-ID: <575F28DB.2070703@gmail.com> Date: Mon, 13 Jun 2016 17:42:51 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <38026197-8DCE-4F23-866D-83BB3777745F@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: IPsecME WG , Daniel Migault , Paul Wouters Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 21:43:03 -0000 On 13/06/16 06:00, Yoav Nir wrote: > >> On 10 Jun 2016, at 5:39 PM, Yaron Sheffer > > wrote: >> >> Hi, >> >> The document takes care to not define Implicit IV for AES-CBC, and I >> believe the underlying reason is malleability of the encryption. The >> same would apply to AES-CTR. So I would suggest to: >> >> * Exclude AES-CTR from this draft, or... >> * Better yet, restrict the draft to AEAD algorithms. >> >> BTW, the reference for AES-GCM is incorrect. Should be 4106. >> >> Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key >> material. Is that kept intact by the current proposal? >> > > Hi, Yaron > > AES-CTR is pretty similar to AES-GCM and AES-CCM, except for the > confusing terminology: > > * The 32-bit per-SA value derived from IKE is called nonce in RFC > 3686 and salt in RFC 4106 (thanks for the corrected reference). > * The concatenation of 32-bit per-SA value and IV is called nonce in > RFC 4106 and doesnt have a name in RFC 3686. > * The concatenation of 32-bit per-SA value, IV, and block counter is > called counter block in RFC 3686, but isnt explicitly mentioned > in RFC 4106. The GCM spec also calls it counter block. > > > AFAICT it is not malleable like CBC. In CBC the issue was that an > attacker knowing the next IV would be able to generate the first block > of the next message such that IV xor Block0 would be whatever the > attacker wanted. That block would be the input to the encryption > function and thus the attacker could force the encryptor to encrypt > whatever block it wanted. With counter mode (or GCM or CCM) the attacker > has no control on the inputs to the encryption function. That is why RFC > 3686 has text similar to the other documents: > > The same > IV and key combination MUST NOT be used more than once. The > encryptor can generate the IV in any manner that ensures uniqueness. > Common approaches to IV generation include *incrementing a counter* for > each packet and linear feedback shift registers (LFSRs). > > So I think CTR belongs in this draft as much as the others. > > And yes, the GCM salt or the CTR nonce are derived in the same way and > used in the same way. > > Yoav > AES-CTR is potentially malleable by a MITM who can change counter values into ones she'd observed before. However since RFC 3686 is very emphatic about the need for integrity protection (Sec. 3.3), we should be fine. Thanks, Yaron From nobody Wed Jun 15 12:50:48 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09ABD12DB79 for ; Wed, 15 Jun 2016 12:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzCeMc0-nY4u for ; Wed, 15 Jun 2016 12:50:44 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF4112DB6D for ; Wed, 15 Jun 2016 12:50:43 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id a66so27641651wme.0 for ; Wed, 15 Jun 2016 12:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=zYz8Y8hz6tCcJ0m8U38iYlVl9SD1TrCmptfPTjovK8k=; b=AD8sPvvd4avbUs2IxWy34+OWdJ7Vzn+PuktYshx1rCOLeAOJAsqMjAB7zeO9LB7J3e ZVUjqIORWWixwXQFbuGKd8I84YGgUcs6gWJKLDcRruvMRNunxSL4S0pAadS/0BnzrRr+ aCg2FJGv9CR4thewTUG5Jm1fy8HHUNBJIXFzTK0xW809UNnI/JXCBuplDsMxVDt+83lw u1GCNF1+AJ30olj0cErefk6R3wCX6n6FLV85CW4rERbE0Rxa7ikeG1PCF5PCR92XHHlH MX1zpUCtaqOieAufqt7OAc3B911Cxc2TuUEAtVBy2Ff4QrQ3j9iuwvJEe53wNMMZ4QLy /xpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=zYz8Y8hz6tCcJ0m8U38iYlVl9SD1TrCmptfPTjovK8k=; b=DfXVQ40xvOmeqt29L4UyZjP8EnkG4o/Qt9lXxG2quPspX0FF9/whPjdqA3t7xphEE8 eUEr8+VxodI8m2AXj5Z69MrTBmvULpdpT8aA9/61GLEFWRHCNnuCjaQf+okO/b/iuPWf iAfG0ARotGmlf5sTj3M4eGBwbAyHQa4b3HkmCtgKs01UGFrKlBZWDSnrRhiIniqQcQMN 8svB35IZLvvwX40M95apQ/q20aFmHrrPT57/Q88F69dcXwPfCk8ZFbtv3cOuMjnDYwhc noI8OLUxO5mQi09aeWFzjdA8EBMWMhrhLm3cfeVl/Up/QLranKCsYmGnV5rKdGDInwM9 NrKA== X-Gm-Message-State: ALyK8tIMcA7DJuCZPWZeqfIbu0rSyQl7m1mUFBZK/GAQEWX66yWDEJHqoXvTolF3DLPWQOH4ygmU7/pN0xtruw== X-Received: by 10.28.30.149 with SMTP id e143mr876428wme.81.1466020242232; Wed, 15 Jun 2016 12:50:42 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.34.99 with HTTP; Wed, 15 Jun 2016 12:50:41 -0700 (PDT) In-Reply-To: <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> From: Daniel Migault Date: Wed, 15 Jun 2016 15:50:41 -0400 X-Google-Sender-Auth: BrGh62yVgCyo3TIe01d7O7Zo43Q Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a114b25fec59ae60535566fd8 Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 19:50:47 -0000 --001a114b25fec59ae60535566fd8 Content-Type: text/plain; charset=UTF-8 Hi Paul, I hope this has been clarified. In order to clarify this I updated the text in the intro: OLD: This document defines how to compute the nonce locally when it is implicit. It also specifies how to negotiate this behavior within the Internet Key Exchange version 2 (IKEv2 - RFC7296). NEW: This document defines how to compute the nonce locally when it is implicit. It also specifies how peers agree with Internet Key Exchange version 2 IKEv2 on using an implicit IV versus an explicit IV Please let us know if that address your purpose. BR, Daniel On Fri, Jun 10, 2016 at 2:01 AM, Yoav Nir wrote: > Hi, Paul > > On 10 Jun 2016, at 5:42 AM, Paul Wouters wrote: > > > On Thu, 9 Jun 2016, Daniel Migault wrote: > > > >> Please find our new proposal with ESP using implicit IV [1]. We would > like to present and discuss it at the next IETF meeting. > > > > I must understand it wrong... > > > > Aren't these IVs different per ESP packet? And unrelated to IKE > > values? How do both parties calculate the IV if it is not send as part > > of the packet? > > > >> From what I understand, only part of that comes from IKE (aka the salt > > values that are taken from the IKE KEYMAT). As far as I understand, it > > still needs to be unpredictable? > > > > If this IV somehow comes from IKE, it might be very tricky for FIPS > > certifications, because the security of the ESP IV then depends on > > the IKE userland. > > > > All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CCM, > ChaCha20-Poly1305) require a nonce that is given in the IV field of an ESP > packet. > > For all of those algorithms, the respective RFC recommends to use a > counter to guarantee nonce uniqueness. Yes, you can use an LFSR instead, > but a counter is simpler. > > ESP already has a counter - the packet sequence. If you follow the advice > in the RFCs the ESP header will look like this: > > 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 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- > | Security Parameters Index (SPI) | ^Int. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- > | Sequence Number | |ered > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- > | IV | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- > > > And the Sequence Number and IV fields will hold the exact same number, > except that one is 32-bit while the other is 64-bit. > > Our draft simply negotiates omitting the IV field since it is redundant. > > Hope this helps > > Yoav > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a114b25fec59ae60535566fd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

I hope this has been= clarified. In order to clarify this I updated the text in the intro:
OLD:
This document defines how to compute the nonce locally= when it is implicit. It also specifies how to negotiate this behavior with= in the Internet Key Exchange version 2 (IKEv2 - RFC7296).

NEW:

This document defines how to compute the nonce loca= lly when it is=20 implicit. It also specifies how peers agree with Internet Key Exchange vers= ion 2 IKEv2 on using an implicit IV versus an explicit IV


Please= let us know if that address your purpose.

BR,
Danie= l

On Fri= , Jun 10, 2016 at 2:01 AM, Yoav Nir <ynir.ietf@gmail.com> = wrote:
Hi, Paul

On 10 Jun 2016, at 5:42 AM, Paul Wouters <paul@nohats.ca> wrote:

> On Thu, 9 Jun 2016, Daniel Migault wrote:
>
>> Please find our new proposal with ESP using implicit IV [1]. We wo= uld like to present and discuss it at the next IETF meeting.
>
> I must understand it wrong...
>
> Aren't these IVs different per ESP packet? And unrelated to IKE > values? How do both parties calculate the IV if it is not send as part=
> of the packet?
>
>> From what I understand, only part of that comes from IKE (aka the = salt
> values that are taken from the IKE KEYMAT). As far as I understand, it=
> still needs to be unpredictable?
>
> If this IV somehow comes from IKE, it might be very tricky for FIPS > certifications, because the security of the ESP IV then depends on
> the IKE userland.
>

All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CC= M, ChaCha20-Poly1305) require a nonce that is given in the IV field of an E= SP packet.

For all of those algorithms, the respective RFC recommends to use a counter= to guarantee nonce uniqueness. Yes, you can use an LFSR instead, but a cou= nter is simpler.

ESP already has a counter - the packet sequence. If you follow the advice i= n the RFCs the ESP header will look like this:

=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Security Parameters= Index (SPI)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Sequence Number=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IV=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| | |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----

And the Sequence Number and IV fields will hold the exact same number, exce= pt that one is 32-bit while the other is 64-bit.

Our draft simply negotiates omitting the IV field since it is redundant.
Hope this helps

Yoav


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

--001a114b25fec59ae60535566fd8-- From nobody Wed Jun 15 12:56:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D847512DB9A for ; Wed, 15 Jun 2016 12:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnikK-5IRT93 for ; Wed, 15 Jun 2016 12:56:16 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5F512DB6D for ; Wed, 15 Jun 2016 12:56:15 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id a66so27820728wme.0 for ; Wed, 15 Jun 2016 12:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=GvpZ16uBWDCPpGBhvFp/FsPJsZ3Qm8uYmcDlR/CDM4U=; b=gShNv4PWO9yCw6OYZ7aS6deOr0aeqpnX91cnOS533c46L0amtTn+V6TToVJjztdo2i Ds4GIfYODCj+X8rTFA0kb1a+LmS2jOONPoh326hFjzpK9Kg5w+hknjE9Ek98VOHSUULr LnKRAMkqHKtPnbh62Ukh6oGeqAfjcJErLRWBZNCD4VKQIILmuxaDWI9q4COTYq+Brfpd BABwGtohxwKIPpnV8eXlPA1bE6ryUuqhsJF3RBaiQfVL89OjNtXkf8PGqsD+oFPStJeF L23s80r8G55Q1q4s4R36kbIhrJbtv/dir18TC4wwXBTbSmxf06sGbcplp71n8NTtYN5n faZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GvpZ16uBWDCPpGBhvFp/FsPJsZ3Qm8uYmcDlR/CDM4U=; b=DMgAcX6OmaznBDL4+dT9fREwtrt4Rj8Z2VIyzVU22I1O4PPhK3zuMNr/0gVwTnslgU V5xf1T61wt32Y805TfeMrAPz+KG0BMXIrLIFy0o3QcHcbNYNdZhTTxhSj92pDjGrw660 9T2AbCH71TUVMu7D1yugCopTEObVC7ma4dHuZPkUQFLh50jepU9Ka9yAmdEEdEwwBzJK uZMKLhk51yHmkC8h2K8F2ZggISgJOwvGqozHzaQMIHbmdA2KvVGRKk73hL1swBbAB7ep jJDTFe7W7MLdPCdysXZSEV4jPOIXHlzyqwC/RCcHrajllh1xWl4ytPAIWLfhoIVEcQ/M VLLA== X-Gm-Message-State: ALyK8tIqGcCs2uLMJwsDfcXa8fpe1eyMmT5bFit+/LvTXFk+C8KNNTJz0ocm0r1nXHWzMQ== X-Received: by 10.194.164.200 with SMTP id ys8mr356310wjb.79.1466020573998; Wed, 15 Jun 2016 12:56:13 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id r129sm11294196wmr.20.2016.06.15.12.56.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Jun 2016 12:56:13 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_484E1D56-2324-472F-BA2B-87DE1B4B7743" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Wed, 15 Jun 2016 22:56:10 +0300 Message-Id: References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> To: Daniel Migault X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 19:56:18 -0000 --Apple-Mail=_484E1D56-2324-472F-BA2B-87DE1B4B7743 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Daniel I think since we didn=E2=80=99t go with some of the wild ideas that = would allow implicit IV in CBC, the verb =E2=80=9Ccompute=E2=80=9D here = is somewhat confusing. We=E2=80=99re pretty much just copying the = sequence number. =E2=80=9CCompute=E2=80=9D implies something a bit more = CPU intensive. Yoav > On 15 Jun 2016, at 10:50 PM, Daniel Migault = wrote: >=20 > Hi Paul,=20 >=20 > I hope this has been clarified. In order to clarify this I updated the = text in the intro: >=20 > OLD: > This document defines how to compute the nonce locally when it is = implicit. It also specifies how to negotiate this behavior within the = Internet Key Exchange version 2 (IKEv2 - RFC7296). >=20 > NEW: >=20 > This document defines how to compute the nonce locally when it is = implicit. It also specifies how peers agree with Internet Key Exchange = version 2 IKEv2 on using an implicit IV versus an explicit IV >=20 >=20 > Please let us know if that address your purpose. >=20 > BR,=20 > Daniel >=20 > On Fri, Jun 10, 2016 at 2:01 AM, Yoav Nir > wrote: > Hi, Paul >=20 > On 10 Jun 2016, at 5:42 AM, Paul Wouters > wrote: >=20 > > On Thu, 9 Jun 2016, Daniel Migault wrote: > > > >> Please find our new proposal with ESP using implicit IV [1]. We = would like to present and discuss it at the next IETF meeting. > > > > I must understand it wrong... > > > > Aren't these IVs different per ESP packet? And unrelated to IKE > > values? How do both parties calculate the IV if it is not send as = part > > of the packet? > > > >> =46rom what I understand, only part of that comes from IKE (aka the = salt > > values that are taken from the IKE KEYMAT). As far as I understand, = it > > still needs to be unpredictable? > > > > If this IV somehow comes from IKE, it might be very tricky for FIPS > > certifications, because the security of the ESP IV then depends on > > the IKE userland. > > >=20 > All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CCM, = ChaCha20-Poly1305) require a nonce that is given in the IV field of an = ESP packet. >=20 > For all of those algorithms, the respective RFC recommends to use a = counter to guarantee nonce uniqueness. Yes, you can use an LFSR instead, = but a counter is simpler. >=20 > ESP already has a counter - the packet sequence. If you follow the = advice in the RFCs the ESP header will look like this: >=20 > 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 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- > | Security Parameters Index (SPI) | = ^Int. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = |Cov- > | Sequence Number | = |ered > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = ---- > | IV | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = ---- >=20 >=20 > And the Sequence Number and IV fields will hold the exact same number, = except that one is 32-bit while the other is 64-bit. >=20 > Our draft simply negotiates omitting the IV field since it is = redundant. >=20 > Hope this helps >=20 > Yoav >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = >=20 --Apple-Mail=_484E1D56-2324-472F-BA2B-87DE1B4B7743 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Daniel

I think since we didn=E2=80=99t go with some of the wild = ideas that would allow implicit IV in CBC, the verb =E2=80=9Ccompute=E2=80= =9D here is somewhat confusing. We=E2=80=99re pretty much just copying = the sequence number. =E2=80=9CCompute=E2=80=9D implies something a bit = more CPU intensive.

Yoav

On = 15 Jun 2016, at 10:50 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi Paul,

I hope this has been clarified. In order = to clarify this I updated the text in the intro:

OLD:
This document = defines how to compute the nonce locally when it is implicit. It also = specifies how to negotiate this behavior within the Internet Key = Exchange version 2 (IKEv2 - RFC7296).

NEW:

This document defines how to compute the nonce = locally when it is=20 implicit. It also specifies how peers agree with Internet Key Exchange = version 2 IKEv2 on using an implicit IV versus an explicit IV


Please let us know if that = address your purpose.

BR,
Daniel

On Fri, = Jun 10, 2016 at 2:01 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
Hi, Paul

On 10 Jun 2016, at 5:42 AM, Paul Wouters <paul@nohats.ca> = wrote:

> On Thu, 9 Jun 2016, Daniel Migault wrote:
>
>> Please find our new proposal with ESP using implicit IV [1]. We = would like to present and discuss it at the next IETF meeting.
>
> I must understand it wrong...
>
> Aren't these IVs different per ESP packet? And unrelated to IKE
> values? How do both parties calculate the IV if it is not send as = part
> of the packet?
>
>> =46rom what I understand, only part of that comes from IKE (aka = the salt
> values that are taken from the IKE KEYMAT). As far as I understand, = it
> still needs to be unpredictable?
>
> If this IV somehow comes from IKE, it might be very tricky for = FIPS
> certifications, because the security of the ESP IV then depends = on
> the IKE userland.
>

All the algorithms we mention in the draft (AES-CTR, AES-GCM, = AES-CCM, ChaCha20-Poly1305) require a nonce that is given in the IV = field of an ESP packet.

For all of those algorithms, the respective RFC recommends to use a = counter to guarantee nonce uniqueness. Yes, you can use an LFSR instead, = but a counter is simpler.

ESP already has a counter - the packet sequence. If you follow the = advice in the RFCs the ESP header will look like this:

 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 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = ----
|               Security = Parameters Index (SPI)              =    | ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ = |Cov-
|                    =   Sequence Number              =             | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = ----
|                    =           IV          =                     =  | |
|                    =                     =                     =    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | = ----


And the Sequence Number and IV fields will hold the exact same number, = except that one is 32-bit while the other is 64-bit.

Our draft simply negotiates omitting the IV field since it is = redundant.

Hope this helps

Yoav


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


= --Apple-Mail=_484E1D56-2324-472F-BA2B-87DE1B4B7743-- From nobody Wed Jun 15 13:00:45 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC7312DB3C for ; Wed, 15 Jun 2016 13:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVwNdCVwdRHH for ; Wed, 15 Jun 2016 13:00:41 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D781412DB38 for ; Wed, 15 Jun 2016 13:00:40 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id a66so27968353wme.0 for ; Wed, 15 Jun 2016 13:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=/M3U9AA3LjBNYaRZo9uYF0DqSNFVq9E6+6iEFSvHKOo=; b=HWz8bxkt9uB6YWCub9zphZ3j5U1o9jiMnfHqNVDA41IDSxdoj64YOmnEOLVHR4xiYN ZSp68pyW0R31+i0uKJncTI/qLbluQRXSp6LIt2Q7HtWxZC2k9qrHCFIvZPzUAENELpA2 hi4ri/+DDouVXGRXNjhb/ShprvbFsuNQ1sdMXbH5PAzxgXtPOSuGQbTzdQIUSaCJiAjd snGs8Ll2QQ0xgj83DotmvEy4aOdcQwO+Zeg/Cr4NoggXw7b3QSXBY7qX8sP1U6+u7WNO hqFnFkdwdAkEtj/ipCleh+oYPX5zraY0sEgbgIopnCu88mWfJh0xVwke9AKZ8m2WLvbb tqrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=/M3U9AA3LjBNYaRZo9uYF0DqSNFVq9E6+6iEFSvHKOo=; b=SHSzKRdboh8ZTuYXvsJPwjYXwgsspns2GeCYtVg2WXEyOekfCAk+Zzeob24tpRkRsS hjq+UQZ3lIbJNzY80KrRRvASKC6ZCCuR5poN92xNsHm4WZJ+7KHIKpl301DD1GSiZlYL Ul8QEj9oQntopr0vgjPxq60FnOVNO6Li9r16mDTE0jmTwrHBJylRe20vrLut4jgDIcbv zq1jx1YRIGjRW0XLjBdvMaMtthL4CMaLOVgbijoFAgIgMriS7sRHXpWuRa8E12W/mrhq EYVVY8rIU1NvHYcgYCa6ZxDAUdF7wf/flJ+mVi+ilnZI+yRNu9dXNJEBXOZ7NzHOj8KQ 2Huw== X-Gm-Message-State: ALyK8tK5WUJxPcybx9np16BNFZn/D9oDBf+zhLU2myWqDVc31fqZAUeAwViSovM1yjm0dY0+KB6C/m4s+VRRvQ== X-Received: by 10.28.30.149 with SMTP id e143mr904309wme.81.1466020839314; Wed, 15 Jun 2016 13:00:39 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.34.99 with HTTP; Wed, 15 Jun 2016 13:00:38 -0700 (PDT) In-Reply-To: <1E256828227C472DAC974F996555AE2B@buildpc> References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <1E256828227C472DAC974F996555AE2B@buildpc> From: Daniel Migault Date: Wed, 15 Jun 2016 16:00:38 -0400 X-Google-Sender-Auth: YyRB9JuBa-zA1TJuNiVRRi9Nt4c Message-ID: To: Valery Smyslov Content-Type: multipart/alternative; boundary=001a114b25fe5c5cba05355693c0 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] New Version Notification fordraft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 20:00:43 -0000 --001a114b25fe5c5cba05355693c0 Content-Type: text/plain; charset=UTF-8 Hi, Valery, Thank you for pointing this section. I assume that is section 8 RFC3686. I will send a new thread to discuss that. I think the motivation is provided in the introduction, that is reducing the size of the payload, which was considered as negligible overhead in RFC3686. In addition RFC3686 specify that the use of an explicit IV instead of an implicit IV was not based on cryptographic considerations. However, I propose that the the Security Consideration section refer to the design section and explain how using the sequence number for the IV impacts the systems. For the vote I will come later to sum up the results. BR, Daniel On Fri, Jun 10, 2016 at 3:17 AM, Valery Smyslov wrote: > Hi Daniel, > > a couple of comments. RFC 3686 Section 6 provides design rationale for > making an IV explicit. > I think it will be good if your draft also gives some design rationale why > you came > to the opposite conclusion (just to give readers an insight why in IoT > world > the weight of different factors might change dramatically comparing to > "big" world). > > Hi, >> >> Please find our new proposal with ESP using implicit IV [1]. We would >> like to present and discuss it at the next IETF meeting. >> >> We would be happy to have the WG opinion on which you think is the better >> way to negotiate the implicit IV between two peers. The different options >> are detailed in section 5 and copy paste here in the email: >> >> """ >> Negotiation of the use of implicit IV can be done in 3 different >> ways: >> >> o An IMPLICIT IV Transform Type. A proposal that contains this >> transform type requires (if accepted) that IPsec use the implicit >> IV and not include an explicit IV in the packets. To facilitate >> backward compatibility with non-supporting implementations the >> Initiator SHOULD add another proposal that does not include this >> transform type as well as cryptographic suite the Initiator does >> not support the implicit IV. >> > > The problems with this option is that it adds additional interdependence > between > Transforms presenting in the Proposal. We already have this for AEAD > algorithms, which requires them to be placed in a separate Proposal > from non-AEAD ciphers. This complicates both encoders and parses > (I'd rather have separate Transform Type for AEAD ciphers, but that is > that). > With new Transform Type which is only applicable to some of Transform IDs > the things become even more complicated for no practical reason. > > o An IMPLICIT IV Transform ID. This doubles the number of ENCR >> transform IDs by creating an ENCR_AES_CCM_16_IIV for each >> ENCR_AES_CCM_16. >> >> o An IMPLICIT IV Transform Attribute, which would be associated to a >> Transform Type ID, specifying the use of an implicit IV. marks a >> particular ENCR transform as using implicit IVs. To facilitate >> backward compatibility with non-supporting implementations the >> Initiator SHOULD add another ENCR transform for each algorithm so >> marked. In other words, for each ENCR_AES_CCM_16 with >> keylength=256 and IIV=1, there will need to be an ENCR_AES_CCM_16 >> with keylength=256 and no IIV attribute. >> >> """ >> > > These two options are similar in terms of complexity. > I slightly prefer new Transform IDs over an Implicit IV Attribute since > in this case it is very clear from the IANA registry which ciphers > can be used with Implicit IV. > > Regards, > Valery. > > > [1] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Thursday, June 09, 2016 12:12 PM >> To: Tobias Guggemos; Yoav Nir; Daniel Migault >> Subject: New Version Notification for >> draft-mglt-ipsecme-implicit-iv-00.txt >> >> >> A new version of I-D, draft-mglt-ipsecme-implicit-iv-00.txt >> has been successfully submitted by Daniel Migault and posted to the IETF >> repository. >> >> Name: draft-mglt-ipsecme-implicit-iv >> Revision: 00 >> Title: Implicit IV for Counter-based Ciphers in IPsec >> Document date: 2016-06-09 >> Group: Individual Submission >> Pages: 7 >> URL: >> https://www.ietf.org/internet-drafts/draft-mglt-ipsecme-implicit-iv-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ >> Htmlized: >> https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-00 >> >> >> Abstract: >> IPsec ESP sends an initialization vector (IV) or nonce in each >> packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, AES- >> CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not >> require an unpredictable nonce. When using such algorithms the >> packet counter value can be used to generate a nonce, saving 8 octets >> per packet. This document describes how to do this. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> 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 > --001a114b25fe5c5cba05355693c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Valery,

Thank you for pointing= this section. I assume that is section 8 RFC3686. I will send a new thread= to discuss that. I think the motivation is provided in the introduction, t= hat is reducing the size of the payload, which was considered as negligible= overhead in RFC3686.

In addition RFC3686 specify that th= e use of an explicit IV instead of an implicit IV was not based on cryptogr= aphic considerations. However, I propose that the the Security Consideratio= n section refer to the design section and explain how using the sequence nu= mber for the IV impacts the systems.

For the vote I will= come later to sum up the results.

BR,
Dan= iel=C2=A0


On Fri, Jun 10, 2016 at 3:17 AM, Valery Smyslov <svanru@gmail.= com> wrote:
Hi Daniel,

a couple of comments. RFC 3686 Section 6 provides design rationale for maki= ng an IV explicit.
I think it will be good if your draft also gives some design rationale why = you came
to the opposite conclusion (just to give readers an insight why in IoT worl= d
the weight of different factors might change dramatically comparing to &quo= t;big" world).

Hi,

Please find our new proposal with ESP using implicit IV [1]. We would like = to present and discuss it at the next IETF meeting.

We would be happy to have the WG opinion on which you think is the better w= ay to negotiate the implicit IV between two peers. The different options ar= e detailed in section 5 and copy paste here in the email:

"""
=C2=A0 Negotiation of the use of implicit IV can be done in 3 different
=C2=A0 ways:

=C2=A0 o=C2=A0 An IMPLICIT IV Transform Type.=C2=A0 A proposal that contain= s this
=C2=A0 =C2=A0 =C2=A0transform type requires (if accepted) that IPsec use th= e implicit
=C2=A0 =C2=A0 =C2=A0IV and not include an explicit IV in the packets.=C2=A0= To facilitate
=C2=A0 =C2=A0 =C2=A0backward compatibility with non-supporting implementati= ons the
=C2=A0 =C2=A0 =C2=A0Initiator SHOULD add another proposal that does not inc= lude this
=C2=A0 =C2=A0 =C2=A0transform type as well as cryptographic suite the Initi= ator does
=C2=A0 =C2=A0 =C2=A0not support the implicit IV.

 The problems with this option is that it adds additional interdependence be= tween
Transforms presenting in the Proposal. We already have this for AEAD
algorithms, which requires them to be placed in a separate Proposal
from non-AEAD ciphers. This complicates both encoders and parses
(I'd rather have separate Transform Type for AEAD ciphers, but that is = that).
With new Transform Type which is only applicable to some of Transform IDs the things become even more complicated for no practical reason.

=C2=A0 o=C2=A0 An IMPLICIT IV Transform ID.=C2=A0 This doubles the number o= f ENCR
=C2=A0 =C2=A0 =C2=A0transform IDs by creating an ENCR_AES_CCM_16_IIV for ea= ch
=C2=A0 =C2=A0 =C2=A0ENCR_AES_CCM_16.

=C2=A0 o=C2=A0 An IMPLICIT IV Transform Attribute, which would be associate= d to a
=C2=A0 =C2=A0 =C2=A0Transform Type ID, specifying the use of an implicit IV= . marks a
=C2=A0 =C2=A0 =C2=A0particular ENCR transform as using implicit IVs.=C2=A0 = To facilitate
=C2=A0 =C2=A0 =C2=A0backward compatibility with non-supporting implementati= ons the
=C2=A0 =C2=A0 =C2=A0Initiator SHOULD add another ENCR transform for each al= gorithm so
=C2=A0 =C2=A0 =C2=A0marked.=C2=A0 In other words, for each ENCR_AES_CCM_16 = with
=C2=A0 =C2=A0 =C2=A0keylength=3D256 and IIV=3D1, there will need to be an E= NCR_AES_CCM_16
=C2=A0 =C2=A0 =C2=A0with keylength=3D256 and no IIV attribute.

"""

 These two options are similar in terms of complexity.
I slightly prefer new Transform IDs over an Implicit IV Attribute since
in this case it is very clear from the IANA registry which ciphers
can be used with Implicit IV.

Regards,
Valery.


[1] https://datatracker.ietf.org/doc= /draft-mglt-ipsecme-implicit-iv/

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, June 09, 2016 12:12 PM
To: Tobias Guggemos; Yoav Nir; Daniel Migault
Subject: New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt=


A new version of I-D, draft-mglt-ipsecme-implicit-iv-00.txt
has been successfully submitted by Daniel Migault and posted to the IETF re= pository.

Name: draft-mglt-ipsecme-implicit-iv
Revision: 00
Title: Implicit IV for Counter-based Ciphers in IPsec
Document date: 2016-06-09
Group: Individual Submission
Pages: 7
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mglt-ipsecme= -implicit-iv-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0htt= ps://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-00


Abstract:
=C2=A0 IPsec ESP sends an initialization vector (IV) or nonce in each
=C2=A0 packet, adding 8 or 16 octets.=C2=A0 Some algorithms such as AES-GCM= , AES-
=C2=A0 CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not=
=C2=A0 require an unpredictable nonce.=C2=A0 When using such algorithms the=
=C2=A0 packet counter value can be used to generate a nonce, saving 8 octet= s
=C2=A0 per packet.=C2=A0 This document describes how to do this.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

_______________________________________________
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

--001a114b25fe5c5cba05355693c0-- From nobody Wed Jun 15 13:14:58 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B59E12DB7E for ; Wed, 15 Jun 2016 13:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nioh82c-mwYw for ; Wed, 15 Jun 2016 13:14:54 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E0512DB96 for ; Wed, 15 Jun 2016 13:14:11 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id m124so40078784wme.1 for ; Wed, 15 Jun 2016 13:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=60G40UIMdbb+K/eRP6fuMPwZ/9Nz+q7s3cMJL7Kh2GM=; b=MQ9oHYzE3TokHA0Xq5r98PzrokippH6r7irI6T+Wb6Er+qUQq5qwo7/KV1eGuWp3AM 8oLF2kuGrz6VM2XuWPVqKM4/wvN6vXuy0lBtiXvrOdlHyhJ6yNHpgVvNrIt2wB7rhBLI SFrjF7fyDSXsjEzDY8PX86evUTTYe2gOXXwhOU+1SXbxPUxUbmvKDUN/a5H1LSLv8LzM FTiLkx3SAsEWDr69rH31qdIts5MS8Y9wcSnTohE++kGqgIy5RRNbdoy8pBnu/naTRQiR 7psft0ffEQBIm3KOANLQFuhyb+QpvKxALAEQIgTlCA3JOuFf8YLq29clr4IlF9nGn7hk FEsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=60G40UIMdbb+K/eRP6fuMPwZ/9Nz+q7s3cMJL7Kh2GM=; b=UN71kt7tKo1tioRHOiAKbHnu/P4VmfSB/wSpNedPLmzaFL10LSKpTLYUbeHZY+QT1X F0l1VFLnSFAfNUWb2+iy55quoXFputWMoYiOgYLl/lLUMfh8cMOicQ6fwYg9BW6bQc6A bscOEScw9tnR3VWQ+SuuZptX3DwuwPwfv0hvHIU3ACunrmpasfG/Y1M/a4evVo1A64Xc v8TNROkL0dVMLs0SwSTMFDvkKKQk+RVqO5ZmPJj0cDVb13CkDs19QY96kVKvxzdGUYnh yXgQ2trMjmMQLURqgWDpUmesJzM7f7lFumRVc8E/ooCuDbgyknY5l7/pHbtButMz8bq8 kkiA== X-Gm-Message-State: ALyK8tJQmAqmILV5Iet2lnkqH8r2oW7HUE4auBeUW1A1XKxLA7tNb5f0fboKR45sdPCxssUEl07ZMDSpwGuJCg== X-Received: by 10.194.3.51 with SMTP id 19mr440920wjz.57.1466021650031; Wed, 15 Jun 2016 13:14:10 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.34.99 with HTTP; Wed, 15 Jun 2016 13:14:09 -0700 (PDT) In-Reply-To: <575F28DB.2070703@gmail.com> References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> <38026197-8DCE-4F23-866D-83BB3777745F@gmail.com> <575F28DB.2070703@gmail.com> From: Daniel Migault Date: Wed, 15 Jun 2016 16:14:09 -0400 X-Google-Sender-Auth: UKl_eEe9a3CRIj7bBpoItkjnuNY Message-ID: To: Yaron Sheffer Content-Type: multipart/alternative; boundary=047d7b3a81fcaee987053556c315 Archived-At: Cc: IPsecME WG , Paul Wouters , Yoav Nir Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 20:14:56 -0000 --047d7b3a81fcaee987053556c315 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yaron, Thanks Yaron for the comments so I updated my local copy replacing RFC4104 by RFC4106 ;-) I also assume that leaving AES-CTR is fine, and so keep it in the draft. In the first version of the draft we described a way to have an implicit IV with AES-CBC. It was based on an additional key derivation for each direction and the IV was the sequence number encrypted with the key. During the presentation, we agreed that the additional complexity would not worth. The reason for that text is to make it clear that would be feasible. BR, Daniel On Mon, Jun 13, 2016 at 5:42 PM, Yaron Sheffer wrote: > On 13/06/16 06:00, Yoav Nir wrote: > >> >> On 10 Jun 2016, at 5:39 PM, Yaron Sheffer >> > wrote: >>> >>> Hi, >>> >>> The document takes care to not define Implicit IV for AES-CBC, and I >>> believe the underlying reason is malleability of the encryption. The >>> same would apply to AES-CTR. So I would suggest to: >>> >>> * Exclude AES-CTR from this draft, or... >>> * Better yet, restrict the draft to AEAD algorithms. >>> >>> BTW, the reference for AES-GCM is incorrect. Should be 4106. >>> >>> Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key >>> material. Is that kept intact by the current proposal? >>> >>> >> Hi, Yaron >> >> AES-CTR is pretty similar to AES-GCM and AES-CCM, except for the >> confusing terminology: >> >> * The 32-bit per-SA value derived from IKE is called =E2=80=9Cnonce=E2= =80=9D in RFC >> 3686 and =E2=80=9Csalt=E2=80=9D in RFC 4106 (thanks for the correcte= d reference). >> * The concatenation of 32-bit per-SA value and IV is called =E2=80=9Cn= once=E2=80=9D in >> RFC 4106 and doesn=E2=80=99t have a name in RFC 3686. >> * The concatenation of 32-bit per-SA value, IV, and block counter is >> called =E2=80=9Ccounter block=E2=80=9D in RFC 3686, but isn=E2=80= =99t explicitly mentioned >> in RFC 4106. The GCM spec also calls it =E2=80=9Ccounter block=E2=80= =9D. >> >> >> AFAICT it is not malleable like CBC. In CBC the issue was that an >> attacker knowing the next IV would be able to generate the first block >> of the next message such that IV xor Block0 would be whatever the >> attacker wanted. That block would be the input to the encryption >> function and thus the attacker could force the encryptor to encrypt >> whatever block it wanted. With counter mode (or GCM or CCM) the attacker >> has no control on the inputs to the encryption function. That is why RFC >> 3686 has text similar to the other documents: >> >> The same >> IV and key combination MUST NOT be used more than once. The >> encryptor can generate the IV in any manner that ensures uniqueness. >> Common approaches to IV generation include *incrementing a counter* >> for >> each packet and linear feedback shift registers (LFSRs). >> >> So I think CTR belongs in this draft as much as the others. >> >> And yes, the GCM salt or the CTR nonce are derived in the same way and >> used in the same way. >> >> Yoav >> >> > AES-CTR is potentially malleable by a MITM who can change counter values > into ones she'd observed before. However since RFC 3686 is very emphatic > about the need for integrity protection (Sec. 3.3), we should be fine. > > Thanks, > Yaron > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --047d7b3a81fcaee987053556c315 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yaron,

Thanks Yaron for the= comments so I updated my local copy replacing RFC4104 by RFC4106 ;-)
I also assume that leaving AES-CTR is fine, and so keep it in the draft= .

In the first version of the draft we described a way to hav= e an implicit IV with AES-CBC. It was based on an additional key derivation= for each direction and the IV was the sequence number encrypted with the k= ey.=C2=A0 During the presentation, we agreed that the additional complexity= would not worth. The reason for that text is to make it clear that would b= e feasible.

BR,
Daniel
=C2=A0

On M= on, Jun 13, 2016 at 5:42 PM, Yaron Sheffer <yaronf.ietf@gmail.com&= gt; wrote:
On 13/= 06/16 06:00, Yoav Nir wrote:

On 10 Jun 2016, at 5:39 PM, Yaron Sheffer <yaronf.ietf@gmail.com
 <mailto:yaron= f.ietf@gmail.com>> wrote:

Hi,

The document takes care to not define Implicit IV for AES-CBC, and I
believe the underlying reason is malleability of the encryption. The
same would apply to AES-CTR. So I would suggest to:

 =C2=A0 * Exclude AES-CTR from this draft, or...
=C2=A0 * Better yet, restrict the draft to AEAD algorithms.

BTW, the reference for AES-GCM is incorrect. Should be 4106.

Speaking of which, AES-GCM in ESP has a "salt" derived from IKE k= ey
material. Is that kept intact by the current proposal?


Hi, Yaron

AES-CTR is pretty similar to AES-GCM and AES-CCM, except for the
confusing terminology:

 =C2=A0 * The 32-bit per-SA value derived from IKE is called =E2=80=9Cnonce= =E2=80=9D in RFC
=C2=A0 =C2=A0 3686 and =E2=80=9Csalt=E2=80=9D in RFC 4106 (thanks for the c= orrected reference).
 =C2=A0 * The concatenation of 32-bit per-SA value and IV is called =E2=80= =9Cnonce=E2=80=9D in
=C2=A0 =C2=A0 RFC 4106 and doesn=E2=80=99t have a name in RFC 3686.
=C2=A0 * The concatenation of 32-bit per-SA value, IV, and block counter is=
=C2=A0 =C2=A0 called =E2=80=9Ccounter block=E2=80=9D=C2=A0 in RFC 3686, but= isn=E2=80=99t explicitly mentioned
=C2=A0 =C2=A0 in RFC 4106. The GCM spec also calls it =E2=80=9Ccounter bloc= k=E2=80=9D.


AFAICT it is not malleable like CBC. In CBC the issue was that an
attacker knowing the next IV would be able to generate the first block
of the next message such that IV xor Block0 would be whatever the
attacker wanted. That block would be the input to the encryption
function and thus the attacker could force the encryptor to encrypt
whatever block it wanted. With counter mode (or GCM or CCM) the attacker has no control on the inputs to the encryption function. That is why RFC 3686 has text similar to the other documents:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 The same
=C2=A0 =C2=A0 IV and key combination MUST NOT be used more than once.=C2=A0= The
=C2=A0 =C2=A0 encryptor can generate the IV in any manner that ensures uniq= ueness.
 =C2=A0 =C2=A0 Common approaches to IV generation include *incrementing a co= unter* for
=C2=A0 =C2=A0 each packet and linear feedback shift registers (LFSRs).

So I think CTR belongs in this draft as much as the others.

And yes, the GCM salt or the CTR nonce are derived in the same way and
used in the same way.

Yoav


AES-CTR is potentially malleable by a MITM who can change counter values in= to ones she'd observed before. However since RFC 3686 is very emphatic = about the need for integrity protection (Sec. 3.3), we should be fine.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

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

--047d7b3a81fcaee987053556c315-- From nobody Wed Jun 15 13:42:55 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7386912D8F3 for ; Wed, 15 Jun 2016 13:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKFwNc3HUxJB for ; Wed, 15 Jun 2016 13:42:51 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFD112D131 for ; Wed, 15 Jun 2016 13:42:51 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id a66so29340823wme.0 for ; Wed, 15 Jun 2016 13:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=NM9/H3KAu4W+dkqL9Rcn2X69LZuk5MLEf2i1sv+uGOk=; b=MrWoWe0FU5HsutIfFGcUbBuSfQeom+glte0Le2AzACkAInq/gi47hS7e3gZOp2RSXt fPh/0qD4STKBWrA9KwxWqjxDPIIIUjGappWYegfb4r8MlCSHaB7+CdDPBIiS0E4F87k4 PYTejzlkukh3oOjMlwPeFBosPqFquI1I70+scor55WTTJR6BPFAR8HMezuFu1cj0Cum2 fqLxG7udp9bQZ7zmmJE5DqRRr1K76pXyZltKXns7w5Ppn/rpUeWfQP7xZbMTWOqjf6iv rE/Sg/tA3DC2s5PkjQOMuk2I2uURATj1iZrV9foaQXz7Gh94VDoWb4fx2by0p9D29abe yBjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=NM9/H3KAu4W+dkqL9Rcn2X69LZuk5MLEf2i1sv+uGOk=; b=lB1u14/wb9h58v/9zJnHFXTLq4Sir0Oe9j5AWPz/eoh3YG9xqfJTSUDTI3/IArtMzK lTxqyj+WivzDs0Q5bp/jvRBfwnlDAB3lSZtx5AeWEOBm1fmq+DR4f4F7/j74KvToMupV YbH5tl0q3dNsSWeyPa8B4MEaBQRiBisCftyhpOMJiXmJ86K0+JRkNc9QY3HIZ1qNE+DZ dS2iuxcUnw0yWaUYJPzoCgdLsLSP7zsXYsAp6p5+HOLxlzKnHjlcBR1TihGWk2etM2F5 m7Udk6572ONTdGLBMbshSDLgEUCo5QrKDZtNrbFyo3frwL+xiMkis4aqP7tLuOmMUEck AfAA== X-Gm-Message-State: ALyK8tLiyIMMHka4iFtriWT5ufIo1Wd0QNmPW7u9J/XjwPRaE0cNzbl7q22gAONvs9+1+Hxljzp6uqLpHqSeIw== X-Received: by 10.28.30.149 with SMTP id e143mr1021274wme.81.1466023369652; Wed, 15 Jun 2016 13:42:49 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.34.99 with HTTP; Wed, 15 Jun 2016 13:42:48 -0700 (PDT) In-Reply-To: References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> <38026197-8DCE-4F23-866D-83BB3777745F@gmail.com> <575F28DB.2070703@gmail.com> From: Daniel Migault Date: Wed, 15 Jun 2016 16:42:48 -0400 X-Google-Sender-Auth: rP-YUIUJ84ijkXnSKue_4O0oFjQ Message-ID: To: Yaron Sheffer Content-Type: multipart/alternative; boundary=001a114b25fe2e42060535572a93 Archived-At: Cc: IPsecME WG , Paul Wouters , Yoav Nir Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 20:42:54 -0000 --001a114b25fe2e42060535572a93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Regarding the negotiation of the use of the implicit IV three ways have been proposed. Currently it seems that the consensus is more encline to define Transform IDs. However, it has been raised that Transform Attributes might be a better protocol design choice. I would like to understand if there are any guidance whether using attributes is preferred to ID or vice versa and if there is any preference in using IMPLICIT IV Transform ID versus an IMPLICIT IV Transform Attribute. Here is a summary of the comments we received on the different ways to negotiate the use of the implicit IV. - a) IMPLICIT Transform Type seems to over complexify the the management of proposals. - b) IMPLICIT IV Transform ID seems the easiest way to move forward. In addition, IKEv2 is known to behave properly with new Transform IDs. - c) IMPLICIT IV Transform Attribute requires additional parsing. This is something that is not widely used outside key sizes. This solution mi= ght be preferred if it is considered a better architecture design than b). BR, Daniel On Wed, Jun 15, 2016 at 4:14 PM, Daniel Migault wrote: > Hi Yaron, > > Thanks Yaron for the comments so I updated my local copy replacing RFC410= 4 > by RFC4106 ;-) > I also assume that leaving AES-CTR is fine, and so keep it in the draft. > > In the first version of the draft we described a way to have an implicit > IV with AES-CBC. It was based on an additional key derivation for each > direction and the IV was the sequence number encrypted with the key. > During the presentation, we agreed that the additional complexity would n= ot > worth. The reason for that text is to make it clear that would be feasibl= e. > > BR, > Daniel > > > On Mon, Jun 13, 2016 at 5:42 PM, Yaron Sheffer > wrote: > >> On 13/06/16 06:00, Yoav Nir wrote: >> >>> >>> On 10 Jun 2016, at 5:39 PM, Yaron Sheffer >>> > wrote: >>>> >>>> Hi, >>>> >>>> The document takes care to not define Implicit IV for AES-CBC, and I >>>> believe the underlying reason is malleability of the encryption. The >>>> same would apply to AES-CTR. So I would suggest to: >>>> >>>> * Exclude AES-CTR from this draft, or... >>>> * Better yet, restrict the draft to AEAD algorithms. >>>> >>>> BTW, the reference for AES-GCM is incorrect. Should be 4106. >>>> >>>> Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key >>>> material. Is that kept intact by the current proposal? >>>> >>>> >>> Hi, Yaron >>> >>> AES-CTR is pretty similar to AES-GCM and AES-CCM, except for the >>> confusing terminology: >>> >>> * The 32-bit per-SA value derived from IKE is called =E2=80=9Cnonce= =E2=80=9D in RFC >>> 3686 and =E2=80=9Csalt=E2=80=9D in RFC 4106 (thanks for the correct= ed reference). >>> * The concatenation of 32-bit per-SA value and IV is called =E2=80=9C= nonce=E2=80=9D in >>> RFC 4106 and doesn=E2=80=99t have a name in RFC 3686. >>> * The concatenation of 32-bit per-SA value, IV, and block counter is >>> called =E2=80=9Ccounter block=E2=80=9D in RFC 3686, but isn=E2=80= =99t explicitly mentioned >>> in RFC 4106. The GCM spec also calls it =E2=80=9Ccounter block=E2= =80=9D. >>> >>> >>> AFAICT it is not malleable like CBC. In CBC the issue was that an >>> attacker knowing the next IV would be able to generate the first block >>> of the next message such that IV xor Block0 would be whatever the >>> attacker wanted. That block would be the input to the encryption >>> function and thus the attacker could force the encryptor to encrypt >>> whatever block it wanted. With counter mode (or GCM or CCM) the attacke= r >>> has no control on the inputs to the encryption function. That is why RF= C >>> 3686 has text similar to the other documents: >>> >>> The sam= e >>> IV and key combination MUST NOT be used more than once. The >>> encryptor can generate the IV in any manner that ensures uniqueness= . >>> Common approaches to IV generation include *incrementing a counter* >>> for >>> each packet and linear feedback shift registers (LFSRs). >>> >>> So I think CTR belongs in this draft as much as the others. >>> >>> And yes, the GCM salt or the CTR nonce are derived in the same way and >>> used in the same way. >>> >>> Yoav >>> >>> >> AES-CTR is potentially malleable by a MITM who can change counter values >> into ones she'd observed before. However since RFC 3686 is very emphatic >> about the need for integrity protection (Sec. 3.3), we should be fine. >> >> Thanks, >> Yaron >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > --001a114b25fe2e42060535572a93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Regarding the negotiation of t= he use of the implicit IV three ways have been proposed. Currently it seems= that the consensus is more encline to define Transform IDs. However, it ha= s been raised that Transform Attributes might be a better protocol design c= hoice.

I would like to understand if there are any guidan= ce whether using attributes is preferred to ID or vice versa and if there i= s any preference in using=C2=A0 IMPLICIT IV Transform ID versus an IMPLIC= IT IV Transform Attribute.
=C2=A0

Here is a summary of= the comments we received on the different ways to negotiate the use of the= implicit IV.
  • a) IMPLICIT Transform Type seems to ove= r complexify the the management of proposals.
  • b) IMPLICIT IV Trans= form ID seems the easiest way to move forward. In addition, IKEv2 is known = to behave properly with new Transform IDs.
  • c) IMPLICIT IV Transform= Attribute requires additional parsing. This is something that is not widel= y used outside key sizes. This solution might be preferred if it is conside= red a better architecture design than b).

=C2=A0=C2=A0 BR,
Daniel


=


O= n Wed, Jun 15, 2016 at 4:14 PM, Daniel Migault <daniel.migault@e= ricsson.com> wrote:
Hi Yaron,

Thanks Yaron for the commen= ts so I updated my local copy replacing RFC4104 by RFC4106 ;-)
I a= lso assume that leaving AES-CTR is fine, and so keep it in the draft.
<= br>
In the first version of the draft we described a way to have an im= plicit IV with AES-CBC. It was based on an additional key derivation for ea= ch direction and the IV was the sequence number encrypted with the key.=C2= =A0 During the presentation, we agreed that the additional complexity would= not worth. The reason for that text is to make it clear that would be feas= ible.

BR,
Daniel
=C2=A0
<= br>
On Mon, Jun 13, 2016 at 5:42 PM, Yaron Sheffe= r <yaronf.ietf@gmail.com> wrote:
On 13/06/16 06:00, Yoav Nir wrote:

On 10 Jun 2016, at 5:39 PM, Yaron Sheffer <yaronf.ietf@gmail.com
 <mailto:yaron= f.ietf@gmail.com>> wrote:

Hi,

The document takes care to not define Implicit IV for AES-CBC, and I
believe the underlying reason is malleability of the encryption. The
same would apply to AES-CTR. So I would suggest to:

 =C2=A0 * Exclude AES-CTR from this draft, or...
=C2=A0 * Better yet, restrict the draft to AEAD algorithms.

BTW, the reference for AES-GCM is incorrect. Should be 4106.

Speaking of which, AES-GCM in ESP has a "salt" derived from IKE k= ey
material. Is that kept intact by the current proposal?


Hi, Yaron

AES-CTR is pretty similar to AES-GCM and AES-CCM, except for the
confusing terminology:

 =C2=A0 * The 32-bit per-SA value derived from IKE is called =E2=80=9Cnonce= =E2=80=9D in RFC
=C2=A0 =C2=A0 3686 and =E2=80=9Csalt=E2=80=9D in RFC 4106 (thanks for the c= orrected reference).
 =C2=A0 * The concatenation of 32-bit per-SA value and IV is called =E2=80= =9Cnonce=E2=80=9D in
=C2=A0 =C2=A0 RFC 4106 and doesn=E2=80=99t have a name in RFC 3686.
=C2=A0 * The concatenation of 32-bit per-SA value, IV, and block counter is=
=C2=A0 =C2=A0 called =E2=80=9Ccounter block=E2=80=9D=C2=A0 in RFC 3686, but= isn=E2=80=99t explicitly mentioned
=C2=A0 =C2=A0 in RFC 4106. The GCM spec also calls it =E2=80=9Ccounter bloc= k=E2=80=9D.


AFAICT it is not malleable like CBC. In CBC the issue was that an
attacker knowing the next IV would be able to generate the first block
of the next message such that IV xor Block0 would be whatever the
attacker wanted. That block would be the input to the encryption
function and thus the attacker could force the encryptor to encrypt
whatever block it wanted. With counter mode (or GCM or CCM) the attacker has no control on the inputs to the encryption function. That is why RFC 3686 has text similar to the other documents:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 The same
=C2=A0 =C2=A0 IV and key combination MUST NOT be used more than once.=C2=A0= The
=C2=A0 =C2=A0 encryptor can generate the IV in any manner that ensures uniq= ueness.
 =C2=A0 =C2=A0 Common approaches to IV generation include *incrementing a co= unter* for
=C2=A0 =C2=A0 each packet and linear feedback shift registers (LFSRs).

So I think CTR belongs in this draft as much as the others.

And yes, the GCM salt or the CTR nonce are derived in the same way and
used in the same way.

Yoav


AES-CTR is potentially malleable by a MITM who can change counter values in= to ones she'd observed before. However since RFC 3686 is very emphatic = about the need for integrity protection (Sec. 3.3), we should be fine.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron


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


--001a114b25fe2e42060535572a93-- From nobody Wed Jun 15 13:49:46 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7B312DBBD for ; Wed, 15 Jun 2016 13:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kO0DhHyPS5h for ; Wed, 15 Jun 2016 13:49:41 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3FE12DBBE for ; Wed, 15 Jun 2016 13:49:41 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id a66so29549931wme.0 for ; Wed, 15 Jun 2016 13:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GoGAl5U3t3HCtZzSmQGIT5hfeNOE1ynB+bt7Z5W05DQ=; b=kbBa6XJcLtuGioa8Iniw24HaZ2KTFxiFVJ5DhbAmCbv0JNYIJ0B3wUgnaMDDe0mCX8 OsuqYPubdQ7hWF49g6JeZNvOCk2RMO0LxFkpXhBKZ91v69bmJ7KEB+f5XylvoWBffKq/ kG4vwFiMHFfdfKGmbqfUkkEVgGXqv7wtdvp5F6zrTWfHofdi6scwaqI09YRl0g3d34GG ttOup2TZWWHv58gE4OI6X5AXf6nMVtzQ7gtIcsvj1sS99iR9qKeBYDjbvyFmXTAP++i7 ofFWjC2eIqBPC7OGzT1LqNbPypwo4TPLD2tn/7AvO11DiAz+LeRHSqXYCsD3kmFJrWUQ 5xFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GoGAl5U3t3HCtZzSmQGIT5hfeNOE1ynB+bt7Z5W05DQ=; b=Heau7n6qwSwCS68f8zBZMDoxQZV0qC88FCvGIJnimy+oetea0vszed/m3Ql8xffRvq f6bBYmY8+awZGEqRSDPrZKsLQIPK2BIJhhfI7KFCw9ejAiRUUPuf/u5zGpvxLgtLRLwm a633YXmem3KYTyct/3Zf715WwZiL8biYvsTdAbcmxh+f6VMODdFzDPcmYAFFIdaGB+BV 8VeQILdCPht4hq9cydisj6Bd+L6Tx76K4tzjY9DTpl3dMddpjYpr+gPXhGIQ6Dp+lg+r qZ2tV/EzR+nAr99d3u6SkAlIGji6cKPfSyraXWU0zBzh7y1mOlp5ki/mCA3/8+XMbnCK YFTg== X-Gm-Message-State: ALyK8tItZUvqV82przF+baqxE+g+MqNa/Zdqh6bJXGdoqT/9pVAoMPQq4dcTstSFidciCXm5Cj3wS8yoj/WbUg== X-Received: by 10.194.3.51 with SMTP id 19mr551684wjz.57.1466023779729; Wed, 15 Jun 2016 13:49:39 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.34.99 with HTTP; Wed, 15 Jun 2016 13:49:38 -0700 (PDT) In-Reply-To: References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> From: Daniel Migault Date: Wed, 15 Jun 2016 16:49:38 -0400 X-Google-Sender-Auth: 2ePb4uY9dI98QbrfaSFrj4vhplA Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=047d7b3a81fc9f898b053557423f Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 20:49:44 -0000 --047d7b3a81fc9f898b053557423f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yoav, You are right. Would the word "generate" more appropriated ? OLD: This document defines how to compute the nonce locally when it is implicit. It also specifies how peers agree with Internet Key Exchange version 2 IKEv2 on using an implicit IV versus an explicit IV. NEW: This document defines how to generate the nonce locally when it is implicit. It also specifies how peers agree with Internet Key Exchange version 2 IKEv2 on using an implicit IV versus an explicit IV BR, Daniel On Wed, Jun 15, 2016 at 3:56 PM, Yoav Nir wrote: > Hi, Daniel > > I think since we didn=E2=80=99t go with some of the wild ideas that would= allow > implicit IV in CBC, the verb =E2=80=9Ccompute=E2=80=9D here is somewhat c= onfusing. We=E2=80=99re > pretty much just copying the sequence number. =E2=80=9CCompute=E2=80=9D i= mplies something a > bit more CPU intensive. > > Yoav > > On 15 Jun 2016, at 10:50 PM, Daniel Migault > wrote: > > Hi Paul, > > I hope this has been clarified. In order to clarify this I updated the > text in the intro: > > OLD: > This document defines how to compute the nonce locally when it is > implicit. It also specifies how to negotiate this behavior within the > Internet Key Exchange version 2 (IKEv2 - RFC7296). > > NEW: > > This document defines how to compute the nonce locally when it is > implicit. It also specifies how peers agree with Internet Key Exchange > version 2 IKEv2 on using an implicit IV versus an explicit IV > > > Please let us know if that address your purpose. > > BR, > Daniel > > On Fri, Jun 10, 2016 at 2:01 AM, Yoav Nir wrote: > >> Hi, Paul >> >> On 10 Jun 2016, at 5:42 AM, Paul Wouters wrote: >> >> > On Thu, 9 Jun 2016, Daniel Migault wrote: >> > >> >> Please find our new proposal with ESP using implicit IV [1]. We would >> like to present and discuss it at the next IETF meeting. >> > >> > I must understand it wrong... >> > >> > Aren't these IVs different per ESP packet? And unrelated to IKE >> > values? How do both parties calculate the IV if it is not send as part >> > of the packet? >> > >> >> From what I understand, only part of that comes from IKE (aka the sal= t >> > values that are taken from the IKE KEYMAT). As far as I understand, it >> > still needs to be unpredictable? >> > >> > If this IV somehow comes from IKE, it might be very tricky for FIPS >> > certifications, because the security of the ESP IV then depends on >> > the IKE userland. >> > >> >> All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CCM, >> ChaCha20-Poly1305) require a nonce that is given in the IV field of an E= SP >> packet. >> >> For all of those algorithms, the respective RFC recommends to use a >> counter to guarantee nonce uniqueness. Yes, you can use an LFSR instead, >> but a counter is simpler. >> >> ESP already has a counter - the packet sequence. If you follow the advic= e >> in the RFCs the ESP header will look like this: >> >> 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 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- >> | Security Parameters Index (SPI) | ^Int. >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- >> | Sequence Number | |ered >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- >> | IV | | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- >> >> >> And the Sequence Number and IV fields will hold the exact same number, >> except that one is 32-bit while the other is 64-bit. >> >> Our draft simply negotiates omitting the IV field since it is redundant. >> >> Hope this helps >> >> Yoav >> >> >> _______________________________________________ >> 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 > > --047d7b3a81fc9f898b053557423f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yoav,

You are right. = Would the word "generate" more appropriated ?

= OLD:

This document defines how to compute the=20 nonce locally when it is=20 implicit. It also specifies how peers agree with Internet Key Exchange=20 version 2 IKEv2 on using an implicit IV versus an explicit IV.

= NEW:

This document defines how to generate the=20 nonce locally when it is=20 implicit. It also specifies how peers agree with Internet Key Exchange=20 version 2 IKEv2 on using an implicit IV versus an explicit IV

= BR,
Daniel

On Wed, Jun 15, 2016 at 3:56 PM, Yoav Nir &l= t;ynir.ietf@gmail.= com> wrote:
Hi, Daniel

I think since we didn=E2= =80=99t go with some of the wild ideas that would allow implicit IV in CBC,= the verb =E2=80=9Ccompute=E2=80=9D here is somewhat confusing. We=E2=80=99= re pretty much just copying the sequence number. =E2=80=9CCompute=E2=80=9D = implies something a bit more CPU intensive.

Yoav

On 15 = Jun 2016, at 10:50 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:<= /div>
Hi Paul,

I hope= this has been clarified. In order to clarify this I updated the text in th= e intro:

OLD:
This document defines how to compute the= nonce locally when it is implicit. It also specifies how to negotiate this= behavior within the Internet Key Exchange version 2 (IKEv2 - RFC7296).
=
NEW:

This document defines how to compute = the nonce locally when it is=20 implicit. It also specifies how peers agree with Internet Key Exchange vers= ion 2 IKEv2 on using an implicit IV versus an explicit IV


Please= let us know if that address your purpose.

BR,
Danie= l

On Fri= , Jun 10, 2016 at 2:01 AM, Yoav Nir <ynir.ietf@gmail.com> = wrote:
Hi, Paul

On 10 Jun 2016, at 5:42 AM, Paul Wouters <paul@nohats.ca> wrote:

> On Thu, 9 Jun 2016, Daniel Migault wrote:
>
>> Please find our new proposal with ESP using implicit IV [1]. We wo= uld like to present and discuss it at the next IETF meeting.
>
> I must understand it wrong...
>
> Aren't these IVs different per ESP packet? And unrelated to IKE > values? How do both parties calculate the IV if it is not send as part=
> of the packet?
>
>> From what I understand, only part of that comes from IKE (aka the = salt
> values that are taken from the IKE KEYMAT). As far as I understand, it=
> still needs to be unpredictable?
>
> If this IV somehow comes from IKE, it might be very tricky for FIPS > certifications, because the security of the ESP IV then depends on
> the IKE userland.
>

All the algorithms we mention in the draft (AES-CTR, AES-GCM, AES-CC= M, ChaCha20-Poly1305) require a nonce that is given in the IV field of an E= SP packet.

For all of those algorithms, the respective RFC recommends to use a counter= to guarantee nonce uniqueness. Yes, you can use an LFSR instead, but a cou= nter is simpler.

ESP already has a counter - the packet sequence. If you follow the advice i= n the RFCs the ESP header will look like this:

=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Security Parameters= Index (SPI)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= ^Int.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Sequence Number=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | |ered
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IV=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| | |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----

And the Sequence Number and IV fields will hold the exact same number, exce= pt that one is 32-bit while the other is 64-bit.

Our draft simply negotiates omitting the IV field since it is redundant.
Hope this helps

Yoav


_______________________________________________
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


--047d7b3a81fc9f898b053557423f-- From nobody Wed Jun 15 14:00:23 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349FC12D95A for ; Wed, 15 Jun 2016 14:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yCKUh9UPDJGA for ; Wed, 15 Jun 2016 14:00:21 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CBDF12D944 for ; Wed, 15 Jun 2016 14:00:21 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rVJnG5BFhz1jM; Wed, 15 Jun 2016 23:00:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id pm29GPPrUuz7; Wed, 15 Jun 2016 23:00:17 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 15 Jun 2016 23:00:17 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id CA050C0C61; Wed, 15 Jun 2016 17:00:16 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca CA050C0C61 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id ADC8E40BDBF8; Wed, 15 Jun 2016 17:00:16 -0400 (EDT) Date: Wed, 15 Jun 2016 17:00:16 -0400 (EDT) From: Paul Wouters To: Daniel Migault In-Reply-To: Message-ID: References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG , Yoav Nir Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2016 21:00:22 -0000 On Wed, 15 Jun 2016, Daniel Migault wrote: > You are right. Would the word "generate" more appropriated ? "obtain" ? Or just reveal your "secret" and state "is taken from the ESP sequence number". Paul From nobody Wed Jun 15 20:03:57 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F03912D9AD; Wed, 15 Jun 2016 20:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_ymHpO0pU1P; Wed, 15 Jun 2016 20:03:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1BE412DC93; Wed, 15 Jun 2016 20:03:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMA63591; Thu, 16 Jun 2016 03:03:51 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 16 Jun 2016 04:03:50 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 16 Jun 2016 11:03:39 +0800 From: Xuxiaohu To: Lou Berger , Linda Dunbar , Liyizhou , NVO3 Thread-Topic: [nvo3] FW: Any use cases of Overlay network requesting IPSec connection from the Underlay for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface? Thread-Index: AQHRxwVNSPtAs0OdV0+nna1mGK2X4J/qGOaAgAFIoAA= Date: Thu, 16 Jun 2016 03:03:39 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5646D5@NKGEML515-MBX.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.57621717.00BA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 11a1488b897e55878f2c39cf59e87dc5 Archived-At: Cc: "IPsec@ietf.org" Subject: Re: [IPsec] [nvo3] FW: Any use cases of Overlay network requesting IPSec connection from the Underlay for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 03:03:56 -0000 Hi Lou, If IPsec tunnels are used within data centers, the security need is well sa= tisfied. However, the ECMP capability built on the UDP tunnels is lost at a= ll. So, how about encapsulating IPsec ESP over UDP tunnels for load-balanci= ng improvement purpose? Note that this ESP-over-UDP encapsulation is differ= ent from the ESP-over-UDP encapsulation as described in RFC3948: the former= uses the UDP tunnel for load-balancing improvement purpose and therefore t= he source port is used as an entropy field, in contrast, the latter uses th= e UDP tunnel for NAT traversal purpose and therefore the source port is set= to a constant value (i.e.,4500). By the way, I had wrote a draft about this ESP-over-UDP approach (w/o submi= ssion) three years ago when considering how to use UDP tunnels to transport= MPLS and IP traffic. If there is enough interest on this ESP-over-UDP appr= oach, I can update it and then submit it for further discussion.=20 Best regards, Xiaohu > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Wednesday, June 15, 2016 11:00 PM > To: Linda Dunbar; Liyizhou; NVO3 > Subject: Re: [nvo3] FW: Any use cases of Overlay network requesting IPSec > connection from the Underlay for a specific time span? (was : Flow Securi= ty > Policies exchanged over I2NSF service layer interface? >=20 >=20 > Yes -- this is a real use case. >=20 > This use case (overlays interconnected over IPsec tunnels with NVE end > points) motivated our work on RFC5566 and we built supported for it (as w= ell as > other tunnel technologies) in a quagga based NVO3 controller. > This code is publicly available, but is not yet part of a standard quagga= release. >=20 > Lou >=20 > On 6/15/2016 8:55 AM, Linda Dunbar wrote: > > > > NVO3 Participants, > > > > > > > > I2NSF (Interface to Network Security function) has a work item in > > defining the flow security policy between domains (which includes > > inquiry of the capability from one domain to another and the actual > > flow policy rules from one domain to another). > > > > Very often, the paths (or links) among nodes of a overlay network are > > provided by other network operators (a.k.a. "underlay network"). The > > flow policy rules are intended to filter out unwanted traffic from > > underlay network so that various attack traffic won't saturated the > > access links to the overlay nodes. > > > > > > > > One interesting scenario brought up is Overlay nodes may need to > > request some traffic to be traversing IPsec channel. To achieve this > > goal, it is necessary for Overlay Network controller to inquire if the > > needed IPsec resource are even available before send the request (may > > even involve AAA process between controllers of each corresponding > > domain ). > > > > > > > > Want to have a survey if people see the use case of Overlay Network > > needing portion of traffic to be through IPSec channel? > > > > IPSec is supposed to be between two end nodes. Here we assume that the > > Overlay nodes don't have the resource or capability for IPsec, but > > expect IPsec between flow's ingress and egress nodes (i.e. NVE). > > > > > > > > Any opinion is appreciated. > > > > Thanks, > > > > Linda > > > > > > > > *From:*Linda Dunbar > > *Sent:* Tuesday, June 14, 2016 4:03 PM > > *To:* 'christian.jacquenet@orange.com'; BOUCADAIR Mohamed IMT/OLN > > *Cc:* I2NSF@ietf.org > > *Subject:* Any use cases of Overlay network requesting IPSec > > connection from the Underlay for a specific time span? (was : Flow > > Security Policies exchanged over I2NSF service layer interface? > > > > > > > > Christian, > > > > > > > > Your feedback seems to suggest that Overlay network Controller may > > send request to the underlay network controller requesting IPsec > > connections among overlay nodes. Do I understand you correctly? > > > > > > > > Are there any use cases of overlay network needing IPSec among their > > nodes only for a specific time span? i.e. Time based IPSec connection? > > > > > > > > Linda > > > > > > > > *From:*christian.jacquenet@orange.com > > > > [mailto:christian.jacquenet@orange.com] > > *Sent:* Monday, June 13, 2016 11:23 AM > > *To:* Linda Dunbar; BOUCADAIR Mohamed IMT/OLN > > *Subject:* RE: Any feedback on the Protocol Independent Flow Security > > Policies exchanged over I2NSF service layer interface? > > > > > > > > > > > > *[snip]* > > > > > > > > > > > > > > > > Very often, the paths (or links) among nodes of a overlay network are > > provided by other network operators (a.k.a. "underlay network"). Very > > much like traditional networks placing FW (Firewall) or IPS (Intrusion > > Prevention System) on the wire to enforce the flow security rules, > > I2NSF *_Protocol Independent Flow Security Policies_* can be used by > > overlay networks to request certain flow based security rules to be > > enforced by its underlay networks, to prevent the unwanted attacks > > traffic from occupying the physical links and ports to the overlay > > network nodes, and to avoid the overlay nodes' CPU/Storage/Port > > utilization being consumed down by the various attacks. Here is one > > example of "Overlay Video Communication network" exchange Flow > > Policies to the Underlay network. > > > > > > > > > > > > cid:image001.png@01D1B516.7F74E410 > > > > > > > > */[CJ] /*The above example clearly shows the necessary interaction > > between the two PDPs/controllers, to make sure that decisions made by > > the network controller accommodate the needs of the video customer as > > possibly expressed towards the video controller: for example, customer > > demands that the confidentiality of the videoconference needs to be > > preserved, thereby suggesting the use of the IPsec protocol suite. The > > video controller may enforce an IPsec design based upon the transport > > mode, whereas the network controller is solicited to allocate IPsec > > resources (read for example no AH, ESP in NULL mode) accordingly. This > > may possibly raise conflicting configuration tasks (the video > > controller uses AH, the network controller doesn't), thereby leading > > to inconsistency that may jeopardize the service. Whether BGP FS is > > used to carry security policy information between the two controllers > > is hardly the point, imho: what matters is the consistency of the > > (flow-based security policies enforced by both parties, and which > > should be derived from the customer's requirements (if any). > > > > The goal of I2NSF is to specify the common information model and data > > model for the *_ Protocol Independent Flow Security Policies _*which > > can be queried and set between domains. > > > > [CJ] OK. > > > > * * > > > > https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mit > > igation-api/ is just the starting point. (needs more work to improve > > the clarity). > > We are asking if people to express their opinion on this work to the > > I2NSF@ietf.org list. > > > > [CJ] I need to read this draft and will get back to you accordingly, > > but this may take a couple of weeks as I'm pretty busy for the time bei= ng. > > > > > > > > I'll let Med further comment as appropriate. > > > > > > > > Cheers, > > > > > > > > Christian. > > > > > > > > Thanks, Linda > > > > > > > > > _____________________________________________________________ > _________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les pieces > jointes. Les messages electroniques etant susceptibles d'alteration, Oran= ge > decline toute responsabilite si ce message a ete altere, deforme ou falsi= fie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete this > message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > modified, changed or falsified. > > Thank you. > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jun 15 21:28:18 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAA312D0A1 for ; Wed, 15 Jun 2016 21:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9y4cXp8Bme76 for ; Wed, 15 Jun 2016 21:28:13 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 627E912D16D for ; Wed, 15 Jun 2016 21:28:13 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id 5so39667965ioy.1 for ; Wed, 15 Jun 2016 21:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=KwfN2RVDc2BgHtDPhkbKAp7Eq08Hj5iv3wlylCAsvB8=; b=sE9GQj+fIyYrucGDzWXAUKgZt4i5baWffWDJ1HFyDiTuINqOvX0qvwVnxRBo2/oKBF gh9OKpS0hFPklAA3CQADMgw8DjZY5YrX/AmREjbQjYdgpAtEjcif/F5YmIn4ZxW658vY CZt4QZCtVQbQGxqTbu/PqTOCbzKWNarLhpZoorGX8itqTXhXaPKsWfIdnugiS85grftJ 3D8UQk8IGhtKOWXkgeYBL1OJf0Rg7Bot2QnaDepmhYXUaMw6e9/nLsld7OfoA1TwcWzU jC8qAWxT0wFJFwrJdxImRA9qQOamiqqZv+aCXtqy/IJSrlAoXbV2sX0pvjeNoItotH1I e8Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=KwfN2RVDc2BgHtDPhkbKAp7Eq08Hj5iv3wlylCAsvB8=; b=AjLgP9Sx7ED2u8ryYvMQzV4OvAA8I9tGtF+aJNsIO8PY2YJr2zsyBrvwwM02keLm/N niYEeeOtWwrpLQrIk8Z028mIKL+WCZWNBrVP+ZMOfksrFlRZsMLPw/4gqR1dwfLgXlzX +suZLgYLKvUGcZ8jXdSL6flZOL5yQujmOv7xkETm/7YJt6FROohXNp7jUqehfMon2C/w 5aHAjUZOsG4GmhSg9+c5rT7JAnanLyW/V5c4E7aG/UNEPjV6cI5F/e6Oa4Y28SWyBspN yfklQrFm3mZAtHASm6ipyHhvdvYSG1wBPhwZPy81mWkor0+dU229dMHmk5sZ7BNi6xBI K+Tg== X-Gm-Message-State: ALyK8tJfDt2r5Qkx9a7HtzmkKX4jvSJEXf5w6rtBfFmYHgGnRoj/d94Ne2Kb9bN5rp8DFMJHsp2mF1v+m0Wn0g== MIME-Version: 1.0 X-Received: by 10.107.11.26 with SMTP id v26mr4718349ioi.107.1466051292649; Wed, 15 Jun 2016 21:28:12 -0700 (PDT) Received: by 10.107.31.202 with HTTP; Wed, 15 Jun 2016 21:28:12 -0700 (PDT) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5646D5@NKGEML515-MBX.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5646D5@NKGEML515-MBX.china.huawei.com> Date: Wed, 15 Jun 2016 21:28:12 -0700 Message-ID: From: Tom Herbert To: Xuxiaohu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "IPsec@ietf.org" , NVO3 , Lou Berger , Liyizhou , Linda Dunbar Subject: Re: [IPsec] [nvo3] FW: Any use cases of Overlay network requesting IPSec connection from the Underlay for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 04:28:16 -0000 On Wed, Jun 15, 2016 at 8:03 PM, Xuxiaohu wrote: > Hi Lou, > > If IPsec tunnels are used within data centers, the security need is well = satisfied. However, the ECMP capability built on the UDP tunnels is lost at= all. So, how about encapsulating IPsec ESP over UDP tunnels for load-balan= cing improvement purpose? Note that this ESP-over-UDP encapsulation is diff= erent from the ESP-over-UDP encapsulation as described in RFC3948: the form= er uses the UDP tunnel for load-balancing improvement purpose and therefore= the source port is used as an entropy field, in contrast, the latter uses = the UDP tunnel for NAT traversal purpose and therefore the source port is s= et to a constant value (i.e.,4500). > > By the way, I had wrote a draft about this ESP-over-UDP approach (w/o sub= mission) three years ago when considering how to use UDP tunnels to transpo= rt MPLS and IP traffic. If there is enough interest on this ESP-over-UDP ap= proach, I can update it and then submit it for further discussion. > Using the flow label for ECMP (RFC6438) solves this problem without requiring the additional overhead of a UDP header. Tom > Best regards, > Xiaohu > >> -----Original Message----- >> From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lou Berger >> Sent: Wednesday, June 15, 2016 11:00 PM >> To: Linda Dunbar; Liyizhou; NVO3 >> Subject: Re: [nvo3] FW: Any use cases of Overlay network requesting IPSe= c >> connection from the Underlay for a specific time span? (was : Flow Secur= ity >> Policies exchanged over I2NSF service layer interface? >> >> >> Yes -- this is a real use case. >> >> This use case (overlays interconnected over IPsec tunnels with NVE end >> points) motivated our work on RFC5566 and we built supported for it (as = well as >> other tunnel technologies) in a quagga based NVO3 controller. >> This code is publicly available, but is not yet part of a standard quagg= a release. >> >> Lou >> >> On 6/15/2016 8:55 AM, Linda Dunbar wrote: >> > >> > NVO3 Participants, >> > >> > >> > >> > I2NSF (Interface to Network Security function) has a work item in >> > defining the flow security policy between domains (which includes >> > inquiry of the capability from one domain to another and the actual >> > flow policy rules from one domain to another). >> > >> > Very often, the paths (or links) among nodes of a overlay network are >> > provided by other network operators (a.k.a. "underlay network"). The >> > flow policy rules are intended to filter out unwanted traffic from >> > underlay network so that various attack traffic won't saturated the >> > access links to the overlay nodes. >> > >> > >> > >> > One interesting scenario brought up is Overlay nodes may need to >> > request some traffic to be traversing IPsec channel. To achieve this >> > goal, it is necessary for Overlay Network controller to inquire if the >> > needed IPsec resource are even available before send the request (may >> > even involve AAA process between controllers of each corresponding >> > domain ). >> > >> > >> > >> > Want to have a survey if people see the use case of Overlay Network >> > needing portion of traffic to be through IPSec channel? >> > >> > IPSec is supposed to be between two end nodes. Here we assume that the >> > Overlay nodes don't have the resource or capability for IPsec, but >> > expect IPsec between flow's ingress and egress nodes (i.e. NVE). >> > >> > >> > >> > Any opinion is appreciated. >> > >> > Thanks, >> > >> > Linda >> > >> > >> > >> > *From:*Linda Dunbar >> > *Sent:* Tuesday, June 14, 2016 4:03 PM >> > *To:* 'christian.jacquenet@orange.com'; BOUCADAIR Mohamed IMT/OLN >> > *Cc:* I2NSF@ietf.org >> > *Subject:* Any use cases of Overlay network requesting IPSec >> > connection from the Underlay for a specific time span? (was : Flow >> > Security Policies exchanged over I2NSF service layer interface? >> > >> > >> > >> > Christian, >> > >> > >> > >> > Your feedback seems to suggest that Overlay network Controller may >> > send request to the underlay network controller requesting IPsec >> > connections among overlay nodes. Do I understand you correctly? >> > >> > >> > >> > Are there any use cases of overlay network needing IPSec among their >> > nodes only for a specific time span? i.e. Time based IPSec connection? >> > >> > >> > >> > Linda >> > >> > >> > >> > *From:*christian.jacquenet@orange.com >> > >> > [mailto:christian.jacquenet@orange.com] >> > *Sent:* Monday, June 13, 2016 11:23 AM >> > *To:* Linda Dunbar; BOUCADAIR Mohamed IMT/OLN >> > *Subject:* RE: Any feedback on the Protocol Independent Flow Security >> > Policies exchanged over I2NSF service layer interface? >> > >> > >> > >> > >> > >> > *[snip]* >> > >> > >> > >> > >> > >> > >> > >> > Very often, the paths (or links) among nodes of a overlay network are >> > provided by other network operators (a.k.a. "underlay network"). Very >> > much like traditional networks placing FW (Firewall) or IPS (Intrusion >> > Prevention System) on the wire to enforce the flow security rules, >> > I2NSF *_Protocol Independent Flow Security Policies_* can be used by >> > overlay networks to request certain flow based security rules to be >> > enforced by its underlay networks, to prevent the unwanted attacks >> > traffic from occupying the physical links and ports to the overlay >> > network nodes, and to avoid the overlay nodes' CPU/Storage/Port >> > utilization being consumed down by the various attacks. Here is one >> > example of "Overlay Video Communication network" exchange Flow >> > Policies to the Underlay network. >> > >> > >> > >> > >> > >> > cid:image001.png@01D1B516.7F74E410 >> > >> > >> > >> > */[CJ] /*The above example clearly shows the necessary interaction >> > between the two PDPs/controllers, to make sure that decisions made by >> > the network controller accommodate the needs of the video customer as >> > possibly expressed towards the video controller: for example, customer >> > demands that the confidentiality of the videoconference needs to be >> > preserved, thereby suggesting the use of the IPsec protocol suite. The >> > video controller may enforce an IPsec design based upon the transport >> > mode, whereas the network controller is solicited to allocate IPsec >> > resources (read for example no AH, ESP in NULL mode) accordingly. This >> > may possibly raise conflicting configuration tasks (the video >> > controller uses AH, the network controller doesn't), thereby leading >> > to inconsistency that may jeopardize the service. Whether BGP FS is >> > used to carry security policy information between the two controllers >> > is hardly the point, imho: what matters is the consistency of the >> > (flow-based security policies enforced by both parties, and which >> > should be derived from the customer's requirements (if any). >> > >> > The goal of I2NSF is to specify the common information model and data >> > model for the *_ Protocol Independent Flow Security Policies _*which >> > can be queried and set between domains. >> > >> > [CJ] OK. >> > >> > * * >> > >> > https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-mit >> > igation-api/ is just the starting point. (needs more work to improve >> > the clarity). >> > We are asking if people to express their opinion on this work to the >> > I2NSF@ietf.org list. >> > >> > [CJ] I need to read this draft and will get back to you accordingly, >> > but this may take a couple of weeks as I'm pretty busy for the time be= ing. >> > >> > >> > >> > I'll let Med further comment as appropriate. >> > >> > >> > >> > Cheers, >> > >> > >> > >> > Christian. >> > >> > >> > >> > Thanks, Linda >> > >> > >> > >> > >> _____________________________________________________________ >> _________ >> > ___________________________________________________ >> > >> > Ce message et ses pieces jointes peuvent contenir des informations >> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> > exploites ou copies sans autorisation. Si vous avez recu ce message >> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi q= ue les pieces >> jointes. Les messages electroniques etant susceptibles d'alteration, Ora= nge >> decline toute responsabilite si ce message a ete altere, deforme ou fals= ifie. Merci. >> > >> > This message and its attachments may contain confidential or >> > privileged information that may be protected by law; they should not b= e >> distributed, used or copied without authorisation. >> > If you have received this email in error, please notify the sender and= delete this >> message and its attachments. >> > As emails may be altered, Orange is not liable for messages that have = been >> modified, changed or falsified. >> > Thank you. >> > >> > >> > _______________________________________________ >> > nvo3 mailing list >> > nvo3@ietf.org >> > https://www.ietf.org/mailman/listinfo/nvo3 >> >> >> _______________________________________________ >> nvo3 mailing list >> nvo3@ietf.org >> https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 From nobody Wed Jun 15 23:31:38 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD76312B04F; Wed, 15 Jun 2016 23:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9cRwC0NgkGt; Wed, 15 Jun 2016 23:31:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 125FD12D1B1; Wed, 15 Jun 2016 23:31:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMA83520; Thu, 16 Jun 2016 06:31:30 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 16 Jun 2016 07:31:27 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 16 Jun 2016 14:31:13 +0800 From: Xuxiaohu To: Tom Herbert Thread-Topic: [nvo3] FW: Any use cases of Overlay network requesting IPSec connection from the Underlay for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface? Thread-Index: AQHRxwVNSPtAs0OdV0+nna1mGK2X4J/qGOaAgAFIoAD//5lPAIAAplwA Date: Thu, 16 Jun 2016 06:31:13 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D564756@NKGEML515-MBX.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5646D5@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.576247C2.011B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 11a1488b897e55878f2c39cf59e87dc5 Archived-At: Cc: "IPsec@ietf.org" , NVO3 , Lou Berger , Liyizhou , Linda Dunbar Subject: Re: [IPsec] [nvo3] FW: Any use cases of Overlay network requesting IPSec connection from the Underlay for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 06:31:37 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVG9tIEhlcmJlcnQgW21h aWx0bzp0b21AaGVyYmVydGxhbmQuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAxNiwgMjAx NiAxMjoyOCBQTQ0KPiBUbzogWHV4aWFvaHUNCj4gQ2M6IExvdSBCZXJnZXI7IExpbmRhIER1bmJh cjsgTGl5aXpob3U7IE5WTzM7IElQc2VjQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbnZvM10g Rlc6IEFueSB1c2UgY2FzZXMgb2YgT3ZlcmxheSBuZXR3b3JrIHJlcXVlc3RpbmcgSVBTZWMNCj4g Y29ubmVjdGlvbiBmcm9tIHRoZSBVbmRlcmxheSBmb3IgYSBzcGVjaWZpYyB0aW1lIHNwYW4/ICh3 YXMgOiBGbG93IFNlY3VyaXR5DQo+IFBvbGljaWVzIGV4Y2hhbmdlZCBvdmVyIEkyTlNGIHNlcnZp Y2UgbGF5ZXIgaW50ZXJmYWNlPw0KPiANCj4gT24gV2VkLCBKdW4gMTUsIDIwMTYgYXQgODowMyBQ TSwgWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+IEhpIExvdSwNCj4g Pg0KPiA+IElmIElQc2VjIHR1bm5lbHMgYXJlIHVzZWQgd2l0aGluIGRhdGEgY2VudGVycywgdGhl IHNlY3VyaXR5IG5lZWQgaXMgd2VsbCBzYXRpc2ZpZWQuDQo+IEhvd2V2ZXIsIHRoZSBFQ01QIGNh cGFiaWxpdHkgYnVpbHQgb24gdGhlIFVEUCB0dW5uZWxzIGlzIGxvc3QgYXQgYWxsLiBTbywgaG93 DQo+IGFib3V0IGVuY2Fwc3VsYXRpbmcgSVBzZWMgRVNQIG92ZXIgVURQIHR1bm5lbHMgZm9yIGxv YWQtYmFsYW5jaW5nDQo+IGltcHJvdmVtZW50IHB1cnBvc2U/IE5vdGUgdGhhdCB0aGlzIEVTUC1v dmVyLVVEUCBlbmNhcHN1bGF0aW9uIGlzIGRpZmZlcmVudA0KPiBmcm9tIHRoZSBFU1Atb3Zlci1V RFAgZW5jYXBzdWxhdGlvbiBhcyBkZXNjcmliZWQgaW4gUkZDMzk0ODogdGhlIGZvcm1lciB1c2Vz DQo+IHRoZSBVRFAgdHVubmVsIGZvciBsb2FkLWJhbGFuY2luZyBpbXByb3ZlbWVudCBwdXJwb3Nl IGFuZCB0aGVyZWZvcmUgdGhlDQo+IHNvdXJjZSBwb3J0IGlzIHVzZWQgYXMgYW4gZW50cm9weSBm aWVsZCwgaW4gY29udHJhc3QsIHRoZSBsYXR0ZXIgdXNlcyB0aGUgVURQDQo+IHR1bm5lbCBmb3Ig TkFUIHRyYXZlcnNhbCBwdXJwb3NlIGFuZCB0aGVyZWZvcmUgdGhlIHNvdXJjZSBwb3J0IGlzIHNl dCB0byBhDQo+IGNvbnN0YW50IHZhbHVlIChpLmUuLDQ1MDApLg0KPiA+DQo+ID4gQnkgdGhlIHdh eSwgSSBoYWQgd3JvdGUgYSBkcmFmdCBhYm91dCB0aGlzIEVTUC1vdmVyLVVEUCBhcHByb2FjaCAo dy9vDQo+IHN1Ym1pc3Npb24pIHRocmVlIHllYXJzIGFnbyB3aGVuIGNvbnNpZGVyaW5nIGhvdyB0 byB1c2UgVURQIHR1bm5lbHMgdG8NCj4gdHJhbnNwb3J0IE1QTFMgYW5kIElQIHRyYWZmaWMuIElm IHRoZXJlIGlzIGVub3VnaCBpbnRlcmVzdCBvbiB0aGlzIEVTUC1vdmVyLVVEUA0KPiBhcHByb2Fj aCwgSSBjYW4gdXBkYXRlIGl0IGFuZCB0aGVuIHN1Ym1pdCBpdCBmb3IgZnVydGhlciBkaXNjdXNz aW9uLg0KPiA+DQo+IFVzaW5nIHRoZSBmbG93IGxhYmVsIGZvciBFQ01QIChSRkM2NDM4KSBzb2x2 ZXMgdGhpcyBwcm9ibGVtIHdpdGhvdXQgcmVxdWlyaW5nDQo+IHRoZSBhZGRpdGlvbmFsIG92ZXJo ZWFkIG9mIGEgVURQIGhlYWRlci4NCg0KSW4gSVB2NiB1bmRlcmxheSBuZXR3b3JrcywgdGhlIGFi b3ZlIGFyZ3VtZW50IHNlZW1zIHRydWUuIEhvd2V2ZXIsIGluIElQdjQgdW5kZXJsYXkgbmV0d29y a3MsIHRoZXJlIGlzIG5vIHN1Y2ggRkwgZmllbGQuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K DQo+IFRvbQ0KPiANCj4gPiBCZXN0IHJlZ2FyZHMsDQo+ID4gWGlhb2h1DQo+ID4NCj4gPj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogbnZvMyBbbWFpbHRvOm52bzMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvdSBCZXJnZXINCj4gPj4gU2VudDogV2VkbmVz ZGF5LCBKdW5lIDE1LCAyMDE2IDExOjAwIFBNDQo+ID4+IFRvOiBMaW5kYSBEdW5iYXI7IExpeWl6 aG91OyBOVk8zDQo+ID4+IFN1YmplY3Q6IFJlOiBbbnZvM10gRlc6IEFueSB1c2UgY2FzZXMgb2Yg T3ZlcmxheSBuZXR3b3JrIHJlcXVlc3RpbmcNCj4gPj4gSVBTZWMgY29ubmVjdGlvbiBmcm9tIHRo ZSBVbmRlcmxheSBmb3IgYSBzcGVjaWZpYyB0aW1lIHNwYW4/ICh3YXMgOg0KPiA+PiBGbG93IFNl Y3VyaXR5IFBvbGljaWVzIGV4Y2hhbmdlZCBvdmVyIEkyTlNGIHNlcnZpY2UgbGF5ZXIgaW50ZXJm YWNlPw0KPiA+Pg0KPiA+Pg0KPiA+PiBZZXMgLS0gdGhpcyBpcyBhIHJlYWwgdXNlIGNhc2UuDQo+ ID4+DQo+ID4+IFRoaXMgdXNlIGNhc2UgKG92ZXJsYXlzIGludGVyY29ubmVjdGVkIG92ZXIgSVBz ZWMgdHVubmVscyB3aXRoIE5WRQ0KPiA+PiBlbmQNCj4gPj4gcG9pbnRzKSBtb3RpdmF0ZWQgb3Vy IHdvcmsgb24gUkZDNTU2NiBhbmQgd2UgYnVpbHQgc3VwcG9ydGVkIGZvciBpdA0KPiA+PiAoYXMg d2VsbCBhcyBvdGhlciB0dW5uZWwgdGVjaG5vbG9naWVzKSBpbiBhIHF1YWdnYSBiYXNlZCBOVk8z IGNvbnRyb2xsZXIuDQo+ID4+IFRoaXMgY29kZSBpcyBwdWJsaWNseSBhdmFpbGFibGUsIGJ1dCBp cyBub3QgeWV0IHBhcnQgb2YgYSBzdGFuZGFyZCBxdWFnZ2ENCj4gcmVsZWFzZS4NCj4gPj4NCj4g Pj4gTG91DQo+ID4+DQo+ID4+IE9uIDYvMTUvMjAxNiA4OjU1IEFNLCBMaW5kYSBEdW5iYXIgd3Jv dGU6DQo+ID4+ID4NCj4gPj4gPiBOVk8zIFBhcnRpY2lwYW50cywNCj4gPj4gPg0KPiA+PiA+DQo+ ID4+ID4NCj4gPj4gPiBJMk5TRiAoSW50ZXJmYWNlIHRvIE5ldHdvcmsgU2VjdXJpdHkgZnVuY3Rp b24pIGhhcyBhIHdvcmsgaXRlbSBpbg0KPiA+PiA+IGRlZmluaW5nIHRoZSBmbG93IHNlY3VyaXR5 IHBvbGljeSBiZXR3ZWVuIGRvbWFpbnMgKHdoaWNoIGluY2x1ZGVzDQo+ID4+ID4gaW5xdWlyeSBv ZiB0aGUgY2FwYWJpbGl0eSBmcm9tIG9uZSBkb21haW4gdG8gYW5vdGhlciBhbmQgdGhlIGFjdHVh bA0KPiA+PiA+IGZsb3cgcG9saWN5IHJ1bGVzIGZyb20gb25lIGRvbWFpbiB0byBhbm90aGVyKS4N Cj4gPj4gPg0KPiA+PiA+IFZlcnkgb2Z0ZW4sIHRoZSBwYXRocyAob3IgbGlua3MpIGFtb25nIG5v ZGVzIG9mIGEgb3ZlcmxheSBuZXR3b3JrDQo+ID4+ID4gYXJlIHByb3ZpZGVkIGJ5IG90aGVyIG5l dHdvcmsgb3BlcmF0b3JzIChhLmsuYS4gInVuZGVybGF5DQo+ID4+ID4gbmV0d29yayIpLiAgVGhl IGZsb3cgcG9saWN5IHJ1bGVzIGFyZSBpbnRlbmRlZCB0byBmaWx0ZXIgb3V0DQo+ID4+ID4gdW53 YW50ZWQgdHJhZmZpYyBmcm9tIHVuZGVybGF5IG5ldHdvcmsgc28gdGhhdCB2YXJpb3VzIGF0dGFj aw0KPiA+PiA+IHRyYWZmaWMgd29uJ3Qgc2F0dXJhdGVkIHRoZSBhY2Nlc3MgbGlua3MgdG8gdGhl IG92ZXJsYXkgbm9kZXMuDQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4gT25lIGludGVy ZXN0aW5nIHNjZW5hcmlvIGJyb3VnaHQgdXAgaXMgT3ZlcmxheSBub2RlcyBtYXkgbmVlZCB0bw0K PiA+PiA+IHJlcXVlc3Qgc29tZSB0cmFmZmljIHRvIGJlIHRyYXZlcnNpbmcgSVBzZWMgY2hhbm5l bC4gVG8gYWNoaWV2ZQ0KPiA+PiA+IHRoaXMgZ29hbCwgaXQgaXMgbmVjZXNzYXJ5IGZvciBPdmVy bGF5IE5ldHdvcmsgY29udHJvbGxlciB0bw0KPiA+PiA+IGlucXVpcmUgaWYgdGhlIG5lZWRlZCBJ UHNlYyByZXNvdXJjZSBhcmUgZXZlbiBhdmFpbGFibGUgYmVmb3JlIHNlbmQNCj4gPj4gPiB0aGUg cmVxdWVzdCAobWF5IGV2ZW4gaW52b2x2ZSBBQUEgcHJvY2VzcyBiZXR3ZWVuIGNvbnRyb2xsZXJz IG9mDQo+ID4+ID4gZWFjaCBjb3JyZXNwb25kaW5nIGRvbWFpbiApLg0KPiA+PiA+DQo+ID4+ID4N Cj4gPj4gPg0KPiA+PiA+IFdhbnQgdG8gaGF2ZSBhIHN1cnZleSBpZiBwZW9wbGUgc2VlIHRoZSB1 c2UgY2FzZSBvZiBPdmVybGF5IE5ldHdvcmsNCj4gPj4gPiBuZWVkaW5nIHBvcnRpb24gb2YgdHJh ZmZpYyB0byBiZSB0aHJvdWdoIElQU2VjIGNoYW5uZWw/DQo+ID4+ID4NCj4gPj4gPiBJUFNlYyBp cyBzdXBwb3NlZCB0byBiZSBiZXR3ZWVuIHR3byBlbmQgbm9kZXMuIEhlcmUgd2UgYXNzdW1lIHRo YXQNCj4gPj4gPiB0aGUgT3ZlcmxheSBub2RlcyBkb24ndCBoYXZlIHRoZSByZXNvdXJjZSBvciBj YXBhYmlsaXR5IGZvciBJUHNlYywNCj4gPj4gPiBidXQgZXhwZWN0IElQc2VjIGJldHdlZW4gZmxv dydzIGluZ3Jlc3MgYW5kIGVncmVzcyBub2RlcyAoaS5lLiBOVkUpLg0KPiA+PiA+DQo+ID4+ID4N Cj4gPj4gPg0KPiA+PiA+IEFueSBvcGluaW9uIGlzIGFwcHJlY2lhdGVkLg0KPiA+PiA+DQo+ID4+ ID4gVGhhbmtzLA0KPiA+PiA+DQo+ID4+ID4gTGluZGENCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4N Cj4gPj4gPiAqRnJvbToqTGluZGEgRHVuYmFyDQo+ID4+ID4gKlNlbnQ6KiBUdWVzZGF5LCBKdW5l IDE0LCAyMDE2IDQ6MDMgUE0NCj4gPj4gPiAqVG86KiAnY2hyaXN0aWFuLmphY3F1ZW5ldEBvcmFu Z2UuY29tJzsgQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KPiA+PiA+ICpDYzoqIEkyTlNGQGll dGYub3JnDQo+ID4+ID4gKlN1YmplY3Q6KiBBbnkgdXNlIGNhc2VzIG9mIE92ZXJsYXkgbmV0d29y ayByZXF1ZXN0aW5nIElQU2VjDQo+ID4+ID4gY29ubmVjdGlvbiBmcm9tIHRoZSBVbmRlcmxheSBm b3IgYSBzcGVjaWZpYyB0aW1lIHNwYW4/ICh3YXMgOiBGbG93DQo+ID4+ID4gU2VjdXJpdHkgUG9s aWNpZXMgZXhjaGFuZ2VkIG92ZXIgSTJOU0Ygc2VydmljZSBsYXllciBpbnRlcmZhY2U/DQo+ID4+ ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4gQ2hyaXN0aWFuLA0KPiA+PiA+DQo+ID4+ID4NCj4g Pj4gPg0KPiA+PiA+IFlvdXIgZmVlZGJhY2sgc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IE92ZXJsYXkg bmV0d29yayBDb250cm9sbGVyIG1heQ0KPiA+PiA+IHNlbmQgcmVxdWVzdCB0byB0aGUgdW5kZXJs YXkgbmV0d29yayBjb250cm9sbGVyIHJlcXVlc3RpbmcgSVBzZWMNCj4gPj4gPiBjb25uZWN0aW9u cyBhbW9uZyBvdmVybGF5IG5vZGVzLiBEbyBJIHVuZGVyc3RhbmQgeW91IGNvcnJlY3RseT8NCj4g Pj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBBcmUgdGhlcmUgYW55IHVzZSBjYXNlcyBvZiBv dmVybGF5IG5ldHdvcmsgbmVlZGluZyBJUFNlYyBhbW9uZw0KPiA+PiA+IHRoZWlyIG5vZGVzIG9u bHkgZm9yIGEgc3BlY2lmaWMgdGltZSBzcGFuPyBpLmUuIFRpbWUgYmFzZWQgSVBTZWMgY29ubmVj dGlvbj8NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBMaW5kYQ0KPiA+PiA+DQo+ID4+ ID4NCj4gPj4gPg0KPiA+PiA+ICpGcm9tOipjaHJpc3RpYW4uamFjcXVlbmV0QG9yYW5nZS5jb20N Cj4gPj4gPiA8bWFpbHRvOmNocmlzdGlhbi5qYWNxdWVuZXRAb3JhbmdlLmNvbT4NCj4gPj4gPiBb bWFpbHRvOmNocmlzdGlhbi5qYWNxdWVuZXRAb3JhbmdlLmNvbV0NCj4gPj4gPiAqU2VudDoqIE1v bmRheSwgSnVuZSAxMywgMjAxNiAxMToyMyBBTQ0KPiA+PiA+ICpUbzoqIExpbmRhIER1bmJhcjsg Qk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTg0KPiA+PiA+ICpTdWJqZWN0OiogUkU6IEFueSBmZWVk YmFjayBvbiB0aGUgUHJvdG9jb2wgSW5kZXBlbmRlbnQgRmxvdw0KPiA+PiA+IFNlY3VyaXR5IFBv bGljaWVzIGV4Y2hhbmdlZCBvdmVyIEkyTlNGIHNlcnZpY2UgbGF5ZXIgaW50ZXJmYWNlPw0KPiA+ PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiAqW3NuaXBdKg0KPiA+ PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ ID4gVmVyeSBvZnRlbiwgdGhlIHBhdGhzIChvciBsaW5rcykgYW1vbmcgbm9kZXMgb2YgYSBvdmVy bGF5IG5ldHdvcmsNCj4gPj4gPiBhcmUgcHJvdmlkZWQgYnkgb3RoZXIgbmV0d29yayBvcGVyYXRv cnMgKGEuay5hLiAidW5kZXJsYXkNCj4gPj4gPiBuZXR3b3JrIikuICBWZXJ5IG11Y2ggbGlrZSB0 cmFkaXRpb25hbCBuZXR3b3JrcyBwbGFjaW5nIEZXDQo+ID4+ID4gKEZpcmV3YWxsKSBvciBJUFMg KEludHJ1c2lvbiBQcmV2ZW50aW9uIFN5c3RlbSkgb24gdGhlIHdpcmUgdG8NCj4gPj4gPiBlbmZv cmNlIHRoZSBmbG93IHNlY3VyaXR5IHJ1bGVzLCBJMk5TRiAqX1Byb3RvY29sIEluZGVwZW5kZW50 IEZsb3cNCj4gPj4gPiBTZWN1cml0eSBQb2xpY2llc18qIGNhbiBiZSB1c2VkIGJ5IG92ZXJsYXkg bmV0d29ya3MgdG8gcmVxdWVzdA0KPiA+PiA+IGNlcnRhaW4gZmxvdyBiYXNlZCBzZWN1cml0eSBy dWxlcyB0byBiZSBlbmZvcmNlZCBieSBpdHMgdW5kZXJsYXkNCj4gPj4gPiBuZXR3b3JrcywgdG8g cHJldmVudCB0aGUgdW53YW50ZWQgYXR0YWNrcyB0cmFmZmljIGZyb20gb2NjdXB5aW5nDQo+ID4+ ID4gdGhlIHBoeXNpY2FsIGxpbmtzIGFuZCBwb3J0cyB0byB0aGUgb3ZlcmxheSBuZXR3b3JrIG5v ZGVzLCBhbmQgdG8NCj4gPj4gPiBhdm9pZCB0aGUgb3ZlcmxheSBub2RlcycgQ1BVL1N0b3JhZ2Uv UG9ydCB1dGlsaXphdGlvbiBiZWluZw0KPiA+PiA+IGNvbnN1bWVkIGRvd24gYnkgdGhlIHZhcmlv dXMgYXR0YWNrcy4gIEhlcmUgaXMgb25lIGV4YW1wbGUgb2YNCj4gPj4gPiAiT3ZlcmxheSBWaWRl byBDb21tdW5pY2F0aW9uIG5ldHdvcmsiIGV4Y2hhbmdlIEZsb3cgUG9saWNpZXMgdG8gdGhlDQo+ IFVuZGVybGF5IG5ldHdvcmsuDQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4g Pg0KPiA+PiA+IGNpZDppbWFnZTAwMS5wbmdAMDFEMUI1MTYuN0Y3NEU0MTANCj4gPj4gPg0KPiA+ PiA+DQo+ID4+ID4NCj4gPj4gPiAqL1tDSl0gLypUaGUgYWJvdmUgZXhhbXBsZSBjbGVhcmx5IHNo b3dzIHRoZSBuZWNlc3NhcnkgaW50ZXJhY3Rpb24NCj4gPj4gPiBiZXR3ZWVuIHRoZSB0d28gUERQ cy9jb250cm9sbGVycywgdG8gbWFrZSBzdXJlIHRoYXQgZGVjaXNpb25zIG1hZGUNCj4gPj4gPiBi eSB0aGUgbmV0d29yayBjb250cm9sbGVyIGFjY29tbW9kYXRlIHRoZSBuZWVkcyBvZiB0aGUgdmlk ZW8NCj4gPj4gPiBjdXN0b21lciBhcyBwb3NzaWJseSBleHByZXNzZWQgdG93YXJkcyB0aGUgdmlk ZW8gY29udHJvbGxlcjogZm9yDQo+ID4+ID4gZXhhbXBsZSwgY3VzdG9tZXIgZGVtYW5kcyB0aGF0 IHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlDQo+ID4+ID4gdmlkZW9jb25mZXJlbmNlIG5lZWRz IHRvIGJlIHByZXNlcnZlZCwgdGhlcmVieSBzdWdnZXN0aW5nIHRoZSB1c2UNCj4gPj4gPiBvZiB0 aGUgSVBzZWMgcHJvdG9jb2wgc3VpdGUuIFRoZSB2aWRlbyBjb250cm9sbGVyIG1heSBlbmZvcmNl IGFuDQo+ID4+ID4gSVBzZWMgZGVzaWduIGJhc2VkIHVwb24gdGhlIHRyYW5zcG9ydCBtb2RlLCB3 aGVyZWFzIHRoZSBuZXR3b3JrDQo+ID4+ID4gY29udHJvbGxlciBpcyBzb2xpY2l0ZWQgdG8gYWxs b2NhdGUgSVBzZWMgcmVzb3VyY2VzIChyZWFkIGZvcg0KPiA+PiA+IGV4YW1wbGUgbm8gQUgsIEVT UCBpbiBOVUxMIG1vZGUpIGFjY29yZGluZ2x5LiBUaGlzIG1heSBwb3NzaWJseQ0KPiA+PiA+IHJh aXNlIGNvbmZsaWN0aW5nIGNvbmZpZ3VyYXRpb24gdGFza3MgKHRoZSB2aWRlbyBjb250cm9sbGVy IHVzZXMNCj4gPj4gPiBBSCwgdGhlIG5ldHdvcmsgY29udHJvbGxlciBkb2Vzbid0KSwgdGhlcmVi eSBsZWFkaW5nIHRvDQo+ID4+ID4gaW5jb25zaXN0ZW5jeSB0aGF0IG1heSBqZW9wYXJkaXplIHRo ZSBzZXJ2aWNlLiBXaGV0aGVyIEJHUCBGUyBpcw0KPiA+PiA+IHVzZWQgdG8gY2Fycnkgc2VjdXJp dHkgcG9saWN5IGluZm9ybWF0aW9uIGJldHdlZW4gdGhlIHR3bw0KPiA+PiA+IGNvbnRyb2xsZXJz IGlzIGhhcmRseSB0aGUgcG9pbnQsIGltaG86IHdoYXQgbWF0dGVycyBpcyB0aGUNCj4gPj4gPiBj b25zaXN0ZW5jeSBvZiB0aGUgKGZsb3ctYmFzZWQgc2VjdXJpdHkgcG9saWNpZXMgZW5mb3JjZWQg YnkgYm90aCBwYXJ0aWVzLA0KPiBhbmQgd2hpY2ggc2hvdWxkIGJlIGRlcml2ZWQgZnJvbSB0aGUg Y3VzdG9tZXIncyByZXF1aXJlbWVudHMgKGlmIGFueSkuDQo+ID4+ID4NCj4gPj4gPiBUaGUgZ29h bCBvZiBJMk5TRiBpcyB0byBzcGVjaWZ5IHRoZSBjb21tb24gaW5mb3JtYXRpb24gbW9kZWwgYW5k DQo+ID4+ID4gZGF0YSBtb2RlbCBmb3IgdGhlICpfIFByb3RvY29sIEluZGVwZW5kZW50IEZsb3cg U2VjdXJpdHkgUG9saWNpZXMNCj4gPj4gPiBfKndoaWNoIGNhbiBiZSBxdWVyaWVkIGFuZCBzZXQg YmV0d2VlbiBkb21haW5zLg0KPiA+PiA+DQo+ID4+ID4gW0NKXSBPSy4NCj4gPj4gPg0KPiA+PiA+ ICogKg0KPiA+PiA+DQo+ID4+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZmFuZy1pMm5zZi1pbnRlci1jbG91ZC1kZG9zLQ0KPiA+PiA+IG1pdCBpZ2F0aW9uLWFwaS8g aXMganVzdCB0aGUgc3RhcnRpbmcgcG9pbnQuIChuZWVkcyBtb3JlIHdvcmsgdG8NCj4gPj4gPiBp bXByb3ZlIHRoZSBjbGFyaXR5KS4NCj4gPj4gPiBXZSBhcmUgYXNraW5nIGlmIHBlb3BsZSB0byBl eHByZXNzIHRoZWlyIG9waW5pb24gb24gdGhpcyB3b3JrIHRvDQo+ID4+ID4gdGhlIEkyTlNGQGll dGYub3JnIDxtYWlsdG86STJOU0ZAaWV0Zi5vcmc+IGxpc3QuDQo+ID4+ID4NCj4gPj4gPiBbQ0pd IEkgbmVlZCB0byByZWFkIHRoaXMgZHJhZnQgYW5kIHdpbGwgZ2V0IGJhY2sgdG8geW91DQo+ID4+ ID4gYWNjb3JkaW5nbHksIGJ1dCB0aGlzIG1heSB0YWtlIGEgY291cGxlIG9mIHdlZWtzIGFzIEkn bSBwcmV0dHkgYnVzeSBmb3IgdGhlDQo+IHRpbWUgYmVpbmcuDQo+ID4+ID4NCj4gPj4gPg0KPiA+ PiA+DQo+ID4+ID4gSSdsbCBsZXQgTWVkIGZ1cnRoZXIgY29tbWVudCBhcyBhcHByb3ByaWF0ZS4N Cj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBDaGVlcnMsDQo+ID4+ID4NCj4gPj4gPg0K PiA+PiA+DQo+ID4+ID4gQ2hyaXN0aWFuLg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+ IFRoYW5rcywgTGluZGENCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+Pg0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+IF9fX19fX19fXw0KPiA+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+DQo+ID4+ID4gQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+ID4+ID4g Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0 cmUNCj4gPj4gPiBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv bi4gU2kgdm91cyBhdmV6IHJlY3UNCj4gPj4gPiBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlDQo+ID4+ID4gZGV0cnVpcmUgYWlu c2kgcXVlIGxlcyBwaWVjZXMNCj4gPj4gam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gPj4gT3JhbmdlIGRlY2xpbmUg dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUg b3UNCj4gZmFsc2lmaWUuIE1lcmNpLg0KPiA+PiA+DQo+ID4+ID4gVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yDQo+ID4+ID4gcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3Vs ZA0KPiA+PiA+IG5vdCBiZQ0KPiA+PiBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLg0KPiA+PiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KPiA+PiA+IGFuZCBkZWxldGUgdGhp cw0KPiA+PiBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4+ID4gQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdA0KPiA+ PiA+IGhhdmUgYmVlbg0KPiA+PiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+ID4+ ID4gVGhhbmsgeW91Lg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+IG52bzMgbWFpbGluZyBsaXN0DQo+ ID4+ID4gbnZvM0BpZXRmLm9yZw0KPiA+PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbnZvMw0KPiA+Pg0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiBudm8zIG1haWxpbmcgbGlzdA0KPiA+PiBudm8z QGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZv Mw0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiBudm8zIG1haWxpbmcgbGlzdA0KPiA+IG52bzNAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCg== From nobody Thu Jun 16 01:15:57 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9D112B051; Thu, 16 Jun 2016 01:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj5w_ExMPaX9; Thu, 16 Jun 2016 01:15:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56C812B015; Thu, 16 Jun 2016 01:15:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMA99407; Thu, 16 Jun 2016 08:15:49 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 16 Jun 2016 09:15:31 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 16 Jun 2016 01:15:21 -0700 From: Linda Dunbar To: Tom Herbert , Xuxiaohu , "I2NSF@ietf.org" Thread-Topic: Can Overlay nodes see any difference on how ECMP is used by the underlay in building the IPSec tunnels for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface? Thread-Index: AQHRx6c5uy7vcdisa0CBTxelX/mQOw== Date: Thu, 16 Jun 2016 08:15:21 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657EB5167@dfweml501-mbb> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5646D5@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.134.143] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.57626036.000E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 32eae9bdebd0fc54f301714064792678 Archived-At: Cc: "IPsec@ietf.org" , Lou Berger , Liyizhou , NVO3 Subject: [IPsec] Can Overlay nodes see any difference on how ECMP is used by the underlay in building the IPSec tunnels for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 08:15:55 -0000 WGlhbyBIdSBhbmQgVG9tLCANCg0KRG8geW91IHRoaW5rIHRoYXQgT3ZlcmxheSBub2RlcyB3aWxs IHNlZSBhbnkgZGlmZmVyZW5jZSBvbiBIb3cgRUNNUCBpcyB1c2VkIGJ5IHRoZSB1bmRlcmxheSB0 byBidWlsZCB0aGUgSVBTZWMgdHVubmVsIGJldHdlZW4gSW5ncmVzcy9FZ3Jlc3Mgbm9kZXMgZm9y IHRoZSBvdmVybGF5IG5ldHdvcmsgbm9kZXM/IA0KDQpJZiB5ZXMsIGhvdyBjYW4gT3ZlcmxheSBj b250cm9sbGVyIHNwZWNpZnkgaXRzIHNwZWNpZmljIHJlcXVlc3RzIHRvIHRoZSB1bmRlcmxheT8g SXMgIm5lZWRpbmcgRUNNUCIgb3IgIkRvbid0IGNhcmUgRUNNUCIgYmUgZ29vZCBlbm91Z2g/IA0K DQpUaGFua3MsIExpbmRhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUb20g SGVyYmVydCBbbWFpbHRvOnRvbUBoZXJiZXJ0bGFuZC5jb21dIA0KU2VudDogV2VkbmVzZGF5LCBK dW5lIDE1LCAyMDE2IDExOjI4IFBNDQpUbzogWHV4aWFvaHUNCkNjOiBMb3UgQmVyZ2VyOyBMaW5k YSBEdW5iYXI7IExpeWl6aG91OyBOVk8zOyBJUHNlY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtu dm8zXSBGVzogQW55IHVzZSBjYXNlcyBvZiBPdmVybGF5IG5ldHdvcmsgcmVxdWVzdGluZyBJUFNl YyBjb25uZWN0aW9uIGZyb20gdGhlIFVuZGVybGF5IGZvciBhIHNwZWNpZmljIHRpbWUgc3Bhbj8g KHdhcyA6IEZsb3cgU2VjdXJpdHkgUG9saWNpZXMgZXhjaGFuZ2VkIG92ZXIgSTJOU0Ygc2Vydmlj ZSBsYXllciBpbnRlcmZhY2U/DQoNCk9uIFdlZCwgSnVuIDE1LCAyMDE2IGF0IDg6MDMgUE0sIFh1 eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPiB3cm90ZToNCj4gSGkgTG91LA0KPg0KPiBJZiBJ UHNlYyB0dW5uZWxzIGFyZSB1c2VkIHdpdGhpbiBkYXRhIGNlbnRlcnMsIHRoZSBzZWN1cml0eSBu ZWVkIGlzIHdlbGwgc2F0aXNmaWVkLiBIb3dldmVyLCB0aGUgRUNNUCBjYXBhYmlsaXR5IGJ1aWx0 IG9uIHRoZSBVRFAgdHVubmVscyBpcyBsb3N0IGF0IGFsbC4gU28sIGhvdyBhYm91dCBlbmNhcHN1 bGF0aW5nIElQc2VjIEVTUCBvdmVyIFVEUCB0dW5uZWxzIGZvciBsb2FkLWJhbGFuY2luZyBpbXBy b3ZlbWVudCBwdXJwb3NlPyBOb3RlIHRoYXQgdGhpcyBFU1Atb3Zlci1VRFAgZW5jYXBzdWxhdGlv biBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgRVNQLW92ZXItVURQIGVuY2Fwc3VsYXRpb24gYXMgZGVz Y3JpYmVkIGluIFJGQzM5NDg6IHRoZSBmb3JtZXIgdXNlcyB0aGUgVURQIHR1bm5lbCBmb3IgbG9h ZC1iYWxhbmNpbmcgaW1wcm92ZW1lbnQgcHVycG9zZSBhbmQgdGhlcmVmb3JlIHRoZSBzb3VyY2Ug cG9ydCBpcyB1c2VkIGFzIGFuIGVudHJvcHkgZmllbGQsIGluIGNvbnRyYXN0LCB0aGUgbGF0dGVy IHVzZXMgdGhlIFVEUCB0dW5uZWwgZm9yIE5BVCB0cmF2ZXJzYWwgcHVycG9zZSBhbmQgdGhlcmVm b3JlIHRoZSBzb3VyY2UgcG9ydCBpcyBzZXQgdG8gYSBjb25zdGFudCB2YWx1ZSAoaS5lLiw0NTAw KS4NCj4NCj4gQnkgdGhlIHdheSwgSSBoYWQgd3JvdGUgYSBkcmFmdCBhYm91dCB0aGlzIEVTUC1v dmVyLVVEUCBhcHByb2FjaCAody9vIHN1Ym1pc3Npb24pIHRocmVlIHllYXJzIGFnbyB3aGVuIGNv bnNpZGVyaW5nIGhvdyB0byB1c2UgVURQIHR1bm5lbHMgdG8gdHJhbnNwb3J0IE1QTFMgYW5kIElQ IHRyYWZmaWMuIElmIHRoZXJlIGlzIGVub3VnaCBpbnRlcmVzdCBvbiB0aGlzIEVTUC1vdmVyLVVE UCBhcHByb2FjaCwgSSBjYW4gdXBkYXRlIGl0IGFuZCB0aGVuIHN1Ym1pdCBpdCBmb3IgZnVydGhl ciBkaXNjdXNzaW9uLg0KPg0KVXNpbmcgdGhlIGZsb3cgbGFiZWwgZm9yIEVDTVAgKFJGQzY0Mzgp IHNvbHZlcyB0aGlzIHByb2JsZW0gd2l0aG91dCByZXF1aXJpbmcgdGhlIGFkZGl0aW9uYWwgb3Zl cmhlYWQgb2YgYSBVRFAgaGVhZGVyLg0KDQpUb20NCg0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9o dQ0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IG52bzMgW21haWx0 bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMb3UgQmVyZ2VyDQo+PiBTZW50 OiBXZWRuZXNkYXksIEp1bmUgMTUsIDIwMTYgMTE6MDAgUE0NCj4+IFRvOiBMaW5kYSBEdW5iYXI7 IExpeWl6aG91OyBOVk8zDQo+PiBTdWJqZWN0OiBSZTogW252bzNdIEZXOiBBbnkgdXNlIGNhc2Vz IG9mIE92ZXJsYXkgbmV0d29yayByZXF1ZXN0aW5nIA0KPj4gSVBTZWMgY29ubmVjdGlvbiBmcm9t IHRoZSBVbmRlcmxheSBmb3IgYSBzcGVjaWZpYyB0aW1lIHNwYW4/ICh3YXMgOiANCj4+IEZsb3cg U2VjdXJpdHkgUG9saWNpZXMgZXhjaGFuZ2VkIG92ZXIgSTJOU0Ygc2VydmljZSBsYXllciBpbnRl cmZhY2U/DQo+Pg0KPj4NCj4+IFllcyAtLSB0aGlzIGlzIGEgcmVhbCB1c2UgY2FzZS4NCj4+DQo+ PiBUaGlzIHVzZSBjYXNlIChvdmVybGF5cyBpbnRlcmNvbm5lY3RlZCBvdmVyIElQc2VjIHR1bm5l bHMgd2l0aCBOVkUgDQo+PiBlbmQNCj4+IHBvaW50cykgbW90aXZhdGVkIG91ciB3b3JrIG9uIFJG QzU1NjYgYW5kIHdlIGJ1aWx0IHN1cHBvcnRlZCBmb3IgaXQgDQo+PiAoYXMgd2VsbCBhcyBvdGhl ciB0dW5uZWwgdGVjaG5vbG9naWVzKSBpbiBhIHF1YWdnYSBiYXNlZCBOVk8zIGNvbnRyb2xsZXIu DQo+PiBUaGlzIGNvZGUgaXMgcHVibGljbHkgYXZhaWxhYmxlLCBidXQgaXMgbm90IHlldCBwYXJ0 IG9mIGEgc3RhbmRhcmQgcXVhZ2dhIHJlbGVhc2UuDQo+Pg0KPj4gTG91DQo+Pg0KPj4gT24gNi8x NS8yMDE2IDg6NTUgQU0sIExpbmRhIER1bmJhciB3cm90ZToNCj4+ID4NCj4+ID4gTlZPMyBQYXJ0 aWNpcGFudHMsDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IEkyTlNGIChJbnRlcmZhY2UgdG8gTmV0 d29yayBTZWN1cml0eSBmdW5jdGlvbikgaGFzIGEgd29yayBpdGVtIGluIA0KPj4gPiBkZWZpbmlu ZyB0aGUgZmxvdyBzZWN1cml0eSBwb2xpY3kgYmV0d2VlbiBkb21haW5zICh3aGljaCBpbmNsdWRl cyANCj4+ID4gaW5xdWlyeSBvZiB0aGUgY2FwYWJpbGl0eSBmcm9tIG9uZSBkb21haW4gdG8gYW5v dGhlciBhbmQgdGhlIGFjdHVhbCANCj4+ID4gZmxvdyBwb2xpY3kgcnVsZXMgZnJvbSBvbmUgZG9t YWluIHRvIGFub3RoZXIpLg0KPj4gPg0KPj4gPiBWZXJ5IG9mdGVuLCB0aGUgcGF0aHMgKG9yIGxp bmtzKSBhbW9uZyBub2RlcyBvZiBhIG92ZXJsYXkgbmV0d29yayANCj4+ID4gYXJlIHByb3ZpZGVk IGJ5IG90aGVyIG5ldHdvcmsgb3BlcmF0b3JzIChhLmsuYS4gInVuZGVybGF5IA0KPj4gPiBuZXR3 b3JrIikuICBUaGUgZmxvdyBwb2xpY3kgcnVsZXMgYXJlIGludGVuZGVkIHRvIGZpbHRlciBvdXQg DQo+PiA+IHVud2FudGVkIHRyYWZmaWMgZnJvbSB1bmRlcmxheSBuZXR3b3JrIHNvIHRoYXQgdmFy aW91cyBhdHRhY2sgDQo+PiA+IHRyYWZmaWMgd29uJ3Qgc2F0dXJhdGVkIHRoZSBhY2Nlc3MgbGlu a3MgdG8gdGhlIG92ZXJsYXkgbm9kZXMuDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IE9uZSBpbnRl cmVzdGluZyBzY2VuYXJpbyBicm91Z2h0IHVwIGlzIE92ZXJsYXkgbm9kZXMgbWF5IG5lZWQgdG8g DQo+PiA+IHJlcXVlc3Qgc29tZSB0cmFmZmljIHRvIGJlIHRyYXZlcnNpbmcgSVBzZWMgY2hhbm5l bC4gVG8gYWNoaWV2ZSANCj4+ID4gdGhpcyBnb2FsLCBpdCBpcyBuZWNlc3NhcnkgZm9yIE92ZXJs YXkgTmV0d29yayBjb250cm9sbGVyIHRvIA0KPj4gPiBpbnF1aXJlIGlmIHRoZSBuZWVkZWQgSVBz ZWMgcmVzb3VyY2UgYXJlIGV2ZW4gYXZhaWxhYmxlIGJlZm9yZSBzZW5kIA0KPj4gPiB0aGUgcmVx dWVzdCAobWF5IGV2ZW4gaW52b2x2ZSBBQUEgcHJvY2VzcyBiZXR3ZWVuIGNvbnRyb2xsZXJzIG9m IA0KPj4gPiBlYWNoIGNvcnJlc3BvbmRpbmcgZG9tYWluICkuDQo+PiA+DQo+PiA+DQo+PiA+DQo+ PiA+IFdhbnQgdG8gaGF2ZSBhIHN1cnZleSBpZiBwZW9wbGUgc2VlIHRoZSB1c2UgY2FzZSBvZiBP dmVybGF5IE5ldHdvcmsgDQo+PiA+IG5lZWRpbmcgcG9ydGlvbiBvZiB0cmFmZmljIHRvIGJlIHRo cm91Z2ggSVBTZWMgY2hhbm5lbD8NCj4+ID4NCj4+ID4gSVBTZWMgaXMgc3VwcG9zZWQgdG8gYmUg YmV0d2VlbiB0d28gZW5kIG5vZGVzLiBIZXJlIHdlIGFzc3VtZSB0aGF0IA0KPj4gPiB0aGUgT3Zl cmxheSBub2RlcyBkb24ndCBoYXZlIHRoZSByZXNvdXJjZSBvciBjYXBhYmlsaXR5IGZvciBJUHNl YywgDQo+PiA+IGJ1dCBleHBlY3QgSVBzZWMgYmV0d2VlbiBmbG93J3MgaW5ncmVzcyBhbmQgZWdy ZXNzIG5vZGVzIChpLmUuIE5WRSkuDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IEFueSBvcGluaW9u IGlzIGFwcHJlY2lhdGVkLg0KPj4gPg0KPj4gPiBUaGFua3MsDQo+PiA+DQo+PiA+IExpbmRhDQo+ PiA+DQo+PiA+DQo+PiA+DQo+PiA+ICpGcm9tOipMaW5kYSBEdW5iYXINCj4+ID4gKlNlbnQ6KiBU dWVzZGF5LCBKdW5lIDE0LCAyMDE2IDQ6MDMgUE0NCj4+ID4gKlRvOiogJ2NocmlzdGlhbi5qYWNx dWVuZXRAb3JhbmdlLmNvbSc7IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCj4+ID4gKkNjOiog STJOU0ZAaWV0Zi5vcmcNCj4+ID4gKlN1YmplY3Q6KiBBbnkgdXNlIGNhc2VzIG9mIE92ZXJsYXkg bmV0d29yayByZXF1ZXN0aW5nIElQU2VjIA0KPj4gPiBjb25uZWN0aW9uIGZyb20gdGhlIFVuZGVy bGF5IGZvciBhIHNwZWNpZmljIHRpbWUgc3Bhbj8gKHdhcyA6IEZsb3cgDQo+PiA+IFNlY3VyaXR5 IFBvbGljaWVzIGV4Y2hhbmdlZCBvdmVyIEkyTlNGIHNlcnZpY2UgbGF5ZXIgaW50ZXJmYWNlPw0K Pj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBDaHJpc3RpYW4sDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+ IFlvdXIgZmVlZGJhY2sgc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IE92ZXJsYXkgbmV0d29yayBDb250 cm9sbGVyIG1heSANCj4+ID4gc2VuZCByZXF1ZXN0IHRvIHRoZSB1bmRlcmxheSBuZXR3b3JrIGNv bnRyb2xsZXIgcmVxdWVzdGluZyBJUHNlYyANCj4+ID4gY29ubmVjdGlvbnMgYW1vbmcgb3Zlcmxh eSBub2Rlcy4gRG8gSSB1bmRlcnN0YW5kIHlvdSBjb3JyZWN0bHk/DQo+PiA+DQo+PiA+DQo+PiA+ DQo+PiA+IEFyZSB0aGVyZSBhbnkgdXNlIGNhc2VzIG9mIG92ZXJsYXkgbmV0d29yayBuZWVkaW5n IElQU2VjIGFtb25nIA0KPj4gPiB0aGVpciBub2RlcyBvbmx5IGZvciBhIHNwZWNpZmljIHRpbWUg c3Bhbj8gaS5lLiBUaW1lIGJhc2VkIElQU2VjIGNvbm5lY3Rpb24/DQo+PiA+DQo+PiA+DQo+PiA+ DQo+PiA+IExpbmRhDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+ICpGcm9tOipjaHJpc3RpYW4uamFj cXVlbmV0QG9yYW5nZS5jb20NCj4+ID4gPG1haWx0bzpjaHJpc3RpYW4uamFjcXVlbmV0QG9yYW5n ZS5jb20+DQo+PiA+IFttYWlsdG86Y2hyaXN0aWFuLmphY3F1ZW5ldEBvcmFuZ2UuY29tXQ0KPj4g PiAqU2VudDoqIE1vbmRheSwgSnVuZSAxMywgMjAxNiAxMToyMyBBTQ0KPj4gPiAqVG86KiBMaW5k YSBEdW5iYXI7IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE4NCj4+ID4gKlN1YmplY3Q6KiBSRTog QW55IGZlZWRiYWNrIG9uIHRoZSBQcm90b2NvbCBJbmRlcGVuZGVudCBGbG93IA0KPj4gPiBTZWN1 cml0eSBQb2xpY2llcyBleGNoYW5nZWQgb3ZlciBJMk5TRiBzZXJ2aWNlIGxheWVyIGludGVyZmFj ZT8NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gKltzbmlwXSoNCj4+ID4NCj4+ ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4gVmVyeSBvZnRlbiwgdGhlIHBh dGhzIChvciBsaW5rcykgYW1vbmcgbm9kZXMgb2YgYSBvdmVybGF5IG5ldHdvcmsgDQo+PiA+IGFy ZSBwcm92aWRlZCBieSBvdGhlciBuZXR3b3JrIG9wZXJhdG9ycyAoYS5rLmEuICJ1bmRlcmxheSAN Cj4+ID4gbmV0d29yayIpLiAgVmVyeSBtdWNoIGxpa2UgdHJhZGl0aW9uYWwgbmV0d29ya3MgcGxh Y2luZyBGVyANCj4+ID4gKEZpcmV3YWxsKSBvciBJUFMgKEludHJ1c2lvbiBQcmV2ZW50aW9uIFN5 c3RlbSkgb24gdGhlIHdpcmUgdG8gDQo+PiA+IGVuZm9yY2UgdGhlIGZsb3cgc2VjdXJpdHkgcnVs ZXMsIEkyTlNGICpfUHJvdG9jb2wgSW5kZXBlbmRlbnQgRmxvdyANCj4+ID4gU2VjdXJpdHkgUG9s aWNpZXNfKiBjYW4gYmUgdXNlZCBieSBvdmVybGF5IG5ldHdvcmtzIHRvIHJlcXVlc3QgDQo+PiA+ IGNlcnRhaW4gZmxvdyBiYXNlZCBzZWN1cml0eSBydWxlcyB0byBiZSBlbmZvcmNlZCBieSBpdHMg dW5kZXJsYXkgDQo+PiA+IG5ldHdvcmtzLCB0byBwcmV2ZW50IHRoZSB1bndhbnRlZCBhdHRhY2tz IHRyYWZmaWMgZnJvbSBvY2N1cHlpbmcgDQo+PiA+IHRoZSBwaHlzaWNhbCBsaW5rcyBhbmQgcG9y dHMgdG8gdGhlIG92ZXJsYXkgbmV0d29yayBub2RlcywgYW5kIHRvIA0KPj4gPiBhdm9pZCB0aGUg b3ZlcmxheSBub2RlcycgQ1BVL1N0b3JhZ2UvUG9ydCB1dGlsaXphdGlvbiBiZWluZyANCj4+ID4g Y29uc3VtZWQgZG93biBieSB0aGUgdmFyaW91cyBhdHRhY2tzLiAgSGVyZSBpcyBvbmUgZXhhbXBs ZSBvZiANCj4+ID4gIk92ZXJsYXkgVmlkZW8gQ29tbXVuaWNhdGlvbiBuZXR3b3JrIiBleGNoYW5n ZSBGbG93IFBvbGljaWVzIHRvIHRoZSBVbmRlcmxheSBuZXR3b3JrLg0KPj4gPg0KPj4gPg0KPj4g Pg0KPj4gPg0KPj4gPg0KPj4gPiBjaWQ6aW1hZ2UwMDEucG5nQDAxRDFCNTE2LjdGNzRFNDEwDQo+ PiA+DQo+PiA+DQo+PiA+DQo+PiA+ICovW0NKXSAvKlRoZSBhYm92ZSBleGFtcGxlIGNsZWFybHkg c2hvd3MgdGhlIG5lY2Vzc2FyeSBpbnRlcmFjdGlvbiANCj4+ID4gYmV0d2VlbiB0aGUgdHdvIFBE UHMvY29udHJvbGxlcnMsIHRvIG1ha2Ugc3VyZSB0aGF0IGRlY2lzaW9ucyBtYWRlIA0KPj4gPiBi eSB0aGUgbmV0d29yayBjb250cm9sbGVyIGFjY29tbW9kYXRlIHRoZSBuZWVkcyBvZiB0aGUgdmlk ZW8gDQo+PiA+IGN1c3RvbWVyIGFzIHBvc3NpYmx5IGV4cHJlc3NlZCB0b3dhcmRzIHRoZSB2aWRl byBjb250cm9sbGVyOiBmb3IgDQo+PiA+IGV4YW1wbGUsIGN1c3RvbWVyIGRlbWFuZHMgdGhhdCB0 aGUgY29uZmlkZW50aWFsaXR5IG9mIHRoZSANCj4+ID4gdmlkZW9jb25mZXJlbmNlIG5lZWRzIHRv IGJlIHByZXNlcnZlZCwgdGhlcmVieSBzdWdnZXN0aW5nIHRoZSB1c2UgDQo+PiA+IG9mIHRoZSBJ UHNlYyBwcm90b2NvbCBzdWl0ZS4gVGhlIHZpZGVvIGNvbnRyb2xsZXIgbWF5IGVuZm9yY2UgYW4g DQo+PiA+IElQc2VjIGRlc2lnbiBiYXNlZCB1cG9uIHRoZSB0cmFuc3BvcnQgbW9kZSwgd2hlcmVh cyB0aGUgbmV0d29yayANCj4+ID4gY29udHJvbGxlciBpcyBzb2xpY2l0ZWQgdG8gYWxsb2NhdGUg SVBzZWMgcmVzb3VyY2VzIChyZWFkIGZvciANCj4+ID4gZXhhbXBsZSBubyBBSCwgRVNQIGluIE5V TEwgbW9kZSkgYWNjb3JkaW5nbHkuIFRoaXMgbWF5IHBvc3NpYmx5IA0KPj4gPiByYWlzZSBjb25m bGljdGluZyBjb25maWd1cmF0aW9uIHRhc2tzICh0aGUgdmlkZW8gY29udHJvbGxlciB1c2VzIA0K Pj4gPiBBSCwgdGhlIG5ldHdvcmsgY29udHJvbGxlciBkb2Vzbid0KSwgdGhlcmVieSBsZWFkaW5n IHRvIA0KPj4gPiBpbmNvbnNpc3RlbmN5IHRoYXQgbWF5IGplb3BhcmRpemUgdGhlIHNlcnZpY2Uu IFdoZXRoZXIgQkdQIEZTIGlzIA0KPj4gPiB1c2VkIHRvIGNhcnJ5IHNlY3VyaXR5IHBvbGljeSBp bmZvcm1hdGlvbiBiZXR3ZWVuIHRoZSB0d28gDQo+PiA+IGNvbnRyb2xsZXJzIGlzIGhhcmRseSB0 aGUgcG9pbnQsIGltaG86IHdoYXQgbWF0dGVycyBpcyB0aGUgDQo+PiA+IGNvbnNpc3RlbmN5IG9m IHRoZSAoZmxvdy1iYXNlZCBzZWN1cml0eSBwb2xpY2llcyBlbmZvcmNlZCBieSBib3RoIHBhcnRp ZXMsIGFuZCB3aGljaCBzaG91bGQgYmUgZGVyaXZlZCBmcm9tIHRoZSBjdXN0b21lcidzIHJlcXVp cmVtZW50cyAoaWYgYW55KS4NCj4+ID4NCj4+ID4gVGhlIGdvYWwgb2YgSTJOU0YgaXMgdG8gc3Bl Y2lmeSB0aGUgY29tbW9uIGluZm9ybWF0aW9uIG1vZGVsIGFuZCANCj4+ID4gZGF0YSBtb2RlbCBm b3IgdGhlICpfIFByb3RvY29sIEluZGVwZW5kZW50IEZsb3cgU2VjdXJpdHkgUG9saWNpZXMgDQo+ PiA+IF8qd2hpY2ggY2FuIGJlIHF1ZXJpZWQgYW5kIHNldCBiZXR3ZWVuIGRvbWFpbnMuDQo+PiA+ DQo+PiA+IFtDSl0gT0suDQo+PiA+DQo+PiA+ICogKg0KPj4gPg0KPj4gPiBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mYW5nLWkybnNmLWludGVyLWNsb3VkLWRkb3MtDQo+ PiA+IG1pdCBpZ2F0aW9uLWFwaS8gaXMganVzdCB0aGUgc3RhcnRpbmcgcG9pbnQuIChuZWVkcyBt b3JlIHdvcmsgdG8gDQo+PiA+IGltcHJvdmUgdGhlIGNsYXJpdHkpLg0KPj4gPiBXZSBhcmUgYXNr aW5nIGlmIHBlb3BsZSB0byBleHByZXNzIHRoZWlyIG9waW5pb24gb24gdGhpcyB3b3JrIHRvIA0K Pj4gPiB0aGUgSTJOU0ZAaWV0Zi5vcmcgPG1haWx0bzpJMk5TRkBpZXRmLm9yZz4gbGlzdC4NCj4+ ID4NCj4+ID4gW0NKXSBJIG5lZWQgdG8gcmVhZCB0aGlzIGRyYWZ0IGFuZCB3aWxsIGdldCBiYWNr IHRvIHlvdSANCj4+ID4gYWNjb3JkaW5nbHksIGJ1dCB0aGlzIG1heSB0YWtlIGEgY291cGxlIG9m IHdlZWtzIGFzIEknbSBwcmV0dHkgYnVzeSBmb3IgdGhlIHRpbWUgYmVpbmcuDQo+PiA+DQo+PiA+ DQo+PiA+DQo+PiA+IEknbGwgbGV0IE1lZCBmdXJ0aGVyIGNvbW1lbnQgYXMgYXBwcm9wcmlhdGUu DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+IENoZWVycywNCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID4g Q2hyaXN0aWFuLg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPiBUaGFua3MsIExpbmRhDQo+PiA+DQo+ PiA+DQo+PiA+DQo+PiA+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBfX19fX19fX18NCj4+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+DQo+PiA+IENlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyANCj4+ID4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50 IGRvbmMgcGFzIGV0cmUgDQo+PiA+IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSANCj4+ID4gY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSANCj4+ID4gZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMNCj4+IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIA0KPj4gT3JhbmdlIGRl Y2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRl Zm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPj4gPg0KPj4gPiBUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgDQo+PiA+IHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQg DQo+PiA+IG5vdCBiZQ0KPj4gZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4NCj4+ID4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIA0KPj4gPiBhbmQgZGVsZXRlIHRoaXMNCj4+IG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+ID4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCANCj4+ID4gaGF2ZSBiZWVu DQo+PiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+PiA+IFRoYW5rIHlvdS4NCj4+ ID4NCj4+ID4NCj4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+ID4gbnZvMyBtYWlsaW5nIGxpc3QNCj4+ID4gbnZvM0BpZXRmLm9yZw0KPj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCj4+DQo+Pg0KPj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG52bzMgbWFp bGluZyBsaXN0DQo+PiBudm8zQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL252bzMNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gbnZvMyBtYWlsaW5nIGxpc3QNCj4gbnZvM0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMNCg== From nobody Thu Jun 16 01:55:52 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC7612B042; Thu, 16 Jun 2016 01:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lpub5msF6jmb; Thu, 16 Jun 2016 01:55:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998F512B014; Thu, 16 Jun 2016 01:55:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQX21879; Thu, 16 Jun 2016 08:55:40 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 16 Jun 2016 09:54:47 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Thu, 16 Jun 2016 16:54:36 +0800 From: Xuxiaohu To: Linda Dunbar , Tom Herbert , "I2NSF@ietf.org" Thread-Topic: Can Overlay nodes see any difference on how ECMP is used by the underlay in building the IPSec tunnels for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface? Thread-Index: AQHRx6dF3l2HaItjV02ugKZ/+h5mbJ/rxyFg Date: Thu, 16 Jun 2016 08:54:35 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5647D4@NKGEML515-MBX.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5646D5@NKGEML515-MBX.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F657EB5167@dfweml501-mbb> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657EB5167@dfweml501-mbb> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5762698D.0152, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5dd51d35443bf41b558e6d36ed42ae71 Archived-At: Cc: "IPsec@ietf.org" , Lou Berger , Liyizhou , NVO3 Subject: Re: [IPsec] Can Overlay nodes see any difference on how ECMP is used by the underlay in building the IPSec tunnels for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 08:55:49 -0000 TGluZGEsDQoNClRvIG1heGltaXplIHRoZSBiYW5kd2lkdGggdXRpbGl6YXRpb24gd2l0aGluIGRh dGEgY2VudGVyIG5ldHdvcmtzLCBpdCdzIG11Y2ggZGVzaXJhYmxlIHRvIHRyYW5zcG9ydCB0cmFm ZmljIGJldHdlZW4gdHdvIE5WRS9QRSBub2RlcyBhY3Jvc3MgRUNNUHMgb2YgdGhlIHVuZGVybGF5 LiBJdCBoYXMgbm90aGluZyB0byBkbyB3aXRoIG92ZXJsYXkgbm9kZXMgYW5kIG92ZXJsYXkgY29u dHJvbGxlcnMuDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IExpbmRhIER1bmJhcg0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAx NiwgMjAxNiA0OjE1IFBNDQo+IFRvOiBUb20gSGVyYmVydDsgWHV4aWFvaHU7IEkyTlNGQGlldGYu b3JnDQo+IENjOiBMb3UgQmVyZ2VyOyBMaXlpemhvdTsgTlZPMzsgSVBzZWNAaWV0Zi5vcmcNCj4g U3ViamVjdDogQ2FuIE92ZXJsYXkgbm9kZXMgc2VlIGFueSBkaWZmZXJlbmNlIG9uIGhvdyBFQ01Q IGlzIHVzZWQgYnkgdGhlDQo+IHVuZGVybGF5IGluIGJ1aWxkaW5nIHRoZSBJUFNlYyB0dW5uZWxz IGZvciBhIHNwZWNpZmljIHRpbWUgc3Bhbj8gKHdhcyA6IEZsb3cNCj4gU2VjdXJpdHkgUG9saWNp ZXMgZXhjaGFuZ2VkIG92ZXIgSTJOU0Ygc2VydmljZSBsYXllciBpbnRlcmZhY2U/DQo+IA0KPiBY aWFvIEh1IGFuZCBUb20sDQo+IA0KPiBEbyB5b3UgdGhpbmsgdGhhdCBPdmVybGF5IG5vZGVzIHdp bGwgc2VlIGFueSBkaWZmZXJlbmNlIG9uIEhvdyBFQ01QIGlzIHVzZWQgYnkNCj4gdGhlIHVuZGVy bGF5IHRvIGJ1aWxkIHRoZSBJUFNlYyB0dW5uZWwgYmV0d2VlbiBJbmdyZXNzL0VncmVzcyBub2Rl cyBmb3IgdGhlDQo+IG92ZXJsYXkgbmV0d29yayBub2Rlcz8NCj4gDQo+IElmIHllcywgaG93IGNh biBPdmVybGF5IGNvbnRyb2xsZXIgc3BlY2lmeSBpdHMgc3BlY2lmaWMgcmVxdWVzdHMgdG8gdGhl IHVuZGVybGF5PyBJcw0KPiAibmVlZGluZyBFQ01QIiBvciAiRG9uJ3QgY2FyZSBFQ01QIiBiZSBn b29kIGVub3VnaD8NCj4gDQo+IFRoYW5rcywgTGluZGENCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IFRvbSBIZXJiZXJ0IFttYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNv bV0NCj4gU2VudDogV2VkbmVzZGF5LCBKdW5lIDE1LCAyMDE2IDExOjI4IFBNDQo+IFRvOiBYdXhp YW9odQ0KPiBDYzogTG91IEJlcmdlcjsgTGluZGEgRHVuYmFyOyBMaXlpemhvdTsgTlZPMzsgSVBz ZWNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtudm8zXSBGVzogQW55IHVzZSBjYXNlcyBvZiBP dmVybGF5IG5ldHdvcmsgcmVxdWVzdGluZyBJUFNlYw0KPiBjb25uZWN0aW9uIGZyb20gdGhlIFVu ZGVybGF5IGZvciBhIHNwZWNpZmljIHRpbWUgc3Bhbj8gKHdhcyA6IEZsb3cgU2VjdXJpdHkNCj4g UG9saWNpZXMgZXhjaGFuZ2VkIG92ZXIgSTJOU0Ygc2VydmljZSBsYXllciBpbnRlcmZhY2U/DQo+ IA0KPiBPbiBXZWQsIEp1biAxNSwgMjAxNiBhdCA4OjAzIFBNLCBYdXhpYW9odSA8eHV4aWFvaHVA aHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gSGkgTG91LA0KPiA+DQo+ID4gSWYgSVBzZWMgdHVubmVs cyBhcmUgdXNlZCB3aXRoaW4gZGF0YSBjZW50ZXJzLCB0aGUgc2VjdXJpdHkgbmVlZCBpcyB3ZWxs IHNhdGlzZmllZC4NCj4gSG93ZXZlciwgdGhlIEVDTVAgY2FwYWJpbGl0eSBidWlsdCBvbiB0aGUg VURQIHR1bm5lbHMgaXMgbG9zdCBhdCBhbGwuIFNvLCBob3cNCj4gYWJvdXQgZW5jYXBzdWxhdGlu ZyBJUHNlYyBFU1Agb3ZlciBVRFAgdHVubmVscyBmb3IgbG9hZC1iYWxhbmNpbmcNCj4gaW1wcm92 ZW1lbnQgcHVycG9zZT8gTm90ZSB0aGF0IHRoaXMgRVNQLW92ZXItVURQIGVuY2Fwc3VsYXRpb24g aXMgZGlmZmVyZW50DQo+IGZyb20gdGhlIEVTUC1vdmVyLVVEUCBlbmNhcHN1bGF0aW9uIGFzIGRl c2NyaWJlZCBpbiBSRkMzOTQ4OiB0aGUgZm9ybWVyIHVzZXMNCj4gdGhlIFVEUCB0dW5uZWwgZm9y IGxvYWQtYmFsYW5jaW5nIGltcHJvdmVtZW50IHB1cnBvc2UgYW5kIHRoZXJlZm9yZSB0aGUNCj4g c291cmNlIHBvcnQgaXMgdXNlZCBhcyBhbiBlbnRyb3B5IGZpZWxkLCBpbiBjb250cmFzdCwgdGhl IGxhdHRlciB1c2VzIHRoZSBVRFANCj4gdHVubmVsIGZvciBOQVQgdHJhdmVyc2FsIHB1cnBvc2Ug YW5kIHRoZXJlZm9yZSB0aGUgc291cmNlIHBvcnQgaXMgc2V0IHRvIGENCj4gY29uc3RhbnQgdmFs dWUgKGkuZS4sNDUwMCkuDQo+ID4NCj4gPiBCeSB0aGUgd2F5LCBJIGhhZCB3cm90ZSBhIGRyYWZ0 IGFib3V0IHRoaXMgRVNQLW92ZXItVURQIGFwcHJvYWNoICh3L28NCj4gc3VibWlzc2lvbikgdGhy ZWUgeWVhcnMgYWdvIHdoZW4gY29uc2lkZXJpbmcgaG93IHRvIHVzZSBVRFAgdHVubmVscyB0bw0K PiB0cmFuc3BvcnQgTVBMUyBhbmQgSVAgdHJhZmZpYy4gSWYgdGhlcmUgaXMgZW5vdWdoIGludGVy ZXN0IG9uIHRoaXMgRVNQLW92ZXItVURQDQo+IGFwcHJvYWNoLCBJIGNhbiB1cGRhdGUgaXQgYW5k IHRoZW4gc3VibWl0IGl0IGZvciBmdXJ0aGVyIGRpc2N1c3Npb24uDQo+ID4NCj4gVXNpbmcgdGhl IGZsb3cgbGFiZWwgZm9yIEVDTVAgKFJGQzY0MzgpIHNvbHZlcyB0aGlzIHByb2JsZW0gd2l0aG91 dCByZXF1aXJpbmcNCj4gdGhlIGFkZGl0aW9uYWwgb3ZlcmhlYWQgb2YgYSBVRFAgaGVhZGVyLg0K PiANCj4gVG9tDQo+IA0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBudm8zIFttYWlsdG86bnZvMy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTG91IEJlcmdlcg0KPiA+PiBTZW50OiBXZWRu ZXNkYXksIEp1bmUgMTUsIDIwMTYgMTE6MDAgUE0NCj4gPj4gVG86IExpbmRhIER1bmJhcjsgTGl5 aXpob3U7IE5WTzMNCj4gPj4gU3ViamVjdDogUmU6IFtudm8zXSBGVzogQW55IHVzZSBjYXNlcyBv ZiBPdmVybGF5IG5ldHdvcmsgcmVxdWVzdGluZw0KPiA+PiBJUFNlYyBjb25uZWN0aW9uIGZyb20g dGhlIFVuZGVybGF5IGZvciBhIHNwZWNpZmljIHRpbWUgc3Bhbj8gKHdhcyA6DQo+ID4+IEZsb3cg U2VjdXJpdHkgUG9saWNpZXMgZXhjaGFuZ2VkIG92ZXIgSTJOU0Ygc2VydmljZSBsYXllciBpbnRl cmZhY2U/DQo+ID4+DQo+ID4+DQo+ID4+IFllcyAtLSB0aGlzIGlzIGEgcmVhbCB1c2UgY2FzZS4N Cj4gPj4NCj4gPj4gVGhpcyB1c2UgY2FzZSAob3ZlcmxheXMgaW50ZXJjb25uZWN0ZWQgb3ZlciBJ UHNlYyB0dW5uZWxzIHdpdGggTlZFDQo+ID4+IGVuZA0KPiA+PiBwb2ludHMpIG1vdGl2YXRlZCBv dXIgd29yayBvbiBSRkM1NTY2IGFuZCB3ZSBidWlsdCBzdXBwb3J0ZWQgZm9yIGl0DQo+ID4+IChh cyB3ZWxsIGFzIG90aGVyIHR1bm5lbCB0ZWNobm9sb2dpZXMpIGluIGEgcXVhZ2dhIGJhc2VkIE5W TzMgY29udHJvbGxlci4NCj4gPj4gVGhpcyBjb2RlIGlzIHB1YmxpY2x5IGF2YWlsYWJsZSwgYnV0 IGlzIG5vdCB5ZXQgcGFydCBvZiBhIHN0YW5kYXJkIHF1YWdnYQ0KPiByZWxlYXNlLg0KPiA+Pg0K PiA+PiBMb3UNCj4gPj4NCj4gPj4gT24gNi8xNS8yMDE2IDg6NTUgQU0sIExpbmRhIER1bmJhciB3 cm90ZToNCj4gPj4gPg0KPiA+PiA+IE5WTzMgUGFydGljaXBhbnRzLA0KPiA+PiA+DQo+ID4+ID4N Cj4gPj4gPg0KPiA+PiA+IEkyTlNGIChJbnRlcmZhY2UgdG8gTmV0d29yayBTZWN1cml0eSBmdW5j dGlvbikgaGFzIGEgd29yayBpdGVtIGluDQo+ID4+ID4gZGVmaW5pbmcgdGhlIGZsb3cgc2VjdXJp dHkgcG9saWN5IGJldHdlZW4gZG9tYWlucyAod2hpY2ggaW5jbHVkZXMNCj4gPj4gPiBpbnF1aXJ5 IG9mIHRoZSBjYXBhYmlsaXR5IGZyb20gb25lIGRvbWFpbiB0byBhbm90aGVyIGFuZCB0aGUgYWN0 dWFsDQo+ID4+ID4gZmxvdyBwb2xpY3kgcnVsZXMgZnJvbSBvbmUgZG9tYWluIHRvIGFub3RoZXIp Lg0KPiA+PiA+DQo+ID4+ID4gVmVyeSBvZnRlbiwgdGhlIHBhdGhzIChvciBsaW5rcykgYW1vbmcg bm9kZXMgb2YgYSBvdmVybGF5IG5ldHdvcmsNCj4gPj4gPiBhcmUgcHJvdmlkZWQgYnkgb3RoZXIg bmV0d29yayBvcGVyYXRvcnMgKGEuay5hLiAidW5kZXJsYXkNCj4gPj4gPiBuZXR3b3JrIikuICBU aGUgZmxvdyBwb2xpY3kgcnVsZXMgYXJlIGludGVuZGVkIHRvIGZpbHRlciBvdXQNCj4gPj4gPiB1 bndhbnRlZCB0cmFmZmljIGZyb20gdW5kZXJsYXkgbmV0d29yayBzbyB0aGF0IHZhcmlvdXMgYXR0 YWNrDQo+ID4+ID4gdHJhZmZpYyB3b24ndCBzYXR1cmF0ZWQgdGhlIGFjY2VzcyBsaW5rcyB0byB0 aGUgb3ZlcmxheSBub2Rlcy4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBPbmUgaW50 ZXJlc3Rpbmcgc2NlbmFyaW8gYnJvdWdodCB1cCBpcyBPdmVybGF5IG5vZGVzIG1heSBuZWVkIHRv DQo+ID4+ID4gcmVxdWVzdCBzb21lIHRyYWZmaWMgdG8gYmUgdHJhdmVyc2luZyBJUHNlYyBjaGFu bmVsLiBUbyBhY2hpZXZlDQo+ID4+ID4gdGhpcyBnb2FsLCBpdCBpcyBuZWNlc3NhcnkgZm9yIE92 ZXJsYXkgTmV0d29yayBjb250cm9sbGVyIHRvDQo+ID4+ID4gaW5xdWlyZSBpZiB0aGUgbmVlZGVk IElQc2VjIHJlc291cmNlIGFyZSBldmVuIGF2YWlsYWJsZSBiZWZvcmUgc2VuZA0KPiA+PiA+IHRo ZSByZXF1ZXN0IChtYXkgZXZlbiBpbnZvbHZlIEFBQSBwcm9jZXNzIGJldHdlZW4gY29udHJvbGxl cnMgb2YNCj4gPj4gPiBlYWNoIGNvcnJlc3BvbmRpbmcgZG9tYWluICkuDQo+ID4+ID4NCj4gPj4g Pg0KPiA+PiA+DQo+ID4+ID4gV2FudCB0byBoYXZlIGEgc3VydmV5IGlmIHBlb3BsZSBzZWUgdGhl IHVzZSBjYXNlIG9mIE92ZXJsYXkgTmV0d29yaw0KPiA+PiA+IG5lZWRpbmcgcG9ydGlvbiBvZiB0 cmFmZmljIHRvIGJlIHRocm91Z2ggSVBTZWMgY2hhbm5lbD8NCj4gPj4gPg0KPiA+PiA+IElQU2Vj IGlzIHN1cHBvc2VkIHRvIGJlIGJldHdlZW4gdHdvIGVuZCBub2Rlcy4gSGVyZSB3ZSBhc3N1bWUg dGhhdA0KPiA+PiA+IHRoZSBPdmVybGF5IG5vZGVzIGRvbid0IGhhdmUgdGhlIHJlc291cmNlIG9y IGNhcGFiaWxpdHkgZm9yIElQc2VjLA0KPiA+PiA+IGJ1dCBleHBlY3QgSVBzZWMgYmV0d2VlbiBm bG93J3MgaW5ncmVzcyBhbmQgZWdyZXNzIG5vZGVzIChpLmUuIE5WRSkuDQo+ID4+ID4NCj4gPj4g Pg0KPiA+PiA+DQo+ID4+ID4gQW55IG9waW5pb24gaXMgYXBwcmVjaWF0ZWQuDQo+ID4+ID4NCj4g Pj4gPiBUaGFua3MsDQo+ID4+ID4NCj4gPj4gPiBMaW5kYQ0KPiA+PiA+DQo+ID4+ID4NCj4gPj4g Pg0KPiA+PiA+ICpGcm9tOipMaW5kYSBEdW5iYXINCj4gPj4gPiAqU2VudDoqIFR1ZXNkYXksIEp1 bmUgMTQsIDIwMTYgNDowMyBQTQ0KPiA+PiA+ICpUbzoqICdjaHJpc3RpYW4uamFjcXVlbmV0QG9y YW5nZS5jb20nOyBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQo+ID4+ID4gKkNjOiogSTJOU0ZA aWV0Zi5vcmcNCj4gPj4gPiAqU3ViamVjdDoqIEFueSB1c2UgY2FzZXMgb2YgT3ZlcmxheSBuZXR3 b3JrIHJlcXVlc3RpbmcgSVBTZWMNCj4gPj4gPiBjb25uZWN0aW9uIGZyb20gdGhlIFVuZGVybGF5 IGZvciBhIHNwZWNpZmljIHRpbWUgc3Bhbj8gKHdhcyA6IEZsb3cNCj4gPj4gPiBTZWN1cml0eSBQ b2xpY2llcyBleGNoYW5nZWQgb3ZlciBJMk5TRiBzZXJ2aWNlIGxheWVyIGludGVyZmFjZT8NCj4g Pj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBDaHJpc3RpYW4sDQo+ID4+ID4NCj4gPj4gPg0K PiA+PiA+DQo+ID4+ID4gWW91ciBmZWVkYmFjayBzZWVtcyB0byBzdWdnZXN0IHRoYXQgT3Zlcmxh eSBuZXR3b3JrIENvbnRyb2xsZXIgbWF5DQo+ID4+ID4gc2VuZCByZXF1ZXN0IHRvIHRoZSB1bmRl cmxheSBuZXR3b3JrIGNvbnRyb2xsZXIgcmVxdWVzdGluZyBJUHNlYw0KPiA+PiA+IGNvbm5lY3Rp b25zIGFtb25nIG92ZXJsYXkgbm9kZXMuIERvIEkgdW5kZXJzdGFuZCB5b3UgY29ycmVjdGx5Pw0K PiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IEFyZSB0aGVyZSBhbnkgdXNlIGNhc2VzIG9m IG92ZXJsYXkgbmV0d29yayBuZWVkaW5nIElQU2VjIGFtb25nDQo+ID4+ID4gdGhlaXIgbm9kZXMg b25seSBmb3IgYSBzcGVjaWZpYyB0aW1lIHNwYW4/IGkuZS4gVGltZSBiYXNlZCBJUFNlYyBjb25u ZWN0aW9uPw0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IExpbmRhDQo+ID4+ID4NCj4g Pj4gPg0KPiA+PiA+DQo+ID4+ID4gKkZyb206KmNocmlzdGlhbi5qYWNxdWVuZXRAb3JhbmdlLmNv bQ0KPiA+PiA+IDxtYWlsdG86Y2hyaXN0aWFuLmphY3F1ZW5ldEBvcmFuZ2UuY29tPg0KPiA+PiA+ IFttYWlsdG86Y2hyaXN0aWFuLmphY3F1ZW5ldEBvcmFuZ2UuY29tXQ0KPiA+PiA+ICpTZW50Oiog TW9uZGF5LCBKdW5lIDEzLCAyMDE2IDExOjIzIEFNDQo+ID4+ID4gKlRvOiogTGluZGEgRHVuYmFy OyBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQo+ID4+ID4gKlN1YmplY3Q6KiBSRTogQW55IGZl ZWRiYWNrIG9uIHRoZSBQcm90b2NvbCBJbmRlcGVuZGVudCBGbG93DQo+ID4+ID4gU2VjdXJpdHkg UG9saWNpZXMgZXhjaGFuZ2VkIG92ZXIgSTJOU0Ygc2VydmljZSBsYXllciBpbnRlcmZhY2U/DQo+ ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+ICpbc25pcF0qDQo+ ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4g Pj4gPiBWZXJ5IG9mdGVuLCB0aGUgcGF0aHMgKG9yIGxpbmtzKSBhbW9uZyBub2RlcyBvZiBhIG92 ZXJsYXkgbmV0d29yaw0KPiA+PiA+IGFyZSBwcm92aWRlZCBieSBvdGhlciBuZXR3b3JrIG9wZXJh dG9ycyAoYS5rLmEuICJ1bmRlcmxheQ0KPiA+PiA+IG5ldHdvcmsiKS4gIFZlcnkgbXVjaCBsaWtl IHRyYWRpdGlvbmFsIG5ldHdvcmtzIHBsYWNpbmcgRlcNCj4gPj4gPiAoRmlyZXdhbGwpIG9yIElQ UyAoSW50cnVzaW9uIFByZXZlbnRpb24gU3lzdGVtKSBvbiB0aGUgd2lyZSB0bw0KPiA+PiA+IGVu Zm9yY2UgdGhlIGZsb3cgc2VjdXJpdHkgcnVsZXMsIEkyTlNGICpfUHJvdG9jb2wgSW5kZXBlbmRl bnQgRmxvdw0KPiA+PiA+IFNlY3VyaXR5IFBvbGljaWVzXyogY2FuIGJlIHVzZWQgYnkgb3Zlcmxh eSBuZXR3b3JrcyB0byByZXF1ZXN0DQo+ID4+ID4gY2VydGFpbiBmbG93IGJhc2VkIHNlY3VyaXR5 IHJ1bGVzIHRvIGJlIGVuZm9yY2VkIGJ5IGl0cyB1bmRlcmxheQ0KPiA+PiA+IG5ldHdvcmtzLCB0 byBwcmV2ZW50IHRoZSB1bndhbnRlZCBhdHRhY2tzIHRyYWZmaWMgZnJvbSBvY2N1cHlpbmcNCj4g Pj4gPiB0aGUgcGh5c2ljYWwgbGlua3MgYW5kIHBvcnRzIHRvIHRoZSBvdmVybGF5IG5ldHdvcmsg bm9kZXMsIGFuZCB0bw0KPiA+PiA+IGF2b2lkIHRoZSBvdmVybGF5IG5vZGVzJyBDUFUvU3RvcmFn ZS9Qb3J0IHV0aWxpemF0aW9uIGJlaW5nDQo+ID4+ID4gY29uc3VtZWQgZG93biBieSB0aGUgdmFy aW91cyBhdHRhY2tzLiAgSGVyZSBpcyBvbmUgZXhhbXBsZSBvZg0KPiA+PiA+ICJPdmVybGF5IFZp ZGVvIENvbW11bmljYXRpb24gbmV0d29yayIgZXhjaGFuZ2UgRmxvdyBQb2xpY2llcyB0byB0aGUN Cj4gVW5kZXJsYXkgbmV0d29yay4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+ PiA+DQo+ID4+ID4gY2lkOmltYWdlMDAxLnBuZ0AwMUQxQjUxNi43Rjc0RTQxMA0KPiA+PiA+DQo+ ID4+ID4NCj4gPj4gPg0KPiA+PiA+ICovW0NKXSAvKlRoZSBhYm92ZSBleGFtcGxlIGNsZWFybHkg c2hvd3MgdGhlIG5lY2Vzc2FyeSBpbnRlcmFjdGlvbg0KPiA+PiA+IGJldHdlZW4gdGhlIHR3byBQ RFBzL2NvbnRyb2xsZXJzLCB0byBtYWtlIHN1cmUgdGhhdCBkZWNpc2lvbnMgbWFkZQ0KPiA+PiA+ IGJ5IHRoZSBuZXR3b3JrIGNvbnRyb2xsZXIgYWNjb21tb2RhdGUgdGhlIG5lZWRzIG9mIHRoZSB2 aWRlbw0KPiA+PiA+IGN1c3RvbWVyIGFzIHBvc3NpYmx5IGV4cHJlc3NlZCB0b3dhcmRzIHRoZSB2 aWRlbyBjb250cm9sbGVyOiBmb3INCj4gPj4gPiBleGFtcGxlLCBjdXN0b21lciBkZW1hbmRzIHRo YXQgdGhlIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUNCj4gPj4gPiB2aWRlb2NvbmZlcmVuY2UgbmVl ZHMgdG8gYmUgcHJlc2VydmVkLCB0aGVyZWJ5IHN1Z2dlc3RpbmcgdGhlIHVzZQ0KPiA+PiA+IG9m IHRoZSBJUHNlYyBwcm90b2NvbCBzdWl0ZS4gVGhlIHZpZGVvIGNvbnRyb2xsZXIgbWF5IGVuZm9y Y2UgYW4NCj4gPj4gPiBJUHNlYyBkZXNpZ24gYmFzZWQgdXBvbiB0aGUgdHJhbnNwb3J0IG1vZGUs IHdoZXJlYXMgdGhlIG5ldHdvcmsNCj4gPj4gPiBjb250cm9sbGVyIGlzIHNvbGljaXRlZCB0byBh bGxvY2F0ZSBJUHNlYyByZXNvdXJjZXMgKHJlYWQgZm9yDQo+ID4+ID4gZXhhbXBsZSBubyBBSCwg RVNQIGluIE5VTEwgbW9kZSkgYWNjb3JkaW5nbHkuIFRoaXMgbWF5IHBvc3NpYmx5DQo+ID4+ID4g cmFpc2UgY29uZmxpY3RpbmcgY29uZmlndXJhdGlvbiB0YXNrcyAodGhlIHZpZGVvIGNvbnRyb2xs ZXIgdXNlcw0KPiA+PiA+IEFILCB0aGUgbmV0d29yayBjb250cm9sbGVyIGRvZXNuJ3QpLCB0aGVy ZWJ5IGxlYWRpbmcgdG8NCj4gPj4gPiBpbmNvbnNpc3RlbmN5IHRoYXQgbWF5IGplb3BhcmRpemUg dGhlIHNlcnZpY2UuIFdoZXRoZXIgQkdQIEZTIGlzDQo+ID4+ID4gdXNlZCB0byBjYXJyeSBzZWN1 cml0eSBwb2xpY3kgaW5mb3JtYXRpb24gYmV0d2VlbiB0aGUgdHdvDQo+ID4+ID4gY29udHJvbGxl cnMgaXMgaGFyZGx5IHRoZSBwb2ludCwgaW1obzogd2hhdCBtYXR0ZXJzIGlzIHRoZQ0KPiA+PiA+ IGNvbnNpc3RlbmN5IG9mIHRoZSAoZmxvdy1iYXNlZCBzZWN1cml0eSBwb2xpY2llcyBlbmZvcmNl ZCBieSBib3RoIHBhcnRpZXMsDQo+IGFuZCB3aGljaCBzaG91bGQgYmUgZGVyaXZlZCBmcm9tIHRo ZSBjdXN0b21lcidzIHJlcXVpcmVtZW50cyAoaWYgYW55KS4NCj4gPj4gPg0KPiA+PiA+IFRoZSBn b2FsIG9mIEkyTlNGIGlzIHRvIHNwZWNpZnkgdGhlIGNvbW1vbiBpbmZvcm1hdGlvbiBtb2RlbCBh bmQNCj4gPj4gPiBkYXRhIG1vZGVsIGZvciB0aGUgKl8gUHJvdG9jb2wgSW5kZXBlbmRlbnQgRmxv dyBTZWN1cml0eSBQb2xpY2llcw0KPiA+PiA+IF8qd2hpY2ggY2FuIGJlIHF1ZXJpZWQgYW5kIHNl dCBiZXR3ZWVuIGRvbWFpbnMuDQo+ID4+ID4NCj4gPj4gPiBbQ0pdIE9LLg0KPiA+PiA+DQo+ID4+ ID4gKiAqDQo+ID4+ID4NCj4gPj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1mYW5nLWkybnNmLWludGVyLWNsb3VkLWRkb3MtDQo+ID4+ID4gbWl0IGlnYXRpb24tYXBp LyBpcyBqdXN0IHRoZSBzdGFydGluZyBwb2ludC4gKG5lZWRzIG1vcmUgd29yayB0bw0KPiA+PiA+ IGltcHJvdmUgdGhlIGNsYXJpdHkpLg0KPiA+PiA+IFdlIGFyZSBhc2tpbmcgaWYgcGVvcGxlIHRv IGV4cHJlc3MgdGhlaXIgb3BpbmlvbiBvbiB0aGlzIHdvcmsgdG8NCj4gPj4gPiB0aGUgSTJOU0ZA aWV0Zi5vcmcgPG1haWx0bzpJMk5TRkBpZXRmLm9yZz4gbGlzdC4NCj4gPj4gPg0KPiA+PiA+IFtD Sl0gSSBuZWVkIHRvIHJlYWQgdGhpcyBkcmFmdCBhbmQgd2lsbCBnZXQgYmFjayB0byB5b3UNCj4g Pj4gPiBhY2NvcmRpbmdseSwgYnV0IHRoaXMgbWF5IHRha2UgYSBjb3VwbGUgb2Ygd2Vla3MgYXMg SSdtIHByZXR0eSBidXN5IGZvciB0aGUNCj4gdGltZSBiZWluZy4NCj4gPj4gPg0KPiA+PiA+DQo+ ID4+ID4NCj4gPj4gPiBJJ2xsIGxldCBNZWQgZnVydGhlciBjb21tZW50IGFzIGFwcHJvcHJpYXRl Lg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IENoZWVycywNCj4gPj4gPg0KPiA+PiA+ DQo+ID4+ID4NCj4gPj4gPiBDaHJpc3RpYW4uDQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ ID4gVGhhbmtzLCBMaW5kYQ0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPj4gX19fX19fX19fDQo+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4NCj4gPj4gPiBDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gPj4g PiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMg ZXRyZQ0KPiA+PiA+IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdQ0KPiA+PiA+IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUNCj4gPj4gPiBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcw0KPiA+PiBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KPiA+PiBPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdQ0KPiBmYWxzaWZpZS4gTWVyY2kuDQo+ID4+ID4NCj4gPj4gPiBUaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4gPj4gPiBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkgc2hv dWxkDQo+ID4+ID4gbm90IGJlDQo+ID4+IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uDQo+ID4+ID4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+ID4+ID4gYW5kIGRlbGV0ZSB0 aGlzDQo+ID4+IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gPj4gPiBBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0DQo+ ID4+ID4gaGF2ZSBiZWVuDQo+ID4+IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4g Pj4gPiBUaGFuayB5b3UuDQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+ID4gbnZvMyBtYWlsaW5nIGxpc3QN Cj4gPj4gPiBudm8zQGlldGYub3JnDQo+ID4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9udm8zDQo+ID4+DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IG52bzMgbWFpbGluZyBsaXN0DQo+ID4+IG52 bzNAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u dm8zDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IG52bzMgbWFpbGluZyBsaXN0DQo+ID4gbnZvM0BpZXRmLm9yZw0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnZvMw0K From nobody Thu Jun 16 07:19:15 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EE412D773; Thu, 16 Jun 2016 07:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAEG7N7pPAwr; Thu, 16 Jun 2016 07:19:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834B912D74D; Thu, 16 Jun 2016 07:19:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQX72130; Thu, 16 Jun 2016 14:19:06 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 16 Jun 2016 15:19:02 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Thu, 16 Jun 2016 07:18:53 -0700 From: Lucy yong To: Xuxiaohu , Lou Berger , "Linda Dunbar" , Liyizhou , NVO3 Thread-Topic: [nvo3] FW: Any use cases of Overlay network requesting IPSec connection from the Underlay for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface? Thread-Index: AdHBttspF0pOVdD6ST+kJ/stBROvZgAAPeIQAAFZtWAAelRdMAB46/+QAABawNAAPN71wAAa2zQQABmpEIAAGUn2gAAIsN8A Date: Thu, 16 Jun 2016 14:18:53 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57299BE8@dfweml501-mbb> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5646D5@NKGEML515-MBX.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5646D5@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.132.101] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.5762B55B.01D4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 88aeb6b020015da33772ae53dcc4e213 Archived-At: Cc: "IPsec@ietf.org" Subject: Re: [IPsec] [nvo3] FW: Any use cases of Overlay network requesting IPSec connection from the Underlay for a specific time span? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 14:19:13 -0000 FYI. draft-hy-nov3-gue-4-secure-transport specifies ESP-over-UDP that provides t= he benefits mentioned below. Lucy -----Original Message----- From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Xuxiaohu Sent: Wednesday, June 15, 2016 10:04 PM To: Lou Berger; Linda Dunbar; Liyizhou; NVO3 Cc: IPsec@ietf.org Subject: Re: [nvo3] FW: Any use cases of Overlay network requesting IPSec c= onnection from the Underlay for a specific time span? (was : Flow Security = Policies exchanged over I2NSF service layer interface? Hi Lou, If IPsec tunnels are used within data centers, the security need is well sa= tisfied. However, the ECMP capability built on the UDP tunnels is lost at a= ll. So, how about encapsulating IPsec ESP over UDP tunnels for load-balanci= ng improvement purpose? Note that this ESP-over-UDP encapsulation is differ= ent from the ESP-over-UDP encapsulation as described in RFC3948: the former= uses the UDP tunnel for load-balancing improvement purpose and therefore t= he source port is used as an entropy field, in contrast, the latter uses th= e UDP tunnel for NAT traversal purpose and therefore the source port is set= to a constant value (i.e.,4500). By the way, I had wrote a draft about this ESP-over-UDP approach (w/o submi= ssion) three years ago when considering how to use UDP tunnels to transport= MPLS and IP traffic. If there is enough interest on this ESP-over-UDP appr= oach, I can update it and then submit it for further discussion.=20 Best regards, Xiaohu > -----Original Message----- > From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Wednesday, June 15, 2016 11:00 PM > To: Linda Dunbar; Liyizhou; NVO3 > Subject: Re: [nvo3] FW: Any use cases of Overlay network requesting=20 > IPSec connection from the Underlay for a specific time span? (was :=20 > Flow Security Policies exchanged over I2NSF service layer interface? >=20 >=20 > Yes -- this is a real use case. >=20 > This use case (overlays interconnected over IPsec tunnels with NVE end > points) motivated our work on RFC5566 and we built supported for it=20 > (as well as other tunnel technologies) in a quagga based NVO3 controller. > This code is publicly available, but is not yet part of a standard quagga= release. >=20 > Lou >=20 > On 6/15/2016 8:55 AM, Linda Dunbar wrote: > > > > NVO3 Participants, > > > > > > > > I2NSF (Interface to Network Security function) has a work item in=20 > > defining the flow security policy between domains (which includes=20 > > inquiry of the capability from one domain to another and the actual=20 > > flow policy rules from one domain to another). > > > > Very often, the paths (or links) among nodes of a overlay network=20 > > are provided by other network operators (a.k.a. "underlay network"). =20 > > The flow policy rules are intended to filter out unwanted traffic=20 > > from underlay network so that various attack traffic won't saturated=20 > > the access links to the overlay nodes. > > > > > > > > One interesting scenario brought up is Overlay nodes may need to=20 > > request some traffic to be traversing IPsec channel. To achieve this=20 > > goal, it is necessary for Overlay Network controller to inquire if=20 > > the needed IPsec resource are even available before send the request=20 > > (may even involve AAA process between controllers of each=20 > > corresponding domain ). > > > > > > > > Want to have a survey if people see the use case of Overlay Network=20 > > needing portion of traffic to be through IPSec channel? > > > > IPSec is supposed to be between two end nodes. Here we assume that=20 > > the Overlay nodes don't have the resource or capability for IPsec,=20 > > but expect IPsec between flow's ingress and egress nodes (i.e. NVE). > > > > > > > > Any opinion is appreciated. > > > > Thanks, > > > > Linda > > > > > > > > *From:*Linda Dunbar > > *Sent:* Tuesday, June 14, 2016 4:03 PM > > *To:* 'christian.jacquenet@orange.com'; BOUCADAIR Mohamed IMT/OLN > > *Cc:* I2NSF@ietf.org > > *Subject:* Any use cases of Overlay network requesting IPSec=20 > > connection from the Underlay for a specific time span? (was : Flow=20 > > Security Policies exchanged over I2NSF service layer interface? > > > > > > > > Christian, > > > > > > > > Your feedback seems to suggest that Overlay network Controller may=20 > > send request to the underlay network controller requesting IPsec=20 > > connections among overlay nodes. Do I understand you correctly? > > > > > > > > Are there any use cases of overlay network needing IPSec among their=20 > > nodes only for a specific time span? i.e. Time based IPSec connection? > > > > > > > > Linda > > > > > > > > *From:*christian.jacquenet@orange.com > > > > [mailto:christian.jacquenet@orange.com] > > *Sent:* Monday, June 13, 2016 11:23 AM > > *To:* Linda Dunbar; BOUCADAIR Mohamed IMT/OLN > > *Subject:* RE: Any feedback on the Protocol Independent Flow=20 > > Security Policies exchanged over I2NSF service layer interface? > > > > > > > > > > > > *[snip]* > > > > > > > > > > > > > > > > Very often, the paths (or links) among nodes of a overlay network=20 > > are provided by other network operators (a.k.a. "underlay network"). =20 > > Very much like traditional networks placing FW (Firewall) or IPS=20 > > (Intrusion Prevention System) on the wire to enforce the flow=20 > > security rules, I2NSF *_Protocol Independent Flow Security=20 > > Policies_* can be used by overlay networks to request certain flow=20 > > based security rules to be enforced by its underlay networks, to=20 > > prevent the unwanted attacks traffic from occupying the physical=20 > > links and ports to the overlay network nodes, and to avoid the=20 > > overlay nodes' CPU/Storage/Port utilization being consumed down by=20 > > the various attacks. Here is one example of "Overlay Video=20 > > Communication network" exchange Flow Policies to the Underlay network. > > > > > > > > > > > > cid:image001.png@01D1B516.7F74E410 > > > > > > > > */[CJ] /*The above example clearly shows the necessary interaction=20 > > between the two PDPs/controllers, to make sure that decisions made=20 > > by the network controller accommodate the needs of the video=20 > > customer as possibly expressed towards the video controller: for=20 > > example, customer demands that the confidentiality of the=20 > > videoconference needs to be preserved, thereby suggesting the use of=20 > > the IPsec protocol suite. The video controller may enforce an IPsec=20 > > design based upon the transport mode, whereas the network controller=20 > > is solicited to allocate IPsec resources (read for example no AH,=20 > > ESP in NULL mode) accordingly. This may possibly raise conflicting=20 > > configuration tasks (the video controller uses AH, the network=20 > > controller doesn't), thereby leading to inconsistency that may=20 > > jeopardize the service. Whether BGP FS is used to carry security=20 > > policy information between the two controllers is hardly the point,=20 > > imho: what matters is the consistency of the (flow-based security=20 > > policies enforced by both parties, and which should be derived from the= customer's requirements (if any). > > > > The goal of I2NSF is to specify the common information model and=20 > > data model for the *_ Protocol Independent Flow Security Policies=20 > > _*which can be queried and set between domains. > > > > [CJ] OK. > > > > * * > > > > https://datatracker.ietf.org/doc/draft-fang-i2nsf-inter-cloud-ddos-m > > it igation-api/ is just the starting point. (needs more work to=20 > > improve the clarity). > > We are asking if people to express their opinion on this work to the=20 > > I2NSF@ietf.org list. > > > > [CJ] I need to read this draft and will get back to you accordingly,=20 > > but this may take a couple of weeks as I'm pretty busy for the time bei= ng. > > > > > > > > I'll let Med further comment as appropriate. > > > > > > > > Cheers, > > > > > > > > Christian. > > > > > > > > Thanks, Linda > > > > > > > > > _____________________________________________________________ > _________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations=20 > > confidentielles ou privilegiees et ne doivent donc pas etre=20 > > diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 > > ce message par erreur, veuillez le signaler a l'expediteur et le=20 > > detruire ainsi que les pieces > jointes. Les messages electroniques etant susceptibles d'alteration,=20 > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or=20 > > privileged information that may be protected by law; they should not=20 > > be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender=20 > > and delete this > message and its attachments. > > As emails may be altered, Orange is not liable for messages that=20 > > have been > modified, changed or falsified. > > Thank you. > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > https://www.ietf.org/mailman/listinfo/nvo3 >=20 >=20 > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3 From nobody Fri Jun 17 06:41:59 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8598712D5D5 for ; Fri, 17 Jun 2016 06:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8nNM1w9b8VO for ; Fri, 17 Jun 2016 06:41:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42CBB12D5AB for ; Fri, 17 Jun 2016 06:41:55 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u5HDfmSW003269 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Jun 2016 16:41:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u5HDfmoI026704; Fri, 17 Jun 2016 16:41:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <22371.65052.171606.514648@fireball.acr.fi> Date: Fri, 17 Jun 2016 16:41:48 +0300 From: Tero Kivinen To: Daniel Migault In-Reply-To: References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> <38026197-8DCE-4F23-866D-83BB3777745F@gmail.com> <575F28DB.2070703@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 16 min Archived-At: Cc: IPsecME WG , Paul Wouters , Yoav Nir Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 13:41:57 -0000 Daniel Migault writes: > Regarding the negotiation of the use of the implicit IV three ways ha= ve been > proposed. Currently it seems that the consensus is more encline to de= fine > Transform IDs. However, it has been raised that Transform Attributes = might be > a better protocol design choice. My personal preference is for Transform IDs.=20 > I would like to understand if there are any guidance whether using at= tributes > is preferred to ID or vice versa and if there is any preference in us= ing=A0 > IMPLICIT IV Transform ID versus an IMPLICIT IV Transform Attribute. Both with Transform IDs and Transform Attributes you need to duplicate each cipher support things. The payload would be either: SA Payload | +-- Proposal #1 ( Proto ID =3D ESP(3), SPI size =3D 4, | | 7 transforms, SPI =3D 0x052357bb ) | | | +-- Transform ENCR ( Name =3D ENCR=5FAES=5FCBC ) | | +-- Attribute ( Key Length =3D 128 ) | | | +-- Transform ENCR ( Name =3D ENCR=5FAES=5FCBC ) | | +-- Attribute ( Key Length =3D 192 ) | | | +-- Transform ENCR ( Name =3D ENCR=5FAES=5FCBC ) | | +-- Attribute ( Key Length =3D 256 ) | | | +-- Transform INTEG ( Name =3D AUTH=5FHMAC=5FSHA1=5F96 ) | +-- Transform INTEG ( Name =3D AUTH=5FAES=5FXCBC=5F96 ) | +-- Transform ESN ( Name =3D ESNs ) | +-- Transform ESN ( Name =3D No ESNs ) | +-- Proposal #2 ( Proto ID =3D ESP(3), SPI size =3D 4, | 6 transforms, SPI =3D 0x35a1d6f2 ) | +-- Transform ENCR ( Name =3D AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length =3D 128 ) | +-- Transform ENCR ( Name =3D AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length =3D 256 ) | +-- Transform ENCR ( Name =3D AES-GCM with a 8 octet ICV Implicit = IV ) | +-- Attribute ( Key Length =3D 128 ) | +-- Transform ENCR ( Name =3D AES-GCM with a 8 octet ICV Implicit = IV ) | +-- Attribute ( Key Length =3D 256 ) | +-- Transform ESN ( Name =3D ESNs ) +-- Transform ESN ( Name =3D No ESNs ) Or: SA Payload | +-- Proposal #1 ( Proto ID =3D ESP(3), SPI size =3D 4, | | 7 transforms, SPI =3D 0x052357bb ) | | | +-- Transform ENCR ( Name =3D ENCR=5FAES=5FCBC ) | | +-- Attribute ( Key Length =3D 128 ) | | | +-- Transform ENCR ( Name =3D ENCR=5FAES=5FCBC ) | | +-- Attribute ( Key Length =3D 192 ) | | | +-- Transform ENCR ( Name =3D ENCR=5FAES=5FCBC ) | | +-- Attribute ( Key Length =3D 256 ) | | | +-- Transform INTEG ( Name =3D AUTH=5FHMAC=5FSHA1=5F96 ) | +-- Transform INTEG ( Name =3D AUTH=5FAES=5FXCBC=5F96 ) | +-- Transform ESN ( Name =3D ESNs ) | +-- Transform ESN ( Name =3D No ESNs ) | +-- Proposal #2 ( Proto ID =3D ESP(3), SPI size =3D 4, | 6 transforms, SPI =3D 0x35a1d6f2 ) | +-- Transform ENCR ( Name =3D AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length =3D 128 ) | +-- Transform ENCR ( Name =3D AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length =3D 256 ) | +-- Transform ENCR ( Name =3D AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length =3D 128 ) | +-- Attribute ( Implicit =3D Yes ) | +-- Transform ENCR ( Name =3D AES-GCM with a 8 octet ICV ) | +-- Attribute ( Key Length =3D 256 ) | +-- Attribute ( Implicit =3D Yes ) | +-- Transform ESN ( Name =3D ESNs ) +-- Transform ESN ( Name =3D No ESNs ) where missing Implicit would mean same as Implicit =3D No. The Transform ID version provides more compact encoding, and I think it is cleaner. If transform attribute version is used, that would provide easy way to expand this for every cipher we have, i.e. including ENCR=5FCAMELLIA=5FCCM, i.e. if we just say it is allowed for ENCR=5FCAMELLIA=5FCCM too, then it can use it. For the Transform ID opt= ion we need to allocate separate ID for ENCR=5FCAMELLIA=5FCCM=5FIIV to allo= w it using implicit IV.=20 Transform IDs are fairly cheap, and I think it is better that we explictly mention which ciphers can use this, and doing this by allocating separate number for them is clean way of indicating that. Otherwise we need table listing which attributes are allowed with which cipher... --=20 kivinen@iki.fi From nobody Fri Jun 17 11:02:13 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF3D12D781 for ; Fri, 17 Jun 2016 11:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPWLbwCSkx4L for ; Fri, 17 Jun 2016 11:02:09 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B904312D940 for ; Fri, 17 Jun 2016 11:02:08 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id a66so9643793wme.0 for ; Fri, 17 Jun 2016 11:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wxlVgPfklajW/TKKIYPqd+GotimTOHBGbsivxm5W3L8=; b=f+qzJQxdT/XylM6PbngzDsc0dhFBP2dU22JKbqaelT5B6n1susF/vvvMSWHGdR2zzK /QqS8ZtMulFs/EkzZtRgfBLNnIVuoW1OOMtFcIHvatKyI086Spo107P8CxceQQQUccHG ksmgylX4fLETxlXZuVt/y8EqVhRy6dAPfC3KHjYmY3gZKdSXWwHp/TOxH1BNX5CpqX5V kaNkxjQlTKFkyQVvg4O1Ybx4syJr2zXjCmaNqYdXi0wDozBSYm89x7Ysv+gZMpFIFNgE LqcnZ+qhmBf1FZKUu7m6KBw9/eEfJHFuDtLVYah72TGueNSolHNIkCAQtyF7sHPRe0hJ wYqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wxlVgPfklajW/TKKIYPqd+GotimTOHBGbsivxm5W3L8=; b=XOx7YIh9tHwaRiJppK+L6v4QuSpfwItGMOCtFpDrdg3nI99v2xXTqnJ13i3tsuZS3W 5fhxbdcuL70gXCFiyrp17uTkC5xyyjL5DGGIgtgoq56DpKUZxq6SNZEOruwhoefv0tai a1Yky/3k8PqR6DaA8LjXNq69YceAWxTOk38BFXxVWqIXu0PhcKH/qGwy7IcRi0KaY1j9 44eFGV/Gd/pHnKb1weZr+JioOQxft9nI9XDBxwjZdtVRgFoiL3RrVMY9F18JClgQI0TL 3o2bGvcdaWxIR4Q6F1htEedQNtDA13s+gbG4jrNF0DTbLBoYMQJgemoeCmemYO3FZJem Ct+A== X-Gm-Message-State: ALyK8tLm7ijkMnAqMH65Vftno9y2GCt0SM4U50r3Mg+wbxrgvdnr6Nm3369Nk9+HL1HkmaX2Y/haAPYDWtVU3A== X-Received: by 10.28.30.149 with SMTP id e143mr3461596wme.81.1466186527246; Fri, 17 Jun 2016 11:02:07 -0700 (PDT) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.194.34.99 with HTTP; Fri, 17 Jun 2016 11:02:06 -0700 (PDT) In-Reply-To: <22371.65052.171606.514648@fireball.acr.fi> References: <20160609161150.16843.73862.idtracker@ietfa.amsl.com> <2DD56D786E600F45AC6BDE7DA4E8A8C117F18574@eusaamb107.ericsson.se> <981BE535-7D87-4C6B-9581-5C82A74BEE69@gmail.com> <38026197-8DCE-4F23-866D-83BB3777745F@gmail.com> <575F28DB.2070703@gmail.com> <22371.65052.171606.514648@fireball.acr.fi> From: Daniel Migault Date: Fri, 17 Jun 2016 14:02:06 -0400 X-Google-Sender-Auth: MBHooBVfnQpLm0nN_hJSJ4W2tqQ Message-ID: To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a114b25fe218e6b05357d2776 Archived-At: Cc: IPsecME WG , Paul Wouters , Yoav Nir Subject: Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 18:02:11 -0000 --001a114b25fe218e6b05357d2776 Content-Type: text/plain; charset=UTF-8 Hi Tero, Thank you for the feed back, my understanding is that we have a a consensus that Transform ID is the preferred way. I will update the draft accordingly and post a new version next week. BR, Daniel On Fri, Jun 17, 2016 at 9:41 AM, Tero Kivinen wrote: > Daniel Migault writes: > > Regarding the negotiation of the use of the implicit IV three ways have > been > > proposed. Currently it seems that the consensus is more encline to define > > Transform IDs. However, it has been raised that Transform Attributes > might be > > a better protocol design choice. > > My personal preference is for Transform IDs. > > > I would like to understand if there are any guidance whether using > attributes > > is preferred to ID or vice versa and if there is any preference in using > > IMPLICIT IV Transform ID versus an IMPLICIT IV Transform Attribute. > > Both with Transform IDs and Transform Attributes you need to duplicate > each cipher support things. The payload would be either: > > SA Payload > | > +-- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, > | | 7 transforms, SPI = 0x052357bb ) > | | > | +-- Transform ENCR ( Name = ENCR_AES_CBC ) > | | +-- Attribute ( Key Length = 128 ) > | | > | +-- Transform ENCR ( Name = ENCR_AES_CBC ) > | | +-- Attribute ( Key Length = 192 ) > | | > | +-- Transform ENCR ( Name = ENCR_AES_CBC ) > | | +-- Attribute ( Key Length = 256 ) > | | > | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) > | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 ) > | +-- Transform ESN ( Name = ESNs ) > | +-- Transform ESN ( Name = No ESNs ) > | > +-- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, > | 6 transforms, SPI = 0x35a1d6f2 ) > | > +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) > | +-- Attribute ( Key Length = 128 ) > | > +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) > | +-- Attribute ( Key Length = 256 ) > | > +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV Implicit IV ) > | +-- Attribute ( Key Length = 128 ) > | > +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV Implicit IV ) > | +-- Attribute ( Key Length = 256 ) > | > +-- Transform ESN ( Name = ESNs ) > +-- Transform ESN ( Name = No ESNs ) > > Or: > > SA Payload > | > +-- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, > | | 7 transforms, SPI = 0x052357bb ) > | | > | +-- Transform ENCR ( Name = ENCR_AES_CBC ) > | | +-- Attribute ( Key Length = 128 ) > | | > | +-- Transform ENCR ( Name = ENCR_AES_CBC ) > | | +-- Attribute ( Key Length = 192 ) > | | > | +-- Transform ENCR ( Name = ENCR_AES_CBC ) > | | +-- Attribute ( Key Length = 256 ) > | | > | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) > | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 ) > | +-- Transform ESN ( Name = ESNs ) > | +-- Transform ESN ( Name = No ESNs ) > | > +-- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, > | 6 transforms, SPI = 0x35a1d6f2 ) > | > +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) > | +-- Attribute ( Key Length = 128 ) > | > +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) > | +-- Attribute ( Key Length = 256 ) > | > +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) > | +-- Attribute ( Key Length = 128 ) > | +-- Attribute ( Implicit = Yes ) > | > +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) > | +-- Attribute ( Key Length = 256 ) > | +-- Attribute ( Implicit = Yes ) > | > +-- Transform ESN ( Name = ESNs ) > +-- Transform ESN ( Name = No ESNs ) > > where missing Implicit would mean same as Implicit = No. > > The Transform ID version provides more compact encoding, and I think > it is cleaner. > > If transform attribute version is used, that would provide easy way to > expand this for every cipher we have, i.e. including > ENCR_CAMELLIA_CCM, i.e. if we just say it is allowed for > ENCR_CAMELLIA_CCM too, then it can use it. For the Transform ID option > we need to allocate separate ID for ENCR_CAMELLIA_CCM_IIV to allow it > using implicit IV. > > Transform IDs are fairly cheap, and I think it is better that we > explictly mention which ciphers can use this, and doing this by > allocating separate number for them is clean way of indicating that. > Otherwise we need table listing which attributes are allowed with > which cipher... > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --001a114b25fe218e6b05357d2776 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tero,

Thank you for the fe= ed back, my understanding is that we have a a consensus that Transform ID i= s the preferred way. I will update the draft accordingly and post a new ver= sion next week.

BR,
Daniel

On Fri, Jun 17, 2016 at 9:41 AM,= Tero Kivinen <kivinen@iki.fi> wrote:
Daniel Migault writes:
> Regarding the negotiation of the use of the implicit IV three ways hav= e been
> proposed. Currently it seems that the consensus is more encline to def= ine
> Transform IDs. However, it has been raised that Transform Attributes m= ight be
> a better protocol design choice.

My personal preference is for Transform IDs.

> I would like to understand if there are any guidance whether using att= ributes
> is preferred to ID or vice versa and if there is any preference in usi= ng=C2=A0
> IMPLICIT IV Transform ID versus an IMPLICIT IV Transform Attribute.
Both with Transform IDs and Transform Attributes you need to duplica= te
each cipher support things. The payload would be either:

=C2=A0SA Payload
=C2=A0|
=C2=A0+-- Proposal #1 ( Proto ID =3D ESP(3), SPI size =3D 4,
=C2=A0|=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7 transforms= ,=C2=A0 =C2=A0 =C2=A0 SPI =3D 0x052357bb )
=C2=A0|=C2=A0 =C2=A0|
=C2=A0|=C2=A0 =C2=A0+-- Transform ENCR ( Name =3D ENCR_AES_CBC )
=C2=A0|=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 128= )
=C2=A0|=C2=A0 =C2=A0|
=C2=A0|=C2=A0 =C2=A0+-- Transform ENCR ( Name =3D ENCR_AES_CBC )
=C2=A0|=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 192= )
=C2=A0|=C2=A0 =C2=A0|
=C2=A0|=C2=A0 =C2=A0+-- Transform ENCR ( Name =3D ENCR_AES_CBC )
=C2=A0|=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 256= )
=C2=A0|=C2=A0 =C2=A0|
=C2=A0|=C2=A0 =C2=A0+-- Transform INTEG ( Name =3D AUTH_HMAC_SHA1_96 )
=C2=A0|=C2=A0 =C2=A0+-- Transform INTEG ( Name =3D AUTH_AES_XCBC_96 )
=C2=A0|=C2=A0 =C2=A0+-- Transform ESN ( Name =3D ESNs )
=C2=A0|=C2=A0 =C2=A0+-- Transform ESN ( Name =3D No ESNs )
=C2=A0|
=C2=A0+-- Proposal #2 ( Proto ID =3D ESP(3), SPI size =3D 4,
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6 transforms= ,=C2=A0 =C2=A0 =C2=A0 SPI =3D 0x35a1d6f2 )
=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0+-- Transform ENCR ( Name =3D AES-GCM with a 8 octet IC= V )
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 128= )
=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0+-- Transform ENCR ( Name =3D AES-GCM with a 8 octet IC= V )
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 256= )
=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0+-- Transform ENCR ( Name =3D AES-GCM with a 8 octet IC= V Implicit IV )
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 128= )
=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0+-- Transform ENCR ( Name =3D AES-GCM with a 8 octet IC= V Implicit IV )
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 256= )
=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0+-- Transform ESN ( Name =3D ESNs )
=C2=A0 =C2=A0 =C2=A0+-- Transform ESN ( Name =3D No ESNs )

Or:

=C2=A0SA Payload
=C2=A0|
=C2=A0+-- Proposal #1 ( Proto ID =3D ESP(3), SPI size =3D 4,
=C2=A0|=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7 transforms= ,=C2=A0 =C2=A0 =C2=A0 SPI =3D 0x052357bb )
=C2=A0|=C2=A0 =C2=A0|
=C2=A0|=C2=A0 =C2=A0+-- Transform ENCR ( Name =3D ENCR_AES_CBC )
=C2=A0|=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 128= )
=C2=A0|=C2=A0 =C2=A0|
=C2=A0|=C2=A0 =C2=A0+-- Transform ENCR ( Name =3D ENCR_AES_CBC )
=C2=A0|=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 192= )
=C2=A0|=C2=A0 =C2=A0|
=C2=A0|=C2=A0 =C2=A0+-- Transform ENCR ( Name =3D ENCR_AES_CBC )
=C2=A0|=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 256= )
=C2=A0|=C2=A0 =C2=A0|
=C2=A0|=C2=A0 =C2=A0+-- Transform INTEG ( Name =3D AUTH_HMAC_SHA1_96 )
=C2=A0|=C2=A0 =C2=A0+-- Transform INTEG ( Name =3D AUTH_AES_XCBC_96 )
=C2=A0|=C2=A0 =C2=A0+-- Transform ESN ( Name =3D ESNs )
=C2=A0|=C2=A0 =C2=A0+-- Transform ESN ( Name =3D No ESNs )
=C2=A0|
=C2=A0+-- Proposal #2 ( Proto ID =3D ESP(3), SPI size =3D 4,
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6 transforms= ,=C2=A0 =C2=A0 =C2=A0 SPI =3D 0x35a1d6f2 )
=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0+-- Transform ENCR ( Name =3D AES-GCM with a 8 octet IC= V )
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 128= )
=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0+-- Transform ENCR ( Name =3D AES-GCM with a 8 octet IC= V )
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 256= )
=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0+-- Transform ENCR ( Name =3D AES-GCM with a 8 octet IC= V )
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 128= )
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Implicit =3D Yes )=
=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0+-- Transform ENCR ( Name =3D AES-GCM with a 8 octet IC= V )
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Key Length =3D 256= )
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+-- Attribute ( Implicit =3D Yes )=
=C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0+-- Transform ESN ( Name =3D ESNs )
=C2=A0 =C2=A0 =C2=A0+-- Transform ESN ( Name =3D No ESNs )

where missing Implicit would mean same as Implicit =3D No.

The Transform ID version provides more compact encoding, and I think
it is cleaner.

If transform attribute version is used, that would provide easy way to
expand this for every cipher we have, i.e. including
ENCR_CAMELLIA_CCM, i.e. if we just say it is allowed for
ENCR_CAMELLIA_CCM too, then it can use it. For the Transform ID option
we need to allocate separate ID for ENCR_CAMELLIA_CCM_IIV to allow it
using implicit IV.

Transform IDs are fairly cheap, and I think it is better that we
explictly mention which ciphers can use this, and doing this by
allocating separate number for them is clean way of indicating that.
Otherwise we need table listing which attributes are allowed with
which cipher...
--
kivinen@iki.fi

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

--001a114b25fe218e6b05357d2776-- From nobody Fri Jun 17 13:51:05 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1339C12DB24; Fri, 17 Jun 2016 13:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rjMPIxEHAhQ; Fri, 17 Jun 2016 13:51:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C34512DB23; Fri, 17 Jun 2016 13:50:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMD45149; Fri, 17 Jun 2016 20:50:56 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 17 Jun 2016 21:50:55 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0235.001; Fri, 17 Jun 2016 13:50:47 -0700 From: Linda Dunbar To: Rafa Marin Lopez , Linda Dunbar Thread-Topic: [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? Thread-Index: AQHRyJXW/dWNT5292kuu9K0bP3U5LZ/t7k5A Date: Fri, 17 Jun 2016 20:50:47 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> In-Reply-To: <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.134.206] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657EB5D2Bdfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.576462B1.0064, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 34c72436a3314ce6aa294479d4c99be0 Archived-At: Cc: "I2NSF@ietf.org" , "IPsec@ietf.org" , Sowmini Varadhan , Sowmini Varadhan Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 20:51:04 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657EB5D2Bdfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmFmYSwNCg0KUXVpY2tseSByZWFkaW5nIHRocm91Z2ggeW91ciBkcmFmdCwgSSBoYXZlIGEgZmV3 IHF1ZXN0aW9uczoNCg0KLSBEbyB5b3UgbWVhbiB0aGF0IHRoZSAoU0ROKSBjb250cm9sbGVyIHdp bGwgYmUgcmVzcG9uc2libGUgZm9yIGRpc3RyaWJ1dGluZyB0aGUgbmVlZGVkIGluZm9ybWF0aW9u IHRvIHRoZSBlbmQgbm9kZXMgb2YgdGhlIElQU2VjIHR1bm5lbCBXaGVuIHlvdSBzYXkgIlNETiBj b250cm9sbGVyIHRha2VzIHRoZSByb2xlIG9mIHRoZSBJbnRlcm5ldCBLZXkgRXhjaGFuZ2UgKElL RSkgZW50aXR5IGluIHRoZSBJUHNlYyBhcmNoaXRlY3R1cmUiPw0KDQotIFNlY3Rpb24gOC4xOiBQ YWdlIDExOiBCdWxsZXQgMToNCiAgICAgIFlvdSBzdGF0ZWQgdGhhdCB0aGUgbm9kZSBzZW5kcyB0 aGUgZmlyc3QgcGFja2V0IHRvIENvbnRyb2xsZXIgZm9yIHRoZSBjb250cm9sbGVyIHRvIGRldGVy bWluZSBpZiB0aGUgdHJhZmZpYyBuZWVkcyB0byBnbyB0aHJvdWdoIElQU2VjIHR1bm5lbC4NCg0K ICAgICAgU2hvdWxkbid0IHRoZSBjb250cm9sbGVyIGdldCBmbG93IHByb3RlY3Rpb24gcG9saWN5 IGZyb20gY2xpZW50cyAobm9ydGggYm91bmQgaW50ZXJmYWNlKSBhbmQgaW5mb3JtIHRoZSBuZWVk ZWQgZW5kIG5vZGVzIG9uIHdoYXQgdHJhZmZpYy9mbG93cyBuZWVkIHRvIGdvIHRocm91Z2ggdGhl IElQU2VjIHR1bm5lbD8NCg0KDQotIFNlY3Rpb24gOC4xOiBQYWdlIDEyOiBCdWxsZXQgMzoNCiAg ICAgIFRoZSBjb250cm9sbGVyIGNhbid0IHJlYWxseSBlbmZvcmNlIHRoZSBydWxlLiBidXQgaW5z dGVhZCByZXF1ZXN0aW5nIHRoZSAiRW5kIE5vZGUiIHRvIGVuY2Fwc3VsYXRlIHRoZSBJUFNlYyB0 dW5uZWwgYXJvdW5kIHRoZSBmbG93cyB0aGF0IG5lZWQgdG8gYmUgdGhyb3VnaCB0aGUgSVBTZWMg dHVubmVsLiBjb3JyZWN0Pw0KDQotIFNlY3Rpb24gNiwgUGFnZSA3LCBTZWNvbmQgcGFyYWdyYXBo IGFmdGVyIHRoZSBGaWd1cmUgMjoNCiAgICAgIFRoZSBDb250cm9sbGVyIHNob3VsZCBzZW5kIHRo ZSBJUFNlYyB0dW5uZWwgcmVxdWVzdCB0byB0aGUgZW5kIHBvaW50cyBvZiB0aGUgZGVzaXJlZCBJ UFNlYyB0dW5uZWwuIEFsc28gdGhlIGNvbnRyb2xsZXIgc2hvdWxkIHNlbmQgcXVlcnkgdG8gdGhl IGVuZCBwb2ludCB0byBjaGVjayBpZiB0aGV5IGhhdmUgdGhlIG5lZWRlZCByZXNvdXJjZSB0byBl c3RhYmxpc2ggdGhlIGRlc2lyZWQgSVBTZWMgdHVubmVsLg0KDQotIFNlY3Rpb24gOC4yOg0KICAg ICAgU2Vjb25kIHBhcmFncmFwaDogV2hlbiB0aGUgdHdvIGVuZCBwb2ludHMgb2YgdGhlIG5lZWRl ZCBJUFNlYyB0dW5uZWwgYXJlIGluIHR3byBkaWZmZXJlbnQgSVNQcyAoc2F5IElTUC1BIGFuZCBJ U1AtQiksIHlvdXIgZHJhZnQgc3RhdGVzIHRoYXQgdGhlIElTUC1BIGNvbnRyb2xsZXIgaGFzIHRv IG5lZ290aWF0ZSB3aXRoIElTUC1CIGNvbnRyb2xsZXIgb24gdGhlIEZsb3cgU2VjdXJpdHkgcG9s aWN5IHJ1bGVzLiBXaGF0IGluZm9ybWF0aW9uIHdpbGwgYmUgY2FycmllZCBieSB0aG9zZSBQb2xp Y3kgUnVsZXM/IFNpbmNlIEkyTlNGIGlzIHRvIHNwZWNpZnkgdGhlIGRhdGEgbW9kZWxzIGZvciB0 aG9zZSBydWxlcywgaXQgd291bGQgYmUgdmVyeSBoZWxwZnVsIHRvIGlkZW50aWZ5IHRoZSBpbmZv cm1hdGlvbiBleGNoYW5nZWQgZmlyc3QuDQoNCiAgICAgIFBhZ2UgMTM6IGJ1bGxldCAyOiBiZWZv cmUgdGhlIG5lZ290aWF0aW9uIGJldHdlZW4gdGhlIHR3byBjb250cm9sbGVycyBvbiB0aGUgU1BE IHBvbGljaWVzIGFuZCBJS0UgY3JlZGVudGlhbHMsIGRvbid0IHlvdSB0aGluayB0aGF0IHRoZXkg bmVlZCB0byBpbnF1aXJlIGVhY2ggb3RoZXIgaWYgdGhlIG90aGVyIHBhcnR5IGhhcyB0aGUgbmVl ZGVkIHJlc291cmNlIGZvciB0aGUgbmVlZGVkIElQc2VjIHR1bm5lbD8NCg0KDQoNClRoYW5rcywg TGluZGENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJhZmEgTWFyaW4gTG9w ZXogW21haWx0bzpyYWZhQHVtLmVzXQ0KU2VudDogRnJpZGF5LCBKdW5lIDE3LCAyMDE2IDc6NDMg QU0NClRvOiBMaW5kYSBEdW5iYXINCkNjOiBSYWZhIE1hcmluIExvcGV6OyBTb3dtaW5pIFZhcmFk aGFuOyBJMk5TRkBpZXRmLm9yZzsgU293bWluaSBWYXJhZGhhbjsgTlZPMzsgTGl5aXpob3UNClN1 YmplY3Q6IFJlOiBbSTJuc2ZdIEhvdyBkb2VzIE92ZXJsYXkgTmV0d29yayBpbmZvcm0gdGhlIFVu ZGVybGF5IG5ldHdvcmsgb24gd2hpY2ggZmxvd3MgYW1vbmcgT3ZlcmxheSBuZXR3b3JrIG5vZGVz IG5lZWQgdG8gZ28gdGhyb3VnaCBJUFNlYyBUdW5uZWw/ICh3YXMgOiBGbG93IFNlY3VyaXR5IFBv bGljaWVzIGV4Y2hhbmdlZCBvdmVyIEkyTlNGIHNlcnZpY2UgbGF5ZXIgaW50ZXJmYWNlPw0KDQpE ZWFyIGFsbDoNCg0KTWF5YmUgdGhpcyBJLUQgbWlnaHQgYmUgaW50ZXJlc3RpbmcgYW5kIHJlbGF0 ZWQgd2l0aCB0aGlzIGRpc2N1c3Npb24gcmVnYXJkaW5nIElQc2VjL0lLRSBtYW5hZ2VtZW50LiBX ZSBob3BlIHRvIGhhdmUgYW4gdXBkYXRlZCB2ZXJzaW9uIHNvb24gYW5kIGEgcHJvb2Ytb2YtY29u Y2VwdCBpbXBsZW1lbnRhdGlvbiBvZiBzb21lIG9mIHRoZSBzY2VuYXJpb3MuDQoNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hYmFkLXNkbnJnLXNkbi1pcHNlYy1mbG93LXByb3Rl Y3Rpb24tMDENCg0KQmVzdCBSZWdhcmRzLg0KDQoNCj4gRWwgMTcganVuIDIwMTYsIGEgbGFzIDEw OjQzLCBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPiBlc2NyaWJpw7M6DQo+ DQo+IFNvd21pbmksDQo+DQo+IFlvdSBzYWlkOg0KPiDigJxIb3dldmVyLCBhcHBseWluZyBJUHNl YyB0byBzcGVjaWZpYyBmbG93cyAoZS5nLiwgdGhvc2UgZGVmaW5lZCBieSBhIHNyYyBvciBkc3Qg cG9ydCBvbiB3aGljaCB0aGUgc2VydmljZSBsaXN0ZW5zKSBpcyBpbXBvcnRhbnQu4oCdDQo+DQo+ IFdoYXQgaXMgdGhlIGN1cnJlbnQgb3BlcmF0aW9uIHByb2NlZHVyZSBmb3IgT3ZlcmxheSBuZXR3 b3JrIHRvIGluZm9ybSB0aGUgdW5kZXJsYXkgbmV0d29yayBvbiB3aGljaCBmbG93cyB0byBnbyB0 aHJvdWdoIElQU2VjIGNoYW5uZWw/DQo+DQo+IFlvdSBzYWlkOg0KPiDigJwuLkJ1dCB0aGF0IGFs c28gbWFkZSBtZSB3b25kZXIgYWJvdXQgdGhlIGludGVyYWN0aW9uIGJldHdlZW4gSVBzZWMvSUtF IGFuZCB0aGUgcHJvcG9zZWQgQkdQIEZTIChJUHNlYyBpcyBmcmVxdWVudGx5IHVzZWQgYmV0d2Vl biBlbmQtc3lzdGVtcyB0aGF0IGRvIG5vdCB3YW50IHRvIHJ1biBhIEJHUCBkYWVtb24pLiBTaW5j ZSB0aGUgY29uZmlnIGluZm9ybWF0aW9uIHRoYXQgbmVlZHMgdG8gYmUgZGlzdHJpYnV0ZWQgYXJl IHRoaW5ncyBsaWtlIGtleXMsIGFsZ29yaXRobXMgZXRjIHRvIHBvcHVsYXRlIHRoZSBzYWRiL3Nw ZCwgSUtFIGxvb2tzIG1vcmUgYXBwcm9wcmlhdGUgaW4gbW9zdCBjYXNlcy7igJ0NCj4NCj4NCj4g RG9lcyB0aGUgdW5kZXJsYXkgbmV0d29yayBjb250cm9sbGVyIGdldCBzb21lIGluZm9ybWF0aW9u IChvciBoaW50IGZyb20gdGhlIE92ZXJsYXkgbmV0d29yayBjb250cm9sbGVyKSBvbiBob3cgdGhl IGtleXMgYXJlIGNvbmZpZ3VyZWQgZm9yIHRoZSBJUFNlYyB0dW5uZWwgZm9yIHRoZSBzcGVjaWZp YyBmbG93cyBhbW9uZyB0aGUgT3ZlcmxheSBub2Rlcz8NCj4NCj4NCj4gVGhhbmtzLA0KPiBMaW5k YQ0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTb3dtaW5pIFZh cmFkaGFuIFttYWlsdG86c293bWluaTA1QGdtYWlsLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIEp1 bmUgMTYsIDIwMTYgMTA6NTcgQU0NCj4gVG86IExpbmRhIER1bmJhcg0KPiBDYzogTGl5aXpob3U7 IE5WTzM7IFNvd21pbmkgVmFyYWRoYW4NCj4gU3ViamVjdDogUmU6IFtudm8zXSBGVzogQW55IHVz ZSBjYXNlcyBvZiBPdmVybGF5IG5ldHdvcmsgcmVxdWVzdGluZyBJUFNlYyBjb25uZWN0aW9uIGZy b20gdGhlIFVuZGVybGF5IGZvciBhIHNwZWNpZmljIHRpbWUgc3Bhbj8gKHdhcyA6IEZsb3cgU2Vj dXJpdHkgUG9saWNpZXMgZXhjaGFuZ2VkIG92ZXIgSTJOU0Ygc2VydmljZSBsYXllciBpbnRlcmZh Y2U/DQo+DQo+IE9uIFdlZCwgSnVuIDE1LCAyMDE2IGF0IDg6NTUgQU0sIExpbmRhIER1bmJhciA8 bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+IHdyb3RlOg0KPiA+DQo+ID4gTlZPMyBQYXJ0aWNpcGFu dHMsDQo+ID4NCj4gPg0KPiA+DQo+ID4gSTJOU0YgKEludGVyZmFjZSB0byBOZXR3b3JrIFNlY3Vy aXR5IGZ1bmN0aW9uKSBoYXMgYSB3b3JrIGl0ZW0gaW4gZGVmaW5pbmcgdGhlIGZsb3cgc2VjdXJp dHkgcG9saWN5IGJldHdlZW4gZG9tYWlucyAod2hpY2ggaW5jbHVkZXMgaW5xdWlyeSBvZiB0aGUg Y2FwYWJpbGl0eSBmcm9tIG9uZSBkb21haW4gdG8gYW5vdGhlciBhbmQgdGhlIGFjdHVhbCBmbG93 IHBvbGljeSBydWxlcyBmcm9tIG9uZSBkb21haW4gdG8gYW5vdGhlcikuDQo+ID4NCj4gPiBWZXJ5 IG9mdGVuLCB0aGUgcGF0aHMgKG9yIGxpbmtzKSBhbW9uZyBub2RlcyBvZiBhIG92ZXJsYXkgbmV0 d29yayBhcmUgcHJvdmlkZWQgYnkgb3RoZXIgbmV0d29yayBvcGVyYXRvcnMgKGEuay5hLiDigJx1 bmRlcmxheSBuZXR3b3Jr4oCdKS4gIFRoZSBmbG93IHBvbGljeSBydWxlcyBhcmUgaW50ZW5kZWQg dG8gZmlsdGVyIG91dCB1bndhbnRlZCB0cmFmZmljIGZyb20gdW5kZXJsYXkgbmV0d29yayBzbyB0 aGF0IHZhcmlvdXMgYXR0YWNrIHRyYWZmaWMgd29u4oCZdCBzYXR1cmF0ZWQgdGhlIGFjY2VzcyBs aW5rcyB0byB0aGUgb3ZlcmxheSBub2Rlcy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBPbmUgaW50ZXJl c3Rpbmcgc2NlbmFyaW8gYnJvdWdodCB1cCBpcyBPdmVybGF5IG5vZGVzIG1heSBuZWVkIHRvIHJl cXVlc3Qgc29tZSB0cmFmZmljIHRvIGJlIHRyYXZlcnNpbmcgSVBzZWMgY2hhbm5lbC4gVG8gYWNo aWV2ZSB0aGlzIGdvYWwsIGl0IGlzIG5lY2Vzc2FyeSBmb3IgT3ZlcmxheSBOZXR3b3JrIGNvbnRy b2xsZXIgdG8gaW5xdWlyZSBpZiB0aGUgbmVlZGVkIElQc2VjIHJlc291cmNlIGFyZSBldmVuIGF2 YWlsYWJsZSBiZWZvcmUgc2VuZCB0aGUgcmVxdWVzdCAobWF5IGV2ZW4gaW52b2x2ZSBBQUEgcHJv Y2VzcyBiZXR3ZWVuIGNvbnRyb2xsZXJzIG9mIGVhY2ggY29ycmVzcG9uZGluZyBkb21haW4gKS4N Cj4gPg0KPiA+DQo+ID4NCj4gPiBXYW50IHRvIGhhdmUgYSBzdXJ2ZXkgaWYgcGVvcGxlIHNlZSB0 aGUgdXNlIGNhc2Ugb2YgT3ZlcmxheSBOZXR3b3JrIG5lZWRpbmcgcG9ydGlvbiBvZiB0cmFmZmlj IHRvIGJlIHRocm91Z2ggSVBTZWMgY2hhbm5lbD8NCj4NCj4gWWVzLCB0aGlzIGlzIGEgdmFsaWQg dXNlIGNhc2UsIGFuZCBvbmUgdGhhdCB3ZSAgYXJlIGxvb2tpbmcgYXQgYXMgd2VsbC4NCj4NCj4g PiBJUFNlYyBpcyBzdXBwb3NlZCB0byBiZSBiZXR3ZWVuIHR3byBlbmQgbm9kZXMuIEhlcmUgd2Ug YXNzdW1lIHRoYXQgdGhlIE92ZXJsYXkgbm9kZXMgZG9u4oCZdCBoYXZlIHRoZSByZXNvdXJjZSBv ciBjYXBhYmlsaXR5IGZvciBJUHNlYywgYnV0IGV4cGVjdCBJUHNlYyBiZXR3ZWVuIGZsb3figJlz IGluZ3Jlc3MgYW5kIGVncmVzcyBub2RlcyAoaS5lLiBOVkUpLg0KPiA+IEFueSBvcGluaW9uIGlz IGFwcHJlY2lhdGVkLg0KPg0KPg0KPiA+DQo+ID4gQXJlIHRoZXJlIGFueSB1c2UgY2FzZXMgb2Yg b3ZlcmxheSBuZXR3b3JrIG5lZWRpbmcgSVBTZWMgYW1vbmcgdGhlaXIgbm9kZXMgb25seSBmb3Ig YSBzcGVjaWZpYyB0aW1lIHNwYW4/IGkuZS4gVGltZSBiYXNlZCBJUFNlYyBjb25uZWN0aW9uPw0K Pg0KPiBUaW1lIGJhc2VkIElQc2VjIGNvbm5lY3Rpb24gaXMgbm90IGEgdXNlLWNhc2Ugd2UgaGF2 ZSBlbmNvdW50ZXJlZC4NCj4gUGVvcGxlIHVzdWFsbHkgdXNlIElLRSBmb3IgcGVyaW9kaWMga2V5 LXJvbGxvdmVyLCBpZiB0aGF0IGlzIHRoZSBnb2FsLg0KPg0KPiBIb3dldmVyLCBhcHBseWluZyBJ UHNlYyB0byBzcGVjaWZpYyBmbG93cyAoZS5nLiwgdGhvc2UgZGVmaW5lZCBieSBhIHNyYyBvciBk c3QgcG9ydCBvbiB3aGljaCB0aGUgc2VydmljZSBsaXN0ZW5zKSBpcyBpbXBvcnRhbnQuDQo+DQo+ IEJ1dCB0aGF0IGFsc28gbWFkZSBtZSB3b25kZXIgYWJvdXQgdGhlIGludGVyYWN0aW9uIGJldHdl ZW4gSVBzZWMvSUtFIGFuZCB0aGUgcHJvcG9zZWQgQkdQIEZTIChJUHNlYyBpcyBmcmVxdWVudGx5 IHVzZWQgYmV0d2VlbiBlbmQtc3lzdGVtcyB0aGF0IGRvIG5vdCB3YW50IHRvIHJ1biBhIEJHUCBk YWVtb24pLiBTaW5jZSB0aGUgY29uZmlnIGluZm9ybWF0aW9uIHRoYXQgbmVlZHMgdG8gYmUgZGlz dHJpYnV0ZWQgYXJlIHRoaW5ncyBsaWtlIGtleXMsIGFsZ29yaXRobXMgZXRjIHRvIHBvcHVsYXRl IHRoZSBzYWRiL3NwZCwgSUtFIGxvb2tzIG1vcmUgYXBwcm9wcmlhdGUgaW4gbW9zdCBjYXNlcy4N Cj4NCj4gTGlrZSBbQ0pdLCBJIHRvbyBoYXZlIHRvIHJlYWQgdGhlIGRyYWZ0IGluIGdyZWF0ZXIg ZGV0YWlsIHRvIGNvbW1lbnQgZnVydGhlci4NCj4NCj4gLS1Tb3dtaW5pDQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEkybnNmIG1haWxpbmcg bGlzdA0KPiBJMm5zZkBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2kybnNmDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClJhZmFlbCBNYXJpbiBMb3BleiwgUGhEDQpEZXB0LiBJbmZvcm1hdGlv biBhbmQgQ29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcgKERJSUMpIEZhY3VsdHkgb2YgQ29tcHV0 ZXIgU2NpZW5jZS1Vbml2ZXJzaXR5IG9mIE11cmNpYQ0KMzAxMDAgTXVyY2lhIC0gU3BhaW4NClRl bGY6ICszNDg2ODg4ODUwMSBGYXg6ICszNDg2ODg4NDE1MSBlLW1haWw6IHJhZmFAdW0uZXMNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K DQoNCg0KDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657EB5D2Bdfweml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDb25zb2xhcyIgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Ij4NCjxkaXY+UmFmYSwgPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj5RdWlja2x5IHJlYWRpbmcgdGhyb3VnaCB5b3VyIGRyYWZ0LCBJIGhhdmUgYSBm ZXcgcXVlc3Rpb25zOjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZu YnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+LSBEbyB5b3UgbWVhbiB0aGF0IHRoZSAoU0ROKSBjb250 cm9sbGVyIHdpbGwgYmUgcmVzcG9uc2libGUgZm9yIGRpc3RyaWJ1dGluZyB0aGUgbmVlZGVkIGlu Zm9ybWF0aW9uIHRvIHRoZSBlbmQgbm9kZXMgb2YgdGhlIElQU2VjIHR1bm5lbCBXaGVuIHlvdSBz YXkgJnF1b3Q7U0ROIGNvbnRyb2xsZXIgdGFrZXMgdGhlIHJvbGUgb2YgdGhlIEludGVybmV0IEtl eSBFeGNoYW5nZSAoSUtFKSBlbnRpdHkgaW4gdGhlIElQc2VjIGFyY2hpdGVjdHVyZSZxdW90Oz88 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9k aXY+DQo8ZGl2Pi0gU2VjdGlvbiA4LjE6IFBhZ2UgMTE6IEJ1bGxldCAxOjwvZGl2Pg0KPGRpdiBz dHlsZT0icGFkZGluZy1sZWZ0OjM2cHQ7Ij5Zb3Ugc3RhdGVkIHRoYXQgdGhlIG5vZGUgc2VuZHMg dGhlIGZpcnN0IHBhY2tldCB0byBDb250cm9sbGVyIGZvciB0aGUgY29udHJvbGxlciB0byBkZXRl cm1pbmUgaWYgdGhlIHRyYWZmaWMgbmVlZHMgdG8gZ28gdGhyb3VnaCBJUFNlYyB0dW5uZWwuIDwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rp dj4NCjxkaXYgc3R5bGU9InBhZGRpbmctbGVmdDozNnB0OyI+U2hvdWxkbid0IHRoZSBjb250cm9s bGVyIGdldCBmbG93IHByb3RlY3Rpb24gcG9saWN5IGZyb20gY2xpZW50cyAobm9ydGggYm91bmQg aW50ZXJmYWNlKSBhbmQgaW5mb3JtIHRoZSBuZWVkZWQgZW5kIG5vZGVzIG9uIHdoYXQgdHJhZmZp Yy9mbG93cyBuZWVkIHRvIGdvIHRocm91Z2ggdGhlIElQU2VjIHR1bm5lbD88L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9m b250PjwvZGl2Pg0KPGRpdj4tIFNlY3Rpb24gOC4xOiBQYWdlIDEyOiBCdWxsZXQgMzo8L2Rpdj4N CjxkaXYgc3R5bGU9InBhZGRpbmctbGVmdDozNnB0OyI+PGZvbnQgZmFjZT0iU2Vnb2UgVUkiIHNp emU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPlRoZSBjb250cm9sbGVyIGNhbid0 IHJlYWxseSBlbmZvcmNlIHRoZSBydWxlLiBidXQgaW5zdGVhZCByZXF1ZXN0aW5nIHRoZSAmcXVv dDtFbmQgTm9kZSZxdW90OyB0byBlbmNhcHN1bGF0ZSB0aGUgSVBTZWMgdHVubmVsIGFyb3VuZCB0 aGUgZmxvd3MgdGhhdCBuZWVkIHRvIGJlIHRocm91Z2ggdGhlIElQU2VjDQp0dW5uZWwuIGNvcnJl Y3Q/PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYgc3R5bGU9InBhZGRpbmctbGVmdDozNnB0OyI+ PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pi0g U2VjdGlvbiA2LCBQYWdlIDcsIFNlY29uZCBwYXJhZ3JhcGggYWZ0ZXIgdGhlIEZpZ3VyZSAyOiA8 L2Rpdj4NCjxkaXYgc3R5bGU9InBhZGRpbmctbGVmdDozNnB0OyI+PGZvbnQgZmFjZT0iU2Vnb2Ug VUkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDsiPlRoZSBDb250cm9sbGVy IHNob3VsZCBzZW5kIHRoZSBJUFNlYyB0dW5uZWwgcmVxdWVzdCB0byB0aGUgZW5kIHBvaW50cyBv ZiB0aGUgZGVzaXJlZCBJUFNlYyB0dW5uZWwuIEFsc28gdGhlIGNvbnRyb2xsZXIgc2hvdWxkIHNl bmQgcXVlcnkgdG8gdGhlIGVuZCBwb2ludCB0byBjaGVjayBpZg0KdGhleSBoYXZlIHRoZSBuZWVk ZWQgcmVzb3VyY2UgdG8gZXN0YWJsaXNoIHRoZSBkZXNpcmVkIElQU2VjIHR1bm5lbC48L3NwYW4+ PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjM2cHQ7Ij48Zm9udCBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+LSBTZWN0aW9uIDgu MjogPC9kaXY+DQo8ZGl2IHN0eWxlPSJwYWRkaW5nLWxlZnQ6MzZwdDsiPlNlY29uZCBwYXJhZ3Jh cGg6IFdoZW4gdGhlIHR3byBlbmQgcG9pbnRzIG9mIHRoZSBuZWVkZWQgSVBTZWMgdHVubmVsIGFy ZSBpbiB0d28gZGlmZmVyZW50IElTUHMgKHNheSBJU1AtQSBhbmQgSVNQLUIpLCB5b3VyIGRyYWZ0 IHN0YXRlcyB0aGF0IHRoZSBJU1AtQSBjb250cm9sbGVyIGhhcyB0byBuZWdvdGlhdGUgd2l0aCBJ U1AtQiBjb250cm9sbGVyIG9uIHRoZSBGbG93IFNlY3VyaXR5IHBvbGljeQ0KcnVsZXMuIFdoYXQg aW5mb3JtYXRpb24gd2lsbCBiZSBjYXJyaWVkIGJ5IHRob3NlIFBvbGljeSBSdWxlcz8gU2luY2Ug STJOU0YgaXMgdG8gc3BlY2lmeSB0aGUgZGF0YSBtb2RlbHMgZm9yIHRob3NlIHJ1bGVzLCBpdCB3 b3VsZCBiZSB2ZXJ5IGhlbHBmdWwgdG8gaWRlbnRpZnkgdGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdl ZCBmaXJzdC4gPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7 PC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjM2cHQ7Ij5QYWdlIDEzOiBi dWxsZXQgMjogYmVmb3JlIHRoZSBuZWdvdGlhdGlvbiBiZXR3ZWVuIHRoZSB0d28gY29udHJvbGxl cnMgb24gdGhlIFNQRCBwb2xpY2llcyBhbmQgSUtFIGNyZWRlbnRpYWxzLCBkb24ndCB5b3UgdGhp bmsgdGhhdCB0aGV5IG5lZWQgdG8gaW5xdWlyZSBlYWNoIG90aGVyIGlmIHRoZSBvdGhlciBwYXJ0 eSBoYXMgdGhlIG5lZWRlZCByZXNvdXJjZSBmb3IgdGhlIG5lZWRlZCBJUHNlYw0KdHVubmVsPyA8 L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21h biI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PiZuYnNwOzwvZm9udD48L2Rpdj4NCjxkaXY+VGhhbmtzLCBMaW5kYTwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L2Rpdj4NCjxkaXY+RnJv bTogUmFmYSBNYXJpbiBMb3BleiBbPGEgaHJlZj0ibWFpbHRvOnJhZmFAdW0uZXMiPm1haWx0bzpy YWZhQHVtLmVzPC9hPl0gPC9kaXY+DQo8ZGl2PlNlbnQ6IEZyaWRheSwgSnVuZSAxNywgMjAxNiA3 OjQzIEFNPC9kaXY+DQo8ZGl2PlRvOiBMaW5kYSBEdW5iYXI8L2Rpdj4NCjxkaXY+Q2M6IFJhZmEg TWFyaW4gTG9wZXo7IFNvd21pbmkgVmFyYWRoYW47IEkyTlNGQGlldGYub3JnOyBTb3dtaW5pIFZh cmFkaGFuOyBOVk8zOyBMaXlpemhvdTwvZGl2Pg0KPGRpdj5TdWJqZWN0OiBSZTogW0kybnNmXSBI b3cgZG9lcyBPdmVybGF5IE5ldHdvcmsgaW5mb3JtIHRoZSBVbmRlcmxheSBuZXR3b3JrIG9uIHdo aWNoIGZsb3dzIGFtb25nIE92ZXJsYXkgbmV0d29yayBub2RlcyBuZWVkIHRvIGdvIHRocm91Z2gg SVBTZWMgVHVubmVsPyAod2FzIDogRmxvdyBTZWN1cml0eSBQb2xpY2llcyBleGNoYW5nZWQgb3Zl ciBJMk5TRiBzZXJ2aWNlIGxheWVyIGludGVyZmFjZT88L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2PkRlYXIgYWxsOjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+TWF5YmUgdGhp cyBJLUQgbWlnaHQgYmUgaW50ZXJlc3RpbmcgYW5kIHJlbGF0ZWQgd2l0aCB0aGlzIGRpc2N1c3Np b24gcmVnYXJkaW5nIElQc2VjL0lLRSBtYW5hZ2VtZW50LiBXZSBob3BlIHRvIGhhdmUgYW4gdXBk YXRlZCB2ZXJzaW9uIHNvb24gYW5kIGEgcHJvb2Ytb2YtY29uY2VwdCBpbXBsZW1lbnRhdGlvbiBv ZiBzb21lIG9mIHRoZSBzY2VuYXJpb3MuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj48 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYWJhZC1zZG5yZy1zZG4t aXBzZWMtZmxvdy1wcm90ZWN0aW9uLTAxIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtYWJhZC1zZG5yZy1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLTAxPC9hPjwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+QmVzdCBSZWdhcmRzLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDsgRWwgMTcganVuIDIwMTYsIGEgbGFzIDEw OjQzLCBMaW5kYSBEdW5iYXIgJmx0O2xpbmRhLmR1bmJhckBodWF3ZWkuY29tJmd0OyBlc2NyaWJp w7M6PC9kaXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgU293bWluaSw8L2Rpdj4NCjxk aXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyBZb3Ugc2FpZDo8L2Rpdj4NCjxkaXY+Jmd0 OyDigJxIb3dldmVyLCBhcHBseWluZyBJUHNlYyB0byBzcGVjaWZpYyBmbG93cyAoZS5nLiwgdGhv c2UgZGVmaW5lZCBieSBhIHNyYyBvciBkc3QgcG9ydCBvbiB3aGljaCB0aGUgc2VydmljZSBsaXN0 ZW5zKSBpcyBpbXBvcnRhbnQu4oCdPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2 PiZndDsgV2hhdCBpcyB0aGUgY3VycmVudCBvcGVyYXRpb24gcHJvY2VkdXJlIGZvciBPdmVybGF5 IG5ldHdvcmsgdG8gaW5mb3JtIHRoZSB1bmRlcmxheSBuZXR3b3JrIG9uIHdoaWNoIGZsb3dzIHRv IGdvIHRocm91Z2ggSVBTZWMgY2hhbm5lbD8gPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsgPC9kaXY+ DQo8ZGl2PiZndDsgWW91IHNhaWQ6IDwvZGl2Pg0KPGRpdj4mZ3Q7IOKAnC4uQnV0IHRoYXQgYWxz byBtYWRlIG1lIHdvbmRlciBhYm91dCB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiBJUHNlYy9JS0Ug YW5kIHRoZSBwcm9wb3NlZCBCR1AgRlMgKElQc2VjIGlzIGZyZXF1ZW50bHkgdXNlZCBiZXR3ZWVu IGVuZC1zeXN0ZW1zIHRoYXQgZG8gbm90IHdhbnQgdG8gcnVuIGEgQkdQIGRhZW1vbikuIFNpbmNl IHRoZSBjb25maWcgaW5mb3JtYXRpb24gdGhhdCBuZWVkcyB0byBiZSBkaXN0cmlidXRlZCBhcmUg dGhpbmdzDQpsaWtlIGtleXMsIGFsZ29yaXRobXMgZXRjIHRvIHBvcHVsYXRlIHRoZSBzYWRiL3Nw ZCwgSUtFIGxvb2tzIG1vcmUgYXBwcm9wcmlhdGUgaW4gbW9zdCBjYXNlcy7igJ08L2Rpdj4NCjxk aXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyBE b2VzIHRoZSB1bmRlcmxheSBuZXR3b3JrIGNvbnRyb2xsZXIgZ2V0IHNvbWUgaW5mb3JtYXRpb24g KG9yIGhpbnQgZnJvbSB0aGUgT3ZlcmxheSBuZXR3b3JrIGNvbnRyb2xsZXIpIG9uIGhvdyB0aGUg a2V5cyBhcmUgY29uZmlndXJlZCBmb3IgdGhlIElQU2VjIHR1bm5lbCBmb3IgdGhlIHNwZWNpZmlj IGZsb3dzIGFtb25nIHRoZSBPdmVybGF5IG5vZGVzPyA8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyA8 L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyBUaGFua3MsPC9kaXY+DQo8 ZGl2PiZndDsgTGluZGE8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyZu YnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvZGl2Pg0K PGRpdj4mZ3Q7IEZyb206IFNvd21pbmkgVmFyYWRoYW4gWzxhIGhyZWY9Im1haWx0bzpzb3dtaW5p MDVAZ21haWwuY29tIj5tYWlsdG86c293bWluaTA1QGdtYWlsLmNvbTwvYT5dPC9kaXY+DQo8ZGl2 PiZndDsgU2VudDogVGh1cnNkYXksIEp1bmUgMTYsIDIwMTYgMTA6NTcgQU08L2Rpdj4NCjxkaXY+ Jmd0OyBUbzogTGluZGEgRHVuYmFyPC9kaXY+DQo8ZGl2PiZndDsgQ2M6IExpeWl6aG91OyBOVk8z OyBTb3dtaW5pIFZhcmFkaGFuPC9kaXY+DQo8ZGl2PiZndDsgU3ViamVjdDogUmU6IFtudm8zXSBG VzogQW55IHVzZSBjYXNlcyBvZiBPdmVybGF5IG5ldHdvcmsgcmVxdWVzdGluZyBJUFNlYyBjb25u ZWN0aW9uIGZyb20gdGhlIFVuZGVybGF5IGZvciBhIHNwZWNpZmljIHRpbWUgc3Bhbj8gKHdhcyA6 IEZsb3cgU2VjdXJpdHkgUG9saWNpZXMgZXhjaGFuZ2VkIG92ZXIgSTJOU0Ygc2VydmljZSBsYXll ciBpbnRlcmZhY2U/PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDsgT24g V2VkLCBKdW4gMTUsIDIwMTYgYXQgODo1NSBBTSwgTGluZGEgRHVuYmFyICZsdDtsaW5kYS5kdW5i YXJAaHVhd2VpLmNvbSZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRp dj4mZ3Q7ICZndDsgTlZPMyBQYXJ0aWNpcGFudHMsPC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2 Pg0KPGRpdj4mZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsg Jmd0OyBJMk5TRiAoSW50ZXJmYWNlIHRvIE5ldHdvcmsgU2VjdXJpdHkgZnVuY3Rpb24pIGhhcyBh IHdvcmsgaXRlbSBpbiBkZWZpbmluZyB0aGUgZmxvdyBzZWN1cml0eSBwb2xpY3kgYmV0d2VlbiBk b21haW5zICh3aGljaCBpbmNsdWRlcyBpbnF1aXJ5IG9mIHRoZSBjYXBhYmlsaXR5IGZyb20gb25l IGRvbWFpbiB0byBhbm90aGVyIGFuZCB0aGUgYWN0dWFsIGZsb3cgcG9saWN5IHJ1bGVzIGZyb20g b25lIGRvbWFpbiB0byBhbm90aGVyKS48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2 PiZndDsgJmd0OyBWZXJ5IG9mdGVuLCB0aGUgcGF0aHMgKG9yIGxpbmtzKSBhbW9uZyBub2RlcyBv ZiBhIG92ZXJsYXkgbmV0d29yayBhcmUgcHJvdmlkZWQgYnkgb3RoZXIgbmV0d29yayBvcGVyYXRv cnMgKGEuay5hLiDigJx1bmRlcmxheSBuZXR3b3Jr4oCdKS4mbmJzcDsgVGhlIGZsb3cgcG9saWN5 IHJ1bGVzIGFyZSBpbnRlbmRlZCB0byBmaWx0ZXIgb3V0IHVud2FudGVkIHRyYWZmaWMgZnJvbSB1 bmRlcmxheSBuZXR3b3JrIHNvIHRoYXQgdmFyaW91cyBhdHRhY2sgdHJhZmZpYw0Kd29u4oCZdCBz YXR1cmF0ZWQgdGhlIGFjY2VzcyBsaW5rcyB0byB0aGUgb3ZlcmxheSBub2Rlcy48L2Rpdj4NCjxk aXY+Jmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDs8 L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IE9uZSBpbnRlcmVzdGluZyBzY2VuYXJpbyBicm91Z2h0IHVw IGlzIE92ZXJsYXkgbm9kZXMgbWF5IG5lZWQgdG8gcmVxdWVzdCBzb21lIHRyYWZmaWMgdG8gYmUg dHJhdmVyc2luZyBJUHNlYyBjaGFubmVsLiBUbyBhY2hpZXZlIHRoaXMgZ29hbCwgaXQgaXMgbmVj ZXNzYXJ5IGZvciBPdmVybGF5IE5ldHdvcmsgY29udHJvbGxlciB0byBpbnF1aXJlIGlmIHRoZSBu ZWVkZWQgSVBzZWMgcmVzb3VyY2UgYXJlIGV2ZW4gYXZhaWxhYmxlIGJlZm9yZQ0Kc2VuZCB0aGUg cmVxdWVzdCAobWF5IGV2ZW4gaW52b2x2ZSBBQUEgcHJvY2VzcyBiZXR3ZWVuIGNvbnRyb2xsZXJz IG9mIGVhY2ggY29ycmVzcG9uZGluZyBkb21haW4gKS48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9k aXY+DQo8ZGl2PiZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0 OyAmZ3Q7IFdhbnQgdG8gaGF2ZSBhIHN1cnZleSBpZiBwZW9wbGUgc2VlIHRoZSB1c2UgY2FzZSBv ZiBPdmVybGF5IE5ldHdvcmsgbmVlZGluZyBwb3J0aW9uIG9mIHRyYWZmaWMgdG8gYmUgdGhyb3Vn aCBJUFNlYyBjaGFubmVsPzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7 IFllcywgdGhpcyBpcyBhIHZhbGlkIHVzZSBjYXNlLCBhbmQgb25lIHRoYXQgd2UmbmJzcDsgYXJl IGxvb2tpbmcgYXQgYXMgd2VsbC48L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+ Jmd0OyAmZ3Q7IElQU2VjIGlzIHN1cHBvc2VkIHRvIGJlIGJldHdlZW4gdHdvIGVuZCBub2Rlcy4g SGVyZSB3ZSBhc3N1bWUgdGhhdCB0aGUgT3ZlcmxheSBub2RlcyBkb27igJl0IGhhdmUgdGhlIHJl c291cmNlIG9yIGNhcGFiaWxpdHkgZm9yIElQc2VjLCBidXQgZXhwZWN0IElQc2VjIGJldHdlZW4g Zmxvd+KAmXMgaW5ncmVzcyBhbmQgZWdyZXNzIG5vZGVzIChpLmUuIE5WRSkuPC9kaXY+DQo8ZGl2 PiZndDsgJmd0OyBBbnkgb3BpbmlvbiBpcyBhcHByZWNpYXRlZC48L2Rpdj4NCjxkaXY+Jmd0OyZu YnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7PC9kaXY+ DQo8ZGl2PiZndDsgJmd0OyBBcmUgdGhlcmUgYW55IHVzZSBjYXNlcyBvZiBvdmVybGF5IG5ldHdv cmsgbmVlZGluZyBJUFNlYyBhbW9uZyB0aGVpciBub2RlcyBvbmx5IGZvciBhIHNwZWNpZmljIHRp bWUgc3Bhbj8gaS5lLiBUaW1lIGJhc2VkIElQU2VjIGNvbm5lY3Rpb24/PC9kaXY+DQo8ZGl2PiZn dDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDsgVGltZSBiYXNlZCBJUHNlYyBjb25uZWN0aW9uIGlz IG5vdCBhIHVzZS1jYXNlIHdlIGhhdmUgZW5jb3VudGVyZWQuPC9kaXY+DQo8ZGl2PiZndDsgUGVv cGxlIHVzdWFsbHkgdXNlIElLRSBmb3IgcGVyaW9kaWMga2V5LXJvbGxvdmVyLCBpZiB0aGF0IGlz IHRoZSBnb2FsLjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7IEhvd2V2 ZXIsIGFwcGx5aW5nIElQc2VjIHRvIHNwZWNpZmljIGZsb3dzIChlLmcuLCB0aG9zZSBkZWZpbmVk IGJ5IGEgc3JjIG9yIGRzdCBwb3J0IG9uIHdoaWNoIHRoZSBzZXJ2aWNlIGxpc3RlbnMpIGlzIGlt cG9ydGFudC48L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyBCdXQgdGhh dCBhbHNvIG1hZGUgbWUgd29uZGVyIGFib3V0IHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIElQc2Vj L0lLRSBhbmQgdGhlIHByb3Bvc2VkIEJHUCBGUyAoSVBzZWMgaXMgZnJlcXVlbnRseSB1c2VkIGJl dHdlZW4gZW5kLXN5c3RlbXMgdGhhdCBkbyBub3Qgd2FudCB0byBydW4gYSBCR1AgZGFlbW9uKS4g U2luY2UgdGhlIGNvbmZpZyBpbmZvcm1hdGlvbiB0aGF0IG5lZWRzIHRvIGJlIGRpc3RyaWJ1dGVk IGFyZSB0aGluZ3MgbGlrZQ0Ka2V5cywgYWxnb3JpdGhtcyBldGMgdG8gcG9wdWxhdGUgdGhlIHNh ZGIvc3BkLCBJS0UgbG9va3MgbW9yZSBhcHByb3ByaWF0ZSBpbiBtb3N0IGNhc2VzLjwvZGl2Pg0K PGRpdj4mZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7IExpa2UgW0NKXSwgSSB0b28gaGF2ZSB0 byByZWFkIHRoZSBkcmFmdCBpbiBncmVhdGVyIGRldGFpbCB0byBjb21tZW50IGZ1cnRoZXIuPC9k aXY+DQo8ZGl2PiZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDsgLS1Tb3dtaW5pPC9kaXY+DQo8 ZGl2PiZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+Jmd0OyBJMm5zZiBtYWlsaW5nIGxp c3Q8L2Rpdj4NCjxkaXY+Jmd0OyBJMm5zZkBpZXRmLm9yZzwvZGl2Pg0KPGRpdj4mZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJuc2YiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJuc2Y8L2E+PC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9kaXY+DQo8ZGl2PlJhZmFlbCBNYXJpbiBMb3BleiwgUGhEPC9kaXY+DQo8 ZGl2PkRlcHQuIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBFbmdpbmVlcmluZyAoRElJ QykgRmFjdWx0eSBvZiBDb21wdXRlciBTY2llbmNlLVVuaXZlcnNpdHkgb2YgTXVyY2lhPC9kaXY+ DQo8ZGl2PjMwMTAwIE11cmNpYSAtIFNwYWluPC9kaXY+DQo8ZGl2PlRlbGY6ICYjNDM7MzQ4Njg4 ODg1MDEgRmF4OiAmIzQzOzM0ODY4ODg0MTUxIGUtbWFpbDogcmFmYUB1bS5lczwvZGl2Pg0KPGRp dj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657EB5D2Bdfweml501mbb_-- From nobody Fri Jun 17 14:27:00 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2445B12DA74; Fri, 17 Jun 2016 14:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ATz1MXeFW1X; Fri, 17 Jun 2016 14:26:57 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1623B12D8BB; Fri, 17 Jun 2016 14:26:57 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u5HLQoS0012736 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2016 21:26:51 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u5HLQoLC002882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 Jun 2016 21:26:50 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u5HLQn2D025399; Fri, 17 Jun 2016 21:26:49 GMT Received: from oracle.com (/10.154.116.124) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 Jun 2016 14:26:48 -0700 Date: Fri, 17 Jun 2016 17:26:48 -0400 From: Sowmini Varadhan To: Linda Dunbar Message-ID: <20160617212648.GB29411@oracle.com> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "I2NSF@ietf.org" , "IPsec@ietf.org" , Sowmini Varadhan , Rafa Marin Lopez Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2016 21:26:58 -0000 On (06/17/16 20:50), Linda Dunbar wrote: > - Section 8.1: Page 11: Bullet 1: > You stated that the node sends the first packet to Controller for the > controller to determine if the traffic needs to go through IPSec tunnel. > I had a related question Section 8.2, #2 as well: is the first data packet in the clear or not? If it is not in the clear, how can you determine the flow in the general case? If it is in the clear, what is the scope of the security consideration? --Sowmini From nobody Sun Jun 19 11:06:33 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6540812D67F; Sun, 19 Jun 2016 11:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8IfmAQf6kAz; Sun, 19 Jun 2016 11:06:26 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id B8CCC12D66C; Sun, 19 Jun 2016 11:06:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 5E4893FAFF; Sun, 19 Jun 2016 20:06:23 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id IWWDCv0R5Igo; Sun, 19 Jun 2016 20:06:23 +0200 (CEST) Received: from [192.168.1.38] (229.red-88-14-208.dynamicip.rima-tde.net [88.14.208.229]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id C8BE33F981; Sun, 19 Jun 2016 20:06:18 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> Date: Sun, 19 Jun 2016 20:06:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C1028FB-4531-4BA8-9C64-AE933945539F@um.es> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> To: Linda Dunbar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "I2NSF@ietf.org" , "IPsec@ietf.org" , Sowmini Varadhan , Rafa Marin Lopez , Sowmini Varadhan Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 18:06:29 -0000 Dear Linda: Thank you for reviewing our I-D. Please see my comments inline. > El 17 jun 2016, a las 22:50, Linda Dunbar = escribi=C3=B3: >=20 > Rafa,=20 > =20 > Quickly reading through your draft, I have a few questions: > =20 > - Do you mean that the (SDN) controller will be responsible for = distributing the needed information to the end nodes of the IPSec tunnel = When you say "SDN controller takes the role of the Internet Key Exchange = (IKE) entity in the IPsec architecture=E2=80=9D? [Rafa] Correct. That is the general idea in this I-D. SDN controller can = also send IKE credentials to the network resources if they implement IKE = (besides IPsec stack of course) > =20 > - Section 8.1: Page 11: Bullet 1: > You stated that the node sends the first packet to Controller for the = controller to determine if the traffic needs to go through IPSec tunnel.=20= > =20 > Shouldn't the controller get flow protection policy from clients = (north bound interface) and inform the needed end nodes on what = traffic/flows need to go through the IPSec tunnel? [Rafa] Actually, there are two options. The one shown in the I-D is = reactive, that is, very similar as it would happen with the OpenFlow = PacketIn message and then PacketOut. The other option, of course, it is = to create the rules in the network resource even when traffic has not = been observed yet (proactive). Both options are completely possible. We = can clarify this in the next version. > =20 > =20 > - Section 8.1: Page 12: Bullet 3: > The controller can't really enforce the rule. but instead requesting = the "End Node" to encapsulate the IPSec tunnel around the flows that = need to be through the IPSec tunnel. correct? [Rafa] Not sure why you think the controller can=E2=80=99t enforce the = rule. Basically the step 3 says the controller is filling a SAD entry = without the need of running IKE between network resources. > =20 > - Section 6, Page 7, Second paragraph after the Figure 2:=20 > The Controller should send the IPSec tunnel request to the end points = of the desired IPSec tunnel. Also the controller should send query to = the end point to check if they have the needed resource to establish the = desired IPSec tunnel. [Rafa] What do you mean with =E2=80=9CIPsec tunnel request=E2=80=9D? By = sending the information related with the IPsec tunnel (e.g. a SAD entry) = to build it should be enough, I guess that is what you mean by that , = right?. The controller can of course verify if the end points of the IPsec SA = have the information to establish an IPsec tunnel according to the = information that the controller keeps. If the state is not there or is = going to be outdated it can enforce the information again. = Alternatively, the end points could also inform when something is = required to the controller (reactive) so the controller can act = accordingly. > =20 > - Section 8.2:=20 > Second paragraph: When the two end points of the needed IPSec tunnel = are in two different ISPs (say ISP-A and ISP-B), your draft states that = the ISP-A controller has to negotiate with ISP-B controller on the Flow = Security policy rules. What information will be carried by those Policy = Rules? Since I2NSF is to specify the data models for those rules, it = would be very helpful to identify the information exchanged first.=20 [Rafa] We can specify better what information in the following draft. = But basically we have two models explained in the draft when 1) IKE is = implemented in the network resource or when IKE is not implemented in = the network resource. =20 In 1) parameters to run an IKE SA between GW1 and GW2 must be negotiated = (IKE credential, cryptographic suite, etc=E2=80=A6) and the different = SPD entries of the SPD that apply. An SPD entry has parameters such as = Remote IP Address, Local IP Address, Next Layer Protocol, Name, Local = and Remote Ports. In 2) apart from SPD entries you need to configure SAD entries. This = information implies Security Parameter Index, Sequence Number, AH = information (keys , key lifetime) , ESP information=E2=80=A6 etc. We can detail what information is required. > =20 > Page 13: bullet 2: before the negotiation between the two controllers = on the SPD policies and IKE credentials, don't you think that they need = to inquire each other if the other party has the needed resource for the = needed IPsec tunnel?=20 [Rafa] But for that, what kind of parameters do you send to ask the = question? I can imagine you could ask : do you have an end point with = this IP address, IKE support, AH or ESP support=E2=80=A6 etc=E2=80=A6? = Is that what you have in mind? In any case, if they do not have that support trying the negotiation = between the two controllers would fail so that you would notice that the = needed resource is not available as well, right? Best Regards. > =20 > =20 > =20 > Thanks, Linda > =20 > -----Original Message----- > From: Rafa Marin Lopez [mailto:rafa@um.es]=20 > Sent: Friday, June 17, 2016 7:43 AM > To: Linda Dunbar > Cc: Rafa Marin Lopez; Sowmini Varadhan; I2NSF@ietf.org; Sowmini = Varadhan; NVO3; Liyizhou > Subject: Re: [I2nsf] How does Overlay Network inform the Underlay = network on which flows among Overlay network nodes need to go through = IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service = layer interface? > =20 > Dear all: > =20 > Maybe this I-D might be interesting and related with this discussion = regarding IPsec/IKE management. We hope to have an updated version soon = and a proof-of-concept implementation of some of the scenarios. > =20 > = https://tools.ietf.org/html/draft-abad-sdnrg-sdn-ipsec-flow-protection-01 > =20 > Best Regards. > =20 > =20 > > El 17 jun 2016, a las 10:43, Linda Dunbar = escribi=C3=B3: > >=20 > > Sowmini, > > =20 > > You said: > > =E2=80=9CHowever, applying IPsec to specific flows (e.g., those = defined by a src or dst port on which the service listens) is = important.=E2=80=9D > > =20 > > What is the current operation procedure for Overlay network to = inform the underlay network on which flows to go through IPSec channel?=20= > > =20 > > You said:=20 > > =E2=80=9C..But that also made me wonder about the interaction = between IPsec/IKE and the proposed BGP FS (IPsec is frequently used = between end-systems that do not want to run a BGP daemon). Since the = config information that needs to be distributed are things like keys, = algorithms etc to populate the sadb/spd, IKE looks more appropriate in = most cases.=E2=80=9D > > =20 > > =20 > > Does the underlay network controller get some information (or hint = from the Overlay network controller) on how the keys are configured for = the IPSec tunnel for the specific flows among the Overlay nodes?=20 > > =20 > > =20 > > Thanks, > > Linda > > =20 > > =20 > > -----Original Message----- > > From: Sowmini Varadhan [mailto:sowmini05@gmail.com] > > Sent: Thursday, June 16, 2016 10:57 AM > > To: Linda Dunbar > > Cc: Liyizhou; NVO3; Sowmini Varadhan > > Subject: Re: [nvo3] FW: Any use cases of Overlay network requesting = IPSec connection from the Underlay for a specific time span? (was : Flow = Security Policies exchanged over I2NSF service layer interface? > > =20 > > On Wed, Jun 15, 2016 at 8:55 AM, Linda Dunbar = wrote: > > > > > > NVO3 Participants, > > > > > > > > > > > > I2NSF (Interface to Network Security function) has a work item in = defining the flow security policy between domains (which includes = inquiry of the capability from one domain to another and the actual flow = policy rules from one domain to another). > > > > > > Very often, the paths (or links) among nodes of a overlay network = are provided by other network operators (a.k.a. =E2=80=9Cunderlay = network=E2=80=9D). The flow policy rules are intended to filter out = unwanted traffic from underlay network so that various attack traffic = won=E2=80=99t saturated the access links to the overlay nodes. > > > > > > > > > > > > One interesting scenario brought up is Overlay nodes may need to = request some traffic to be traversing IPsec channel. To achieve this = goal, it is necessary for Overlay Network controller to inquire if the = needed IPsec resource are even available before send the request (may = even involve AAA process between controllers of each corresponding = domain ). > > > > > > > > > > > > Want to have a survey if people see the use case of Overlay = Network needing portion of traffic to be through IPSec channel? > > =20 > > Yes, this is a valid use case, and one that we are looking at as = well. > > =20 > > > IPSec is supposed to be between two end nodes. Here we assume that = the Overlay nodes don=E2=80=99t have the resource or capability for = IPsec, but expect IPsec between flow=E2=80=99s ingress and egress nodes = (i.e. NVE). > > > Any opinion is appreciated. > > =20 > > =20 > > > > > > Are there any use cases of overlay network needing IPSec among = their nodes only for a specific time span? i.e. Time based IPSec = connection? > > =20 > > Time based IPsec connection is not a use-case we have encountered. > > People usually use IKE for periodic key-rollover, if that is the = goal. > > =20 > > However, applying IPsec to specific flows (e.g., those defined by a = src or dst port on which the service listens) is important. > > =20 > > But that also made me wonder about the interaction between IPsec/IKE = and the proposed BGP FS (IPsec is frequently used between end-systems = that do not want to run a BGP daemon). Since the config information that = needs to be distributed are things like keys, algorithms etc to populate = the sadb/spd, IKE looks more appropriate in most cases. > > =20 > > Like [CJ], I too have to read the draft in greater detail to comment = further. > > =20 > > --Sowmini > > =20 > > _______________________________________________ > > I2nsf mailing list > > I2nsf@ietf.org > > https://www.ietf.org/mailman/listinfo/i2nsf > =20 > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) Faculty of = Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Sun Jun 19 11:07:08 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338D112D67F; Sun, 19 Jun 2016 11:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pNl1molYi0T; Sun, 19 Jun 2016 11:06:52 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 28FBB12D684; Sun, 19 Jun 2016 11:06:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 70AD33F981; Sun, 19 Jun 2016 20:06:51 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zggoUNjSWT4F; Sun, 19 Jun 2016 20:06:51 +0200 (CEST) Received: from [192.168.1.38] (229.red-88-14-208.dynamicip.rima-tde.net [88.14.208.229]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id 634083FAFF; Sun, 19 Jun 2016 20:06:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <20160617212648.GB29411@oracle.com> Date: Sun, 19 Jun 2016 20:06:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4D1F6DFD-12E1-4EA7-B440-C18203758C37@um.es> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <20160617212648.GB29411@oracle.com> To: Sowmini Varadhan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "I2NSF@ietf.org" , "IPsec@ietf.org" , Sowmini Varadhan , Rafa Marin Lopez , Linda Dunbar Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 18:07:07 -0000 Dear Sowmini: Thanks for asking about our I-D. > El 17 jun 2016, a las 23:26, Sowmini Varadhan = escribi=C3=B3: >=20 > On (06/17/16 20:50), Linda Dunbar wrote: >> - Section 8.1: Page 11: Bullet 1: >> You stated that the node sends the first packet to Controller for = the >> controller to determine if the traffic needs to go through IPSec = tunnel. >>=20 >=20 > I had a related question Section 8.2, #2 as well: is the first > data packet in the clear or not? If it is not in the clear, how > can you determine the flow in the general case?=20 [Rafa] Please be aware that, if ESP (AH does not encrypt the packet) has = been applied to the packet before reaching the GW1 the IP header of that = packet is still visible (it is not encrypted). And based on that = information there would be SPD entries so that the IPsec implementation = would act based on that visible information. Thus, adding the controller = does not change that behavior. So I am not sure the issue/problem you = may have in mind. > If it is in=20 > the clear, what is the scope of the security consideration? [Rafa] Not sure about what do you mean? Are you referring to section 9 = or other aspect? >=20 > --Sowmini >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Sun Jun 19 14:46:01 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F4B12D840; Sun, 19 Jun 2016 14:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYZdc2jfdG4U; Sun, 19 Jun 2016 14:45:57 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC07412D67C; Sun, 19 Jun 2016 14:45:57 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u5JLjlcH029215 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 19 Jun 2016 21:45:48 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u5JLjjAq010142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 19 Jun 2016 21:45:47 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u5JLjgBP014762; Sun, 19 Jun 2016 21:45:43 GMT Received: from oracle.com (/10.154.113.242) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 19 Jun 2016 14:45:42 -0700 Date: Sun, 19 Jun 2016 17:45:43 -0400 From: Sowmini Varadhan To: Rafa Marin Lopez Message-ID: <20160619214543.GD654@oracle.com> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <20160617212648.GB29411@oracle.com> <4D1F6DFD-12E1-4EA7-B440-C18203758C37@um.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D1F6DFD-12E1-4EA7-B440-C18203758C37@um.es> User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: "I2NSF@ietf.org" , "IPsec@ietf.org" , Sowmini Varadhan , Linda Dunbar Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 21:45:59 -0000 On (06/19/16 20:06), Rafa Marin Lopez wrote: > > I had a related question Section 8.2, #2 as well: is the first > > data packet in the clear or not? If it is not in the clear, how > > can you determine the flow in the general case? > > [Rafa] Please be aware that, if ESP (AH does not encrypt the packet) > has been applied to the packet before reaching the GW1 the IP header of > that packet is still visible (it is not encrypted). And based on that > information there would be SPD entries so that the IPsec implementation > would act based on that visible information. Thus, adding the controller > does not change that behavior. So I am not sure the issue/problem you > may have in mind. if the first packet is using AH, then the sender has alredy made some assumption about the auth key. How is the receiver going to know that key (assuming that AH has been added for a reason)? And what is the point of the following (quoted from Section 8.2) if the sender is already making some assumptions about the AH parameters for the first packet? "2. The SDN Controller looks for security policies in its SPD table and decides that the flow MUST be protected, for example, with IPsec ESP in tunnel mode. 3. The SDN controller derives keys for the IPsec tunnel and enforces them, along with other information required, such as IPsec mode (ESP or AH), into both gateways' IPsec Security Association Database (SAD)." To put this in another way, isnt this a chicken-and-egg problem: receiver is supposed to use the first data packet figure out the sadb/spd configuration (which may or may not include both AH and ESP), but the first packet itself has some AH (with no ESP) based on ? > > If it is in > > the clear, what is the scope of the security consideration? > > [Rafa] Not sure about what do you mean? Are you referring to section > 9 or other aspect? Is the IPsec SA/SPD negotiated in Section 8.1 applicable/different for the first packet compared to the rest of the flow? --Sowmini From nobody Sun Jun 19 16:29:27 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B2D12D18F; Sun, 19 Jun 2016 16:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmqftimSPEU7; Sun, 19 Jun 2016 16:29:21 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id BEF2112D110; Sun, 19 Jun 2016 16:29:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 660423FB53; Mon, 20 Jun 2016 01:29:19 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Z9A-wkQTIZtR; Mon, 20 Jun 2016 01:29:19 +0200 (CEST) Received: from [192.168.1.38] (229.red-88-14-208.dynamicip.rima-tde.net [88.14.208.229]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id 933BF3FB48; Mon, 20 Jun 2016 01:29:13 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <20160619214543.GD654@oracle.com> Date: Mon, 20 Jun 2016 01:29:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <20160617212648.GB29411@oracle.com> <4D1F6DFD-12E1-4EA7-B440-C18203758C37@um.es> <20160619214543.GD654@oracle.com> To: Sowmini Varadhan X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "I2NSF@ietf.org" , "IPsec@ietf.org" , Sowmini Varadhan , Rafa Marin Lopez , Linda Dunbar Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jun 2016 23:29:23 -0000 Dear Sowmini: > El 19 jun 2016, a las 23:45, Sowmini Varadhan = escribi=C3=B3: >=20 > On (06/19/16 20:06), Rafa Marin Lopez wrote: >>> I had a related question Section 8.2, #2 as well: is the first >>> data packet in the clear or not? If it is not in the clear, how >>> can you determine the flow in the general case?=20 >>=20 >> [Rafa] Please be aware that, if ESP (AH does not encrypt the packet) >> has been applied to the packet before reaching the GW1 the IP header = of >> that packet is still visible (it is not encrypted). And based on that >> information there would be SPD entries so that the IPsec = implementation >> would act based on that visible information. Thus, adding the = controller >> does not change that behavior. So I am not sure the issue/problem you >> may have in mind. >=20 > if the first packet is using AH, then the sender has alredy made > some assumption about the auth key. How is the receiver going to > know that key (assuming that AH has been added for a reason)?=20 [Rafa] The quick answer would be the controller have to install what is = required in both end points. However, from your questions, we have to = clarify first what is the use case we are discussing, which is the = following: host1-=E2=80=94gw1=E2=80=94=E2=80=94IPsec=E2=80=94=E2=80=94gw2=E2=80=94-ho= st2.=20 That is, a typical GW-to-GW scenario for IPsec tunnel. Imagine that host1 sends a IP packet to host2. The gw1 will get the IP = packet and it has to determine what to do. The gw1 contacts the = controller and the controller installs what it is required in both gw1 = and gw2 (e.g. IPsec tunnel in ESP mode, and the key material). With that = information the gw1 can tunnel the IP packet coming from host1 to host2 = inside a IPsec tunnel whose endpoints are gw1 and gw2. Thus, IPsec SA is = between gw1 and gw2 and the controller configures both. That would be the reactive case because everything is triggered in the = first packet arriving the gw1. I agree that gw1 must have something like = a default behavior saying =E2=80=9Cgo to the controller when you do not = know what to do=E2=80=9D (which is similar to packetin in openflow). Another approach is to just sending the SPD/SAD entries to gw1 and gw2 = (the controller knows that from the policies obtained from the = northbound api) even when either gw1 or gw2 have not observed any = traffic with those features. That is what I called proactive. =20 > And what is the point of the following (quoted from Section 8.2) > if the sender is already making some assumptions about the AH > parameters for the first packet? >=20 > "2. The SDN Controller looks for security policies in its SPD table > and decides that the flow MUST be protected, for example, with > IPsec ESP in tunnel mode. >=20 > 3. The SDN controller derives keys for the IPsec tunnel and = enforces > them, along with other information required, such as IPsec mode > (ESP or AH), into both gateways' IPsec Security Association > Database (SAD).=E2=80=9D [Rafa] As you can see, this text applies to the example I just = mentioned. Do you want to consider IPsec between host1 to host2 in an = end-to-end fashion (transport mode)? If the answer is yes, that should = be fairly similar. We can add also that use case to the next version of = the I-D. =20 >=20 > To put this in another way, isnt this a chicken-and-egg problem: [Rafa] I do not think so. > receiver is supposed to use the first data packet figure out the > sadb/spd configuration (which may or may not include both AH and ESP), > but the first packet itself has some AH (with no ESP) based on negotiation?>? [Rafa] I mentioned AH just to show that packets may be still in clear. = In any case, to your question and considering our example, if the first = packet coming from host1 to host2 through gw1 has AH, it does not matter = for gw1. =20 It would mean that there is some an IPsec SA AH in transport mode = between host1 and host2. The behavior in the gw1 will be same as = described above because they are different IPsec SA between different = end-points (host1-host2 and gw1-gw2). Now, you may ask: how does host1 know that the IP packet to host2 must = be protected with AH. If we follow the approach of using a controller, = the controller should have installed IPsec policies in both host1 and = host2. >=20 >>> If it is in=20 >>> the clear, what is the scope of the security consideration? >>=20 >> [Rafa] Not sure about what do you mean? Are you referring to section >> 9 or other aspect? >=20 > Is the IPsec SA/SPD negotiated in Section 8.1 applicable/different > for the first packet compared to the rest of the flow? No, it isn=E2=80=99t. This first packet that triggers everything (in the = reactive case) will be protected in the same way that the rest of the = flow. Although perhaps you question is related to what I have just mentioned = about the behavior regarding the first packet: "go to the controller = when you do not know what to do=E2=80=9D. This is a new behavior... I = agree (it is something like OpenFlow does) that we should definitely = describe for the reactive case. In the proactive case, no need for that.=20= Best Regards. >=20 > --Sowmini ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Mon Jun 20 06:42:10 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF57D12D5C4; Mon, 20 Jun 2016 06:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5-TfghBiZAw; Mon, 20 Jun 2016 06:41:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BAF712D5BD; Mon, 20 Jun 2016 06:41:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRE04350; Mon, 20 Jun 2016 13:41:54 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 20 Jun 2016 14:41:53 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Mon, 20 Jun 2016 06:41:50 -0700 From: Linda Dunbar To: Rafa Marin Lopez Thread-Topic: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? Thread-Index: AQHRyJXW/dWNT5292kuu9K0bP3U5LZ/t7k5AgAOga4CAAI+jwA== Date: Mon, 20 Jun 2016 13:41:48 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657ECCD0E@dfweml501-mbb> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <7C1028FB-4531-4BA8-9C64-AE933945539F@um.es> In-Reply-To: <7C1028FB-4531-4BA8-9C64-AE933945539F@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.219.148] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657ECCD0Edfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.5767F2A3.0165, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ae7d25a1209ff254589ee9cf5ae2fe9a Archived-At: Cc: "I2NSF@ietf.org" , "IPsec@ietf.org" , Sowmini Varadhan , Sowmini Varadhan Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jun 2016 13:42:03 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657ECCD0Edfweml501mbb_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmFmYSwNCg0KSSBzZWUgdGhhdCB5b3VyIGRyYWZ0IGhhcyBpZGVudGlmaWVkIG11bHRpcGxlIGNh c2VzIG9mIFNETiBjb250cm9sbGVkIElQU2VjIHR1bm5lbC4NCg0KQXMgSTJOU0YgZm9jdXMgb24g c3BlY2lmeWluZyB0aGUgZGF0YSBtb2RlbHMgZm9yIHRoZSBGbG93IFNlY3VyaXR5IFBvbGljaWVz LCB0aGUgY29udHJvbGxlciAiUHJvYWN0aXZlbHkiIHNldHRpbmcgdXAgdGhlIElQU2VjIHBvbGlj ZXMva2V5cyB0byBuZXR3b3JrIGVsZW1lbnRzIGFyZSB3aXRoaW4gdGhlIEkyTlNGIHNjb3BlLg0K DQpUaGUgInJlYWN0aXZlIG9wdGlvbiwgdGhhdCBpcywgIHZlcnkgc2ltaWxhciBhcyBpdCB3b3Vs ZCBoYXBwZW4gd2l0aCB0aGUgT3BlbkZsb3cgUGFja2V0SW4gbWVzc2FnZSBhbmQgdGhlbiBQYWNr ZXRPdXQiIGlzIG5vdCBpbiB0aGUgSTJOU0Ygc2NvcGUuIEhvd2V2ZXIsIHRoZSBzcGVjaWZ5aW5n IHRoZSBkYXRhIG1vZGVsIGZvciB0aGUgcG9saWN5IHRvIHRoZSBjb250cm9sbGVyIG9uIHdoaWNo IGZsb3dzIHRvIGJlIHByb3RlY3RlZCBieSBJUFNlYyB0dW5uZWwgc2hvdWxkIGJlIGluIHRoZSBJ Mk5TRiBzY29wZS4NCg0KT3RoZXIgY29tbWVudHMgYXJlIGluc2VydGVkIGJlbG93DQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJhZmEgTWFyaW4gTG9wZXogW21haWx0bzpy YWZhQHVtLmVzXQ0KU2VudDogU3VuZGF5LCBKdW5lIDE5LCAyMDE2IDE6MDYgUE0NClRvOiBMaW5k YSBEdW5iYXINCkNjOiBSYWZhIE1hcmluIExvcGV6OyBJMk5TRkBpZXRmLm9yZzsgSVBzZWNAaWV0 Zi5vcmc7IFNvd21pbmkgVmFyYWRoYW47IFNvd21pbmkgVmFyYWRoYW4NClN1YmplY3Q6IFJlOiBb SVBzZWNdIFtJMm5zZl0gSG93IGRvZXMgT3ZlcmxheSBOZXR3b3JrIGluZm9ybSB0aGUgVW5kZXJs YXkgbmV0d29yayBvbiB3aGljaCBmbG93cyBhbW9uZyBPdmVybGF5IG5ldHdvcmsgbm9kZXMgbmVl ZCB0byBnbyB0aHJvdWdoIElQU2VjIFR1bm5lbD8gKHdhcyA6IEZsb3cgU2VjdXJpdHkgUG9saWNp ZXMgZXhjaGFuZ2VkIG92ZXIgSTJOU0Ygc2VydmljZSBsYXllciBpbnRlcmZhY2U/DQoNCjxzbmlw Pg0KPg0KPiAtIFNlY3Rpb24gOC4xOiBQYWdlIDExOiBCdWxsZXQgMToNCj4gWW91IHN0YXRlZCB0 aGF0IHRoZSBub2RlIHNlbmRzIHRoZSBmaXJzdCBwYWNrZXQgdG8gQ29udHJvbGxlciBmb3IgdGhl IGNvbnRyb2xsZXIgdG8gZGV0ZXJtaW5lIGlmIHRoZSB0cmFmZmljIG5lZWRzIHRvIGdvIHRocm91 Z2ggSVBTZWMgdHVubmVsLg0KPg0KPiBTaG91bGRuJ3QgdGhlIGNvbnRyb2xsZXIgZ2V0IGZsb3cg cHJvdGVjdGlvbiBwb2xpY3kgZnJvbSBjbGllbnRzIChub3J0aCBib3VuZCBpbnRlcmZhY2UpIGFu ZCBpbmZvcm0gdGhlIG5lZWRlZCBlbmQgbm9kZXMgb24gd2hhdCB0cmFmZmljL2Zsb3dzIG5lZWQg dG8gZ28gdGhyb3VnaCB0aGUgSVBTZWMgdHVubmVsPw0KDQpbUmFmYV0gQWN0dWFsbHksIHRoZXJl IGFyZSB0d28gb3B0aW9ucy4gVGhlIG9uZSBzaG93biBpbiB0aGUgSS1EIGlzIHJlYWN0aXZlLCB0 aGF0IGlzLCAgdmVyeSBzaW1pbGFyIGFzIGl0IHdvdWxkIGhhcHBlbiB3aXRoIHRoZSBPcGVuRmxv dyBQYWNrZXRJbiBtZXNzYWdlIGFuZCB0aGVuIFBhY2tldE91dC4gVGhlIG90aGVyIG9wdGlvbiwg b2YgY291cnNlLCBpdCBpcyB0byBjcmVhdGUgdGhlIHJ1bGVzIGluIHRoZSBuZXR3b3JrIHJlc291 cmNlIGV2ZW4gd2hlbiB0cmFmZmljIGhhcyBub3QgYmVlbiBvYnNlcnZlZCB5ZXQgKHByb2FjdGl2 ZSkuIEJvdGggb3B0aW9ucyBhcmUgY29tcGxldGVseSBwb3NzaWJsZS4gV2UgY2FuIGNsYXJpZnkg dGhpcyBpbiB0aGUgbmV4dCB2ZXJzaW9uLg0KDQpbTGluZGFdIHNvIHRoZSBJMk5TRiBzaG91bGQg b25seSBmb2N1cyBvbiBzcGVjaWZ5aW5nIHRoZSBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGZv ciB0aGUg4oCcUHJvdGVjdGl2ZeKAnSBtZXRob2RzLiBNYXliZSBwYXJ0IG9mIHlvdXIgZHJhZnQg Y2FuIGJlIGZ1cnRoZXIgZGV2ZWxvcGVkIGluIEkyTlNGIFdHLg0KDQo+DQo+DQo+IC0gU2VjdGlv biA4LjE6IFBhZ2UgMTI6IEJ1bGxldCAzOg0KPiBUaGUgY29udHJvbGxlciBjYW4ndCByZWFsbHkg ZW5mb3JjZSB0aGUgcnVsZS4gYnV0IGluc3RlYWQgcmVxdWVzdGluZyB0aGUgIkVuZCBOb2RlIiB0 byBlbmNhcHN1bGF0ZSB0aGUgSVBTZWMgdHVubmVsIGFyb3VuZCB0aGUgZmxvd3MgdGhhdCBuZWVk IHRvIGJlIHRocm91Z2ggdGhlIElQU2VjIHR1bm5lbC4gY29ycmVjdD8NCg0KW1JhZmFdIE5vdCBz dXJlIHdoeSB5b3UgdGhpbmsgdGhlIGNvbnRyb2xsZXIgY2Fu4oCZdCBlbmZvcmNlIHRoZSBydWxl LiBCYXNpY2FsbHkgdGhlIHN0ZXAgMyBzYXlzIHRoZSBjb250cm9sbGVyIGlzIGZpbGxpbmcgYSBT QUQgZW50cnkgd2l0aG91dCB0aGUgbmVlZCBvZiBydW5uaW5nIElLRSBiZXR3ZWVuIG5ldHdvcmsg cmVzb3VyY2VzLg0KDQpbTGluZGFdIEFyZSB5b3UgYXNzdW1pbmcgdGhhdCBkYXRhIHBhY2tldHMg YWN0dWFsbHkgdHJhdmVyc2luZyB0aGUg4oCcQ29udHJvbGxlcuKAnT8gSWYgeWVzLCB0aGUgSTJO U0YgZm9jdXMgb24gdGhlIGZsb3cgcG9saWN5IG5vcnRoIGJvdW5kIHRvIHRoZSBjb250cm9sbGVy Lg0KDQoNCg0KPg0KPiAtIFNlY3Rpb24gNiwgUGFnZSA3LCBTZWNvbmQgcGFyYWdyYXBoIGFmdGVy IHRoZSBGaWd1cmUgMjoNCj4gVGhlIENvbnRyb2xsZXIgc2hvdWxkIHNlbmQgdGhlIElQU2VjIHR1 bm5lbCByZXF1ZXN0IHRvIHRoZSBlbmQgcG9pbnRzIG9mIHRoZSBkZXNpcmVkIElQU2VjIHR1bm5l bC4gQWxzbyB0aGUgY29udHJvbGxlciBzaG91bGQgc2VuZCBxdWVyeSB0byB0aGUgZW5kIHBvaW50 IHRvIGNoZWNrIGlmIHRoZXkgaGF2ZSB0aGUgbmVlZGVkIHJlc291cmNlIHRvIGVzdGFibGlzaCB0 aGUgZGVzaXJlZCBJUFNlYyB0dW5uZWwuDQoNCltSYWZhXSBXaGF0IGRvIHlvdSBtZWFuIHdpdGgg 4oCcSVBzZWMgdHVubmVsIHJlcXVlc3TigJ0/IEJ5IHNlbmRpbmcgdGhlIGluZm9ybWF0aW9uIHJl bGF0ZWQgd2l0aCB0aGUgSVBzZWMgdHVubmVsIChlLmcuIGEgU0FEIGVudHJ5KSB0byBidWlsZCBp dCBzaG91bGQgYmUgZW5vdWdoLCBJIGd1ZXNzIHRoYXQgaXMgd2hhdCB5b3UgbWVhbiBieSB0aGF0 ICwgcmlnaHQ/Lg0KDQpbTGluZGFdIFllcy4NCg0KDQpUaGUgY29udHJvbGxlciBjYW4gb2YgY291 cnNlIHZlcmlmeSBpZiB0aGUgZW5kIHBvaW50cyBvZiB0aGUgSVBzZWMgU0EgaGF2ZSB0aGUgaW5m b3JtYXRpb24gdG8gZXN0YWJsaXNoIGFuIElQc2VjIHR1bm5lbCBhY2NvcmRpbmcgdG8gdGhlIGlu Zm9ybWF0aW9uIHRoYXQgdGhlIGNvbnRyb2xsZXIga2VlcHMuIElmIHRoZSBzdGF0ZSBpcyBub3Qg dGhlcmUgb3IgaXMgZ29pbmcgdG8gYmUgb3V0ZGF0ZWQgaXQgY2FuIGVuZm9yY2UgdGhlIGluZm9y bWF0aW9uIGFnYWluLiBBbHRlcm5hdGl2ZWx5LCB0aGUgZW5kIHBvaW50cyBjb3VsZCBhbHNvIGlu Zm9ybSB3aGVuIHNvbWV0aGluZyBpcyByZXF1aXJlZCB0byB0aGUgY29udHJvbGxlciAocmVhY3Rp dmUpIHNvIHRoZSBjb250cm9sbGVyIGNhbiBhY3QgYWNjb3JkaW5nbHkuDQoNCltMaW5kYV0gYWJv dmUgaXMgd2hhdCBJIGNhbGwg4oCccXVlcnnigJ0uIE5lZWQgdG8gZmx1c2ggb3V0IHRoZSBkZXRh aWxlZCBkYXRhIG1vZGVsIGZvciB5b3VyIElQU2VjIGNhc2UgaW4gSTJOU0YgV0cuDQoNCg0KPg0K PiAtIFNlY3Rpb24gOC4yOg0KPiBTZWNvbmQgcGFyYWdyYXBoOiBXaGVuIHRoZSB0d28gZW5kIHBv aW50cyBvZiB0aGUgbmVlZGVkIElQU2VjIHR1bm5lbCBhcmUgaW4gdHdvIGRpZmZlcmVudCBJU1Bz IChzYXkgSVNQLUEgYW5kIElTUC1CKSwgeW91ciBkcmFmdCBzdGF0ZXMgdGhhdCB0aGUgSVNQLUEg Y29udHJvbGxlciBoYXMgdG8gbmVnb3RpYXRlIHdpdGggSVNQLUIgY29udHJvbGxlciBvbiB0aGUg RmxvdyBTZWN1cml0eSBwb2xpY3kgcnVsZXMuIFdoYXQgaW5mb3JtYXRpb24gd2lsbCBiZSBjYXJy aWVkIGJ5IHRob3NlIFBvbGljeSBSdWxlcz8gU2luY2UgSTJOU0YgaXMgdG8gc3BlY2lmeSB0aGUg ZGF0YSBtb2RlbHMgZm9yIHRob3NlIHJ1bGVzLCBpdCB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwgdG8g aWRlbnRpZnkgdGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdlZCBmaXJzdC4NCg0KW1JhZmFdIFdlIGNh biBzcGVjaWZ5IGJldHRlciB3aGF0IGluZm9ybWF0aW9uIGluIHRoZSBmb2xsb3dpbmcgZHJhZnQu IEJ1dCBiYXNpY2FsbHkgd2UgaGF2ZSB0d28gbW9kZWxzIGV4cGxhaW5lZCBpbiB0aGUgZHJhZnQg d2hlbiAxKSBJS0UgaXMgaW1wbGVtZW50ZWQgaW4gdGhlIG5ldHdvcmsgcmVzb3VyY2Ugb3Igd2hl biBJS0UgaXMgbm90IGltcGxlbWVudGVkIGluIHRoZSBuZXR3b3JrIHJlc291cmNlLg0KDQpJbiAx KSBwYXJhbWV0ZXJzIHRvIHJ1biBhbiBJS0UgU0EgYmV0d2VlbiBHVzEgYW5kIEdXMiBtdXN0IGJl IG5lZ290aWF0ZWQgKElLRSBjcmVkZW50aWFsLCBjcnlwdG9ncmFwaGljIHN1aXRlLCBldGPigKYp IGFuZCB0aGUgZGlmZmVyZW50IFNQRCBlbnRyaWVzIG9mIHRoZSBTUEQgdGhhdCBhcHBseS4gQW4g U1BEIGVudHJ5IGhhcyBwYXJhbWV0ZXJzIHN1Y2ggYXMgUmVtb3RlIElQIEFkZHJlc3MsIExvY2Fs IElQIEFkZHJlc3MsIE5leHQgTGF5ZXIgUHJvdG9jb2wsIE5hbWUsIExvY2FsIGFuZCBSZW1vdGUg UG9ydHMuDQoNCkluIDIpIGFwYXJ0IGZyb20gU1BEIGVudHJpZXMgeW91IG5lZWQgdG8gY29uZmln dXJlIFNBRCBlbnRyaWVzLiBUaGlzIGluZm9ybWF0aW9uIGltcGxpZXMgU2VjdXJpdHkgUGFyYW1l dGVyIEluZGV4LCBTZXF1ZW5jZSBOdW1iZXIsIEFIIGluZm9ybWF0aW9uIChrZXlzICwga2V5IGxp ZmV0aW1lKSAsIEVTUCBpbmZvcm1hdGlvbuKApiBldGMuDQoNCldlIGNhbiBkZXRhaWwgd2hhdCBp bmZvcm1hdGlvbiBpcyByZXF1aXJlZC4NCg0KW0xpbmRhXSB0aGF0IHdpbGwgYmUgdXNlZnVsLiBD YW4geW91IHdyaXRlIHRoaXMgZGV0YWlsZWQgaW5mb3JtYXRpb24gZXhjaGFuZ2UgZm9yIEkyTlNG Pw0KDQoNCj4NCj4gUGFnZSAxMzogYnVsbGV0IDI6IGJlZm9yZSB0aGUgbmVnb3RpYXRpb24gYmV0 d2VlbiB0aGUgdHdvIGNvbnRyb2xsZXJzIG9uIHRoZSBTUEQgcG9saWNpZXMgYW5kIElLRSBjcmVk ZW50aWFscywgZG9uJ3QgeW91IHRoaW5rIHRoYXQgdGhleSBuZWVkIHRvIGlucXVpcmUgZWFjaCBv dGhlciBpZiB0aGUgb3RoZXIgcGFydHkgaGFzIHRoZSBuZWVkZWQgcmVzb3VyY2UgZm9yIHRoZSBu ZWVkZWQgSVBzZWMgdHVubmVsPw0KDQpbUmFmYV0gQnV0IGZvciB0aGF0LCB3aGF0IGtpbmQgb2Yg cGFyYW1ldGVycyBkbyB5b3Ugc2VuZCB0byBhc2sgdGhlIHF1ZXN0aW9uPyBJIGNhbiBpbWFnaW5l IHlvdSBjb3VsZCBhc2sgOiBkbyB5b3UgaGF2ZSBhbiBlbmQgcG9pbnQgd2l0aCB0aGlzIElQIGFk ZHJlc3MsIElLRSBzdXBwb3J0LCBBSCBvciBFU1Agc3VwcG9ydOKApiBldGPigKY/IElzIHRoYXQg d2hhdCB5b3UgaGF2ZSBpbiBtaW5kPw0KDQpJbiBhbnkgY2FzZSwgaWYgdGhleSBkbyBub3QgaGF2 ZSB0aGF0IHN1cHBvcnQgdHJ5aW5nIHRoZSBuZWdvdGlhdGlvbiBiZXR3ZWVuIHRoZSB0d28gY29u dHJvbGxlcnMgd291bGQgZmFpbCBzbyB0aGF0IHlvdSB3b3VsZCBub3RpY2UgdGhhdCB0aGUgbmVl ZGVkIHJlc291cmNlIGlzIG5vdCBhdmFpbGFibGUgYXMgd2VsbCwgcmlnaHQ/DQoNCg0KW0xpbmRh XSBjb3JyZWN0Lg0KDQpUaGFua3MsIExpbmRhDQoNCg0KDQoNCkJlc3QgUmVnYXJkcy4NCj4NCj4N Cj4NCj4gVGhhbmtzLCBMaW5kYQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBSYWZhIE1hcmluIExvcGV6IFttYWlsdG86cmFmYUB1bS5lc10NCj4gU2VudDogRnJpZGF5 LCBKdW5lIDE3LCAyMDE2IDc6NDMgQU0NCj4gVG86IExpbmRhIER1bmJhcg0KPiBDYzogUmFmYSBN YXJpbiBMb3BlejsgU293bWluaSBWYXJhZGhhbjsgSTJOU0ZAaWV0Zi5vcmc8bWFpbHRvOkkyTlNG QGlldGYub3JnPjsgU293bWluaQ0KPiBWYXJhZGhhbjsgTlZPMzsgTGl5aXpob3UNCj4gU3ViamVj dDogUmU6IFtJMm5zZl0gSG93IGRvZXMgT3ZlcmxheSBOZXR3b3JrIGluZm9ybSB0aGUgVW5kZXJs YXkgbmV0d29yayBvbiB3aGljaCBmbG93cyBhbW9uZyBPdmVybGF5IG5ldHdvcmsgbm9kZXMgbmVl ZCB0byBnbyB0aHJvdWdoIElQU2VjIFR1bm5lbD8gKHdhcyA6IEZsb3cgU2VjdXJpdHkgUG9saWNp ZXMgZXhjaGFuZ2VkIG92ZXIgSTJOU0Ygc2VydmljZSBsYXllciBpbnRlcmZhY2U/DQo+DQo+IERl YXIgYWxsOg0KPg0KPiBNYXliZSB0aGlzIEktRCBtaWdodCBiZSBpbnRlcmVzdGluZyBhbmQgcmVs YXRlZCB3aXRoIHRoaXMgZGlzY3Vzc2lvbiByZWdhcmRpbmcgSVBzZWMvSUtFIG1hbmFnZW1lbnQu IFdlIGhvcGUgdG8gaGF2ZSBhbiB1cGRhdGVkIHZlcnNpb24gc29vbiBhbmQgYSBwcm9vZi1vZi1j b25jZXB0IGltcGxlbWVudGF0aW9uIG9mIHNvbWUgb2YgdGhlIHNjZW5hcmlvcy4NCj4NCj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWFiYWQtc2Rucmctc2RuLWlwc2VjLWZsb3ct cHJvdGVjdGlvbg0KPiAtMDENCj4NCj4gQmVzdCBSZWdhcmRzLg0KPg0KPg0KPiA+IEVsIDE3IGp1 biAyMDE2LCBhIGxhcyAxMDo0MywgTGluZGEgRHVuYmFyIDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNv bTxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+PiBlc2NyaWJpw7M6DQo+ID4NCj4gPiBT b3dtaW5pLA0KPiA+DQo+ID4gWW91IHNhaWQ6DQo+ID4g4oCcSG93ZXZlciwgYXBwbHlpbmcgSVBz ZWMgdG8gc3BlY2lmaWMgZmxvd3MgKGUuZy4sIHRob3NlIGRlZmluZWQgYnkgYSBzcmMgb3IgZHN0 IHBvcnQgb24gd2hpY2ggdGhlIHNlcnZpY2UgbGlzdGVucykgaXMgaW1wb3J0YW50LuKAnQ0KPiA+ DQo+ID4gV2hhdCBpcyB0aGUgY3VycmVudCBvcGVyYXRpb24gcHJvY2VkdXJlIGZvciBPdmVybGF5 IG5ldHdvcmsgdG8gaW5mb3JtIHRoZSB1bmRlcmxheSBuZXR3b3JrIG9uIHdoaWNoIGZsb3dzIHRv IGdvIHRocm91Z2ggSVBTZWMgY2hhbm5lbD8NCj4gPg0KPiA+IFlvdSBzYWlkOg0KPiA+IOKAnC4u QnV0IHRoYXQgYWxzbyBtYWRlIG1lIHdvbmRlciBhYm91dCB0aGUgaW50ZXJhY3Rpb24gYmV0d2Vl biBJUHNlYy9JS0UgYW5kIHRoZSBwcm9wb3NlZCBCR1AgRlMgKElQc2VjIGlzIGZyZXF1ZW50bHkg dXNlZCBiZXR3ZWVuIGVuZC1zeXN0ZW1zIHRoYXQgZG8gbm90IHdhbnQgdG8gcnVuIGEgQkdQIGRh ZW1vbikuIFNpbmNlIHRoZSBjb25maWcgaW5mb3JtYXRpb24gdGhhdCBuZWVkcyB0byBiZSBkaXN0 cmlidXRlZCBhcmUgdGhpbmdzIGxpa2Uga2V5cywgYWxnb3JpdGhtcyBldGMgdG8gcG9wdWxhdGUg dGhlIHNhZGIvc3BkLCBJS0UgbG9va3MgbW9yZSBhcHByb3ByaWF0ZSBpbiBtb3N0IGNhc2VzLuKA nQ0KPiA+DQo+ID4NCj4gPiBEb2VzIHRoZSB1bmRlcmxheSBuZXR3b3JrIGNvbnRyb2xsZXIgZ2V0 IHNvbWUgaW5mb3JtYXRpb24gKG9yIGhpbnQgZnJvbSB0aGUgT3ZlcmxheSBuZXR3b3JrIGNvbnRy b2xsZXIpIG9uIGhvdyB0aGUga2V5cyBhcmUgY29uZmlndXJlZCBmb3IgdGhlIElQU2VjIHR1bm5l bCBmb3IgdGhlIHNwZWNpZmljIGZsb3dzIGFtb25nIHRoZSBPdmVybGF5IG5vZGVzPw0KPiA+DQo+ ID4NCj4gPiBUaGFua3MsDQo+ID4gTGluZGENCj4gPg0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBTb3dtaW5pIFZhcmFkaGFuIFttYWlsdG86c293bWluaTA1 QGdtYWlsLmNvbV0NCj4gPiBTZW50OiBUaHVyc2RheSwgSnVuZSAxNiwgMjAxNiAxMDo1NyBBTQ0K PiA+IFRvOiBMaW5kYSBEdW5iYXINCj4gPiBDYzogTGl5aXpob3U7IE5WTzM7IFNvd21pbmkgVmFy YWRoYW4NCj4gPiBTdWJqZWN0OiBSZTogW252bzNdIEZXOiBBbnkgdXNlIGNhc2VzIG9mIE92ZXJs YXkgbmV0d29yayByZXF1ZXN0aW5nIElQU2VjIGNvbm5lY3Rpb24gZnJvbSB0aGUgVW5kZXJsYXkg Zm9yIGEgc3BlY2lmaWMgdGltZSBzcGFuPyAod2FzIDogRmxvdyBTZWN1cml0eSBQb2xpY2llcyBl eGNoYW5nZWQgb3ZlciBJMk5TRiBzZXJ2aWNlIGxheWVyIGludGVyZmFjZT8NCj4gPg0KPiA+IE9u IFdlZCwgSnVuIDE1LCAyMDE2IGF0IDg6NTUgQU0sIExpbmRhIER1bmJhciA8bGluZGEuZHVuYmFy QGh1YXdlaS5jb208bWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPj4gd3JvdGU6DQo+ID4g Pg0KPiA+ID4gTlZPMyBQYXJ0aWNpcGFudHMsDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBJ Mk5TRiAoSW50ZXJmYWNlIHRvIE5ldHdvcmsgU2VjdXJpdHkgZnVuY3Rpb24pIGhhcyBhIHdvcmsg aXRlbSBpbiBkZWZpbmluZyB0aGUgZmxvdyBzZWN1cml0eSBwb2xpY3kgYmV0d2VlbiBkb21haW5z ICh3aGljaCBpbmNsdWRlcyBpbnF1aXJ5IG9mIHRoZSBjYXBhYmlsaXR5IGZyb20gb25lIGRvbWFp biB0byBhbm90aGVyIGFuZCB0aGUgYWN0dWFsIGZsb3cgcG9saWN5IHJ1bGVzIGZyb20gb25lIGRv bWFpbiB0byBhbm90aGVyKS4NCj4gPiA+DQo+ID4gPiBWZXJ5IG9mdGVuLCB0aGUgcGF0aHMgKG9y IGxpbmtzKSBhbW9uZyBub2RlcyBvZiBhIG92ZXJsYXkgbmV0d29yayBhcmUgcHJvdmlkZWQgYnkg b3RoZXIgbmV0d29yayBvcGVyYXRvcnMgKGEuay5hLiDigJx1bmRlcmxheSBuZXR3b3Jr4oCdKS4g IFRoZSBmbG93IHBvbGljeSBydWxlcyBhcmUgaW50ZW5kZWQgdG8gZmlsdGVyIG91dCB1bndhbnRl ZCB0cmFmZmljIGZyb20gdW5kZXJsYXkgbmV0d29yayBzbyB0aGF0IHZhcmlvdXMgYXR0YWNrIHRy YWZmaWMgd29u4oCZdCBzYXR1cmF0ZWQgdGhlIGFjY2VzcyBsaW5rcyB0byB0aGUgb3ZlcmxheSBu b2Rlcy4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IE9uZSBpbnRlcmVzdGluZyBzY2VuYXJp byBicm91Z2h0IHVwIGlzIE92ZXJsYXkgbm9kZXMgbWF5IG5lZWQgdG8gcmVxdWVzdCBzb21lIHRy YWZmaWMgdG8gYmUgdHJhdmVyc2luZyBJUHNlYyBjaGFubmVsLiBUbyBhY2hpZXZlIHRoaXMgZ29h bCwgaXQgaXMgbmVjZXNzYXJ5IGZvciBPdmVybGF5IE5ldHdvcmsgY29udHJvbGxlciB0byBpbnF1 aXJlIGlmIHRoZSBuZWVkZWQgSVBzZWMgcmVzb3VyY2UgYXJlIGV2ZW4gYXZhaWxhYmxlIGJlZm9y ZSBzZW5kIHRoZSByZXF1ZXN0IChtYXkgZXZlbiBpbnZvbHZlIEFBQSBwcm9jZXNzIGJldHdlZW4g Y29udHJvbGxlcnMgb2YgZWFjaCBjb3JyZXNwb25kaW5nIGRvbWFpbiApLg0KPiA+ID4NCj4gPiA+ DQo+ID4gPg0KPiA+ID4gV2FudCB0byBoYXZlIGEgc3VydmV5IGlmIHBlb3BsZSBzZWUgdGhlIHVz ZSBjYXNlIG9mIE92ZXJsYXkgTmV0d29yayBuZWVkaW5nIHBvcnRpb24gb2YgdHJhZmZpYyB0byBi ZSB0aHJvdWdoIElQU2VjIGNoYW5uZWw/DQo+ID4NCj4gPiBZZXMsIHRoaXMgaXMgYSB2YWxpZCB1 c2UgY2FzZSwgYW5kIG9uZSB0aGF0IHdlICBhcmUgbG9va2luZyBhdCBhcyB3ZWxsLg0KPiA+DQo+ ID4gPiBJUFNlYyBpcyBzdXBwb3NlZCB0byBiZSBiZXR3ZWVuIHR3byBlbmQgbm9kZXMuIEhlcmUg d2UgYXNzdW1lIHRoYXQgdGhlIE92ZXJsYXkgbm9kZXMgZG9u4oCZdCBoYXZlIHRoZSByZXNvdXJj ZSBvciBjYXBhYmlsaXR5IGZvciBJUHNlYywgYnV0IGV4cGVjdCBJUHNlYyBiZXR3ZWVuIGZsb3fi gJlzIGluZ3Jlc3MgYW5kIGVncmVzcyBub2RlcyAoaS5lLiBOVkUpLg0KPiA+ID4gQW55IG9waW5p b24gaXMgYXBwcmVjaWF0ZWQuDQo+ID4NCj4gPg0KPiA+ID4NCj4gPiA+IEFyZSB0aGVyZSBhbnkg dXNlIGNhc2VzIG9mIG92ZXJsYXkgbmV0d29yayBuZWVkaW5nIElQU2VjIGFtb25nIHRoZWlyIG5v ZGVzIG9ubHkgZm9yIGEgc3BlY2lmaWMgdGltZSBzcGFuPyBpLmUuIFRpbWUgYmFzZWQgSVBTZWMg Y29ubmVjdGlvbj8NCj4gPg0KPiA+IFRpbWUgYmFzZWQgSVBzZWMgY29ubmVjdGlvbiBpcyBub3Qg YSB1c2UtY2FzZSB3ZSBoYXZlIGVuY291bnRlcmVkLg0KPiA+IFBlb3BsZSB1c3VhbGx5IHVzZSBJ S0UgZm9yIHBlcmlvZGljIGtleS1yb2xsb3ZlciwgaWYgdGhhdCBpcyB0aGUgZ29hbC4NCj4gPg0K PiA+IEhvd2V2ZXIsIGFwcGx5aW5nIElQc2VjIHRvIHNwZWNpZmljIGZsb3dzIChlLmcuLCB0aG9z ZSBkZWZpbmVkIGJ5IGEgc3JjIG9yIGRzdCBwb3J0IG9uIHdoaWNoIHRoZSBzZXJ2aWNlIGxpc3Rl bnMpIGlzIGltcG9ydGFudC4NCj4gPg0KPiA+IEJ1dCB0aGF0IGFsc28gbWFkZSBtZSB3b25kZXIg YWJvdXQgdGhlIGludGVyYWN0aW9uIGJldHdlZW4gSVBzZWMvSUtFIGFuZCB0aGUgcHJvcG9zZWQg QkdQIEZTIChJUHNlYyBpcyBmcmVxdWVudGx5IHVzZWQgYmV0d2VlbiBlbmQtc3lzdGVtcyB0aGF0 IGRvIG5vdCB3YW50IHRvIHJ1biBhIEJHUCBkYWVtb24pLiBTaW5jZSB0aGUgY29uZmlnIGluZm9y bWF0aW9uIHRoYXQgbmVlZHMgdG8gYmUgZGlzdHJpYnV0ZWQgYXJlIHRoaW5ncyBsaWtlIGtleXMs IGFsZ29yaXRobXMgZXRjIHRvIHBvcHVsYXRlIHRoZSBzYWRiL3NwZCwgSUtFIGxvb2tzIG1vcmUg YXBwcm9wcmlhdGUgaW4gbW9zdCBjYXNlcy4NCj4gPg0KPiA+IExpa2UgW0NKXSwgSSB0b28gaGF2 ZSB0byByZWFkIHRoZSBkcmFmdCBpbiBncmVhdGVyIGRldGFpbCB0byBjb21tZW50IGZ1cnRoZXIu DQo+ID4NCj4gPiAtLVNvd21pbmkNCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gSTJuc2YgbWFpbGluZyBsaXN0DQo+ID4gSTJuc2ZA aWV0Zi5vcmc8bWFpbHRvOkkybnNmQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaTJuc2YNCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBSYWZhZWwgTWFyaW4gTG9wZXosIFBoRA0K PiBEZXB0LiBJbmZvcm1hdGlvbiBhbmQgQ29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcgKERJSUMp IEZhY3VsdHkgb2YNCj4gQ29tcHV0ZXIgU2NpZW5jZS1Vbml2ZXJzaXR5IG9mIE11cmNpYQ0KPiAz MDEwMCBNdXJjaWEgLSBTcGFpbg0KPiBUZWxmOiArMzQ4Njg4ODg1MDEgRmF4OiArMzQ4Njg4ODQx NTEgZS1tYWlsOiByYWZhQHVtLmVzPG1haWx0bzpyYWZhQHVtLmVzPg0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+DQo+DQo+DQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElQ c2VjIG1haWxpbmcgbGlzdA0KPiBJUHNlY0BpZXRmLm9yZzxtYWlsdG86SVBzZWNAaWV0Zi5vcmc+ DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUmFmYWVs IE1hcmluIExvcGV6LCBQaEQNCkRlcHQuIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBF bmdpbmVlcmluZyAoRElJQykgRmFjdWx0eSBvZiBDb21wdXRlciBTY2llbmNlLVVuaXZlcnNpdHkg b2YgTXVyY2lhDQozMDEwMCBNdXJjaWEgLSBTcGFpbg0KVGVsZjogKzM0ODY4ODg4NTAxIEZheDog KzM0ODY4ODg0MTUxIGUtbWFpbDogcmFmYUB1bS5lczxtYWlsdG86cmFmYUB1bS5lcz4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoN Cg0KDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657ECCD0Edfweml501mbb_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+DQo8ZGl2PlJhZmEsIDwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+SSBzZWUgdGhhdCB5b3VyIGRy YWZ0IGhhcyBpZGVudGlmaWVkIG11bHRpcGxlIGNhc2VzIG9mIFNETiBjb250cm9sbGVkIElQU2Vj IHR1bm5lbC4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5BcyBJMk5TRiBmb2N1cyBv biBzcGVjaWZ5aW5nIHRoZSBkYXRhIG1vZGVscyBmb3IgdGhlIEZsb3cgU2VjdXJpdHkgUG9saWNp ZXMsIHRoZSBjb250cm9sbGVyICZxdW90O1Byb2FjdGl2ZWx5JnF1b3Q7IHNldHRpbmcgdXAgdGhl IElQU2VjIHBvbGljZXMva2V5cyB0byBuZXR3b3JrIGVsZW1lbnRzIGFyZSB3aXRoaW4gdGhlIEky TlNGIHNjb3BlLiA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PlRoZSAmcXVvdDtyZWFj dGl2ZSBvcHRpb24sIHRoYXQgaXMsJm5ic3A7IHZlcnkgc2ltaWxhciBhcyBpdCB3b3VsZCBoYXBw ZW4gd2l0aCB0aGUgT3BlbkZsb3cgUGFja2V0SW4gbWVzc2FnZSBhbmQgdGhlbiBQYWNrZXRPdXQm cXVvdDsgaXMgbm90IGluIHRoZSBJMk5TRiBzY29wZS4gSG93ZXZlciwgdGhlIHNwZWNpZnlpbmcg dGhlIGRhdGEgbW9kZWwgZm9yIHRoZSBwb2xpY3kgdG8gdGhlIGNvbnRyb2xsZXIgb24gd2hpY2gg Zmxvd3MgdG8gYmUgcHJvdGVjdGVkIGJ5DQpJUFNlYyB0dW5uZWwgc2hvdWxkIGJlIGluIHRoZSBJ Mk5TRiBzY29wZS4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5PdGhlciBjb21tZW50 cyBhcmUgaW5zZXJ0ZWQgYmVsb3c8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsiPiZuYnNwOzwvc3Bh bj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0i MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCg0KRnJvbTogUmFmYSBN YXJpbiBMb3BleiBbPGEgaHJlZj0ibWFpbHRvOnJhZmFAdW0uZXMiPm1haWx0bzpyYWZhQHVtLmVz PC9hPl0gPGJyPg0KDQpTZW50OiBTdW5kYXksIEp1bmUgMTksIDIwMTYgMTowNiBQTTxicj4NCg0K VG86IExpbmRhIER1bmJhcjxicj4NCg0KQ2M6IFJhZmEgTWFyaW4gTG9wZXo7IEkyTlNGQGlldGYu b3JnOyBJUHNlY0BpZXRmLm9yZzsgU293bWluaSBWYXJhZGhhbjsgU293bWluaSBWYXJhZGhhbjxi cj4NCg0KU3ViamVjdDogUmU6IFtJUHNlY10gW0kybnNmXSBIb3cgZG9lcyBPdmVybGF5IE5ldHdv cmsgaW5mb3JtIHRoZSBVbmRlcmxheSBuZXR3b3JrIG9uIHdoaWNoIGZsb3dzIGFtb25nIE92ZXJs YXkgbmV0d29yayBub2RlcyBuZWVkIHRvIGdvIHRocm91Z2ggSVBTZWMgVHVubmVsPyAod2FzIDog RmxvdyBTZWN1cml0eSBQb2xpY2llcyBleGNoYW5nZWQgb3ZlciBJMk5TRiBzZXJ2aWNlIGxheWVy IGludGVyZmFjZT88L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXpl PSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+ PC9kaXY+DQo8ZGl2PiZsdDtzbmlwJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7IDwvZGl2Pg0K PGRpdj4mZ3Q7IC0gU2VjdGlvbiA4LjE6IFBhZ2UgMTE6IEJ1bGxldCAxOjwvZGl2Pg0KPGRpdj4m Z3Q7IFlvdSBzdGF0ZWQgdGhhdCB0aGUgbm9kZSBzZW5kcyB0aGUgZmlyc3QgcGFja2V0IHRvIENv bnRyb2xsZXIgZm9yIHRoZSBjb250cm9sbGVyIHRvIGRldGVybWluZSBpZiB0aGUgdHJhZmZpYyBu ZWVkcyB0byBnbyB0aHJvdWdoIElQU2VjIHR1bm5lbC4gPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsg PC9kaXY+DQo8ZGl2PiZndDsgU2hvdWxkbid0IHRoZSBjb250cm9sbGVyIGdldCBmbG93IHByb3Rl Y3Rpb24gcG9saWN5IGZyb20gY2xpZW50cyAobm9ydGggYm91bmQgaW50ZXJmYWNlKSBhbmQgaW5m b3JtIHRoZSBuZWVkZWQgZW5kIG5vZGVzIG9uIHdoYXQgdHJhZmZpYy9mbG93cyBuZWVkIHRvIGdv IHRocm91Z2ggdGhlIElQU2VjIHR1bm5lbD88L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2 PltSYWZhXSBBY3R1YWxseSwgdGhlcmUgYXJlIHR3byBvcHRpb25zLiBUaGUgb25lIHNob3duIGlu IHRoZSBJLUQgaXMgcmVhY3RpdmUsIHRoYXQgaXMsJm5ic3A7IHZlcnkgc2ltaWxhciBhcyBpdCB3 b3VsZCBoYXBwZW4gd2l0aCB0aGUgT3BlbkZsb3cgUGFja2V0SW4gbWVzc2FnZSBhbmQgdGhlbiBQ YWNrZXRPdXQuIFRoZSBvdGhlciBvcHRpb24sIG9mIGNvdXJzZSwgaXQgaXMgdG8gY3JlYXRlIHRo ZSBydWxlcyBpbiB0aGUgbmV0d29yayByZXNvdXJjZQ0KZXZlbiB3aGVuIHRyYWZmaWMgaGFzIG5v dCBiZWVuIG9ic2VydmVkIHlldCAocHJvYWN0aXZlKS4gQm90aCBvcHRpb25zIGFyZSBjb21wbGV0 ZWx5IHBvc3NpYmxlLiBXZSBjYW4gY2xhcmlmeSB0aGlzIGluIHRoZSBuZXh0IHZlcnNpb24uPC9k aXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj5b TGluZGFdIHNvIHRoZSBJMk5TRiBzaG91bGQgb25seSBmb2N1cyBvbiBzcGVjaWZ5aW5nIHRoZSBw cm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGZvciB0aGUg4oCcUHJvdGVjdGl2ZeKAnSBtZXRob2Rz LiBNYXliZSBwYXJ0IG9mIHlvdXIgZHJhZnQgY2FuIGJlIGZ1cnRoZXIgZGV2ZWxvcGVkIGluIEky TlNGIFdHLiA8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIy Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQo8ZGl2PiZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2 PiZndDsgLSBTZWN0aW9uIDguMTogUGFnZSAxMjogQnVsbGV0IDM6PC9kaXY+DQo8ZGl2PiZndDsg VGhlIGNvbnRyb2xsZXIgY2FuJ3QgcmVhbGx5IGVuZm9yY2UgdGhlIHJ1bGUuIGJ1dCBpbnN0ZWFk IHJlcXVlc3RpbmcgdGhlICZxdW90O0VuZCBOb2RlJnF1b3Q7IHRvIGVuY2Fwc3VsYXRlIHRoZSBJ UFNlYyB0dW5uZWwgYXJvdW5kIHRoZSBmbG93cyB0aGF0IG5lZWQgdG8gYmUgdGhyb3VnaCB0aGUg SVBTZWMgdHVubmVsLiBjb3JyZWN0PzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+W1Jh ZmFdIE5vdCBzdXJlIHdoeSB5b3UgdGhpbmsgdGhlIGNvbnRyb2xsZXIgY2Fu4oCZdCBlbmZvcmNl IHRoZSBydWxlLiBCYXNpY2FsbHkgdGhlIHN0ZXAgMyBzYXlzIHRoZSBjb250cm9sbGVyIGlzIGZp bGxpbmcgYSBTQUQgZW50cnkgd2l0aG91dCB0aGUgbmVlZCBvZiBydW5uaW5nIElLRSBiZXR3ZWVu IG5ldHdvcmsgcmVzb3VyY2VzLjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyI+Jm5ic3A7PC9zcGFu PjwvZm9udD48L2Rpdj4NCjxkaXY+W0xpbmRhXSBBcmUgeW91IGFzc3VtaW5nIHRoYXQgZGF0YSBw YWNrZXRzIGFjdHVhbGx5IHRyYXZlcnNpbmcgdGhlIOKAnENvbnRyb2xsZXLigJ0/IElmIHllcywg dGhlIEkyTlNGIGZvY3VzIG9uIHRoZSBmbG93IHBvbGljeSBub3J0aCBib3VuZCB0byB0aGUgY29u dHJvbGxlci4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2PiZndDsmbmJz cDsgPC9kaXY+DQo8ZGl2PiZndDsgLSBTZWN0aW9uIDYsIFBhZ2UgNywgU2Vjb25kIHBhcmFncmFw aCBhZnRlciB0aGUgRmlndXJlIDI6IDwvZGl2Pg0KPGRpdj4mZ3Q7IFRoZSBDb250cm9sbGVyIHNo b3VsZCBzZW5kIHRoZSBJUFNlYyB0dW5uZWwgcmVxdWVzdCB0byB0aGUgZW5kIHBvaW50cyBvZiB0 aGUgZGVzaXJlZCBJUFNlYyB0dW5uZWwuIEFsc28gdGhlIGNvbnRyb2xsZXIgc2hvdWxkIHNlbmQg cXVlcnkgdG8gdGhlIGVuZCBwb2ludCB0byBjaGVjayBpZiB0aGV5IGhhdmUgdGhlIG5lZWRlZCBy ZXNvdXJjZSB0byBlc3RhYmxpc2ggdGhlIGRlc2lyZWQgSVBTZWMgdHVubmVsLjwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+W1JhZmFdIFdoYXQgZG8geW91IG1lYW4gd2l0aCDigJxJUHNl YyB0dW5uZWwgcmVxdWVzdOKAnT8gQnkgc2VuZGluZyB0aGUgaW5mb3JtYXRpb24gcmVsYXRlZCB3 aXRoIHRoZSBJUHNlYyB0dW5uZWwgKGUuZy4gYSBTQUQgZW50cnkpIHRvIGJ1aWxkIGl0IHNob3Vs ZCBiZSBlbm91Z2gsIEkgZ3Vlc3MgdGhhdCBpcyB3aGF0IHlvdSBtZWFuIGJ5IHRoYXQgLCByaWdo dD8uPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0K PGRpdj5bTGluZGFdIFllcy4gPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21h biIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Ij4mbmJzcDs8L3NwYW4+ PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rp dj4NCjxkaXY+VGhlIGNvbnRyb2xsZXIgY2FuIG9mIGNvdXJzZSB2ZXJpZnkgaWYgdGhlIGVuZCBw b2ludHMgb2YgdGhlIElQc2VjIFNBIGhhdmUgdGhlIGluZm9ybWF0aW9uIHRvIGVzdGFibGlzaCBh biBJUHNlYyB0dW5uZWwgYWNjb3JkaW5nIHRvIHRoZSBpbmZvcm1hdGlvbiB0aGF0IHRoZSBjb250 cm9sbGVyIGtlZXBzLiBJZiB0aGUgc3RhdGUgaXMgbm90IHRoZXJlIG9yIGlzIGdvaW5nIHRvIGJl IG91dGRhdGVkIGl0IGNhbiBlbmZvcmNlIHRoZSBpbmZvcm1hdGlvbg0KYWdhaW4uIEFsdGVybmF0 aXZlbHksIHRoZSBlbmQgcG9pbnRzIGNvdWxkIGFsc28gaW5mb3JtIHdoZW4gc29tZXRoaW5nIGlz IHJlcXVpcmVkIHRvIHRoZSBjb250cm9sbGVyIChyZWFjdGl2ZSkgc28gdGhlIGNvbnRyb2xsZXIg Y2FuIGFjdCBhY2NvcmRpbmdseS48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJv bWFuIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsiPiZuYnNwOzwvc3Bh bj48L2ZvbnQ+PC9kaXY+DQo8ZGl2PltMaW5kYV0gYWJvdmUgaXMgd2hhdCBJIGNhbGwg4oCccXVl cnnigJ0uIE5lZWQgdG8gZmx1c2ggb3V0IHRoZSBkZXRhaWxlZCBkYXRhIG1vZGVsIGZvciB5b3Vy IElQU2VjIGNhc2UgaW4gSTJOU0YgV0cuIDwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyI+Jm5ic3A7 PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBz aXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsiPiZuYnNwOzwvc3Bhbj48L2Zv bnQ+PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDsgLSBTZWN0aW9uIDgu MjogPC9kaXY+DQo8ZGl2PiZndDsgU2Vjb25kIHBhcmFncmFwaDogV2hlbiB0aGUgdHdvIGVuZCBw b2ludHMgb2YgdGhlIG5lZWRlZCBJUFNlYyB0dW5uZWwgYXJlIGluIHR3byBkaWZmZXJlbnQgSVNQ cyAoc2F5IElTUC1BIGFuZCBJU1AtQiksIHlvdXIgZHJhZnQgc3RhdGVzIHRoYXQgdGhlIElTUC1B IGNvbnRyb2xsZXIgaGFzIHRvIG5lZ290aWF0ZSB3aXRoIElTUC1CIGNvbnRyb2xsZXIgb24gdGhl IEZsb3cgU2VjdXJpdHkgcG9saWN5IHJ1bGVzLiBXaGF0IGluZm9ybWF0aW9uDQp3aWxsIGJlIGNh cnJpZWQgYnkgdGhvc2UgUG9saWN5IFJ1bGVzPyBTaW5jZSBJMk5TRiBpcyB0byBzcGVjaWZ5IHRo ZSBkYXRhIG1vZGVscyBmb3IgdGhvc2UgcnVsZXMsIGl0IHdvdWxkIGJlIHZlcnkgaGVscGZ1bCB0 byBpZGVudGlmeSB0aGUgaW5mb3JtYXRpb24gZXhjaGFuZ2VkIGZpcnN0LiA8L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2PltSYWZhXSBXZSBjYW4gc3BlY2lmeSBiZXR0ZXIgd2hhdCBpbmZv cm1hdGlvbiBpbiB0aGUgZm9sbG93aW5nIGRyYWZ0LiBCdXQgYmFzaWNhbGx5IHdlIGhhdmUgdHdv IG1vZGVscyBleHBsYWluZWQgaW4gdGhlIGRyYWZ0IHdoZW4gMSkgSUtFIGlzIGltcGxlbWVudGVk IGluIHRoZSBuZXR3b3JrIHJlc291cmNlIG9yIHdoZW4gSUtFIGlzIG5vdCBpbXBsZW1lbnRlZCBp biB0aGUgbmV0d29yayByZXNvdXJjZS4mbmJzcDsgPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PGRpdj5JbiAxKSBwYXJhbWV0ZXJzIHRvIHJ1biBhbiBJS0UgU0EgYmV0d2VlbiBHVzEgYW5kIEdX MiBtdXN0IGJlIG5lZ290aWF0ZWQgKElLRSBjcmVkZW50aWFsLCBjcnlwdG9ncmFwaGljIHN1aXRl LCBldGPigKYpIGFuZCB0aGUgZGlmZmVyZW50IFNQRCBlbnRyaWVzIG9mIHRoZSBTUEQgdGhhdCBh cHBseS4gQW4gU1BEIGVudHJ5IGhhcyBwYXJhbWV0ZXJzIHN1Y2ggYXMgUmVtb3RlIElQIEFkZHJl c3MsIExvY2FsIElQIEFkZHJlc3MsIE5leHQgTGF5ZXINClByb3RvY29sLCBOYW1lLCBMb2NhbCBh bmQgUmVtb3RlIFBvcnRzLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SW4gMikgYXBh cnQgZnJvbSBTUEQgZW50cmllcyB5b3UgbmVlZCB0byBjb25maWd1cmUgU0FEIGVudHJpZXMuIFRo aXMgaW5mb3JtYXRpb24gaW1wbGllcyBTZWN1cml0eSBQYXJhbWV0ZXIgSW5kZXgsIFNlcXVlbmNl IE51bWJlciwgQUggaW5mb3JtYXRpb24gKGtleXMgLCBrZXkgbGlmZXRpbWUpICwgRVNQIGluZm9y bWF0aW9u4oCmIGV0Yy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PldlIGNhbiBkZXRh aWwgd2hhdCBpbmZvcm1hdGlvbiBpcyByZXF1aXJlZC48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0i VGltZXMgTmV3IFJvbWFuIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsi PiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2PltMaW5kYV0gdGhhdCB3aWxsIGJlIHVz ZWZ1bC4gQ2FuIHlvdSB3cml0ZSB0aGlzIGRldGFpbGVkIGluZm9ybWF0aW9uIGV4Y2hhbmdlIGZv ciBJMk5TRj8gPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0i MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+ Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyBQYWdlIDEzOiBidWxsZXQgMjogYmVmb3JlIHRo ZSBuZWdvdGlhdGlvbiBiZXR3ZWVuIHRoZSB0d28gY29udHJvbGxlcnMgb24gdGhlIFNQRCBwb2xp Y2llcyBhbmQgSUtFIGNyZWRlbnRpYWxzLCBkb24ndCB5b3UgdGhpbmsgdGhhdCB0aGV5IG5lZWQg dG8gaW5xdWlyZSBlYWNoIG90aGVyIGlmIHRoZSBvdGhlciBwYXJ0eSBoYXMgdGhlIG5lZWRlZCBy ZXNvdXJjZSBmb3IgdGhlIG5lZWRlZCBJUHNlYyB0dW5uZWw/IDwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxkaXY+W1JhZmFdIEJ1dCBmb3IgdGhhdCwgd2hhdCBraW5kIG9mIHBhcmFtZXRlcnMg ZG8geW91IHNlbmQgdG8gYXNrIHRoZSBxdWVzdGlvbj8gSSBjYW4gaW1hZ2luZSB5b3UgY291bGQg YXNrIDogZG8geW91IGhhdmUgYW4gZW5kIHBvaW50IHdpdGggdGhpcyBJUCBhZGRyZXNzLCBJS0Ug c3VwcG9ydCwgQUggb3IgRVNQIHN1cHBvcnTigKYgZXRj4oCmPyBJcyB0aGF0IHdoYXQgeW91IGhh dmUgaW4gbWluZD88L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkluIGFueSBjYXNlLCBp ZiB0aGV5IGRvIG5vdCBoYXZlIHRoYXQgc3VwcG9ydCB0cnlpbmcgdGhlIG5lZ290aWF0aW9uIGJl dHdlZW4gdGhlIHR3byBjb250cm9sbGVycyB3b3VsZCBmYWlsIHNvIHRoYXQgeW91IHdvdWxkIG5v dGljZSB0aGF0IHRoZSBuZWVkZWQgcmVzb3VyY2UgaXMgbm90IGF2YWlsYWJsZSBhcyB3ZWxsLCBy aWdodD88L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIyIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+ DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj5bTGlu ZGFdIGNvcnJlY3QuIDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+VGhhbmtzLCBMaW5k YTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iIHNpemU9IjIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxk aXY+QmVzdCBSZWdhcmRzLjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7 Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7IFRoYW5rcywg TGluZGE8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTwvZGl2Pg0KPGRpdj4mZ3Q7IEZyb206IFJhZmEgTWFyaW4gTG9wZXog WzxhIGhyZWY9Im1haWx0bzpyYWZhQHVtLmVzIj5tYWlsdG86cmFmYUB1bS5lczwvYT5dPC9kaXY+ DQo8ZGl2PiZndDsgU2VudDogRnJpZGF5LCBKdW5lIDE3LCAyMDE2IDc6NDMgQU08L2Rpdj4NCjxk aXY+Jmd0OyBUbzogTGluZGEgRHVuYmFyPC9kaXY+DQo8ZGl2PiZndDsgQ2M6IFJhZmEgTWFyaW4g TG9wZXo7IFNvd21pbmkgVmFyYWRoYW47IDxhIGhyZWY9Im1haWx0bzpJMk5TRkBpZXRmLm9yZyI+ STJOU0ZAaWV0Zi5vcmc8L2E+OyBTb3dtaW5pIDwvZGl2Pg0KPGRpdj4mZ3Q7IFZhcmFkaGFuOyBO Vk8zOyBMaXlpemhvdTwvZGl2Pg0KPGRpdj4mZ3Q7IFN1YmplY3Q6IFJlOiBbSTJuc2ZdIEhvdyBk b2VzIE92ZXJsYXkgTmV0d29yayBpbmZvcm0gdGhlIFVuZGVybGF5IG5ldHdvcmsgb24gd2hpY2gg Zmxvd3MgYW1vbmcgT3ZlcmxheSBuZXR3b3JrIG5vZGVzIG5lZWQgdG8gZ28gdGhyb3VnaCBJUFNl YyBUdW5uZWw/ICh3YXMgOiBGbG93IFNlY3VyaXR5IFBvbGljaWVzIGV4Y2hhbmdlZCBvdmVyIEky TlNGIHNlcnZpY2UgbGF5ZXIgaW50ZXJmYWNlPzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7IDwvZGl2 Pg0KPGRpdj4mZ3Q7IERlYXIgYWxsOjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRp dj4mZ3Q7IE1heWJlIHRoaXMgSS1EIG1pZ2h0IGJlIGludGVyZXN0aW5nIGFuZCByZWxhdGVkIHdp dGggdGhpcyBkaXNjdXNzaW9uIHJlZ2FyZGluZyBJUHNlYy9JS0UgbWFuYWdlbWVudC4gV2UgaG9w ZSB0byBoYXZlIGFuIHVwZGF0ZWQgdmVyc2lvbiBzb29uIGFuZCBhIHByb29mLW9mLWNvbmNlcHQg aW1wbGVtZW50YXRpb24gb2Ygc29tZSBvZiB0aGUgc2NlbmFyaW9zLjwvZGl2Pg0KPGRpdj4mZ3Q7 Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1hYmFkLXNkbnJnLXNkbi1pcHNlYy1mbG93LXByb3RlY3Rpb24iPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hYmFkLXNkbnJnLXNkbi1pcHNlYy1mbG93LXByb3Rl Y3Rpb248L2E+PC9kaXY+DQo8ZGl2PiZndDsgLTAxPC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsgPC9k aXY+DQo8ZGl2PiZndDsgQmVzdCBSZWdhcmRzLjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7IDwvZGl2 Pg0KPGRpdj4mZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgRWwgMTcganVuIDIwMTYs IGEgbGFzIDEwOjQzLCBMaW5kYSBEdW5iYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsaW5kYS5kdW5i YXJAaHVhd2VpLmNvbSI+bGluZGEuZHVuYmFyQGh1YXdlaS5jb208L2E+Jmd0OyBlc2NyaWJpw7M6 PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IFNvd21pbmksPC9k aXY+DQo8ZGl2PiZndDsgJmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IFlvdSBzYWlk OjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsg4oCcSG93ZXZlciwgYXBwbHlpbmcgSVBzZWMgdG8gc3Bl Y2lmaWMgZmxvd3MgKGUuZy4sIHRob3NlIGRlZmluZWQgYnkgYSBzcmMgb3IgZHN0IHBvcnQgb24g d2hpY2ggdGhlIHNlcnZpY2UgbGlzdGVucykgaXMgaW1wb3J0YW50LuKAnTwvZGl2Pg0KPGRpdj4m Z3Q7ICZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBXaGF0IGlzIHRoZSBjdXJyZW50 IG9wZXJhdGlvbiBwcm9jZWR1cmUgZm9yIE92ZXJsYXkgbmV0d29yayB0byBpbmZvcm0gdGhlIHVu ZGVybGF5IG5ldHdvcmsgb24gd2hpY2ggZmxvd3MgdG8gZ28gdGhyb3VnaCBJUFNlYyBjaGFubmVs PyA8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgWW91 IHNhaWQ6IDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsg4oCcLi5CdXQgdGhhdCBhbHNvIG1hZGUgbWUg d29uZGVyIGFib3V0IHRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIElQc2VjL0lLRSBhbmQgdGhlIHBy b3Bvc2VkIEJHUCBGUyAoSVBzZWMgaXMgZnJlcXVlbnRseSB1c2VkIGJldHdlZW4gZW5kLXN5c3Rl bXMgdGhhdCBkbyBub3Qgd2FudCB0byBydW4gYSBCR1AgZGFlbW9uKS4gU2luY2UgdGhlIGNvbmZp ZyBpbmZvcm1hdGlvbiB0aGF0IG5lZWRzIHRvIGJlIGRpc3RyaWJ1dGVkIGFyZSB0aGluZ3MNCmxp a2Uga2V5cywgYWxnb3JpdGhtcyBldGMgdG8gcG9wdWxhdGUgdGhlIHNhZGIvc3BkLCBJS0UgbG9v a3MgbW9yZSBhcHByb3ByaWF0ZSBpbiBtb3N0IGNhc2VzLuKAnTwvZGl2Pg0KPGRpdj4mZ3Q7ICZn dDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyAm Z3Q7IERvZXMgdGhlIHVuZGVybGF5IG5ldHdvcmsgY29udHJvbGxlciBnZXQgc29tZSBpbmZvcm1h dGlvbiAob3IgaGludCBmcm9tIHRoZSBPdmVybGF5IG5ldHdvcmsgY29udHJvbGxlcikgb24gaG93 IHRoZSBrZXlzIGFyZSBjb25maWd1cmVkIGZvciB0aGUgSVBTZWMgdHVubmVsIGZvciB0aGUgc3Bl Y2lmaWMgZmxvd3MgYW1vbmcgdGhlIE92ZXJsYXkgbm9kZXM/IDwvZGl2Pg0KPGRpdj4mZ3Q7ICZn dDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyAm Z3Q7IFRoYW5rcyw8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IExpbmRhPC9kaXY+DQo8ZGl2PiZndDsg Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7 ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IEZy b206IFNvd21pbmkgVmFyYWRoYW4gWzxhIGhyZWY9Im1haWx0bzpzb3dtaW5pMDVAZ21haWwuY29t Ij5tYWlsdG86c293bWluaTA1QGdtYWlsLmNvbTwvYT5dPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBT ZW50OiBUaHVyc2RheSwgSnVuZSAxNiwgMjAxNiAxMDo1NyBBTTwvZGl2Pg0KPGRpdj4mZ3Q7ICZn dDsgVG86IExpbmRhIER1bmJhcjwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgQ2M6IExpeWl6aG91OyBO Vk8zOyBTb3dtaW5pIFZhcmFkaGFuPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBTdWJqZWN0OiBSZTog W252bzNdIEZXOiBBbnkgdXNlIGNhc2VzIG9mIE92ZXJsYXkgbmV0d29yayByZXF1ZXN0aW5nIElQ U2VjIGNvbm5lY3Rpb24gZnJvbSB0aGUgVW5kZXJsYXkgZm9yIGEgc3BlY2lmaWMgdGltZSBzcGFu PyAod2FzIDogRmxvdyBTZWN1cml0eSBQb2xpY2llcyBleGNoYW5nZWQgb3ZlciBJMk5TRiBzZXJ2 aWNlIGxheWVyIGludGVyZmFjZT88L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7Jm5ic3A7IDwvZGl2Pg0K PGRpdj4mZ3Q7ICZndDsgT24gV2VkLCBKdW4gMTUsIDIwMTYgYXQgODo1NSBBTSwgTGluZGEgRHVu YmFyICZsdDs8YSBocmVmPSJtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20iPmxpbmRhLmR1 bmJhckBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7IE5WTzMgUGFydGljaXBhbnRzLDwvZGl2Pg0KPGRp dj4mZ3Q7ICZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OzwvZGl2Pg0KPGRpdj4m Z3Q7ICZndDsgJmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0OyBJMk5TRiAoSW50ZXJmYWNl IHRvIE5ldHdvcmsgU2VjdXJpdHkgZnVuY3Rpb24pIGhhcyBhIHdvcmsgaXRlbSBpbiBkZWZpbmlu ZyB0aGUgZmxvdyBzZWN1cml0eSBwb2xpY3kgYmV0d2VlbiBkb21haW5zICh3aGljaCBpbmNsdWRl cyBpbnF1aXJ5IG9mIHRoZSBjYXBhYmlsaXR5IGZyb20gb25lIGRvbWFpbiB0byBhbm90aGVyIGFu ZCB0aGUgYWN0dWFsIGZsb3cgcG9saWN5IHJ1bGVzIGZyb20gb25lIGRvbWFpbiB0byBhbm90aGVy KS48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsg VmVyeSBvZnRlbiwgdGhlIHBhdGhzIChvciBsaW5rcykgYW1vbmcgbm9kZXMgb2YgYSBvdmVybGF5 IG5ldHdvcmsgYXJlIHByb3ZpZGVkIGJ5IG90aGVyIG5ldHdvcmsgb3BlcmF0b3JzIChhLmsuYS4g 4oCcdW5kZXJsYXkgbmV0d29ya+KAnSkuJm5ic3A7IFRoZSBmbG93IHBvbGljeSBydWxlcyBhcmUg aW50ZW5kZWQgdG8gZmlsdGVyIG91dCB1bndhbnRlZCB0cmFmZmljIGZyb20gdW5kZXJsYXkgbmV0 d29yayBzbyB0aGF0IHZhcmlvdXMgYXR0YWNrDQp0cmFmZmljIHdvbuKAmXQgc2F0dXJhdGVkIHRo ZSBhY2Nlc3MgbGlua3MgdG8gdGhlIG92ZXJsYXkgbm9kZXMuPC9kaXY+DQo8ZGl2PiZndDsgJmd0 OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAm Z3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7IE9uZSBpbnRlcmVzdGluZyBzY2VuYXJpbyBi cm91Z2h0IHVwIGlzIE92ZXJsYXkgbm9kZXMgbWF5IG5lZWQgdG8gcmVxdWVzdCBzb21lIHRyYWZm aWMgdG8gYmUgdHJhdmVyc2luZyBJUHNlYyBjaGFubmVsLiBUbyBhY2hpZXZlIHRoaXMgZ29hbCwg aXQgaXMgbmVjZXNzYXJ5IGZvciBPdmVybGF5IE5ldHdvcmsgY29udHJvbGxlciB0byBpbnF1aXJl IGlmIHRoZSBuZWVkZWQgSVBzZWMgcmVzb3VyY2UgYXJlIGV2ZW4gYXZhaWxhYmxlDQpiZWZvcmUg c2VuZCB0aGUgcmVxdWVzdCAobWF5IGV2ZW4gaW52b2x2ZSBBQUEgcHJvY2VzcyBiZXR3ZWVuIGNv bnRyb2xsZXJzIG9mIGVhY2ggY29ycmVzcG9uZGluZyBkb21haW4gKS48L2Rpdj4NCjxkaXY+Jmd0 OyAmZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAm Z3Q7ICZndDs8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7ICZndDsgV2FudCB0byBoYXZlIGEgc3VydmV5 IGlmIHBlb3BsZSBzZWUgdGhlIHVzZSBjYXNlIG9mIE92ZXJsYXkgTmV0d29yayBuZWVkaW5nIHBv cnRpb24gb2YgdHJhZmZpYyB0byBiZSB0aHJvdWdoIElQU2VjIGNoYW5uZWw/PC9kaXY+DQo8ZGl2 PiZndDsgJmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IFllcywgdGhpcyBpcyBhIHZh bGlkIHVzZSBjYXNlLCBhbmQgb25lIHRoYXQgd2UmbmJzcDsgYXJlIGxvb2tpbmcgYXQgYXMgd2Vs bC48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgJmd0 OyBJUFNlYyBpcyBzdXBwb3NlZCB0byBiZSBiZXR3ZWVuIHR3byBlbmQgbm9kZXMuIEhlcmUgd2Ug YXNzdW1lIHRoYXQgdGhlIE92ZXJsYXkgbm9kZXMgZG9u4oCZdCBoYXZlIHRoZSByZXNvdXJjZSBv ciBjYXBhYmlsaXR5IGZvciBJUHNlYywgYnV0IGV4cGVjdCBJUHNlYyBiZXR3ZWVuIGZsb3figJlz IGluZ3Jlc3MgYW5kIGVncmVzcyBub2RlcyAoaS5lLiBOVkUpLjwvZGl2Pg0KPGRpdj4mZ3Q7ICZn dDsgJmd0OyBBbnkgb3BpbmlvbiBpcyBhcHByZWNpYXRlZC48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7 Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZndDsgJmd0 OyAmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgJmd0OyAmZ3Q7IEFyZSB0aGVyZSBhbnkgdXNlIGNhc2Vz IG9mIG92ZXJsYXkgbmV0d29yayBuZWVkaW5nIElQU2VjIGFtb25nIHRoZWlyIG5vZGVzIG9ubHkg Zm9yIGEgc3BlY2lmaWMgdGltZSBzcGFuPyBpLmUuIFRpbWUgYmFzZWQgSVBTZWMgY29ubmVjdGlv bj88L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgVGlt ZSBiYXNlZCBJUHNlYyBjb25uZWN0aW9uIGlzIG5vdCBhIHVzZS1jYXNlIHdlIGhhdmUgZW5jb3Vu dGVyZWQuPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyBQZW9wbGUgdXN1YWxseSB1c2UgSUtFIGZvciBw ZXJpb2RpYyBrZXktcm9sbG92ZXIsIGlmIHRoYXQgaXMgdGhlIGdvYWwuPC9kaXY+DQo8ZGl2PiZn dDsgJmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IEhvd2V2ZXIsIGFwcGx5aW5nIElQ c2VjIHRvIHNwZWNpZmljIGZsb3dzIChlLmcuLCB0aG9zZSBkZWZpbmVkIGJ5IGEgc3JjIG9yIGRz dCBwb3J0IG9uIHdoaWNoIHRoZSBzZXJ2aWNlIGxpc3RlbnMpIGlzIGltcG9ydGFudC48L2Rpdj4N CjxkaXY+Jmd0OyAmZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgQnV0IHRoYXQgYWxz byBtYWRlIG1lIHdvbmRlciBhYm91dCB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiBJUHNlYy9JS0Ug YW5kIHRoZSBwcm9wb3NlZCBCR1AgRlMgKElQc2VjIGlzIGZyZXF1ZW50bHkgdXNlZCBiZXR3ZWVu IGVuZC1zeXN0ZW1zIHRoYXQgZG8gbm90IHdhbnQgdG8gcnVuIGEgQkdQIGRhZW1vbikuIFNpbmNl IHRoZSBjb25maWcgaW5mb3JtYXRpb24gdGhhdCBuZWVkcyB0byBiZSBkaXN0cmlidXRlZCBhcmUg dGhpbmdzIGxpa2UNCmtleXMsIGFsZ29yaXRobXMgZXRjIHRvIHBvcHVsYXRlIHRoZSBzYWRiL3Nw ZCwgSUtFIGxvb2tzIG1vcmUgYXBwcm9wcmlhdGUgaW4gbW9zdCBjYXNlcy48L2Rpdj4NCjxkaXY+ Jmd0OyAmZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgTGlrZSBbQ0pdLCBJIHRvbyBo YXZlIHRvIHJlYWQgdGhlIGRyYWZ0IGluIGdyZWF0ZXIgZGV0YWlsIHRvIGNvbW1lbnQgZnVydGhl ci48L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7ICZndDsgLS1T b3dtaW5pPC9kaXY+DQo8ZGl2PiZndDsgJmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9kaXY+DQo8 ZGl2PiZndDsgJmd0OyBJMm5zZiBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxkaXY+Jmd0OyAmZ3Q7IDxh IGhyZWY9Im1haWx0bzpJMm5zZkBpZXRmLm9yZyI+STJuc2ZAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8 ZGl2PiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2kybnNmIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kybnNmPC9h PjwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7IDwvZGl2Pg0KPGRpdj4mZ3Q7IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2Rpdj4NCjxkaXY+Jmd0 OyBSYWZhZWwgTWFyaW4gTG9wZXosIFBoRDwvZGl2Pg0KPGRpdj4mZ3Q7IERlcHQuIEluZm9ybWF0 aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBFbmdpbmVlcmluZyAoRElJQykgRmFjdWx0eSBvZiA8L2Rp dj4NCjxkaXY+Jmd0OyBDb21wdXRlciBTY2llbmNlLVVuaXZlcnNpdHkgb2YgTXVyY2lhPC9kaXY+ DQo8ZGl2PiZndDsgMzAxMDAgTXVyY2lhIC0gU3BhaW48L2Rpdj4NCjxkaXY+Jmd0OyBUZWxmOiAm IzQzOzM0ODY4ODg4NTAxIEZheDogJiM0MzszNDg2ODg4NDE1MSBlLW1haWw6IDxhIGhyZWY9Im1h aWx0bzpyYWZhQHVtLmVzIj5yYWZhQHVtLmVzPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2Rpdj4NCjxk aXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyZu YnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyA8L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyA8L2Rp dj4NCjxkaXY+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzwvZGl2Pg0KPGRpdj4mZ3Q7IElQc2VjIG1haWxpbmcgbGlzdDwvZGl2Pg0KPGRpdj4mZ3Q7 IDxhIGhyZWY9Im1haWx0bzpJUHNlY0BpZXRmLm9yZyI+SVBzZWNAaWV0Zi5vcmc8L2E+PC9kaXY+ DQo8ZGl2PiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pcHNlYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYzwvYT48 L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2 Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 L2Rpdj4NCjxkaXY+UmFmYWVsIE1hcmluIExvcGV6LCBQaEQ8L2Rpdj4NCjxkaXY+RGVwdC4gSW5m b3JtYXRpb24gYW5kIENvbW11bmljYXRpb25zIEVuZ2luZWVyaW5nIChESUlDKSBGYWN1bHR5IG9m IENvbXB1dGVyIFNjaWVuY2UtVW5pdmVyc2l0eSBvZiBNdXJjaWE8L2Rpdj4NCjxkaXY+MzAxMDAg TXVyY2lhIC0gU3BhaW48L2Rpdj4NCjxkaXY+VGVsZjogJiM0MzszNDg2ODg4ODUwMSBGYXg6ICYj NDM7MzQ4Njg4ODQxNTEgZS1tYWlsOiA8YSBocmVmPSJtYWlsdG86cmFmYUB1bS5lcyI+cmFmYUB1 bS5lczwvYT48L2Rpdj4NCjxkaXY+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+PGZvbnQg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L3NwYW4+PC9mb250Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_4A95BA014132FF49AE685FAB4B9F17F657ECCD0Edfweml501mbb_-- From nobody Wed Jun 22 08:26:23 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E485B12DAAD; Wed, 22 Jun 2016 08:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqsfVXxDtAaN; Wed, 22 Jun 2016 08:26:19 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 49F4612DD2A; Wed, 22 Jun 2016 08:13:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 0D991369C; Wed, 22 Jun 2016 17:13:19 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ki-3vXPs4+N0; Wed, 22 Jun 2016 17:13:18 +0200 (CEST) Received: from eduroam_um-6-253.inf.um.es (eduroam_um-6-253.inf.um.es [155.54.6.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id 0862B3687; Wed, 22 Jun 2016 17:13:16 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657ECCD0E@dfweml501-mbb> Date: Wed, 22 Jun 2016 17:13:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <466D704F-4C9B-45FB-AE68-841896D29B72@um.es> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <7C1028FB-4531-4BA8-9C64-AE933945539F@um.es> <4A95BA014132FF49AE685FAB4B9F17F657ECCD0E@dfweml501-mbb> To: Linda Dunbar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "I2NSF@ietf.org" , "IPsec@ietf.org" , Sowmini Varadhan , Rafa Marin Lopez , Sowmini Varadhan Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 15:26:23 -0000 Hi Linda: > El 20 jun 2016, a las 15:41, Linda Dunbar = escribi=C3=B3: >=20 > Rafa,=20 > =20 > I see that your draft has identified multiple cases of SDN controlled = IPSec tunnel.=20 > =20 > As I2NSF focus on specifying the data models for the Flow Security = Policies, the controller "Proactively" setting up the IPSec polices/keys = to network elements are within the I2NSF scope.=20 I see. > =20 > The "reactive option, that is, very similar as it would happen with = the OpenFlow PacketIn message and then PacketOut" is not in the I2NSF = scope. However, the specifying the data model for the policy to the = controller on which flows to be protected by IPSec tunnel should be in = the I2NSF scope. Please be aware that some reactive (upon an event) behavior may be = required even when the controller sets up the IPsec policies/keys = proactively. For example, the PF_KEY interface (RFC 2367) in the kernel = has an =E2=80=9Cevent=E2=80=9D "The SADB_EXPIRE message is sent from the kernel to key management applications when the "soft lifetime" or "hard lifetime" of a Security Association has expired. Key management applications should use receipt of a soft lifetime SADB_EXPIRE message as a hint to negotiate a replacement SA so the replacement SA will be ready and in the kernel before it is needed.=E2=80=9D This is a kind of asynchronous event, which is important because it = allows the controller to react and update the SAs. Is this kind of event = in the I2NSF scope?=20 In any case we are going to modify the I-D to show all these aspects. Some comments inline: > =20 > =20 > Other comments are inserted below > =20 > =20 > -----Original Message----- > From: Rafa Marin Lopez [mailto:rafa@um.es]=20 > Sent: Sunday, June 19, 2016 1:06 PM > To: Linda Dunbar > Cc: Rafa Marin Lopez; I2NSF@ietf.org; IPsec@ietf.org; Sowmini = Varadhan; Sowmini Varadhan > Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the = Underlay network on which flows among Overlay network nodes need to go = through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF = service layer interface? > =20 > > > =20 > > - Section 8.1: Page 11: Bullet 1: > > You stated that the node sends the first packet to Controller for = the controller to determine if the traffic needs to go through IPSec = tunnel.=20 > > =20 > > Shouldn't the controller get flow protection policy from clients = (north bound interface) and inform the needed end nodes on what = traffic/flows need to go through the IPSec tunnel? > =20 > [Rafa] Actually, there are two options. The one shown in the I-D is = reactive, that is, very similar as it would happen with the OpenFlow = PacketIn message and then PacketOut. The other option, of course, it is = to create the rules in the network resource even when traffic has not = been observed yet (proactive). Both options are completely possible. We = can clarify this in the next version. > =20 > [Linda] so the I2NSF should only focus on specifying the protocols and = data models for the =E2=80=9CProtective=E2=80=9D methods. Maybe part of = your draft can be further developed in I2NSF WG.=20 > =20 > > =20 > > =20 > > - Section 8.1: Page 12: Bullet 3: > > The controller can't really enforce the rule. but instead requesting = the "End Node" to encapsulate the IPSec tunnel around the flows that = need to be through the IPSec tunnel. correct? > =20 > [Rafa] Not sure why you think the controller can=E2=80=99t enforce the = rule. Basically the step 3 says the controller is filling a SAD entry = without the need of running IKE between network resources. > =20 > [Linda] Are you assuming that data packets actually traversing the = =E2=80=9CController=E2=80=9D? If yes, the I2NSF focus on the flow policy = north bound to the controller.=20 [Rafa] It is not traverse but it is to check the first data packet in a = flow to see there is need for security or not. But certainly that = belongs to southbound interface. > =20 > =20 > =20 > > =20 > > - Section 6, Page 7, Second paragraph after the Figure 2:=20 > > The Controller should send the IPSec tunnel request to the end = points of the desired IPSec tunnel. Also the controller should send = query to the end point to check if they have the needed resource to = establish the desired IPSec tunnel. > =20 > [Rafa] What do you mean with =E2=80=9CIPsec tunnel request=E2=80=9D? = By sending the information related with the IPsec tunnel (e.g. a SAD = entry) to build it should be enough, I guess that is what you mean by = that , right?. > =20 > [Linda] Yes.=20 > =20 > =20 > The controller can of course verify if the end points of the IPsec SA = have the information to establish an IPsec tunnel according to the = information that the controller keeps. If the state is not there or is = going to be outdated it can enforce the information again. = Alternatively, the end points could also inform when something is = required to the controller (reactive) so the controller can act = accordingly. > =20 > [Linda] above is what I call =E2=80=9Cquery=E2=80=9D. Need to flush = out the detailed data model for your IPSec case in I2NSF WG.=20 > =20 > =20 > > =20 > > - Section 8.2:=20 > > Second paragraph: When the two end points of the needed IPSec tunnel = are in two different ISPs (say ISP-A and ISP-B), your draft states that = the ISP-A controller has to negotiate with ISP-B controller on the Flow = Security policy rules. What information will be carried by those Policy = Rules? Since I2NSF is to specify the data models for those rules, it = would be very helpful to identify the information exchanged first.=20 > =20 > [Rafa] We can specify better what information in the following draft. = But basically we have two models explained in the draft when 1) IKE is = implemented in the network resource or when IKE is not implemented in = the network resource. =20 > =20 > In 1) parameters to run an IKE SA between GW1 and GW2 must be = negotiated (IKE credential, cryptographic suite, etc=E2=80=A6) and the = different SPD entries of the SPD that apply. An SPD entry has parameters = such as Remote IP Address, Local IP Address, Next Layer Protocol, Name, = Local and Remote Ports. > =20 > In 2) apart from SPD entries you need to configure SAD entries. This = information implies Security Parameter Index, Sequence Number, AH = information (keys , key lifetime) , ESP information=E2=80=A6 etc. > =20 > We can detail what information is required. > =20 > [Linda] that will be useful. Can you write this detailed information = exchange for I2NSF?=20 [Rafa] We think so yes. Best Regards. > =20 > =20 > > =20 > > Page 13: bullet 2: before the negotiation between the two = controllers on the SPD policies and IKE credentials, don't you think = that they need to inquire each other if the other party has the needed = resource for the needed IPsec tunnel?=20 > =20 > [Rafa] But for that, what kind of parameters do you send to ask the = question? I can imagine you could ask : do you have an end point with = this IP address, IKE support, AH or ESP support=E2=80=A6 etc=E2=80=A6? = Is that what you have in mind? > =20 > In any case, if they do not have that support trying the negotiation = between the two controllers would fail so that you would notice that the = needed resource is not available as well, right? > =20 > =20 > [Linda] correct.=20 > =20 > Thanks, Linda > =20 > =20 > =20 > =20 > Best Regards. > > =20 > > =20 > > =20 > > Thanks, Linda > > =20 > > -----Original Message----- > > From: Rafa Marin Lopez [mailto:rafa@um.es] > > Sent: Friday, June 17, 2016 7:43 AM > > To: Linda Dunbar > > Cc: Rafa Marin Lopez; Sowmini Varadhan; I2NSF@ietf.org; Sowmini=20 > > Varadhan; NVO3; Liyizhou > > Subject: Re: [I2nsf] How does Overlay Network inform the Underlay = network on which flows among Overlay network nodes need to go through = IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service = layer interface? > > =20 > > Dear all: > > =20 > > Maybe this I-D might be interesting and related with this discussion = regarding IPsec/IKE management. We hope to have an updated version soon = and a proof-of-concept implementation of some of the scenarios. > > =20 > > = https://tools.ietf.org/html/draft-abad-sdnrg-sdn-ipsec-flow-protection > > -01 > > =20 > > Best Regards. > > =20 > > =20 > > > El 17 jun 2016, a las 10:43, Linda Dunbar = escribi=C3=B3: > > >=20 > > > Sowmini, > > > =20 > > > You said: > > > =E2=80=9CHowever, applying IPsec to specific flows (e.g., those = defined by a src or dst port on which the service listens) is = important.=E2=80=9D > > > =20 > > > What is the current operation procedure for Overlay network to = inform the underlay network on which flows to go through IPSec channel?=20= > > > =20 > > > You said:=20 > > > =E2=80=9C..But that also made me wonder about the interaction = between IPsec/IKE and the proposed BGP FS (IPsec is frequently used = between end-systems that do not want to run a BGP daemon). Since the = config information that needs to be distributed are things like keys, = algorithms etc to populate the sadb/spd, IKE looks more appropriate in = most cases.=E2=80=9D > > > =20 > > > =20 > > > Does the underlay network controller get some information (or hint = from the Overlay network controller) on how the keys are configured for = the IPSec tunnel for the specific flows among the Overlay nodes?=20 > > > =20 > > > =20 > > > Thanks, > > > Linda > > > =20 > > > =20 > > > -----Original Message----- > > > From: Sowmini Varadhan [mailto:sowmini05@gmail.com] > > > Sent: Thursday, June 16, 2016 10:57 AM > > > To: Linda Dunbar > > > Cc: Liyizhou; NVO3; Sowmini Varadhan > > > Subject: Re: [nvo3] FW: Any use cases of Overlay network = requesting IPSec connection from the Underlay for a specific time span? = (was : Flow Security Policies exchanged over I2NSF service layer = interface? > > > =20 > > > On Wed, Jun 15, 2016 at 8:55 AM, Linda Dunbar = wrote: > > > > > > > > NVO3 Participants, > > > > > > > > > > > > > > > > I2NSF (Interface to Network Security function) has a work item = in defining the flow security policy between domains (which includes = inquiry of the capability from one domain to another and the actual flow = policy rules from one domain to another). > > > > > > > > Very often, the paths (or links) among nodes of a overlay = network are provided by other network operators (a.k.a. =E2=80=9Cunderlay = network=E2=80=9D). The flow policy rules are intended to filter out = unwanted traffic from underlay network so that various attack traffic = won=E2=80=99t saturated the access links to the overlay nodes. > > > > > > > > > > > > > > > > One interesting scenario brought up is Overlay nodes may need to = request some traffic to be traversing IPsec channel. To achieve this = goal, it is necessary for Overlay Network controller to inquire if the = needed IPsec resource are even available before send the request (may = even involve AAA process between controllers of each corresponding = domain ). > > > > > > > > > > > > > > > > Want to have a survey if people see the use case of Overlay = Network needing portion of traffic to be through IPSec channel? > > > =20 > > > Yes, this is a valid use case, and one that we are looking at as = well. > > > =20 > > > > IPSec is supposed to be between two end nodes. Here we assume = that the Overlay nodes don=E2=80=99t have the resource or capability for = IPsec, but expect IPsec between flow=E2=80=99s ingress and egress nodes = (i.e. NVE). > > > > Any opinion is appreciated. > > > =20 > > > =20 > > > > > > > > Are there any use cases of overlay network needing IPSec among = their nodes only for a specific time span? i.e. Time based IPSec = connection? > > > =20 > > > Time based IPsec connection is not a use-case we have encountered. > > > People usually use IKE for periodic key-rollover, if that is the = goal. > > > =20 > > > However, applying IPsec to specific flows (e.g., those defined by = a src or dst port on which the service listens) is important. > > > =20 > > > But that also made me wonder about the interaction between = IPsec/IKE and the proposed BGP FS (IPsec is frequently used between = end-systems that do not want to run a BGP daemon). Since the config = information that needs to be distributed are things like keys, = algorithms etc to populate the sadb/spd, IKE looks more appropriate in = most cases. > > > =20 > > > Like [CJ], I too have to read the draft in greater detail to = comment further. > > > =20 > > > --Sowmini > > > =20 > > > _______________________________________________ > > > I2nsf mailing list > > > I2nsf@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2nsf > > =20 > > ------------------------------------------------------- > > Rafael Marin Lopez, PhD > > Dept. Information and Communications Engineering (DIIC) Faculty of=20= > > Computer Science-University of Murcia > > 30100 Murcia - Spain > > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > > ------------------------------------------------------- > > =20 > > =20 > > =20 > > =20 > > =20 > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > =20 > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) Faculty of = Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Wed Jun 22 09:16:18 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF5E12D931 for ; Wed, 22 Jun 2016 09:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yn3VP_bWjcWp for ; Wed, 22 Jun 2016 09:16:16 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88DA112D8DB for ; Wed, 22 Jun 2016 09:11:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rZV2Q2qbJz45s for ; Wed, 22 Jun 2016 18:11:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id FqxwJSCrwDdL for ; Wed, 22 Jun 2016 18:11:09 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 22 Jun 2016 18:11:09 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A0C3A3522C3; Wed, 22 Jun 2016 12:11:08 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca A0C3A3522C3 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 96D19406B150 for ; Wed, 22 Jun 2016 12:11:08 -0400 (EDT) Date: Wed, 22 Jun 2016 12:11:08 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] Endless stream of NAT-T keepalive probes? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 16:16:18 -0000 Hi, One of my machines is seeing a continous stream of NAT-T keepalive probes for which we have no state (and for which we had no state for days or weeks or ever). These always seem to come in sets of 3 probes at once, every 20 seconds. And oddly enough on port 500, not 4500. Containing the 1 byte 0xFF NAT-Keepalive payload. Currently offending IPs are: 87.236.232.253, 46.34.71.246 and 64.115.92.187. Small pcap entry attached. Has oneone experienced these before? Is this a known bad device? Or am I just special? :) Paul From nobody Wed Jun 22 09:19:12 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6DE12D689 for ; Wed, 22 Jun 2016 09:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKuRh6VEeiB4 for ; Wed, 22 Jun 2016 09:19:07 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0094.outbound.protection.outlook.com [23.103.200.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CDE712D7E0 for ; Wed, 22 Jun 2016 09:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EDVVQDhTri98m+U8czgqiASSHyNTr3RhJXmy+SEDZ/E=; b=zPMrYzlDD6sf29e1S6krVqXsoDxz6jdeHW5q9csBt7EKCbIW6JNdQtYHbwVw1ZIHz8f5Q3ciQVLePGWqmURrOoz8jTE04QTLlmoO8jPxClUwWM2oPiN9ma6a/x1ow4xPlTrL45+/fROAHBCyxFrDEWuJPOsWYqF2ExsUlXBFYFo= Received: from DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) by DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) with Microsoft SMTP Server (TLS) id 15.1.523.12; Wed, 22 Jun 2016 16:15:34 +0000 Received: from DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) by DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) with mapi id 15.01.0523.015; Wed, 22 Jun 2016 16:15:34 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document Thread-Index: AdG/QdJ7yDaA38r6SPqACsa9vNxuhQNXijLA Date: Wed, 22 Jun 2016 16:15:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 441710ab-ad53-43b2-c659-08d39ab870f2 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0365; 6:6XURDA66+xqlDbPpWfLlAAvZjdHK/D7LgbFb/gAKRAHgRpVK+5XvVoMqOiqmcO0h+VrOxs+rogf9eYUb14wJEAQNzGQDTAm7a2oz9FlP5RVIlQfLlePJ9gM4gXkhRJRoqIo6cVCOYukH6pOvJm0tfea1rrOJq3YmWsAOwVus+A+SrDo8zwvj4EOXJfXSjouHoFnDQVetOoXg+KooZak1t2biMds5AEN3VuhrfP8SWPcuAkmWfrp7AS6JuHNxFfXg7yObyWM8mFEzZKY5vNbZFPnrAhWWrrmv7/TUGGXsa8AjTbljcL7yO2LG9rNwiQV+ayQp9NHLo//rncatZrmnIgTmFzEZN5Z2qj83lUjZo5I=; 5:MfQc57/i/jsyMxod/qKu8fwXpcTygdVje5iWeT5v0iRoNIMlfCYYuH6DjKi9GjRMaVvV/r6aeXoLxKwRb41rDk1oKCmma3rU3Da5aovv//lPO/frLWhu1jBYIci6+bGWWu6NV0hjKjVgGzJfvHxLvw==; 24:MWm17PxMjKo++OxO8i+j58WeG2LJsM6TW2nT/NSUuAID7OBMC2iYMYTuuAgQ+pyO7ujpx1K8Qy+20lSunqzcaj5DOTPKqrGliBS+ihOi+dQ=; 7:NJ979886pDcHNlVzR7odNk4+wFI6sChqyJ22GGUM7h8BpsBg68KG0zpJv4ROmam+XN/FmeFzmp3XB95Wr0moUM1GJrkdNhm53kWWcQe53LBLTAIE0H3rNfEIB5uG2XC6KRexCZ6tyNmpx9jefMt2TfnWUr2IliTSfT9tIZgMXO41+nMEikfPfrmZ/nDPVb+V2+1F0UsysDYRMH0HSKOQb9nRNUbKNZhLo+cg0nWff5R1cmLeeQ5gVZYU55sPHctnEyaQTiK81h8qe6TN4RvQAg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0365; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DM2PR09MB0365; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0365; x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(189002)(377454003)(5002640100001)(122556002)(189998001)(87936001)(33656002)(11100500001)(81166006)(7736002)(5003600100003)(92566002)(8676002)(81156014)(7846002)(7696003)(10400500002)(106356001)(6116002)(3846002)(102836003)(586003)(76576001)(110136002)(107886002)(19580395003)(450100001)(86362001)(3900700001)(97736004)(3660700001)(3280700002)(8936002)(230783001)(9686002)(105586002)(19580405001)(2906002)(101416001)(54356999)(50986999)(15975445007)(77096005)(66066001)(74316001)(99286002)(68736007)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0365; H:DM2PR09MB0365.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 16:15:34.5327 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0365 Archived-At: Subject: Re: [IPsec] Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 16:19:11 -0000 For the adoption call on draft-pauly-ipsecme-tcp-encaps, 7 individuals resp= onded with support for adoption, with no concerns raised during the call. S= ome of these responses indicated a desire to implement the final solution, = and to provide reviews. Thank you to everyone who provided feedback. The consensus for adopting this draft as a WG document is strong in my view= . As a result, I am changing the status for the document to adopted in the= datatracker. The next revision should be posted as draft-ietf-ipsecme-tcp-= encaps-00. To move this draft forward we need more review. Are there any volunteers to= review and provide feedback on the draft in the next week or so? This will= give the editors some time to post an update prior to the July 8, 2016 dra= ft cut-off. Thanks, Dave > -----Original Message----- > From: Waltermire, David A. (Fed) > Sent: Sunday, June 05, 2016 12:03 PM > To: IPsecME WG > Subject: Call for adoption on draft-pauly-ipsecme-tcp-encaps as an IPSecM= E > WG document >=20 > This is the official call for adoption of https://datatracker.ietf.org/do= c/draft- > pauly-ipsecme-tcp-encaps/ as an IPSecME working group (WG) document. >=20 > By adopting this draft the WG is agreeing to take this on as an official = WG > item to continue work on the draft. Please reply with any comments > supporting or concerns against adopting to the mailing list. This call wi= ll run > until Friday, June 17th UTC 23:59. >=20 > Thanks, > Dave and Tero >=20 From nobody Wed Jun 22 10:21:53 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0F512D987 for ; Wed, 22 Jun 2016 10:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xj0fFZrnZsn for ; Wed, 22 Jun 2016 10:21:45 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0134.outbound.protection.outlook.com [23.103.200.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8884712D533 for ; Wed, 22 Jun 2016 10:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gEa3ZUjfoJVU5yeA3ERj9msDE4sX/taZ/iAdQDcsNVs=; b=OXplSmojqAcuoea+9NBMFGmTNfaAHfGIHsxvcc+ICAZ7ipvoO4uw2vpzCi7cnt7z0ApXq5CXkN2RAG9a2uHQ4UYvMi8FSE0tzC8phaKxvhx/JyuM3XPbspnobhG7lknliktch0DfCkA4YiMIwh7IKt78NXdQW9+0Hs0AvBiETQ0= Received: from DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) by DM2PR09MB0366.namprd09.prod.outlook.com (10.160.247.20) with Microsoft SMTP Server (TLS) id 15.1.517.8; Wed, 22 Jun 2016 17:21:43 +0000 Received: from DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) by DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) with mapi id 15.01.0523.015; Wed, 22 Jun 2016 17:21:43 +0000 From: "Waltermire, David A. (Fed)" To: Valery Smyslov , "paul@nohats.ca" Thread-Topic: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 Thread-Index: AQHRu30/DegBsfiJbkS4bhMRAGamZJ/WR2IxgAC6mgCAAL2FcIAAL3AAgAQjogCAGcjVgA== Date: Wed, 22 Jun 2016 17:21:42 +0000 Message-ID: References: <4200F5373D5542C985F3D4C51609213C@buildpc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: adbb1fc0-fe71-4c6e-8590-08d39ac1ae41 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0366; 6:qZmkFdmNqqpUne1X0haxLULahkYc4uzdy6yD3XuhYQFPTUlS6uzc0DajFgtL63EfR1z7VIguNkd4/2bwkXBjgu2O247jgmdRLmgtdR+MpjBQVbnZJXorqO1tZOgYY6nZjv2d7EM03uyi9GfuDVvGaXuVMxsvTE8IyyG0XdYQAhzh8M4PW1v5eqM1QhXrw4XZLqXuxT2PLHRLs/edwUwhis3cV+CUIwlx88d8iYlx9sVgYT7vdzGPe3GJsQn8Nuj2D7K9wGByvJWEWuryO7FFPZgcKCejSMFExX+b5q3Onl6ZlY5QjJ6+EbwpaP7UH3crDrDtmMNt7tfEuYTTSXy/I7PkT8oUz1aeOxYUndf0AjA=; 5:kXP9cpR/HUJQJWiVkjum5LB+6aUjjayJtke7QTrUxgbd7b9iuuvZkRcSPfa4CYgRg8+SzGWeB0t3J4DBLd7s1e6aaPgTCfcqdd55q3VSJLQT6PmN9qgcFsoZl8YKAFjSxPlc7tzH0+YLkIdWfzf9tw==; 24:FXkGJSsKFS+WDR8xXdVEPlowTVfshjo42EOX8AnUW4vo++nAQGP9zlvtb9hEWxgsAMn3dKdIL0kLL+vkUWKeBAcs9yRCEt8fOzoGaJ8ypww=; 7:8STl1xVkKz/Q/yasHB/4DKsAlabgEuV6HOw7p6SoJQ64v1ZdZBY0DXu+MkBzkzBqMW+GiTnc/BtC0pwS/p4lWhFTQXidsD45ic9l2WU35xYITliAOckkTuQpe0rclYFgOXCr3cEdyHB+3nYQSRtQVeRAjdCI6pJ/tnPCtqnU8ve/QwKeQZ253k6U5AHlVJgT1twt4tr7Jbnk0a6DkEuGsyXC//l1lXis7KKW2aEkmlA/MEr4PW67SmVBRa4c9ReQ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0366; x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DM2PR09MB0366; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0366; x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(377454003)(199003)(189002)(52314003)(2501003)(230783001)(81156014)(101416001)(87936001)(5002640100001)(33656002)(3660700001)(81166006)(4326007)(7696003)(8936002)(92566002)(93886004)(2906002)(8676002)(9686002)(68736007)(19580395003)(31430400001)(122556002)(7846002)(3846002)(19580405001)(5003600100003)(106356001)(99286002)(106116001)(105586002)(74316001)(102836003)(2950100001)(2900100001)(5001770100001)(10400500002)(77096005)(6116002)(76176999)(66066001)(50986999)(3280700002)(76576001)(15975445007)(54356999)(86362001)(11100500001)(189998001)(586003)(7736002)(97736004)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0366; H:DM2PR09MB0365.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 17:21:42.8924 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0366 Archived-At: Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 17:21:51 -0000 Paul and Valery, We are extremely close on wrapping up this draft. This thread appears to be= all that remains before sending the draft to the IESG. Can you guys wrap u= p the final minor wording changes this week? Valery, once agreement is reached on the text changes, can you post an upda= ted draft early next week that is ready to send to the IESG? Thanks, Dave > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Valery Smyslov > Sent: Monday, June 06, 2016 3:26 AM > To: paul@nohats.ca > Cc: ipsec@ietf.org; Yoav Nir > Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 >=20 > > [ cut everything we agreed ] > > > >>> > > Depending on the Responder implementation, this can be > repeated > >>> > > with > >>> > > the same half-open SA. > >>> > > > >>> > > I don't think this "depends on the implemention". Since any on-= path > >>> > > attacker can spoof rubbish, a Responder MUST ignore the failed > packet > >>> > > and remain ready to accept the real one for a certain about of = time. > >>> > > >>> > "Depending on the Responder implementation" means here that if > >>> > along with discarding the failed packet the Responder also > >>> > discards the computed SK_* keys, then it will need to > >>> > re-calculate them again when the next IKE_AUTH packet is > >>> > received, so the attack can be repeated. The SK_* keys don't > >>> > depend on IKE_AUTH messages, so in general there is no need to > >>> > discard them even if the received IKE_AUTH packet failed to > >>> > decrypt properly, and the draft advises to keep them in this > >>> > case. However, implementations may have good reasons to do this > >>> > (e.g. to free hardware resources if crypto is performed in HW). > >>> > >>> Oh, I didnt realise you talked about re-using DH components. Ok, in > >>> that case it makes sense but you might want to say it only applies > >>> to those who re-use DH calculations between different IKE peers. > >>> Our software never does that (and I think FIPS also puts additional > >>> constraints on > >>> this) > >> > >> No, it is not about re-using DH private key with different peers. I > >> probably poorly explained. Let me try again. > >> > >> Once the IKE_SA_INIT is complete the responder has all needed data to > >> calculate SKEYSEED and SK_* keys. However, it is a CPU consuming > >> operations, so the responder may want to postpone them until the keys > >> are really needed, i.e. until it receives the IKE_AUTH request from > >> the initiator. > >> This behaviour allows responder not to waste resources in case > >> IKE_SA_INIT was from an attacker and IKE_AUTH request never comes. > >> Once IKE_AUTH request arrives the responder performs DH, calculates > >> SKEYSEED and SK_* keys that allows him to decrypt and verify this > >> request. In case it fails to decrypt IKE_AUTH request, the responder > >> has two possibilities - keep just calculated SK_* keys until the next > >> (hopely proper) IKE_AUTH request is received or discard them (e.g. to > >> save crypto resources) and recalculate them again once the next > >> IKE_AUTH request is received (note that re-calculating will result in > >> EXACTLY the same keys, since they don't depent on any data from > >> IKE_AUTH). The draft recommends to keep the keys until the proper > >> IKE_AUTH request is received (or until the exchange timed out). This > >> advise may look obvious, but I think is still worth to mention. > >> > >> I recall we've already discussed this while reviewing the -05 version.= .. > > > > Ohh okay. I vaguely remember. I guess reading this explanation, I > > would say it should not be needed to mention it in this document, but > > it you want to do it anyway, how about: > > > > OLD: > > > > Depending on the Responder implementation, this can be repeated with > > the same half-open SA. > > > > NEW: > > > > If a Responder does not hold on to the calculated SKEYSEED and SK_* > > keys (which it should in case a valid IKE_AUTH comes in later) this > > attack might be repeated on the same half-open SA. >=20 > OK. >=20 > >>> This does not so much relate to IPv6 but to whether you rather > >>> overestimate or underestimate the attacker's IP space. If you > >>> underestimate, you will take longer to punish the attacking IPs. If > >>> you overestimate you will needlessly slow down legitimate clients. > >>> > >>> I don't know which of the two is better, hence my objection to "it > >>> makes sense" because I don't see that. > >> > >> What's your suggestion for this text? Just remove "it make sense" or > >> completely rewrite the para? If the latter, please provide the text. > > > > Something like: > > > > For IPv6, ISPs assign between a /48 and a /64, so it does not make > > sense for rate-limiting to work on single IPv6 IPs. Instead, > > ratelimits should be done based on either the /48 or /64 of the > > misbehaving IPv6 address observed. >=20 > OK. >=20 > >>> > > When the Responder is under attack, it MAY choose to prefer > >>> > > previously authenticated peers who present a Session > Resumption > >>> > > ticket (see [RFC5723] for details). > >>> > > > >>> > > Why is this only a MAY? Why is it not a SHOULD or MUST? > >>> > > >>> > A good question. I think the idea was not to force the Responder > >>> > to serve only resumed clients and to let him(her) prioterize > >>> > clients according to its own policy. In my opinion MUST is too > >>> > strong, but SHOULD is probably OK. > >>> > >>> In the famous words of Steve Kent, if you say SHOULD instead of > >>> MUST, explain when the Responder should not. > >> > >> When it has good reasons :-) > >> > >> Seriously, consider the situation when the responder finds itself > >> under attack and switches to only respond to IKE_SA_RESUME requests. > >> In this case it will leave legitimate clients without resumption > >> tickets (e.g. ticket expired) out of scope. > >> I think there is no reasom to put MUST here, since in any case it is > >> a local policy which dictates the responder's behaviour, and ther are > >> no interoperability issues whether is is MAY, SHOULD or MUST, it is > >> just the responder's local policy matter. > >> So SHOULD is just good advise. > > > > Actually, what you are describing is something else: > > > > When the Responder is under attack, it MUST NOT prefer previously > > authenticated peers who present a Session Resumption ticket [RFC5723] > > as that could cause a complete lock-out of legitimate clients that > > have no session to resume. > > > > Although that is probably better rewritten a bit: > > > > When the Responder is under attack, it SHOULD prefer previously > > authenticated peers who present a Session Resumption ticket [RFC5723] > > unless the attack itself consists of sending bogus resumption > > requests, in which case it SHOULD treat resumption and new session > > requests equally to avoid locking out a class of legitimate clients. >=20 > I'd rather change it a bit: >=20 > When the Responder is under attack, it SHOULD prefer previously > authenticated peers who present a Session Resumption ticket [RFC5723]= . > However, the Responder SHOULD NOT swich to resumed clients > completely (and thus refuse every IKE_SA_INIT request), > so that legitimate initiators without resumption tickets still have > chances to connect. >=20 > >>> That also > >>> avoids what to do when rekey's happen because that would likely > >>> reset the counter because it is a new state? > >> > >> Well, I think the proper approach is to measure the rate of such > >> exchanges (per SA or course). So, just reset the counter every second > >> and measure how many exchanges happened within the second. If the > >> number looks abusive, take measures. > > > > From our implementation point of view "per SA" is difficult, because > > we delete failed SA states, and then lose the count of those. So in > > that sense, using global counters makes more sense. For us, a rekey > > means that the old state is replaced with a new state. >=20 > I don't see any problem here. We are talking not about failed exchanges > (after which the SA must be deleted), but about an abusive number of > unnecessary exchanges, which are successful from IKEv2 point of view. > You can very well count their number per SA and it is not a big deal to r= eset > counters when IKE SA is rekeyed. >=20 > > so perhaps it is useful to elaborate a little more? >=20 > Isn't all this a local matter of implementation? > I don't think we need to mandate how implementations decide whether > they are under attack. >=20 > > Paul >=20 > Regards, > Valery. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jun 22 10:30:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A7B12D98A for ; Wed, 22 Jun 2016 10:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5mdsoyMf185 for ; Wed, 22 Jun 2016 10:30:11 -0700 (PDT) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0124.outbound.protection.outlook.com [23.103.201.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D2412D76B for ; Wed, 22 Jun 2016 10:30:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XfX4uHfz6jk0LGfeQa9DmYUqXCCWKbx+ZyUOVd/W/PY=; b=ZLoVWJVNVwsabDiSX8HlcSKy7QqVxzfsduTczcRxSyW/9DqtaT3EtkrIkp+/rNjiD7Id7UKtwHEqHB/cyqXbqgse6X0yYnK/ctY30sYyklPZNuxCJxoPbSaURzGsP/ycrVAeG9uoB7U6BDkTUJEcsdaoXtZhDfwRSs7n0i1PH40= Received: from DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) by DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) with Microsoft SMTP Server (TLS) id 15.1.523.12; Wed, 22 Jun 2016 17:30:08 +0000 Received: from DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) by DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) with mapi id 15.01.0523.015; Wed, 22 Jun 2016 17:30:08 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document Thread-Index: AdHMq6AaWm7UWPXSRFyRus61cfvSJA== Date: Wed, 22 Jun 2016 17:30:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 80c76211-2746-414e-6463-08d39ac2dba1 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0365; 6:fzqjdzRj1IdcR+R+O1H9vl22mKJYLMUYdNlu3dGRZ48scJGgrrMRYFBbMNNGxLJWhRfv/eQ8wVjBlKaM4MbKM3hkUNzxAH7T/2yluOeVVemSS5LXO6ndxQdPjk/phm5ipwM0//1hsiOh90IoVMKd2Pgn1t+4C0z5Xv7bm11pfOWaoouFb+kUjm93ugF3u9p4oCzLvN781y7mXfFX/xKDHJhoPWpPhRaW+SM3xv9+xPY8ZXV0BZH7I8bicqUB5R7wHxxwuWnjBZg3B2uvS5pp/ROJr3y8znyTe73ngI8NGy70fXZiV5QAXOPqbyfBpHoJ8hhU4/sJk+gNAsvP7XBJ4TyCPAPtfAROuk6/WGUtZnI=; 5:lWqPmyhL0b9vSCKUJ7e7b9vVlliRQ33LvsHXL7Lho+Z/jI3xXUkTaTJY2KwWosOaJCf65NKNNM5mCN8QYUeX048twUwIWEtzNU9NZDdPK3JoSi8t4WREL0mKtQvBuvHGjGupWrseNcmEtnN0QRmitg==; 24:F/BtNwfBDOh01on5JrYuOb4yXsVMca1r4dtJC1xi52N0VkgsJmknYPYIGZ9ZFNpdiIHXJy73mB+as6RgpM+IznPKMPvTRLqJ25Tj90y7qXg=; 7:3DSoSt9a3w6w6rH4MyfByVgy/9Ofit6ixD8BoqbsKhxdGsauy0+JkMwjvu8+5u9+8gt29Qhc7S8ik9vQdw2PzgmqSVC/Tcg4XizZ15D3uVZ4Jyq+/AK85kDUxl4CcDP5uH7AnWsy1fWXMGAgC+FQhbU8HuH894m1z7llzIrdRcdJz7ytgk9Nn4Ay2AwM9Zulnn5kZrKr8VYRc2ERmJpJcMvmsdJqXqg8UGs2OnO4ktlFSkHm9mrileg8tZ1An8Tg55sC69Chc8ZQA4Sv7We3MQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0365; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:DM2PR09MB0365; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0365; x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(97736004)(3660700001)(450100001)(86362001)(3280700002)(19580395003)(9686002)(105586002)(230783001)(8936002)(6116002)(102836003)(586003)(3846002)(106356001)(107886002)(76576001)(110136002)(15975445007)(77096005)(66066001)(2900100001)(99286002)(74316001)(68736007)(101416001)(2906002)(54356999)(50986999)(87936001)(33656002)(189998001)(122556002)(11100500001)(5002640100001)(81166006)(10400500002)(229853001)(8676002)(92566002)(5003600100003)(7736002)(7846002)(7696003)(81156014)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0365; H:DM2PR09MB0365.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 17:30:08.5739 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0365 Archived-At: Subject: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 17:30:12 -0000 At IETF 95 the chairs took an action to issue a call for adoption on draft-= fluhrer-qr-ikev2-01 based on WG interest in the concept described by the dr= aft. This call is long overdue. This is the official call for adoption of https://datatracker.ietf.org/doc/= draft-fluhrer-qr-ikev2/ as an IPSecME working group (WG) document.=20 By adopting this draft, the WG is agreeing to take this on as an official W= G item to continue work on the draft. Please reply with any comments suppor= ting or concerns against adopting to the mailing list. This call will run u= ntil Friday, July 4th UTC 23:59. Thanks, Dave and Tero From nobody Wed Jun 22 10:34:21 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 393FF12D78B; Wed, 22 Jun 2016 10:34:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160622173420.11063.44142.idtracker@ietfa.amsl.com> Date: Wed, 22 Jun 2016 10:34:20 -0700 Archived-At: Subject: [IPsec] The IPSECME WG has placed draft-fluhrer-qr-ikev2 in state "Call For Adoption By WG Issued" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 17:34:20 -0000 The IPSECME WG has placed draft-fluhrer-qr-ikev2 in state Call For Adoption By WG Issued (entered by David Waltermire) The document is available at https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ From nobody Wed Jun 22 12:42:50 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F4C12D5A5 for ; Wed, 22 Jun 2016 12:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOcJoUmTnV7J for ; Wed, 22 Jun 2016 12:42:46 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1466112D519 for ; Wed, 22 Jun 2016 12:33:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rZZWS3gQvz4Zp; Wed, 22 Jun 2016 21:33:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 0EdYU6XGImJx; Wed, 22 Jun 2016 21:33:07 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 22 Jun 2016 21:33:07 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E51D33522C4; Wed, 22 Jun 2016 15:33:00 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca E51D33522C4 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DDCFA406B15E; Wed, 22 Jun 2016 15:33:00 -0400 (EDT) Date: Wed, 22 Jun 2016 15:33:00 -0400 (EDT) From: Paul Wouters To: "Waltermire, David A. (Fed)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 19:42:48 -0000 On Wed, 22 Jun 2016, Waltermire, David A. (Fed) wrote: > At IETF 95 the chairs took an action to issue a call for adoption on draft-fluhrer-qr-ikev2-01 based on WG interest in the concept described by the draft. This call is long overdue. > > This is the official call for adoption of https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ as an IPSecME working group (WG) document. I still don't know if we should adopt this document or https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01 The qkd document was rejected for adoption at the time for lack of interest. I would like to better understand why draft-fluhrer-qr-ikev2 would be prefered over draft-nagayama-ipsecme-ipsec-with-qkd. Paul From nobody Wed Jun 22 14:53:21 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9155912B02F for ; Wed, 22 Jun 2016 14:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4feUZtghBOHK for ; Wed, 22 Jun 2016 14:53:18 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCDDF12D9DD for ; Wed, 22 Jun 2016 14:53:15 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id f126so103846481wma.1 for ; Wed, 22 Jun 2016 14:53:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dEba+PeSu9CZ50d6bUmT092nU3zeBkg4UOmQTSLi6UQ=; b=kbwiFx8KkQMTj6yhb7dyO2dq47mUZoKgeGKdbVYRQzrQNbvHqgJn0OSpIO3MsD/frj edGt2ySNeb4Zg0eS0d3lbmspPJJ4ynYMdEc1VAnUfqgMO4277R3tuoaWvKkFNvyg6njw U6bBIIXlk306h2ro2hsglAstPT6xX9T+mLtt8f/YQr39tQ8RobWziVHyvTEuu2mcvAOY g3GLPo0fYehj+0A/eaoeYTWKmpNn2KotDIU8S86ZdcAyNj/uyJsp6ZSzOdyk1XnBlsYl GVg9nDSF7PuO41O6MyCAEOKSXxquemmCj2CqsuaU+3B5fI8Slk+APHSlW8trE7TcFhEm xwiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dEba+PeSu9CZ50d6bUmT092nU3zeBkg4UOmQTSLi6UQ=; b=dgre7Wlsoe7pQimO1EAgk5GmSoepjRiFBKIzJS0fz/w+0qoZ+QX4cb3jIPJ+Fc+6CK 8S+6KSGujsX2pU2NR8ZtAHFcTntFXM6CxmbY9M+vbEiKGLEZsjwpFq7O70OI2sbT/5Eq 6iiy4xs2MnTmq2xPcNjcHTTwcTmP36fMwOhhcTUnohVzJWQzNm/I2AXvERhu+mg1OFL8 Pj7CRt/rZ6OoDbcSTZo4P2L0BkjY0D8s3BBZo6wvMUwymx6k6bfMKUAktIlk1+4dTVH4 DVlLPEOF4pPsXxEEzCQZYCa+ftlrVaHAZ33Rhsv+vbEN9px65T2C7Di70kXVSlwh81X1 tWHw== X-Gm-Message-State: ALyK8tILjXhAf3scaBTHjuwk0QaUqPgUmp7Hk6OUduP3BNFK0ICsGeS05L605Mj3acIuHA== X-Received: by 10.28.27.8 with SMTP id b8mr10540944wmb.40.1466632393193; Wed, 22 Jun 2016 14:53:13 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id g10sm1232815wjl.25.2016.06.22.14.53.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 22 Jun 2016 14:53:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Thu, 23 Jun 2016 00:53:10 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <61EFFC26-DF41-4E11-AB9D-D7E772C9502D@gmail.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Endless stream of NAT-T keepalive probes? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 21:53:20 -0000 All three devices also run an SSL-VPN, so you can just go to = https:// to see who owns them.=20 The first one will also tell you the vendor as they didn=E2=80=99t = customize the landing page=E2=80=A6 > On 22 Jun 2016, at 7:11 PM, Paul Wouters wrote: >=20 >=20 > Hi, >=20 > One of my machines is seeing a continous stream of NAT-T keepalive = probes > for which we have no state (and for which we had no state for days or > weeks or ever). These always seem to come in sets of 3 probes at once, > every 20 seconds. And oddly enough on port 500, not 4500. Containing > the 1 byte 0xFF NAT-Keepalive payload. >=20 > Currently offending IPs are: 87.236.232.253, 46.34.71.246 and = 64.115.92.187. >=20 > Small pcap entry attached. >=20 > Has oneone experienced these before? Is this a known bad device? Or am = I > just special? :) >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jun 22 19:20:59 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9712DEBB for ; Wed, 22 Jun 2016 19:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEdn8ObxMCFy for ; Wed, 22 Jun 2016 19:20:56 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B9D12DEBA for ; Wed, 22 Jun 2016 19:20:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rZlYm6y5gzlR; Thu, 23 Jun 2016 04:20:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id CO9RQwxUvIb8; Thu, 23 Jun 2016 04:20:43 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 23 Jun 2016 04:20:43 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6998F3522C4; Wed, 22 Jun 2016 22:20:42 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 6998F3522C4 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4E2074001693; Wed, 22 Jun 2016 22:20:42 -0400 (EDT) Date: Wed, 22 Jun 2016 22:20:42 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: Message-ID: References: <4200F5373D5542C985F3D4C51609213C@buildpc> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 02:20:58 -0000 On Mon, 6 Jun 2016, Valery Smyslov wrote: >> > When it has good reasons :-) >> > >> > Seriously, consider the situation when the responder finds itself >> > under attack and switches to only respond to IKE_SA_RESUME >> > requests. In this case it will leave legitimate clients without >> > resumption tickets (e.g. ticket expired) out of scope. I think there is >> > no reasom to put MUST here, since in any case >> > it is a local policy which dictates the responder's behaviour, >> > and ther are no interoperability issues whether is is MAY, SHOULD or >> > MUST, it is just the responder's local policy matter. >> > So SHOULD is just good advise. >> >> Actually, what you are describing is something else: >> >> When the Responder is under attack, it MUST NOT prefer previously >> authenticated peers who present a Session Resumption ticket [RFC5723] >> as that could cause a complete lock-out of legitimate clients that >> have no session to resume. >> >> Although that is probably better rewritten a bit: >> >> When the Responder is under attack, it SHOULD prefer previously >> authenticated peers who present a Session Resumption ticket [RFC5723] >> unless the attack itself consists of sending bogus resumption requests, >> in which case it SHOULD treat resumption and new session requests >> equally to avoid locking out a class of legitimate clients. > > I'd rather change it a bit: > > When the Responder is under attack, it SHOULD prefer previously > authenticated peers who present a Session Resumption ticket [RFC5723]. > However, the Responder SHOULD NOT swich to resumed clients > completely (and thus refuse every IKE_SA_INIT request), > so that legitimate initiators without resumption tickets still have > chances to connect. Ok, minor change: When the Responder is under attack, it SHOULD prefer previously authenticated peers who present a Session Resumption ticket [RFC5723]. However, the Responder SHOULD NOT serve resumed Initiators exclusively because dropping all IKE_SA_INIT requests would lock out legitimate Initiators that have no resumption ticket. >> > Well, I think the proper approach is to measure the rate of such >> > exchanges (per SA or course). So, just reset the counter every second >> > and measure how many exchanges happened within >> > the second. If the number looks abusive, take measures. >> >> From our implementation point of view "per SA" is difficult, because we >> delete failed SA states, and then lose the count of those. So in that >> sense, using global counters makes more sense. For us, a rekey means >> that the old state is replaced with a new state. > > I don't see any problem here. We are talking not about failed exchanges > (after which the SA must be deleted), but about an abusive number of > unnecessary exchanges, which are successful from IKEv2 point of view. > You can very well count their number per SA and it is not a big deal > to reset counters when IKE SA is rekeyed. I don't think you would want to reset the counters, but I know that our implementation, which creates a new state object for the rekeyed state, would lose information unless we specifically added code to copy those. >> so perhaps it is useful to elaborate a little more? > > Isn't all this a local matter of implementation? > I don't think we need to mandate how implementations > decide whether they are under attack. I agree, this discussion does not need to be in the document. Paul From nobody Wed Jun 22 21:26:15 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B838512D808 for ; Wed, 22 Jun 2016 21:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3hzqp8pDfrz for ; Wed, 22 Jun 2016 21:26:10 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7517912D7C3 for ; Wed, 22 Jun 2016 21:26:09 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id l188so86343104lfe.2 for ; Wed, 22 Jun 2016 21:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=rCphFWgiYnzk9Px3g4NYfeK1orPT7537Px/rjIbSLTQ=; b=ZhzKGYf+dTBHgba+3soIqA5H9JS0QjCdNW1rcp4V6GW2y9Kg9/9Ltam03iLTE+Yg53 98UcxQ1/k916uXddhR1rOkyS7oWrT+PIwqrLGJE40ZcT0ZcOHkNMt6aV1Q0/+sO7U1hL RfpJwAgii6b6jVLKNwOM08qL9Pn1JpoHkLJ53/yXZxiPxkMIoQt3MTAQDLSUWDJDSHIn nnKNmOANI+fhJGlZ38VXXKYZAOuLaCbM0Keq2C0wBJFadNlPctI61XICvkmSsAoHWZRv G5ycmHDH7JH9wbum/HUkS6FInyDUG0bCEc4AOuvA1xxB2h7hQhjzNFgxK3DTa1b3JGfs t2vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=rCphFWgiYnzk9Px3g4NYfeK1orPT7537Px/rjIbSLTQ=; b=CGsLtDrdHnGcgQIQAGS9O6jLliGK1ZD77RdFrRa1bQ1xHKkMNmGUpG13LzMrHXsJpX EXmIas2Sxn3e1/HYSZ5E2oLpwyTHoGSy8JlaQFmo+6hU9O82f/4uLYnMl2/kBL0vzRE7 XKPnd6SGAAPV2XMt/xhYpkmuIm53gbIFpnrQpWg6svjHAdYH+/EXMc778ZvTVnpSr9Mk LZkYrjDIvtk4Bmos9HgM/F3B+NukRdTKXa1oeZqgdqAte6OC1g0hhYZ9IR0uDPPtEQ7r 7YwUSn+EECE8GyYWf9NkDR6VeLBYDKGs+XkzzPgbva+W9QdrpxJ0nZyMFYDBwwr/CW0y ftZQ== X-Gm-Message-State: ALyK8tJdbzChmOhAR/J2DhkSuVojwPYSvOadBAxfCh5+rcfN31QzuX2KEYCQvUhh4LfflA== X-Received: by 10.25.4.4 with SMTP id 4mr8411068lfe.208.1466655967580; Wed, 22 Jun 2016 21:26:07 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id m6sm341745lbp.38.2016.06.22.21.26.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Jun 2016 21:26:06 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Waltermire, David A. \(Fed\)" , References: <4200F5373D5542C985F3D4C51609213C@buildpc> Date: Thu, 23 Jun 2016 07:26:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 04:26:13 -0000 Hi Dave, we've already incorporated Paul Wouters' comments in the draft on github. The only thing that stops us publishing it is Paul's promise to review the rest of the document (from Sections 7 up to the end). I've just sent him a reminder asking if he could do it within the next few days. BTW, I'm on vacation till Tuesday. So, it's more realistic to post an updated draft later next week, say Wednesday or Thursday (I presume that Paul will do his promised review; otherwise it's possible to post the draft earlier). Regards, Valery. ----- Original Message ----- From: "Waltermire, David A. (Fed)" To: "Valery Smyslov" ; Cc: ; "Yoav Nir" Sent: Wednesday, June 22, 2016 8:21 PM Subject: RE: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 Paul and Valery, We are extremely close on wrapping up this draft. This thread appears to be all that remains before sending the draft to the IESG. Can you guys wrap up the final minor wording changes this week? Valery, once agreement is reached on the text changes, can you post an updated draft early next week that is ready to send to the IESG? Thanks, Dave > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Valery Smyslov > Sent: Monday, June 06, 2016 3:26 AM > To: paul@nohats.ca > Cc: ipsec@ietf.org; Yoav Nir > Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 > > > [ cut everything we agreed ] > > > >>> > > Depending on the Responder implementation, this can be > repeated > >>> > > with > >>> > > the same half-open SA. > >>> > > > >>> > > I don't think this "depends on the implemention". Since any on-path > >>> > > attacker can spoof rubbish, a Responder MUST ignore the failed > packet > >>> > > and remain ready to accept the real one for a certain about of time. > >>> > > >>> > "Depending on the Responder implementation" means here that if > >>> > along with discarding the failed packet the Responder also > >>> > discards the computed SK_* keys, then it will need to > >>> > re-calculate them again when the next IKE_AUTH packet is > >>> > received, so the attack can be repeated. The SK_* keys don't > >>> > depend on IKE_AUTH messages, so in general there is no need to > >>> > discard them even if the received IKE_AUTH packet failed to > >>> > decrypt properly, and the draft advises to keep them in this > >>> > case. However, implementations may have good reasons to do this > >>> > (e.g. to free hardware resources if crypto is performed in HW). > >>> > >>> Oh, I didnt realise you talked about re-using DH components. Ok, in > >>> that case it makes sense but you might want to say it only applies > >>> to those who re-use DH calculations between different IKE peers. > >>> Our software never does that (and I think FIPS also puts additional > >>> constraints on > >>> this) > >> > >> No, it is not about re-using DH private key with different peers. I > >> probably poorly explained. Let me try again. > >> > >> Once the IKE_SA_INIT is complete the responder has all needed data to > >> calculate SKEYSEED and SK_* keys. However, it is a CPU consuming > >> operations, so the responder may want to postpone them until the keys > >> are really needed, i.e. until it receives the IKE_AUTH request from > >> the initiator. > >> This behaviour allows responder not to waste resources in case > >> IKE_SA_INIT was from an attacker and IKE_AUTH request never comes. > >> Once IKE_AUTH request arrives the responder performs DH, calculates > >> SKEYSEED and SK_* keys that allows him to decrypt and verify this > >> request. In case it fails to decrypt IKE_AUTH request, the responder > >> has two possibilities - keep just calculated SK_* keys until the next > >> (hopely proper) IKE_AUTH request is received or discard them (e.g. to > >> save crypto resources) and recalculate them again once the next > >> IKE_AUTH request is received (note that re-calculating will result in > >> EXACTLY the same keys, since they don't depent on any data from > >> IKE_AUTH). The draft recommends to keep the keys until the proper > >> IKE_AUTH request is received (or until the exchange timed out). This > >> advise may look obvious, but I think is still worth to mention. > >> > >> I recall we've already discussed this while reviewing the -05 version... > > > > Ohh okay. I vaguely remember. I guess reading this explanation, I > > would say it should not be needed to mention it in this document, but > > it you want to do it anyway, how about: > > > > OLD: > > > > Depending on the Responder implementation, this can be repeated with > > the same half-open SA. > > > > NEW: > > > > If a Responder does not hold on to the calculated SKEYSEED and SK_* > > keys (which it should in case a valid IKE_AUTH comes in later) this > > attack might be repeated on the same half-open SA. > > OK. > > >>> This does not so much relate to IPv6 but to whether you rather > >>> overestimate or underestimate the attacker's IP space. If you > >>> underestimate, you will take longer to punish the attacking IPs. If > >>> you overestimate you will needlessly slow down legitimate clients. > >>> > >>> I don't know which of the two is better, hence my objection to "it > >>> makes sense" because I don't see that. > >> > >> What's your suggestion for this text? Just remove "it make sense" or > >> completely rewrite the para? If the latter, please provide the text. > > > > Something like: > > > > For IPv6, ISPs assign between a /48 and a /64, so it does not make > > sense for rate-limiting to work on single IPv6 IPs. Instead, > > ratelimits should be done based on either the /48 or /64 of the > > misbehaving IPv6 address observed. > > OK. > > >>> > > When the Responder is under attack, it MAY choose to prefer > >>> > > previously authenticated peers who present a Session > Resumption > >>> > > ticket (see [RFC5723] for details). > >>> > > > >>> > > Why is this only a MAY? Why is it not a SHOULD or MUST? > >>> > > >>> > A good question. I think the idea was not to force the Responder > >>> > to serve only resumed clients and to let him(her) prioterize > >>> > clients according to its own policy. In my opinion MUST is too > >>> > strong, but SHOULD is probably OK. > >>> > >>> In the famous words of Steve Kent, if you say SHOULD instead of > >>> MUST, explain when the Responder should not. > >> > >> When it has good reasons :-) > >> > >> Seriously, consider the situation when the responder finds itself > >> under attack and switches to only respond to IKE_SA_RESUME requests. > >> In this case it will leave legitimate clients without resumption > >> tickets (e.g. ticket expired) out of scope. > >> I think there is no reasom to put MUST here, since in any case it is > >> a local policy which dictates the responder's behaviour, and ther are > >> no interoperability issues whether is is MAY, SHOULD or MUST, it is > >> just the responder's local policy matter. > >> So SHOULD is just good advise. > > > > Actually, what you are describing is something else: > > > > When the Responder is under attack, it MUST NOT prefer previously > > authenticated peers who present a Session Resumption ticket [RFC5723] > > as that could cause a complete lock-out of legitimate clients that > > have no session to resume. > > > > Although that is probably better rewritten a bit: > > > > When the Responder is under attack, it SHOULD prefer previously > > authenticated peers who present a Session Resumption ticket [RFC5723] > > unless the attack itself consists of sending bogus resumption > > requests, in which case it SHOULD treat resumption and new session > > requests equally to avoid locking out a class of legitimate clients. > > I'd rather change it a bit: > > When the Responder is under attack, it SHOULD prefer previously > authenticated peers who present a Session Resumption ticket [RFC5723]. > However, the Responder SHOULD NOT swich to resumed clients > completely (and thus refuse every IKE_SA_INIT request), > so that legitimate initiators without resumption tickets still have > chances to connect. > > >>> That also > >>> avoids what to do when rekey's happen because that would likely > >>> reset the counter because it is a new state? > >> > >> Well, I think the proper approach is to measure the rate of such > >> exchanges (per SA or course). So, just reset the counter every second > >> and measure how many exchanges happened within the second. If the > >> number looks abusive, take measures. > > > > From our implementation point of view "per SA" is difficult, because > > we delete failed SA states, and then lose the count of those. So in > > that sense, using global counters makes more sense. For us, a rekey > > means that the old state is replaced with a new state. > > I don't see any problem here. We are talking not about failed exchanges > (after which the SA must be deleted), but about an abusive number of > unnecessary exchanges, which are successful from IKEv2 point of view. > You can very well count their number per SA and it is not a big deal to reset > counters when IKE SA is rekeyed. > > > so perhaps it is useful to elaborate a little more? > > Isn't all this a local matter of implementation? > I don't think we need to mandate how implementations decide whether > they are under attack. > > > Paul > > Regards, > Valery. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jun 23 14:13:21 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBDEF12D6A8; Thu, 23 Jun 2016 14:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSQfNNug3HO2; Thu, 23 Jun 2016 14:13:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6332B12D1A2; Thu, 23 Jun 2016 14:13:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMM52030; Thu, 23 Jun 2016 21:13:06 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 23 Jun 2016 22:13:05 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Thu, 23 Jun 2016 14:13:00 -0700 From: Linda Dunbar To: Rafa Marin Lopez Thread-Topic: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? Thread-Index: AQHRyJXW/dWNT5292kuu9K0bP3U5LZ/t7k5AgAOga4CAAI+jwIAD9wOAgAGAqKA= Date: Thu, 23 Jun 2016 21:13:00 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657ED6A35@dfweml501-mbb> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <7C1028FB-4531-4BA8-9C64-AE933945539F@um.es> <4A95BA014132FF49AE685FAB4B9F17F657ECCD0E@dfweml501-mbb> <466D704F-4C9B-45FB-AE68-841896D29B72@um.es> In-Reply-To: <466D704F-4C9B-45FB-AE68-841896D29B72@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.242] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.576C50E3.0231, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f7494696dd16692f2209729fd487d774 Archived-At: Cc: "I2NSF@ietf.org" , "IPsec@ietf.org" , Sowmini Varadhan , Sowmini Varadhan Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 21:13:16 -0000 UmFmYSwgDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmFmYSBNYXJp biBMb3BleiBbbWFpbHRvOnJhZmFAdW0uZXNdIA0KU2VudDogV2VkbmVzZGF5LCBKdW5lIDIyLCAy MDE2IDEwOjEzIEFNDQpUbzogTGluZGEgRHVuYmFyDQoNCjxzbmlwPg0KDQo+ICANCj4gVGhlICJy ZWFjdGl2ZSBvcHRpb24sIHRoYXQgaXMsICB2ZXJ5IHNpbWlsYXIgYXMgaXQgd291bGQgaGFwcGVu IHdpdGggdGhlIE9wZW5GbG93IFBhY2tldEluIG1lc3NhZ2UgYW5kIHRoZW4gUGFja2V0T3V0IiBp cyBub3QgaW4gdGhlIEkyTlNGIHNjb3BlLiBIb3dldmVyLCB0aGUgc3BlY2lmeWluZyB0aGUgZGF0 YSBtb2RlbCBmb3IgdGhlIHBvbGljeSB0byB0aGUgY29udHJvbGxlciBvbiB3aGljaCBmbG93cyB0 byBiZSBwcm90ZWN0ZWQgYnkgSVBTZWMgdHVubmVsIHNob3VsZCBiZSBpbiB0aGUgSTJOU0Ygc2Nv cGUuDQoNClBsZWFzZSBiZSBhd2FyZSB0aGF0IHNvbWUgcmVhY3RpdmUgKHVwb24gYW4gZXZlbnQp IGJlaGF2aW9yIG1heSBiZSByZXF1aXJlZCBldmVuIHdoZW4gdGhlIGNvbnRyb2xsZXIgc2V0cyB1 cCB0aGUgSVBzZWMgcG9saWNpZXMva2V5cyBwcm9hY3RpdmVseS4gRm9yIGV4YW1wbGUsIHRoZSBQ Rl9LRVkgaW50ZXJmYWNlIChSRkMgMjM2NykgaW4gdGhlIGtlcm5lbCBoYXMgYW4g4oCcZXZlbnTi gJ0NCg0KW0xpbmRhXUkgc2VlLiBUaG9zZSAiZXZlbnRzIiBkZWZpbml0ZWx5IG5lZWQgdG8gYmUg YWRkcmVzc2VkIGJ5IHRoZSBkYXRhIG1vZGVsIGJldHdlZW4gY29udHJvbGxlciBhbmQgZW5kIHBv aW50cy4gSXQgaXMgaGVscGZ1bCB0byBkZXNjcmliZSB0aGUgaW5mb3JtYXRpb24gbW9kZWwuIA0K DQoNCiJUaGUgU0FEQl9FWFBJUkUgbWVzc2FnZSBpcyBzZW50IGZyb20gdGhlIGtlcm5lbCB0byBr ZXkgbWFuYWdlbWVudA0KICAgYXBwbGljYXRpb25zIHdoZW4gdGhlICJzb2Z0IGxpZmV0aW1lIiBv ciAiaGFyZCBsaWZldGltZSIgb2YgYQ0KICAgU2VjdXJpdHkgQXNzb2NpYXRpb24gaGFzIGV4cGly ZWQuICBLZXkgbWFuYWdlbWVudCBhcHBsaWNhdGlvbnMgc2hvdWxkDQogICB1c2UgcmVjZWlwdCBv ZiBhIHNvZnQgbGlmZXRpbWUgU0FEQl9FWFBJUkUgbWVzc2FnZSBhcyBhIGhpbnQgdG8NCiAgIG5l Z290aWF0ZSBhIHJlcGxhY2VtZW50IFNBIHNvIHRoZSByZXBsYWNlbWVudCBTQSB3aWxsIGJlIHJl YWR5IGFuZCBpbg0KICAgdGhlIGtlcm5lbCBiZWZvcmUgaXQgaXMgbmVlZGVkLuKAnQ0KDQpUaGlz IGlzIGEga2luZCBvZiBhc3luY2hyb25vdXMgZXZlbnQsIHdoaWNoIGlzIGltcG9ydGFudCBiZWNh dXNlIGl0IGFsbG93cyB0aGUgY29udHJvbGxlciB0byByZWFjdCBhbmQgdXBkYXRlIHRoZSBTQXMu IElzIHRoaXMga2luZCBvZiBldmVudCBpbiB0aGUgSTJOU0Ygc2NvcGU/IA0KDQpJbiBhbnkgY2Fz ZSB3ZSBhcmUgZ29pbmcgdG8gbW9kaWZ5IHRoZSBJLUQgdG8gc2hvdyBhbGwgdGhlc2UgYXNwZWN0 cy4NCltMaW5kYV0gVGhhbmtzLiBBcmUgeW91IGdvaW5nIHRvIHRha2UgdGhlIHJlbGV2YW50IHBv cnRpb24gaW4gdGhlIEktRCBmb3IgSTJOU0YgV0c/IE9yIGFyZSB5b3UgZ29pbmcgdG8ga2VlcCBp biB0aGUgU0ROcmc/IA0KDQoNClNvbWUgY29tbWVudHMgaW5saW5lOg0KDQo+ICANCj4gIA0KPiBP dGhlciBjb21tZW50cyBhcmUgaW5zZXJ0ZWQgYmVsb3cNCj4gIA0KPiAgDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFJhZmEgTWFyaW4gTG9wZXogW21haWx0bzpyYWZhQHVt LmVzXQ0KPiBTZW50OiBTdW5kYXksIEp1bmUgMTksIDIwMTYgMTowNiBQTQ0KPiBUbzogTGluZGEg RHVuYmFyDQo+IENjOiBSYWZhIE1hcmluIExvcGV6OyBJMk5TRkBpZXRmLm9yZzsgSVBzZWNAaWV0 Zi5vcmc7IFNvd21pbmkgDQo+IFZhcmFkaGFuOyBTb3dtaW5pIFZhcmFkaGFuDQo+IFN1YmplY3Q6 IFJlOiBbSVBzZWNdIFtJMm5zZl0gSG93IGRvZXMgT3ZlcmxheSBOZXR3b3JrIGluZm9ybSB0aGUg VW5kZXJsYXkgbmV0d29yayBvbiB3aGljaCBmbG93cyBhbW9uZyBPdmVybGF5IG5ldHdvcmsgbm9k ZXMgbmVlZCB0byBnbyB0aHJvdWdoIElQU2VjIFR1bm5lbD8gKHdhcyA6IEZsb3cgU2VjdXJpdHkg UG9saWNpZXMgZXhjaGFuZ2VkIG92ZXIgSTJOU0Ygc2VydmljZSBsYXllciBpbnRlcmZhY2U/DQo+ ICANCj4gPHNuaXA+DQo+ID4gIA0KPiA+IC0gU2VjdGlvbiA4LjE6IFBhZ2UgMTE6IEJ1bGxldCAx Og0KPiA+IFlvdSBzdGF0ZWQgdGhhdCB0aGUgbm9kZSBzZW5kcyB0aGUgZmlyc3QgcGFja2V0IHRv IENvbnRyb2xsZXIgZm9yIHRoZSBjb250cm9sbGVyIHRvIGRldGVybWluZSBpZiB0aGUgdHJhZmZp YyBuZWVkcyB0byBnbyB0aHJvdWdoIElQU2VjIHR1bm5lbC4gDQo+ID4gIA0KPiA+IFNob3VsZG4n dCB0aGUgY29udHJvbGxlciBnZXQgZmxvdyBwcm90ZWN0aW9uIHBvbGljeSBmcm9tIGNsaWVudHMg KG5vcnRoIGJvdW5kIGludGVyZmFjZSkgYW5kIGluZm9ybSB0aGUgbmVlZGVkIGVuZCBub2RlcyBv biB3aGF0IHRyYWZmaWMvZmxvd3MgbmVlZCB0byBnbyB0aHJvdWdoIHRoZSBJUFNlYyB0dW5uZWw/ DQo+ICANCj4gW1JhZmFdIEFjdHVhbGx5LCB0aGVyZSBhcmUgdHdvIG9wdGlvbnMuIFRoZSBvbmUg c2hvd24gaW4gdGhlIEktRCBpcyByZWFjdGl2ZSwgdGhhdCBpcywgIHZlcnkgc2ltaWxhciBhcyBp dCB3b3VsZCBoYXBwZW4gd2l0aCB0aGUgT3BlbkZsb3cgUGFja2V0SW4gbWVzc2FnZSBhbmQgdGhl biBQYWNrZXRPdXQuIFRoZSBvdGhlciBvcHRpb24sIG9mIGNvdXJzZSwgaXQgaXMgdG8gY3JlYXRl IHRoZSBydWxlcyBpbiB0aGUgbmV0d29yayByZXNvdXJjZSBldmVuIHdoZW4gdHJhZmZpYyBoYXMg bm90IGJlZW4gb2JzZXJ2ZWQgeWV0IChwcm9hY3RpdmUpLiBCb3RoIG9wdGlvbnMgYXJlIGNvbXBs ZXRlbHkgcG9zc2libGUuIFdlIGNhbiBjbGFyaWZ5IHRoaXMgaW4gdGhlIG5leHQgdmVyc2lvbi4N Cj4gIA0KPiBbTGluZGFdIHNvIHRoZSBJMk5TRiBzaG91bGQgb25seSBmb2N1cyBvbiBzcGVjaWZ5 aW5nIHRoZSBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGZvciB0aGUg4oCcUHJvdGVjdGl2ZeKA nSBtZXRob2RzLiBNYXliZSBwYXJ0IG9mIHlvdXIgZHJhZnQgY2FuIGJlIGZ1cnRoZXIgZGV2ZWxv cGVkIGluIEkyTlNGIFdHLiANCj4gIA0KPiA+ICANCj4gPiAgDQo+ID4gLSBTZWN0aW9uIDguMTog UGFnZSAxMjogQnVsbGV0IDM6DQo+ID4gVGhlIGNvbnRyb2xsZXIgY2FuJ3QgcmVhbGx5IGVuZm9y Y2UgdGhlIHJ1bGUuIGJ1dCBpbnN0ZWFkIHJlcXVlc3RpbmcgdGhlICJFbmQgTm9kZSIgdG8gZW5j YXBzdWxhdGUgdGhlIElQU2VjIHR1bm5lbCBhcm91bmQgdGhlIGZsb3dzIHRoYXQgbmVlZCB0byBi ZSB0aHJvdWdoIHRoZSBJUFNlYyB0dW5uZWwuIGNvcnJlY3Q/DQo+ICANCj4gW1JhZmFdIE5vdCBz dXJlIHdoeSB5b3UgdGhpbmsgdGhlIGNvbnRyb2xsZXIgY2Fu4oCZdCBlbmZvcmNlIHRoZSBydWxl LiBCYXNpY2FsbHkgdGhlIHN0ZXAgMyBzYXlzIHRoZSBjb250cm9sbGVyIGlzIGZpbGxpbmcgYSBT QUQgZW50cnkgd2l0aG91dCB0aGUgbmVlZCBvZiBydW5uaW5nIElLRSBiZXR3ZWVuIG5ldHdvcmsg cmVzb3VyY2VzLg0KPiAgDQo+IFtMaW5kYV0gQXJlIHlvdSBhc3N1bWluZyB0aGF0IGRhdGEgcGFj a2V0cyBhY3R1YWxseSB0cmF2ZXJzaW5nIHRoZSDigJxDb250cm9sbGVy4oCdPyBJZiB5ZXMsIHRo ZSBJMk5TRiBmb2N1cyBvbiB0aGUgZmxvdyBwb2xpY3kgbm9ydGggYm91bmQgdG8gdGhlIGNvbnRy b2xsZXIuIA0KDQpbUmFmYV0gSXQgaXMgbm90IHRyYXZlcnNlIGJ1dCBpdCBpcyB0byBjaGVjayB0 aGUgZmlyc3QgZGF0YSBwYWNrZXQgaW4gYSBmbG93IHRvIHNlZSB0aGVyZSBpcyBuZWVkIGZvciBz ZWN1cml0eSBvciBub3QuIEJ1dCBjZXJ0YWlubHkgdGhhdCBiZWxvbmdzIHRvIHNvdXRoYm91bmQg aW50ZXJmYWNlLg0KDQo+ICANCj4gIA0KPiAgDQo+ID4gIA0KPiA+IC0gU2VjdGlvbiA2LCBQYWdl IDcsIFNlY29uZCBwYXJhZ3JhcGggYWZ0ZXIgdGhlIEZpZ3VyZSAyOiANCj4gPiBUaGUgQ29udHJv bGxlciBzaG91bGQgc2VuZCB0aGUgSVBTZWMgdHVubmVsIHJlcXVlc3QgdG8gdGhlIGVuZCBwb2lu dHMgb2YgdGhlIGRlc2lyZWQgSVBTZWMgdHVubmVsLiBBbHNvIHRoZSBjb250cm9sbGVyIHNob3Vs ZCBzZW5kIHF1ZXJ5IHRvIHRoZSBlbmQgcG9pbnQgdG8gY2hlY2sgaWYgdGhleSBoYXZlIHRoZSBu ZWVkZWQgcmVzb3VyY2UgdG8gZXN0YWJsaXNoIHRoZSBkZXNpcmVkIElQU2VjIHR1bm5lbC4NCj4g IA0KPiBbUmFmYV0gV2hhdCBkbyB5b3UgbWVhbiB3aXRoIOKAnElQc2VjIHR1bm5lbCByZXF1ZXN0 4oCdPyBCeSBzZW5kaW5nIHRoZSBpbmZvcm1hdGlvbiByZWxhdGVkIHdpdGggdGhlIElQc2VjIHR1 bm5lbCAoZS5nLiBhIFNBRCBlbnRyeSkgdG8gYnVpbGQgaXQgc2hvdWxkIGJlIGVub3VnaCwgSSBn dWVzcyB0aGF0IGlzIHdoYXQgeW91IG1lYW4gYnkgdGhhdCAsIHJpZ2h0Py4NCj4gIA0KPiBbTGlu ZGFdIFllcy4gDQo+ICANCj4gIA0KPiBUaGUgY29udHJvbGxlciBjYW4gb2YgY291cnNlIHZlcmlm eSBpZiB0aGUgZW5kIHBvaW50cyBvZiB0aGUgSVBzZWMgU0EgaGF2ZSB0aGUgaW5mb3JtYXRpb24g dG8gZXN0YWJsaXNoIGFuIElQc2VjIHR1bm5lbCBhY2NvcmRpbmcgdG8gdGhlIGluZm9ybWF0aW9u IHRoYXQgdGhlIGNvbnRyb2xsZXIga2VlcHMuIElmIHRoZSBzdGF0ZSBpcyBub3QgdGhlcmUgb3Ig aXMgZ29pbmcgdG8gYmUgb3V0ZGF0ZWQgaXQgY2FuIGVuZm9yY2UgdGhlIGluZm9ybWF0aW9uIGFn YWluLiBBbHRlcm5hdGl2ZWx5LCB0aGUgZW5kIHBvaW50cyBjb3VsZCBhbHNvIGluZm9ybSB3aGVu IHNvbWV0aGluZyBpcyByZXF1aXJlZCB0byB0aGUgY29udHJvbGxlciAocmVhY3RpdmUpIHNvIHRo ZSBjb250cm9sbGVyIGNhbiBhY3QgYWNjb3JkaW5nbHkuDQo+ICANCj4gW0xpbmRhXSBhYm92ZSBp cyB3aGF0IEkgY2FsbCDigJxxdWVyeeKAnS4gTmVlZCB0byBmbHVzaCBvdXQgdGhlIGRldGFpbGVk IGRhdGEgbW9kZWwgZm9yIHlvdXIgSVBTZWMgY2FzZSBpbiBJMk5TRiBXRy4gDQo+ICANCj4gIA0K PiA+ICANCj4gPiAtIFNlY3Rpb24gOC4yOiANCj4gPiBTZWNvbmQgcGFyYWdyYXBoOiBXaGVuIHRo ZSB0d28gZW5kIHBvaW50cyBvZiB0aGUgbmVlZGVkIElQU2VjIHR1bm5lbCBhcmUgaW4gdHdvIGRp ZmZlcmVudCBJU1BzIChzYXkgSVNQLUEgYW5kIElTUC1CKSwgeW91ciBkcmFmdCBzdGF0ZXMgdGhh dCB0aGUgSVNQLUEgY29udHJvbGxlciBoYXMgdG8gbmVnb3RpYXRlIHdpdGggSVNQLUIgY29udHJv bGxlciBvbiB0aGUgRmxvdyBTZWN1cml0eSBwb2xpY3kgcnVsZXMuIFdoYXQgaW5mb3JtYXRpb24g d2lsbCBiZSBjYXJyaWVkIGJ5IHRob3NlIFBvbGljeSBSdWxlcz8gU2luY2UgSTJOU0YgaXMgdG8g c3BlY2lmeSB0aGUgZGF0YSBtb2RlbHMgZm9yIHRob3NlIHJ1bGVzLCBpdCB3b3VsZCBiZSB2ZXJ5 IGhlbHBmdWwgdG8gaWRlbnRpZnkgdGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdlZCBmaXJzdC4gDQo+ ICANCj4gW1JhZmFdIFdlIGNhbiBzcGVjaWZ5IGJldHRlciB3aGF0IGluZm9ybWF0aW9uIGluIHRo ZSBmb2xsb3dpbmcgZHJhZnQuIEJ1dCBiYXNpY2FsbHkgd2UgaGF2ZSB0d28gbW9kZWxzIGV4cGxh aW5lZCBpbiB0aGUgZHJhZnQgd2hlbiAxKSBJS0UgaXMgaW1wbGVtZW50ZWQgaW4gdGhlIG5ldHdv cmsgcmVzb3VyY2Ugb3Igd2hlbiBJS0UgaXMgbm90IGltcGxlbWVudGVkIGluIHRoZSBuZXR3b3Jr IHJlc291cmNlLiAgDQo+ICANCj4gSW4gMSkgcGFyYW1ldGVycyB0byBydW4gYW4gSUtFIFNBIGJl dHdlZW4gR1cxIGFuZCBHVzIgbXVzdCBiZSBuZWdvdGlhdGVkIChJS0UgY3JlZGVudGlhbCwgY3J5 cHRvZ3JhcGhpYyBzdWl0ZSwgZXRj4oCmKSBhbmQgdGhlIGRpZmZlcmVudCBTUEQgZW50cmllcyBv ZiB0aGUgU1BEIHRoYXQgYXBwbHkuIEFuIFNQRCBlbnRyeSBoYXMgcGFyYW1ldGVycyBzdWNoIGFz IFJlbW90ZSBJUCBBZGRyZXNzLCBMb2NhbCBJUCBBZGRyZXNzLCBOZXh0IExheWVyIFByb3RvY29s LCBOYW1lLCBMb2NhbCBhbmQgUmVtb3RlIFBvcnRzLg0KPiAgDQo+IEluIDIpIGFwYXJ0IGZyb20g U1BEIGVudHJpZXMgeW91IG5lZWQgdG8gY29uZmlndXJlIFNBRCBlbnRyaWVzLiBUaGlzIGluZm9y bWF0aW9uIGltcGxpZXMgU2VjdXJpdHkgUGFyYW1ldGVyIEluZGV4LCBTZXF1ZW5jZSBOdW1iZXIs IEFIIGluZm9ybWF0aW9uIChrZXlzICwga2V5IGxpZmV0aW1lKSAsIEVTUCBpbmZvcm1hdGlvbuKA piBldGMuDQo+ICANCj4gV2UgY2FuIGRldGFpbCB3aGF0IGluZm9ybWF0aW9uIGlzIHJlcXVpcmVk Lg0KPiAgDQo+IFtMaW5kYV0gdGhhdCB3aWxsIGJlIHVzZWZ1bC4gQ2FuIHlvdSB3cml0ZSB0aGlz IGRldGFpbGVkIGluZm9ybWF0aW9uIGV4Y2hhbmdlIGZvciBJMk5TRj8gDQoNCltSYWZhXSBXZSB0 aGluayBzbyB5ZXMuDQoNCkJlc3QgUmVnYXJkcy4NCg0KPiAgDQo+ICANCj4gPiAgDQo+ID4gUGFn ZSAxMzogYnVsbGV0IDI6IGJlZm9yZSB0aGUgbmVnb3RpYXRpb24gYmV0d2VlbiB0aGUgdHdvIGNv bnRyb2xsZXJzIG9uIHRoZSBTUEQgcG9saWNpZXMgYW5kIElLRSBjcmVkZW50aWFscywgZG9uJ3Qg eW91IHRoaW5rIHRoYXQgdGhleSBuZWVkIHRvIGlucXVpcmUgZWFjaCBvdGhlciBpZiB0aGUgb3Ro ZXIgcGFydHkgaGFzIHRoZSBuZWVkZWQgcmVzb3VyY2UgZm9yIHRoZSBuZWVkZWQgSVBzZWMgdHVu bmVsPyANCj4gIA0KPiBbUmFmYV0gQnV0IGZvciB0aGF0LCB3aGF0IGtpbmQgb2YgcGFyYW1ldGVy cyBkbyB5b3Ugc2VuZCB0byBhc2sgdGhlIHF1ZXN0aW9uPyBJIGNhbiBpbWFnaW5lIHlvdSBjb3Vs ZCBhc2sgOiBkbyB5b3UgaGF2ZSBhbiBlbmQgcG9pbnQgd2l0aCB0aGlzIElQIGFkZHJlc3MsIElL RSBzdXBwb3J0LCBBSCBvciBFU1Agc3VwcG9ydOKApiBldGPigKY/IElzIHRoYXQgd2hhdCB5b3Ug aGF2ZSBpbiBtaW5kPw0KPiAgDQo+IEluIGFueSBjYXNlLCBpZiB0aGV5IGRvIG5vdCBoYXZlIHRo YXQgc3VwcG9ydCB0cnlpbmcgdGhlIG5lZ290aWF0aW9uIGJldHdlZW4gdGhlIHR3byBjb250cm9s bGVycyB3b3VsZCBmYWlsIHNvIHRoYXQgeW91IHdvdWxkIG5vdGljZSB0aGF0IHRoZSBuZWVkZWQg cmVzb3VyY2UgaXMgbm90IGF2YWlsYWJsZSBhcyB3ZWxsLCByaWdodD8NCj4gIA0KPiAgDQo+IFtM aW5kYV0gY29ycmVjdC4gDQo+ICANCj4gVGhhbmtzLCBMaW5kYQ0KPiAgDQo+ICANCj4gIA0KPiAg DQo+IEJlc3QgUmVnYXJkcy4NCj4gPiAgDQo+ID4gIA0KPiA+ICANCj4gPiBUaGFua3MsIExpbmRh DQo+ID4gIA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogUmFmYSBN YXJpbiBMb3BleiBbbWFpbHRvOnJhZmFAdW0uZXNdDQo+ID4gU2VudDogRnJpZGF5LCBKdW5lIDE3 LCAyMDE2IDc6NDMgQU0NCj4gPiBUbzogTGluZGEgRHVuYmFyDQo+ID4gQ2M6IFJhZmEgTWFyaW4g TG9wZXo7IFNvd21pbmkgVmFyYWRoYW47IEkyTlNGQGlldGYub3JnOyBTb3dtaW5pIA0KPiA+IFZh cmFkaGFuOyBOVk8zOyBMaXlpemhvdQ0KPiA+IFN1YmplY3Q6IFJlOiBbSTJuc2ZdIEhvdyBkb2Vz IE92ZXJsYXkgTmV0d29yayBpbmZvcm0gdGhlIFVuZGVybGF5IG5ldHdvcmsgb24gd2hpY2ggZmxv d3MgYW1vbmcgT3ZlcmxheSBuZXR3b3JrIG5vZGVzIG5lZWQgdG8gZ28gdGhyb3VnaCBJUFNlYyBU dW5uZWw/ICh3YXMgOiBGbG93IFNlY3VyaXR5IFBvbGljaWVzIGV4Y2hhbmdlZCBvdmVyIEkyTlNG IHNlcnZpY2UgbGF5ZXIgaW50ZXJmYWNlPw0KPiA+ICANCj4gPiBEZWFyIGFsbDoNCj4gPiAgDQo+ ID4gTWF5YmUgdGhpcyBJLUQgbWlnaHQgYmUgaW50ZXJlc3RpbmcgYW5kIHJlbGF0ZWQgd2l0aCB0 aGlzIGRpc2N1c3Npb24gcmVnYXJkaW5nIElQc2VjL0lLRSBtYW5hZ2VtZW50LiBXZSBob3BlIHRv IGhhdmUgYW4gdXBkYXRlZCB2ZXJzaW9uIHNvb24gYW5kIGEgcHJvb2Ytb2YtY29uY2VwdCBpbXBs ZW1lbnRhdGlvbiBvZiBzb21lIG9mIHRoZSBzY2VuYXJpb3MuDQo+ID4gIA0KPiA+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hYmFkLXNkbnJnLXNkbi1pcHNlYy1mbG93LXByb3Rl Y3RpDQo+ID4gb24NCj4gPiAtMDENCj4gPiAgDQo+ID4gQmVzdCBSZWdhcmRzLg0KPiA+ICANCj4g PiAgDQo+ID4gPiBFbCAxNyBqdW4gMjAxNiwgYSBsYXMgMTA6NDMsIExpbmRhIER1bmJhciA8bGlu ZGEuZHVuYmFyQGh1YXdlaS5jb20+IGVzY3JpYmnDszoNCj4gPiA+IA0KPiA+ID4gU293bWluaSwN Cj4gPiA+ICANCj4gPiA+IFlvdSBzYWlkOg0KPiA+ID4g4oCcSG93ZXZlciwgYXBwbHlpbmcgSVBz ZWMgdG8gc3BlY2lmaWMgZmxvd3MgKGUuZy4sIHRob3NlIGRlZmluZWQgYnkgYSBzcmMgb3IgZHN0 IHBvcnQgb24gd2hpY2ggdGhlIHNlcnZpY2UgbGlzdGVucykgaXMgaW1wb3J0YW50LuKAnQ0KPiA+ ID4gIA0KPiA+ID4gV2hhdCBpcyB0aGUgY3VycmVudCBvcGVyYXRpb24gcHJvY2VkdXJlIGZvciBP dmVybGF5IG5ldHdvcmsgdG8gaW5mb3JtIHRoZSB1bmRlcmxheSBuZXR3b3JrIG9uIHdoaWNoIGZs b3dzIHRvIGdvIHRocm91Z2ggSVBTZWMgY2hhbm5lbD8gDQo+ID4gPiAgDQo+ID4gPiBZb3Ugc2Fp ZDogDQo+ID4gPiDigJwuLkJ1dCB0aGF0IGFsc28gbWFkZSBtZSB3b25kZXIgYWJvdXQgdGhlIGlu dGVyYWN0aW9uIGJldHdlZW4gSVBzZWMvSUtFIGFuZCB0aGUgcHJvcG9zZWQgQkdQIEZTIChJUHNl YyBpcyBmcmVxdWVudGx5IHVzZWQgYmV0d2VlbiBlbmQtc3lzdGVtcyB0aGF0IGRvIG5vdCB3YW50 IHRvIHJ1biBhIEJHUCBkYWVtb24pLiBTaW5jZSB0aGUgY29uZmlnIGluZm9ybWF0aW9uIHRoYXQg bmVlZHMgdG8gYmUgZGlzdHJpYnV0ZWQgYXJlIHRoaW5ncyBsaWtlIGtleXMsIGFsZ29yaXRobXMg ZXRjIHRvIHBvcHVsYXRlIHRoZSBzYWRiL3NwZCwgSUtFIGxvb2tzIG1vcmUgYXBwcm9wcmlhdGUg aW4gbW9zdCBjYXNlcy7igJ0NCj4gPiA+ICANCj4gPiA+ICANCj4gPiA+IERvZXMgdGhlIHVuZGVy bGF5IG5ldHdvcmsgY29udHJvbGxlciBnZXQgc29tZSBpbmZvcm1hdGlvbiAob3IgaGludCBmcm9t IHRoZSBPdmVybGF5IG5ldHdvcmsgY29udHJvbGxlcikgb24gaG93IHRoZSBrZXlzIGFyZSBjb25m aWd1cmVkIGZvciB0aGUgSVBTZWMgdHVubmVsIGZvciB0aGUgc3BlY2lmaWMgZmxvd3MgYW1vbmcg dGhlIE92ZXJsYXkgbm9kZXM/IA0KPiA+ID4gIA0KPiA+ID4gIA0KPiA+ID4gVGhhbmtzLA0KPiA+ ID4gTGluZGENCj4gPiA+ICANCj4gPiA+ICANCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4gPiBGcm9tOiBTb3dtaW5pIFZhcmFkaGFuIFttYWlsdG86c293bWluaTA1QGdtYWls LmNvbV0NCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBKdW5lIDE2LCAyMDE2IDEwOjU3IEFNDQo+ID4g PiBUbzogTGluZGEgRHVuYmFyDQo+ID4gPiBDYzogTGl5aXpob3U7IE5WTzM7IFNvd21pbmkgVmFy YWRoYW4NCj4gPiA+IFN1YmplY3Q6IFJlOiBbbnZvM10gRlc6IEFueSB1c2UgY2FzZXMgb2YgT3Zl cmxheSBuZXR3b3JrIHJlcXVlc3RpbmcgSVBTZWMgY29ubmVjdGlvbiBmcm9tIHRoZSBVbmRlcmxh eSBmb3IgYSBzcGVjaWZpYyB0aW1lIHNwYW4/ICh3YXMgOiBGbG93IFNlY3VyaXR5IFBvbGljaWVz IGV4Y2hhbmdlZCBvdmVyIEkyTlNGIHNlcnZpY2UgbGF5ZXIgaW50ZXJmYWNlPw0KPiA+ID4gIA0K PiA+ID4gT24gV2VkLCBKdW4gMTUsIDIwMTYgYXQgODo1NSBBTSwgTGluZGEgRHVuYmFyIDxsaW5k YS5kdW5iYXJAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gPiA+DQo+ID4gPiA+IE5WTzMgUGFydGlj aXBhbnRzLA0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBJMk5TRiAoSW50ZXJm YWNlIHRvIE5ldHdvcmsgU2VjdXJpdHkgZnVuY3Rpb24pIGhhcyBhIHdvcmsgaXRlbSBpbiBkZWZp bmluZyB0aGUgZmxvdyBzZWN1cml0eSBwb2xpY3kgYmV0d2VlbiBkb21haW5zICh3aGljaCBpbmNs dWRlcyBpbnF1aXJ5IG9mIHRoZSBjYXBhYmlsaXR5IGZyb20gb25lIGRvbWFpbiB0byBhbm90aGVy IGFuZCB0aGUgYWN0dWFsIGZsb3cgcG9saWN5IHJ1bGVzIGZyb20gb25lIGRvbWFpbiB0byBhbm90 aGVyKS4NCj4gPiA+ID4NCj4gPiA+ID4gVmVyeSBvZnRlbiwgdGhlIHBhdGhzIChvciBsaW5rcykg YW1vbmcgbm9kZXMgb2YgYSBvdmVybGF5IG5ldHdvcmsgYXJlIHByb3ZpZGVkIGJ5IG90aGVyIG5l dHdvcmsgb3BlcmF0b3JzIChhLmsuYS4g4oCcdW5kZXJsYXkgbmV0d29ya+KAnSkuICBUaGUgZmxv dyBwb2xpY3kgcnVsZXMgYXJlIGludGVuZGVkIHRvIGZpbHRlciBvdXQgdW53YW50ZWQgdHJhZmZp YyBmcm9tIHVuZGVybGF5IG5ldHdvcmsgc28gdGhhdCB2YXJpb3VzIGF0dGFjayB0cmFmZmljIHdv buKAmXQgc2F0dXJhdGVkIHRoZSBhY2Nlc3MgbGlua3MgdG8gdGhlIG92ZXJsYXkgbm9kZXMuDQo+ ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IE9uZSBpbnRlcmVzdGluZyBzY2VuYXJp byBicm91Z2h0IHVwIGlzIE92ZXJsYXkgbm9kZXMgbWF5IG5lZWQgdG8gcmVxdWVzdCBzb21lIHRy YWZmaWMgdG8gYmUgdHJhdmVyc2luZyBJUHNlYyBjaGFubmVsLiBUbyBhY2hpZXZlIHRoaXMgZ29h bCwgaXQgaXMgbmVjZXNzYXJ5IGZvciBPdmVybGF5IE5ldHdvcmsgY29udHJvbGxlciB0byBpbnF1 aXJlIGlmIHRoZSBuZWVkZWQgSVBzZWMgcmVzb3VyY2UgYXJlIGV2ZW4gYXZhaWxhYmxlIGJlZm9y ZSBzZW5kIHRoZSByZXF1ZXN0IChtYXkgZXZlbiBpbnZvbHZlIEFBQSBwcm9jZXNzIGJldHdlZW4g Y29udHJvbGxlcnMgb2YgZWFjaCBjb3JyZXNwb25kaW5nIGRvbWFpbiApLg0KPiA+ID4gPg0KPiA+ ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBXYW50IHRvIGhhdmUgYSBzdXJ2ZXkgaWYgcGVvcGxlIHNl ZSB0aGUgdXNlIGNhc2Ugb2YgT3ZlcmxheSBOZXR3b3JrIG5lZWRpbmcgcG9ydGlvbiBvZiB0cmFm ZmljIHRvIGJlIHRocm91Z2ggSVBTZWMgY2hhbm5lbD8NCj4gPiA+ICANCj4gPiA+IFllcywgdGhp cyBpcyBhIHZhbGlkIHVzZSBjYXNlLCBhbmQgb25lIHRoYXQgd2UgIGFyZSBsb29raW5nIGF0IGFz IHdlbGwuDQo+ID4gPiAgDQo+ID4gPiA+IElQU2VjIGlzIHN1cHBvc2VkIHRvIGJlIGJldHdlZW4g dHdvIGVuZCBub2Rlcy4gSGVyZSB3ZSBhc3N1bWUgdGhhdCB0aGUgT3ZlcmxheSBub2RlcyBkb27i gJl0IGhhdmUgdGhlIHJlc291cmNlIG9yIGNhcGFiaWxpdHkgZm9yIElQc2VjLCBidXQgZXhwZWN0 IElQc2VjIGJldHdlZW4gZmxvd+KAmXMgaW5ncmVzcyBhbmQgZWdyZXNzIG5vZGVzIChpLmUuIE5W RSkuDQo+ID4gPiA+IEFueSBvcGluaW9uIGlzIGFwcHJlY2lhdGVkLg0KPiA+ID4gIA0KPiA+ID4g IA0KPiA+ID4gPg0KPiA+ID4gPiBBcmUgdGhlcmUgYW55IHVzZSBjYXNlcyBvZiBvdmVybGF5IG5l dHdvcmsgbmVlZGluZyBJUFNlYyBhbW9uZyB0aGVpciBub2RlcyBvbmx5IGZvciBhIHNwZWNpZmlj IHRpbWUgc3Bhbj8gaS5lLiBUaW1lIGJhc2VkIElQU2VjIGNvbm5lY3Rpb24/DQo+ID4gPiAgDQo+ ID4gPiBUaW1lIGJhc2VkIElQc2VjIGNvbm5lY3Rpb24gaXMgbm90IGEgdXNlLWNhc2Ugd2UgaGF2 ZSBlbmNvdW50ZXJlZC4NCj4gPiA+IFBlb3BsZSB1c3VhbGx5IHVzZSBJS0UgZm9yIHBlcmlvZGlj IGtleS1yb2xsb3ZlciwgaWYgdGhhdCBpcyB0aGUgZ29hbC4NCj4gPiA+ICANCj4gPiA+IEhvd2V2 ZXIsIGFwcGx5aW5nIElQc2VjIHRvIHNwZWNpZmljIGZsb3dzIChlLmcuLCB0aG9zZSBkZWZpbmVk IGJ5IGEgc3JjIG9yIGRzdCBwb3J0IG9uIHdoaWNoIHRoZSBzZXJ2aWNlIGxpc3RlbnMpIGlzIGlt cG9ydGFudC4NCj4gPiA+ICANCj4gPiA+IEJ1dCB0aGF0IGFsc28gbWFkZSBtZSB3b25kZXIgYWJv dXQgdGhlIGludGVyYWN0aW9uIGJldHdlZW4gSVBzZWMvSUtFIGFuZCB0aGUgcHJvcG9zZWQgQkdQ IEZTIChJUHNlYyBpcyBmcmVxdWVudGx5IHVzZWQgYmV0d2VlbiBlbmQtc3lzdGVtcyB0aGF0IGRv IG5vdCB3YW50IHRvIHJ1biBhIEJHUCBkYWVtb24pLiBTaW5jZSB0aGUgY29uZmlnIGluZm9ybWF0 aW9uIHRoYXQgbmVlZHMgdG8gYmUgZGlzdHJpYnV0ZWQgYXJlIHRoaW5ncyBsaWtlIGtleXMsIGFs Z29yaXRobXMgZXRjIHRvIHBvcHVsYXRlIHRoZSBzYWRiL3NwZCwgSUtFIGxvb2tzIG1vcmUgYXBw cm9wcmlhdGUgaW4gbW9zdCBjYXNlcy4NCj4gPiA+ICANCj4gPiA+IExpa2UgW0NKXSwgSSB0b28g aGF2ZSB0byByZWFkIHRoZSBkcmFmdCBpbiBncmVhdGVyIGRldGFpbCB0byBjb21tZW50IGZ1cnRo ZXIuDQo+ID4gPiAgDQo+ID4gPiAtLVNvd21pbmkNCj4gPiA+ICANCj4gPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBJMm5zZiBtYWlsaW5n IGxpc3QNCj4gPiA+IEkybnNmQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2kybnNmDQo+ID4gIA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBSYWZhZWwgTWFyaW4gTG9wZXos IFBoRA0KPiA+IERlcHQuIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0aW9ucyBFbmdpbmVlcmlu ZyAoRElJQykgRmFjdWx0eSBvZiANCj4gPiBDb21wdXRlciBTY2llbmNlLVVuaXZlcnNpdHkgb2Yg TXVyY2lhDQo+ID4gMzAxMDAgTXVyY2lhIC0gU3BhaW4NCj4gPiBUZWxmOiArMzQ4Njg4ODg1MDEg RmF4OiArMzQ4Njg4ODQxNTEgZS1tYWlsOiByYWZhQHVtLmVzDQo+ID4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ICANCj4gPiAgDQo+ ID4gIA0KPiA+ICANCj4gPiAgDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBJUHNlYyBtYWlsaW5nIGxpc3QNCj4gPiBJUHNlY0BpZXRmLm9y Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCj4gIA0K PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IFJhZmFlbCBNYXJpbiBMb3BleiwgUGhEDQo+IERlcHQuIEluZm9ybWF0aW9uIGFuZCBDb21t dW5pY2F0aW9ucyBFbmdpbmVlcmluZyAoRElJQykgRmFjdWx0eSBvZiANCj4gQ29tcHV0ZXIgU2Np ZW5jZS1Vbml2ZXJzaXR5IG9mIE11cmNpYQ0KPiAzMDEwMCBNdXJjaWEgLSBTcGFpbg0KPiBUZWxm OiArMzQ4Njg4ODg1MDEgRmF4OiArMzQ4Njg4ODQxNTEgZS1tYWlsOiByYWZhQHVtLmVzDQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g IA0KPiAgDQo+ICANCj4gIA0KPiAgDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IElQc2VjIG1haWxpbmcgbGlzdA0KPiBJUHNlY0BpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJhZmFlbCBN YXJpbiBMb3BleiwgUGhEDQpEZXB0LiBJbmZvcm1hdGlvbiBhbmQgQ29tbXVuaWNhdGlvbnMgRW5n aW5lZXJpbmcgKERJSUMpIEZhY3VsdHkgb2YgQ29tcHV0ZXIgU2NpZW5jZS1Vbml2ZXJzaXR5IG9m IE11cmNpYQ0KMzAxMDAgTXVyY2lhIC0gU3BhaW4NClRlbGY6ICszNDg2ODg4ODUwMSBGYXg6ICsz NDg2ODg4NDE1MSBlLW1haWw6IHJhZmFAdW0uZXMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCg0K From nobody Thu Jun 23 15:55:23 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73E6B12D51C for ; Thu, 23 Jun 2016 15:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aosCofOVTGjo for ; Thu, 23 Jun 2016 15:55:19 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C31AD12B010 for ; Thu, 23 Jun 2016 15:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2047; q=dns/txt; s=iport; t=1466722519; x=1467932119; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=abGoWvDvwR1HIxavFoo9QALGfXV3cKq9zTd3v1ttGFE=; b=F0glppxPQKbQLLG9imDStkGtF8YWkIi5I6Sz4E1b1SQM+ln2PxxsA7U4 ZM/pzMjP6SVVjtO/5BXyIOs9SA4rWjUEvcqC3zMwMHsP4UnPgWMgur6dN lBBGNJFH62Zasqvfau1eeYOt3ZMxiDVlGjM8stYQV0Mwf5nD7rfScLw5Y Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAgCfaGxX/4QNJK1UCYM+Vn0GujaBe?= =?us-ascii?q?hcLhXYCgTQ4FAEBAQEBAQFlJ4RMAQEBAwEBAQEaHTQLBQcEAgEIEQQBAR8JByc?= =?us-ascii?q?LFAkIAgQOBQiIIAgOxzsBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYYnhE2EGYVlH?= =?us-ascii?q?QWIH4cMiVQBhgeIIo8rj30BHjaCO4E1bokBfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,518,1459814400"; d="scan'208";a="288674984" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jun 2016 22:55:19 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5NMtI93000825 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Jun 2016 22:55:18 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 23 Jun 2016 17:55:18 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1104.009; Thu, 23 Jun 2016 17:55:18 -0500 From: "Panos Kampanakis (pkampana)" To: Paul Wouters , "Waltermire, David A. (Fed)" Thread-Topic: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document Thread-Index: AQHRzL5I/3IuxFFqPEuQJeebP9cco5/3p21w Date: Thu, 23 Jun 2016 22:55:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.108.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IPsecME WG , "David McGrew \(mcgrew\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 22:55:21 -0000 Introducing quantum computer resistance in IKEv2 helps to avoid the implica= tions of having sec admins that want to have quantum computer resistance re= vert back to IKEv1 with shared secrets. The draft adds quantum resistance u= sing todays infrastructure. The qkd draft introduced a way to add quantum r= esistance, but it came with many different challenges of how practical it i= s and how costly it would be to introduce a QKD network. Instead, draft-flu= hrer-qr-ikev2 uses a more practical approach that could be implemented and = employed easily. Scott almost has a working PoC ready, I believe. There are= details that need to be hashed out in the group, like what to do with iden= tity hiding, but the draft is practical and can be introduced quickly and i= n a backwards compatible way to IKEv2. =20 Panos -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Wouters Sent: Wednesday, June 22, 2016 3:33 PM To: Waltermire, David A. (Fed) Cc: IPsecME WG Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSe= cME WG document On Wed, 22 Jun 2016, Waltermire, David A. (Fed) wrote: > At IETF 95 the chairs took an action to issue a call for adoption on draf= t-fluhrer-qr-ikev2-01 based on WG interest in the concept described by the = draft. This call is long overdue. > > This is the official call for adoption of https://datatracker.ietf.org/do= c/draft-fluhrer-qr-ikev2/ as an IPSecME working group (WG) document. I still don't know if we should adopt this document or https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01 The qkd document was rejected for adoption at the time for lack of interest= . I would like to better understand why draft-fluhrer-qr-ikev2 would be prefe= red over draft-nagayama-ipsecme-ipsec-with-qkd. Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jun 23 18:06:23 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9683712D662 for ; Thu, 23 Jun 2016 18:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHlYdrNXa9WE for ; Thu, 23 Jun 2016 18:06:20 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC28B12D16F for ; Thu, 23 Jun 2016 18:06:19 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rbKsC0F6mz3Tx; Fri, 24 Jun 2016 03:06:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 2_GCDFn3Vz0O; Fri, 24 Jun 2016 03:06:05 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 24 Jun 2016 03:06:04 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A08D3768B23; Thu, 23 Jun 2016 21:06:00 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca A08D3768B23 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 88FAE4065381; Thu, 23 Jun 2016 21:06:00 -0400 (EDT) Date: Thu, 23 Jun 2016 21:06:00 -0400 (EDT) From: Paul Wouters To: "Panos Kampanakis (pkampana)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG , "David McGrew \(mcgrew\)" , "Waltermire, David A. \(Fed\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 01:06:21 -0000 On Thu, 23 Jun 2016, Panos Kampanakis (pkampana) wrote: > The draft adds quantum resistance using todays infrastructure. So did the old draft? > The qkd draft introduced a way to add quantum resistance, but it came with many different challenges of how practical it is and how costly it would be to introduce a QKD network. Instead, draft-fluhrer-qr-ikev2 uses a more practical approach that could be implemented and employed easily. This is sort of answering the question by just rephrasing the question as an answer :P As I understand it, both drafts depend on exchanging an identifier in the clear, that leads to identifying an out-of-band PreSharedKey. This is then mixed into the prf/prfplus. The drafts use different ways to accomplish this. (and I think both are too complicated) > Scott almost has a working PoC ready, I believe. There are details that need to be hashed out in the group, like what to do with identity hiding, but the draft is practical and can be introduced quickly and in a backwards compatible way to IKEv2. I don't understand why the use of AES and SHA256 hardcoded in the document? Why isn't the ID enough to gain access to the new PSK? If the source of the PSK is not fast or good enough to create enough key material, why doesn't the out-of-band process do its own PRF function? I don't see why that needs to be in this specfication. Why use ECB? I thought this algorithm had fallen out of favour? I don't yet understand why the child sa also needs to be modified. Do we think that the prf() is insecure if the EC(DH) is broken? If the IKE SA is broken, what other attacks are possible? IKE SA deletion? How does this work with session resumption? I thought for IKEv2, we realised that anonimity is hard to protect for against an active attacker, as the initiator always has to out itself somehow for the responder to be authenticated. As such, I think the fourth "stated goal" might not be worth it, and everything could be simplified further. And it would remove the whole extra exchange with cookies too. The simplest implementation I see, which would also work with a shared onetime pad, is to just send some kind of notification that IDs the source for the additional key material, then whenever we draw from an IKE prf(), throw in some of that keymaterial. I don't yet see the real advantage of anything more complicated then that. Paul From nobody Fri Jun 24 03:06:05 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DAA12DA01 for ; Fri, 24 Jun 2016 03:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfNn5j9yKG6F for ; Fri, 24 Jun 2016 03:06:02 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7B212D0ED for ; Fri, 24 Jun 2016 03:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3974; q=dns/txt; s=iport; t=1466762762; x=1467972362; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=famte6fGWCf1/aDFU5xCiUtoLgWDsjD+Mg+X2NDAjx8=; b=hXLxhIxS45q9vAhH1xsk1vVj4P1ZkFnl6UbINwKR4WQYAGtgXwal38oq NWRMNblr1Kmpf9XpjK+76URQxt0zFfLf3lBtkiPUs2IXKUcHamneCRgGM zrpPlSYeujODkBF0NAOXh70Dl3/ZyHgeSP6R6S9d8sD8jvAE0Se6XAYgJ Y=; X-IronPort-AV: E=Sophos;i="5.26,520,1459814400"; d="scan'208";a="288012821" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jun 2016 10:06:01 +0000 Received: from rtp-mcgrew-8915.cisco.com (rtp-mcgrew-8915.cisco.com [10.117.10.230]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u5OA6088027332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2016 10:06:01 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: David McGrew In-Reply-To: Date: Fri, 24 Jun 2016 06:06:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Paul Wouters X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG , "Panos Kampanakis \(pkampana\)" , "Waltermire, David A. \(Fed\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 10:06:05 -0000 Hi Paul, > On Jun 23, 2016, at 6:55 PM, Panos Kampanakis (pkampana) = wrote: >=20 > Introducing quantum computer resistance in IKEv2 helps to avoid the = implications of having sec admins that want to have quantum computer = resistance revert back to IKEv1 with shared secrets. The draft adds = quantum resistance using todays infrastructure. The qkd draft introduced = a way to add quantum resistance, but it came with many different = challenges of how practical it is and how costly it would be to = introduce a QKD network. Instead, draft-fluhrer-qr-ikev2 uses a more = practical approach that could be implemented and employed easily. Scott = almost has a working PoC ready, I believe. There are details that need = to be hashed out in the group, like what to do with identity hiding, but = the draft is practical and can be introduced quickly and in a backwards = compatible way to IKEv2. >=20 > Panos >=20 >=20 > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Wouters > Sent: Wednesday, June 22, 2016 3:33 PM > To: Waltermire, David A. (Fed) > Cc: IPsecME WG > Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an = IPSecME WG document >=20 > On Wed, 22 Jun 2016, Waltermire, David A. (Fed) wrote: >=20 >> At IETF 95 the chairs took an action to issue a call for adoption on = draft-fluhrer-qr-ikev2-01 based on WG interest in the concept described = by the draft. This call is long overdue. >>=20 >> This is the official call for adoption of = https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ as an IPSecME = working group (WG) document. >=20 > I still don't know if we should adopt this document or >=20 > https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01 >=20 > The qkd document was rejected for adoption at the time for lack of = interest. >=20 > I would like to better understand why draft-fluhrer-qr-ikev2 would be = prefered over draft-nagayama-ipsecme-ipsec-with-qkd. Because QKD is not a practical system for Internet security. It has = serious security issues/challenges and operational limitations on = bitrate, range, and physical media. It requires a point to point = optical link, which is typically dedicated fiber, which must be shorter = than 60 miles. There are security issues with QKD because it relies on = a physical interaction across the line between the encrypter and = decrypter, thus giving an attacker the opportunity to perform an attack = on the physical process anywhere on that line. See for instance = Brassard et. al. Security Aspects of Practical Quantum Cryptography, = Lydersen et. al., Hacking commercial quantum cryptography systems by = tailored bright illumination, or Gerhardt et. al., Full-field = implementation of a perfect eavesdropper on a quantum cryptography = system. Another major security problem is the range limitation; it has = been proposed to extend the range of QKD by using a chain of trusted = repeaters, each connected by a QKD system. These repeaters would = greatly increase the attack surface, and require the end user to trust = the infrastructure provider(s); in contrast, the Internet community = wants end to end encryption, as described in RFC3365 and RFC7624. In contrast, QR-IKEv2 can be used to add postquantum security between = any two points on the globe, without requiring dedicated fiber, and = without requiring physical layer security assumptions. It has *fewer* = security assumptions than draft-nagayama-ipsecme-ipsec-with-qkd, as that = draft relies on the security of symmetric cryptography and the physical = layer, whereas QR-IKEv2 relies only on the former. thanks David >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Jun 24 04:34:04 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C696F12D1AD for ; Fri, 24 Jun 2016 04:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.326 X-Spam-Level: X-Spam-Status: No, score=-103.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LqX9075PV16f for ; Fri, 24 Jun 2016 04:34:00 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D80A12D0CD for ; Fri, 24 Jun 2016 04:33:59 -0700 (PDT) Received: from vanmetedneysmbp.fletsphone (42.25.30.125.dy.iij4u.or.jp [125.30.25.42]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 30ABB2784A9; Fri, 24 Jun 2016 20:33:58 +0900 (JST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7DC88342-472B-4632-8E25-94AB99E06DCD" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Rodney Van Meter In-Reply-To: Date: Fri, 24 Jun 2016 20:33:57 +0900 Message-Id: <8D457EC4-FF63-42E7-AA19-B8C0E1235095@sfc.wide.ad.jp> References: To: David McGrew X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Shota Nagayama , IPsecME WG , "Panos Kampanakis \(pkampana\)" , "Scott Fluhrer \(sfluhrer\)" , Rodney Van Meter , Paul Wouters , "Waltermire, David A. \(Fed\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 11:34:03 -0000 --Apple-Mail=_7DC88342-472B-4632-8E25-94AB99E06DCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 24, 2016, at 7:06 PM, David McGrew wrote: >=20 > Hi Paul, >=20 >> On Jun 23, 2016, at 6:55 PM, Panos Kampanakis (pkampana) = wrote: >>=20 >> Introducing quantum computer resistance in IKEv2 helps to avoid the = implications of having sec admins that want to have quantum computer = resistance revert back to IKEv1 with shared secrets. The draft adds = quantum resistance using todays infrastructure. The qkd draft introduced = a way to add quantum resistance, but it came with many different = challenges of how practical it is and how costly it would be to = introduce a QKD network. Note that the QKD draft talks in terms of QKD, but the mechanisms = developed are in fact generic to out-of-band generated key material that = must be named and agreed on. The last status of the nagayama draft was = that there was resistance to the concept of QKD from some quarters, and = less resistance from others but no sense of urgency. We were encouraged by the ADs and a few others to rework the draft to = focus more on generic uses of out-of-band generated key material, but we = haven=E2=80=99t managed to put together the right set of hours to get it = done. At least one person said, =E2=80=9CIt may be snake oil, but = you=E2=80=99re entitled to interoperable snake oil,=E2=80=9D with = reference to the fact that we want a published document that has had = input and review and improvements, but certainly recognize that the use = case remains a specialized corner for the moment. But given the work = being done to standardize other parts of QKD inside ETSI, it seems = important to have matching IPsec hooks that will be common, and it=E2=80=99= s especially important to me that IETF retain control to any changes to = IPsec, rather than having another standards organization documenting = changes to protocols developed here, which certainly seems a recipe for = nightmarish politics and non-interoperable implementations. draft-nagayama-ipsecme-ipsec-with-qkd went through both -00 and -01 = drafts a significant time period apart. The protocol in -00 represents = our actual implement with actual QKD devices, from some time ago. Shota = was working at one point to modify the code to match -01; he would have = to remind me how close to complete that code is. The source for the = -00-compliant version is downloadable at http://aqua.sfc.wide.ad.jp/research/ipsecwithqkd.html = =E2=80=94Rod --Apple-Mail=_7DC88342-472B-4632-8E25-94AB99E06DCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 24, 2016, at 7:06 PM, David McGrew <mcgrew@cisco.com> = wrote:

Hi = Paul,

On= Jun 23, 2016, at 6:55 PM, Panos Kampanakis (pkampana) <pkampana@cisco.com> = wrote:

Introducing quantum computer = resistance in IKEv2 helps to avoid the implications of having sec admins = that want to have quantum computer resistance revert back to IKEv1 with = shared secrets. The draft adds quantum resistance using todays = infrastructure. The qkd draft introduced a way to add quantum = resistance, but it came with many different challenges of how practical = it is and how costly it would be to introduce a QKD = network.

Note that the QKD draft talks in terms of QKD, but = the mechanisms developed are in fact generic to out-of-band generated = key material that must be named and agreed on.  The last status of = the nagayama draft was that there was resistance to the concept of QKD = from some quarters, and less resistance from others but no sense of = urgency.

We were encouraged by the = ADs and a few others to rework the draft to focus more on generic uses = of out-of-band generated key material, but we haven=E2=80=99t managed to = put together the right set of hours to get it done. At least one person = said, =E2=80=9CIt may be snake oil, but you=E2=80=99re entitled to = interoperable snake oil,=E2=80=9D with reference to the fact that we = want a published document that has had input and review and = improvements, but certainly recognize that the use case remains a = specialized corner for the moment. But given the work being done to = standardize other parts of QKD inside ETSI, it seems important to have = matching IPsec hooks that will be common, and it=E2=80=99s especially = important to me that IETF retain control to any changes to IPsec, rather = than having another standards organization documenting changes to = protocols developed here, which certainly seems a recipe for nightmarish = politics and non-interoperable implementations.

draft-nagayama-ipsecme-ipsec-with-qkd went through = both -00 and -01 drafts a significant time period apart. The protocol in = -00 represents our actual implement with actual QKD devices, from some = time ago. Shota was working at one point to modify the code to match = -01; he would have to remind me how close to complete that code is. The = source for the -00-compliant version is downloadable at
=

=E2=80=94Rod

= --Apple-Mail=_7DC88342-472B-4632-8E25-94AB99E06DCD-- From nobody Fri Jun 24 06:44:51 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A7712DB2D for ; Fri, 24 Jun 2016 06:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFwgLTXOeD9x for ; Fri, 24 Jun 2016 06:44:46 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C512012DAEA for ; Fri, 24 Jun 2016 06:43:52 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rbffs3GR6z36R; Fri, 24 Jun 2016 15:43:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id scSLu2E0-jRe; Fri, 24 Jun 2016 15:43:16 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 24 Jun 2016 15:43:15 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DCEE1768B26; Fri, 24 Jun 2016 09:43:07 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca DCEE1768B26 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C4CA34001696; Fri, 24 Jun 2016 09:43:07 -0400 (EDT) Date: Fri, 24 Jun 2016 09:43:07 -0400 (EDT) From: Paul Wouters To: David McGrew In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IPsecME WG , "Panos Kampanakis \(pkampana\)" , "Waltermire, David A. \(Fed\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 13:44:49 -0000 On Fri, 24 Jun 2016, David McGrew wrote: Hi David, > Because QKD is not a practical system for Internet security. It has serious security issues/challenges and operational limitations on bitrate, range, and physical media. It requires a point to point optical link, which is typically dedicated fiber, which must be shorter than 60 miles. There are security issues with QKD because it relies on a physical interaction across the line between the encrypter and decrypter, thus giving an attacker the opportunity to perform an attack on the physical process anywhere on that line. See for instance Brassard et. al. Security Aspects of Practical Quantum Cryptography, Lydersen et. al., Hacking commercial quantum cryptography systems by tailored bright illumination, or Gerhardt et. al., Full-field implementation of a perfect eavesdropper on a quantum cryptography system. Another major security problem is the range limitation; it has been proposed to extend the range of QKD by using a chain of trusted repeaters, each connected by a QKD sy stem. These repeaters would greatly increase the attack surface, and require the end user to trust the infrastructure provider(s); in contrast, the Internet community wants end to end encryption, as described in RFC3365 and RFC7624. > > In contrast, QR-IKEv2 can be used to add postquantum security between any two points on the globe, without requiring dedicated fiber, and without requiring physical layer security assumptions. It has *fewer* security assumptions than draft-nagayama-ipsecme-ipsec-with-qkd, as that draft relies on the security of symmetric cryptography and the physical layer, whereas QR-IKEv2 relies only on the former. For a postquantum IKEv2 extension, does it matter which underlying mechanism is used to provide the extra bits to mix into the SKEYSEED? I think what is needed is: - A NOTIFY message that signals an identifier of where the extra bits should be taken/generated from. Both endpoints have previous knowledge of what tjos identifier refers to. Be it a hardware device or an offset in a onetime pad, etc, etc. - A specification on how to mix in these extra bits into SKEYSEED generation to gain postquantum security. - Any additional counter meassures (such as increased minimum keysizes) Do we need to know if these bits came from a QKD link, a QR link, or a mutually shared onetime pad? If not, then these specifics should not go into such an ikev2 extension. Paul From nobody Fri Jun 24 06:47:29 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A292912DAEA for ; Fri, 24 Jun 2016 06:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ7csqMwFdJI for ; Fri, 24 Jun 2016 06:47:27 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5142612DB19 for ; Fri, 24 Jun 2016 06:46:22 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rbfjq0JVCz36S; Fri, 24 Jun 2016 15:45:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qxq21PfE2YDs; Fri, 24 Jun 2016 15:45:50 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 24 Jun 2016 15:45:50 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5F7DF768B26; Fri, 24 Jun 2016 09:45:49 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 5F7DF768B26 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5A0884001696; Fri, 24 Jun 2016 09:45:49 -0400 (EDT) Date: Fri, 24 Jun 2016 09:45:49 -0400 (EDT) From: Paul Wouters To: Rodney Van Meter In-Reply-To: <8D457EC4-FF63-42E7-AA19-B8C0E1235095@sfc.wide.ad.jp> Message-ID: References: <8D457EC4-FF63-42E7-AA19-B8C0E1235095@sfc.wide.ad.jp> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: Shota Nagayama , IPsecME WG , David McGrew , "Panos Kampanakis \(pkampana\)" , "Scott Fluhrer \(sfluhrer\)" , "Waltermire, David A. \(Fed\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 13:47:29 -0000 On Fri, 24 Jun 2016, Rodney Van Meter wrote: > We were encouraged by the ADs and a few others to rework the draft to focus more on generic uses of out-of-band generated key material, > but we haven’t managed to put together the right set of hours to get it done. At least one person said, “It may be snake oil, but you’re > entitled to interoperable snake oil,” with reference to the fact that we want a published document that has had input and review and > improvements, but certainly recognize that the use case remains a specialized corner for the moment. But given the work being done to > standardize other parts of QKD inside ETSI, it seems important to have matching IPsec hooks that will be common, and it’s especially > important to me that IETF retain control to any changes to IPsec, rather than having another standards organization documenting changes > to protocols developed here, which certainly seems a recipe for nightmarish politics and non-interoperable implementations. Agreed. Those groups should really come out of the dark and discuss their proposals at the IETF. Paul From nobody Fri Jun 24 07:06:06 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE7B12B009 for ; Fri, 24 Jun 2016 07:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ku4Fka2YOrdx for ; Fri, 24 Jun 2016 07:06:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD9512DAD6 for ; Fri, 24 Jun 2016 07:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2946; q=dns/txt; s=iport; t=1466777162; x=1467986762; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wuSAj9wTgExvSgyZs1qArLHPkFSF3ZBqo53t4j/o0pc=; b=aF2s4VuYcS6QpGJfMn8wYlsWeKwiXDdlENB/tMhJb8dsC2whmBcvNrLZ qh4K6zs/5ao/QDw34mZfqlXUOYfh737sq1dZA7dWVMpENNZlrc63eoPO9 l4gQ756Ei00i6XbVxXB72pPLYGzzDX37m668+YDagJe5Szck8ToquJ3UL I=; X-IronPort-AV: E=Sophos;i="5.26,521,1459814400"; d="scan'208";a="116496151" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jun 2016 14:06:01 +0000 Received: from rtp-mcgrew-8915.cisco.com (rtp-mcgrew-8915.cisco.com [10.117.10.230]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u5OE605b022766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2016 14:06:01 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: David McGrew In-Reply-To: Date: Fri, 24 Jun 2016 10:05:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <82CD3C97-9C93-4AE9-82FE-56F974820118@cisco.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IPsecME WG , "Panos Kampanakis \(pkampana\)" , "Waltermire, David A. \(Fed\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 14:06:05 -0000 Hi Paul, > On Jun 24, 2016, at 9:43 AM, Paul Wouters wrote: >=20 > On Fri, 24 Jun 2016, David McGrew wrote: >=20 > Hi David, >=20 >> Because QKD is not a practical system for Internet security. It has = serious security issues/challenges and operational limitations on = bitrate, range, and physical media. It requires a point to point = optical link, which is typically dedicated fiber, which must be shorter = than 60 miles. There are security issues with QKD because it relies on = a physical interaction across the line between the encrypter and = decrypter, thus giving an attacker the opportunity to perform an attack = on the physical process anywhere on that line. See for instance = Brassard et. al. Security Aspects of Practical Quantum Cryptography, = Lydersen et. al., Hacking commercial quantum cryptography systems by = tailored bright illumination, or Gerhardt et. al., Full-field = implementation of a perfect eavesdropper on a quantum cryptography = system. Another major security problem is the range limitation; it has = been proposed to extend the range of QKD by using a chain of trusted = repeaters, each connected by a QKD sy > stem. These repeaters would greatly increase the attack surface, and = require the end user to trust the infrastructure provider(s); in = contrast, the Internet community wants end to end encryption, as = described in RFC3365 and RFC7624. >>=20 >> In contrast, QR-IKEv2 can be used to add postquantum security between = any two points on the globe, without requiring dedicated fiber, and = without requiring physical layer security assumptions. It has *fewer* = security assumptions than draft-nagayama-ipsecme-ipsec-with-qkd, as that = draft relies on the security of symmetric cryptography and the physical = layer, whereas QR-IKEv2 relies only on the former. >=20 > For a postquantum IKEv2 extension, does it matter which underlying > mechanism is used to provide the extra bits to mix into the SKEYSEED? yes, if identity hiding, efficiency, and incremental deployability = matter; please see the rationale in Appendix A of = https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-01. =20 thanks David >=20 > I think what is needed is: >=20 > - A NOTIFY message that signals an identifier of where the extra bits > should be taken/generated from. Both endpoints have previous = knowledge > of what tjos identifier refers to. Be it a hardware device or an > offset in a onetime pad, etc, etc. >=20 > - A specification on how to mix in these extra bits into SKEYSEED = generation > to gain postquantum security. >=20 > - Any additional counter meassures (such as increased minimum = keysizes) >=20 > Do we need to know if these bits came from a QKD link, a QR link, or a > mutually shared onetime pad? If not, then these specifics should not = go > into such an ikev2 extension. >=20 > Paul From nobody Fri Jun 24 07:58:30 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54A312D150 for ; Fri, 24 Jun 2016 07:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dexlljcMeiDc for ; Fri, 24 Jun 2016 07:58:26 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0092.outbound.protection.outlook.com [23.103.200.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4A412D134 for ; Fri, 24 Jun 2016 07:58:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0Z3e5EhNQWIvZh9pySoy2wC4zciDwHDSNjwQtr9nm3E=; b=HonyByPqgcp1wi1JpHACKWpPJC+b8bFPgqQty85w+czLzDRXphpPR2yCHovD4+tVDZ/O9xjk1OhNrkAkcAfzbrcld2TTTd1rNsRsTRyo5ym2YalY79XjB4ru2WAbgn87fR53uYrb+lkqgbNbVjSj6dlsYXy+a69gQffLWjDo07I= Received: from DM2PR09MB0665.namprd09.prod.outlook.com (10.161.144.16) by DM2PR09MB0666.namprd09.prod.outlook.com (10.161.144.17) with Microsoft SMTP Server (TLS) id 15.1.523.12; Fri, 24 Jun 2016 14:58:25 +0000 Received: from DM2PR09MB0665.namprd09.prod.outlook.com ([10.161.144.16]) by DM2PR09MB0665.namprd09.prod.outlook.com ([10.161.144.16]) with mapi id 15.01.0523.019; Fri, 24 Jun 2016 14:58:25 +0000 From: "Waltermire, David A. (Fed)" To: "paul@nohats.ca" , David McGrew Thread-Topic: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document Thread-Index: AdHMq6AaWm7UWPXSRFyRus61cfvSJAAEUKcAADlbKIAAF2ytAAAHlSyAAAKEQFA= Date: Fri, 24 Jun 2016 14:58:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr,ExtAddr x-ms-office365-filtering-correlation-id: bd8eaf0b-3938-4277-d185-08d39c3ffe40 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0666; 6:Z5drfcsQjbgmqm96c5nRFyR+r/WSBWYc52Zl88gBpVW5AU4k1j2th+uRJTaI2KYHd50CJP/7Me3Jiseqi74jNm+EgYqul2Kwbjq5HigJhIMJbCM6VityY6PHMeCg+oJgcJ3azyG4vKrG2FjjkgEFh3VN4fRhxr1honEEaADv2ZM/j6OUaTTucsX2mEh3hB+by2XxFvBSH3+jbg8dNpvcPJYhlrsOPrjFL0iN6tfAnPJgTlKu8//eBYESIToSCGvXQLPFCuNmR+z9idlE/CIsjpDeOLcg2LQ17+wZG+EWyRBKFtNWxHShJB5x2SRNjli7zzlQpv5oaA7pUWvtQLr+O5SxlWyopDywLps9K5Wz/Q8=; 5:j5CNolMe4ztO9Cs7t3H2ekJgKG8jkiWk++sI3dGkFDrhwPK0Hl1eitCXir+LwdUKe8C3bIplxJcd2TQTF1IeiTYw6MWCwPJvm4pdj3woYeu3BzN4wb1HTeID7BKyqXbSeoygGyHXrbkHbMaC7mf2dA==; 24:w88Iz2l5NlImJd4P9bqfCUnRWFwz8HSb7tv7Rm75FbOR9/BoWSiWBpwbsRuMfZfKCABB7wmf/c+HGhg4FqEV4qwfpq9vI4k+CT4cVc5N4xM=; 7:ddWbtP1ojUJNxJ9udq9xiDGgawbphSoTBe412me1xaxrNX6H8UZrBR1Wm9LhWKBb53QcDPU3p1gwLv7PXeNTusYEcKGKOJMqov4DwTYOlCeJzYKCYob6fO7w1yDgr/VPIzA2SxgLHCcJLaHbzDxpSkKtcpQllVsjJCbl2Zidh1JxjtB0arez4V5+cNe9x+OqAe56lWtcN+aTXsIRjHHQ6mSrbEBbFErEKicpUNlnpJWdYVn2yn0/reNBM6LNfuc1cjyQAenIXsxRp/IMzEh4Cg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0666; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:DM2PR09MB0666; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0666; x-forefront-prvs: 0983EAD6B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(57704003)(189002)(199003)(81166006)(8676002)(92566002)(66066001)(5003600100003)(3280700002)(50986999)(93886004)(74316001)(2950100001)(7736002)(2900100001)(3660700001)(5001770100001)(7696003)(122556002)(7846002)(97736004)(81156014)(5002640100001)(86362001)(2906002)(10400500002)(4326007)(99286002)(9686002)(77096005)(68736007)(189998001)(33656002)(106356001)(105586002)(586003)(6116002)(102836003)(11100500001)(87936001)(3846002)(8936002)(2501003)(76576001)(76176999)(54356999)(101416001)(230783001)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0666; H:DM2PR09MB0665.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2016 14:58:24.6200 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0666 Archived-At: Cc: IPsecME WG , "Panos Kampanakis \(pkampana\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 14:58:29 -0000 Comments below. > > In contrast, QR-IKEv2 can be used to add postquantum security between > any two points on the globe, without requiring dedicated fiber, and witho= ut > requiring physical layer security assumptions. It has *fewer* security > assumptions than draft-nagayama-ipsecme-ipsec-with-qkd, as that draft > relies on the security of symmetric cryptography and the physical layer, > whereas QR-IKEv2 relies only on the former. >=20 > For a postquantum IKEv2 extension, does it matter which underlying > mechanism is used to provide the extra bits to mix into the SKEYSEED? >=20 > I think what is needed is: >=20 > - A NOTIFY message that signals an identifier of where the extra bits > should be taken/generated from. Both endpoints have previous > knowledge > of what tjos identifier refers to. Be it a hardware device or an > offset in a onetime pad, etc, etc. >=20 > - A specification on how to mix in these extra bits into SKEYSEED generat= ion > to gain postquantum security. >=20 > - Any additional counter meassures (such as increased minimum keysizes) >=20 > Do we need to know if these bits came from a QKD link, a QR link, or a > mutually shared onetime pad? If not, then these specifics should not go i= nto > such an ikev2 extension. Could this be done in multiple drafts? One to generalize the approach and o= ther drafts to discuss the acquisition methods (e.g., QKD link, QR identifi= er, etc). Thanks, Dave From nobody Fri Jun 24 08:26:13 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6358D12B029 for ; Fri, 24 Jun 2016 08:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYHFWTkYPdv1 for ; Fri, 24 Jun 2016 08:26:10 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3EDC12D0AC for ; Fri, 24 Jun 2016 08:26:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3995; q=dns/txt; s=iport; t=1466781970; x=1467991570; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=R6NmIrfS75huYiv26ufG7hiixoWk5Qvr7abOeCjpbI0=; b=b60LhTD3GAnf6VIEelMR11xuhGiNZ8a18wXHSQEXwXP3/Zd4FKrvbK2v KXKKkGATt6E49XuwaOGYFYYUgRDE92jQjeTh49nkj6lrrUgAFsrx8QInc QEAGFqy9TEzv355YOZNk3M9yVS94rDWy3QEZ8dkbAwpH6oJjeJ6VVavYT A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgDwT21X/4oNJK1cgz6BUwa6IIF7h?= =?us-ascii?q?hgCgTI4FAEBAQEBAQFlJ4RMAQEBAwEdHTIKAwwEAgEIEQQBAQEeCQcyFAkIAgQ?= =?us-ascii?q?BDQUIDIgUCMccAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIYohE2Jfh0FmQABjiyPK?= =?us-ascii?q?o99AR42gjuBNW6IMX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,521,1459814400"; d="scan'208";a="121492059" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 24 Jun 2016 15:26:09 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u5OFQ9f7016639 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Jun 2016 15:26:09 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 24 Jun 2016 11:26:08 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1104.009; Fri, 24 Jun 2016 11:26:08 -0400 From: "Scott Fluhrer (sfluhrer)" To: Paul Wouters , "David McGrew (mcgrew)" Thread-Topic: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document Thread-Index: AQHRzL5IGlp/kxuNuk2jW8rWXL/+i5/37jCAgAC7ZQCAADyqgP//1znQ Date: Fri, 24 Jun 2016 15:26:08 +0000 Message-ID: <6c8f674e54b1483db684b261a8109378@XCH-RTP-006.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IPsecME WG , "Waltermire, David A. \(Fed\)" , "Panos Kampanakis \(pkampana\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 15:26:12 -0000 > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: Friday, June 24, 2016 9:43 AM > To: David McGrew (mcgrew) > Cc: Waltermire, David A. (Fed); IPsecME WG; Scott Fluhrer (sfluhrer); Pan= os > Kampanakis (pkampana) > Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IP= SecME > WG document >=20 > On Fri, 24 Jun 2016, David McGrew wrote: >=20 > Hi David, >=20 > > Because QKD is not a practical system for Internet security. It has s= erious > security issues/challenges and operational limitations on bitrate, range,= and > physical media. It requires a point to point optical link, which is typ= ically > dedicated fiber, which must be shorter than 60 miles. There are security > issues with QKD because it relies on a physical interaction across the li= ne > between the encrypter and decrypter, thus giving an attacker the > opportunity to perform an attack on the physical process anywhere on that > line. See for instance Brassard et. al. Security Aspects of Practical Q= uantum > Cryptography, Lydersen et. al., Hacking commercial quantum cryptography > systems by tailored bright illumination, or Gerhardt et. al., Full-field > implementation of a perfect eavesdropper on a quantum cryptography > system. Another major security problem is the range limitation; it has = been > proposed to extend the range of QKD by using a chain of trusted repeaters= , > each connected by a QKD sy > stem. These repeaters would greatly increase the attack surface, and > require the end user to trust the infrastructure provider(s); in contrast= , the > Internet community wants end to end encryption, as described in RFC3365 > and RFC7624. > > > > In contrast, QR-IKEv2 can be used to add postquantum security between > any two points on the globe, without requiring dedicated fiber, and witho= ut > requiring physical layer security assumptions. It has *fewer* security > assumptions than draft-nagayama-ipsecme-ipsec-with-qkd, as that draft > relies on the security of symmetric cryptography and the physical layer, > whereas QR-IKEv2 relies only on the former. >=20 > For a postquantum IKEv2 extension, does it matter which underlying > mechanism is used to provide the extra bits to mix into the SKEYSEED? >=20 > I think what is needed is: >=20 > - A NOTIFY message that signals an identifier of where the extra bits > should be taken/generated from. Both endpoints have previous > knowledge > of what tjos identifier refers to. Be it a hardware device or an > offset in a onetime pad, etc, etc. One possible concern is whether such a notify message would compromise the = anonymity properties of IKE; if someone in the middle sees the same identif= ier in multiple exchanges, would they be able to conclude that those are th= e same individuals negotiating? If the NOTIFY messages are anonymized, how= is that done? Now, it might be that the WG would decide to compromise on such anonymizati= on concerns; this would simplify things a lot, however it's very much somet= hing we need WG agreement on. >=20 > - A specification on how to mix in these extra bits into SKEYSEED generat= ion > to gain postquantum security. The reason we specify modifying the public nonces (rather than doing a more= fundamental change to the skeyseed computation) was to minimize changes to= the IKE implementation itself (and in particular, the crypto parts). Is t= here a reason why we wouldn't continue with this approach? >=20 > - Any additional counter meassures (such as increased minimum keysizes) And what algorithms are suggested (e.g. XCBC and CMAC both don't work, as t= he standard IKE versions are fixed to 128 bit keys) >=20 > Do we need to know if these bits came from a QKD link, a QR link, or a > mutually shared onetime pad? If not, then these specifics should not go i= nto > such an ikev2 extension. >=20 > Paul From nobody Fri Jun 24 09:04:35 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC7212DC84; Fri, 24 Jun 2016 09:00:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160049.10933.77095.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:49 -0700 Archived-At: Cc: ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 96 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:50 -0000 Dear David Waltermire, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (2:00:00) Tuesday, Afternoon Session I 1400-1600 Room Name: Charlottenburg I size: 80 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: David Waltermire Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: First Priority: mile sacm tcpinc curdle tls saag cfrg Second Priority: 6tisch lwig ace httpauth Third Priority: uta 6lo dane tcpm netmod Special Requests: --------------------------------------------------------- From nobody Fri Jun 24 15:04:02 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D01F12D6A7 for ; Fri, 24 Jun 2016 15:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.327 X-Spam-Level: X-Spam-Status: No, score=-103.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2upZiWMajm9 for ; Fri, 24 Jun 2016 15:03:57 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277DC12D7A2 for ; Fri, 24 Jun 2016 15:03:56 -0700 (PDT) Received: from vanmetedneysmbp.fletsphone (42.25.30.125.dy.iij4u.or.jp [125.30.25.42]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 239A127850D; Sat, 25 Jun 2016 07:03:55 +0900 (JST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Rodney Van Meter In-Reply-To: Date: Sat, 25 Jun 2016 07:03:53 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David McGrew X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPsecME WG , "Panos Kampanakis \(pkampana\)" , "Scott Fluhrer \(sfluhrer\)" , Rodney Van Meter , Paul Wouters , "Waltermire, David A. \(Fed\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 22:04:00 -0000 > On Jun 24, 2016, at 7:06 PM, David McGrew wrote: >=20 >=20 > Because QKD is not a practical system for Internet security. It has = serious security issues/challenges and operational limitations on = bitrate, range, and physical media. It requires a point to point = optical link, which is typically dedicated fiber, which must be shorter = than 60 miles. There are security issues with QKD because it relies on = a physical interaction across the line between the encrypter and = decrypter, thus giving an attacker the opportunity to perform an attack = on the physical process anywhere on that line. See for instance = Brassard et. al. Security Aspects of Practical Quantum Cryptography, = Lydersen et. al., Hacking commercial quantum cryptography systems by = tailored bright illumination, or Gerhardt et. al., Full-field = implementation of a perfect eavesdropper on a quantum cryptography = system. All of these things are true for existing technology. > Another major security problem is the range limitation; it has been = proposed to extend the range of QKD by using a chain of trusted = repeaters, each connected by a QKD syst > em. These repeaters would greatly increase the attack surface, and = require the end user to trust the infrastructure provider(s); in = contrast, the Internet community wants end to end encryption, as = described in RFC3365 and RFC7624. The technology is evolving rapidly. We can now talk about the existence of a quantum IT industry; there are billions of dollars of government and VC and big company money, and at least a dozen startups that are out in the open, half in quantum computing and half in QKD. Over the next few years, a lot will happen. Most importantly in this context, it's very important to recognize that there is a YUUGE technological difference between networks that create and use long-distance quantum entanglement, versus those that use only quantum effects on single photons. Entanglement-based networks are way harder to build, but will solve the distance problems and enable many applications besides just QKD. =20 If appropriate constraints on architecture (both hardware and protocols) are put into place at the beginning, I believe it is also possible to *guarantee* that the system avoids the kind of hacks that plague existing QKD systems; the keys are the need to perform certain quantum operations on quantum data (qubits) that are *optically isolated* from the (possibly compromised) inter-node channel, and to have adequate classical random number generators available each node. But that's an area where things are still kind of settling out, and it's not yet technically feasible. I gave a talk last year at Verisign on applications of quantum networks, focusing on *entangled* networks. I divide quantum networking apps into three areas: distributed cryptographic functions, sensor networks, and distributed digital computation. QKD sits at the border of dist crypto and sensors. If you know nothing about the topic, I suggest you start at the beginning, but if you want to skip the background (at any rate, all done without any serious math), scroll forward to the 20:30 mark, where the discussion of classes of applications of distributed entanglement begins. At 23:50, I begin discussing QKD. At about 27:00, I start discussing different usage scenarios in a way that I think is particularly relevant to this conversation. = https://www.verisign.com/en_IN/innovation/verisign-labs/speakers-series/qu= antum-networks/index.xhtml Apologies, but one more plug for our work: in 2014, I published a book on Quantum Networking. http://as.wiley.com/WileyCDA/WileyTitle/productCd-1848215371.html (Apologies for the horrific price, I didn't set it and I'm appalled.) There is only a little discussion of QKD in it, but there is a lot of basic background on quantum teleportation and discussion of leading-edge work on quantum repeaters. The last third of the book is about quantum *networks* (as opposed to just chains of repeaters), an area where my research group is just about the only group in the world working. We recently published a paper on quantum *internetworking*, http://arxiv.org/abs/1508.04599. On a different topic, IEEE has recently started a standardization project aimed at interoperability at the network control level, using software defined networking (SDN for QKD), P1913 - Software-Defined Quantum Communication, https://standards.ieee.org/develop/project/1913.html. Enough for now, --Rod From nobody Mon Jun 27 03:14:47 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D665212D0A6; Mon, 27 Jun 2016 03:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoBRMjCw69r7; Mon, 27 Jun 2016 03:14:43 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD19128E18; Mon, 27 Jun 2016 03:14:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 8E7B33F807; Mon, 27 Jun 2016 12:14:42 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id w3LP5fWfmdaM; Mon, 27 Jun 2016 12:14:42 +0200 (CEST) Received: from inf-205-171.inf.um.es (inf-205-171.inf.um.es [155.54.205.171]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id 1A8C93FB74; Mon, 27 Jun 2016 12:14:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657ED6A35@dfweml501-mbb> Date: Mon, 27 Jun 2016 12:14:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <7C1028FB-4531-4BA8-9C64-AE933945539F@um.es> <4A95BA014132FF49AE685FAB4B9F17F657ECCD0E@dfweml501-mbb> <466D704F-4C9B-45FB-AE68-841896D29B72@um.es> <4A95BA014132FF49AE685FAB4B9F17F657ED6A35@dfweml501-mbb> To: Linda Dunbar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "I2NSF@ietf.org" , "IPsec@ietf.org" , Sowmini Varadhan , Rafa Marin Lopez , Sowmini Varadhan Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 10:14:46 -0000 Hi Linda: > El 23 jun 2016, a las 23:13, Linda Dunbar = escribi=C3=B3: >=20 > Rafa,=20 >=20 >=20 >=20 >=20 > Please be aware that some reactive (upon an event) behavior may be = required even when the controller sets up the IPsec policies/keys = proactively. For example, the PF_KEY interface (RFC 2367) in the kernel = has an =E2=80=9Cevent=E2=80=9D >=20 > [Linda]I see. Those "events" definitely need to be addressed by the = data model between controller and end points. It is helpful to describe = the information model.=20 [Rafa] Good to know. >=20 >=20 > "The SADB_EXPIRE message is sent from the kernel to key management > applications when the "soft lifetime" or "hard lifetime" of a > Security Association has expired. Key management applications = should > use receipt of a soft lifetime SADB_EXPIRE message as a hint to > negotiate a replacement SA so the replacement SA will be ready and = in > the kernel before it is needed.=E2=80=9D >=20 > This is a kind of asynchronous event, which is important because it = allows the controller to react and update the SAs. Is this kind of event = in the I2NSF scope?=20 >=20 > In any case we are going to modify the I-D to show all these aspects. > [Linda] Thanks. Are you going to take the relevant portion in the I-D = for I2NSF WG? Or are you going to keep in the SDNrg? [Rafa] We will bring these modifications to I2NSF WG. Best Regards > =20 >=20 >=20 > Some comments inline: >=20 >>=20 >>=20 >> Other comments are inserted below >>=20 >>=20 >> -----Original Message----- >> From: Rafa Marin Lopez [mailto:rafa@um.es] >> Sent: Sunday, June 19, 2016 1:06 PM >> To: Linda Dunbar >> Cc: Rafa Marin Lopez; I2NSF@ietf.org; IPsec@ietf.org; Sowmini=20 >> Varadhan; Sowmini Varadhan >> Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the = Underlay network on which flows among Overlay network nodes need to go = through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF = service layer interface? >>=20 >> >>>=20 >>> - Section 8.1: Page 11: Bullet 1: >>> You stated that the node sends the first packet to Controller for = the controller to determine if the traffic needs to go through IPSec = tunnel.=20 >>>=20 >>> Shouldn't the controller get flow protection policy from clients = (north bound interface) and inform the needed end nodes on what = traffic/flows need to go through the IPSec tunnel? >>=20 >> [Rafa] Actually, there are two options. The one shown in the I-D is = reactive, that is, very similar as it would happen with the OpenFlow = PacketIn message and then PacketOut. The other option, of course, it is = to create the rules in the network resource even when traffic has not = been observed yet (proactive). Both options are completely possible. We = can clarify this in the next version. >>=20 >> [Linda] so the I2NSF should only focus on specifying the protocols = and data models for the =E2=80=9CProtective=E2=80=9D methods. Maybe part = of your draft can be further developed in I2NSF WG.=20 >>=20 >>>=20 >>>=20 >>> - Section 8.1: Page 12: Bullet 3: >>> The controller can't really enforce the rule. but instead requesting = the "End Node" to encapsulate the IPSec tunnel around the flows that = need to be through the IPSec tunnel. correct? >>=20 >> [Rafa] Not sure why you think the controller can=E2=80=99t enforce = the rule. Basically the step 3 says the controller is filling a SAD = entry without the need of running IKE between network resources. >>=20 >> [Linda] Are you assuming that data packets actually traversing the = =E2=80=9CController=E2=80=9D? If yes, the I2NSF focus on the flow policy = north bound to the controller.=20 >=20 > [Rafa] It is not traverse but it is to check the first data packet in = a flow to see there is need for security or not. But certainly that = belongs to southbound interface. >=20 >>=20 >>=20 >>=20 >>>=20 >>> - Section 6, Page 7, Second paragraph after the Figure 2:=20 >>> The Controller should send the IPSec tunnel request to the end = points of the desired IPSec tunnel. Also the controller should send = query to the end point to check if they have the needed resource to = establish the desired IPSec tunnel. >>=20 >> [Rafa] What do you mean with =E2=80=9CIPsec tunnel request=E2=80=9D? = By sending the information related with the IPsec tunnel (e.g. a SAD = entry) to build it should be enough, I guess that is what you mean by = that , right?. >>=20 >> [Linda] Yes.=20 >>=20 >>=20 >> The controller can of course verify if the end points of the IPsec SA = have the information to establish an IPsec tunnel according to the = information that the controller keeps. If the state is not there or is = going to be outdated it can enforce the information again. = Alternatively, the end points could also inform when something is = required to the controller (reactive) so the controller can act = accordingly. >>=20 >> [Linda] above is what I call =E2=80=9Cquery=E2=80=9D. Need to flush = out the detailed data model for your IPSec case in I2NSF WG.=20 >>=20 >>=20 >>>=20 >>> - Section 8.2:=20 >>> Second paragraph: When the two end points of the needed IPSec tunnel = are in two different ISPs (say ISP-A and ISP-B), your draft states that = the ISP-A controller has to negotiate with ISP-B controller on the Flow = Security policy rules. What information will be carried by those Policy = Rules? Since I2NSF is to specify the data models for those rules, it = would be very helpful to identify the information exchanged first.=20 >>=20 >> [Rafa] We can specify better what information in the following draft. = But basically we have two models explained in the draft when 1) IKE is = implemented in the network resource or when IKE is not implemented in = the network resource. =20 >>=20 >> In 1) parameters to run an IKE SA between GW1 and GW2 must be = negotiated (IKE credential, cryptographic suite, etc=E2=80=A6) and the = different SPD entries of the SPD that apply. An SPD entry has parameters = such as Remote IP Address, Local IP Address, Next Layer Protocol, Name, = Local and Remote Ports. >>=20 >> In 2) apart from SPD entries you need to configure SAD entries. This = information implies Security Parameter Index, Sequence Number, AH = information (keys , key lifetime) , ESP information=E2=80=A6 etc. >>=20 >> We can detail what information is required. >>=20 >> [Linda] that will be useful. Can you write this detailed information = exchange for I2NSF?=20 >=20 > [Rafa] We think so yes. >=20 > Best Regards. >=20 >>=20 >>=20 >>>=20 >>> Page 13: bullet 2: before the negotiation between the two = controllers on the SPD policies and IKE credentials, don't you think = that they need to inquire each other if the other party has the needed = resource for the needed IPsec tunnel?=20 >>=20 >> [Rafa] But for that, what kind of parameters do you send to ask the = question? I can imagine you could ask : do you have an end point with = this IP address, IKE support, AH or ESP support=E2=80=A6 etc=E2=80=A6? = Is that what you have in mind? >>=20 >> In any case, if they do not have that support trying the negotiation = between the two controllers would fail so that you would notice that the = needed resource is not available as well, right? >>=20 >>=20 >> [Linda] correct.=20 >>=20 >> Thanks, Linda >>=20 >>=20 >>=20 >>=20 >> Best Regards. >>>=20 >>>=20 >>>=20 >>> Thanks, Linda >>>=20 >>> -----Original Message----- >>> From: Rafa Marin Lopez [mailto:rafa@um.es] >>> Sent: Friday, June 17, 2016 7:43 AM >>> To: Linda Dunbar >>> Cc: Rafa Marin Lopez; Sowmini Varadhan; I2NSF@ietf.org; Sowmini=20 >>> Varadhan; NVO3; Liyizhou >>> Subject: Re: [I2nsf] How does Overlay Network inform the Underlay = network on which flows among Overlay network nodes need to go through = IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service = layer interface? >>>=20 >>> Dear all: >>>=20 >>> Maybe this I-D might be interesting and related with this discussion = regarding IPsec/IKE management. We hope to have an updated version soon = and a proof-of-concept implementation of some of the scenarios. >>>=20 >>> https://tools.ietf.org/html/draft-abad-sdnrg-sdn-ipsec-flow-protecti >>> on >>> -01 >>>=20 >>> Best Regards. >>>=20 >>>=20 >>>> El 17 jun 2016, a las 10:43, Linda Dunbar = escribi=C3=B3: >>>>=20 >>>> Sowmini, >>>>=20 >>>> You said: >>>> =E2=80=9CHowever, applying IPsec to specific flows (e.g., those = defined by a src or dst port on which the service listens) is = important.=E2=80=9D >>>>=20 >>>> What is the current operation procedure for Overlay network to = inform the underlay network on which flows to go through IPSec channel?=20= >>>>=20 >>>> You said:=20 >>>> =E2=80=9C..But that also made me wonder about the interaction = between IPsec/IKE and the proposed BGP FS (IPsec is frequently used = between end-systems that do not want to run a BGP daemon). Since the = config information that needs to be distributed are things like keys, = algorithms etc to populate the sadb/spd, IKE looks more appropriate in = most cases.=E2=80=9D >>>>=20 >>>>=20 >>>> Does the underlay network controller get some information (or hint = from the Overlay network controller) on how the keys are configured for = the IPSec tunnel for the specific flows among the Overlay nodes?=20 >>>>=20 >>>>=20 >>>> Thanks, >>>> Linda >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Sowmini Varadhan [mailto:sowmini05@gmail.com] >>>> Sent: Thursday, June 16, 2016 10:57 AM >>>> To: Linda Dunbar >>>> Cc: Liyizhou; NVO3; Sowmini Varadhan >>>> Subject: Re: [nvo3] FW: Any use cases of Overlay network requesting = IPSec connection from the Underlay for a specific time span? (was : Flow = Security Policies exchanged over I2NSF service layer interface? >>>>=20 >>>> On Wed, Jun 15, 2016 at 8:55 AM, Linda Dunbar = wrote: >>>>>=20 >>>>> NVO3 Participants, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I2NSF (Interface to Network Security function) has a work item in = defining the flow security policy between domains (which includes = inquiry of the capability from one domain to another and the actual flow = policy rules from one domain to another). >>>>>=20 >>>>> Very often, the paths (or links) among nodes of a overlay network = are provided by other network operators (a.k.a. =E2=80=9Cunderlay = network=E2=80=9D). The flow policy rules are intended to filter out = unwanted traffic from underlay network so that various attack traffic = won=E2=80=99t saturated the access links to the overlay nodes. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> One interesting scenario brought up is Overlay nodes may need to = request some traffic to be traversing IPsec channel. To achieve this = goal, it is necessary for Overlay Network controller to inquire if the = needed IPsec resource are even available before send the request (may = even involve AAA process between controllers of each corresponding = domain ). >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Want to have a survey if people see the use case of Overlay = Network needing portion of traffic to be through IPSec channel? >>>>=20 >>>> Yes, this is a valid use case, and one that we are looking at as = well. >>>>=20 >>>>> IPSec is supposed to be between two end nodes. Here we assume that = the Overlay nodes don=E2=80=99t have the resource or capability for = IPsec, but expect IPsec between flow=E2=80=99s ingress and egress nodes = (i.e. NVE). >>>>> Any opinion is appreciated. >>>>=20 >>>>=20 >>>>>=20 >>>>> Are there any use cases of overlay network needing IPSec among = their nodes only for a specific time span? i.e. Time based IPSec = connection? >>>>=20 >>>> Time based IPsec connection is not a use-case we have encountered. >>>> People usually use IKE for periodic key-rollover, if that is the = goal. >>>>=20 >>>> However, applying IPsec to specific flows (e.g., those defined by a = src or dst port on which the service listens) is important. >>>>=20 >>>> But that also made me wonder about the interaction between = IPsec/IKE and the proposed BGP FS (IPsec is frequently used between = end-systems that do not want to run a BGP daemon). Since the config = information that needs to be distributed are things like keys, = algorithms etc to populate the sadb/spd, IKE looks more appropriate in = most cases. >>>>=20 >>>> Like [CJ], I too have to read the draft in greater detail to = comment further. >>>>=20 >>>> --Sowmini >>>>=20 >>>> _______________________________________________ >>>> I2nsf mailing list >>>> I2nsf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2nsf >>>=20 >>> ------------------------------------------------------- >>> Rafael Marin Lopez, PhD >>> Dept. Information and Communications Engineering (DIIC) Faculty of=20= >>> Computer Science-University of Murcia >>> 30100 Murcia - Spain >>> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >>> ------------------------------------------------------- >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >> ------------------------------------------------------- >> Rafael Marin Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) Faculty of=20 >> Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) Faculty of = Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Mon Jun 27 07:05:07 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC61712D58A; Mon, 27 Jun 2016 07:05:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160627140505.5379.34019.idtracker@ietfa.amsl.com> Date: Mon, 27 Jun 2016 07:05:05 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 14:05:06 -0000 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 of the IETF. Title : TCP Encapsulation of IKE and IPSec Packets Authors : Tommy Pauly Samy Touati Ravi Mantha Filename : draft-ietf-ipsecme-tcp-encaps-00.txt Pages : 19 Date : 2016-06-24 Abstract: This document describes a method to transport IKE and IPSec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending all packets for tunnel establishment as well as tunneled packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 27 22:38:13 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F35612D9E3 for ; Mon, 27 Jun 2016 22:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAh_8Pu_BCel for ; Mon, 27 Jun 2016 22:38:09 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 492EA12D9D9 for ; Mon, 27 Jun 2016 22:38:09 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id f6so3645059lfg.0 for ; Mon, 27 Jun 2016 22:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=QjgpFgDuC//GnAjf4X8NXeLt0io9r2qxdkemY0Y5ReE=; b=KSZfdI9ZVXFiBtLdVLL+KGiUGTYoUeRzcBTmcWlSW1RqMzTE8uh0weyh+ZWaUJwdUA WL3oIviEwNMSaX+2ZWUxdR1h1f2xNsfFR4QVDZAdSMD7HXoN2XQpno95WnINmk9FECX8 w9BFrGQ/9p+nLJtoMPkJ2mkpOPS4tkJ36gdFRy+nt73bmXuAfgwXuPkzkdS7isB5EKw9 KXwV8pUnLpzqE/7BARv2A7SNc1N6bOo6duDJVR06XrjBPtqx3cQAxO5n9Mc52VZuoUMt tLVmM/oFB2W0UkriCJGIlpFw/XVbR4PsGB2Lw4B0Hy4898dfgZur5Lw4JKvnYKuXeh1m uUtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=QjgpFgDuC//GnAjf4X8NXeLt0io9r2qxdkemY0Y5ReE=; b=OvZGeSSCgUUCizEaFsWJCrok304/ni0oCPXyAgzD+jiV9COwutkkgcbD4k8trE3WrE DJa9VeLbZ8D/cDsh61sjgScBMF3ABqE9PlL5NKFxiuz+pVcCUaYVJkXAQKeIf2P3qbCx ygwSDU3UwPW0mWdPGBL+fCTWizvx0xPvtF7v8f6TwH2NcalsY864cqHZOZwEbzM+j6AW x6XMWZ5uyJfVYlqdfipM9JeM5GtHP47dtrUr1VXQC62x1nQ03E0qnFdRgnfdSevZ1R0Q y8ULNL149AvKnFSd0fFgxuVX+WtMzKS/5zOqLgXYuhZzivM5gpeVCP+Gznas3MU99+eD qiwA== X-Gm-Message-State: ALyK8tJcAwYQRBNP22q6QJiL4OhIhY5ZpXEhDKDT0Ov6ccMkWSOWDbxjIYS9gvJC7KNdqA== X-Received: by 10.25.145.211 with SMTP id t202mr375828lfd.230.1467092287421; Mon, 27 Jun 2016 22:38:07 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g193sm1641470lfb.14.2016.06.27.22.38.06 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Mon, 27 Jun 2016 22:38:06 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <4200F5373D5542C985F3D4C51609213C@buildpc> Date: Tue, 28 Jun 2016 08:37:58 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 05:38:11 -0000 HI Paul, >> I'd rather change it a bit: >> >> When the Responder is under attack, it SHOULD prefer previously >> authenticated peers who present a Session Resumption ticket [RFC5723]. >> However, the Responder SHOULD NOT swich to resumed clients >> completely (and thus refuse every IKE_SA_INIT request), >> so that legitimate initiators without resumption tickets still have >> chances to connect. > > Ok, minor change: > > When the Responder is under attack, it SHOULD prefer previously > authenticated peers who present a Session Resumption ticket [RFC5723]. > However, the Responder SHOULD NOT serve resumed Initiators exclusively > because dropping all IKE_SA_INIT requests would lock out legitimate > Initiators that have no resumption ticket. Works for me. Regards, Valery. From nobody Tue Jun 28 01:59:26 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE07012DB54 for ; Tue, 28 Jun 2016 01:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN_L5yhISRNJ for ; Tue, 28 Jun 2016 01:59:24 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9A612B062 for ; Tue, 28 Jun 2016 01:59:23 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id q132so6611509lfe.3 for ; Tue, 28 Jun 2016 01:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-transfer-encoding; bh=Ki9BgUMstF/csMNUTKfCNGsravD5SIxwqdO0LLWvpRg=; b=UL/O6sW1gMgdM2qAuzSf5JtI7Z8yi6s6YxmMGQpsrFfSLXyw5SqwdMKBMio/MivHXz qUfg063Io6Xj1FbOyTTUFzaCDAYaVlEBS7g5CWDQW2JhePDhmEPgsrmQZF2eoVDZPOdG RmgJQrTKb5KqM2bAzdfgWITM4lkMVYb4y2zmviG6PTzup2kOouuUIxmPhH/efGeUGl1b 7AjZi73zOCJGnFI50kEH9uVN931dAU+P/RlwxgVy6rDkfw6rJKklSokMNbDY45zFaTff mSaCPrlyllfOTLz+CMg+yxu+nV86pF0a9SPik7ZXsk7hgMSB2I1ZIg+IRqXjwLZdymLW 3BdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=Ki9BgUMstF/csMNUTKfCNGsravD5SIxwqdO0LLWvpRg=; b=cZQPEJtgucsWHOmOgmjrKaopSQqsIeh80L7PSoFzN7X6eQ0MrSvItDRWggah/XBDNg 0UojlDk1ttXAwGwJ14l3WwJNF4xy3Qt5MbBa46lAQBw68Yre3ha+WQPN9SduWJgPV3Ig i1rMNqPeiryGcTnqMFDIfeU971PBuDDS4DvE3TV3cIH8kHq7bvdmiFlxJmkTp0O/Z6yO 5ysWBX5FQ88TpNGgxG611HiW5g82xGp09QWdWjIagIWbSxpzm+bXkTyUUQ6OcwhbwBLB TGHDj7p7rYXiBeIUZ3K8qdXk2nn5HTWLUxPJ+HsGGM3lvR4vurE2QuJxOHchQeMiucAd r7ZA== X-Gm-Message-State: ALyK8tLX9V6A1DCHkOXsQ2+/hvPvdCtYDTuK5zYnTcuCMOHUrdIo4cxwDSgNIwkwOFZu4w== X-Received: by 10.46.5.145 with SMTP id 139mr595270ljf.11.1467104361946; Tue, 28 Jun 2016 01:59:21 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 75sm3951108lfq.25.2016.06.28.01.59.20 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Tue, 28 Jun 2016 01:59:21 -0700 (PDT) Message-ID: <6FF0193D8A9141FFA1878A9365B01841@buildpc> From: "Valery Smyslov" To: "Waltermire, David A. \(Fed\)" , "IPsecME WG" References: Date: Tue, 28 Jun 2016 11:59:14 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecMEWG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 08:59:26 -0000 Hi, I support adopting this document. I think we need to have a PQ-secure solution in IPsec. I'd like to see it generic enough and not limiting to QKD technology only. I'd also like to have IKE SA to be protected, as well as Child SAs, so that this solution can be used in cases when sensitive data is transferred over IKE SA (like in G-IKEv2). I think the draft is a good starting point, which by no means excludes collaborations with authors of draft-nagayama-ipsecme-ipsec-with-qkd (or with others) during the work on this document (if it is adopted). Regards, Valery. > At IETF 95 the chairs took an action to issue a call for adoption on draft-fluhrer-qr-ikev2-01 based on WG interest in > the concept described by the draft. This call is long overdue. > > This is the official call for adoption of https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ as an IPSecME > working group (WG) document. > > By adopting this draft, the WG is agreeing to take this on as an official WG item to continue work on the draft. > Please reply with any comments supporting or concerns against adopting to the mailing list. This call will run until > Friday, July 4th UTC 23:59. > > Thanks, > Dave and Tero > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Jun 28 11:13:00 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DE112D1D7 for ; Tue, 28 Jun 2016 11:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlCYwLItZFj8 for ; Tue, 28 Jun 2016 11:12:56 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0127.outbound.protection.outlook.com [23.103.200.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4575412B02D for ; Tue, 28 Jun 2016 11:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w6lBuJLxFCOlFJF9AcSITd3ozZrap9dhdXFOy5vlet8=; b=e7W9+9xxmkbFy3Fqe/8sW0hhP6wDlRVWaLdu3e7+/F9oG4QD9hvQVcaA68ntfj3jNNcaDgPU0jAp4gqF99VXjAPSX/mMlwGyOmR/ZxfYu8P8lfxL7/dqk2yMC+mNw5dlVDNstsIG4DMjlr/GwTjqgbodvL795aqH3tPJVMKh2Bc= Received: from DM2PR09MB0665.namprd09.prod.outlook.com (10.161.144.16) by DM2PR09MB0665.namprd09.prod.outlook.com (10.161.144.16) with Microsoft SMTP Server (TLS) id 15.1.523.12; Tue, 28 Jun 2016 18:12:54 +0000 Received: from DM2PR09MB0665.namprd09.prod.outlook.com ([10.161.144.16]) by DM2PR09MB0665.namprd09.prod.outlook.com ([10.161.144.16]) with mapi id 15.01.0523.024; Tue, 28 Jun 2016 18:12:54 +0000 From: "Waltermire, David A. (Fed)" To: "Scott Fluhrer (sfluhrer)" , "paul@nohats.ca" , David McGrew Thread-Topic: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document Thread-Index: AdHMq6AaWm7UWPXSRFyRus61cfvSJAAEUKcAADlbKIAAF2ytAAAHlSyAAAOZCwAAzVwXAA== Date: Tue, 28 Jun 2016 18:12:54 +0000 Message-ID: References: <6c8f674e54b1483db684b261a8109378@XCH-RTP-006.cisco.com> In-Reply-To: <6c8f674e54b1483db684b261a8109378@XCH-RTP-006.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: a1eb68ef-c9f0-4c0b-8588-08d39f7fd377 x-microsoft-exchange-diagnostics: 1; DM2PR09MB0665; 6:K8NTlHRZc7E71/auDaP7O3hbBwPcvwSDeUHZ75WnSC0etNf28VcOL7SoLOhSVGUHmW1pfB4yCE6eQVBuwlgM7tNCDAtwkBv0c14uSevaKDos8PKbdIbxW3wt2DW6d7GFvmZVn8QFa/HURj0gk2K5S67qLqa5E6rK8eJk13BAWG9nTuHrW6rINY6+mutN2vUUPQ40zI7oecCeVV9mHGYivVlthzEDUH9Oq4zwwoxd2T2oA0bILJLaUvTVn8pNtPEP08LuK9hrj9dKotGZmT0kh0REeYiVG6/CQ1ULeUe0CQtX6YtXf3I2XBrR9JBHP2N6UqsuyODFJK5Yvnh8Ip0aeGDpinebnaMF/fEmNPHwagA=; 5:99CwAwlbGkWS2ytDZzu9RrDE62Vte0KfG1g4ZR8BhwP1gN8epDzj21vaeAV5jSzaomLbK4ujsLxPIUfH5lDptfmhrllWdtG06HENViX3lnGGt8X5DJj1F3zZjBGV2H0DRk7dqxopIouiltetsKdpfw==; 24:G70fSmWckWIKnENjPPSgy+bbA4hrAo8YYmfO3ryxqHDvZSqvF71Xp0ZObAqpHFEbSN1n1eeFkWjhWczZFIZPH+tHzBQ47X5CLmR/Ff8nYrs=; 7:P8mlpyVLd/7XRDbSZTYrJafxkIzoOULknwXwDg0nYE5a1iNJtjx5wK1hz4oNCh1c8WRDzPjxFoA7OJWQGHurbuX2o+CO64YnY9+N00ZgFmj9SXDfkrtw6gOfJ2Gewgv2tXum/0A2IkOoiOcr+HHePFoJS8i699RbM/+EtIlRafVVcFoh3mjqRMdi9goMF05GYWYSXwk+vhLmlhv+wNehngDUp3Yti9qkcVEsVpRaIWQZmTeawPTr18sjKhazPrGcJ0sKPtTuJBTUuAhwyyrvyg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0665; x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705)(100405760836317)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:DM2PR09MB0665; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0665; x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(13464003)(24454002)(57704003)(199003)(377454003)(2906002)(54356999)(5002640100001)(93886004)(97736004)(5001770100001)(4326007)(76176999)(2501003)(74316001)(586003)(66066001)(77096005)(50986999)(11100500001)(99286002)(106356001)(3280700002)(86362001)(102836003)(6116002)(3660700001)(87936001)(3846002)(2900100001)(2950100001)(105586002)(68736007)(19580395003)(19580405001)(122556002)(9686002)(33656002)(10400500002)(8936002)(7736002)(5003600100003)(92566002)(7696003)(189998001)(81156014)(81166006)(8676002)(76576001)(101416001)(305945005)(7846002)(230783001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0665; H:DM2PR09MB0665.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2016 18:12:54.1796 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0665 Archived-At: Cc: IPsecME WG , "Panos Kampanakis \(pkampana\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 18:12:59 -0000 This has been a good discussion so far. There is work to be done to address= the issues raised. Getting back to the call for adoption, I'd like to see feedback on the foll= owing questions to better understand where consensus is on this issue. 1) Previous WG discussions have indicated interest in this problem. Does th= e working group think that there is a problem here that we need to address? 2) Should we do this work in the IPsecME working group? If not, where? 3) Can we use draft-fluhrer-qr-ikev2 as a starting point for developing a W= G solution to this problem? If not, what is a suitable starting point inste= ad? Regards, Dave > -----Original Message----- > From: Scott Fluhrer (sfluhrer) [mailto:sfluhrer@cisco.com] > Sent: Friday, June 24, 2016 11:26 AM > To: paul@nohats.ca; David McGrew > Cc: Waltermire, David A. (Fed) ; IPsecME WG > ; Panos Kampanakis (pkampana) > Subject: RE: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IP= SecME > WG document >=20 >=20 > > -----Original Message----- > > From: Paul Wouters [mailto:paul@nohats.ca] > > Sent: Friday, June 24, 2016 9:43 AM > > To: David McGrew (mcgrew) > > Cc: Waltermire, David A. (Fed); IPsecME WG; Scott Fluhrer (sfluhrer); > > Panos Kampanakis (pkampana) > > Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an > > IPSecME WG document > > > > On Fri, 24 Jun 2016, David McGrew wrote: > > > > Hi David, > > > > > Because QKD is not a practical system for Internet security. It has= serious > > security issues/challenges and operational limitations on bitrate, rang= e, and > > physical media. It requires a point to point optical link, which is t= ypically > > dedicated fiber, which must be shorter than 60 miles. There are > > security issues with QKD because it relies on a physical interaction > > across the line between the encrypter and decrypter, thus giving an > > attacker the opportunity to perform an attack on the physical process > anywhere on that > > line. See for instance Brassard et. al. Security Aspects of Practical= Quantum > > Cryptography, Lydersen et. al., Hacking commercial quantum > > cryptography systems by tailored bright illumination, or Gerhardt et. > > al., Full-field implementation of a perfect eavesdropper on a quantum > cryptography > > system. Another major security problem is the range limitation; it ha= s > been > > proposed to extend the range of QKD by using a chain of trusted > > repeaters, each connected by a QKD sy stem. These repeaters would > > greatly increase the attack surface, and require the end user to trust > > the infrastructure provider(s); in contrast, the Internet community > > wants end to end encryption, as described in RFC3365 and RFC7624. > > > > > > In contrast, QR-IKEv2 can be used to add postquantum security > > > between > > any two points on the globe, without requiring dedicated fiber, and > without > > requiring physical layer security assumptions. It has *fewer* securit= y > > assumptions than draft-nagayama-ipsecme-ipsec-with-qkd, as that draft > > relies on the security of symmetric cryptography and the physical > > layer, whereas QR-IKEv2 relies only on the former. > > > > For a postquantum IKEv2 extension, does it matter which underlying > > mechanism is used to provide the extra bits to mix into the SKEYSEED? > > > > I think what is needed is: > > > > - A NOTIFY message that signals an identifier of where the extra bits > > should be taken/generated from. Both endpoints have previous > > knowledge > > of what tjos identifier refers to. Be it a hardware device or an > > offset in a onetime pad, etc, etc. >=20 > One possible concern is whether such a notify message would compromise > the anonymity properties of IKE; if someone in the middle sees the same > identifier in multiple exchanges, would they be able to conclude that tho= se > are the same individuals negotiating? If the NOTIFY messages are > anonymized, how is that done? >=20 > Now, it might be that the WG would decide to compromise on such > anonymization concerns; this would simplify things a lot, however it's ve= ry > much something we need WG agreement on. >=20 > > > > - A specification on how to mix in these extra bits into SKEYSEED gener= ation > > to gain postquantum security. >=20 > The reason we specify modifying the public nonces (rather than doing a mo= re > fundamental change to the skeyseed computation) was to minimize changes > to the IKE implementation itself (and in particular, the crypto parts). = Is there > a reason why we wouldn't continue with this approach? >=20 > > > > - Any additional counter meassures (such as increased minimum > > keysizes) >=20 > And what algorithms are suggested (e.g. XCBC and CMAC both don't work, as > the standard IKE versions are fixed to 128 bit keys) >=20 > > > > Do we need to know if these bits came from a QKD link, a QR link, or a > > mutually shared onetime pad? If not, then these specifics should not > > go into such an ikev2 extension. > > > > Paul From nobody Tue Jun 28 11:13:20 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99DF12D63C for ; Tue, 28 Jun 2016 11:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-xXkEXrcolj for ; Tue, 28 Jun 2016 11:13:07 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2B1412D63A for ; Tue, 28 Jun 2016 11:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1467137587; x=2331051187; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SVbjQqwIxQ82ec80iDfYz8/7BPMhm/Bbh3Kj/abGdgQ=; b=i84VkBaZF/Ql27kSVfbsPSfgUm252IiVnCS081lAEbIA07sK6aTSeziElrSbUNoC qXei9hT1d8YEYtyeB5Jb/8cJ8ncEiD2R4rCWkt9me6r+QGwchMW/SRKZzWrZmQ92 Ck4EScuY0FXejcNDwehy0Yn8F4h55d7DCk2J+LwEph0WmEVRDlrTdTg76YQ8x3Ta afs5o0sYfb8C4HcLyZSNM3e7cWBN5o9AaJjYJ9xFqN4EGuH+BYZo/srbcZ+XEXXd 7yW6rqqu+DbQyisxcimfhWIVubC7+ywbpyEvrb/ifYPN1kiOvwmT0LtdLe4Lvxio gnhM+B217anktizbGSe1JA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id F6.A3.16520.33EB2775; Tue, 28 Jun 2016 11:13:07 -0700 (PDT) X-AuditID: 11973e11-f79896d000004088-61-5772be334a6f Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 88.81.09720.23EB2775; Tue, 28 Jun 2016 11:13:06 -0700 (PDT) Received: from [17.153.56.158] (unknown [17.153.56.158]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O9H006S4ULTED10@nwk-mmpp-sz11.apple.com> for ipsec@ietf.org; Tue, 28 Jun 2016 11:13:05 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable MIME-version: 1.0 (Mac OS X Mail 10.0 \(3195\)) Date: Tue, 28 Jun 2016 11:13:05 -0700 References: <20160627140505.5379.34019.idtracker@ietfa.amsl.com> To: IPsecME WG In-reply-to: <20160627140505.5379.34019.idtracker@ietfa.amsl.com> Message-id: X-Mailer: Apple Mail (2.3195) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUi2FAYoWu8ryjcYNI5NYv9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEro3kif8FpoYo/izayNTCu4+ti5OSQEDCR2DNnNyOELSZx4d56 ti5GLg4hgb2MEh9WfGKGKVr5+RNYkZDAciaJpiUJEEXzmCSWLd3K0sXIwSEsICGxeU8iSA2b gIrE8W8bwHqZBbQk1u88zgRha0s8eXeBFaScV0BfYvZPM5CwsICrxIP2fWDlLAKqEp++XWeD WOUgcX7HOkaQchEBeYmZNzJBwpwCjhIN7a1QU2wkln0PhThSVmLunzeMIIdJCExgkzh2uZF9 AqPwLCRHzEJyxCyEIxYwMq9iFMpNzMzRzcwz0kssKMhJ1UvOz93ECAre6XaCOxiPr7I6xCjA wajEw7ujrjBciDWxrLgy9xCjNAeLkjhv5+6icCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M wrt7Jl2cHBX9XrAy33NvUkJ1nNfLv7d5fZlX5z/n4tt18o+aa/mP7+xzZt1/VXBLeI/ulhzm O8e3TyuWe3juZ7DhjpB1GiVrDDJ+hsuzaL0pDX1+4lKVd7dz7Ouo/M/vV/77w7ngaKWVXnDP 5L4/equ7zE7ES4YscbU3/RrIk/Rg57S1LmuWKrEUZyQaajEXFScCAAna6j0/AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUi2FA8W9d4X1G4wa03zBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvNE/oLTQhV/Fm1ka2Bcx9fFyMkhIWAisfLzJ0YIW0ziwr31 bCC2kMByJommJQldjFxA9jwmiWVLt7J0MXJwCAtISGzekwhSwyagInH82wZmEJtZQEti/c7j TBC2tsSTdxdYQcp5BfQlZv80AwkLC7hKPGjfB1bOIqAq8enbdahVDhLnd6xjBCkXEZCXmHkj EyTMKeAo0dDeCjXFRmLZ91CII2Ul5v55wziBUWAWkr2zkOydhbB3ASPzKkaBotScxEpTvcSC gpxUveT83E2M4GArjNjB+H+Z1SFGAQ5GJR5egcbCcCHWxLLiytxDjBIczEoivG92F4UL8aYk VlalFuXHF5XmpBYfYkwGun4is5Rocj4wEvJK4g1NTAxMjI3NjI3NTcxJE1YS5/36sSBcSCA9 sSQ1OzW1ILUIZgsTB6dUA2O9SYuWfAaXtp3qw5jrKtMEKlkTj2x0f14UKm/Q9s1B4uiE06k9 advPqgj/iBL9fKPis3H2K6FC6cPiTl5zJ9yMqdr6i+29nc2rP/nZk2+3Luk2r3RyntD77s9t Vd9v/Z1Pulk9cr9JfjE0eVtz62pmbEvJzS6LkgUT7iss6PDOX8645ZTWVCWW4oxEQy3mouJE ABqkGMh6AgAA Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-tcp-encaps-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 18:13:19 -0000 Hello, We've posted a new version of the TCP Encapsulation draft, now as a WG = document (https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-00). Here are the major changes in this version, based on the last round of = feedback: - Changed most references to IKEv2 to IKE to make this technique more = generic - Changed the Stream Prefix from IKEv2 to IKETCP - Clarified the use of the Stream Prefix with regards to extra layers of = protocols (TLS) in the appendix examples - Clarified that ESP SPI must be zero We'd like to post one more version with feedback and input from the = group by our Berlin meeting. Please review! Thanks, Tommy > On Jun 27, 2016, at 7:05 AM, internet-drafts@ietf.org wrote: >=20 >=20 > 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 of the IETF. >=20 > Title : TCP Encapsulation of IKE and IPSec Packets > Authors : Tommy Pauly > Samy Touati > Ravi Mantha > Filename : draft-ietf-ipsecme-tcp-encaps-00.txt > Pages : 19 > Date : 2016-06-24 >=20 > Abstract: > This document describes a method to transport IKE and IPSec packets > over a TCP connection for traversing network middleboxes that may > block IKE negotiation over UDP. This method, referred to as TCP > encapsulation, involves sending all packets for tunnel establishment > as well as tunneled packets over a TCP connection. This method is > intended to be used as a fallback option when IKE cannot be > negotiated over UDP. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Jun 29 16:11:38 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306FD12D904 for ; Wed, 29 Jun 2016 16:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Akr1ebOUqQZU for ; Wed, 29 Jun 2016 16:11:34 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0116.outbound.protection.outlook.com [23.103.200.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6137A12D927 for ; Wed, 29 Jun 2016 16:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VlGz0x9opy1ULd6OL91cvbkQrCLGPp7C0RkkR8KL+KU=; b=SHVyNxSmGAhdE4lqigDboAY+nJoyMQD/opj85k7MnbpwYUlQV0ELt3VUrRKnU50qbNjT4HNk35PIjGSW2wuo2aozLZ9ZmSyf5ODb9HhWlJKMHIgXCpgJF2vsxukyPUnr5pa6nlGTKwP25sW94BkKD74Xdhaf//A8BXlP3csc9fQ= Received: from DM2PR09MB0665.namprd09.prod.outlook.com (10.161.144.16) by DM2PR09MB0665.namprd09.prod.outlook.com (10.161.144.16) with Microsoft SMTP Server (TLS) id 15.1.523.12; Wed, 29 Jun 2016 23:11:32 +0000 Received: from DM2PR09MB0665.namprd09.prod.outlook.com ([10.161.144.16]) by DM2PR09MB0665.namprd09.prod.outlook.com ([10.161.144.16]) with mapi id 15.01.0523.024; Wed, 29 Jun 2016 23:11:32 +0000 From: "Waltermire, David A. (Fed)" To: IPsecME WG Thread-Topic: Review of draft-ietf-ipsecme-ddos-protection Thread-Index: AdHSWx59AuDIEcsNSdSPK3G4/aSINg== Date: Wed, 29 Jun 2016 23:11:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.224.58] x-ms-office365-filtering-correlation-id: 838ba6c7-830a-4751-d626-08d3a072b5df x-microsoft-exchange-diagnostics: 1; DM2PR09MB0665; 6:DqIf88LpuR4N8mvTTkMwJBjC/18TuqIUeK4jV5N0e/LscxvmzgdtkD1LmPyZVP4h+Jw0sh18Dn934xVSGx9xThcrDIHCj5YMOTwwTuUVNCwdO+IvIHcxHY8HbYzjayPEK3GeCTn1+z1lQU5jmc/cqNTKNk2ohfOqTYwSpPFqYGrfLNdmvBhelGZ8SkMxkVFjGsd78cb2tJrcdp8SduxYQ5Gp/l8mVBV+r/rZOg++LCcwtdQB38SIVHaY2cDjeJyYAZ+JytX6MoEitFLmnU9rmlQxziaUaoCoULyzkUfOFtjMragna5oKmf0UA+BbrNt8VLiD9aCMXIRP+s728rtGK4escEteflOoT1oE2H/NgSE=; 5:GpfuzP0wjwocJMkZwVUTVNI/UR5ycPxf79sIDLYmaaQhbhC6rXWZLf0EXt5FO9BOX7rmBgFWYOgrtBfvb5TiElXLdJWuFxiGVSFg2sYNiFRUFJNK01c3wqYHyT5WL6zCXe312yWExUflxl0ZrTzcaw==; 24:w2mknWZPdUvBDKrSV2i0ASDODyX9nw8NFokudenfb3GeGY/otxgbZ/JZnANZF729zyC1/BYf7XjeHn51nM+2rADL4/sdeBbXpdWbTM2I/aE=; 7:8JzehOO256MdrLtiCE0XsRYbDvrw7w+re4RijpqiYsrPvn2rQy2Z4EKoQlFE+rrCe+EAhGRl44cX+ojfYZqUW2wF1Miz46gyl+vl9On05t7+vwkBaNLSyvE9ilKVhHJLBWS8iKjwjOXIcW45FOHo7mVbKmUQxM9EYM/0kabUPaS204sHlG0uQXp+nomp/3oRf4VWXmUlQ0x9gwU1OAjvNTlz5Won7jbn4UVROsOzxanReE4RbpgiRJJO5jb8FXaVv3cuGbiad0Me0Fr6OvPcJg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0665; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:DM2PR09MB0665; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0665; x-forefront-prvs: 09888BC01D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(99286002)(2906002)(54356999)(5002640100001)(97736004)(229853001)(450100001)(74316001)(77096005)(586003)(50986999)(66066001)(11100500001)(106356001)(3846002)(3280700002)(86362001)(102836003)(6116002)(87936001)(2900100001)(3660700001)(305945005)(7846002)(68736007)(105586002)(122556002)(9686002)(33656002)(76576001)(5003600100003)(189998001)(10400500002)(7736002)(8936002)(107886002)(110136002)(7696003)(92566002)(81156014)(8676002)(81166006)(230783001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0665; H:DM2PR09MB0665.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2016 23:11:32.5852 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0665 Archived-At: Subject: [IPsec] Review of draft-ietf-ipsecme-ddos-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2016 23:11:36 -0000 I just completed a review of the DDoS draft. I fixed a number of grammar an= d wording issues. I would like to issue a pull request, but I don't have ac= cess to the site yet. I hope to get that resolved ASAP and then submit the = pull request. While I was reviewing the draft I noticed a couple of small things. In section 6, the text reads: When there is no general DDoS attack, it is suggested that no cookie or puz= zles be used. At this point the only defensive measure is to monitor the nu= mber of half-open SAs, and setting a soft limit per peer IP or prefix. The = soft limit can be set to 3-5, and the puzzle difficulty should be set to su= ch a level (number of zero-bits) that all legitimate clients can handle it = without degraded user experience. This paragraph is confusing since the first sentence suggests that no puzzl= es are used and the last sentence suggests a puzzle difficult value. Should= the puzzle text be removed from the last sentence? How about the following? When there is no general DDoS attack, it is suggested that no cookie or puz= zles be used. At this point the only defensive measure is to monitor the nu= mber of half-open SAs, and setting a soft limit per peer IP or prefix. The = soft limit can be set to 3-5 to support DoS detection. If puzzles are used,= the difficulty should be set to such a level (number of zero-bits) that al= l legitimate clients can handle it without degraded user experience. Two paragraphs down the text reads: When cookies are activated for all requests and the attacker is still manag= ing to consume too many resources, the Responder MAY increase the difficult= y of puzzles imposed on IKE_SA_INIT requests coming from suspicious nodes/p= refixes. It should still be doable by all legitimate peers, but it can degr= ade experience, for example by taking up to 10 seconds to solve the puzzle. This assumes that puzzles are already in use, which might not be the case b= ased on the earlier paragraph. Perhaps the following text can be used inste= ad: When cookies are activated for all requests and the attacker is still manag= ing to consume too many resources, the Responder MAY start to use puzzles f= or these requests or increase the difficulty of puzzles imposed on IKE_SA_I= NIT requests coming from suspicious nodes/prefixes. This should still be do= able by all legitimate peers, but the use of puzzles at a higher difficulty= may degrade the user experience, for example by taking up to 10 seconds to= solve the puzzle. Section 7.2.1 contains the sentence: The Responder MUST NOT use puzzles in the IKE_AUTH exchange unless the puzz= le has been previously presented and solved in the preceding IKE_SA_INIT ex= change."? Should this state "unless the puzzle" or "unless a puzzle"? It seems like t= he latter is what was intended. Thanks, Dave David Waltermire Information Technology Laboratory | Computer Security Division National Institute of Standards and Technology From nobody Thu Jun 30 01:52:14 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4F312B032 for ; Thu, 30 Jun 2016 01:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2yGeGs3cdry for ; Thu, 30 Jun 2016 01:52:11 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0887212B078 for ; Thu, 30 Jun 2016 01:52:10 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id q132so50489922lfe.3 for ; Thu, 30 Jun 2016 01:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-transfer-encoding; bh=xk3GCBhZqxD0BWHmJ7zIUFIaWNMZU8sbnqMPrpkP/4I=; b=i1h4l0xnLJPpxBGxvjC8FdEXE5YIBI/vb/kNyM1rrXqMvorO/91Hc3OTNnzmoNXuHB caeHz1aPwrBlIPkpReBk2wsDI7+N1pD+Wj+D0QuTReiKvVYVZE2PxKz1qeS1OIxOWpNY Pi08WDTnGrLe4DPrLRiR1doILiSuynISYv4q08hFzKWan027R1dNagfriBhjZ8RctXpy QRkTS2F1c4fT+u8ZwoXk0A5lfqnFvSF4FcDaCLKD95RoJESR6FLHxV5eQ+d6cUGHeeTh paNMuUsAnFemymRxUcQXNcuYcC2zhRUQyC0Dbu6ptHKwCTlkcLni7+6W4v+xducKxxP4 X/Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-transfer-encoding; bh=xk3GCBhZqxD0BWHmJ7zIUFIaWNMZU8sbnqMPrpkP/4I=; b=lSZMc9HJj3ODWOF2AfPtQmzlL5aFQEGYP2r5y06wVHGOOgomW6K1Ga7gVno/6P7oKL UV6x8NaS5nOhjhY6g9A4kq9iQoi3pGjR5E73l+mkwaTvmcjEfTsk36a1LhcAAJTMPuaB WQyf4IOxVKat/XgNF/f90+wOhYorv+M+G25MQ4H1Erod3a6gnRLla3Hgn80qE2Kb/FDU b+7eL6aK+temT0J9e8gO5J0H3kBYFPtUvek0m+FMDidhvpYz3Xqpni4KWtIcHnhunDrR ipfibi6juswHuNqFz2RDunvBp6gPDbDc7f2gwrgBkiYHf+UWVqhNn3uf0vYX1/rYWMEA 4Gnw== X-Gm-Message-State: ALyK8tKNtnfNBOvtsnHXXhRDQtq3q7hsVqenkhQLkJ2+selCWiQDxh0U58WSoD/6YppLOQ== X-Received: by 10.25.15.213 with SMTP id 82mr3988534lfp.126.1467276729001; Thu, 30 Jun 2016 01:52:09 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 5sm1323738lja.34.2016.06.30.01.52.07 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Thu, 30 Jun 2016 01:52:08 -0700 (PDT) Message-ID: <33A8023F7A7A4C75A7058E85E6D27A01@buildpc> From: "Valery Smyslov" To: "Waltermire, David A. \(Fed\)" , "IPsecME WG" References: Date: Thu, 30 Jun 2016 11:52:07 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 08:52:13 -0000 Hi Dave, thank you for your review. >I just completed a review of the DDoS draft. I fixed a number of grammar and wording issues. I would like to issue a >pull request, but I don't have access to the site yet. I hope to get that resolved ASAP and then submit the pull >request. > > While I was reviewing the draft I noticed a couple of small things. > > In section 6, the text reads: > > When there is no general DDoS attack, it is suggested that no cookie or puzzles be used. At this point the only > defensive measure is to monitor the number of half-open SAs, and setting a soft limit per peer IP or prefix. The soft > limit can be set to 3-5, and the puzzle difficulty should be set to such a level (number of zero-bits) that all > legitimate clients can handle it without degraded user experience. > > This paragraph is confusing since the first sentence suggests that no puzzles are used and the last sentence suggests > a puzzle difficult value. Should the puzzle text be removed from the last sentence? > > How about the following? > > When there is no general DDoS attack, it is suggested that no cookie or puzzles be used. At this point the only > defensive measure is to monitor the number of half-open SAs, and setting a soft limit per peer IP or prefix. The soft > limit can be set to 3-5 to support DoS detection. If puzzles are used, the difficulty should be set to such a level > (number of zero-bits) that all legitimate clients can handle it without degraded user experience. I see your point. I'd rather make a minor change to your text: When there is no general DDoS attack, it is suggested that no cookie or puzzles be used. At this point the only defensive measure is to monitor the number of half-open SAs, and setting a soft limit per peer IP or prefix. The soft limit can be set to 3-5. If the puzzles are used, the puzzle difficulty should be set to such a level (number of zero-bits) that all legitimate clients can handle it without degraded user experience. (since Soft Limit is not intended to detect DoS attack). > Two paragraphs down the text reads: > > When cookies are activated for all requests and the attacker is still managing to consume too many resources, the > Responder MAY increase the difficulty of puzzles imposed on IKE_SA_INIT requests coming from suspicious > nodes/prefixes. It should still be doable by all legitimate peers, but it can degrade experience, for example by > taking up to 10 seconds to solve the puzzle. > > This assumes that puzzles are already in use, which might not be the case based on the earlier paragraph. Perhaps the > following text can be used instead: > > When cookies are activated for all requests and the attacker is still managing to consume too many resources, the > Responder MAY start to use puzzles for these requests or increase the difficulty of puzzles imposed on IKE_SA_INIT > requests coming from suspicious nodes/prefixes. This should still be doable by all legitimate peers, but the use of > puzzles at a higher difficulty may degrade the user experience, for example by taking up to 10 seconds to solve the > puzzle. Works for me. > Section 7.2.1 contains the sentence: > > The Responder MUST NOT use puzzles in the IKE_AUTH exchange unless the puzzle has been previously presented and solved > in the preceding IKE_SA_INIT exchange."? > > Should this state "unless the puzzle" or "unless a puzzle"? It seems like the latter is what was intended. Sure, the latter was an intended meaning. Thank you. Regards, Valery. > Thanks, > Dave > > > David Waltermire > Information Technology Laboratory | Computer Security Division > National Institute of Standards and Technology > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jun 30 01:58:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44FC12B078 for ; Thu, 30 Jun 2016 01:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZBYqtAlPVmB for ; Thu, 30 Jun 2016 01:58:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B7D912B032 for ; Thu, 30 Jun 2016 01:58:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rgD376K2jz37c; Thu, 30 Jun 2016 10:58:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id zfdyNb0VSGYr; Thu, 30 Jun 2016 10:58:09 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 30 Jun 2016 10:58:09 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3140135D62A; Thu, 30 Jun 2016 04:58:08 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 3140135D62A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1BDCE40D6EB3; Thu, 30 Jun 2016 04:58:08 -0400 (EDT) Date: Thu, 30 Jun 2016 04:58:07 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: Message-ID: References: <4200F5373D5542C985F3D4C51609213C@buildpc> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 08:58:17 -0000 On Tue, 28 Jun 2016, Valery Smyslov wrote: This is part two of my review. I do think the document needs some work moving text to better locations and I have some questions I would like to see resolved. I wrote down some nits but stopped doing that in the end because I think chunks of text shoud be moved. By biggest issue is that section 6 and section 7 are not clearly separated, and I see various chunks of text I think is in the wrong section (or is section 6 text repeated in section 7) I think this document should update 7296 due to adding non-encrypted payloads to IKE_AUTH - even though the core IKEv2 RFC does not say that is not allowed. Someone implementing 7296 should be aware of it to allow it in their implementation. I will redo a nits/grammer check on the next iteration of the document. Note, that it is not possible with clients using NULL Authentication, since their identity cannot be verified. It feels that this sentence should be followed by some specific advise for this category of clients? Section 6 descibes in item 1: "A general DDoS attack" some numbers that I find dangerous to follow. It descibes a scenario of 20 tunnels per second as expected that when increased to 100 tunnels per second is considerared a DDOS attack. But that does not take into account network failures that would cause a large chunk of clients to reconnect at once. While the draft says this "can be interpreted as an attack", implementors might just put in these hardcoded numbers from the document. I'd rather describe it a bit different so we don't give them these absolute numbers. for example: Typical measures might be 5 concurrent half-open SAs, 1 decrypt failure, or 10 EAP failures within a minute. Why is this "typical"? And again, these numbers provide too tempting easy numbers for implementors to hardcode in their implementation. And I think these are speculation at best. puzzle difficulty should be set to such a level (number of zero-bits) that all legitimate clients can handle it without degraded user experience. This is of course the big issue of this draft. Is this possible at all? Note te _lack_ of specific numbers here :) I don't understand this paragraph: it is best to begin by requiring stateless cookies from all Initiators. This will force the attacker to use real source addresses, and help avoid the need to impose a greater burden in the form of cookies on the general population of Initiators. Perhaps the "form of cookies" was meant to say "puzzles" ? And this one confuses me too: When cookies are activated for all requests and the attacker is still managing to consume too many resources, the Responder MAY increase the difficulty of puzzles imposed on IKE_SA_INIT But up to now, we haven't been given advise to enable puzzles, and now we are recommended to increase the difficult of puzzles? If the load on the Responder is still too great, and there are many nodes causing multiple half-open SAs or IKE_AUTH failures, the Responder MAY impose hard limits on those nodes. Unlike elsewhere, it does not describe what failure to send back, if anything, to the responder. Sending back a NOTIFY might actually not be desirable, as it would tell the attacker their attack has reached a good enough volume to lock out real clients. Some advise on how to handle this scenario is needed. And confusingly, only NOW are puzzles suggested as a next "last step", even though before this it already told us to incrase puzzle strength. Why is there not an option to add puzzles to the CREATE_CHILD_SA to punish just those clients requesting too many of those? (I'm not sure if it is a good idea, I'm asking because I'm not sure it is a bad idea) Section 7 has: According to the plan, described in Section 6, [.....] We are not Cylons :) Seriously though, section 6 describes _when_ to activate puzzles, and section 7 should describe how to activate puzzles without any contetx of when to enable it or not. Currently, section 7 repeats some of the "plan" of section 6, which should not be needed and makes the implementation section longer/harder to read. Some of the text in section 7, like the new "processing some fraction of requests" should be in section 6, not section 7. 7.1.1 states: "then it MUST include two notifications in its response message" So earlier text said "may" also use cookies, and this text assumes there puzzles can only happen with cookies. That is contradicting. I would say remove the requirement in section 7 and change the text in section 6 to make it obvious that cookies should be the first line of defense and should still be used when handing out puzzles on top of cookies. If you mean to talk about the interaction or combination of puzzles and cookies, perhaps a separate section on that would be most clear. 7.1.1.1 introduces a term ZBC which I have no idea what it means yet. It then talks about difficulty level 0 which I don't know what that is. Does it translate to number of zero's in solution? If so I would expect level 1 to be the lowest? Maybe this discussion should go into the section 7 introduction. What is the general idea of the puzzle, what are difficuly levels, etc. The Responder MAY set different difficulty levels to different requests depending on the IP address the request has come from. I would think that MAY should be stronger, a SHOULD ? If you can detect a few problem causing IPs or IP ranges, you made good points saying to only punish those with puzzles. The Responder parses received SA payload and finds mutually supported set of transforms of type PRF. It selects most preferred transform from this set and includes it into the PUZZLE notification. I find the use of transform a bit confusing. I would say PRF. (and "most preferred" -> preferred) If there are no mutually supported PRFs, then negotiation will fail anyway and there is no reason to return a puzzle. I first thought of the AES_GCM not needing PRF, then realised I confused IKE and IPsec SA. Perhaps add change "negotiation will fail" to "IKE SA negotiation will fail". 7.1.1.3. Generating Cookie If Responder supports puzzles then cookie should be computed in such a manner, that the Responder is able to learn some important information from the sole cookie, We are in the middle of puzzles and not cookies. Why suddenly cookies? Again, I think the document can use a better introduction in section 7 that explains the interaction between the two, laying out the principes. Only later on do I read responder puzzle state is encoded in the cookie. The point of encoding puzzle information in the cookie is presumbly so that this state does not need to be remembered by the responder. So how does it know "The number of consecutive puzzles given to the Initiator."? Is this a counter in the ? I would like to put a note here as well about the maximum cookie size of 64 bytes that implementors might not realise. to avoid naive implementations building a very big "string cookie" with these bullet points of information. Cookie = | | Hash(Ni | IPi | SPIi | | ) This would give the responder the AdditionalInfo information which it might use as feedback on how successful the attack is. Why not use an encryption of using the ? Would that be too expensive for the Responder? I'd think not as it is not more expensive than decrypting IKE_AUTH. Or stick with the second approach listed, where the responder keeps this state locally, which probably is better anyway because it needs to know the scale of the entire attack that cannot be learned from individual negotiation states. 7.1.2 states if the inititor does not want to solve a puzzle of difficulty X, it will pretend not to support the NOTIFY. This causes the responder to not learn that the initiator rejected the difficulty versus that it just does not support puzzles. It would be useful for the responder to know how many iniators support puzzles, so I would recommend a different NOTIFY for the "puzzle too difficult" error path (Maybe a return notify of PUZZLED :) If the received message contains a PUZZLE notification and doesn't contain a COOKIE notification, then this message is malformed because it requests to solve the puzzle, but doesn't provide enough information to do it. Again, conflicting with earlier text saying cookies are not mandated for puzzles, which now it seems they are. It seems 7.1.4 paragraph 2 and 3 are better moved to the introduction of that section. If a PS payload is found in the message, then the Responder MUST verify the puzzle solution that it contains. Doesn't that open up the responder to a DDOS attack. Initiators will just submit fake puzzle solutions to drive up the initiator CPU. Also, if the responder is no longer under attack, why can't it just ignore the puzzle solution and continue with regular IKE? if the Responder didn't indicate any particular difficulty level (by setting ZBC to zero) and the Initiator was free to select any difficulty level it can afford, Woah, these options were not discussed before at all. So that's what level 0 means! I would really move this text to the start of section 7 in the introduction of how puzzles work in general. o Demand more work from Initiator by giving it a new puzzle. This seems a waste of a round trip. Why can the responder demand a variable puzzle without telling what would make it happy, only to have the initiator misguess and cause another roundtrip, or to avoid a potential roundtrip, waste too much resources and cause visible delays to endusers by overestimating puzzle difficulty? I think this is not a good feature of the protocol. The more puzzles the Initiator solves the higher its chances are to be served That seems bad. Each puzzle is a delaying round-trip! includes a puzzle solution in the first IKE_AUTH request message outside the Encrypted payload Note this is very exceptional and should probably be written out in our syntax, eg: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} [PUZZLE] --> While I checked RFC 7296 it does not state some exchanges only have encrypted payloads, and so technically this document does not update the core document, but I think many implementations might not expect unencrypted payloads in IKE_AUTH and CREATE_CHILD_SA so perhaps that is important enough to mark this document as "updating 7296". in the IKE_AUTH exchange S is a concatenation of Nr and SPIr. Why Nr and SPIr? I think because of re-using DH vales on the responder? If so, it would be good to explain that. Should it state somewhere that IKE_AUTH puzzles are not allowed unless the clinet confirmed support for puzzles in IKE_INIT. Because then the responder does not actually know whetrher the initiator supports puzzles at all. And since it is stated those IKE_AUTH responses without puzzle should be silently dropped, that becomes very important. I think the IKE fragmentation paragraph deserves to be in its own sub-section. It's pretty important to get it right and not start attempts to decrypt potentially bogus fragments. Regarding the puzzle format, this is now 11 octects. we've aligned things in the past, so should we do that hear and add another 1 octet of reserved bits? The puzzle notification also misses an IANA line: The payload type for the Puzzle payload is . Section 9 states: A good rule of thumb is for taking about 1 second to solve the puzzle. Why is this a good rule of thumb? Again this comes down to me having no idea whether or not puzzles is a good idea to begin with. I'm very skeptical of this claim. A botnet will be able to waste 1s of 99% CPU on this attack per node. Initiators should set a maximum difficulty level beyond which they won't try to solve the puzzle and log or display a failure message to the administrator or user. and again note that this information will never be available to the Responder, so it can never figure out what solving levels is causing a sharp drop in legitimate clients. (other than seeing an attack that is more successful, but it won't know that this is caused by the puzzle difficulty level) that the Responder's load remain close to the maximum it can tolerate. Which ignores the pain on initiators. it should probably be pointed out somewhere that confirmation a puzzle solution is a lot cheaper than solving the puzzle. nits Note this draft also mentions IKEv2 with version instead of refering to just IKE, which makes more sense if we end up with IKEv3. buggy implementation -> broken implementation escape any responsibility for its actions -> escape any responsibility for its bad behaviour Since currently there is no way -> Since there is currently no way In IKEv2 client can request various configuration attributes -> In IKE, a client can request various configuration attributes Most often those attributes -> Most often these attributes for defeating the DDoS attack -> for surviving DDoS attacks. Implementations may be deployed in different environments -> Implementations are deployed in different environments As an example -> For example , searching for two things: -> for two scenarios: Supposing the the tunnels -> Supposing that the tunnels If they are mitigated well enough -> If these are mitigated successfully This is a good thing as it prevents Initiators that are not close to the attackers from being affected. I think this sentence adds nothing and can be removed. This will force the attacker to use real source addresses, -> This will mitigate attacks based on IP address spoofing I would probably shorten the introduction of section 7 to something like: Puzzles can be added in the IKE_INIT and IKE_AUTH ecchanges. and leave out the text describing the document flow, like "Both sections are divided into ..." The message may optionally contain a COOKIE notification If implementations base themselves on this draft, it is actually basically guaranteed to have a cookie, say "may optionally" seems a bit weak? "most likely" or "usually" seems better. I mean, this part of the document should assume previous parts of the document are implemented. To support this feature -> To support crypto agility also MAY ignore -> MAY ignore ready to deal with them, -> ready to solve them" From nobody Thu Jun 30 01:58:59 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F221412D940 for ; Thu, 30 Jun 2016 01:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.326 X-Spam-Level: X-Spam-Status: No, score=-103.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiGnMeyeCqP4 for ; Thu, 30 Jun 2016 01:58:55 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4654F12B032 for ; Thu, 30 Jun 2016 01:58:55 -0700 (PDT) Received: from wifi-139-223.sfc.wide.ad.jp (wifi-139-223.sfc.wide.ad.jp [203.178.139.223]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id E9ABC278299; Thu, 30 Jun 2016 17:58:53 +0900 (JST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C49D4C87-11DF-4D24-A315-4BE4CF9B84B1" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Rodney Van Meter In-Reply-To: Date: Thu, 30 Jun 2016 17:58:52 +0900 Message-Id: References: <6c8f674e54b1483db684b261a8109378@XCH-RTP-006.cisco.com> To: "Waltermire, David A. (Fed)" X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Shota Nagayama , IPsecME WG , David McGrew , "Panos Kampanakis \(pkampana\)" , "Scott Fluhrer \(sfluhrer\)" , Rodney Van Meter , "paul@nohats.ca" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 08:58:58 -0000 --Apple-Mail=_C49D4C87-11DF-4D24-A315-4BE4CF9B84B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 29, 2016, at 3:12 AM, Waltermire, David A. (Fed) = wrote: >=20 > This has been a good discussion so far. There is work to be done to = address the issues raised. >=20 > Getting back to the call for adoption, I'd like to see feedback on the = following questions to better understand where consensus is on this = issue. >=20 > 1) Previous WG discussions have indicated interest in this problem. = Does the working group think that there is a problem here that we need = to address? I think it=E2=80=99s pretty clear that a mechanism for using keys = created in some out-of-band fashion for keying symmetric encryption = methods, such as AES, is valuable. > 2) Should we do this work in the IPsecME working group? If not, where? Here. > 3) Can we use draft-fluhrer-qr-ikev2 as a starting point for = developing a WG solution to this problem? If not, what is a suitable = starting point instead? >=20 Neither Shota nor I have sat down and reviewed this in detail, so I = can=E2=80=99t really comment yet, but I=E2=80=99m happy to support = whatever results in the best standard, whether it=E2=80=99s starting = from fluhrer or from=20 https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01 = It=E2=80=99s important to me that the mechanism support not just = *pre-shared* keys, but dynamically created keys from *any* out-of-band = mechanism, within constraints that probably need to be defined = carefully. If that=E2=80=99s done right, it can be used to support = QKD-generated keys, or a daily or weekly courier. One of the biggest technical issues, and one that hit us, was what to do = when the key generation channel is disrupted. We proposed a set of = fallback options in that draft, which generated significant controversy. I *don=E2=80=99t* think it=E2=80=99s yet appropriate to work on one-time = pad, as I think that results in more complex changes to IPsec than is = reasonable to bite off. Tero was perhaps the person who reviewed our work most carefully, so is = probably the best qualified person to determine the relative merits. =E2=80=94Rod --Apple-Mail=_C49D4C87-11DF-4D24-A315-4BE4CF9B84B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 29, 2016, at 3:12 AM, Waltermire, David A. (Fed) = <david.waltermire@nist.gov> wrote:

This has been a good = discussion so far. There is work to be done to address the issues = raised.

Getting back to the call for = adoption, I'd like to see feedback on the following questions to better = understand where consensus is on this issue.

1) Previous WG discussions have indicated interest in this = problem. Does the working group think that there is a problem here that = we need to address?

I think it=E2=80=99s pretty clear that a mechanism = for using keys created in some out-of-band fashion for keying symmetric = encryption methods, such as AES, is valuable.

2) = Should we do this work in the IPsecME working group? If not, where?

Here.

3) Can we use draft-fluhrer-qr-ikev2 as a = starting point for developing a WG solution to this problem? If not, = what is a suitable starting point instead?


Neither Shota = nor I have sat down and reviewed this in detail, so I can=E2=80=99t = really comment yet, but I=E2=80=99m happy to support whatever results in = the best standard, whether it=E2=80=99s starting from fluhrer or = from 

It=E2=80=99s important to = me that the mechanism support not just *pre-shared* keys, but = dynamically created keys from *any* out-of-band mechanism, within = constraints that probably need to be defined carefully. If that=E2=80=99s = done right, it can be used to support QKD-generated keys, or a daily or = weekly courier.

One of the biggest = technical issues, and one that hit us, was what to do when the key = generation channel is disrupted. We proposed a set of fallback options = in that draft, which generated significant controversy.

I *don=E2=80=99t* think it=E2=80=99s yet = appropriate to work on one-time pad, as I think that results in more = complex changes to IPsec than is reasonable to bite off.

Tero was perhaps the person who reviewed our work most = carefully, so is probably the best qualified person to determine the = relative merits.

= =E2=80=94Rod

= --Apple-Mail=_C49D4C87-11DF-4D24-A315-4BE4CF9B84B1-- From nobody Thu Jun 30 02:17:48 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D0C12DA0D for ; Thu, 30 Jun 2016 02:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg8tc67Mpqok for ; Thu, 30 Jun 2016 02:17:44 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2362912DA2E for ; Thu, 30 Jun 2016 02:17:37 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3rgDTW5Tzhz37c; Thu, 30 Jun 2016 11:17:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id VrdPPJZPLE1m; Thu, 30 Jun 2016 11:17:34 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 30 Jun 2016 11:17:33 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 028EE35D62A; Thu, 30 Jun 2016 05:17:32 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 028EE35D62A Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DDBCA40D6EB3; Thu, 30 Jun 2016 05:17:32 -0400 (EDT) Date: Thu, 30 Jun 2016 05:17:32 -0400 (EDT) From: Paul Wouters To: Rodney Van Meter In-Reply-To: Message-ID: References: <6c8f674e54b1483db684b261a8109378@XCH-RTP-006.cisco.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: Shota Nagayama , IPsecME WG , David McGrew , "Waltermire, David A. \(Fed\)" , "Scott Fluhrer \(sfluhrer\)" , "Panos Kampanakis \(pkampana\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 09:17:47 -0000 On Thu, 30 Jun 2016, Rodney Van Meter wrote: > I think it’s pretty clear that a mechanism for using keys created in some out-of-band fashion for keying symmetric encryption methods, such as AES, is valuable. Yes. > Neither Shota nor I have sat down and reviewed this in detail, so I can’t really comment yet, but I’m happy to support whatever results in the best standard, whether it’s starting from > fluhrer or from  > https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01 > Good. > defined carefully. If that’s done right, it can be used to support QKD-generated keys, or a daily or weekly courier. Yes. > One of the biggest technical issues, and one that hit us, was what to do when the key generation channel is disrupted. We proposed a set of fallback options in that draft, which > generated significant controversy. I think those should not be in the document itself. It could be in a separate document. > I *don’t* think it’s yet appropriate to work on one-time pad, as I think that results in more complex changes to IPsec than is reasonable to bite off. But onetime pads is how implementations without access to quantum computers would want to test their implementation. Paul From nobody Thu Jun 30 03:41:25 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6888A12DA2F for ; Thu, 30 Jun 2016 03:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.327 X-Spam-Level: X-Spam-Status: No, score=-103.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRyMAyztTrSu for ; Thu, 30 Jun 2016 03:41:22 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18B9812D9C1 for ; Thu, 30 Jun 2016 03:41:21 -0700 (PDT) Received: from [IPv6:2001:200::8805:5839:ef14:a19e:4811] (unknown [IPv6:2001:200:0:8805:5839:ef14:a19e:4811]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 50F9C278476; Thu, 30 Jun 2016 19:41:20 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Rodney Van Meter In-Reply-To: Date: Thu, 30 Jun 2016 19:41:18 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2B7F083A-E608-491A-B6EA-4CB4C9277B3B@sfc.wide.ad.jp> References: <6c8f674e54b1483db684b261a8109378@XCH-RTP-006.cisco.com> To: Paul Wouters X-Mailer: Apple Mail (2.2104) Archived-At: Cc: Shota Nagayama , IPsecME WG , David McGrew , "Waltermire, David A. \(Fed\)" , "Scott Fluhrer \(sfluhrer\)" , Rodney Van Meter , "Panos Kampanakis \(pkampana\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 10:41:24 -0000 > On Jun 30, 2016, at 6:17 PM, Paul Wouters wrote: >=20 > On Thu, 30 Jun 2016, Rodney Van Meter wrote: >=20 >> Neither Shota nor I have sat down and reviewed this in detail, so I = can=E2=80=99t really comment yet, but I=E2=80=99m happy to support = whatever results in the best standard, whether it=E2=80=99s starting = from >> fluhrer or from=20 >> https://tools.ietf.org/html/draft-nagayama-ipsecme-ipsec-with-qkd-01 >>=20 >=20 > Good. Sounds like agreement that we should work on _something_. >=20 >=20 >> One of the biggest technical issues, and one that hit us, was what to = do when the key generation channel is disrupted. We proposed a set of = fallback options in that draft, which >> generated significant controversy. >=20 > I think those should not be in the document itself. It could be in a > separate document. Could be. >=20 >> I *don=E2=80=99t* think it=E2=80=99s yet appropriate to work on = one-time pad, as I think that results in more complex changes to IPsec = than is reasonable to bite off. >=20 > But onetime pads is how implementations without access to quantum > computers would want to test their implementation. Not sure we=E2=80=99re talking about the same thing here, might be that = I=E2=80=99m sloppy in writing or reading. Our I-D and Fluhrer both are talking about changes to IKEv2. I=E2=80=99m = happy to see a one-time-use stream of such key material; that=E2=80=99s = effectively our goal with any OOB keying mechanism. I=E2=80=99m not in = favor of attempting to change the IPsec bulk data encryption protocol to = use these OOB keys as a OTP. I think it=E2=80=99s too much to = standardize, implement and test. Of course, I=E2=80=99m not the one who = will be doing the bulk of the work, so if there=E2=80=99s somebody = willing to take it on, I won=E2=80=99t stand in their way. It certainly = is a useful long-term goal for the evolution of they keying, IMO. =E2=80=94Rod From nobody Thu Jun 30 08:23:19 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309B912B004 for ; Thu, 30 Jun 2016 08:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.93 X-Spam-Level: X-Spam-Status: No, score=-1.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFG-_mH6l5Lj for ; Thu, 30 Jun 2016 08:23:13 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45AC912B014 for ; Thu, 30 Jun 2016 08:23:13 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id l188so57978503lfe.2 for ; Thu, 30 Jun 2016 08:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-transfer-encoding; bh=cAHRh2ZnHcw5K5q9yKsYmPgC0F/QGHpOqeKnyzmy0Eg=; b=oZUQR2i+ZNnn9DgRSL7UJjwwk4zH4aPTXCGd3CFfYZuZ8ugLhnbqv7LLCVTEjknLG+ /FPvf0whtXdND3O1cWBDWLCMVEP24n8m/f4PUoLGqGTMfnwD+7bBCUN7kherNBPmGkBz vs10H2+6YiLd6yz44wjLZtq18de0DBEpDXvywdWeqKfXr6/pzFQRjZSipe6mpMorZgap rvbQjt3UetZQkeSrE9qeNVLQdyrIIwFGUE/ZSL6viwzdhvyuEbDJDRXAkg78NnCJrOkr mHS383Jp47o5/YL+9Zh9yJf8AtqsK8nMClbN0b02moidIGbCJvQxhEC68BIIEPuvWw2I oQYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=cAHRh2ZnHcw5K5q9yKsYmPgC0F/QGHpOqeKnyzmy0Eg=; b=ApQcvOKpEvykYAxHzhilQSspMYo77YFgQmv75pjD+518O9wBPWv0iaph6Kx0IKR42T g86RcNWJjSsFNqI25ucYeeo3XLlEgl+dX+YjnGAfhMl0Oe3toRM/g8iHwyskyMmdYGmN YlDRVdv32Aye6wb34ezUNdNgBnHTT4z31YB9TCrE8ZKysjXy8kzx3MkRKpuwBEteuGd/ xz5vr9HL87rV+8Zl+kX56/t7xMRFVnZ7Rwea+f784zbt5y59OouNQzwH7/6F0XxEwxgD pc19mm2CU3XnkQEffznd0hhPVYBkpJSjlf9sokBlvhZkp3j8V9yY83oTDi8GbDtarWkJ H5KA== X-Gm-Message-State: ALyK8tLMbBvszoqSR4Lb7g5HEXLsVkFBp+ONjGjTcDhJZ7ywtA9z5SJVKpNrmhOUeNkBfw== X-Received: by 10.25.134.194 with SMTP id i185mr4312536lfd.116.1467300190808; Thu, 30 Jun 2016 08:23:10 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 89sm1546459lja.35.2016.06.30.08.23.09 (version=TLS1 cipher=DES-CBC3-SHA bits=112/168); Thu, 30 Jun 2016 08:23:10 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <4200F5373D5542C985F3D4C51609213C@buildpc> Date: Thu, 30 Jun 2016 18:23:09 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 15:23:17 -0000 Hi Paul, thank you for part two of your review. > This is part two of my review. I do think the document needs some work > moving text to better locations and I have some questions I would like > to see resolved. I wrote down some nits but stopped doing that in the > end because I think chunks of text shoud be moved. By biggest issue > is that section 6 and section 7 are not clearly separated, and I see > various chunks of text I think is in the wrong section (or is section 6 > text repeated in section 7) > > I think this document should update 7296 due to adding non-encrypted > payloads to IKE_AUTH - even though the core IKEv2 RFC does not say that > is not allowed. Someone implementing 7296 should be aware of it to allow > it in their implementation. Hmmm... Not sure it is needed. As you said RFC 7296 doesn't explicitely prohibit that (so we don't violate its requirements) and there is a clear negotiation mechanism with puzzles, so that old implementations won't be affected. I think we should be consitent in our policy whether to update core RFC or not. For example, RFC 5723 (Resumption) defines new exchange IKE_SA_RESUME that can be used in conjunction with IKE_AUTH instead of IKE_SA_INIT. RFC 7296 tells only about IKE_SA_INIT + IKE_AUTH, however RFC 5723 doesn't update IKEv2 RFC. Is our situation much different? I don't think so. To be clear - I'm not against updating RFC 7296, I just think it is not needed. > I will redo a nits/grammer check on the next iteration of the document. OK. > Note, that it is not possible with clients using NULL Authentication, > since their identity cannot be verified. > > It feels that this sentence should be followed by some specific advise for > this category of clients? What's your suggestion? We've mentioned several times that NULL Authentiacted peers are special case for DoS defense, here we just remind about this fact to readers once more. I don't think any special advice could be gived here. If you have one, please share it with us. > Section 6 descibes in item 1: "A general DDoS attack" some numbers that I > find dangerous to follow. It descibes a scenario of 20 tunnels per second > as expected that when increased to 100 tunnels per second is considerared > a DDOS attack. But that does not take into account network failures > that would cause a large chunk of clients to reconnect at once. While > the draft says this "can be interpreted as an attack", implementors > might just put in these hardcoded numbers from the document. I'd rather > describe it a bit different so we don't give them these absolute numbers. Well, there is a text in the beginning of this section: the numbers given here are not normative, and their purpose is to illustrate the configurable parameters needed for defeating a DDoS attack. Isn't this text enough for any sane implementer not to hardcode those numbers? > for example: > > Typical measures might be 5 concurrent half-open SAs, 1 decrypt > failure, or 10 EAP failures within a minute. > > Why is this "typical"? And again, these numbers provide too tempting easy > numbers for implementors to hardcode in their implementation. And I > think these are speculation at best. How about: For example, measures might be 5 concurrent half-open SAs, 1 decrypt failure, or 10 EAP failures within a minute. > puzzle difficulty should be set to such a level (number of zero-bits) > that all legitimate clients can handle it without degraded user > experience. > > This is of course the big issue of this draft. Is this possible at all? > Note te _lack_ of specific numbers here :) Yes, no specific figures can be given here. This text just says that unless the responder finds itself under severe DoS attack, puzzles, if used, must not be hard. > I don't understand this paragraph: > > it is best to begin by requiring stateless cookies from all > Initiators. This will force the attacker to use real source > addresses, and help avoid the need to impose a greater burden in the > form of cookies on the general population of Initiators. > > Perhaps the "form of cookies" was meant to say "puzzles" ? Agreed. > And this one confuses me too: > > When cookies are activated for all requests and the attacker is still > managing to consume too many resources, the Responder MAY increase > the difficulty of puzzles imposed on IKE_SA_INIT > > But up to now, we haven't been given advise to enable puzzles, and now we > are recommended to increase the difficult of puzzles? This text has already been corrected (thanks to Dave's review). > If the load on the Responder is still too great, and there are many > nodes causing multiple half-open SAs or IKE_AUTH failures, the > Responder MAY impose hard limits on those nodes. > > Unlike elsewhere, it does not describe what failure to send back, if > anything, to the responder. Sending back a NOTIFY might actually not > be desirable, as it would tell the attacker their attack has reached > a good enough volume to lock out real clients. Some advise on how > to handle this scenario is needed. Section 4.2 describes a "Hard Limit" as situation when any further IKE_SA_INIT requests are rejected. In any case, I think section 7 is explicit enough that no NOTIFY is sent in this case. And I think that sending back a NOTIFY is a really bad idea. First, as you said it'll be an extra information for attacker and second - it consumes additional resources from responer that is already under DoS attack, for no good reason. > And confusingly, only NOW are puzzles suggested as a next "last step", > even though before this it already told us to incrase puzzle strength. The text earlier is about puzzles for selected IP addresses, while here it advises to impose puzzles on all initiators. > Why is there not an option to add puzzles to the CREATE_CHILD_SA to > punish just those clients requesting too many of those? (I'm not sure > if it is a good idea, I'm asking because I'm not sure it is a bad idea) Once IKE SA is created you don't need to use puzzles. Section 5 lists less controversal and more effective countermeasures. > Section 7 has: > > According to the plan, described in Section 6, [.....] > > We are not Cylons :) > > Seriously though, section 6 describes _when_ to activate puzzles, and section 7 > should describe how to activate puzzles without any contetx of when to enable it or not. > Currently, section 7 repeats some of the "plan" of section 6, which should not be > needed and makes the implementation section longer/harder to read. Some of the text > in section 7, like the new "processing some fraction of requests" should be in section 6, > not section 7. Well, my understanding is that section 6 gives a higher level picture (roadmap, strategy) of how responder is recommended to defend itself, while section 7 is very specific about how puzzles should be used in IKEv2 to get interoperability. I agree that they overlap, but I don't think they must be merged. When you start implementing puzzles you may read the draft starting from Section 7. So, what's wrong with the fact that SEction 7 refers to SEction 6? Do you want the reference to be removed? > 7.1.1 states: "then it MUST include two notifications in its response message" > So earlier text said "may" also use cookies, and this text assumes there puzzles > can only happen with cookies. That is contradicting. I would say remove the requirement Sorry, where is contradiction? You may always use cookie as described in RFC 7296. > in section 7 and change the text in section 6 to make it obvious that cookies should be > the first line of defense and should still be used when handing out puzzles on top of > cookies. Section 6 already recommends to first require cookies from all initiators before making next step and require puzzles. > If you mean to talk about the interaction or combination of puzzles and cookies, perhaps > a separate section on that would be most clear. Yes. The text above is only meant to say that puzzle notification must always go together with cookie notification. I don't think we need a separate section for this requirement. How about: If the Responder makes a decision to use puzzles, then it includes two notifications in its response message - the COOKIE notification and the PUZZLE notification. Note that the PUZZLE notification MUST always be accompanied with the COOKIE notification, since the content of the COOKIE notification is used as an input data when solving puzzle. > 7.1.1.1 introduces a term ZBC which I have no idea what it means yet. It then talks Already introduced in 4.4. > about difficulty level 0 which I don't know what that is. Does it translate to number The format of the PUZZLE notification is described in 8.1 > of zero's in solution? If so I would expect level 1 to be the lowest? Maybe this > discussion should go into the section 7 introduction. What is the general idea of the > puzzle, what are difficuly levels, etc. I think 4.4 serves this. > The > Responder MAY set different difficulty levels to different requests > depending on the IP address the request has come from. > > I would think that MAY should be stronger, a SHOULD ? If you can detect a few problem > causing IPs or IP ranges, you made good points saying to only punish those with puzzles. I don't think so. It is responder's local matter how to defend itself. > The Responder parses received SA payload and > finds mutually supported set of transforms of type PRF. It selects > most preferred transform from this set and includes it into the > PUZZLE notification. > > I find the use of transform a bit confusing. I would say PRF. (and "most preferred" -> preferred) OK. How about: The Responder parses the received SA payload and finds a mutually supported PRFs. The Responder selects the preferred PRF from the list of mutually supported ones and includes it into the PUZZLE notification. > If there are no mutually > supported PRFs, then negotiation will fail anyway and there is no > reason to return a puzzle. > > I first thought of the AES_GCM not needing PRF, then realised I confused IKE and IPsec SA. > Perhaps add change "negotiation will fail" to "IKE SA negotiation will fail". OK. > 7.1.1.3. Generating Cookie > > If Responder supports puzzles then cookie should be computed in such > a manner, that the Responder is able to learn some important > information from the sole cookie, > > We are in the middle of puzzles and not cookies. Why suddenly cookies? Because puzzles closely linked with cookies :-) > Again, I think the document can use a better introduction in section 7 > that explains the interaction between the two, laying out the principes. Again, section 4.4 introduces puzzles on a higher level. > Only later on do I read responder puzzle state is encoded in the cookie. > The point of encoding puzzle information in the cookie is presumbly so > that this state does not need to be remembered by the responder. So how > does it know "The number of consecutive puzzles given to the Initiator."? > Is this a counter in the ? Yes. However, it is a local matter how responder generated cookie. He could use alternative methods, the method described in this section is only an example. > I would like to put a note here as well about the maximum cookie size of 64 > bytes that implementors might not realise. to avoid naive implementations > building a very big "string cookie" with these bullet points of information. OK. > Cookie = | | > Hash(Ni | IPi | SPIi | | ) > > This would give the responder the AdditionalInfo information which it might Attacker? > use as feedback on how successful the attack is. Why not use an encryption > of using the ? Would that be too expensive for > the Responder? I'd think not as it is not more expensive than decrypting > IKE_AUTH. Sure, it is possible. The above is just an example. However, I don't think an attacker learns much from AdditionalInfo. All the information from there he must already know (of course unless the responder puts there something really sensitive). > Or stick with the second approach listed, where the responder keeps this > state locally, which probably is better anyway because it needs to know > the scale of the entire attack that cannot be learned from individual > negotiation states. Both approaches (and also some combinations of them) are possible. > 7.1.2 states if the inititor does not want to solve a puzzle of difficulty X, > it will pretend not to support the NOTIFY. This causes the responder to not > learn that the initiator rejected the difficulty versus that it just does not > support puzzles. It would be useful for the responder to know how many iniators > support puzzles, so I would recommend a different NOTIFY for the "puzzle too > difficult" error path (Maybe a return notify of PUZZLED :) Hmmm... What the responder shoud do with this notify? Just perform some completely unreliable statistical measurments (for what purpose)? I think that better approach would be for such initiators that want to participate in such polls just solve puzzle with say 1 bit difficulty. It'll cost them always nothing and will read to the same results for responder: serve such initiators with the lowest priority (as if they don't support puzzles). But again, I don't understand what is the value of such polls. > If the received message contains a PUZZLE notification and doesn't > contain a COOKIE notification, then this message is malformed because > it requests to solve the puzzle, but doesn't provide enough > information to do it. > > Again, conflicting with earlier text saying cookies are not mandated for puzzles, > which now it seems they are. Sorry, I don't see where the conflict is. Cookie mechanism is unchanged from RFC 7296. Puzzles mechanism is used only with cookie mechanism because cookie content is used while solving puzzle. > It seems 7.1.4 paragraph 2 and 3 are better moved to the introduction of that > section. I think it will make reading the section more difficult. Why do you think is is needed? > If a PS payload is found in the message, then the Responder MUST > verify the puzzle solution that it contains. > > Doesn't that open up the responder to a DDOS attack. Initiators will just > submit fake puzzle solutions to drive up the initiator CPU. Every defense mechanism has its limits. If attacker can exhaust your CPU by sending fake puzzle solutions, then you loose. > Also, if the responder is no longer under attack, why can't it just ignore > the puzzle solution and continue with regular IKE? I see your point. However the puzzles must be easy to check, especially if the responder is not under attack. Are you suggesting to change this MUST to SHOULD? Then what are situations when responder can skip puzzles validation? > if the Responder didn't indicate any > particular difficulty level (by setting ZBC to zero) and the > Initiator was free to select any difficulty level it can afford, > > Woah, these options were not discussed before at all. So that's what level 0 means! > I would really move this text to the start of section 7 in the introduction of how > puzzles work in general. These options are described in 7.1.1.1 > o Demand more work from Initiator by giving it a new puzzle. > > This seems a waste of a round trip. Why can the responder demand a variable puzzle > without telling what would make it happy, only to have the initiator misguess and > cause another roundtrip, or to avoid a potential roundtrip, waste too much resources > and cause visible delays to endusers by overestimating puzzle difficulty? I think > this is not a good feature of the protocol. It is the responder's local policy whether to demand more work (by requesting new puzzle) or not. > The more puzzles the Initiator solves the higher its chances are to be served > > That seems bad. Each puzzle is a delaying round-trip! But each new puzzle proves that the initiator spends more effort, so its chances to be served raise with each round trip. I don't think where will be more than 2-3 of them. And in many cases solving more difficult puzzle would delay connection more than solving a few of less difficult ones, even with additional round trips. > includes a puzzle > solution in the first IKE_AUTH request message outside the Encrypted > payload > > Note this is very exceptional and should probably be written out in our syntax, eg: > > HDR, SK {IDi, [CERT,] [CERTREQ,] > [IDr,] AUTH, SAi2, > TSi, TSr} [PUZZLE] --> Your picture is wrong. SK payload is always the last payload in the message (according to RFC 7296), so PS payload can only be placed before it. And it is not optional in case the puzzle mechanism is used. What's wrong for you with the picture from the draft? HDR, PS, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SA, TSi, TSr} --> > While I checked RFC 7296 it does not state some exchanges only have encrypted payloads, > and so technically this document does not update the core document, but I think many > implementations might not expect unencrypted payloads in IKE_AUTH and CREATE_CHILD_SA > so perhaps that is important enough to mark this document as "updating 7296". Please, see above (the beginning of this message). > in the IKE_AUTH exchange S is a concatenation of Nr and SPIr. > > Why Nr and SPIr? I think because of re-using DH vales on the responder? If so, it would > be good to explain that. No, it has nothing common with reusing DH secrets. We just need fresh some unpredictable for an Initiator data for solving IKE_AUTH puzzles, so Nr and SPIr are natural choise. > Should it state somewhere that IKE_AUTH puzzles are not allowed unless the clinet > confirmed support for puzzles in IKE_INIT. Because then the responder does not actually > know whetrher the initiator supports puzzles at all. And since it is stated those IKE_AUTH > responses without puzzle should be silently dropped, that becomes very important. Section 7.2.1 says: The Responder MUST NOT use puzzles in the IKE_AUTH exchange unless a puzzle has been previously presented and solved in the preceding IKE_SA_INIT exchange. Isn't it not enough? > I think the IKE fragmentation paragraph deserves to be in its own sub-section. It's pretty > important to get it right and not start attempts to decrypt potentially bogus fragments. I'm very reluctant to do so, since IKE fragmentation nuances are present in severalsections. I think it's better to have them "in place" rather than keep together out of context. Another option is to make IKE Fragmentation dedicated subsection in every relevant section, but it's usually only a para and somebody already complained on the large number of subsections in Section 7. So, unless you think it is absolutely necessary, I'll refrain from doing that. > Regarding the puzzle format, this is now 11 octects. we've aligned things in the past, so > should we do that hear and add another 1 octet of reserved bits? The puzzle notification I'd rather make it compact. We already have payloads and notifications with odd length even in the core spec (like CERREQ or IPCOMP_SUPPORTED) and there is no any requirement in IKEv2 that payloads are aligned, so I don't see any reason for wasting an extra byte in the precious IKE_SA_INIT spae (remember IP fragmentation!). > also misses an IANA line: The payload type for the Puzzle payload is . It is in the description of the corresponding field: o Notify Message Type (2 octets) -- MUST be , the value assigned for the PUZZLE notification. > Section 9 states: A good rule of thumb is for taking about 1 second to solve the puzzle. > > Why is this a good rule of thumb? Again this comes down to me having no idea whether or There are some explanations below. > not puzzles is a good idea to begin with. I'm very skeptical of this claim. A botnet > will be able to waste 1s of 99% CPU on this attack per node. Then the difficulty level will increase. > Initiators should set a maximum difficulty level beyond which they > won't try to solve the puzzle and log or display a failure message to > the administrator or user. > > and again note that this information will never be available to the Responder, so it > can never figure out what solving levels is causing a sharp drop in legitimate clients. > (other than seeing an attack that is more successful, but it won't know that this is > caused by the puzzle difficulty level) Do you have better solution? > that the Responder's load remain close to the maximum it can tolerate. > > Which ignores the pain on initiators. it should probably be pointed out somewhere > that confirmation a puzzle solution is a lot cheaper than solving the puzzle. The text means that the difficulty level must not be too high even under attack. So, I don't understand how it ignores the pain on initiators. Instead, the responder is advised to keep difficulty level as low as possible, only to keep itself operational even under attack, so that it can still serve legitimate initiators. > nits Accepted most of them, exceptions described below. > Note this draft also mentions IKEv2 with version instead of > refering to just IKE, which makes more sense if we end up > with IKEv3. > > buggy implementation -> broken implementation > > escape any responsibility for its actions -> > escape any responsibility for its bad behaviour > > Since currently there is no way -> Since there is currently no way > > In IKEv2 client can request various configuration attributes -> > In IKE, a client can request various configuration attributes > > Most often those attributes -> Most often these attributes > > for defeating the DDoS attack -> for surviving DDoS attacks. > > Implementations may be deployed in different environments -> > Implementations are deployed in different environments > > As an example -> For example > > , searching for two things: -> for two scenarios: > > Supposing the the tunnels -> Supposing that the tunnels > > If they are mitigated well enough -> If these are mitigated successfully > > > This is a good > thing as it prevents Initiators that are not close to the attackers > from being affected. > > I think this sentence adds nothing and can be removed. > > This will force the attacker to use real source addresses, -> > This will mitigate attacks based on IP address spoofing > > I would probably shorten the introduction of section 7 to something like: > > Puzzles can be added in the IKE_INIT and IKE_AUTH ecchanges. > > and leave out the text describing the document flow, like "Both sections are divided into ..." Well, that part was added by Dave's request as a short descrition of Section 7 subsections. > The message may optionally contain a COOKIE notification > > If implementations base themselves on this draft, it is actually basically > guaranteed to have a cookie, say "may optionally" seems a bit weak? > "most likely" or "usually" seems better. > > I mean, this part of the document should assume previous parts of the document > are implemented. This section describes how puzzles are handled by the responder, including situations with non-supporting initiators, in which cases COOKIE is really optional/ So, left as is. > To support this feature -> To support crypto agility > > also MAY ignore -> MAY ignore > > ready to deal with them, -> ready to solve them" Thank you, Valery. From nobody Thu Jun 30 09:26:40 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B6112DA9C; Thu, 30 Jun 2016 09:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.646 X-Spam-Level: X-Spam-Status: No, score=-5.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B1bUXR2ZS83; Thu, 30 Jun 2016 09:26:34 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0992312B036; Thu, 30 Jun 2016 09:26:33 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u5UGQSG8003764 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 30 Jun 2016 16:26:28 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u5UGQQ3T004638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 30 Jun 2016 16:26:26 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u5UGQJOZ021197; Thu, 30 Jun 2016 16:26:25 GMT Received: from oracle.com (/10.154.163.237) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 Jun 2016 09:26:19 -0700 Date: Thu, 30 Jun 2016 12:26:15 -0400 From: Sowmini Varadhan To: Rafa Marin Lopez Message-ID: <20160630162615.GA32734@oracle.com> References: <4A95BA014132FF49AE685FAB4B9F17F657EB4B26@dfweml501-mbb> <4A95BA014132FF49AE685FAB4B9F17F657EB587D@dfweml501-mbb> <3AC251AC-3DB4-42BD-BDC5-25A23C1A219C@um.es> <4A95BA014132FF49AE685FAB4B9F17F657EB5D2B@dfweml501-mbb> <20160617212648.GB29411@oracle.com> <4D1F6DFD-12E1-4EA7-B440-C18203758C37@um.es> <20160619214543.GD654@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: "I2NSF@ietf.org" , "IPsec@ietf.org" , Sowmini Varadhan , Linda Dunbar Subject: Re: [IPsec] [I2nsf] How does Overlay Network inform the Underlay network on which flows among Overlay network nodes need to go through IPSec Tunnel? (was : Flow Security Policies exchanged over I2NSF service layer interface? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 16:26:36 -0000 Hi, sorry for the delay in response, needed some time to go over the draft carefully. Here are some comments. > 1. Introduction : > .. In this sense, it will provision the required > parameters to create valid entries in the Security Association > Database (SAD), which we assumed to be in the data plane. That definition was a bit unusual (at least from a network-stack perspective) and threw me off. The SAD is security assoction database, thus it is not "data plane" as such, but rather, a database configured by the control-plane that is looked up by the network stack's dataplane. (In the same way, the SPD is also just a security policy database, so the decision to call one "control plane", while the other as "data plane" is also quite confusing). > Therefore, > the data plane will have only support for IPsec while SPD and IKE > functionality is moved to the control plane. In both cases, to carry > out this provisioning, an interface/protocol will be required between > the SDN controller and the data plane to send: the policies to be Again, perhaps my notion of "data plane" does not match the intention, but the SDN controller has to interface with the control plane (i.e, the IKE implementation in the network resource) in case 1. Seems to me like case-1 vs case-2 is basically a split-IKE model (where IKE is split between the network-resource and the controller) and a model where the network resource implements IPsec only, with IKE exclusively managed by the controller. > 5. Case 1: IKE/IPsec in the network resource : > Advantages: It is simple since network resources typically have and > IKE/IPsec implementations. > > Disadvantages: 1) IKE implementations needs to renegotiate IPsec SAs > upon SPD entries changes without restarting IKE daemon. 2) Data plane > more complex. How does the data-plane become any more complex than a non-SDN env where there would be no controller? The only change introduced by the controller is that the IKE/IPsec SAs and policies are now orchestrated via the controller. I do agree that this results in a split-IKE model, which may need to be thought through. > 6. Case 2: IKE and SPD in the SDN Controller : > Advantages: 1) There is clear separation of data plane (IPsec > protection per flow) and control plane (IKE and SPD policies). > Hence, it allows less complex data planes. 2) IKE does not need to be > run in gateway-to-gateway scenario with a single controller (see > Section 8.1). Moving IKE into the controller will result in a fairly complex controller implementation, making the control plane extremely complex (we need to now worry about interop, compat with config options supported by existing IKE impelementations etc) Section 8.1 underlines this somewhat- essentially the controller is now doing everything that a standard IKE implementation would do. Trying to get this to work with a stock TCP/IP stack implmentation would be quite complex (whereas stock TCP/IP stack implementations already deal correctly with stock IPsec/IKE implementations). There may also be other complications, if the IKE-enabled-controller has to negotiate IKE on behalf of some other entity (network resource) with a peer that thinks it is negotiating iwth the network-resource itself. I dont know if the current IKE specs would have some issues with that. --Sowmini From nobody Thu Jun 30 17:16:17 2016 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C922612D0A7 for ; Thu, 30 Jun 2016 17:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jExX_GVs_a7d for ; Thu, 30 Jun 2016 17:16:13 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0120.outbound.protection.outlook.com [23.103.200.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606A012D0A0 for ; Thu, 30 Jun 2016 17:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FpbjuWUMkAi7MeQOGdOnrV5jSRFfiGGqG4k5gj+3PSo=; b=jBV4f+0qjpjWAnIiDnInE4b3vUosRYeCbkPnxrvtFP4r9TAcVkeDJpVsW6ZzS/3EQnCRL+uxeO0LkHd7T9NyCDkr7qx9Xcst4cZqPWaLjqET+O1mCEnedYl2xxpndGxe/r8GifN28U7LsDRQdMUX+cdwihVNHq70pJo49ShGdN8= Received: from CY1PR09MB0662.namprd09.prod.outlook.com (10.161.172.20) by CY1PR09MB0662.namprd09.prod.outlook.com (10.161.172.20) with Microsoft SMTP Server (TLS) id 15.1.528.16; Fri, 1 Jul 2016 00:16:11 +0000 Received: from CY1PR09MB0662.namprd09.prod.outlook.com ([10.161.172.20]) by CY1PR09MB0662.namprd09.prod.outlook.com ([10.161.172.20]) with mapi id 15.01.0528.020; Fri, 1 Jul 2016 00:16:11 +0000 From: "Waltermire, David A. (Fed)" To: "Scott Fluhrer (sfluhrer)" , "paul@nohats.ca" , David McGrew Thread-Topic: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document Thread-Index: AQHR0y3FWm7UWPXSRFyRus61cfvSJA== Date: Fri, 1 Jul 2016 00:16:10 +0000 Message-ID: <801841A44829C337E33105CAD6DEF511D6735721@unknown> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [108.18.200.221] x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr,ExtAddr x-ms-office365-filtering-correlation-id: 079462f1-9b26-4412-c0b7-08d3a144e7fc x-microsoft-exchange-diagnostics: 1; CY1PR09MB0662; 6:Mx71RO0ksajArOF3Sgpc4i2/hPdQYn0ixyqVxG91546/hu4Qui+LgaJJrc4Tf8gISstvaY/Cvj65LVVDK1t28jlLnHkB+jVXvUtv1sOHzETuKrZOF/razBndgfaLiXqPaRsIOc7NpoHTAK6ngqg21vDN5Ho0nOWTqfHaLsXaMmqbz2IpmWr0UOaYWFwpy5gxeHOipl9XgIiK8tY6vJfp4l0szxw1j63mA3pJVnDC2xWJ6Z+wAhsBpG8/Wo10laZ22uqVRxXuqFE58tuICczg/yMOGQlRYziaFobCcsH7fww//2Z0bI6Zo+w1uighnm2TDucsX4OktZAs9hDqqow1/g==; 5:GfVF21IT42egDOg0O9NMog/YAmYvdaFYi0PqGjnDpWD5YFNlxl1ZlUt3CsHkH9yq6A0KK18Chpy9iqnZJsZxtjEtHSpwR6iHAx7KL/KSCEIC3dJjBgNMeqbpOap40MulxOsf/o/J0A1+U7/zpvWBgg==; 24:sru4JH30Z5EP+oTa7t+tp6Plu7kUYbuinywCWZvVsow2ruIflKaZ3ftzbZMUAyEc+v7PQUdyXbhsbRtgxjoX3dJ1OppkQRhbhuvBRbOCI2E=; 7:NvyDoHIazFxvb1Gzmv+QIKlUyl1pCbXKbdNw14Ue84CuIyghWe902MmHf4zaZ4iZgCbO49ixmIE46XnQ6VkCL72UQcgCRhHQO/EOCZoDKk91Mcf9SLOyO2BjkYDxsz74UXc8ydWFEBzogVgGrfZnjhIn6SKAqar5ctT2+jBArhT1SyxCxwz2Sb+ND8tbCLPSxmXhv47zn2srg4+pq1BB1wtjC9TW72WB/m/b0EdA/aoTDsWhSJaqLVZHFNY/3Baj x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0662; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:CY1PR09MB0662; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0662; x-forefront-prvs: 0990C54589 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(13464003)(189002)(57704003)(199003)(377454003)(7736002)(105586002)(106116001)(66066001)(86362001)(586003)(55846006)(68736007)(102836003)(2906002)(106356001)(6116002)(101416001)(11100500001)(3660700001)(97736004)(189998001)(92566002)(8936002)(77096005)(5001770100001)(2501003)(5002640100001)(33716001)(99286002)(2860100001)(3846002)(19625215002)(81156014)(81166006)(2930100002)(2920100001)(2900100001)(3280700002)(8676002)(16236675004)(50986999)(19580405001)(19580395003)(9686002)(122556002)(87936001)(54356999)(7846002)(230783001)(33656002)(10400500002)(4326007)(82676001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0662; H:CY1PR09MB0662.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_801841A44829C337E33105CAD6DEF511D6735721unknown_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2016 00:16:10.8929 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0662 Archived-At: Cc: IPsecME WG , "Panos Kampanakis \(pkampana\)" Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 00:16:16 -0000 --_000_801841A44829C337E33105CAD6DEF511D6735721unknown_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Could multiple identifier aliases be used to provide different ids for the = same key? This could help preserve anonymity until all id aliases are exhau= sted. By providing enough aliases, the same key can be reused multiple time= s until the aliases run out. Dave ________________________________ On: 24 June 2016 11:26, "Scott Fluhrer (sfluhrer)" wro= te: > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: Friday, June 24, 2016 9:43 AM > To: David McGrew (mcgrew) > Cc: Waltermire, David A. (Fed); IPsecME WG; Scott Fluhrer (sfluhrer); Pan= os > Kampanakis (pkampana) > Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IP= SecME > WG document > > On Fri, 24 Jun 2016, David McGrew wrote: > > Hi David, > > > Because QKD is not a practical system for Internet security. It has s= erious > security issues/challenges and operational limitations on bitrate, range,= and > physical media. It requires a point to point optical link, which is typ= ically > dedicated fiber, which must be shorter than 60 miles. There are security > issues with QKD because it relies on a physical interaction across the li= ne > between the encrypter and decrypter, thus giving an attacker the > opportunity to perform an attack on the physical process anywhere on that > line. See for instance Brassard et. al. Security Aspects of Practical Q= uantum > Cryptography, Lydersen et. al., Hacking commercial quantum cryptography > systems by tailored bright illumination, or Gerhardt et. al., Full-field > implementation of a perfect eavesdropper on a quantum cryptography > system. Another major security problem is the range limitation; it has = been > proposed to extend the range of QKD by using a chain of trusted repeaters= , > each connected by a QKD sy > stem. These repeaters would greatly increase the attack surface, and > require the end user to trust the infrastructure provider(s); in contrast= , the > Internet community wants end to end encryption, as described in RFC3365 > and RFC7624. > > > > In contrast, QR-IKEv2 can be used to add postquantum security between > any two points on the globe, without requiring dedicated fiber, and witho= ut > requiring physical layer security assumptions. It has *fewer* security > assumptions than draft-nagayama-ipsecme-ipsec-with-qkd, as that draft > relies on the security of symmetric cryptography and the physical layer, > whereas QR-IKEv2 relies only on the former. > > For a postquantum IKEv2 extension, does it matter which underlying > mechanism is used to provide the extra bits to mix into the SKEYSEED? > > I think what is needed is: > > - A NOTIFY message that signals an identifier of where the extra bits > should be taken/generated from. Both endpoints have previous > knowledge > of what tjos identifier refers to. Be it a hardware device or an > offset in a onetime pad, etc, etc. One possible concern is whether such a notify message would compromise the = anonymity properties of IKE; if someone in the middle sees the same identif= ier in multiple exchanges, would they be able to conclude that those are th= e same individuals negotiating? If the NOTIFY messages are anonymized, how= is that done? Now, it might be that the WG would decide to compromise on such anonymizati= on concerns; this would simplify things a lot, however it's very much somet= hing we need WG agreement on. > > - A specification on how to mix in these extra bits into SKEYSEED generat= ion > to gain postquantum security. The reason we specify modifying the public nonces (rather than doing a more= fundamental change to the skeyseed computation) was to minimize changes to= the IKE implementation itself (and in particular, the crypto parts). Is t= here a reason why we wouldn't continue with this approach? > > - Any additional counter meassures (such as increased minimum keysizes) And what algorithms are suggested (e.g. XCBC and CMAC both don't work, as t= he standard IKE versions are fixed to 128 bit keys) > > Do we need to know if these bits came from a QKD link, a QR link, or a > mutually shared onetime pad? If not, then these specifics should not go i= nto > such an ikev2 extension. > > Paul --_000_801841A44829C337E33105CAD6DEF511D6735721unknown_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Could multiple identifier aliases be used to provide different ids for the = same key? This could help preserve anonymity until all id aliases are exhau= sted. By providing enough aliases, the same key can be reused multiple time= s until the aliases run out.

Dave

On: 24 June 2016 11:26, "Scott Fluhrer (sfluhrer)" <sfluhrer@c= isco.com> wrote:

> -----Original Message-----
> From: Paul Wouters [mailto:paul@noha= ts.ca]
> Sent: Friday, June 24, 2016 9:43 AM
> To: David McGrew (mcgrew)
> Cc: Waltermire, David A. (Fed); IPsecME WG; Scott Fluhrer (sfluhrer); = Panos
> Kampanakis (pkampana)
> Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an= IPSecME
> WG document
>
> On Fri, 24 Jun 2016, David McGrew wrote:
>
> Hi David,
>
> > Because QKD is not a practical system for Internet security. = ;  It has serious
> security issues/challenges and operational limitations on bitrate, ran= ge, and
> physical media.   It requires a point to point optical link,= which is typically
> dedicated fiber, which must be shorter than 60 miles.  There are = security
> issues with QKD because it relies on a physical interaction across the= line
> between the encrypter and decrypter, thus giving an attacker the
> opportunity to perform an attack on the physical process anywhere on t= hat
> line.   See for instance Brassard et. al. Security Aspects o= f Practical Quantum
> Cryptography, Lydersen et. al., Hacking commercial quantum cryptograph= y
> systems by tailored bright illumination, or Gerhardt et. al., Full-fie= ld
> implementation of a perfect eavesdropper on a quantum cryptography
> system.   Another major security problem is the range limita= tion; it has been
> proposed to extend the range of QKD by using a chain of trusted repeat= ers,
> each connected by a QKD sy
>  stem.  These repeaters would greatly increase the attack su= rface, and
> require the end user to trust the infrastructure provider(s); in contr= ast, the
> Internet community wants end to end encryption, as described in RFC336= 5
> and RFC7624.
> >
> > In contrast, QR-IKEv2 can be used to add postquantum security bet= ween
> any two points on the globe, without requiring dedicated fiber, and wi= thout
> requiring physical layer security assumptions.   It has *few= er* security
> assumptions than draft-nagayama-ipsecme-ipsec-with-qkd, as that draft<= br> > relies on the security of symmetric cryptography and the physical laye= r,
> whereas QR-IKEv2 relies only on the former.
>
> For a postquantum IKEv2 extension, does it matter which underlying
> mechanism is used to provide the extra bits to mix into the SKEYSEED?<= br> >
> I think what is needed is:
>
> - A NOTIFY message that signals an identifier of where the extra bits<= br> >    should be taken/generated from. Both endpoints have = previous
> knowledge
>    of what tjos identifier refers to. Be it a hardware = device or an
>    offset in a onetime pad, etc, etc.

One possible concern is whether such a notify message would compromise the = anonymity properties of IKE; if someone in the middle sees the same identif= ier in multiple exchanges, would they be able to conclude that those are th= e same individuals negotiating?  If the NOTIFY messages are anonymized, how is that done?

Now, it might be that the WG would decide to compromise on such anonymizati= on concerns; this would simplify things a lot, however it's very much somet= hing we need WG agreement on.

>
> - A specification on how to mix in these extra bits into SKEYSEED gene= ration
>    to gain postquantum security.

The reason we specify modifying the public nonces (rather than doing a more= fundamental change to the skeyseed computation) was to minimize changes to= the IKE implementation itself (and in particular, the crypto parts). = Is there a reason why we wouldn't continue with this approach?

>
> - Any additional counter meassures (such as increased minimum keysizes= )

And what algorithms are suggested (e.g. XCBC and CMAC both don't work, as t= he standard IKE versions are fixed to 128 bit keys)

>
> Do we need to know if these bits came from a QKD link, a QR link, or a=
> mutually shared onetime pad? If not, then these specifics should not g= o into
> such an ikev2 extension.
>
> Paul
--_000_801841A44829C337E33105CAD6DEF511D6735721unknown_--