From svanru@gmail.com  Fri Jan 10 03:22:19 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F245A1ACC82 for <ipsec@ietfa.amsl.com>; Fri, 10 Jan 2014 03:22:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 ZthoXV0Q7WAm for <ipsec@ietfa.amsl.com>; Fri, 10 Jan 2014 03:22:16 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id ED0CB1AC4C1 for <ipsec@ietf.org>; Fri, 10 Jan 2014 03:22:15 -0800 (PST)
Received: by mail-lb0-f171.google.com with SMTP id w7so3319656lbi.30 for <ipsec@ietf.org>; Fri, 10 Jan 2014 03:22:05 -0800 (PST)
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-type:content-transfer-encoding; bh=39CBvbaAPdQVCiNJpjjvqQggtH7H10j/Q2CVQQDUB+A=; b=LSHfY+6BeWmOGNmfnqeKlOZDdxcvVCdqu9FIlAmbqwYQTC2uHQgOqsYzop3dj0RptF yqvXRDEkyCEgnEX6gbrRJX0RIC/GUdysE7wqMMAPHGs7xILtJ9UWJd/AlfZFKkuPvGIS sqdvCfPJJ+3viMg7BpiFhmaLBb8GEXCK+kThQ3hTUghfEIJ7rsBRmCvY6shkn4Oruhau mLkJSlqSlHk96VFAC0gDfvXVyZS5NAKtN1T47C2DDgmqMqChB7J9n48AdLmFBJl2QjOn bteEbKBz1CyZZVgFLvWkirSmu7symyIBluSzCl6NIUpfnkA+zj1/SV/dVGGeF3twkfqI uWmg==
X-Received: by 10.152.204.39 with SMTP id kv7mr3552847lac.42.1389352925352; Fri, 10 Jan 2014 03:22:05 -0800 (PST)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id xl4sm4034574lac.9.2014.01.10.03.22.03 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 10 Jan 2014 03:22:04 -0800 (PST)
Message-ID: <32DF7E65FBDB480EA7DBBF86CDA59B66@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Paul Wouters" <paul@nohats.ca>
References: <C687BD9EA2204F1087D18646766A3C7B@buildpc> <alpine.LFD.2.10.1312301901450.16515@bofh.nohats.ca>
Date: Fri, 10 Jan 2014 15:21:59 +0400
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
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2014 11:22:19 -0000

Hi Paul,

please, see my comments inline.

> This is what we (libreswan) have started implementing as well, although we
> called it AUTH_NONE instead of AUTH_NULL. We use private range number 201
> for this exchange type. We also followed the PSK exchange method. But
> we are still looking at some issues and therefor have not yet written
> out our implementation as draft yet. For those interested, libreswan
> developers are meeting up in San Francisco in the second and third week
> of January to work on OE (both anonymous and authenticated). Ping me if
> you would like to attend.
>
> Valery's draft is a start, but we need to address a lot more than just
> defining a new IKEv2 AUTH method:
>
> 1) Use of IDs
>
> I don't think we should allow any IDs, as there could be conflicts with
> other non-anonymous connections. Or possibly a way to detect which
> non-anonymous IDs are accepted at the remote. I was leaning towards
> mandating the ID to be "anonymous" to make it extremely clear that this
> is an anonymous connection.

I think that using NULL Auth method clearly identifies
anonymous users and allows to distingush them from regular ones.
Adding special "anonymous" ID here seems to be superfluous.

First, in this case you need to specify what to do when
"anonymous" ID is used with regular auth method or
NULL auth method is used with non-"anonymous" ID.
More conditions to check - more branches - more possibilities
to make errors in code. Second, as Yaron pointed out, IDs
may still be useful for upper level and sometimes even
could be verified via out-of-band means.

So, I think that it's better to follow Occam's razor principle here
and not to add new ID type, as all that it could tell to the peer
is already told by using NULL Auth method.

> 2) Endpoints
>
> Your draft does not state anything about the traffic selectors. I think
> it is important to specify it for only a single host-to-host connection
> only. Deployments who want to protect a whole subnet can use similar
> tricks to load balancers and capture port (4)500 and use the NAT-T
> capability of IPsec. Allowing subnet-to-subnet is just too dangerous
> because there are no verifiable claims yet about who owns what IP range.

Aren't these restrictions too narrow? I can imagine situation with
anonymous user access to protected network (some kind of DMZ).
In this case we will have one-way authentication (server will be
authenticated, but user - not) and traffic selectors host-subnet.
I can agree with you that peer using NULL Auth must
represent single IP only, but it is not necessary that
both peers will use NULL Auth, one of them may
be fully authenticated,

> 3) Mode
>
> I would like to only support tunnel mode and not transport mode, due to
> the interaction with NATs - particularly multiple endpoints behind the

Why? Transport mode ESP has no issues with NAT, has it?

> same NAT router. We would hope this happens a lot if everyone enables
> OE (anonymous and non-anonymous). Obviously using AH also makes no sense
> so we should note that this is only valid for ESP.
>
> 4) Mandatory PFS
>
> It should be mandatory to do PFS with an appropriate DH group.

Why should it be mandatory? Why can't it be left to local security policy?

> 5) Priority
>
> The priority of the SPDs of any anonymous IPsec connection should be
> lower than the priority of any non-anonymous SPD. This ensures that
> an anonymous IPsec connection can never steal traffic from an
> authenticated IPsec connection.

Agree.

> non-anonymous with anonymous IPsec
>
> Now this only covers anonymous IPsec. While better than plaintext,
> we do hope servers with stable hostnames will use IPSECKEY records to
> provide their public key, and that the clients will mostly use this new
> auth-none, while the server responds with its FQDN ID so the client can
> verify the connection is not MITMed. In fact, I think it is better for
> roaming devices to remain as anonymous as possible by not providing
> the server with an identity (and why I also do not like your proposal
> of allowing and ignoring the identity).

It doesn't contradict to my proposal - roaming devices can put
anything in their identity or even make it empty - all at their discretion,
so they have all means to keep their anonymity.

Most of your concerns are related to OE use case. I don't think
that NULL Auth is limited to OE case only. User may have all
credentials to authenticate himself, but still prefer to anonymously
access some protected network to prevent traceability of his actions.
On the other hand, I can imagine situation, when user must be authenticated,
but server - not. Consider example with remote garage door opener -
this device must authenticate user to ensure his access to garage,
but does user need to authenticate door opener? I don't think so -
user requests some simple action and can immediately see the result -
either door openes or remains closed.  What additional value
user gains if he will know for sure via IKE that it is exactly the door
he is willing to open? Lacking device authentication may simplify setup.
And these cases are not related to OE, IMHO.

So, I think that it is worth to separate NULL Auth from OE stuff
and describe all OE related issues in a separate draft, that
will use NULL Auth as a mechanism to skip authentication.

Regards,
Valery.

> I have not yet solved the issue of two servers and "return traffic". Say
> host A on public IP initiates anonymously to host B on public IP. Let's
> say both are mail servers. Host A has authenticated host B. Host A
> can now send traffic to host B encrypted. Host B can respond to that
> traffic. While the tunnel is up, host B needs to connect to host A
> for unrelated traffic. It has an IPsec connection up, but it has not
> authenticated this connection. It should not initiate traffic to host A.
> BTNS tried to solve this problem with changing the kernel and doing
> channel binding, but I don't think that solution has support anywhere.
> I can think of some methods on Linux to "hack" detection and support,
> but I'm not happy about it yet.
>
> Evil ranges
>
> Another unresolved problem of using tunnel mode is if a client uses
> somebody elses IP range. eg my laptop behind NAT using 8.8.8.8 should
> not be able to steal the remote's google DNS traffic. Again, I can
> see linux hacks to implement this but I'm still not happy with this.
> One way out is to use CP and assign IP addresses but since our clients
> and servers will have thousands of these of connections there will be
> clashes. Using IPv6 is possible but I'm not convinced the v6-in-v4 IPsec
> has seen enough deployment and might not be implemented widely.
>
> Other kinds of semi-anonymous connections
>
> We are trying to limit the number of different kinds of OE connections
> possible to make it as easy as possible to represent things back to the
> user. So we have left things like "ssh style leap of faith" out of this.
>
> Paul 


From paul@nohats.ca  Sat Jan 11 09:46:01 2014
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4391A1AE086 for <ipsec@ietfa.amsl.com>; Sat, 11 Jan 2014 09:46:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level: 
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538] autolearn=ham
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 9kI5ZnAGGM2B for <ipsec@ietfa.amsl.com>; Sat, 11 Jan 2014 09:45:58 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id A25B01AE085 for <ipsec@ietf.org>; Sat, 11 Jan 2014 09:45:58 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B3F1A800A1; Sat, 11 Jan 2014 12:45:46 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1389462346; bh=Jzgn1UaZb1tsIVhSRNWU2M1on71J5fNIHx705l6KGdA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=WwE3E0nT2Z5YiR/mHRSkB1KOeRiDozdSAbjXn0WX5PH2+lt8+G0Ajvg6HBVQpZfN9 9pBnU8OzIoDQt6Yuc1PAJv6m1O+Ot82phjs+fte8SUAhIBxPUtHjhLb9eg6JbnQCp7 lHV4tc1D/mkAw0XhaZu7nC2KbSDgFGx0AAAa4zqA=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s0BHjkUr021928; Sat, 11 Jan 2014 12:45:46 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Sat, 11 Jan 2014 12:45:46 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: Valery Smyslov <svanru@gmail.com>
In-Reply-To: <32DF7E65FBDB480EA7DBBF86CDA59B66@buildpc>
Message-ID: <alpine.LFD.2.10.1401111227070.16447@bofh.nohats.ca>
References: <C687BD9EA2204F1087D18646766A3C7B@buildpc> <alpine.LFD.2.10.1312301901450.16515@bofh.nohats.ca> <32DF7E65FBDB480EA7DBBF86CDA59B66@buildpc>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jan 2014 17:46:01 -0000

On Fri, 10 Jan 2014, Valery Smyslov wrote:

>> 1) Use of IDs
>> 
>> I don't think we should allow any IDs, as there could be conflicts with
>> other non-anonymous connections. Or possibly a way to detect which
>> non-anonymous IDs are accepted at the remote. I was leaning towards
>> mandating the ID to be "anonymous" to make it extremely clear that this
>> is an anonymous connection.
>
> I think that using NULL Auth method clearly identifies
> anonymous users and allows to distingush them from regular ones.
> Adding special "anonymous" ID here seems to be superfluous.

Than you should stick to that and not send any IDs whatsoever.

> to make errors in code. Second, as Yaron pointed out, IDs
> may still be useful for upper level and sometimes even
> could be verified via out-of-band means.

I am strongly against channel bindings, connection latching, or connection
reconfiguration-promotions. Nice good complicated ideas, but they have
failed with BTNS already. If you want access to a non-anonymously shared
resource, setup a proper authenticated IPsec connection.

> So, I think that it's better to follow Occam's razor principle here
> and not to add new ID type, as all that it could tell to the peer
> is already told by using NULL Auth method.

Ocam's razor would tell you not to send IDs if you don't plan to use
them or have the other end use them.

>> 2) Endpoints
>> 
>> Your draft does not state anything about the traffic selectors. I think
>> it is important to specify it for only a single host-to-host connection
>> only. Deployments who want to protect a whole subnet can use similar
>> tricks to load balancers and capture port (4)500 and use the NAT-T
>> capability of IPsec. Allowing subnet-to-subnet is just too dangerous
>> because there are no verifiable claims yet about who owns what IP range.
>
> Aren't these restrictions too narrow? I can imagine situation with
> anonymous user access to protected network (some kind of DMZ).

Again, you are promoting anonymous IPsec to "somewhat restricted could
possibly allow non-anoymous IPsec" upgrades. Don't.

> In this case we will have one-way authentication (server will be
> authenticated, but user - not) and traffic selectors host-subnet.
> I can agree with you that peer using NULL Auth must
> represent single IP only, but it is not necessary that
> both peers will use NULL Auth, one of them may
> be fully authenticated,

The problem is a server vouching for any IP ranges. How do you find out?
What's the discovery mechanism? How can we prevent it from falsely
claiming to give it precious traffic (like 127.0.0.1 or 8.8.8.8). The
initiator knows what IP it was trying to connect to. So to me, it should
be limited to that IP only.

I'll agree we might be able to do this work in another draft. But at
least it should go into the security consideration section.

>> 3) Mode
>> 
>> I would like to only support tunnel mode and not transport mode, due to
>> the interaction with NATs - particularly multiple endpoints behind the
>
> Why? Transport mode ESP has no issues with NAT, has it?

Yes it does, when multiple clients behind the same NAT router try to
connect to the same remote IPsec gateway.

>> 4) Mandatory PFS
>> 
>> It should be mandatory to do PFS with an appropriate DH group.
>
> Why should it be mandatory? Why can't it be left to local security policy?

Because null auth is already weak? Then again, I think PFS should be
made mandatory for all IPsec connections. I guess this could also move
into a separate OE draft.

> It doesn't contradict to my proposal - roaming devices can put
> anything in their identity or even make it empty - all at their discretion,
> so they have all means to keep their anonymity.

But "at their discretion" means someone is going to make an
authentication decision based on it. It's dangerous. Instead of
sprinkling the draft with "SHOULD NOT use ID" and "MUST NOT use ID",
we should simply not give them the option for making such bad mistakes.

> Most of your concerns are related to OE use case. I don't think
> that NULL Auth is limited to OE case only. User may have all
> credentials to authenticate himself, but still prefer to anonymously
> access some protected network to prevent traceability of his actions.

So use NULL AUTH with no IDs? I don't see the problem?

> On the other hand, I can imagine situation, when user must be authenticated,

So don't use NULL AUTH, but a real AUTH with ID.

I don't think we disagree here? When you say "allow the ID to be used
for audit only" I think you are introducing a false sense of security.
That ID could be easilly forged making the audit log incorrect. The
audit log _should_ log no ID if presented with a forgable ID.

> So, I think that it is worth to separate NULL Auth from OE stuff
> and describe all OE related issues in a separate draft, that
> will use NULL Auth as a mechanism to skip authentication.

Sure, but than I do really want the ID parts not sent for NULL AUTH.

Paul

From yaronf.ietf@gmail.com  Sat Jan 11 10:32:21 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1171AE104 for <ipsec@ietfa.amsl.com>; Sat, 11 Jan 2014 10:32:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 ze7kLIGU-RAQ for <ipsec@ietfa.amsl.com>; Sat, 11 Jan 2014 10:32:19 -0800 (PST)
Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8751AE0E9 for <ipsec@ietf.org>; Sat, 11 Jan 2014 10:32:19 -0800 (PST)
Received: by mail-ee0-f50.google.com with SMTP id c41so2420171eek.23 for <ipsec@ietf.org>; Sat, 11 Jan 2014 10:32:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lp3CxOEq8yVfi370K/9wWXP8MHTv0UMHW+Jti4dtU3A=; b=iCFvwLrpEdbYF5qAlCz83xgncDW7kkWVU3blb07735fSE6T5tFx03QtV+uS5S7rz4E RzLl58Kyo7WFFRfpQ3noAa7YEmce+9DCQ1zMasrrmtnG8S/OA3PiQnPyYBnwvz0FLLkZ aQa5hphoNrGVrUTxoqrydGdcejLfDDEOfLTDvNsZXv+rzE4PrMT4Kl28u49Sj9S/GWG3 hn3WyuKCqJjvSYplwHDFjdvH/ksK10nX8lM3Tmdle0QAWZNZ9YnfhUS8YEw2Rvt+i+WK wmKg+ZfBy7t+8NiCYVLTxUH3fGous/Jr8/FDtcU9O9Z7NcVmhCSHjb3QvG9f9U5/W/ve JfKw==
X-Received: by 10.15.52.136 with SMTP id p8mr8143006eew.11.1389465128590; Sat, 11 Jan 2014 10:32:08 -0800 (PST)
Received: from [10.0.0.9] (cablep-219-63-169.cablep.bezeqint.net. [62.219.63.169]) by mx.google.com with ESMTPSA id o13sm24854052eex.19.2014.01.11.10.32.07 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 Jan 2014 10:32:08 -0800 (PST)
Message-ID: <52D18E26.90108@gmail.com>
Date: Sat, 11 Jan 2014 20:32:06 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Paul Wouters <paul@nohats.ca>, Valery Smyslov <svanru@gmail.com>
References: <C687BD9EA2204F1087D18646766A3C7B@buildpc> <alpine.LFD.2.10.1312301901450.16515@bofh.nohats.ca> <32DF7E65FBDB480EA7DBBF86CDA59B66@buildpc> <alpine.LFD.2.10.1401111227070.16447@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1401111227070.16447@bofh.nohats.ca>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jan 2014 18:32:21 -0000

