for the lifetime of the IKE SA. Perhaps we could store the contents of
the previous AUTH payload (or a hash thereof) and sign that.
On Oct 6, 2010, at 11:17 PM, Keith Welter wrote:
Yoav Nir y...@checkpoint.com wrote on 10/05/2010 07:33:33 AM:
Hi Keith.
After reading your draft, I wish I had
I was not suggesting to use SK_d itself.
RFC 5996 says this:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
I suggest replaceing/augmenting it with this:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr | SK_ri
Hi Keith.
After reading your draft, I wish I had done this in RFC 4478. Still, I have
some comments.
What are the considerations for the responder accepting a re-authentication?
Suppose we have an active IKE SA between Alice and Bob. Now Bob gets a new
IKE_SA_INIT request with an
identities.
All the more reason to have set rules on when a new IKE SA can inherit.
But this implies that we need something else to ensure continuity of the
identity, and mixing the old SK_d into the new authentication certainly
makes sense.
Thanks,
Yaron
On 10/05/2010 04:33 PM, Yoav
OK. there were zero responses to this. Since this seems obvious to me, I will
correct it as Scott suggests, and close the issue with the publication of -01.
On Sep 21, 2010, at 2:58 PM, Yoav Nir wrote:
Hi all.
We're starting discussions of the issues that are open for the failure
This was actually reported by both Yaron and Tero. I have no problem moving
the QCD token to the first message (in case of EAP), but as Yaron requested, I
will not publish the fixed version before the resolution of #191.
Two more issues soon.
Yoav
On Sep 21, 2010, at 3:06 PM, Yoav Nir wrote
Reported by Yaron Sheffer:
5.1: this method is indeed problemmatic if SPIi/SPIr pairs are repeated with
high probability. If SPI pairs only repeat across reboots (somewhat unlikely),
then an epoch (time of last reboot) value can be included to mitigate this
problem. This is still close enough
Reported by Yaron Sheffer:
9.1: this is not really a MUST, let's use some non-RFC 2119 wording.
Yoav Nir: I disagree. We are giving requirements for implementations that
conform to this spec. The requirements vary by the role that the implementation
plays: RA client, RA gateway, Site to site
Hi all.
We're starting discussions of the issues that are open for the failure
detection draft.
Reported by Scott C Moonen:
What is the purpose of sending an empty response to the unprotected
N(INVALID[_IKE]_SPI)N(QCD_TOKEN)+ message? I'm not sure it provides any real
value and would
Reported by Yaron Sheffer:
I would have preferred the token to be resistant to stealing (and duplication),
in which case it can be sent in the *first* AUTH message. If we ensure that the
token maker's SPI is long/random (see below), this might be possible.
The relevant part of the document
On Sep 8, 2010, at 3:03 AM, Marshall Eubanks wrote:
On Sep 7, 2010, at 7:26 PM, Richard Bennett wrote:
I think you should have shared the message from our public relations agency
that started this incident, Russ. Here's what it said:
--
IETF Chair speaks on Paid
On Sep 8, 2010, at 1:50 PM, Tero Kivinen wrote:
Raj Singh writes:
It's actually worse than that. If message #4 was missed, and 5-8 were
received, then messages 5-8 are stored, but not processed. This has to be
so, because suppose message 7 deletes the SA that was created in message 4,
you
True.
But the visa issues seem to be the worst part of any US IETF. Travel, food and
finding a hotel are typically much easier in most US venues then European
venues.
People from Europe, Japan, Australia, and some other countries don't need a
visa at all to go to an IETF meeting in the US.
On Sep 4, 2010, at 3:01 PM, Kalyani Garigipati (kagarigi) wrote:
1. If window size is say some five and range expected is 4-8, and if
peer has got all four requests with values 5,6,7,8 and 4 is lost, then
there would be no message id that can be used to send the notify
reset_window.
The
On Sep 5, 2010, at 11:03 AM, Yaron Sheffer wrote:
In general, the draft is in good shape. But IMO, we have one major
security issue left: the dependence on SPI values which potentially come
from a small space, i.e. may be repeated in normal operation, or may be
coerced into repeating.
On Aug 31, 2010, at 4:56 PM, Iljitsch van Beijnum wrote:
Consider that contributors
usually start as newcomers, attend several meetings, then write a draft,
I don't know about you, but I wrote drafts before my first meeting.
Me too. I actually had an RFC published two months before
On Aug 31, 2010, at 10:43 AM, t.petch wrote:
If you want to be fair to the individual participants you have to optimize
in such a way that attending 6 meetings costs the same for every individual
that
regularly attends the IETF. Obviously one can only approximate that by putting
fairly
On Aug 29, 2010, at 9:32 AM, Ole Jacobsen wrote:
You said:
For an IETF meeting, we don't really have either of these.
What? IETF 79 is hosted by Tsinghua University, CERNET and CNNIC. The
website is still work in progress, but I would be very surprised if
they won't iinclude
On Aug 29, 2010, at 10:31 AM, Glen Zorn wrote:
Lonely Planet? Google? Ask someone who has been there? Wait a couple
of weeks and see what the host comes up with?
Again, that’s not the problem: in about an hour I was able to come up with
half a dozen 4*+ hotels as close or closer to the
On Aug 29, 2010, at 10:31 AM, Glen Zorn wrote:
Ole Jacobsen [mailto:o...@cisco.com]mailto:[mailto:o...@cisco.com] writes:
On Sun, 29 Aug 2010, Yoav Nir wrote:
Hopefully. But only the two hotels listed there have agreements and
special rates for IETF attendants. In Maastricht there were
On Aug 29, 2010, at 11:08 PM, Randall Gellens wrote:
At 8:51 AM -0700 8/24/10, Dave CROCKER wrote:
Let me get this straight. You are going to go to China and you
are /not/ going to do ANY site-seeing? If the answer is yes, I
think you have deeper problems than the visa...
I
On Aug 29, 2010, at 2:55 AM, Glen Zorn wrote:
What you save in transportation at the tail end can be totally destroyed
by hotel and dining costs, and the IETF has to pay more for meeting
facilities.
Speaking of which, I hope to be the first to note that paying $192 for a
room in Beijing
On Aug 27, 2010, at 12:18 AM, Dave CROCKER wrote:
On 8/26/2010 2:08 PM, Cullen Jennings wrote:
Thank you for providing this but this data seems to support something closer
to 2-1-1 than 1-1-1
...
(and sorry I just joined the thread now - been on vacation )
Cullen,
The rest of the
On Aug 26, 2010, at 4:35 AM, JORDI PALET MARTINEZ wrote:
Hi Alexa, all,
In many countries, applying for a VISA different that the main purpose of
the travel to the country is illegal and could mean that you pay fines, get
deported, or even go to the jail.
In many countries, if you are
I'm more in favor the 3-2-1 model. The stats clearly show that the largest
group of repeat offenders comes from the US.
But either way, I also agree that Europe is the summer is not ideal. in the US
there's much less of the vacances phenomenon.
So how about:
- March in Europe
- July in N
On Aug 5, 2010, at 5:07 PM, Michael Richardson wrote:
Yoav == Yoav Nir y...@checkpoint.com writes:
Yoav In keeping with IETF traditions, I'm putting some XML where my
Yoav mouth is.
Yoav Here's a -00 draft about this.
Yoav
http://www.ietf.org/internet-drafts/draft-nir
Asia is big. Some parts of Asia (the middle east and the eastern parts of
Russia) are closer to Europe than to China, Japan or Korea, at least as far as
traveling goes.
But I think that only adds up to about 15-20 attendees, so it's still in the
noise.
I also wonder if the data we have is
On Aug 2, 2010, at 10:20 PM, Yoav Nir wrote:
On Aug 2, 2010, at 6:16 PM, Spencer Dawkins wrote:
In the case of the 2 BarBOFS I organized at IETF-78, in both cases
there were very useful contributions made by people I didn't know and
therefore wouldn't have invited. Even if the efforts
On Aug 3, 2010, at 8:32 PM, Brian Eaton wrote:
Please provide an example of code that you would put to
thirdparty.comhttp://thirdparty.com and that
would not break the use cases.
Take a look at the facebook APIs, in particular the cross-domain
communication schemes:
On Aug 3, 2010, at 11:18 PM, Marius Scurtescu wrote:
On Tue, Aug 3, 2010 at 12:44 PM, Yoav Nir y...@checkpoint.com wrote:
On Aug 3, 2010, at 8:32 PM, Brian Eaton wrote:
Please provide an example of code that you would put to thirdparty.com and
that
would not break the use cases
Partially agree.
Just requiring a draft (that was not submitted within the meeting week) gives
you a two-week waiting period. I'm not so sure about the mailing list
requirement.
One of the best presentations-posing-as-barBoF in IETF 77 was about a traceback
experiment in Japan. They did
On Aug 2, 2010, at 5:48 PM, Marshall Eubanks wrote:
Dear Joel;
On Aug 1, 2010, at 10:08 AM, Joel M. Halpern wrote:
In hallway discussion about this, it was suggested to me that part
of the problem is that some folks can not figure out how to
socialize their ideas.
I would say
On Aug 2, 2010, at 6:16 PM, Spencer Dawkins wrote:
In the case of the 2 BarBOFS I organized at IETF-78, in both cases
there were very useful contributions made by people I didn't know and
therefore wouldn't have invited. Even if the efforts fail (and one of
them was DOA and will not move
On Jul 31, 2010, at 2:00 PM, Peter Saint-Andre wrote:
At 9:32 AM -0800 7/30/10, Melinda Shore wrote:
The implication that there needs to be a session, with a room
and slides and humans sitting in chairs, kind of suggests that
people who want to participate in the IETF have to attend
On Aug 1, 2010, at 9:45 AM, Melinda Shore wrote:
Yoav Nir wrote:
Who's folks? A lot of people come to an IETF meeting, and are
only following one or two of the working groups. That does not mean
that they sit in their hotel rooms for the rest of the meeting.
Instead, they pick what looks
I think there are really two issues here.
First is people who have an idea they want to present, but that idea either
doesn't fit the charter of any particular working group (or they don't know
about such a working group), or else said working group's schedule is too full
with existing work.
On Jul 30, 2010, at 7:32 PM, Melinda Shore wrote:
Yoav Nir wrote:
First is people who have an idea they want to present,
but that idea either doesn't fit the charter of any
particular working group (or they don't know about such a
working group), or else said working group's schedule
But we have...
On Jul 27, 2010, at 5:08 PM, Phillip Hallam-Baker wrote:
The endpoints used in these protocols all have the ability to perform
public key cryptography at acceptable speeds. Even if they did not,
the price of 64Mb of flash memory is negligible these days and that is
sufficient
On Jul 28, 2010, at 9:30 AM, jarrett...@oracle.com wrote:
A new 00 version of IKEv2 extension for security label has just been
published:
http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-label-00
Authors welcome comments from IPsec community.
Thanks.
You will get that, but
In today's session there was an disagreement between Yaron and Tero about how
likely it is that messages are missing.
Let's assume our cluster has tunnels with 10,000 peers, and that we do Liveness
Check (DPD) every 20 seconds (StrongSwan default)
Also, let's assume that we synch every 0.1
Thanks for the extensive review, Tero.
I haven't had time to read it through yet, but I would like to respond to one
point in this (below)
On Jul 25, 2010, at 4:30 PM, Tero Kivinen wrote:
The big issue is that the draft does not provide solution to case
where the IKEv2 SA messages missed
Hi all
The Quick Crash Detection protocol is one of the candidates for the failure
detection work item in our charter.
I have implemented in my company's product with a private Notify type and a
VendorID, and up until a few months ago, this has been the only implementation
that I know of.
As
Hi Adrian
It depends on the definition of politicking. In this, umm, draft, there's this
definition:
An organized campaign that seeks selection of a particular nominee
So you can't promote Dave all by yourself. You'll have to get a bunch of people
sending over-the-top opinions (Dave will save
There this:
http://www.maastrichtbrusselexpress.nl/?id=26
But apparently it doesn't run on Sunday.
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Iljitsch van Beijnum
Sent: Tuesday, July 13, 2010 10:03 AM
To: IETF-Discussion list
Subject: Re:
On July 08, 2010 12:42 AM joel jaeggli wrote:
On 2010-07-07 12:53, Ole Jacobsen wrote:
Sam,
I view this more or less as standard boilerplate, something you find
in a lot of online places. I think it is reasonable to expect that
if you register for a meeting your personal info (e-mail
Sure we are, but I didn't want to start the discussion, because QCD is my
proposal.
Hopefully we've learned something from the history of XAuth vs Hybrid, and we
won't end up with two non-interoperable, proprietary ways of doing this,
neither of which makes it to RFC. I think that failure led
: July 4, 2010 5:15:22 PM GMT+03:00
To: Yoav Nir y...@checkpoint.commailto:y...@checkpoint.com
Subject: New Version Notification for draft-ietf-ipsecme-ipsec-ha-09
A new version of I-D, draft-ietf-ipsecme-ipsec-ha-09.txt has been successfully
submitted by Yoav Nir and posted to the IETF
On Jun 26, 2010, at 12:56 AM, Phillip Hallam-Baker wrote:
The fact remains that RFC 821 has the STANDARD imprimatur and the better
specification that was intended to replace it does not.
Yes, but most of the RFC repositories, including
http://tools.ietf.org/html/rfc821 show Obsoleted by:
On Thursday, June 24, 2010 22:01 Phillip Hallam-Baker wrote:
snip/
We currently have the idiotic position where RFC821 is a full standard and
RFC2821 which obsoletes it is not.
Why is this idiotic. RFC 821 needed to be obsoleted. It had some features that
needed to be removed, and some
Hi all
No big changes here. Just some nits from the secdir review.
Yoav
On Jun 24, 2010, at 6:00 PM, internet-dra...@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Security Maintenance and Extensions
I like this proposal, but there should be a (relatively) easy process to
advance from Experimental to Proposed, especially if implementation experience
shows no need for bits-on-the-wire changes.
We should be able to say that for a particular experimental RFC there have been
this many
Hi Sean.
I have just submitted version -05 which addresses most (but not all) of your
comments. Here's a list of the exceptions (hope I didn't miss any)
#2. I've worded the abstract a little differently. Main difference is adding to
gaps in existing standards the words and their
On Jun 10, 2010, at 6:39 PM, Sean Turner wrote:
Yoav Nir wrote:
#13, #15, a few more (no MUST/SHOULD/MAY language). I have two issues with
this. The first, is that this document is a problem statement, and intended
to be INFORMATIONAL. No gateway is ever going to be said to implement
Done in -06
On Jun 10, 2010, at 7:17 PM, Sean Turner wrote:
Yoav Nir wrote:
On Jun 10, 2010, at 6:39 PM, Sean Turner wrote:
Yoav Nir wrote:
#13, #15, a few more (no MUST/SHOULD/MAY language). I have two issues with
this. The first, is that this document is a problem statement
Hi Lars
Great study. Looking forward to seeing more devices there.
Two tests I would add to this:
1. TCP segment size negotiation - have a low-MTU link somewhere between the NAT
box and the server, and see if the MSS gets adjusted like it should.
2. IKE/IPsec - IKE was supposed to go from
Nice to hear just worked in the context of IPv6. Did your router give you
just an IPv6 address, or also an IPv4 address? If both, does the IPv6 address
ever get anywhere on the Internet, or is it always NATted?
-Original Message-
From: ietf-boun...@ietf.org
Hi.
This draft revision includes comments from Jean-Michel Combes and Yaron.
-Original Message-
From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] On
Behalf Of internet-dra...@ietf.org
Sent: Tuesday, June 01, 2010 10:15 AM
To: i-d-annou...@ietf.org
Cc:
1. I didn't want to make ha-03 dependent on bis, but since bis is now approved,
we may as well do it.
2. OK
3. It should be out of scope, because this is internal to the cluster. We are
not going to require a peer to accept having two SAs with the same SPIs with
the same peer, so it's up to
Works for me.
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
Stephen Kent
Sent: Thursday, May 27, 2010 5:18 PM
To: Yoav Nir
Cc: IPsecme WG
Subject: Re: [IPsec] Working Group LC: draft-ietf-ipsecme-ipsec-ha-03
At 11:36 AM +0300 5/27/10, Yoav
I'm fine with the change, and with the reference being either normative or
informative. I prefer informative, though.
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron
Sheffer
Sent: Saturday, May 08, 2010 11:55 PM
To: IPsecme WG
Subject:
Can't compete with Martin's running code, but I have a few comments. Before
that, the draft seems good, and easy to follow. I think developers who have
never heard of the IPsec list should have no problem reading and implementing
this correctly. Having said that, here's two comments.
The
Well, this draft is kind of a smorgasbord of issues, so once the issue that
bothers you is in there, you're not that interested any more.
I would like to post another draft with section 3.7 that I posted on the list
on 25-Apr, and unless anyone has another issue that's not addressed, I think
Sorry for the dual post. Some mail client problem.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
This is why we need multiple vendors to look at this draft.
On Apr 26, 2010, at 2:29 PM, Tero Kivinen wrote:
Yoav Nir writes:
I agree. And whatever we may think of the particular solution, it does
present a problem that can and should be in the problem statement draft.
So how about adding
I agree. And whatever we may think of the particular solution, it does present
a problem that can and should be in the problem statement draft.
So how about adding teh following sub-section:
3.7. Different IP addresses for IKE and IPsec
In many implementations there are separate IP
On Apr 22, 2010, at 1:46 AM, Martin Rex wrote:
It might be worse than that, actually.
When RFC-5746 was recently published, the URL from an extremely useful
informative reference apparently got stripped by the RFC Editor:
draft -03:
[Ray09]Ray, M., Authentication Gap in TLS
Hi.
It's true that the standard is more geared to full implementations than those
minimal implementations, but in this case there really is no solution.
The minimal implementation can delete the IKE SA that was created and start
fresh with a single pair. But since the responder is also not
How about a Real World Deployment wiki page linked from each RFC, where
implementers can insert comments like Don't do like vendor xxx - don't always
set the nonce to zero.
Hopefully vendor xxx fixes it in the next release, and changes the page to read
Don't do like vendor xxx did prior to
On Mar 22, 2010, at 6:44 PM, sh...@arsc.edu sh...@arsc.edu wrote:
This is probably a small thing, but in general the term cluster
implies at least some degree of shared state among cluster members.
I understand that there's some suggestion of that in saying that
a cluster protects the same
You have to admit, though, that sending spam in a link to Google docs is
impressive. Shows real ingenuity and innovation from the spamming community.
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Robert
Stangarone
Sent: Thursday, April 15,
Begin forwarded message:
From: IETF I-D Submission Tool idsubmiss...@ietf.org
Date: April 14, 2010 8:21:14 PM GMT+03:00
To: Yoav Nir y...@checkpoint.com
Subject: New Version Notification for draft-ietf-ipsecme-ipsec-ha-01
A new version of I-D, draft-ietf-ipsecme-ipsec-ha-01.txt has
Hi all.
As the previous discussion on this topic showed, the WG would like a more
thorough taxonomy in section 2 of the HA/LS draft. Here's what I have come up
with so far. Please send comments to the list.
2. Terminology
Single Gateway is an implementation of IKE and IPsec enforcing a
On Apr 13, 2010, at 1:17 PM, Yaron Sheffer wrote:
Looks good. A few comments down below.
Yaron
On Tue, 2010-04-13 at 11:49 +0300, Yoav Nir wrote:
Fault Tolerance is a condition related to high availability, where
a system maintains service availability, even when a specified
Hi all
Following Sean's review, Paul has opened 7 issues, which we'd like to close.
I think issues #182, #183, #185 and #186 can be closed immediately.
I think issues #181, #184 and #187 can also be closed, and I have included
below my suggestions. Please take a look and respond if you
On Apr 5, 2010, at 5:25 AM, Bill Strahm wrote:
Anyhow, it has to be an iPad app, rather than iPhone/iPod-touch,
because the smaller devices can't display 80-char-66-line ASCII
properly. -T
Just thinking what would happen if someone were to propose a Windows 7 app
for the IETF.
Maybe it's just me, but I couldn't find any files there.
On Mar 25, 2010, at 12:03 AM, Stefan Santesson wrote:
Actually, there seems to be one here:
http://sourceforge.net/projects/rfc2xml/
Not sure how much of a good work it does.
/Stefan
On 10-03-24 5:10 PM, Julian Reschke
On Mar 25, 2010, at 3:07 AM, Spencer Dawkins wrote:
So a month ago, I was wondering about something like
one day pass: $300
two day pass: $500
all week pass: $645 or whatever I paid this time
We might (in some cases, please see below for details) want to give some
people a break
The corporate name on my nametag is there only because I filled that field in
the registration form. Others haven't and don't have a corporation name.
Besides, the corporation name is there not because Check Point has bought the
IETF, but so that if I say that everyone should use a firewall,
Agree. This was just in response to the IETF is bought message.
This disclosure in important for identifying bias, I think.
On Mar 23, 2010, at 11:03 AM, todd glassey wrote:
On 3/23/2010 10:20 AM, Donald Eastlake wrote:
On Tue, Mar 23, 2010 at 12:57 PM, Yoav Nir y...@checkpoint.com wrote
And thank you for taking the time, Rod.
The linktionary has a pretty good definition, though I don't know if it counts
as textbook. Same for Wikipedia
http://www.linktionary.com/f/fault_tolerance.html
http://en.wikipedia.org/wiki/Fault-tolerant_system
Anyway, we need to limit the scope of this
On Mar 23, 2010, at 2:31 PM, Melinda Shore wrote:
On Tue, March 23, 2010 1:20 pm, Yoav Nir wrote:
- For the cluster with just one member doing IKE and IPsec, I propose
hot-standby cluster
- For the cluster with several members doing IKE and IPsec, I propose to
keep load-sharing cluster
I
On Mar 23, 2010, at 6:05 PM, Dan Harkins wrote:
Hi,
hot standby implies a box sitting (hot) twiddling its thumbs doing
little but waiting for another box to fail (standby). It's the VRRP
model.
And that's exactly what I want to describe. Well, not twiddling its thumbs. The
standby is
On Mar 22, 2010, at 11:18 AM, black_da...@emc.com black_da...@emc.com wrote:
Summarizing what I said in the meeting:
(1) The performance criteria should include performance with large complex
secrets (e.g., pre-shared keys), not just the smaller passwords that people
can reasonably be
That would be good, but we don't want to madate not using certain modes of
operation when you have a cluster. That would be very counter-productive.
OTOH, because of the replay counter, we've already agreed that an outbound
child SA cannot be shared among members of a load-sharing cluster.
As
It sometimes bugs me that spelling my name in Latin letters like in this email,
does not give English speakers enough information to pronounce my name
correctly.
In fact, I don't think there's any sequence of Latin letters that will do it.
Still, I don't think putting יואב ניר in the author
Without paper, I don't see the point of pagination.
On Mar 20, 2010, at 11:28 AM, Tim Bray wrote:
So you would argue that RFCs should normally be used in paper form? This is the
only way I can see to avoid requiring internet access.
This idea seems sane to me. Given the current policy, the
To me it’s pretty obviously the former, although the latter is also true.
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Keith
Welter
Sent: Monday, March 08, 2010 6:18 PM
To: ipsec@ietf.org
Subject: [IPsec] IETFLC comments for
Explaining a joke spoils all the fun, but here goes:
It's not like PKI is working out better for user authentication.
And password-in-https-form is also vulnerable to online dictionary attacks.
Now if they were using TLS-EAP
But that, of course, suffers from excessive layering.
Yes, you can sort-of negotiate DH groups, but you don't have the New Group
Mode that we had in section 5.6 or RFC 2409.
So with RFC 4306, you're stuck with only those groups that appear in the IANA
registry, rather than your own pet DH groups.
On Mar 2, 2010, at 10:49 PM, Yaron Sheffer wrote:
Paragraph 5 of section #2:
MUST accept any length that results in proper alignment. It should
be noticed that the ESP [RFC4303] Encrypted Payload requires
Please change noticed to noted.
Other than that, the document looks good enough for implementation.
-Original Message-
From:
Hi folks.
5 issues got lost in the system (they were tagged wrong). Hopefully these are
really the last 5.
Issue #132 - Should NO_ADDITIONAL_SAS cover rekeying IKE SAs?
=
In section 1.3 at the end there is text talking about the
On Feb 22, 2010, at 5:48 PM, Stephen Kent wrote:
At 7:22 PM +0530 2/22/10, Syed Ajim Hussain wrote:
Hi Steve
According to me IPSEC/IKE should have intelligence by by-pass ND Traffic
when SA is not ready state without end-user intervention, and same
should be accepted by other
On Feb 19, 2010, at 6:30 AM, Syed Ajim Hussain wrote:
Hi Yoav Nir All Group Member
Thanks for your quick response. I think, instead of user takes special
care by adding extra Rule to allow un-encrypted ND traffic(unicast) ,
There should be some RFC guidelines, such that IPSEC/IKE
Hi, Syed Ajim.
In future please expand acronyms, because while it's safe to assume that anyone
reading this list knows what an SA is, not all of us are proficient in IPv6
terminology.
Having said that, policies usually have exceptions for protocols, that need to
run in the clear. IKE is an
Hi Rahul.
I don’t have a link, but common sense says that there are four things to
consider when choosing algorithms:
- required strength - for example DES is only 56 bits.
- compliance - certain industries have regulations specifying which algorithms
to use.
- performance - of all the
Hi all.
Wer'e down to single digits with the open issues on IKEv2bis. Here are 5 more.
Issue #168 - Identifier field in the EAP payload
3.16: the text here, ...this field MAY be set to any value implies that the
Identifier field can be constant,
Hi all.
Again we have some more issues:
Issue #147 - Allowing limited retransmission of one-way IKE messages
Either in 2.1 or in 1.5 we should say something about allowing limited
retransmission of the rare one-way IKE
Hi.
This is an interesting subject, and perhaps could be a good candidate for
discussion at Anaheim. However, from the narrow perspective of a VPN vendor, I
don't think this issue is very complicated:
- In the first IKE_AUTH request the initiator provides *an* identity. This
could be
Hi. Another week, another 5 issues to discuss.
Issue #159 - Payload processing order within messages
=
(3.1) Clarify that the text:
Payloads are processed in the order in which
they appear in an IKE message by invoking
do need the
user identity.
-Original Message-
From: Alper Yegin [mailto:alper.ye...@yegin.org]
Sent: Thursday, February 04, 2010 3:40 PM
To: Yoav Nir; 'Raj Singh'; Yaron Sheffer
Cc: 'ipsec'
Subject: RE: [IPsec] Fwd: Issue : Regarding EAP identity
Hello,
Why would the IKEv2 responder
1101 - 1200 of 1331 matches
Mail list logo
