On Jun 15, 2012, at 1:34 PM, Tero Kivinen wrote:
2. Since INIT always happens over UDP, as responder, I can immediately
close any TCP connection that doesn't present an IKE header with an SPI
I recognize.
I don't agree that IKE_SA_INIT should always be over UDP. The first
flight of
slip through.
I guess. There is a MUST in section 2.4 for keeping retransmission detection,
so when implementing the transmitter, you can do either. It doesn't make sense
to retransmit at the application level when TCP does it for you.
Thanks,
Yaron
On 06/14/2012 12:59 AM, Yoav Nir
On Jun 14, 2012, at 10:34 PM, John Leser wrote:
On 06/14/12 13:39, Yoav Nir wrote:
Hi Yaron
Responses are inline.
Yoav
On Jun 14, 2012, at 1:40 AM, Yaron Sheffer wrote:
Hi Yoav,
thank you for the new draft. A few comments:
- Please mention the question of IKE keepalive
This line is not too hot either:
There's also a htmlized version available at:
http://tools.ietf.org/html/submission.filename }}-01
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E
Carpenter
Sent: 13 June 2012 10:48
To: IETF discussion
...@ietf.org
Subject: New Version Notification for draft-nir-ipsecme-ike-tcp-00.txt
Date: June 13, 2012 7:13:55 PM GMT+03:00
To: Yoav Nir y...@checkpoint.commailto:y...@checkpoint.com
A new version of I-D, draft-nir-ipsecme-ike-tcp-00.txt
has been successfully submitted by Yoav Nir and posted
Kivinen; ipsec@ietf.org; Yoav Nir
Subject: Re: [IPsec] Fragmentation causing IKE to fail
Hi Valery,
This is not a different problem, because whatever solution we choose, we must
ensure the whole system is functional: both IKE and IPsec. Routers that drop
IKE fragments will not hesitate to drop ESP
To be fair, nearly half the attendees come from that continent. Even when the
meetings are held in Taipei or Paris.
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randy
Bush
Sent: 10 June 2012 03:33
To: Glen Zorn
Cc: IETF Disgust
Subject: Re:
Hi
I work for a vendor selling and IKE/IPsec solution.
In the last few months, we've heard a troubling complaint from some of our
customers. They say that some ISPs have begun to drop IP fragments. While
specific ISPs were not named, most of the issues seem to be in south-east Asia.
One
On Jun 7, 2012, at 7:15 PM, Paul Hoffman wrote:
* Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is
already allocated to ISAKMP. We have had IKE running over TCP for several
years for remote access clients. This was done because remote access clients
connect from behind
On Jun 7, 2012, at 8:26 PM, Nico Williams wrote:
On Thu, Jun 7, 2012 at 11:54 AM, Paul Hoffman paul.hoff...@vpnc.org wrote:
On Jun 7, 2012, at 9:43 AM, Paul Wouters wrote:
Also, if we are doing this, I'd prefer to be able to signal which tcp
port to use, to make it more flexible to bypass
On Jun 8, 2012, at 1:01 AM, Paul Hoffman wrote:
On Jun 7, 2012, at 2:53 PM, Yoav Nir wrote:
On Jun 7, 2012, at 7:15 PM, Paul Hoffman wrote:
* Use IKE over TCP. Looking at the IANA registry ([2]) TCP port 500 is
already allocated to ISAKMP. We have had IKE running over TCP
On Jun 6, 2012, at 5:54 PM, Sheng Hsin Lo wrote:
Hello,
Should the SPD search in IPsec support longest prefix match(LPM)?
Hi
The answer is no. The SPD is an ordered list of entries, and the first match is
the one to follow.
RFC 4301 defines a decorrelation algorithm (section 4.4.1
Hi
The similarity of pinning and DANE has been discussed before. DANE relies on
DNSSEC being deployed, which key-pinning does not. Come to think of it, the
draft needs a section comparing with DANE, but that's for another thread.
draft-perrin-tls-tack seems to tackle the same problem as
On Jun 1, 2012, at 11:13 AM, Randy Bush wrote:
if i have to delete through much more about this bikeshed, i will give
you some colloquial american to read.
bikeshed ?
:-)
Yoav
Hi Peter
I tend to disagree. I am not a native English speaker, although I will admit to
watching way too much American TV in my teens.
I believe most of these should be recognizable to anyone who has learned enough
English to participate meaningfully in IETF mailing lists and discussions.
On May 31, 2012, at 10:39 PM, Martin Rex wrote:
Stephen Farrell wrote:
I'm with Brian and Yoav on this. I don't see a need
to change here. And I do think we might lose something
if we become too PC. If a bunch of non-native speakers
did say yes, I found that made the document less
useful
for Supporting ERP
Author(s) : Yoav Nir
Qin Wu
Filename: draft-nir-ipsecme-erx-04.txt
Pages : 8
Date: 2012-05-20
This document describes an extension to the IKEv2 protocol that
allows an IKE Security Association (SA) to be created
On May 20, 2012, at 11:36 PM, Marc Petit-Huguenin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/20/2012 12:41 PM, Stephane Bortzmeyer wrote:
On Wed, May 16, 2012 at 11:06:25AM -0400, Simon Perreault
simon.perrea...@viagenie.ca wrote a message of 12 lines which said:
One
On May 19, 2012, at 3:53 PM, Yaron Sheffer wrote:
Hi Vishwas, Yoav,
Check Point (IIRC) supports communities of IPsec endpoints, arranged
either as a star or a full mesh. This is nice and simple to configure
but obviously does not cover all use cases. Some networks cannot be
represented
Hi,
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments
to
Say this in the security considerations
Yoav Nir:
Has to be a requirement that any solution
can
implement different policies
Yaron Sheffer
I'm not sure I understand the suggested resolution. The biggest barrier to
direct connectivity is that the responder may be behind NAT. Is this considered
a routing issue? In any case, there are protocols for getting to a responder
behind a NAT. They work well enough that VoIP solutions work
for the mesh topology.
Let me know if that makes sense. I think we can state that the requirement
should allow for such iterative use cases, however at one instance we only look
at star or mesh topology. Do I make sense?
Thanks,
Vishwas
On Sat, May 12, 2012 at 11:34 AM, Yoav Nir
y
On May 10, 2012, at 12:10 PM, Doug Barton wrote:
On 5/10/2012 1:48 AM, Tobias Gondrom wrote:
What I dispute is that make available to those who are interested
necessarily leads to the need to broadcast the data (i.e. publish in the
proceedings).
What is the harm you are trying to guard
On May 10, 2012, at 8:42 PM, Melinda Shore wrote:
On 5/10/12 9:32 AM, Martin Rex wrote:
There has never been a need to actively broadcast these massive amounts
of personally identifiable information (PII), and I haven't seen any
convincing rationale for doing it now.
To be honest, I don't
I think that regardless of how it's worded, the real question is whether
liability falls to the person who sent the email (to a public mailing list) or
the IETF. The difference between believe and shown seems minor in
comparison.
-Original Message-
From: ietf-boun...@ietf.org
, if they
have been received in the UK via the Internet.
Regards
Brian Carpenter
On 2012-05-09 08:07, Yoav Nir wrote:
I think that regardless of how it's worded, the real question is whether
liability falls to the person who sent the email (to a public mailing list)
or the IETF
On May 9, 2012, at 12:28 PM, SM wrote:
Hi Yoav,
At 00:44 09-05-2012, Yoav Nir wrote:
What the IETF writes in its policy amounts to a plea to users to
pretty please send only factual information. I don't know that it
makes a difference as to who is liable if the information turns out
On May 8, 2012, at 1:12 PM, Yaakov Stein wrote:
Around 30%-40%. I don't have hard numbers,
but I have a feeling that it has gone down a bit in the last 10 years.
Yoav,
Your feelings are quite accurate as to the range,
but less so regarding the trend.
According to a recent study,
On May 5, 2012, at 4:58 AM, Marshall Eubanks wrote:
On Fri, May 4, 2012 at 9:50 PM, Phillip Hallam-Baker hal...@gmail.com wrote:
On Wed, May 2, 2012 at 3:14 PM, Hannes Tschofenig
hannes.tschofe...@gmx.net wrote:
Hi PHB,
the IETF is not like an enterprise where you can decide (as part of
PM, Paul Hoffman wrote:
On Apr 12, 2012, at 11:17 AM, Yoav Nir wrote:
We would like this working group to accept this, and have it added to
charter. Of course, if it gets accepted, we volunteer to be authors. If it
is not accepted, we will try to progress it as an individual submission
On May 1, 2012, at 12:31 AM, Janet P Gunn wrote:
My own anecdotes.
Yes, it starts early.
When I was 3 I announced that I was going to be a physicist when I grew up.
WHY?
1 - a physicist has a chair that is on WHEELS, and spins ROUND and ROUND
2 - a physicist has a blackboard with COLORED
On Apr 30, 2012, at 10:52 PM, Mary Barnes wrote:
Here is an article that does a far better job of explaining the situation than
I did:
http://www.todaysengineer.org/2011/May/women-in-engineering.asp
The largest reason women leave engineering is due to the work environment and
perceived lack
On May 1, 2012, at 4:45 PM, Mary Barnes wrote:
The article clearly states that women leave for the two reasons you mentioned,
which are certainly the exact same things males deal with, but you missed a few
others that the article notes, specifically and directly quoted below:
...lack of real
On May 1, 2012, at 8:44 PM, Janet P Gunn wrote:
This is VERY narrow minded, and, to be honest, somewhat insulting.
You suggest that time at work and family are the only important things to
women.
I'm suggesting no such thing. This authors of this survey say that women who
left engineering
Hi Phil
After each meeting, Ray sends out a survey to all participants. The results
from the latest one:
When were you born?
Before 19502.9%
1950 - 1960 16.6%
1961 - 1970 33.7%
1971 - 1980 32.8%
After 198014.0%
I think an earlier survey had the 1971-1980 crowd inch
On Apr 27, 2012, at 6:05 PM, Carsten Bormann wrote:
On Apr 27, 2012, at 16:41, Yoav Nir wrote:
Before 19502.9%
1950 - 1960 16.6%
1961 - 1970 33.7%
1971 - 1980 32.8%
After 198014.0%
Nice bell curve, יואב, but you can't pop that soap bubble of perception
RFC 2026 says this about Experimental RFCs:
The Experimental designation typically denotes a specification that
is part of some research or development effort.
However, I do not believe that this is still typical. Authors come up with
ideas that they think are useful. If when the
On Apr 16, 2012, at 1:53 PM, Nick Hilliard wrote:
I'd like to add a voice of support to this draft. AH adds little except
complication to ipsec implementations and confusion to end users.
It only adds confusion and complication in the sense that telnet adds them (ESP
is SSH in this
To: Yoav Nir y...@checkpoint.com
Cc: sunse...@huawei.com sunse...@huawei.com
A new version of I-D, draft-nir-ipsecme-erx-03.txt has been successfully
submitted by Yoav Nir and posted to the IETF repository.
Filename: draft-nir-ipsecme-erx
Revision: 03
Title: An IKEv2
On Apr 9, 2012, at 7:58 PM, Paul Hoffman wrote:
...are available at
http://www.ietf.org/proceedings/83/minutes/minutes-83-rpsreqs.txt. Send me
any corrections. My apologies for taking so long to do the transcription, but
there was a lot of good material there. There are many ideas that
Hi Daniel
On Apr 5, 2012, at 9:22 PM, Daniel Migault wrote:
Hi,
I am wondering how SPI collision is considered by IKEv2, and have not found
any documentation on it, so if there are some, please let me know.
My current understanding is that when an CREATE_CHILD_SA exchange is
On Mar 30, 2012, at 1:11 PM, Dean Willis wrote:
From today's meeting, taking to list.
Remote participation for users connecting via the PSTN though gateways into a
VoIP conference platform raises some issues.
One of these is registration . There are hacks like PINs that can be made
to
On Mar 30, 2012, at 1:11 PM, Dean Willis wrote:
From today's meeting, taking to list.
Remote participation for users connecting via the PSTN though gateways into a
VoIP conference platform raises some issues.
One of these is registration . There are hacks like PINs that can be made
to
[sorry for the resend]
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html.
https://www.ietf.org/mailman/listinfo/vmeet
Oh, this guy pre-dates RFC 4633
http://www.google.com/search?q=%22jim%20fleming%22%20site:ietf.org
On Mar 29, 2012, at 11:48 PM, Eric Burger wrote:
I was about to say we are at a point for an RFC 4633 action. Thanks.
On Mar 29, 2012, at 2:26 PM, JORDI PALET MARTINEZ wrote:
Hi Jim,
This
Hi Dan
I have no opinion about the level of review needed for changes to IKEv1, and I
share your unhappiness with the way PAKE turned out.
If I had to guess the reasons for the slow adoption of IKEv2, I would guess
that it's because IKEv1 (with XAuth/hybrid, Config, odd-numbered messages, and
On Mar 28, 2012, at 2:12 PM, Michael Richardson wrote:
Yoav == Yoav Nir y...@checkpoint.com writes:
Yoav If I had to guess the reasons for the slow adoption of IKEv2,
Yoav I would guess that it's because IKEv1 (with XAuth/hybrid,
Yoav Config, odd-numbered messages, and poor PSK
On Mar 26, 2012, at 9:52 AM, Michael Richardson wrote:
Geoffrey == Geoffrey Huang ghu...@juniper.net writes:
Geoffrey My initial inclination is to say that won't fly: that many
Geoffrey deployments still require preshared key authentication.
Geoffrey Rather, they would object to
On Mar 26, 2012, at 10:47 AM, Michael Richardson wrote:
Yaron == Yaron Sheffer yaronf.i...@gmail.com writes:
Yaron I don't want to speak for MCR, but I think you are taking his
Yaron question too far towards the implementation aspects. What I
Yaron read in the question is, do we
Hi
This is about my presentation from the IPsecME meeting today (which for some
reason is not on the website)
Anyways, RFC 5266 mentions that RFC 4306 must be updated to carry ERP
messages. This caused some controversy a year ago, but regardless, I did think
of a use case, so I partnered with
On Mar 26, 2012, at 6:43 PM, Tero Kivinen wrote:
Yoav Nir writes:
This is about my presentation from the IPsecME meeting today (which
for some reason is not on the website)
Anyways, RFC 5266 mentions that RFC 4306 must be updated to carry
ERP messages. This caused some controversy a year
Hi
It was my review that triggered this, so I'd like to explain my position.
There are several things that could be considered failures of the TLS layer:
1. Revoked certificate
2. No CRL/OCSP response
3. Expired certificate
4. Expired CRL (yes, I know NextUpdate is not expiry…)
5. Mismatch
Hi
This is about fetching CRLs from a domain that happens to be the same as that
of a website.
Obviously you can't get a CRL or an OCSP response over HTTPS. Jeff's response
was that they should use a different domain name for the CRLs (if they want to
deploy HSTS)
Obviously, it's too late
, India
+91-9686202644
On Wed, Mar 21, 2012 at 6:49 PM, Yoav Nir
y...@checkpoint.commailto:y...@checkpoint.com wrote:
direct endpoint-to-endpoint connectivity may not be possible if both endpoints
are NATed
Why? There are several protocols (SIP/RTP come to mind) that manage
endpoint-to-endpoint
I don't think this is an all-or-nothing choice. You might want a mesh for VoIP,
but a star for HTTP, FTP and mail protocols. Or you may want a mesh within your
organization, but to trunk and inspect all traffic going somewhere else.
On Mar 21, 2012, at 3:37 AM, Stephen Hanna wrote:
Please
direct endpoint-to-endpoint connectivity may not be possible if both endpoints
are NATed
Why? There are several protocols (SIP/RTP come to mind) that manage
endpoint-to-endpoint connectivity even when both are behind NAT. Why shouldn't
IPsec endpoints do this?
If this requires some new NAT
I agree that this pre-supposes that the solution will involve gateways
figuring things out for endpoints in either one step or more than one step.
It pre-supposes a two-tier system.
We've had a presentation in Taipei that did not involve gateways, but rather
specialized servers carrying
+1
Not only IP addresses, but actual peers may come and go. A user database
changes every day as employees (for example) come and go.
On Mar 21, 2012, at 9:26 PM, Vishwas Manral wrote:
Hi Steve,
Like I mentioned the problem is not just exhaustive configuration but also the
fact that
On Mar 14, 2012, at 8:00 AM, Tero Kivinen wrote:
In section 2.1 where there is dicsussion about the endpoint to
endpoint vpn use case, it should be noted, that this might require
different temporary credentials. Endpoints (especially remote access
users) do use passwords or similar
Even better, also add the XML2RFC output if it's available at the same time:
http://tools.ietf.org/id/draft-name.html
for example, (just picking my own latest draft as an example):
http://tools.ietf.org/id/draft-nir-websec-extended-origin-02.html
I don't know which drafts get this version
The XML2RFC version is not linked from there. If that was added to the Other
versions field, that would be great.
On Mar 6, 2012, at 5:11 PM, Xavier Marjou wrote:
With a link like https://datatracker.ietf.org/doc/draft-name/ (e.g.
On Mar 6, 2012, at 11:44 PM, Julian Reschke wrote:
On 2012-03-06 16:26, Yoav Nir wrote:
The XML2RFC version is not linked from there. If that was added to the
Other versions field, that would be great.
...
Indeed. HTMLized plain text is progress over plain text, but properly
generated
Hi Steve
On Mar 6, 2012, at 11:54 PM, Stephen Hanna wrote:
So please review this short document and send comments.
While the draft does a good job of describing use cases, and certain inadequate
solutions, I think it's missing a description of why this is hard.
Even if we accept the solution
Hi Tobias,
Replies inline.
On Mar 3, 2012, at 6:07 PM, Tobias Gondrom wrote:
Hello Yoav,
thank you for the interesting draft.
hat=individual
I have a few points as feedback:
- the 3-tupel of origin consists of real parameters (protocol, URL,
port), while the introduction of the 4th
On Feb 26, 2012, at 2:44 AM, Mark Nottingham wrote:
I proposed a plan that I think might allow us to make progress
on that. I believe we could.
OK, great.
Could you please explain why you think tying this effort to HTTP/2.0 is
necessary to achieve that? To me that's the critical
On Feb 24, 2012, at 5:02 PM, Paul Hoffman wrote:
On Feb 24, 2012, at 4:54 AM, Stephen Farrell wrote:
Proposals for new HTTP authentication schemes are in scope.
How would a plan like the following look to folks:
- httpbis is chartered to include auth mechanism work as
per the above
On Feb 16, 2012, at 4:09 PM, Måns Nilsson wrote:
Subject: IETF Last Calls and Godwin-like rules Date: Thu, Feb 16, 2012 at
09:04:03AM -0500 Quoting John C Klensin (john-i...@jck.com):
...
first appearance of many no-information I support this
endorsements from people and constituencies
On Feb 16, 2012, at 4:04 PM, John C Klensin wrote:
A current Last Call has apparently brought on another of the
please tell all your friends to send in supportive notes, even
if they don't say much of anything substantive campaigns that
we see from time to time. When those notes come from
On Feb 16, 2012, at 4:48 PM, Roger Jørgensen wrote:
On Thu, Feb 16, 2012 at 3:34 PM, Yoav Nir y...@checkpoint.com wrote:
snip
I think that an endorsement like I work for Cisco and we intend to
implement this in every one of our products is useful. But it's not nearly
as useful
On Feb 15, 2012, at 1:56 AM, Bob Hinden wrote:
Martin,
On Feb 14, 2012, at 2:45 PM, Martin Rex wrote:
Brian E Carpenter wrote:
Martin,
One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF. But if you look at the IETFs
(lack of) migration
On Feb 12, 2012, at 10:19 PM, Kai Engert wrote:
On 12.02.2012 01:57, Stephen Farrell wrote:
If folks wanna meet during IETF week then I'd suggest a doodle
poll to pick a time slot.
How about this?
http://www.doodle.com/8c5s43ayqbrft5rm
That's about it, but usually we do this after the
Hi Kevin
You can register at https://www.ietf.org/meeting/register.html
You can hold off on paying until early March.
That will give you the ability to edit the meeting wiki:
https://www.ietf.org/registration/MeetingWiki/wiki/ietf83
You can easily add a page there for what you're looking for.
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: 答复: Re: [IPsec] [IPSec]: New Version Notification for
draft-zong-ipsecme-ikev2-cpext4femto-00.txt
Hi Yoav:
Thank you for your email. Regarding to your question on what is the malicious
FAP lying about, I would like to give you some further background
I believe that Alexey has requested a session on 19-Dec.
On Jan 17, 2012, at 7:08 PM, Peter Saint-Andre wrote:
Just a friendly reminder that WG sessions for IETF 83 need to be
scheduled less than 2 weeks from now:
http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83
Peter
Interesting.
But I don't see how subdomains help. If I have a website called
charcount-5.example.com, and I use a wildcard *.example.com certificate, the
HSTS entry is still written for charcount-5.example.com. Adding subdomains
would affect *.charcount-5.example.com, not 0-H.example.com.
I
8, 2011, at 10:06 PM, Yoav Nir wrote:
Agree. How about:
In an environment with many IPsec gateways and remote clients that
share an established trust infrastructure (in a single
administrative domain or across multiple domains), customers want
to get on-demand point-to-point IPsec
On Dec 22, 2011, at 9:07 PM, Gaurav Poothia wrote:
Hello,
The basic IKEv2 cert auth mechanism for RSA (from RFC 5996) seems to be to hash
using SHA-1 before signing.
However when using ECDSA certs for IKEv2 I am trying to make sure I am reading
RFC 4754 correctly when it says the following:
Hi
I've compiled a recent SNAP of OpenSSL 1.0.1 (from 18/12). I am pretty sure
that the assembly language code generated for the ghash function (in
ghash-x86.s) is incorrect.
The gcm_init_4bit() function generates a 16-entry table of 128-bit values, to
be used as a multiplication table. The
logic, or +1 is
all it takes.
Yoav
On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote:
Agree. How about:
In an environment with many IPsec gateways and remote clients that share an
established trust infrastructure (in a single administrative domain or across
multiple domains), customers want
Hi all.
The discussion has died down a bit, so I thought I'd chime in with proposed
charter text. What do people think of the following? The first paragraph is
taken from Steve's email of 18-Nov.
Yoav
In an environment with many IPsec gateways and remote clients that share an
established
On Dec 8, 2011, at 6:04 PM, Paul Hoffman wrote:
On Dec 8, 2011, at 1:55 AM, Yoav Nir wrote:
In an environment with many IPsec gateways and remote clients that share an
established trust infrastructure (in a single administrative domain or
across multiple domains), customers want to get
On Dec 8, 2011, at 8:14 PM, Yaron Sheffer wrote:
We as a group can commit to deliverable #1 and #3 (problem statement and
standardized solution). But deliverable #2 (vendor protocols) is mostly
out of our hands.
That's why I used review and help rather than write or produce.
So before we
On Nov 21, 2011, at 10:09 PM, Stephen Hanna wrote:
The conclusion of Wednesday night's P2P VPN side meeting
was that we would start a new thread on the proposed
ipsecme charter change and resolve the open questions
by email. Let's start off with the text that came out
of Wednesday's meeting
On Aug 6, 2011, at 10:37 PM, Yoav Nir wrote:
Hi
At the meeting in Quebec, I gave a presentation at the hokey meeting about
http://tools.ietf.org/html/draft-nir-ipsecme-erx .
The draft covers using the EAP extensions for re-authentication in IKEv2. The
obvious (to me) use-case
On Nov 18, 2011, at 2:06 AM, Nico Williams wrote:
On Wed, Nov 16, 2011 at 8:17 PM, Yoav Nir y...@checkpoint.com wrote:
On Nov 17, 2011, at 9:31 AM, Paul Wouters wrote:
But seriously, IPsec tunnels are based on RFC 4301 and there SPDs and PADs
are static, so there is only one peer where
to test it, and say
hi, go ahead.
Otherwise see y'all at 20:00 in room 101D.
Yoav
On Nov 14, 2011, at 10:09 AM, Yoav Nir wrote:
Hi all
This is to announce a side meeting about peer to peer VPN, as described in
our recently published draft:
http://tools.ietf.org/html/draft-nir-ipsecme-p2p-00
16, 2011 4:24 AM
To: Yoav Nir
Cc: ipsec@ietf.org WG; Tero Kivinen; Mike Sullenberger
Subject: Re: [IPsec] P2P VPN - Side Meeting
You are mixing everything up. It is too much work to correct you over
email. I will try to help you at the meeting.
regards,
fred
On 16 Nov 2011
On Nov 17, 2011, at 2:17 AM, Michael Richardson wrote:
Mike I am not sure where you are getting a set of extended
Mike access-lists. There aren't any extended access-lists added.
Mike If a packet is routed through the tunnel it is encapsulated
Mike and then encrypted. There
On Nov 17, 2011, at 9:31 AM, Paul Wouters wrote:
On Thu, 17 Nov 2011, Yoav Nir wrote:
Not necessarily. If your device drops packets that come through the wrong
tunnel, you're safe. Typically in a complex network you will allow multiple
paths through the overlay network, and then some
On Nov 15, 2011, at 5:55 PM, Ray Bellis wrote:
On 15 Nov 2011, at 16:26, Bob Hinden wrote:
+1
The Datatracker does officially support PPTX, so I don't believe it's
unreasonable to use it. If you don't like that policy, I'm not sure where
you would take that up.
It also hadn't
On Nov 16, 2011, at 2:28 AM, Martin Rex wrote:
todd glassey wrote:
Marshall Eubanks wrote:
Should the system reject PPTX files ? If people can't read them, why
are we accepting them ?
I would appreciate if that datatracker simply rejected PPTX on upload.
It is several mangnitudes
On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote:
On 15 Nov 2011, at 12:05, Yoav Nir wrote:
Hi Frederic
Inline...
On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote:
Hi Yoav,
We will be there (following offline with you for the details).
I do not think
Hi Mike
On Nov 15, 2011, at 6:25 PM, Mike Sullenberger wrote:
Hi Yoav,
Please see inline.
Mike.
On Nov 15, 2011, at 12:12 PM, Frederic Detienne wrote:
On 15 Nov 2011, at 12:05, Yoav Nir wrote:
Hi Frederic
Inline...
On Nov 15, 2011, at 11:42 AM, Frederic Detienne wrote
On Nov 15, 2011, at 7:36 PM, Ulliott, Chris wrote:
Classification:UNCLASSIFIED
The problem with a single SA is that it usually means a single key (what ever
form that takes) such that a compromise of a single spoke puts all traffic at
risk... So what ever solution we go for - we need to
On Nov 15, 2011, at 10:52 PM, Michael Richardson wrote:
Mark == Mark Boltz mark.bo...@stonesoft.com writes:
Mark With all due respect to Cisco, the larger problem we're trying
Mark to address, is in part the fact that DMVPN and ACVPN are
Mark vendor specific implementations. And
really is not a problem until shown otherwise.
Again, I urge you to be specific because there is nothing tangible in your
claims. I understand what you mean but if you rationalized it, you would see
your intuition fools you.
On 16 Nov 2011, at 14:17, Yoav Nir wrote:
On Nov 16, 2011
On Nov 16, 2011, at 3:31 PM, Tero Kivinen wrote:
Frederic Detienne writes:
Again, I urge you to be specific because there is nothing tangible
in your claims. I understand what you mean but if you rationalized
it, you would see your intuition fools you.
When one does not know what problem
On Nov 16, 2011, at 3:38 PM, Tero Kivinen wrote:
Frederic Detienne writes:
Frederic Detienne writes:
And like I said earlier, the amount of negotiation when there are
multiple prefixes to protect is limited to one. With modern ipsec
tunneling (got to love that), there is still a lot of
On Nov 15, 2011, at 10:24 AM, Brian E Carpenter wrote:
Please can everybody who doesn't upload PDF to the meeting materials page
at least take care to upload PPT instead of PPTX?
Not everybody has paid the ransom necessary to open PPTX files.
The latest LibreOffice (and I think also
901 - 1000 of 1331 matches
Mail list logo