Hi Paul,

I regularly use SSH, which binds a public key fingerprint to a DNS name. 
It's usable, and not too complicated.

We can argue why BTNS failed but I don't want to waste our time on that. 
I believe some limited form of channel binding can work. Specifically, I 
am thinking of post facto authentication, e.g. by reading out the 
fingerprint on the phone.

Regarding audit, we can mandate that each record should say something 
like "Snow White (claimed but unauthenticated identity)".

Thanks,
	Yaron

On 01/11/2014 07:45 PM, Paul Wouters wrote:
> On Fri, 10 Jan 2014, Valery Smyslov wrote:
>
>>> 1) Use of IDs
>>>
>>> I don't think we should allow any IDs, as there could be conflicts with
>>> other non-anonymous connections. Or possibly a way to detect which
>>> non-anonymous IDs are accepted at the remote. I was leaning towards
>>> mandating the ID to be "anonymous" to make it extremely clear that this
>>> is an anonymous connection.
>>
>> I think that using NULL Auth method clearly identifies
>> anonymous users and allows to distingush them from regular ones.
>> Adding special "anonymous" ID here seems to be superfluous.
>
> Than you should stick to that and not send any IDs whatsoever.
>
>> to make errors in code. Second, as Yaron pointed out, IDs
>> may still be useful for upper level and sometimes even
>> could be verified via out-of-band means.
>
> I am strongly against channel bindings, connection latching, or connection
> reconfiguration-promotions. Nice good complicated ideas, but they have
> failed with BTNS already. If you want access to a non-anonymously shared
> resource, setup a proper authenticated IPsec connection.
>
>> So, I think that it's better to follow Occam's razor principle here
>> and not to add new ID type, as all that it could tell to the peer
>> is already told by using NULL Auth method.
>
> Ocam's razor would tell you not to send IDs if you don't plan to use
> them or have the other end use them.
>

From yaronf.ietf@gmail.com  Sat Jan 11 11:06:49 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5668C1AE132 for <ipsec@ietfa.amsl.com>; Sat, 11 Jan 2014 11:06:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.276
X-Spam-Level: 
X-Spam-Status: No, score=-1.276 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, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=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 pM1hcRS4hG6I for <ipsec@ietfa.amsl.com>; Sat, 11 Jan 2014 11:06:48 -0800 (PST)
Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4161AE130 for <ipsec@ietf.org>; Sat, 11 Jan 2014 11:06:47 -0800 (PST)
Received: by mail-ee0-f45.google.com with SMTP id d49so2465548eek.4 for <ipsec@ietf.org>; Sat, 11 Jan 2014 11:06:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=lBPeTefR7AzvbF4ZWiqAXsRnHxll5G6ppKV/MlPpsQU=; b=1E75joH/IxrqhvJbXMvGuSTl33yAGz97U5GHnfx95Byol3T4N/BorAOepuFMXO8zLs GGU+kbbbaVh1UMAC7Lm5bf1N/QUsd7KbAGG0Mv1QYG34Je8XwAB9V2WRHQdjqAHW52Tb 7/IjqXB+EadHjQAy6oT8fXC8NK8emc3guiPMEZBZYENkSM+1sVfKEKuzOU6+BNn6BcqJ pEwx3Xmf1vLW4Uf8vM1p5dSOBpWVi+qjXJbLLDCzRJmdr0Js4W8NkhRYEIN6oaYyrcnS Ddu9eauEhAWuTyEJqMuqBpuRDxxLdH6EQg1JxODtxYCWUSRo/6is530xdT09wXegk8cg ZWMQ==
X-Received: by 10.15.24.72 with SMTP id i48mr17647737eeu.74.1389467197364; Sat, 11 Jan 2014 11:06:37 -0800 (PST)
Received: from [10.0.0.9] (cablep-219-63-169.cablep.bezeqint.net. [62.219.63.169]) by mx.google.com with ESMTPSA id o1sm25051870eea.10.2014.01.11.11.06.36 for <ipsec@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 Jan 2014 11:06:36 -0800 (PST)
Message-ID: <52D1963B.9050106@gmail.com>
Date: Sat, 11 Jan 2014 21:06:35 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: ipsec <ipsec@ietf.org>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [IPsec] AD VPN protocol selection
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jan 2014 19:06:49 -0000

<html style="direction: ltr;">
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;"
    bidimailui-detected-decoding-type="latin-charset" bgcolor="#FFFFFF"
    text="#000000">
    <pre wrap="">Hi everyone,

Paul and I have asked the group to pick one of the three AD VPN proposals as a starting point for a standard. So far we have had a number of reasoned choices from those who are not authors, but unfortunately not enough to let us judge the group's consensus.

I would like to request people (other than authors) who are interested in this area to post their preference to the list, along with their reasons for selecting it. We plan to decide by Feb. 6 (3 weeks from now) whether and how to move forward with the Auto-Discovery VPN protocol.
</pre>
    <pre wrap="">Thanks,
	Yaron 
</pre>
  </body>
</html>

From paul@nohats.ca  Sat Jan 11 21:16:06 2014
Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE98B1AD944 for <ipsec@ietfa.amsl.com>; Sat, 11 Jan 2014 21:16:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.663
X-Spam-Level: 
X-Spam-Status: No, score=-0.663 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_LOLITA1=1.865, RP_MATCHES_RCVD=-0.538, T_FRT_LOLITA1=0.01] autolearn=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 Fs3j-9pkQt6U for <ipsec@ietfa.amsl.com>; Sat, 11 Jan 2014 21:16:04 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 87C461ACCF5 for <ipsec@ietf.org>; Sat, 11 Jan 2014 21:16:04 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BC67B800A1; Sun, 12 Jan 2014 00:15:52 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1389503752; bh=EQgxcf6qytmlrRUBHf+uyKl61OQJLs2aoZVo5hrb+N0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=WfJFuIgMv1NgZOKqRT3hfIKSzH8BpSeGEN3BNFgYeDEYKcWxrVDPPB+RSvtFDtHQF dLR5XCD2s7mNf9W/hAJZkeO+B3QCdJw1uJlKf2VnUpWYtpuowR2VhGieNqnT9iwW+P CvXK0YDeAMbytHm3WKG/ssMpFv6s2LEbxPk8IF90=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s0C5FqdT002296; Sun, 12 Jan 2014 00:15:52 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Sun, 12 Jan 2014 00:15:52 -0500 (EST)
From: Paul Wouters <paul@nohats.ca>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
In-Reply-To: <52D18E26.90108@gmail.com>
Message-ID: <alpine.LFD.2.10.1401120010450.10993@bofh.nohats.ca>
References: <C687BD9EA2204F1087D18646766A3C7B@buildpc> <alpine.LFD.2.10.1312301901450.16515@bofh.nohats.ca> <32DF7E65FBDB480EA7DBBF86CDA59B66@buildpc> <alpine.LFD.2.10.1401111227070.16447@bofh.nohats.ca> <52D18E26.90108@gmail.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: ipsec@ietf.org, Valery Smyslov <svanru@gmail.com>
Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jan 2014 05:16:07 -0000

On Sat, 11 Jan 2014, Yaron Sheffer wrote:

> I regularly use SSH, which binds a public key fingerprint to a DNS name. It's 
> usable, and not too complicated.

But always requires a human decision.

> I believe some limited form of channel binding can work. Specifically, I am 
> thinking of post facto authentication, e.g. by reading out the fingerprint on 
> the phone.

As I explained before, I don't see why we need to complicate the OE
cases with other cases that can be done perfectly fine with existing
authenticated IPsec. There is no issue setting up two IPsec connections,
one authenticated and one anonymous. Seeing how many prefer 1000's of
narrowed IKEv2 tunnels over a single net-net tunnel, I don't see why
your use case requires complicating the OE case.

> Regarding audit, we can mandate that each record should say something like 
> "Snow White (claimed but unauthenticated identity)".

You are suggesting client side security? I don't understand. If I would
write software where an ID is sent but completely unauthenticated and
falsifiable, I would probably just not log it to avoid confusion.

Paul

From ynir@checkpoint.com  Sun Jan 12 00:37:21 2014
Return-Path: <ynir@checkpoint.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FBC1ADF7C for <ipsec@ietfa.amsl.com>; Sun, 12 Jan 2014 00:37:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.564
X-Spam-Level: 
X-Spam-Status: No, score=-5.564 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_LOLITA1=1.865, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, T_FRT_LOLITA1=0.01] autolearn=ham
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 vgx-rzQQF1MF for <ipsec@ietfa.amsl.com>; Sun, 12 Jan 2014 00:37:20 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6C11ADBCB for <ipsec@ietf.org>; Sun, 12 Jan 2014 00:37:19 -0800 (PST)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s0C7mIb3002629; Sun, 12 Jan 2014 09:48:18 +0200
X-CheckPoint: {52D24351-0-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Sun, 12 Jan 2014 09:48:17 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Paul Wouters <paul@nohats.ca>
Thread-Topic: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
Thread-Index: AQHPD1WgMBmH6ijsZ0mvHXRsiWZ0gpqAlR4A
Date: Sun, 12 Jan 2014 07:48:17 +0000
Message-ID: <DA445B0B-8541-4F30-AF87-3C0718F16FBA@checkpoint.com>
References: <C687BD9EA2204F1087D18646766A3C7B@buildpc> <alpine.LFD.2.10.1312301901450.16515@bofh.nohats.ca> <32DF7E65FBDB480EA7DBBF86CDA59B66@buildpc> <alpine.LFD.2.10.1401111227070.16447@bofh.nohats.ca> <52D18E26.90108@gmail.com> <alpine.LFD.2.10.1401120010450.10993@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1401120010450.10993@bofh.nohats.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.248]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D8668511EDB2814DA708A13F63D23AF2@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jan 2014 08:37:22 -0000

On Jan 12, 2014, at 7:15 AM, Paul Wouters <paul@nohats.ca>
 wrote:
>> Regarding audit, we can mandate that each record should say something li=
ke "Snow White (claimed but unauthenticated identity)".
>=20
> You are suggesting client side security? I don't understand. If I would
> write software where an ID is sent but completely unauthenticated and
> falsifiable, I would probably just not log it to avoid confusion.

IDK. My mail client shows your message as coming from "Paul Wouters <paul@n=
ohats.ca>" even though that is just a text field that you could put anythin=
g in. We always trust claimed identities to a certain extent. The only time=
 we don't is when someone claims an identity that is bound (in our policy) =
to some authorization. So if your machine contacts mine out of the blue and=
 claims to be "Paul's VPN gateway" that's fine and I can log it. If it clai=
ms to be "ili-natasha-gw.checkpoint.com", then I'll need some more proof.

Yoav


From TurnerS@ieca.com  Sun Jan 12 14:44:37 2014
Return-Path: <TurnerS@ieca.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7107D1ACC8B for <ipsec@ietfa.amsl.com>; Sun, 12 Jan 2014 14:44:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level: 
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 RgKMN5JaX4FG for <ipsec@ietfa.amsl.com>; Sun, 12 Jan 2014 14:44:35 -0800 (PST)
Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.80.17]) by ietfa.amsl.com (Postfix) with ESMTP id BF8551A8028 for <ipsec@ietf.org>; Sun, 12 Jan 2014 14:44:35 -0800 (PST)
Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id DD39F6214D62B; Sun, 12 Jan 2014 16:44:24 -0600 (CST)
Received: from ham03.websitewelcome.com (ham.websitewelcome.com [173.192.100.229]) by gateway07.websitewelcome.com (Postfix) with ESMTP id C9B726214D5A5 for <ipsec@ietf.org>; Sun, 12 Jan 2014 16:44:24 -0600 (CST)
Received: by ham03.websitewelcome.com (Postfix, from userid 666) id C7BF548DF80C6; Sun, 12 Jan 2014 16:44:24 -0600 (CST)
X-Spam-Flag2999: NO
X-Spam-Level2999: 
X-Spam-Status2999: "No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.3.1
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by ham03.websitewelcome.com (Postfix) with ESMTP id 9A5DE48DF8028 for <ipsec@ietf.org>; Sun, 12 Jan 2014 16:44:23 -0600 (CST)
Received: from [173.73.130.192] (port=63364 helo=[192.168.1.4]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <TurnerS@ieca.com>) id 1W2TlW-00062y-60; Sun, 12 Jan 2014 16:44:22 -0600
From: Sean Turner <TurnerS@ieca.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_F1C74043-FAE5-4357-B0CD-A0ABB01BBD5C"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: <794F997F-DE48-4D0F-9922-F3F04718B82D@ieca.com>
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Date: Sun, 12 Jan 2014 17:44:18 -0500
References: <20130904182317.4646A8E016@rfc-editor.org> <384EEED2-6652-42BE-9BBE-1723127A7953@checkpoint.com>
To: Yoav Nir <ynir@checkpoint.com>, "<charliek@microsoft.com>" <charliek@microsoft.com>, Paul Hoffman <paul.hoffman@vpnc.org>, Pasi Eronen <pe@iki.fi>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Yaron Sheffer <yaronf.ietf@gmail.com>, "<gsmith@sta.samsung.com>" <gsmith@sta.samsung.com>, "<ipsec@ietf.org>" <ipsec@ietf.org>
In-Reply-To: <384EEED2-6652-42BE-9BBE-1723127A7953@checkpoint.com>
X-Mailer: Apple Mail (2.1827)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator3286.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source-IP: 173.73.130.192
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([192.168.1.4]) [173.73.130.192]:63364
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 31
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Subject: Re: [IPsec] [Technical Errata Reported] RFC5996 (3718)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jan 2014 22:44:37 -0000

--Apple-Mail=_F1C74043-FAE5-4357-B0CD-A0ABB01BBD5C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Unless I hear otherwise, I=92m going to follow Yoav=92s suggestion and =
reject this coming Friday.

spt

On Sep 04, 2013, at 16:08, Yoav Nir <ynir@checkpoint.com> wrote:

