Thanks Valery,
We are negotiating experimental keep-alive methods and a protected address must
be exchanged between the peers. This is why we wish to cover the exchange.
We will go with a simple protected Notify in the Status Type range.
Thanks again and best regards,
Fred
> On 20 May 2015
ticated. So depending on how sensitive the content of the parameters
> is, you might not want to send it at that point. The IKE SA at that point
> protects against passive eavesdropping and message modification only.
>
> Yoav
>
>> On May 20, 2015, at 3:13 PM, Frederic Detie
Hello,
we would like to implement new vendor specific capabilities under IKEv2. This
capability requires argument passing. These arguments should be protected
(encrypted and signed).
We were wondering what was the cleanest way to do this.
What seemed the most logical is
1- negotiating capabil
Answer: yes, should pursue
Transport mode is an important use case.
I concur with Joe Touch’s arguments on Tunnel Mode. There are much more
powerful overlay methods than IPsec Tunnel mode yet IPsec/IKE security is the
best in its class. In this area, transport mode and is needed.
For native a
gt; Airdrop. To do these, expecting mobile devices to run BGP protocol, to
> discover a direct tunnel is not a reasonable expectation. Or for that
> matter expecting a firewall device to run routing protocol, is not a
> reasonable expectation either.
>
> More comments inline.
>
&
> On 03 Feb 2014, at 16:02, "Michael Richardson" wrote:
>
>
> Harms, Patrick wrote:
>> - is allowing to add 'spokes' without configuration changes on the 'hub'
>> devices (8.1 dmvpn draft)
>
>> For me, this is an important point. Changing the configuration on the hub
>> routers, everytime a
Hi Praveen,
Comments inline.
Thanks,
Fred
(sent from mobile)
>
> [PRAVEEN] I think you didn’t get my answer. What I was trying to say is,
> if there is a network prefix change on the spoke side, Spoke renegotiates
> with Hub (Child SA rekey has TSi and Tsr payload to convey about the
> add
On 03 Feb 2014, at 16:28, Yoav Nir wrote:
> […]
> The missing piece here is the propagation of the union protected domain
> information among all the 1st tier nodes. This is fairly simple in a single
> enterprise network where such nodes are managed centrally. I can also see how
> in more het
Hi Praveen,
Sorry about the delay. I am just back from our EMEA company event and have been
a lot busier than I planned.
> [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 detaile
>
> 1.2 What happens when a prefix administratively changes from behind one
> branch to another ? How do servers get notified about that ?
>
> [PRAVEEN] That’s an interesting point Fred, and thanks for bringing it up.
> First, please refer the ADVPN_INFO Payload and PROTECTED_DOMAIN sections
> 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)"
> wrote:
>
> Hi,
>
> In revie
n-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)
>> wrote:
>&g
you,
Frederic Detienne
On 13 Jan 2014, at 17:07, Frederic Detienne (fdetienn)
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.
&
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 cla
On 08 Dec 2013, at 22:07, Michael Richardson
wrote:
>
> Frederic Detienne (fdetienn) wrote:
>>> On 08 Dec 2013, at 12:08, "Michael Richardson"
>>> wrote:
>>>
>>>
>>> Frederic Detienne (fdetienn) wrote:
>>>>> On
> On 08 Dec 2013, at 12:08, "Michael Richardson" wrote:
>
>
> Frederic Detienne (fdetienn) wrote:
>>> On 06 Dec 2013, at 19:41, Michael Richardson wrote:
>>> ...
>>> I'd rather that you had mandated OSPFv2/3 or someso that I could evalua
On 06 Dec 2013, at 19:41, Michael Richardson wrote:
> ...
> I'd rather that you had mandated OSPFv2/3 or someso that I could evaluate the
> entire solution.
The point is that we can't mandate that. Each of those protocols have different
properties and are better suited in various environments.
stalls a prefix in the RIB such tat
192.168.10.0 / 24 --> Tu1
I.e. IKE forces the traffic negotiated in the IKE exchange
I will add a section to this effect in the draft.
best regards,
fred
>
> (thread broken intentionally)
>
> Frederic Detienne (fdetienn) wro
Hi Andreas,
On 04 Dec 2013, at 09:59, Andreas Steffen
wrote:
> ...
> - No overlay of additional routing protocols is needed.
please note that our proposal does not mandate a routing protocol. We also
support IKEv2 config exchange and treat the protected subnets as "routes" for
the tunnel.
Hi Yaron,
Is this an official poll or is it "just to see" ? If this is serious, what is
the deadline ?
thanks,
fred
On 03 Dec 2013, at 18:40, Yaron Sheffer wrote:
> Dear IPsecME folks,
>
> There is clear working group interest in a standard auto-discovery VPN
> solution. We have ag
Hi Stephen,
On 05 Nov 2013, at 23:21, Stephen Kent wrote:
>
>> As for scaling, we already have DMVPN networks of 1+ nodes and looking
>> at building networks of 4+ nodes.
>> In many cases customers have multiple subnets behind each node, therefore
>> with just IPsec I would need to
Hi Praveen,
I think the discussion has been somewhat use case centric.
Like I said, we can take policy information from any source. The routing
protocol captures a mindshare in some deployments but it is not the only one.
In our last iteration (product called FlexVPN but compliant with the draf
On 06 Nov 2013, at 19:10, Michael Richardson wrote:
>
> Manish Kumar (manishkr) wrote:
>> NHRP is used to resolve the remote peer which serves/owns the address
>> we're
>> interested in. The information in this resolution culminates in the
>> creation of
>> SPD.
>
> I think your description
On 06 Nov 2013, at 19:01, Yoav Nir wrote:
>
> On Nov 6, 2013, at 7:53 AM, Manish Kumar (manishkr)
> wrote:
>
>> Steve,
>>
>> NHRP is used to resolve the remote peer which serves/owns the address we're
>> interested in. The information in this resolution culminates in the creation
>> of SP
On 06 Nov 2013, at 17:09, Stephen Kent wrote:
> Manish,
>> Steve,
>>
>> NHRP is used to resolve the remote peer which serves/owns the address we're
>> interested in. The information in this resolution culminates in the creation
>> of SPD.
> So the NHRP interaction creates a new SPD entry as a
Hi Tero,
yes you are right about the Child SA and definition. I think what Mike had in
mind is that in some platform architectures the selectors have to be expanded
in TSi x TSr entries which is not very friendly.
When we developed the protocol with IKEv1, multiple SA's simply were a no-no.
Wh
Hi Stephen,
please find some answers inline.
On 04 Nov 2013, at 22:57, Stephen Kent wrote:
> Mike,
>
> A couple of your comments caught my attention, as an author of 4301, 02, and
> 03. I admit to not having read the DMVPN proposal, so my comments are based
> only on your message, which argu
ed for interoperability).
thanks,
fred
> Thanks,
> Praveen
>
>
>> Thanks,
>> Praveen
>>
>>
>> On 10/9/13 8:23 AM, "Frederic Detienne (fdetienn)"
>> wrote:
>>
>> Hi Yoav,
>>
>> Thanks indeed for your co
today (and not required for
> interoperability) that is not part of this draft?
yes. Not sure how much more you want to know...
regards,
fred
> Thanks,
> Praveen
>
>
> On 10/9/13 8:23 AM, "Frederic Detienne (fdetienn)"
> wrote:
>
> Hi Yoa
Hi Yoav,
Thanks indeed for your comments! Please find additional [Fred] comments inline.
On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) wrote:
> Hi Yoav,
>
> Thanks for your comments. I would try adding clarity to some of these
> inline [Manish] to supplement what Mike said.
>
> Manish
>
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Frederic Detienne (fdetienn):MAILTO:fdeti...@cisco.com
ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=ipsec@ietf
.org:MAILTO:ipsec@ietf.org
DESCRIPTION;LANGUAGE=en-US:When: Wednesday\, November 16\, 2011 12:00 PM-2:
00 PM. UTC\nWhere: WebEx - 201
g":MAILTO:ipsec@ietf.org
ORGANIZER;CN="Frederic Detienne (fdetienn)":MAILTO:fdeti...@cisco.com
LOCATION:WebEx - 201 123 128
DTEND;TZID="Asia/Taipei":2016T22
DESCRIPTION:- WebEx Invite -\N\NMeeting Number: 201123128\NPassword
: NMRhBGcT\N\N--
32 matches
Mail list logo
