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
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
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 Detienne (fdetienn)
fdeti...@cisco.com wrote:
Hello,
we would like to implement new
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
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 detailed
On 03 Feb 2014, at 16:28, Yoav Nir y...@checkpoint.com 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
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
address
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.
Thanks,
Praveen
On 2/5/14, 5:45 AM, Frederic Detienne
.
Thanks,
Praveen
On 1/13/14, 8:07 AM, Frederic Detienne (fdetienn) fdeti...@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
you,
Frederic Detienne
On 13 Jan 2014, at 17:07, Frederic Detienne (fdetienn) fdeti...@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
, Frederic Detienne (fdetienn) fdeti...@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
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
Hi Andreas,
On 04 Dec 2013, at 09:59, Andreas Steffen andreas.stef...@strongswan.org
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
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) fdeti...@cisco.com wrote:
...
- No overlay of additional routing
On 06 Dec 2013, at 19:41, Michael Richardson mcr+i...@sandelman.ca 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
On 06 Nov 2013, at 17:09, Stephen Kent k...@bbn.com 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
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
Hi Stephen,
On 05 Nov 2013, at 23:21, Stephen Kent k...@bbn.com 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
Hi Stephen,
please find some answers inline.
On 04 Nov 2013, at 22:57, Stephen Kent k...@bbn.com 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,
On 10/9/13 8:23 AM, Frederic Detienne (fdetienn) fdeti...@cisco.com
wrote:
Hi Yoav,
Thanks indeed for your comments! Please find additional [Fred] comments
inline.
On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) manis...@cisco.com
wrote:
Hi Yoav,
Thanks for your comments. I
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) fdeti...@cisco.com
wrote:
Hi Yoav,
Thanks indeed for your comments
Hi Yoav,
Thanks indeed for your comments! Please find additional [Fred] comments inline.
On 07 Oct 2013, at 19:47, Manish Kumar (manishkr) manis...@cisco.com wrote:
Hi Yoav,
Thanks for your comments. I would try adding clarity to some of these
inline [Manish] to supplement what Mike said.
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
23 matches
Mail list logo