> Hi
>=20
> I believe this report should be rejected. The address returned in the =
INTERNAL_IP6_ADDRESS attribute is not a /64 subnet, it is just one =
address. The fact that it belongs to a /64 subnet is besides the point, =
and in fact the TSi payload in both the original and corrected versions =
contains but one address.
>=20
> There is no requirement that TSi and TSr have the same subnet size, =
and in fact the selectors shown in the example are rather common for =
remote access. The client has but one address, while the gateway might =
as well protect the Internet. This kind of universal tunnel is very =
convenient, and even more so when the client does not have prior =
knowledge of the protected domain behind the gateway.
>=20
> Yoav
>=20
> On Sep 4, 2013, at 9:23 PM, RFC Errata System =
<rfc-editor@rfc-editor.org> wrote:
>=20
>> The following errata report has been submitted for RFC5996,
>> "Internet Key Exchange Protocol Version 2 (IKEv2)".
>>=20
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=3D5996&eid=3D3718
>>=20
>> --------------------------------------
>> Type: Technical
>> Reported by: Gerald Smith <gsmith@sta.samsung.com>
>>=20
>> Section: 3.15.3
>>=20
>> Original Text
>> -------------
>> A client can be assigned an IPv6 address using the
>> INTERNAL_IP6_ADDRESS Configuration payload. A minimal exchange might
>> look like this:
>>=20
>> CP(CFG_REQUEST) =3D
>> INTERNAL_IP6_ADDRESS()
>> INTERNAL_IP6_DNS()
>> TSi =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
>> TSr =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
>>=20
>> CP(CFG_REPLY) =3D
>> INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
>> INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
>> TSi =3D (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
>> TSr =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
>>=20
>> Corrected Text
>> --------------
>> CP(CFG_REPLY) =3D
>> INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
>> INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
>> TSi =3D (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
>> TSr =3D (0, 0-65535, 2001:DB8:0:1:: - =
2001:DB8:0:1:FFFF:FFFF:FFFF:FFFF)
>>=20
>> Notes
>> -----
>> The INTERNAL_IP6_ADDRESS returned in the CFG_REPLY is a 64 bit =
subnet, but the TSr returned in the CFG_REPLY shows a 0 bit subnet =
instead of the 64 bit subnet.
>>=20
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary.=20
>>=20
>> --------------------------------------
>> RFC5996 (draft-ietf-ipsecme-ikev2bis-11)
>> --------------------------------------
>> Title               : Internet Key Exchange Protocol Version 2 =
(IKEv2)
>> Publication Date    : September 2010
>> Author(s)           : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen
>> Category            : PROPOSED STANDARD
>> Source              : IP Security Maintenance and Extensions
>> Area                : Security
>> Stream              : IETF
>> Verifying Party     : IESG
>>=20
>> Email secured by Check Point
>=20
>=20


--Apple-Mail=_F1C74043-FAE5-4357-B0CD-A0ABB01BBD5C
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIEgDCCBHww
ggJkoAMCAQICCQCdWMxKNutUeTANBgkqhkiG9w0BAQsFADAiMQswCQYDVQQGEwJVUzETMBEGA1UE
ChMKSUVDQSwgSW5jLjAeFw0xMzA0MDMxNDUxMThaFw0xNDA0MDMxNDUxMThaMDgxCzAJBgNVBAYT
AlVTMRMwEQYDVQQKEwpJRUNBLCBJbmMuMRQwEgYDVQQDEwtTZWFuIFR1cm5lcjCCASIwDQYJKoZI
hvcNAQEBBQADggEPADCCAQoCggEBAOpCGCRptT1m+bIpLTmbahZLZ0Qe4X99f8SgTQ7QISvUfpmn
tfOD1oA1AttXlOULEERYubzvDnUTXvstFomQx0XTA67IaV+mw9ODRtG1hPN/erdKX6sU6rH4tsEb
ba3Drr/I0HT3YVvD3SjWtGXjF12XLvTP6+LfMIIDTCAPiEd9KPG23D7skVu/4BvvmdLFI96OARhg
wQ86M+lTIn83KRJlbbfAeIevbRx/rUB7D+uvMdWxOzR0KZJhd6dEeTXVwBXZG4rnQ4uFM+mRSiD4
rxDCyOuIuOzR07tnOyCRio6sRipOZvwQUWttdsgMEs6IxLdWsaTXcs1HjCsxrdedovMCAwEAAaOB
njCBmzAOBgNVHQ8BAf8EBAMCBeAwHwYDVR0jBBgwFoAUAHRsSeXJUmFxTVY4q2HJ8uHl+w0wGwYD
VR0RBBQwEoEQVHVybmVyU0BpZWNhLmNvbTAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vd3d3Lmll
Y2EuY29tL2NybHMvaWVjYS5jcmwwFwYDVR0gBBAwDjAMBgorBgEEAYHXAAAAMA0GCSqGSIb3DQEB
CwUAA4ICAQAimDYm77ppTi4vK6qJSUhyvCDMGb8mngiEXEYKxsfdHPWoDO7+06j7dAZ8sDD9/FtE
kiUMyoNGSUmKHR+tGperVnNiM/Zk6WwCJv8dYZwhGXNQeEGzeys/UkFv7CFX7uDSn8GQeB8sOAZ1
N1hxV/TvT8qXvcRxP5+aWTAGAq3TKtCQxZjuU74L3st2hZiOhJlhjhqz0K5FIwWzXUK9uwhZe1th
GUpDbRustVgmKN2Xa0pzwqI1VUO0jnWt24A4u59xo6DJQXzQVMhCx0xhpemuT9BrsBDTX8eJdI1i
Wv9wp3ivSrfHjKXp8y8OGD+usiG40HCjj0W9C+dH0VfbgrB6QOI4vA9+kTg4mANth1cxyxwPYOSJ
v0zi1qR0eDIGI//2v2/s6TmGuNqbnRa26Ldv5gGqS7xj32Fiaby6UOXs4+aAIWGZEOH+BXjozcvE
eGBwjU/VRQYu6itR28PaNhNVji4D5ITaGxWWiycqK1EUaFraWHtk7W100ROX69xTeFVZP86D2ymi
/aohl5Vb1vlYHdqlbgqjDRl9dPbTxVCXEHf+jkexcuwlLTvr7F+5DIN6c/EbCpRqQx3edy193L48
OGyRDh1/Wmzpew0VWWAWOSXGl/P9VzXf3Z6GPt7flN/V9iEJAa3Mo+w+eIdzJkHBWR+yJcqQcCRM
MSyishMwLDGCAjgwggI0AgEBMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C
CQCdWMxKNutUeTAJBgUrDgMCGgUAoIHfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI
hvcNAQkFMQ8XDTE0MDExMjIyNDQyMVowIwYJKoZIhvcNAQkEMRYEFG8+SSjhLCvDd9MuO1ZjGfIf
Jcz8MD4GCSsGAQQBgjcQBDExMC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklFQ0EsIEluYy4C
CQCdWMxKNutUeTBABgsqhkiG9w0BCRACCzExoC8wIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCklF
Q0EsIEluYy4CCQCdWMxKNutUeTANBgkqhkiG9w0BAQEFAASCAQB1b2YPufGYX7tGwhga6IRcRxUG
0mNgHjS9fbrAjdf1R1qW+GwAon2dZJKtIMk3r03uyDy8kbjsQTLy3sVnhCpzlpLlIV+QHfPpBswy
0K6OLa6H+8YdVfgKXJFwSLAmxzcZpp9utCcnpk6N+03ZVAcCW2ys6HDTF+gLPiH/bzMO4MFbGbWm
zVpOgDHXRdS0J2IhHbqSacucDYuboQYQpfQWJAIBpyQNkUpxcvRhY2OkNv5eY/UJHx1sXP3nznPb
Fm5b/P1EPJtuRPLNfQbrcQETYlis+KKZ95+MrvkNVNI1etFA/Sxdr7HLD4aM/vjrcYYYTIjJ6p6A
kmQApukDrT4HAAAAAAAA

--Apple-Mail=_F1C74043-FAE5-4357-B0CD-A0ABB01BBD5C--

From svanru@gmail.com  Mon Jan 13 05:57:28 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FA61AE17D for <ipsec@ietfa.amsl.com>; Mon, 13 Jan 2014 05:57:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 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, SPF_PASS=-0.001] autolearn=ham
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 exCaNWxH2YEk for <ipsec@ietfa.amsl.com>; Mon, 13 Jan 2014 05:57:26 -0800 (PST)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4411AE15B for <ipsec@ietf.org>; Mon, 13 Jan 2014 05:57:26 -0800 (PST)
Received: by mail-lb0-f169.google.com with SMTP id q8so2391719lbi.0 for <ipsec@ietf.org>; Mon, 13 Jan 2014 05:57:14 -0800 (PST)
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-type:content-transfer-encoding; bh=x+89simmCIt6BWpy+ASHbcxNsavqgjagjGssi1SYNfU=; b=NqX+N9E4oIvKQO/jT39/Dgxi6Yv1jtH+8rQOUphLZFt/77WHvB3jhOdAm4ApDAfWXI mP4Y9jXaxsXoR1TK+/yo/5tHWc6EogvOFTrUUtuV5SN5QWcq40n2aPZjFpXdUxpW6ndm xL4/dGXv6yCDVqX9tcXyhrSZq/1bWJR+UE4/exWG5lI5+JTbvMtkmmt8qz5WDVoPFKUX qDW/CUX9WWgpt+N1DBcY1ATdBMxnO5gzBzs4K7KxliPZR/3TGxk8fj/IJeVTxyzb9KEw 0ocGVwkhVyJMwmvRYQOoJDPyMYZIWBB23myUR6LT5g4huSKYxL3H1aUEsajcAtvQrplW /CFw==
X-Received: by 10.112.52.6 with SMTP id p6mr725190lbo.67.1389621434393; Mon, 13 Jan 2014 05:57:14 -0800 (PST)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id j6sm6798385lam.6.2014.01.13.05.57.12 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 Jan 2014 05:57:13 -0800 (PST)
Message-ID: <81AFD482C15342A5AB700107D3609101@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Paul Wouters" <paul@nohats.ca>
References: <C687BD9EA2204F1087D18646766A3C7B@buildpc> <alpine.LFD.2.10.1312301901450.16515@bofh.nohats.ca> <32DF7E65FBDB480EA7DBBF86CDA59B66@buildpc> <alpine.LFD.2.10.1401111227070.16447@bofh.nohats.ca>
Date: Mon, 13 Jan 2014 17:57:10 +0400
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
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jan 2014 13:57:28 -0000

>> I think that using NULL Auth method clearly identifies
>> anonymous users and allows to distingush them from regular ones.
>> Adding special "anonymous" ID here seems to be superfluous.
>
> Than you should stick to that and not send any IDs whatsoever.

If we mandate ID to always be empty in case of NULL Auth,
then what to do if you still receive non-empty ID with NULL Auth?
Reject connection attempt or just ignore received ID?
For me the latter looks more appropriate (just follow
Postel's principle - be tolerant to what others do).
And I don't see any harm here if you just ignore received ID.
Act as if you receive no ID at all. You may even not to
log it, if you think it might give user false sense of security.

BTW, we have 3 possibility for inidicating "anonymous" ID.
1. Don't send ID Payload at all.
2. Send empty ID Payload (say, Type = 0, Len=0).
3. Send special ID Payload (say, Type=KeyId, Value="anonymous")

For me, case 3 looks the worst, I'd rather to avoid special values.
Case 1 looks the best from theoretical point of view, but
it will add complexity to already over-complicated IKE_AUTH
state machine (note, that currently ID Payload is mandatory).
For me case 2 looks like acceptible compromise.

What do others think?

>> Why? Transport mode ESP has no issues with NAT, has it?
>
> Yes it does, when multiple clients behind the same NAT router try to
> connect to the same remote IPsec gateway.

Can you, please, elaborate? Where the problem come from?

>> Why should it be mandatory? Why can't it be left to local security 
>> policy?
>
> Because null auth is already weak?

So what? How auth (or the lack of it) is related to PFS?

> Then again, I think PFS should be
> made mandatory for all IPsec connections.

I tend to agree with you in general, but I still think it is a policy issue.

>> So, I think that it is worth to separate NULL Auth from OE stuff
>> and describe all OE related issues in a separate draft, that
>> will use NULL Auth as a mechanism to skip authentication.
>
> Sure, but than I do really want the ID parts not sent for NULL AUTH.

If draft says that in case of NULL Auth ID Payload SHOULD be sent empty
and MUST be ignored by receiver, will it satisfy you?

Regards,
Valery. 


From fdetienn@cisco.com  Mon Jan 13 08:07:56 2014
Return-Path: <fdetienn@cisco.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2581AE184 for <ipsec@ietfa.amsl.com>; Mon, 13 Jan 2014 08:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Level: 
X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 wFfxuxyXCe2R for <ipsec@ietfa.amsl.com>; Mon, 13 Jan 2014 08:07:54 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id C9AD71AE04F for <ipsec@ietf.org>; Mon, 13 Jan 2014 08:07:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1702; q=dns/txt; s=iport; t=1389629264; x=1390838864; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=IynpQlF9fU5liJju0BK/T4Mex7KoplZG/WQYsxn0mrQ=; b=Az7VY6YZZHBaqqCXrLKk3nyTIiScF+CA+74nS3QdIVQ5KSeWhI/2TkAp fFau/PZ8kksSdAVAO/K5UNYZxLq2MK+ZaD++s6sALI/0xgAXL4qxwJEhQ LZTC+P7aMTqweLe58zbg5p46qHkGZv8okRSN9nOFzYO+H7rWv93lyCnLN Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah8FACoO1FKtJXHB/2dsb2JhbABagwuBDqhLkjcWdIIsOlEBPkInBIgXmnOpYxeOMIQCgRMEmBeSFYMtgWlB
X-IronPort-AV: E=Sophos;i="4.95,653,1384300800"; d="scan'208";a="12489488"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-8.cisco.com with ESMTP; 13 Jan 2014 16:07:43 +0000
Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0DG7hrW008655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <ipsec@ietf.org>; Mon, 13 Jan 2014 16:07:43 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.243]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Mon, 13 Jan 2014 10:07:43 -0600
From: "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>
To: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Thread-Topic: clariciations for draft-sathyanarayan-ipsecme-advpn-03
Thread-Index: AQHPEHmWVSfQ3H7ZOEi1TNp+NhtSpw==
Date: Mon, 13 Jan 2014 16:07:10 +0000
Message-ID: <7DC80D6C-3342-43C3-9407-E5D25CB5F5CD@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.60.74.189]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <876BABD1101A6340A075DF52245FCC1A@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jan 2014 16:07:56 -0000

Hi,

In reviewing the discussions over the past few weeks, there appear to be a =
number of issues concerning draft-sathyanarayan-ipsecme-advpn-03 that requi=
re further clarification.

It would be useful for the working group if the following aspects of draft-=
sathyanarayan-ipsecme-advpn-03 were clarified:

 1. scaling & general networking:
  1.1 It does appear this proposal has a limit of 256 networks. Is this cor=
rect ? How do nodes negotiate SA's when there are more than 256 prefixes on=
 each side ? For reference, RFC5996 does not offer the ability to negotiate=
 more than 256 prefixes in the TSi TSr payloads.

  1.2 What happens when a prefix administratively changes from behind one b=
ranch to another ? How do servers get notified about that ?

  1.3 How is VLSM taken into consideration (Variable Length Subnet Masking)=
. E.g. long prefix behind one branch and a short prefix behind another

  1.4 How does a hub decide which Security Association to use when to spoke=
 devices decide to advertise the same prefix ?

 2. multicast:

 2.1 There does not appear to be a specification of Multicast in this propo=
sal. This is a key requirement for some of the ADVPN sponsors. How does mul=
ticast  work ?

 2.2 How are SA's negotiated and how do applications request multicast traf=
fic to be sent ?

 3.interoperability. draft-sathyanarayan-ipsecme-advpn-03 does not mention =
how a server/hub learns about networks behind other servers

 3.1 what are the steps a server should take to establish a network with ot=
her servers

 3.2 how is topology and reachability information exchanged between servers


Thank you,

	Frederic Detienne=

From paul@cypherpunks.ca  Thu Jan 16 18:41:47 2014
Return-Path: <paul@cypherpunks.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44301ADBE8 for <ipsec@ietfa.amsl.com>; Thu, 16 Jan 2014 18:41:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 8XkcugtKtMp2 for <ipsec@ietfa.amsl.com>; Thu, 16 Jan 2014 18:41:45 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 19A341ADBE5 for <ipsec@ietf.org>; Thu, 16 Jan 2014 18:41:44 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AC8E7800A1; Thu, 16 Jan 2014 21:41:31 -0500 (EST)
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s0H2fU2U025700; Thu, 16 Jan 2014 21:41:31 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Thu, 16 Jan 2014 21:41:30 -0500 (EST)
From: Paul Wouters <paul@cypherpunks.ca>
X-X-Sender: paul@bofh.nohats.ca
To: Valery Smyslov <svanru@gmail.com>
In-Reply-To: <81AFD482C15342A5AB700107D3609101@buildpc>
Message-ID: <alpine.LFD.2.10.1401162114390.31096@bofh.nohats.ca>
References: <C687BD9EA2204F1087D18646766A3C7B@buildpc> <alpine.LFD.2.10.1312301901450.16515@bofh.nohats.ca> <32DF7E65FBDB480EA7DBBF86CDA59B66@buildpc> <alpine.LFD.2.10.1401111227070.16447@bofh.nohats.ca> <81AFD482C15342A5AB700107D3609101@buildpc>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2014 02:41:48 -0000

On Mon, 13 Jan 2014, Valery Smyslov wrote:

>>> I think that using NULL Auth method clearly identifies
>>> anonymous users and allows to distingush them from regular ones.
>>> Adding special "anonymous" ID here seems to be superfluous.
>> 
>> Than you should stick to that and not send any IDs whatsoever.
>
> If we mandate ID to always be empty in case of NULL Auth,
> then what to do if you still receive non-empty ID with NULL Auth?
> Reject connection attempt or just ignore received ID?
> For me the latter looks more appropriate (just follow
> Postel's principle - be tolerant to what others do).

Yes, I would ignore it.

> BTW, we have 3 possibility for inidicating "anonymous" ID.
> 1. Don't send ID Payload at all.
> 2. Send empty ID Payload (say, Type = 0, Len=0).
> 3. Send special ID Payload (say, Type=KeyId, Value="anonymous")
>
> For me, case 3 looks the worst, I'd rather to avoid special values.
> Case 1 looks the best from theoretical point of view, but
> it will add complexity to already over-complicated IKE_AUTH
> state machine (note, that currently ID Payload is mandatory).
> For me case 2 looks like acceptible compromise.

I don't think this complicates the state machine that much, as it's
clearly distinct by the auth type none payload. My preference is for #1.

> What do others think?
>
>>> Why? Transport mode ESP has no issues with NAT, has it?
>> 
>> Yes it does, when multiple clients behind the same NAT router try to
>> connect to the same remote IPsec gateway.
>
> Can you, please, elaborate? Where the problem come from?

Multiple clients behind the same NAT router with transport mode would use
different NATed UDP ports. The IPsec server can differentiate incoming
packets this way.  But for outgoing UDP packet streams (not udp replies)
it would need to know which of the clients using the same IP this packet
would need to get encrypted to. You would need some kind of "mark"
asociating the SA with the socket. For *swan we did this with an "SAref"
marker. It would use ip_conntrack and put an SPI based iptables MARK
on the packt. For new connections originating from the IPsec gateway,
you could set a socket option (IP_IPSEC_BINDREF) if you know the SPI/MARK.

>>> Why should it be mandatory? Why can't it be left to local security policy?
>> 
>> Because null auth is already weak?
>
> So what? How auth (or the lack of it) is related to PFS?
>
>> Then again, I think PFS should be
>> made mandatory for all IPsec connections.
>
> I tend to agree with you in general, but I still think it is a policy issue.

Stepping back, I agree that we could leave these things out of the auth
none specification.

>>> So, I think that it is worth to separate NULL Auth from OE stuff
>>> and describe all OE related issues in a separate draft, that
>>> will use NULL Auth as a mechanism to skip authentication.
>> 
>> Sure, but than I do really want the ID parts not sent for NULL AUTH.
>
> If draft says that in case of NULL Auth ID Payload SHOULD be sent empty
> and MUST be ignored by receiver, will it satisfy you?

Yes, that would be perfect.

By the way, I do prefer the name "auth none" over "auth null". To me,
'null' embodies more of an error condition.

Paul

From fdetienn@cisco.com  Fri Jan 17 01:57:54 2014
Return-Path: <fdetienn@cisco.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765D41ADFC0 for <ipsec@ietfa.amsl.com>; Fri, 17 Jan 2014 01:57:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.039
X-Spam-Level: 
X-Spam-Status: No, score=-15.039 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, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 XH5jubSNHQ2A for <ipsec@ietfa.amsl.com>; Fri, 17 Jan 2014 01:57:53 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDD71ADFB6 for <ipsec@ietf.org>; Fri, 17 Jan 2014 01:57:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2350; q=dns/txt; s=iport; t=1389952661; x=1391162261; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8a/rjcKXJ5Cj6kUA0smmcWEuk5qtcAJKSqDxEB2u2F0=; b=TfjHskKeQjLDjoj/u/XI+nQYsL/wvPZ8F30bORHTUWwtY4vR3BagMuZb PTmjyuwr3r/iQwK+irQk0J7rn2JSO60IkXQOmI6jE4a6RE3KsvzBkq/Gt ruT6NLQrQCR1WDafTNcsVfjcIxHTYr+e5JI1R7qdlr9PWMeECV9kLILqn 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjEFAJFf2FKtJXG8/2dsb2JhbABZgws4VqkikW+BDxZ0giUBAQEDAQEBATc0BgoLAgEINhAnCyUCBBOHfAgNxTQTBI4oJDqDJIEUBJghkheDLYFpQQ
X-IronPort-AV: E=Sophos;i="4.95,670,1384300800"; d="scan'208";a="298053226"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 17 Jan 2014 09:57:40 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0H9ve6E004084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <ipsec@ietf.org>; Fri, 17 Jan 2014 09:57:40 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.243]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Fri, 17 Jan 2014 03:57:40 -0600
From: "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>
To: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Thread-Topic: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
Thread-Index: AQHPEHmWVSfQ3H7ZOEi1TNp+NhtSp5qJGL6A
Date: Fri, 17 Jan 2014 09:56:51 +0000
Message-ID: <CDABA9E0-1655-4F48-AF9B-99C15EFB8EF9@cisco.com>
References: <7DC80D6C-3342-43C3-9407-E5D25CB5F5CD@cisco.com>
In-Reply-To: <7DC80D6C-3342-43C3-9407-E5D25CB5F5CD@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.60.74.189]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10BDB0C84F350A439A1C5EA6198244F2@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2014 09:57:54 -0000

Hi,

I would like to re-iterate the importance of clarifying the points below as=
 it is not possible to assess the performances, relevance and interoperabil=
ity of draft-sathyanarayan-ipsecme-advpn-03 at this stage - - these are all=
 important issues to potential users of this techology.

Thank you,

 Frederic Detienne


On 13 Jan 2014, at 17:07, Frederic Detienne (fdetienn) <fdetienn@cisco.com>=
 wrote:

> Hi,
>=20
> In reviewing the discussions over the past few weeks, there appear to be =
a number of issues concerning draft-sathyanarayan-ipsecme-advpn-03 that req=
uire further clarification.
>=20
> It would be useful for the working group if the following aspects of draf=
t-sathyanarayan-ipsecme-advpn-03 were clarified:
>=20
> 1. scaling & general networking:
>  1.1 It does appear this proposal has a limit of 256 networks. Is this co=
rrect ? How do nodes negotiate SA's when there are more than 256 prefixes o=
n each side ? For reference, RFC5996 does not offer the ability to negotiat=
e more than 256 prefixes in the TSi TSr payloads.
>=20
>  1.2 What happens when a prefix administratively changes from behind one =
branch to another ? How do servers get notified about that ?
>=20
>  1.3 How is VLSM taken into consideration (Variable Length Subnet Masking=
). E.g. long prefix behind one branch and a short prefix behind another
>=20
>  1.4 How does a hub decide which Security Association to use when to spok=
e devices decide to advertise the same prefix ?
>=20
> 2. multicast:
>=20
> 2.1 There does not appear to be a specification of Multicast in this prop=
osal. This is a key requirement for some of the ADVPN sponsors. How does mu=
lticast  work ?
>=20
> 2.2 How are SA's negotiated and how do applications request multicast tra=
ffic to be sent ?
>=20
> 3.interoperability. draft-sathyanarayan-ipsecme-advpn-03 does not mention=
 how a server/hub learns about networks behind other servers
>=20
> 3.1 what are the steps a server should take to establish a network with o=
ther servers
>=20
> 3.2 how is topology and reachability information exchanged between server=
s
>=20
>=20
> Thank you,
>=20
> 	Frederic Detienne
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec


From svanru@gmail.com  Fri Jan 17 05:23:58 2014
Return-Path: <svanru@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1701AE0B9 for <ipsec@ietfa.amsl.com>; Fri, 17 Jan 2014 05:23:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 SyqjBr70zG62 for <ipsec@ietfa.amsl.com>; Fri, 17 Jan 2014 05:23:57 -0800 (PST)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id B09041AE0B3 for <ipsec@ietf.org>; Fri, 17 Jan 2014 05:23:56 -0800 (PST)
Received: by mail-la0-f54.google.com with SMTP id y1so3664280lam.27 for <ipsec@ietf.org>; Fri, 17 Jan 2014 05:23:43 -0800 (PST)
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-type:content-transfer-encoding; bh=arUR0/Jgd9aejBwbqxJqQCQDDG7pKR5jAtMyUhwqeY8=; b=brFlcs6rCman8qL2HVHZGC6am1gplaJVTmR3qaPR7bZNvF8GbXAA/34aso61AjVQw4 mSqzYVKn9kzdnq8/iXcVssrWAWBWz0GBkbvYrxIR17AiWYysmklhgdTkew4+9xIQYKMZ PdKVhjYLfeqIbH2K92nVMGFbNPwv7zMne/f2I5pTcH3gPiNvgsFVYYuiPusxgUDXNia7 xzZYyx42YsfKsiI8gL+iNo0He7U1Q/N2QA1j1RjOGaUpyt1Fn9J3IUUhHacKq2foSYta auEm4AGYgde1gspe56hJ8lKTNpVKiXDLbg75fPShgHh2VMn4Rxu5DnlBBme/JYw2bqS9 LKVw==
X-Received: by 10.152.19.170 with SMTP id g10mr1075956lae.9.1389965023390; Fri, 17 Jan 2014 05:23:43 -0800 (PST)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id ox6sm6765044lbb.6.2014.01.17.05.23.39 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 17 Jan 2014 05:23:42 -0800 (PST)
Message-ID: <DE35DE017F47446BBB96382DE2948F74@buildpc>
From: "Valery Smyslov" <svanru@gmail.com>
To: "Paul Wouters" <paul@cypherpunks.ca>
References: <C687BD9EA2204F1087D18646766A3C7B@buildpc> <alpine.LFD.2.10.1312301901450.16515@bofh.nohats.ca> <32DF7E65FBDB480EA7DBBF86CDA59B66@buildpc> <alpine.LFD.2.10.1401111227070.16447@bofh.nohats.ca> <81AFD482C15342A5AB700107D3609101@buildpc> <alpine.LFD.2.10.1401162114390.31096@bofh.nohats.ca>
Date: Fri, 17 Jan 2014 17:23:39 +0400
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
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2014 13:23:58 -0000

>> BTW, we have 3 possibility for inidicating "anonymous" ID.
>> 1. Don't send ID Payload at all.
>> 2. Send empty ID Payload (say, Type = 0, Len=0).
>> 3. Send special ID Payload (say, Type=KeyId, Value="anonymous")
>>
>> For me, case 3 looks the worst, I'd rather to avoid special values.
>> Case 1 looks the best from theoretical point of view, but
>> it will add complexity to already over-complicated IKE_AUTH
>> state machine (note, that currently ID Payload is mandatory).
>> For me case 2 looks like acceptible compromise.
>
> I don't think this complicates the state machine that much, as it's
> clearly distinct by the auth type none payload. My preference is for #1.

Thank you for sharing your opinion. I still think that empty
ID is preferrable, as IMHO it will add less complexity to
implementation. I'd still like to know more opinions on this.

> Multiple clients behind the same NAT router with transport mode would use
> different NATed UDP ports. The IPsec server can differentiate incoming
> packets this way.  But for outgoing UDP packet streams (not udp replies)
> it would need to know which of the clients using the same IP this packet
> would need to get encrypted to. You would need some kind of "mark"
> asociating the SA with the socket. For *swan we did this with an "SAref"
> marker. It would use ip_conntrack and put an SPI based iptables MARK
> on the packt. For new connections originating from the IPsec gateway,
> you could set a socket option (IP_IPSEC_BINDREF) if you know the SPI/MARK.

I got your point. But this problem is unrelated to NULL Auth and even
to OE, IMHO. So I don't think it must be addressed in this draft.

>> If draft says that in case of NULL Auth ID Payload SHOULD be sent empty
>> and MUST be ignored by receiver, will it satisfy you?
>
> Yes, that would be perfect.

Great.

> By the way, I do prefer the name "auth none" over "auth null". To me,
> 'null' embodies more of an error condition.

My reasons for selecting this name were the folowing.
First, we define new Authentication Method in IANA. A method
is some essence, that defines how authentication has to be done.
For me "NONE authentication" implies that this essence doesn't
exist at all, while "NULL authentication" implies that this essence
(authentication) exists, but performs no real action (is dummy).
For me is sounds a bit better, as we define an essence in IANA.
And second, I had a similar example - NULL Encryption Algorithm
in ESP. For some reason it was named NULL, not NONE,
so I just decided to follow this tradition.

Disclaimer: english is not my native language, so my
arguments for the naming may look a bit silly.

> Paul

Regards,
Valery. 


From praveenys@juniper.net  Fri Jan 17 09:01:43 2014
Return-Path: <praveenys@juniper.net>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B121AE125 for <ipsec@ietfa.amsl.com>; Fri, 17 Jan 2014 09:01:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 G4YMUCqgTTEe for <ipsec@ietfa.amsl.com>; Fri, 17 Jan 2014 09:01:41 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id C62D21AE0DA for <ipsec@ietf.org>; Fri, 17 Jan 2014 09:01:40 -0800 (PST)
Received: from mail84-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.22; Fri, 17 Jan 2014 17:01:27 +0000
Received: from mail84-va3 (localhost [127.0.0.1])	by mail84-va3-R.bigfish.com (Postfix) with ESMTP id E89BC26013B; Fri, 17 Jan 2014 17:01:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -24
X-BigFish: VPS-24(zzbb2dI98dI9371I1432Idb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h1155h)
Received-SPF: pass (mail84-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=praveenys@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(679001)(689001)(779001)(51704005)(24454002)(189002)(199002)(377454003)(479174003)(74876001)(87936001)(31966008)(47446002)(76176001)(561944002)(15975445006)(74502001)(85852003)(83506001)(83072002)(81542001)(81342001)(74366001)(80022001)(81686001)(74706001)(77982001)(90146001)(85306002)(76786001)(87266001)(69226001)(4396001)(2656002)(56816005)(65816001)(74662001)(66066001)(47976001)(80976001)(63696002)(83322001)(51856001)(19580395003)(47736001)(54356001)(53806001)(49866001)(79102001)(19580405001)(50986001)(46102001)(93136001)(59766001)(76482001)(56776001)(76796001)(81816001)(54316002)(92566001)(92726001)(36756003)(93516002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB668; H:CO2PR05MB665.namprd05.prod.outlook.com; CLIP:66.129.239.19; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail84-va3 (localhost.localdomain [127.0.0.1]) by mail84-va3 (MessageSwitch) id 1389978084970129_11452; Fri, 17 Jan 2014 17:01:24 +0000 (UTC)
Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.225])	by mail84-va3.bigfish.com (Postfix) with ESMTP id DF0166005D;	Fri, 17 Jan 2014 17:01:24 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 17 Jan 2014 17:01:24 +0000
Received: from CO2PR05MB668.namprd05.prod.outlook.com (10.141.230.25) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 17 Jan 2014 17:01:24 +0000
Received: from CO2PR05MB665.namprd05.prod.outlook.com (10.141.230.11) by CO2PR05MB668.namprd05.prod.outlook.com (10.141.230.25) with Microsoft SMTP Server (TLS) id 15.0.842.7; Fri, 17 Jan 2014 17:01:22 +0000
Received: from CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) by CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) with mapi id 15.00.0851.011; Fri, 17 Jan 2014 17:01:22 +0000
From: Praveen Sathyanarayan <praveenys@juniper.net>
To: "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>, "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Thread-Topic: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
Thread-Index: AQHPEHmWVSfQ3H7ZOEi1TNp+NhtSp5qJGL6A//+Ln4A=
Date: Fri, 17 Jan 2014 17:01:21 +0000
Message-ID: <CEFEA13A.69906%praveenys@juniper.net>
In-Reply-To: <CDABA9E0-1655-4F48-AF9B-99C15EFB8EF9@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.0.121105
x-originating-ip: [66.129.239.19]
x-forefront-prvs: 0094E3478A
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1899104016FD034D96F15E5058FED499@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2014 17:01:43 -0000

Hi Fred,

All of our co-authors are currently busy, as we need to catch up with many
post holidays pending works. We will get back to you soon.

-- Praveen


On 1/17/14 1:56 AM, "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>
wrote:

>Hi,
>
>I would like to re-iterate the importance of clarifying the points below
>as it is not possible to assess the performances, relevance and
>interoperability of draft-sathyanarayan-ipsecme-advpn-03 at this stage -
>- these are all important issues to potential users of this techology.
>
>Thank you,
>
> Frederic Detienne
>
>
>On 13 Jan 2014, at 17:07, Frederic Detienne (fdetienn)
><fdetienn@cisco.com> wrote:
>
>> Hi,
>>=20
>> In reviewing the discussions over the past few weeks, there appear to
>>be a number of issues concerning draft-sathyanarayan-ipsecme-advpn-03
>>that require further clarification.
>>=20
>> It would be useful for the working group if the following aspects of
>>draft-sathyanarayan-ipsecme-advpn-03 were clarified:
>>=20
>> 1. scaling & general networking:
>>  1.1 It does appear this proposal has a limit of 256 networks. Is this
>>correct ? How do nodes negotiate SA's when there are more than 256
>>prefixes on each side ? For reference, RFC5996 does not offer the
>>ability to negotiate more than 256 prefixes in the TSi TSr payloads.
>>=20
>>  1.2 What happens when a prefix administratively changes from behind
>>one branch to another ? How do servers get notified about that ?
>>=20
>>  1.3 How is VLSM taken into consideration (Variable Length Subnet
>>Masking). E.g. long prefix behind one branch and a short prefix behind
>>another
>>=20
>>  1.4 How does a hub decide which Security Association to use when to
>>spoke devices decide to advertise the same prefix ?
>>=20
>> 2. multicast:
>>=20
>> 2.1 There does not appear to be a specification of Multicast in this
>>proposal. This is a key requirement for some of the ADVPN sponsors. How
>>does multicast  work ?
>>=20
>> 2.2 How are SA's negotiated and how do applications request multicast
>>traffic to be sent ?
>>=20
>> 3.interoperability. draft-sathyanarayan-ipsecme-advpn-03 does not
>>mention how a server/hub learns about networks behind other servers
>>=20
>> 3.1 what are the steps a server should take to establish a network with
>>other servers
>>=20
>> 3.2 how is topology and reachability information exchanged between
>>servers
>>=20
>>=20
>> Thank you,
>>=20
>> 	Frederic Detienne
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>
>_______________________________________________
>IPsec mailing list
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec
>
>



From fdetienn@cisco.com  Fri Jan 17 09:06:16 2014
Return-Path: <fdetienn@cisco.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3981AE140 for <ipsec@ietfa.amsl.com>; Fri, 17 Jan 2014 09:06:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.039
X-Spam-Level: 
X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 fvua81gkUjHl for <ipsec@ietfa.amsl.com>; Fri, 17 Jan 2014 09:06:15 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id F14DB1AE0D6 for <ipsec@ietf.org>; Fri, 17 Jan 2014 09:06:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3070; q=dns/txt; s=iport; t=1389978362; x=1391187962; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dVvzZqQ/4hRWg1L58MwVkEZzucOakXUv1Z075Fxcu7g=; b=FkBL4H9NfB8VzoTCCjxJDxRmn71WbhgYQa2xWQKlpzS6A0RVIaECb/er Hkgj5oK3+ZQbbmvFveey4nQIqaPQlMz3I6m06uygyhPjyNyMspTDS7joL HmnssAgM+49i0CrSFkaZ6Bs2ZBjua3jxQPeQO4OxWEZfoYFkxI4BLBDTo 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFACRb2VKtJXG8/2dsb2JhbABZgws4Vq08gQ8WdIIlAQEBAwEBAQE3NAYFBQsCAQgYHhAnCyUCBA4Fh3wIDcN6EwSOKCQzB4MkgRQEmCGSF4MtgWlB
X-IronPort-AV: E=Sophos;i="4.95,675,1384300800"; d="scan'208";a="13664606"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-8.cisco.com with ESMTP; 17 Jan 2014 17:06:02 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0HH62Su007316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Jan 2014 17:06:02 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.243]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Fri, 17 Jan 2014 11:06:02 -0600
From: "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>
To: Praveen Sathyanarayan <praveenys@juniper.net>
Thread-Topic: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
Thread-Index: AQHPEHmWVSfQ3H7ZOEi1TNp+NhtSp5qJGL6A//+Ln4CAAOwOgA==
Date: Fri, 17 Jan 2014 17:05:11 +0000
Message-ID: <F95CC8EF-ED8D-41B0-A5E4-5B5EFF9EE563@cisco.com>
References: <CEFEA13A.69906%praveenys@juniper.net>
In-Reply-To: <CEFEA13A.69906%praveenys@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.60.74.189]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9C02E410B0C0BE40A135440B9B72C1AA@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Subject: Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2014 17:06:17 -0000

Thanks Praveen!

	fred

On 17 Jan 2014, at 18:01, Praveen Sathyanarayan <praveenys@juniper.net>
 wrote:

> Hi Fred,
>=20
> All of our co-authors are currently busy, as we need to catch up with man=
y
> post holidays pending works. We will get back to you soon.
>=20
> -- Praveen
>=20
>=20
> On 1/17/14 1:56 AM, "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>
> wrote:
>=20
>> Hi,
>>=20
>> I would like to re-iterate the importance of clarifying the points below
>> as it is not possible to assess the performances, relevance and
>> interoperability of draft-sathyanarayan-ipsecme-advpn-03 at this stage -
>> - these are all important issues to potential users of this techology.
>>=20
>> Thank you,
>>=20
>> Frederic Detienne
>>=20
>>=20
>> On 13 Jan 2014, at 17:07, Frederic Detienne (fdetienn)
>> <fdetienn@cisco.com> wrote:
>>=20
>>> Hi,
>>>=20
>>> In reviewing the discussions over the past few weeks, there appear to
>>> be a number of issues concerning draft-sathyanarayan-ipsecme-advpn-03
>>> that require further clarification.
>>>=20
>>> It would be useful for the working group if the following aspects of
>>> draft-sathyanarayan-ipsecme-advpn-03 were clarified:
>>>=20
>>> 1. scaling & general networking:
>>> 1.1 It does appear this proposal has a limit of 256 networks. Is this
>>> correct ? How do nodes negotiate SA's when there are more than 256
>>> prefixes on each side ? For reference, RFC5996 does not offer the
>>> ability to negotiate more than 256 prefixes in the TSi TSr payloads.
>>>=20
>>> 1.2 What happens when a prefix administratively changes from behind
>>> one branch to another ? How do servers get notified about that ?
>>>=20
>>> 1.3 How is VLSM taken into consideration (Variable Length Subnet
>>> Masking). E.g. long prefix behind one branch and a short prefix behind
>>> another
>>>=20
>>> 1.4 How does a hub decide which Security Association to use when to
>>> spoke devices decide to advertise the same prefix ?
>>>=20
>>> 2. multicast:
>>>=20
>>> 2.1 There does not appear to be a specification of Multicast in this
>>> proposal. This is a key requirement for some of the ADVPN sponsors. How
>>> does multicast  work ?
>>>=20
>>> 2.2 How are SA's negotiated and how do applications request multicast
>>> traffic to be sent ?
>>>=20
>>> 3.interoperability. draft-sathyanarayan-ipsecme-advpn-03 does not
>>> mention how a server/hub learns about networks behind other servers
>>>=20
>>> 3.1 what are the steps a server should take to establish a network with
>>> other servers
>>>=20
>>> 3.2 how is topology and reachability information exchanged between
>>> servers
>>>=20
>>>=20
>>> Thank you,
>>>=20
>>> 	Frederic Detienne
>>> _______________________________________________
>>> 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
>>=20
>>=20
>=20
>=20


From paul@cypherpunks.ca  Fri Jan 17 16:40:14 2014
Return-Path: <paul@cypherpunks.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EC51ACCDF for <ipsec@ietfa.amsl.com>; Fri, 17 Jan 2014 16:40:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 tv0FZb1y6B4M for <ipsec@ietfa.amsl.com>; Fri, 17 Jan 2014 16:40:12 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA141AC4C1 for <ipsec@ietf.org>; Fri, 17 Jan 2014 16:40:12 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6C31D800A1; Fri, 17 Jan 2014 19:39:58 -0500 (EST)
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s0I0dvmW014344; Fri, 17 Jan 2014 19:39:58 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Fri, 17 Jan 2014 19:39:57 -0500 (EST)
From: Paul Wouters <paul@cypherpunks.ca>
X-X-Sender: paul@bofh.nohats.ca
To: Valery Smyslov <svanru@gmail.com>
In-Reply-To: <DE35DE017F47446BBB96382DE2948F74@buildpc>
Message-ID: <alpine.LFD.2.10.1401171937110.20749@bofh.nohats.ca>
References: <C687BD9EA2204F1087D18646766A3C7B@buildpc> <alpine.LFD.2.10.1312301901450.16515@bofh.nohats.ca> <32DF7E65FBDB480EA7DBBF86CDA59B66@buildpc> <alpine.LFD.2.10.1401111227070.16447@bofh.nohats.ca> <81AFD482C15342A5AB700107D3609101@buildpc> <alpine.LFD.2.10.1401162114390.31096@bofh.nohats.ca> <DE35DE017F47446BBB96382DE2948F74@buildpc>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>
Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jan 2014 00:40:15 -0000

On Fri, 17 Jan 2014, Valery Smyslov wrote:

>> I don't think this complicates the state machine that much, as it's
>> clearly distinct by the auth type none payload. My preference is for #1.
>
> Thank you for sharing your opinion. I still think that empty
> ID is preferrable, as IMHO it will add less complexity to
> implementation. I'd still like to know more opinions on this.

Sure. Let's hear from others.

> I got your point. But this problem is unrelated to NULL Auth and even
> to OE, IMHO. So I don't think it must be addressed in this draft.

Agreed.

>> By the way, I do prefer the name "auth none" over "auth null". To me,
>> 'null' embodies more of an error condition.
>
> My reasons for selecting this name were the folowing.
> First, we define new Authentication Method in IANA. A method
> is some essence, that defines how authentication has to be done.
> For me "NONE authentication" implies that this essence doesn't
> exist at all, while "NULL authentication" implies that this essence
> (authentication) exists, but performs no real action (is dummy).
> For me is sounds a bit better, as we define an essence in IANA.
> And second, I had a similar example - NULL Encryption Algorithm
> in ESP. For some reason it was named NULL, not NONE,
> so I just decided to follow this tradition.

I figured that was the reason. Although I think in the ESP case
there is an NO-OP encryption with the name NULL. Here I think
we have "no authentication", not an "authentication with null"

> Disclaimer: english is not my native language, so my
> arguments for the naming may look a bit silly.

The same disclaimer applies to me. So I would also like to hear
from others on this issue. Regardless, it is not a big deal for
me.

Paul

From praveenys@juniper.net  Mon Jan 20 10:15:18 2014
Return-Path: <praveenys@juniper.net>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4841C1A01C1 for <ipsec@ietfa.amsl.com>; Mon, 20 Jan 2014 10:15:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level: 
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 wFaWtAmtcU-Y for <ipsec@ietfa.amsl.com>; Mon, 20 Jan 2014 10:15:14 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4292C1A0169 for <ipsec@ietf.org>; Mon, 20 Jan 2014 10:15:14 -0800 (PST)
Received: from mail105-co9-R.bigfish.com (10.236.132.232) by CO9EHSOBE030.bigfish.com (10.236.130.93) with Microsoft SMTP Server id 14.1.225.22; Mon, 20 Jan 2014 18:15:14 +0000
Received: from mail105-co9 (localhost [127.0.0.1])	by mail105-co9-R.bigfish.com (Postfix) with ESMTP id 3CE07440157;	Mon, 20 Jan 2014 18:15:14 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -28
X-BigFish: VPS-28(zzbb2dI98dI9371Ic85eh148cI1a09J4015I1447Idb82hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh20f0h2216h22d0h2336h2438h2461h2487h1155h)
Received-SPF: pass (mail105-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=praveenys@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(189002)(199002)(51914003)(24454002)(164054003)(66654002)(52604005)(377454003)(479174003)(15975445006)(83506001)(561944002)(81686001)(81816001)(74876001)(74706001)(19580395003)(83322001)(19580405001)(85852003)(83072002)(63696002)(80976001)(90146001)(56816005)(85306002)(80022001)(87266001)(87936001)(2656002)(65816001)(66066001)(76786001)(76796001)(47446002)(74502001)(31966008)(74662001)(36756003)(74366001)(76176001)(92566001)(92726001)(93136001)(93516002)(86362001)(15202345003)(50986001)(47976001)(47736001)(49866001)(4396001)(59766001)(77982001)(76482001)(54356001)(69226001)(54316002)(79102001)(51856001)(53806001)(16236675002)(81342001)(81542001)(46102001)(56776001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB666; H:CO2PR05MB665.namprd05.prod.outlook.com; CLIP:66.129.239.12; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail105-co9 (localhost.localdomain [127.0.0.1]) by mail105-co9 (MessageSwitch) id 1390241703569476_32544; Mon, 20 Jan 2014 18:15:03 +0000 (UTC)
Received: from CO9EHSMHS012.bigfish.com (unknown [10.236.132.230])	by mail105-co9.bigfish.com (Postfix) with ESMTP id 85BA0700041; Mon, 20 Jan 2014 18:15:03 +0000 (UTC)
Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS012.bigfish.com (10.236.130.22) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 20 Jan 2014 18:15:03 +0000
Received: from CO2PR05MB666.namprd05.prod.outlook.com (10.141.230.19) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.395.1; Mon, 20 Jan 2014 18:15:01 +0000
Received: from CO2PR05MB665.namprd05.prod.outlook.com (10.141.230.11) by CO2PR05MB666.namprd05.prod.outlook.com (10.141.230.19) with Microsoft SMTP Server (TLS) id 15.0.851.15; Mon, 20 Jan 2014 18:15:00 +0000
Received: from CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) by CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) with mapi id 15.00.0851.011; Mon, 20 Jan 2014 18:14:59 +0000
From: Praveen Sathyanarayan <praveenys@juniper.net>
To: "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>, "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Thread-Topic: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
Thread-Index: AQHPEHmWVSfQ3H7ZOEi1TNp+NhtSp5qNb/iA
Date: Mon, 20 Jan 2014 18:14:58 +0000
Message-ID: <CF02A72F.6A65A%praveenys@juniper.net>
In-Reply-To: <7DC80D6C-3342-43C3-9407-E5D25CB5F5CD@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.0.121105
x-originating-ip: [66.129.239.12]
x-forefront-prvs: 00979FCB3A
Content-Type: multipart/alternative; boundary="_000_CF02A72F6A65Apraveenysjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jan 2014 18:15:18 -0000

--_000_CF02A72F6A65Apraveenysjunipernet_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Fred,



Many thanks for the good comments. We're happy to clarify the fine details =
and nuances in our proposal further. As you could imagine, there are two wa=
ys that one can deploy ADVPN, as described in our draft. First, you can use=
 the IPSec rules as defined on a per system/zone/virtual-system basis. Alte=
rnatively, one can bind the negotiated traffic-selectors during the negotia=
tion (i.e. bind them to a virtual tunnel interface; in vendor-speak, I gues=
s Cisco calls this a VTI interface, while Juniper refers to it as st0 inter=
face). In general we consider this primarily an implementation decision. Th=
at is, different vendors may opt for either way, depending on what said ven=
dor wants to bring into production. Both approaches are viable in the field=
 and have their respective advantages. For example, if a tunnel-interface b=
ased approach is adopted, this allows us to run standard routing protocols =
to manage a large network, or achieve load-balancing in ECMP-based next hop=
s. If someone choose rule based approach, they get better granularity and b=
etter security management.



The take-home message here is that our draft (draft-sathyanarayan-ipsecme-a=
dvpn) is flexible enough to allow any vendor (commercial, open-source, and =
even academic) to go for whichever approach they prefer to implement accord=
ing to their own considerations. With respect to commercially-oriented vend=
ors, in particular, we expect that they can easily adopt our draft to provi=
de an open solution without compromising their business goals. (This may no=
t be the case for the other two drafts, but never mind for now).



We would like to highlight once again that our draft does _not_ require the=
 use of another tunneling mechanism just for establishing a shortcut tunnel=
 between two endpoints. That is, one can simply extend their existing IPsec=
 implementation to support shortcuts.



Please see inline below for further answers and comments to your questions.



Thanks,

Praveen





On 1/13/14, 8:07 AM, "Frederic Detienne (fdetienn)" <fdetienn@cisco.com<mai=
lto:fdetienn@cisco.com>>

wrote:



Hi,



In reviewing the discussions over the past few weeks, there appear to be a

number of issues concerning draft-sathyanarayan-ipsecme-advpn-03 that

require further clarification.



It would be useful for the working group if the following aspects of

draft-sathyanarayan-ipsecme-advpn-03 were clarified:



1. scaling & general networking:

  1.1 It does appear this proposal has a limit of 256 networks. Is this

correct ? How do nodes negotiate SA's when there are more than 256

prefixes on each side ? For reference, RFC5996 does not offer the ability

to negotiate more than 256 prefixes in the TSi TSr payloads.



[PRAVEEN] The value you mention (256) is on a per shortcut tunnel basis. No=
thing prevents you from having multiple shortcuts between the same shortcut=
 partners. If a tunnel-interface approach is chosen, a routing protocol can=
 be employed to manage, say, a large network. Based on the authors=92 own i=
mplementation experience of IKE (i.e. without the ADVPN implementation in),=
 you can always negotiate a single range (read: single subnet without narro=
wing). In other words, setting up an IPsec tunnel that is not tied to a VTI=
 is pretty cheap and simple. It's just one round-trip in IKEv2 and, by defa=
ult, involves no "heavy" crypto - just an encrypted CCSA packet and a KDF.





  1.2 What happens when a prefix administratively changes from behind one

branch to another ? How do servers get notified about that ?



[PRAVEEN] That=92s an interesting point Fred, and thanks for bringing it up=
. First, please refer the ADVPN_INFO Payload and PROTECTED_DOMAIN sections =
(3.6 and 3.9, respectively) of http://tools.ietf.org/html/draft-sathyanaray=
an-ipsecme-advpn-03. As a general rule, each spoke can download updated PRO=
TECTED_DOMAIN information periodically, which advertises everything behind =
the hub and all other spokes combined. Of course, this does not change if s=
ome subnet has moved from behind spoke A to behind another spoke, B. Howeve=
r, the Lifetime attribute of the ADVPN_INFO payload is key here. We could s=
ee this being employed in a straightforward manner to allow for this transi=
tion: a) the subnet can "disappear" and be unreachable for one Lifetime, or=
 b) the original spoke can redirect to the new spoke.



We don't think this matters much in the real world, because people don't ju=
st move entire subnets instantaneously. Typically, folks stop using a subne=
t in one place, then begin using it in another. This makes a lot of sense f=
or several operational reasons, as you would imagine. In fact, experience s=
hows that since routing doesn't update across the world immediately, best p=
ractice would, for instance, indicate that it=92s best to wait a day betwee=
n stopping using the subnet in one place and starting to use it in another =
place. In this case, a Lifetime of one day or less should be just fine (and=
 we=92re thinking that, in fact, an hour would be a reasonable Lifetime val=
ue in practice).



We would indeed argue that using Lifetime allows us to make the basic imple=
mentation of ADVPN handle a transition from one administrative domain to an=
other in a straightforward manner. A redirection based on RFC5685 re-uses a=
n already defined mechanism and makes the transition immediate, if/when nec=
essary. This is one more argument for draft-sathyanarayan-ipsecme-advpn as =
it illustrates the modularity of our ADVPN proposal _and_ keeps the impleme=
ntation simple.





  1.3 How is VLSM taken into consideration (Variable Length Subnet

Masking). E.g. long prefix behind one branch and a short prefix behind

another



[PRAVEEN] Traffic-selector payloads are specified through address ranges. A=
s such, shortcut tunnels can be established with _finer granularity than wi=
th VLSM_. Of course, on balance, this may mean that you can have weird sele=
ctors (for example, 192.168.0.0-192.168.36.255 and 192.168.38.0-192.168.255=
.255). Overall, we consider this yet another +1 for our proposal.





  1.4 How does a hub decide which Security Association to use when to

spoke devices decide to advertise the same prefix ?



[PRAVEEN] I guess you refer to error-handling, right? Because we see this a=
s an erroneous configuration; please let us know if this is not the case (a=
nd why would that be so in a typical deployment; we=92re looking forward to=
 it).



In general, we assume that the hub has correct configuration or that, at th=
e very minimum, the implementation would reject configuration changes that =
lead to an inconsistent state (and if that is the case, promptly alert the =
administrator about it). But to your question: Since it is hub, it must hav=
e SPD entries for its corresponding spokes. According to the SPD entries, t=
he hub will choose which tunnel to use for forwarding the traffic. Please s=
ee Section 5 (http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-=
03#section-5), which details how SPD entries are modified when a shortcut t=
unnel is established. In a nutshell, a dynamic shortcut SPD entry is added =
on top of an administratively configured static entry. We believe that, for=
 all practical purposes, this is more than =93good enough=94. Of course, if=
 routing protocols have a better solution to the problem you bring up, we=
=92re all ears.





2. multicast:



2.1 There does not appear to be a specification of Multicast in this

proposal. This is a key requirement for some of the ADVPN sponsors. How

does multicast  work ?



[PRAVEEN] The traffic-selector payload does not make any assumptions about =
the type of prefixes that can be exchanged during the negotiation; multicas=
t prefixes can be exchanged. If a virtual interface approach is adopted, th=
e administrator can also use multicast routing protocols like PIM to discov=
er source and best paths.





2.2 How are SA's negotiated and how do applications request multicast

traffic to be sent ?



[PRAVEEN] As mentioned above, one can configure and negotiate multicast gro=
ups. I believe, #2.1 already answers your question. However, we do not see =
multicast used with spokes: mutlicast IP is tunneled as regular IP. Maybe w=
e didn=92t get the scenario well understood though. Would you mind elaborat=
ing the scenario you have in mind wrt multicast?



3.interoperability. draft-sathyanarayan-ipsecme-advpn-03 does not mention

how a server/hub learns about networks behind other servers



3.1 what are the steps a server should take to establish a network with

other servers



[PRAVEEN] Would you please clarify the problem by providing some details he=
re? What specific issues did you identify? May be you should refer to Appen=
dix A, B and C of our draft. They may answer your question.



3.2 how is topology and reachability information exchanged between servers



[PRAVEEN] Please refer to Appendix C (http://tools.ietf.org/html/draft-sath=
yanarayan-ipsecme-advpn-03#appendix-C), which illustrates PROTECTED-DOMAIN =
can be used.



--_000_CF02A72F6A65Apraveenysjunipernet_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <088124BD4E949445976F4CD336AE60FA@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; font-family: Calibri, sans-serif; font-size: 14=
px; color: rgb(0, 0, 0); ">
<div>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">Hi Fred,<o:p></o:p><=
/span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">Many thanks for the =
good comments. We're happy to clarify the fine details and nuances in our p=
roposal further. As you could imagine, there are two ways that one can depl=
oy ADVPN, as described in our draft.
 First, you can use the IPSec rules as defined on a per system/zone/virtual=
-system basis. Alternatively, one can bind the negotiated traffic-selectors=
 during the negotiation (i.e. bind them to a virtual tunnel interface; in v=
endor-speak, I guess Cisco calls
 this a VTI interface, while Juniper refers to it as st0 interface). In gen=
eral we consider this primarily an implementation decision. That is, differ=
ent vendors may opt for either way, depending on what said vendor wants to =
bring into production. Both approaches
 are viable in the field and have their respective advantages. For example,=
 if a tunnel-interface based approach is adopted, this allows us to run sta=
ndard routing protocols to manage a large network, or achieve load-balancin=
g in ECMP-based next hops. If someone
 choose rule based approach, they get better granularity and better securit=
y management.<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">The take-home messag=
e here is that our draft (draft-sathyanarayan-ipsecme-advpn) is flexible en=
ough to allow any vendor (commercial, open-source, and even academic) to go=
 for whichever approach they prefer
 to implement according to their own considerations. With respect to commer=
cially-oriented vendors, in particular, we expect that they can easily adop=
t our draft to provide an open solution without compromising their business=
 goals. (This may not be the case
 for the other two drafts, but never mind for now).<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">We would like to hig=
hlight once again that our draft does _not_ require the use of another tunn=
eling mechanism just for establishing a shortcut tunnel between two endpoin=
ts. That is, one can simply extend their
 existing IPsec implementation to support shortcuts.<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">Please see inline be=
low for further answers and comments to your questions.<o:p></o:p></span></=
p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">Thanks,<o:p></o:p></=
span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">Praveen<o:p></o:p></=
span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">On 1/13/14, 8:07 AM, &quot;Frederic Detienne (fdetienn=
)&quot; &lt;<a href=3D"mailto:fdetienn@cisco.com" style=3D"color: purple; "=
>fdetienn@cisco.com</a>&gt;<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">wrote:<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">Hi,<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">In reviewing the discussions over the past few weeks, =
there appear to be a<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">number of issues concerning draft-sathyanarayan-ipsecm=
e-advpn-03 that<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">require further clarification.<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">It would be useful for the working group if the follow=
ing aspects of<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">draft-sathyanarayan-ipsecme-advpn-03 were clarified:<o=
:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">1. scaling &amp; general networking:<o:p></o:p></span>=
</p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;&nbsp;1.1 It does appear this proposal has a lim=
it of 256 networks. Is this<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">correct ? How do nodes negotiate SA's when there are m=
ore than 256<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">prefixes on each side ? For reference, RFC5996 does no=
t offer the ability<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">to negotiate more than 256 prefixes in the TSi TSr pay=
loads.<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">[PRAVEEN] The value =
you mention (256) is on a per shortcut tunnel basis. Nothing prevents you f=
rom having multiple shortcuts between the same shortcut partners. If a tunn=
el-interface approach is chosen, a routing
 protocol can be employed to manage, say, a large network. Based on the aut=
hors=92 own implementation experience of IKE (i.e. without the ADVPN implem=
entation in), you can always negotiate a single range (read: single subnet =
without narrowing). In other words,
 setting up an IPsec tunnel that is not tied to a VTI is pretty cheap and s=
imple. It's just one round-trip in IKEv2 and, by default, involves no &quot=
;heavy&quot; crypto - just an encrypted CCSA packet and a KDF.<o:p></o:p></=
span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;&nbsp;1.2 What happens when a prefix administrat=
ively changes from behind one<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">branch to another ? How do servers get notified about =
that ?<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">[PRAVEEN] That=92s a=
n interesting point Fred, and thanks for bringing it up. First, please refe=
r the ADVPN_INFO Payload and PROTECTED_DOMAIN sections (3.6 and 3.9, respec=
tively) of&nbsp;<a href=3D"http://tools.ietf.org/html/draft-sathyanarayan-i=
psecme-advpn-03" style=3D"color: purple; ">http://tools.ietf.org/html/draft=
-sathyanarayan-ipsecme-advpn-03</a>.
 As a general rule, each spoke can download updated PROTECTED_DOMAIN inform=
ation periodically, which advertises everything behind the hub and all othe=
r spokes combined. Of course, this does not change if some subnet has moved=
 from behind spoke A to behind another
 spoke, B. However, the Lifetime attribute of the ADVPN_INFO payload is key=
 here. We could see this being employed in a straightforward manner to allo=
w for this transition: a) the subnet can &quot;disappear&quot; and be unrea=
chable for one Lifetime, or b) the original
 spoke can redirect to the new spoke.<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">We don't think this =
matters much in the real world, because people don't just move entire subne=
ts instantaneously. Typically, folks stop using a subnet in one place, then=
 begin using it in another. This makes
 a lot of sense for several operational reasons, as you would imagine. In f=
act, experience shows that since routing doesn't update across the world im=
mediately, best practice would, for instance, indicate that it=92s best to =
wait a day between stopping using
 the subnet in one place and starting to use it in another place. In this c=
ase, a Lifetime of one day or less should be just fine (and we=92re thinkin=
g that, in fact, an hour would be a reasonable Lifetime value in practice).=
&nbsp;<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">We would indeed argu=
e that using Lifetime allows us to make the basic implementation of ADVPN h=
andle a transition from one administrative domain to another in a straightf=
orward manner. A redirection based on
 RFC5685 re-uses an already defined mechanism and makes the transition imme=
diate, if/when necessary. This is one more argument for draft-sathyanarayan=
-ipsecme-advpn as it illustrates the modularity of our ADVPN proposal _and_=
 keeps the implementation simple.<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;&nbsp;1.3 How is VLSM taken into consideration (=
Variable Length Subnet<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">Masking). E.g. long prefix behind one branch and a sho=
rt prefix behind<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">another<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">[PRAVEEN] Traffic-se=
lector payloads are specified through address ranges. As such, shortcut tun=
nels can be established with _finer granularity than with VLSM_. Of course,=
 on balance, this may mean that you
 can have weird selectors (for example, 192.168.0.0-192.168.36.255 and 192.=
168.38.0-192.168.255.255). Overall, we consider this yet another &#43;1 for=
 our proposal.<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;&nbsp;1.4 How does a hub decide which Security A=
ssociation to use when to<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">spoke devices decide to advertise the same prefix ?<o:=
p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">[PRAVEEN] I guess yo=
u refer to error-handling, right? Because we see this as an erroneous confi=
guration; please let us know if this is not the case (and why would that be=
 so in a typical deployment; we=92re looking
 forward to it).<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">In general, we assum=
e that the hub has correct configuration or that, at the very minimum, the =
implementation would reject configuration changes that lead to an inconsist=
ent state (and if that is the case,
 promptly alert the administrator about it). But to your question: Since it=
 is hub, it must have SPD entries for its corresponding spokes. According t=
o the SPD entries, the hub will choose which tunnel to use for forwarding t=
he traffic. Please see Section 5
 (<a href=3D"http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-0=
3#section-5" style=3D"color: purple; "><span style=3D"color: rgb(0, 32, 96)=
; ">http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03#section=
-5</span></a>), which details how SPD
 entries are modified when a shortcut tunnel is established. In a nutshell,=
 a dynamic shortcut SPD entry is added on top of an administratively config=
ured static entry. We believe that, for all practical purposes, this is mor=
e than =93good enough=94. Of course,
 if routing protocols have a better solution to the problem you bring up, w=
e=92re all ears.<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">2. multicast:<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">2.1 There does not appear to be a specification of Mul=
ticast in this<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">proposal. This is a key requirement for some of the AD=
VPN sponsors. How<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">does multicast&nbsp;&nbsp;work ?<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">[PRAVEEN] The traffi=
c-selector payload does not make any assumptions about the type of prefixes=
 that can be exchanged during the negotiation; multicast prefixes can be ex=
changed. If a virtual interface approach
 is adopted, the administrator can also use multicast routing protocols lik=
e PIM to discover source and best paths.<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">2.2 How are SA's negotiated and how do applications re=
quest multicast<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">traffic to be sent ?<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">[PRAVEEN] As mention=
ed above, one can configure and negotiate multicast groups. I believe, #2.1=
 already answers your question. However, we do not see multicast used with =
spokes: mutlicast IP is tunneled as
 regular&nbsp;IP. Maybe we didn=92t get the scenario well understood though=
. Would you mind elaborating the scenario you have in mind wrt multicast?<o=
:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">3.interoperability. draft-sathyanarayan-ipsecme-advpn-=
03 does not mention<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">how a server/hub learns about networks behind other se=
rvers<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">3.1 what are the steps a server should take to establi=
sh a network with<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">other servers<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">[PRAVEEN] Would you =
please clarify the problem by providing some details here? What specific is=
sues did you identify? May be you should refer to Appendix A, B and C of ou=
r draft. They may answer your question.<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">3.2 how is topology and reachability information excha=
nged between servers<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US" style=3D"color: rgb(0, 32, 96); ">[PRAVEEN] Please ref=
er to Appendix C (<a href=3D"http://tools.ietf.org/html/draft-sathyanarayan=
-ipsecme-advpn-03#appendix-C" style=3D"color: purple; "><span style=3D"colo=
r: rgb(0, 32, 96); ">http://tools.ietf.org/html/draft-sathyanarayan-ipsecme=
-advpn-03#appendix-C</span></a>),
 which illustrates PROTECTED-DOMAIN can be used.<o:p></o:p></span></p>
<p class=3D"MsoPlainText" style=3D"margin: 0cm 0cm 0.0001pt; font-family: C=
onsolas; ">
<span lang=3D"EN-US">&nbsp;</span></p>
</div>
</body>
</html>

--_000_CF02A72F6A65Apraveenysjunipernet_--

From fdetienn@cisco.com  Tue Jan 21 00:52:57 2014
Return-Path: <fdetienn@cisco.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C191A0091 for <ipsec@ietfa.amsl.com>; Tue, 21 Jan 2014 00:52:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level: 
X-Spam-Status: No, score=-15.036 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 TcK4NmT-B1Qh for <ipsec@ietfa.amsl.com>; Tue, 21 Jan 2014 00:52:55 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C2CA21A006B for <ipsec@ietf.org>; Tue, 21 Jan 2014 00:52:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9902; q=dns/txt; s=iport; t=1390294375; x=1391503975; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iaUZq4+Ka3KBx8u/I+hGlcVC4/QyDU2Nnf8itDODi/c=; b=TD+6Z/EJ1F0HN4Se8e2MWm+bygXOjI3s7FwFjMHD6WwDl2503VBz3djB qdjNnA14QUL2fdDSuYBog77smG4BiHc+zpSNXPcOFym/CfsBhFJw91O6r NWUhNp0YBJEl+Xy/llvsdwGdgDn4zYcwH0vTuWiPRLagn0WoTDHpb2Mvy c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag4FALI03lKtJV2b/2dsb2JhbABPCoMLOFa7XYEPFnSCJQEBAQMBDlcMCAULAgEIGC4yJQIEDgUbh2IIDcN3F44jBSQzB4MkgRQEmCKBMpBmgy2BaUE
X-IronPort-AV: E=Sophos;i="4.95,695,1384300800"; d="scan'208";a="298630255"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 21 Jan 2014 08:52:53 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s0L8qrqK002173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jan 2014 08:52:53 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.243]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 02:52:52 -0600
From: "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>
To: Praveen Sathyanarayan <praveenys@juniper.net>
Thread-Topic: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
Thread-Index: AQHPEHmWVSfQ3H7ZOEi1TNp+NhtSp5qNb/iAgAHgAAA=
Date: Tue, 21 Jan 2014 08:52:46 +0000
Message-ID: <09AF395E-A0B5-4839-BEC9-B4E02C042132@cisco.com>
References: <CF02A72F.6A65A%praveenys@juniper.net>
In-Reply-To: <CF02A72F.6A65A%praveenys@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.60.74.189]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <05AC3AB2A61FD548981CEEDF2ABA0208@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Subject: Re: [IPsec] clariciations for draft-sathyanarayan-ipsecme-advpn-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 08:52:57 -0000

Hi Praveen,

thanks for taking the time to respond. I have read the ADVPN proposal with =
attention and these points need a much deeper dive as I do not think the sp=
ecification is so straightforward.

I will split the Q&A's for easier follow up as the thread will be very quic=
kly unreadable.

regards,

	fred

On 20 Jan 2014, at 19:14, Praveen Sathyanarayan <praveenys@juniper.net> wro=
te:

> Hi Fred,
> =20
> Many thanks for the good comments. We're happy to clarify the fine detail=
s and nuances in our proposal further. As you could imagine, there are two =
ways that one can deploy ADVPN, as described in our draft. First, you can u=
se the IPSec rules as defined on a per system/zone/virtual-system basis. Al=
ternatively, one can bind the negotiated traffic-selectors during the negot=
iation (i.e. bind them to a virtual tunnel interface; in vendor-speak, I gu=
ess Cisco calls this a VTI interface, while Juniper refers to it as st0 int=
erface). In general we consider this primarily an implementation decision. =
That is, different vendors may opt for either way, depending on what said v=
endor wants to bring into production. Both approaches are viable in the fie=
ld and have their respective advantages. For example, if a tunnel-interface=
 based approach is adopted, this allows us to run standard routing protocol=
s to manage a large network, or achieve load-balancing in ECMP-based next h=
ops. If someone choose rule based approach, they get better granularity and=
 better security management.
> =20
> The take-home message here is that our draft (draft-sathyanarayan-ipsecme=
-advpn) is flexible enough to allow any vendor (commercial, open-source, an=
d even academic) to go for whichever approach they prefer to implement acco=
rding to their own considerations. With respect to commercially-oriented ve=
ndors, in particular, we expect that they can easily adopt our draft to pro=
vide an open solution without compromising their business goals. (This may =
not be the case for the other two drafts, but never mind for now).
> =20
> We would like to highlight once again that our draft does _not_ require t=
he use of another tunneling mechanism just for establishing a shortcut tunn=
el between two endpoints. That is, one can simply extend their existing IPs=
ec implementation to support shortcuts.
> =20
> Please see inline below for further answers and comments to your question=
s.
> =20
> Thanks,
> Praveen
> =20
> =20
> On 1/13/14, 8:07 AM, "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>
> wrote:
> =20
> Hi,
> =20
> In reviewing the discussions over the past few weeks, there appear to be =
a
> number of issues concerning draft-sathyanarayan-ipsecme-advpn-03 that
> require further clarification.
> =20
> It would be useful for the working group if the following aspects of
> draft-sathyanarayan-ipsecme-advpn-03 were clarified:
> =20
> 1. scaling & general networking:
>   1.1 It does appear this proposal has a limit of 256 networks. Is this
> correct ? How do nodes negotiate SA's when there are more than 256
> prefixes on each side ? For reference, RFC5996 does not offer the ability
> to negotiate more than 256 prefixes in the TSi TSr payloads.
> =20
> [PRAVEEN] The value you mention (256) is on a per shortcut tunnel basis. =
Nothing prevents you from having multiple shortcuts between the same shortc=
ut partners. If a tunnel-interface approach is chosen, a routing protocol c=
an be employed to manage, say, a large network. Based on the authors=92 own=
 implementation experience of IKE (i.e. without the ADVPN implementation in=
), you can always negotiate a single range (read: single subnet without nar=
rowing). In other words, setting up an IPsec tunnel that is not tied to a V=
TI is pretty cheap and simple. It's just one round-trip in IKEv2 and, by de=
fault, involves no "heavy" crypto - just an encrypted CCSA packet and a KDF=
.
> =20
> =20
>   1.2 What happens when a prefix administratively changes from behind one
> branch to another ? How do servers get notified about that ?
> =20
> [PRAVEEN] That=92s an interesting point Fred, and thanks for bringing it =
up. First, please refer the ADVPN_INFO Payload and PROTECTED_DOMAIN section=
s (3.6 and 3.9, respectively) of http://tools.ietf.org/html/draft-sathyanar=
ayan-ipsecme-advpn-03. As a general rule, each spoke can download updated P=
ROTECTED_DOMAIN information periodically, which advertises everything behin=
d the hub and all other spokes combined. Of course, this does not change if=
 some subnet has moved from behind spoke A to behind another spoke, B. Howe=
ver, the Lifetime attribute of the ADVPN_INFO payload is key here. We could=
 see this being employed in a straightforward manner to allow for this tran=
sition: a) the subnet can "disappear" and be unreachable for one Lifetime, =
or b) the original spoke can redirect to the new spoke.
> =20
> We don't think this matters much in the real world, because people don't =
just move entire subnets instantaneously. Typically, folks stop using a sub=
net in one place, then begin using it in another. This makes a lot of sense=
 for several operational reasons, as you would imagine. In fact, experience=
 shows that since routing doesn't update across the world immediately, best=
 practice would, for instance, indicate that it=92s best to wait a day betw=
een stopping using the subnet in one place and starting to use it in anothe=
r place. In this case, a Lifetime of one day or less should be just fine (a=
nd we=92re thinking that, in fact, an hour would be a reasonable Lifetime v=
alue in practice).=20
> =20
> We would indeed argue that using Lifetime allows us to make the basic imp=
lementation of ADVPN handle a transition from one administrative domain to =
another in a straightforward manner. A redirection based on RFC5685 re-uses=
 an already defined mechanism and makes the transition immediate, if/when n=
ecessary. This is one more argument for draft-sathyanarayan-ipsecme-advpn a=
s it illustrates the modularity of our ADVPN proposal _and_ keeps the imple=
mentation simple.
> =20
> =20
>   1.3 How is VLSM taken into consideration (Variable Length Subnet
> Masking). E.g. long prefix behind one branch and a short prefix behind
> another
> =20
> [PRAVEEN] Traffic-selector payloads are specified through address ranges.=
 As such, shortcut tunnels can be established with _finer granularity than =
with VLSM_. Of course, on balance, this may mean that you can have weird se=
lectors (for example, 192.168.0.0-192.168.36.255 and 192.168.38.0-192.168.2=
55.255). Overall, we consider this yet another +1 for our proposal.
> =20
> =20
>   1.4 How does a hub decide which Security Association to use when to
> spoke devices decide to advertise the same prefix ?
> =20
> [PRAVEEN] I guess you refer to error-handling, right? Because we see this=
 as an erroneous configuration; please let us know if this is not the case =
(and why would that be so in a typical deployment; we=92re looking forward =
to it).
> =20
> In general, we assume that the hub has correct configuration or that, at =
the very minimum, the implementation would reject configuration changes tha=
t lead to an inconsistent state (and if that is the case, promptly alert th=
e administrator about it). But to your question: Since it is hub, it must h=
ave SPD entries for its corresponding spokes. According to the SPD entries,=
 the hub will choose which tunnel to use for forwarding the traffic. Please=
 see Section 5 (http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advp=
n-03#section-5), which details how SPD entries are modified when a shortcut=
 tunnel is established. In a nutshell, a dynamic shortcut SPD entry is adde=
d on top of an administratively configured static entry. We believe that, f=
or all practical purposes, this is more than =93good enough=94. Of course, =
if routing protocols have a better solution to the problem you bring up, we=
=92re all ears.
> =20
> =20
> 2. multicast:
> =20
> 2.1 There does not appear to be a specification of Multicast in this
> proposal. This is a key requirement for some of the ADVPN sponsors. How
> does multicast  work ?
> =20
> [PRAVEEN] The traffic-selector payload does not make any assumptions abou=
t the type of prefixes that can be exchanged during the negotiation; multic=
ast prefixes can be exchanged. If a virtual interface approach is adopted, =
the administrator can also use multicast routing protocols like PIM to disc=
over source and best paths.
> =20
> =20
> 2.2 How are SA's negotiated and how do applications request multicast
> traffic to be sent ?
> =20
> [PRAVEEN] As mentioned above, one can configure and negotiate multicast g=
roups. I believe, #2.1 already answers your question. However, we do not se=
e multicast used with spokes: mutlicast IP is tunneled as regular IP. Maybe=
 we didn=92t get the scenario well understood though. Would you mind elabor=
ating the scenario you have in mind wrt multicast?
> =20
> 3.interoperability. draft-sathyanarayan-ipsecme-advpn-03 does not mention
> how a server/hub learns about networks behind other servers
> =20
> 3.1 what are the steps a server should take to establish a network with
> other servers
> =20
> [PRAVEEN] Would you please clarify the problem by providing some details =
here? What specific issues did you identify? May be you should refer to App=
endix A, B and C of our draft. They may answer your question.
> =20
> 3.2 how is topology and reachability information exchanged between server=
s
> =20
> [PRAVEEN] Please refer to Appendix C (http://tools.ietf.org/html/draft-sa=
thyanarayan-ipsecme-advpn-03#appendix-C), which illustrates PROTECTED-DOMAI=
N can be used.
> =20


From ynir@checkpoint.com  Tue Jan 21 08:45:20 2014
Return-Path: <ynir@checkpoint.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F6F1A016D for <ipsec@ietfa.amsl.com>; Tue, 21 Jan 2014 08:45:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.436
X-Spam-Level: 
X-Spam-Status: No, score=-7.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham
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 Ze4MRuuNCejJ for <ipsec@ietfa.amsl.com>; Tue, 21 Jan 2014 08:45:15 -0800 (PST)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0974F1A0140 for <ipsec@ietf.org>; Tue, 21 Jan 2014 08:45:14 -0800 (PST)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id s0LGiwLg024544 for <ipsec@ietf.org>; Tue, 21 Jan 2014 18:44:58 +0200
X-CheckPoint: {52DE9E0A-1B-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.110]) by IL-EX10.ad.checkpoint.com ([169.254.2.228]) with mapi id 14.03.0123.003; Tue, 21 Jan 2014 18:44:58 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Thread-Topic: I-D Action: draft-nir-ipsecme-chacha20-poly1305-00.txt
Thread-Index: AQHPFrJPTpgOBqdLeUmh+xi6Ptj44w==
Date: Tue, 21 Jan 2014 16:44:58 +0000
Message-ID: <66DC0FA6-3AA6-4BE3-B521-FDE61D81E7D3@checkpoint.com>
References: <20140121140832.15163.31178.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.2]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <94DA958D12A5DF4B94654FF3705ECE0A@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [IPsec] Fwd: I-D Action: draft-nir-ipsecme-chacha20-poly1305-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 16:45:20 -0000

Hi,

Continuing the conversation about "spare algorithms" in case cryptanalytica=
l results are found against AES, I've submitted this document, modeled roug=
hly around AGL's document for TLS with the same algorithms.

Reviews and comments would be greatly appreciated, as well as anyone checki=
ng my examples.

Thanks

Yoav

Begin forwarded message:

> From: <internet-drafts@ietf.org>
> Subject: I-D Action: draft-nir-ipsecme-chacha20-poly1305-00.txt
> Date: January 21, 2014 4:08:32 PM GMT+02:00
> To: <i-d-announce@ietf.org>
> Reply-To: <internet-drafts@ietf.org>
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
>=20
>=20
>        Title           : ChaCha20 and Poly1305 and their use in IPsec
>        Author          : Yoav Nir
> 	Filename        : draft-nir-ipsecme-chacha20-poly1305-00.txt
> 	Pages           : 16
> 	Date            : 2014-01-21
>=20
> Abstract:
>   This document describes the use of the ChaCha20 stream cipher in
>   IPsec, as well as the use of the Poly1305 authenticator, both as
>   stand-alone algorithms, and as a combined mode AEAD algorithm.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-nir-ipsecme-chacha20-poly1305/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-00
>=20
>=20
> Please note that it may take a couple of minutes from the time of submiss=
ion
> 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/


From yaronf.ietf@gmail.com  Tue Jan 21 09:24:21 2014
Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9A5D1A0426 for <ipsec@ietfa.amsl.com>; Tue, 21 Jan 2014 09:24:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 AHjLEnaocGTo for <ipsec@ietfa.amsl.com>; Tue, 21 Jan 2014 09:24:19 -0800 (PST)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 66BB01A042B for <ipsec@ietf.org>; Tue, 21 Jan 2014 09:24:18 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id hr1so4693159wib.8 for <ipsec@ietf.org>; Tue, 21 Jan 2014 09:24:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=40GOOrKFbdm7zXG+IJrjyx3hSsSUmbzO5LcTyqxOX5Y=; b=gjpivGiUDKVILe2rfB9kGLXZW2myrKBLzdH40pIEXuqcX//kA6HqFKncpcKLYxx6il +TwAO72vRTHbufLU3kxNKLBIwY+IIkdbNeu/BTCLdZmAsUGmYEQ6z7WzfRFF9JItLfY+ B+DwLIqVtSxqbYk6EwKR+y5umv5qXtXPZpltYPa14nRRv6tCKGNug8HofT4abv6BoCEH CFY7lM9Dpelth6KoJJ2YRZIG0/hyTqHVTnv1AtezgHQlXeApUGnuIUr1qQ8Ph0kbKPtA 1UtajU5Jzy9Jrd13UrGLmiQk7vFWP2M+u0Mp4Vb576MFzC4h0LPFR08ePu4ncSS0yvEE zV0g==
X-Received: by 10.194.241.228 with SMTP id wl4mr20422431wjc.2.1390325057748; Tue, 21 Jan 2014 09:24:17 -0800 (PST)
Received: from [10.0.0.6] ([109.65.96.42]) by mx.google.com with ESMTPSA id ot9sm8987240wjc.0.2014.01.21.09.24.16 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 21 Jan 2014 09:24:17 -0800 (PST)
Message-ID: <52DEAD3F.5000507@gmail.com>
Date: Tue, 21 Jan 2014 19:24:15 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>,  "<ipsec@ietf.org> WG" <ipsec@ietf.org>
References: <20140121140832.15163.31178.idtracker@ietfa.amsl.com> <66DC0FA6-3AA6-4BE3-B521-FDE61D81E7D3@checkpoint.com>
In-Reply-To: <66DC0FA6-3AA6-4BE3-B521-FDE61D81E7D3@checkpoint.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [IPsec] Fwd: I-D Action: draft-nir-ipsecme-chacha20-poly1305-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 17:24:22 -0000

Hi Yoav,

Thank you for submitting this draft. I am all in favor of having a 
credible "standby algorithm", and I'm hearing that ChaCha20 is a worthy 
candidate.

What worries me in the current instance is that the definition of the 
algorithm is fluffy. This could be old-fashioned of me, but I think an 
SDO should produce standards, i.e. written documents that allow a 
developer to implement an algorithm without having to resort to reverse 
engineering of libraries. (I do applaud the test vectors though).

I would recommend that you (or someone) publish a CFRG document that we 
can use as a normative reference here. With respect, none of the DJB 
documents cited here (and note that the references themselves are kinda 
incomplete) reads as a formal definition of the algorithm.

Thanks,
	Yaron

On 01/21/2014 06:44 PM, Yoav Nir wrote:
> Hi,
>
> Continuing the conversation about "spare algorithms" in case cryptanalytical results are found against AES, I've submitted this document, modeled roughly around AGL's document for TLS with the same algorithms.
>
> Reviews and comments would be greatly appreciated, as well as anyone checking my examples.
>
> Thanks
>
> Yoav
>
> Begin forwarded message:
>
>> From: <internet-drafts@ietf.org>
>> Subject: I-D Action: draft-nir-ipsecme-chacha20-poly1305-00.txt
>> Date: January 21, 2014 4:08:32 PM GMT+02:00
>> To: <i-d-announce@ietf.org>
>> Reply-To: <internet-drafts@ietf.org>
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>
>>         Title           : ChaCha20 and Poly1305 and their use in IPsec
>>         Author          : Yoav Nir
>> 	Filename        : draft-nir-ipsecme-chacha20-poly1305-00.txt
>> 	Pages           : 16
>> 	Date            : 2014-01-21
>>
>> Abstract:
>>    This document describes the use of the ChaCha20 stream cipher in
>>    IPsec, as well as the use of the Poly1305 authenticator, both as
>>    stand-alone algorithms, and as a combined mode AEAD algorithm.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-nir-ipsecme-chacha20-poly1305/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-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/
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

From fdetienn@cisco.com  Thu Jan 23 07:32:40 2014
Return-Path: <fdetienn@cisco.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7C41A0037 for <ipsec@ietfa.amsl.com>; Thu, 23 Jan 2014 07:32:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level: 
X-Spam-Status: No, score=-15.036 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, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 gHn402nRlsSm for <ipsec@ietfa.amsl.com>; Thu, 23 Jan 2014 07:32:38 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D576B1A0036 for <ipsec@ietf.org>; Thu, 23 Jan 2014 07:32:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1249; q=dns/txt; s=iport; t=1390491158; x=1391700758; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AWcsvf20GcMJ9aSin3QJjiJDyJXZknoTMljnv65zOgY=; b=PzzfmQY4vqluEfNToj1hqEN0+9XKcIi5g67F5whULi3RcvExAMqc0+on W+lx9mKzbo6jOtJT4MApiewyanBECkiW51aGA0MYu4pyZv6GHFrnidbq3 ET7jqJMA2wUMebR6gNznCdF+jgJyWBt9QRwBh8+xkWi949/Zc6B5F8ocM Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgsFAA414VKtJXHB/2dsb2JhbABbgww4VrtzgRAWdIIlAQEBAwF5EAIBTjIlAgQOiAIIDcVjF48AB4MkgRQEmCOBMpBmgy2CKg
X-IronPort-AV: E=Sophos;i="4.95,706,1384300800"; d="scan'208";a="299228545"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 23 Jan 2014 15:32:38 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s0NFWba8011181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jan 2014 15:32:37 GMT
Received: from xmb-aln-x06.cisco.com ([169.254.1.243]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 23 Jan 2014 09:32:37 -0600
From: "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>
To: Praveen Sathyanarayan <praveenys@juniper.net>
Thread-Topic: Moving prefixes --  clariciations for draft-sathyanarayan-ipsecme-advpn-03
Thread-Index: AQHPGFBYhUfNVOEedUmNXuQwCZtSsQ==
Date: Thu, 23 Jan 2014 15:32:20 +0000
Message-ID: <88259CEC-4D10-48EC-8A21-0D2F348EEE3F@cisco.com>
References: <CF02A72F.6A65A%praveenys@juniper.net>
In-Reply-To: <CF02A72F.6A65A%praveenys@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.60.74.189]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <AD6FF8EA73964141900C164E3812378E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Subject: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 15:32:41 -0000

>=20
>   1.2 What happens when a prefix administratively changes from behind one
> branch to another ? How do servers get notified about that ?
> =20
> [PRAVEEN] That=92s an interesting point Fred, and thanks for bringing it =
up. First, please refer the ADVPN_INFO Payload and PROTECTED_DOMAIN section=
s (3.6 and 3.9, respectively) of http://tools.ietf.org/html/draft-sathyanar=
ayan-ipsecme-advpn-03. As a general rule, each spoke can download updated P=
ROTECTED_DOMAIN information periodically, which advertises everything behin=
d the hub and all other spokes combined. Of course, this does not change if=
 some subnet has moved from behind spoke A to behind another spoke, B. Howe=
ver, the Lifetime attribute of the ADVPN_INFO payload is key here. We could=
 see this being employed in a straightforward manner to allow for this tran=
sition: a) the subnet can "disappear" and be unreachable for one Lifetime, =
or b) the original spoke can redirect to the new spoke.

It turns out I did read those sections and this is exactly what surprised m=
e. Your answer is even more surprising.

Before going any further, is this resource exclusively exchanged between hu=
b & spoke or also between spokes ?

thanks,

	fred=

From praveenys@juniper.net  Mon Jan 27 09:13:59 2014
Return-Path: <praveenys@juniper.net>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2AB1A0387 for <ipsec@ietfa.amsl.com>; Mon, 27 Jan 2014 09:13:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 W74uZiWZp16J for <ipsec@ietfa.amsl.com>; Mon, 27 Jan 2014 09:13:56 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7457E1A0384 for <ipsec@ietf.org>; Mon, 27 Jan 2014 09:13:56 -0800 (PST)
Received: from mail109-co9-R.bigfish.com (10.236.132.236) by CO9EHSOBE033.bigfish.com (10.236.130.96) with Microsoft SMTP Server id 14.1.225.22; Mon, 27 Jan 2014 17:13:54 +0000
Received: from mail109-co9 (localhost [127.0.0.1])	by mail109-co9-R.bigfish.com (Postfix) with ESMTP id 2043B401D7;	Mon, 27 Jan 2014 17:13:54 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -26
X-BigFish: VPS-26(z579ehzbb2dI98dI9371I148cI1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h1155h)
Received-SPF: pass (mail109-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=praveenys@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; 
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(199002)(189002)(52604005)(51704005)(479174003)(24454002)(377454003)(69226001)(2656002)(81542001)(74876001)(74706001)(81342001)(87936001)(92726001)(54316002)(56776001)(92566001)(59766001)(77982001)(76176001)(63696002)(51856001)(79102001)(36756003)(4396001)(80976001)(76796001)(81686001)(19580395003)(90146001)(56816005)(19580405001)(83322001)(47736001)(93516002)(76482001)(54356001)(50986001)(76786001)(47976001)(49866001)(53806001)(86362001)(85306002)(47446002)(94316002)(74502001)(87266001)(83072002)(85852003)(65816001)(74366001)(31966008)(83506001)(93136001)(81816001)(46102001)(66066001)(74662001)(80022001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB665; H:CO2PR05MB665.namprd05.prod.outlook.com; CLIP:66.129.239.14; FPR:; InfoNoRecordsA:1; MX:1; LANG:en; 
Received: from mail109-co9 (localhost.localdomain [127.0.0.1]) by mail109-co9 (MessageSwitch) id 1390842832110879_29486; Mon, 27 Jan 2014 17:13:52 +0000 (UTC)
Received: from CO9EHSMHS005.bigfish.com (unknown [10.236.132.237])	by mail109-co9.bigfish.com (Postfix) with ESMTP id 1690E36004A; Mon, 27 Jan 2014 17:13:52 +0000 (UTC)
Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS005.bigfish.com (10.236.130.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 27 Jan 2014 17:13:51 +0000
Received: from CO2PR05MB665.namprd05.prod.outlook.com (10.141.230.11) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.395.1; Mon, 27 Jan 2014 17:13:47 +0000
Received: from CO2PR05MB665.namprd05.prod.outlook.com (10.141.230.11) by CO2PR05MB665.namprd05.prod.outlook.com (10.141.230.11) with Microsoft SMTP Server (TLS) id 15.0.859.15; Mon, 27 Jan 2014 17:13:45 +0000
Received: from CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) by CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) with mapi id 15.00.0859.020; Mon, 27 Jan 2014 17:13:45 +0000
From: Praveen Sathyanarayan <praveenys@juniper.net>
To: "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>
Thread-Topic: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03
Thread-Index: AQHPGFBmIvsjxkaNukGJzmUJkO7gl5qYT5OA
Date: Mon, 27 Jan 2014 17:13:44 +0000
Message-ID: <CF0BCF53.6AC0F%praveenys@juniper.net>
In-Reply-To: <88259CEC-4D10-48EC-8A21-0D2F348EEE3F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.0.121105
x-originating-ip: [66.129.239.14]
x-forefront-prvs: 0104247462
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <1D9C71ECAC51A246BF02E1C5854594B3@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "<ipsec@ietf.org> WG" <ipsec@ietf.org>
Subject: Re: [IPsec] Moving prefixes -- clariciations for draft-sathyanarayan-ipsecme-advpn-03
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jan 2014 17:13:59 -0000

Hi Fred,

Comments inline.

Thanks,
Praveen

On 1/23/14 7:32 AM, "Frederic Detienne (fdetienn)" <fdetienn@cisco.com>
wrote:

>>=20
>>   1.2 What happens when a prefix administratively changes from behind
>>one
>> branch to another ? How do servers get notified about that ?
>> =20
>> [PRAVEEN] That=B9s an interesting point Fred, and thanks for bringing it
>>up. First, please refer the ADVPN_INFO Payload and PROTECTED_DOMAIN
>>sections (3.6 and 3.9, respectively) of
>>http://tools.ietf.org/html/draft-sathyanarayan-ipsecme-advpn-03. As a
>>general rule, each spoke can download updated PROTECTED_DOMAIN
>>information periodically, which advertises everything behind the hub and
>>all other spokes combined. Of course, this does not change if some
>>subnet has moved from behind spoke A to behind another spoke, B.
>>However, the Lifetime attribute of the ADVPN_INFO payload is key here.
>>We could see this being employed in a straightforward manner to allow
>>for this transition: a) the subnet can "disappear" and be unreachable
>>for one Lifetime, or b) the original spoke can redirect to the new spoke.
>
>It turns out I did read those sections and this is exactly what surprised
>me. Your answer is even more surprising.


[PRAVEEN] For one-liner question, we could only imagine the scenario that
you are trying to solve. And this is what we could come up. May be you can
provide more detailed question on what scenario you would like to solve.
We could help in answering those scenarios.

When admin changes the prefix of a spoke, spoke=B9s existing static tunnel
with Hub, gets re-negotatiaged for updated prefix in Tsi/TSr payload. This
event updates the Hub about changed prefix information. Is that what you
wanted to know?=20

>
>Before going any further, is this resource exclusively exchanged between
>hub & spoke or also between spokes ?


[PRAVEEN] =B3resource=B2 you means ADVPN_INFO payload or Subnet information=
?
ADVPN_INFO exchanged between spokes. Subnet information exchanged part of
Tsi and TSr during IKE negotiation (which means between hub & spoke and
between spokes as well).

>
>thanks,
>
>	fred
>_______________________________________________
>IPsec mailing list
>IPsec@ietf.org
>https://www.ietf.org/mailman/listinfo/ipsec
>
>



From georgehanes@hushmail.com  Thu Jan 30 14:08:04 2014
Return-Path: <georgehanes@hushmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558371A04DA for <ipsec@ietfa.amsl.com>; Thu, 30 Jan 2014 14:08:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.323
X-Spam-Level: 
X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_HELO_NEUTRAL=0.112, SPF_PASS=-0.001] autolearn=ham
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 v-xaCn0jdl3o for <ipsec@ietfa.amsl.com>; Thu, 30 Jan 2014 14:08:02 -0800 (PST)
Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id BA14B1A04DB for <ipsec@ietf.org>; Thu, 30 Jan 2014 14:08:02 -0800 (PST)
Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id 8413BA0337 for <ipsec@ietf.org>; Thu, 30 Jan 2014 22:07:59 +0000 (UTC)
Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp2.hushmail.com (Postfix) with ESMTP for <ipsec@ietf.org>; Thu, 30 Jan 2014 22:07:59 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id 5390A601CB; Thu, 30 Jan 2014 22:07:59 +0000 (UTC)
MIME-Version: 1.0
Date: Thu, 30 Jan 2014 17:07:59 -0500
To: ipsec@ietf.org
From: georgehanes@hushmail.com
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20140130220759.5390A601CB@smtp.hushmail.com>
Subject: [IPsec] Be cautious of this computer science conference
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 22:08:29 -0000

Be cautious of this computer science conference

If you have any thought of attending the world’s biggest 
f-a-k-e conference in computer science 
http://www.world-academy-of-science.org  you should visit 
any websites below

https://sites.google.com/site/worlddump1 
or
https://sites.google.com/site/dumpconf 
https://sites.google.com/site/moneycomp1
https://sites.google.com/site/worlddump4

The organizer of this conference is H-amid A-rabnia  
http://www.cs.uga.edu/~hra  a professor from University 
of Georgia, Athens, US.  He already earned millions of 
dollars from the registration fee. He recently started 
a new conference CSCI due to his hunger for money 
http://www.americancse.org 

He did not reveal the reviews and reviewers' information 
for all the papers he received, despite repeated requests 
and challenges. The reason for his failure is there are 
no reviews and reviewers and he just cheated the research 
community for more than a decade by announcing that each 
draft paper is reviewed by two experts. We challenge him 
to publish these details at the conference website. 
Where are your experts? Where are your reviews? 

Soon he comes up with a story announcing that he lost all 
the information having reviews and reviewers because of 
computer crash or theft.

DBLP stopped indexing these conferences since 2011 and 
displayed an explicit message; 
"The DBLP Advisory Board decided to discontinue indexing 
of this conference series". Visit 
http://www.informatik.uni-trier.de/~ley/db/conf/biocomp/index.html 
as a sample.

He was forced to remove his name, the university of Georgia 
name, and university of Georgia email address from the 
conference’s contact page because the University has 
banned him from doing that. Do not spoil your resume by 
publishing in this conference.

Apologies for posting to multiple mailing lists. Spreading 
the news is the only way to stop this conference from 
harming innocent researchers.

Respectfully,

Many researchers cheated by these conferences


From mglt.ietf@gmail.com  Fri Jan 31 06:48:19 2014
Return-Path: <mglt.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE8E1A0064; Fri, 31 Jan 2014 06:48:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 Y0v27GMR_laG; Fri, 31 Jan 2014 06:48:17 -0800 (PST)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id AAC9B1A020C; Fri, 31 Jan 2014 06:48:16 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id l18so9102324wgh.5 for <multiple recipients>; Fri, 31 Jan 2014 06:48:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=e5av1DSGZsFTk/UHfhKFrgPp27dwhqpN7flBjKw4LIs=; b=QzSkaI15ZZY6yYJ1jVyM9KXLhUV2V6V92SHHVhn/ltw8I9xIXhdg5LNL0YS4189TGO BdAz06f+NK/B1/rm/NCYTWX4SP0sHd6Z5U8i6tpJvDYwlcMRAFO0rF/R5d8Csjfns0Bv fjKWBydcI9rzUPQY46cCxnobJWnhGR4GuEb2MG/KqkDr8HVYLJ7TLmyOEiga6Dqh6ldK ttgea4XAesJrZu/BjusovxxHP5nSrtQC6yNxZzKjEoWHcsDjC7WLgApXuPK8dRT/yzvw ARj1IdJ/P4TfNHCUAOtJczcK/tpDgiEegecKnmSPYZc1yB/Cqyzgbdot7HCS66GtKaGq bJsQ==
MIME-Version: 1.0
X-Received: by 10.180.94.67 with SMTP id da3mr14287274wib.38.1391179692606; Fri, 31 Jan 2014 06:48:12 -0800 (PST)
Received: by 10.194.171.129 with HTTP; Fri, 31 Jan 2014 06:48:12 -0800 (PST)
Date: Fri, 31 Jan 2014 15:48:12 +0100
Message-ID: <CADZyTk=GRC4kN5mXobgzeZJ+k44dxZHLaW49z8dFkjt0N=C5aw@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
To: "ipsec@ietf.org" <ipsec@ietf.org>, dtls-iot@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [IPsec] IPsec/Diet-ESP for IoT and Minimal ESP
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 14:48:19 -0000

Hi,

Please find the two drafts we have just posted. They are about
IPsec/ESP minimal implementation and Diet-ESP designed for IoT.

Comment are welcome!

Best Regards,
Daniel


Name:        draft-mglt-dice-diet-esp
Revision:    00
Title:        Diet-ESP: a flexible and compressed format for IPsec/ESP
Document date:    2014-01-31
Group:        Individual Submission
Pages:        21
URL:http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt
Status:https://datatracker.ietf.org/doc/draft-mglt-dice-diet-esp/
Htmlized:http://tools.ietf.org/html/draft-mglt-dice-diet-esp-00


Abstract:
   IPsec/ESP has been designed to secure IP packets exchanged between
   two nodes.  IPsec implements security at the IP layer which makes
   security transparent to the applications, as opposed to TLS or DTLS
   that requires application to implement TLS/DTLS.  As a result, IPsec
   enable to define the security rules in a similar way one establishes
   firewall rules.

   One of the IPsec's drawbacks is that implementing security on a per
   packet basis adds overhead to each IP packet.  Considering IoT
   devices, the data transmitted over an IP packet is expected to be
   rather small, and the cost of sending extra bytes is so high that
   IPsec/ESP can hardly be used for IoT as it is currently defined in
   RFC 4303.

   This document defines Diet-ESP, a protocol that compress and reduce
   the ESP overhead of IPsec/ESP so that it can fit security and energy
   efficient IoT requirements.  Diet-ESP use already existing mechanism
   like IKEv2 to negotiate the compression format.  Furthermore a lot of
   information, already existing for an IPsec Security Association, are
   reused to offer light negotiation in addition to maximum compression.


Name:        draft-mglt-lwig-minimal-esp
Revision:    00
Title:        Minimal ESP
Document date:    2014-01-31
Group:        Individual Submission
Pages:        6
URL:http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-00.txt
Status:https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/
Htmlized:http://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-00


Abstract:
   This document describes a minimal version of the IP Encapsulation
   Security Payload (ESP) described in RFC 4303 which is part of the
   IPsec suite.

   ESP is used to provide confidentiality, data origin authentication,
   connectionless integrity, an anti-replay service (a form of partial
   sequence integrity), and limited traffic flow confidentiality.

   This document does not update or modify RFC 4303, but provides a
   compact description of the minimal version of the protocol.  If this
   document and RFC 4303 conflicts then RFC 4303 is the authoritative
   description.


-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58