Hi Matt
Requests and responses have matching MsgID numbers. The requestor can instantly
identify the response by its matching Msg ID number. INFORMATIONAL exchanges
have message authentication codes applied to messages, so the ID numbers can't
(or shouldn't) get "messed up" on the responsder.
The traffic selectors in the REKEY exchange are not currently specified. If
were designing IKEv2 from scratch, I would be in favor of removing traffic
selectors altogether from REKEY exchanges - I don't think it should be called a
"rekey" if you get a totally different SA. This does raise the
I prefer the second proposal. I would rather have one (even if longer)
variation of the protocol over two variations (even if one is shorter)
With such a possible attack published, auditors are going to force large
installations to use the safer (and longer) version anyway, as it is up to the
I see that in section 6 the following:
In such cases, the gateway should send the REDIRECT notification
payload in the final IKE_AUTH response message that carries the AUTH
payload and the traffic selectors. The gateway MUST NOT send and the
client MUST NOT accept a redirect in an ear
Vijay Devarapalli wrote:
>
> Hello,
>
> Yoav Nir wrote:
> > I see that in section 6 the following:
> >
> >In such cases, the gateway should send the REDIRECT notification
> >payload in the final IKE_AUTH response message that carries the AUTH
> >
Devarapalli wrote:
> Hi,
>
> On 4/18/09 11:16 AM, "Yoav Nir" wrote:
>
> > Vijay Devarapalli wrote:
> >>
> >> Hello,
> >>
> >> Yoav Nir wrote:
> >>> I see that in section 6 the following:
> >>>
> >&g
Hi Matt.
You can't initiate INFORMATIONAL exchanges before the IKE_AUTH exchange(s)
concluded successfully.
Section 2.3 prohibits sending INVALID_MESSAGE_ID in responses, so you don't use
that for the IKE_AUTH exchange.
If the IKE_AUTH exchange contains invalid message IDs, these requests MUS
So are we working with the assumption that the gateway (or the AAA server) can
always authenticate any user that connects?
> -Original Message-
> From: Yaron Sheffer
> Sent: Monday, April 20, 2009 10:43 AM
> To: Yoav Nir; Vijay Devarapalli
> Cc: IPsecme WG
> Subje
Hi Raj
Matt is correct. There is no way in IKEv2 to do a phase1-only exchange, and
then wait for traffic to establish the child SAs.
While we do establish an IKE SA if the piggy-backed child SA failed for
whatever reason (bad selectors, no proposal chosen), we don't allow for an
IKE_AUTH excha
I agree with Tero
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron
Sheffer
Sent: Monday, April 27, 2009 10:32 PM
To: IPsecme WG
Subject: [IPsec] Issue #13: INVALID_MAJOR_VESION similar to other notifies
being discussed
> {{ Cla
I don't think we should really prohibit such extensions and enhancements. It's
just that IKE will fail if you try it with a peer that does not support it.
As far as the end-user is concerned, this is not different from an
UNSUPPORTED_CRITICAL_PAYLOAD in IKE_AUTH. Either way, the tunnel setup f
+1
Paso.Eronen wrote:
>
> Yaron Sheffer wrote:
>
> > [Sec. 3.15.1:]
> >
> > Tero:
> >
> > The text 'The requested address is valid until there are no IKE_SAs
> > between the peers.' is incorrect, it most likely should say 'The
> > requested address is valid as long as this IKE SA (or its reke
Grewal, Ken wrote:
>
> Issue #90: shorter WESP negotiation
>
> In the current traffic visibility draft, we indicate that WESP can be
> negotiated via IKEv2 using a new protocol identifier.
> Charlie Kaufman suggested that it may be plausible to use a notification
> method along the lines of USE_TR
Michael Richardson wrote:
> Yoav Nir wrote:
> > Hi Raj
> >
> > Matt is correct. There is no way in IKEv2 to do a phase1-only
> > exchange, and then wait for traffic to establish the child SAs.
> >
> > While we do establish an IKE SA if the piggy-backed c
Hi Michael
> Let me suggest a situation where perhaps I would like to
> bring up an IKE_SA and not a CHILD_SA: it might be for just
> sending initial contact, and perhaps even a DELETE.
>
> I sometimes move quickly from being "outside" my IPsec
> gateway/firewall (such as being on wireless),
Hi all
I've submitted issue #107 about certificate encoding.
IMO it's not clear how certificate chains are to be encoded in IKEv2.
http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/107
Yoav
Email secured by Check Point
___
IPsec mailing list
IPsec@ie
Paul Hoffman wrote:
>
> At 2:08 PM +0300 5/10/09, Yoav Nir wrote:
> >Hi all
> >
> >I've submitted issue #107 about certificate encoding.
> >
> >IMO it's not clear how certificate chains are to be encoded in IKEv2.
> >
> >http://trac.tools
Paul Hoffman wrote:
>
> At 12:53 AM +0300 5/11/09, Yoav Nir wrote:
> >Paul Hoffman wrote:
> >>
> >> At 2:08 PM +0300 5/10/09, Yoav Nir wrote:
> >> >Hi all
> >> >
> >> >I've submitted issue #107 about certificate encoding.
>
Pasi.Eronen wrote:
>
> Yoav Nir wrote:
> > > You can:
> > >
> > > a) start using hash-and-url
> > >
> > > b) hope your peer has the sub-CA
> > >
> > > c) write an extension to 4306 that allows bundles in CERT
> > &g
WARNING: contains banned part
--- Begin Message ---
On Tue, 2009-05-12 at 10:05 +, ss murthy nittala wrote:
> Hi
>
> Thanks for the clarifications regarding IV usage for AES methods.
>
> RFC 2405 (DES) in its implementation note says
>
> "Common practice is to use random data for the first I
Paul Hoffman wrote:
>
> At 8:56 PM +0800 5/13/09, Hui Deng wrote:
> >Dear IPsec forks,
> >
> >May I consult one question here:
> >
> >Whether we could still do IKEv2 negotiation
> (Authenticaiton), but not
> >use IPsec tunnel?
>
> You never need to use a tunnel, regardless of how it was
> brou
Scott C Moonen wrote:
>
> I'm reviewing RFC 4869 and it seems to under-specify the attributes that
> are needed to achieve real interoperability: it doesn't specify whether to
> do a phase 2 Diffie-Hellman exchange for perfect forward secrecy, nor
> does it specify IKEv1 lifetime and lifesize val
Paul Hoffman wrote:
>
> >IOW it's up to the initiator whether or not to do PFS, and both
> >configurations are OK to use the suite name.
>
> That was my intention in RFC 4308; I cannot speak for the
> authors of RFC 4869.
You can't speak for them, but Scott has to figure it out.
> >As for lif
Hi all
I've just noticed that section 3.12 of the bis draft has the following text:
Writers of Internet-Drafts who wish to extend this protocol MUST
define a Vendor ID payload to announce the ability to implement the
extension in the Internet-Draft. It is expected that Internet-Drafts
WARNING: contains banned part
--- Begin Message ---
桔牥❥潮桴湩潴瀠敲敶瑮愠挠湯汦捩ⱴ戠瑵琠慨⁴敳瑣潩灳捥晩捩污祬爊晥牥潴∠牗瑩牥景䤠瑮牥敮牤晡獴⸢䰠潯楫杮琠牨畯桧琠敨䤠瑮牥敮ੴ牄晡獴琠慨⁴硥整摮䤠䕋㉶潮敮猠祡猠浯瑥楨杮氠歩ⱥ∠獵潮楴楦慣楴湯琊灹㜱㔬㘴湡灳捥晩⁹畳灰牯⁴楷桴嘠䑉瘠污敵攊戱㜵慡㔴〷㈲㈵愶戶㐴〳摢昲ち〱∱ਊ桔祥愠汬樠獵⁴慨敶愠渠瑯晩捩瑡潩慰汹慯楷桴琠灹吢䅂戠⁹䅉䅎•湡桷瑡癥牥琠敨⁹潤映牯椠瑮牥灯琠獥獴漠潦捡畴污椠瑮牥灯椠桴楦汥敲慭湩湵灳捥晩敩ਊ潓眠桳畯摬攠瑩敨湥潣牵条瑳晵楬敫琠
tion? Note that we never required private notification
numbers to be picked at random, so conflict are likely to occur.
Thanks,
Yaron
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Yoav Nir
> Sent: Sunday, May 17, 2009
Hi all
Recently there's been some discussions about creating an IKE SA without child
SAs (on purpose).
I'm still not entirely convinced that this is necessary, but I have submitted
this draft, and would like to hear comments about it. Does it fill the need
that some people on this mailing lis
Hi all
Recently there's been some discussions about creating an IKE SA without child
SAs (on purpose).
I'm still not entirely convinced that this is necessary, but I have submitted
this draft, and would like to hear comments about it. Does it fill the need
that some people on this mailing lis
Hi Raj
On Thursday, May 21, 2009 9:44 PM, Raj Singh wrote:
> Hi Yoav,
>
> 1. In section5, why we need N[ADDITIONAL_TS_POSSIBLE] when we want
> to create child sa?
We don't. That comes from (note careful enough) cut-and-paste. Good catch.
> 2. Also, please mention clearly in draft that w
Hi Raj
> 3. Also, why its a VID payload, Notify suits better. Because a third
> party client will want to connect to some other server. Please give
> justification for IKE_AUTH_NO_CHILD to be a VID.
Section 3.12 of -bis document says "A Vendor ID payload MAY announce that the
sender is capable o
Hi.
I've read through the draft again, and here are a few comments:
Section 3 has the following line:
If the
IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload,
the responder MUST NOT send the REDIRECT payload to the VPN
han by IP address. Such a name could be ASCII or UTF-8.
From: Tero Kivinen [kivi...@iki.fi]
Sent: Wednesday, May 27, 2009 13:02
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: [IPsec] Some comments about redirect
Yoav Nir writes:
> Section 10 sets up an IANA registr
GUI. In any case, the client is as aware of the names as the
gateways.
From: Vijay Devarapalli [vi...@wichorus.com]
Sent: Thursday, May 28, 2009 01:04
To: Yoav Nir; Tero Kivinen
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Some comments about redirect
Hi Yoav
apalli [vi...@wichorus.com]
Sent: Thursday, May 28, 2009 01:02
To: Yoav Nir; ipsec@ietf.org
Subject: Re: [IPsec] Some comments about redirect
Hello,
On 5/27/09 12:36 AM, "Yoav Nir" wrote:
> Hi.
>
> I've read through the draft again, and here are a few comments:
&g
al Message-
From: IETF I-D Submission Tool [mailto:idsubmiss...@ietf.org]
Sent: Sunday, May 31, 2009 6:03 PM
To: Yoav Nir
Subject: New Version Notification for draft-nir-ike-nochild-01
A new version of I-D, draft-nir-ike-nochild-01.txt has been successfuly
submitted by Yoav Nir and posted t
I'm not so sure about that. The authentication in the IKE_AUTH exchange that
follows the resumption only proves that the (new) responder can decipher the
ticket (or has access to the ticket database).
Presumably a "cluster" of gateways backing each other up would have the same
IDr, but if they'
I agree with Yaron that it should be the way it is now described in the draft.
If either side deleted the IKE SA, then it should not come back to life through
session resumption. Specifically, the client should not get reconnected without
authentication. The laptop example is excellent. If I clo
Hi all
version -02 of this private submission draft, with two additional co-authors
and some more use cases.
Enjoy
Yoav
From: i-d-announce-boun...@ietf.org [i-d-announce-boun...@ietf.org] On Behalf
Of internet-dra...@ietf.org [internet-dra...@ietf.org]
Hi.
IMO the CFG payloads are the last place where there will ever be a shortage of
IPv4 addresses. The addresses distributed through CFG payloads in IKEv2 or
through extensions to IKEv1 are almost always non-routable addresses, and even
for extremely large organizations, there are plenty of tho
Hi all.
This is the fourth iteration of this draft. New in this iteration
- Another co-author
- Changed the name, so that this item is considered in the rechartering
discussion
- Fixed some notation and some discussion based on comments from the list
Yoav
ut I'm not
sure that's a good idea.
From: Raj Singh [rsjen...@gmail.com]
Sent: Friday, July 03, 2009 16:51
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
Hi Yoav,
Mostly the Initiator will
Inline with
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Raj
Singh
Sent: Sunday, July 05, 2009 5:02 AM
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
Hi Yoav,
Please find my
, 2009 1:43 PM
To: Yoav Nir; Raj Singh
Cc: ipsec@ietf.org
Subject: RE: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
Hi Yoav/Raj,
I think its a good idea for the initiator to announce its capabilities about
supporting just IKE SA without child SA. The responder will then act
I've read it again, and it seems fine. One minor issue, though.
Section 2 describes the WESP header format. It has the following:
HdrLen, 8 bits: Offset to the beginning of the Payload Data in
octets. The receiver MUST ensure that this field matches with
the header offset computed fro
#x27;t back up this dislike with any good argument.
Maybe when we make version 2.1 of IKE, we can add a "critical type" bit to the
notification payload.
From: Raj Singh [mailto:rsjen...@gmail.com]
Sent: Wednesday, July 08, 2009 7:18 AM
To: Tero Kivinen
Cc:
solvable, because the policies actually
conflict.
From: Gaurav Poothia [mailto:gpoot...@microsoft.com]
Sent: Thursday, July 09, 2009 7:57 AM
To: Yoav Nir; 'Raghunandan P (raghup)'; Raj Singh
Cc: ipsec@ietf.org
Subject: RE: [IPsec] FW: I-D Action:draft-n
Works for me.
From: gabriel montenegro [mailto:g_e_montene...@yahoo.com]
Sent: Monday, July 13, 2009 9:21 PM
To: Yoav Nir; Yaron Sheffer; ipsec@ietf.org
Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-traffic-visibility-05
Brian Swander notes that we should
Hi Raj.
Too many variables, let's assume values without loss of generality.
Suppose N=3, and you have send requests 17, 18 and 19. Because of the network
problems, you got responses for 18 and 19, but not *yet* for 17.
What the draft (and RFC 4306) says, is that you keep retransmitting 17, unti
AM
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: Re: [IPsec] [IKEv2] Questions on windowing in IKEv2
Hi Yoav,
Do you think this behavior contradicts with definition of windowing mentioned
in draft that if responder window is 3, initiator can have 3 outstanding
request ?
Regards,
Raj
On Wed, Jul 22, 20
discard #17. If it was still valid for
the initiator to send request #17 again, the responder would have to retain all
the old responses indefinitely.
From: Amjad Inamdar (amjads) [mailto:amj...@cisco.com]
Sent: Wednesday, July 22, 2009 12:23 PM
To: Yoav Nir; Raj
Hi Vijay.
"default" is usually associated with a particular implementation or product. I
think it would be better to say "suggested value" rather than "default value".
Also, I don't see a point in mandating that all products should have an extra
knob for setting this value. For example, for an
Vijar Devarapalli wrote:
>Hi Yoav,
>
>On 7/29/09 9:13 PM, "Yoav Nir" wrote:
>
>> Hi Vijay.
>>
>> "default" is usually associated with a particular implementation or
>> product. I think it would be better to say "suggested value"
Any "INVALID_IKE_SPI" or "INVALID_SPI" message can trigger DPD (or, as RFC 4306
calls it, "liveness check"). These messages are very easy to spoof.
But liveness check is just one round trip between the peers and it's supposed
to be rate-limited. I don't think an off-path attacker can cause the l
Sorry for the delay.
I believe the draft is in good shape, but I do have some comments.
1. ESN is mentioned as optional for IKEv1 and included in IKEv2. It is not
mentioned that this is an optional feature for IPsec (both old and new)
2. Section 4.2.1 describes RFC 4478 (authentication lifetime
Hi Raj.
The issue is concerned with Config payload in Child SA only. Config in
INFORMATIONAL will stay, or at least, there is no current proposal to remove it.
It can be useful for querying the application version, which is still a defined
attribute for CP.
Can you elaborate on the cases where
e_Child SA exchange
On Aug 26, 2009, at 10:40 AM, Raj Singh wrote:
Hi Yoav,
These applications are using same IKE SA for allocating IP to the application
specific virtual interfaces, which can be more than one. Let me know if you
further clarification.
Thanks & Regards,
Raj
2009/8/26 Yoa
Good. So how about we close this issue by adding the last sentence
below:
If
multiple certificates are sent, the first certificate MUST contain
the public key used to sign the AUTH payload. The other
certificates
may b
I disagree.
Payloads in a particular CREATE_CHILD_SA exchange should be specifically
related to the SA being created. The IKE_AUTH exchange is different, because
it is used to set up everything we need to get an IPsec SA going.
We do not use the CREATE_CHILD_SA to delete old SAs, to query app
Hello all.
Issue #26 was submitted by Tero Kivinen. It concerns section 2.21
("error handling") and states that several things are missing:
- handling of errors before authentication
- listing what error conditions cause the IKE SA to be deleted entirely
- listing how errors are handled in the
On Sep 1, 2009, at 5:07 PM, Tero Kivinen wrote:
> Yoav Nir writes:
>> Following is our suggested new text. Please let us know what you
>> think. Also, please take a look at the description of
>> "AUTHENTICATION_FAILED" in section 3.10.1. "response to an
Hi Kalyani
Of the two, I prefer the 2nd solution, as it is simpler. Reusing message IDs is
not that bad, and you can decrease the change by including (in the
RESET_MESSAGE_ID notification) a random number as the starting message ID.
What I'm not so sure, is that there is a real problem here th
Yes, I will soften the language a bit, but I won't mention a DELETE payload. If
some implementations do it. others may come to expect it. We don't want to
encourage that by suggesting that it's a good idea.
On Sep 3, 2009, at 11:52 PM, Keith Welter wrote:
>If the error occurs on the
>i
Then I should have explained better.
If an initiator sees an error in the response, the exchange is already over, so
the only way it can notify the responder of the error, is to create a new
INFORMATIONAL exchange with an error notification.
All the text here discusses the one INFORMATIONAL exc
On Sep 4, 2009, at 5:53 PM, David Wierbowski wrote:
>Yes, I will soften the language a bit, but I won't mention a DELETE payload.
>If some implementations do it.
>others may come to expect it. We don't want to encourage that by suggesting
>that it's a good idea.
Yoav, Why is it a a bad idea t
OK. Let's try this again. Is this acceptable?
2.21. Error Handling
There are many kinds of errors that can occur during IKE processing.
If a request is received that is badly formatted, or unacceptable
for
reasons of policy (e.g., no matching cryptographic algorithms), the
resp
On Sep 7, 2009, at 3:48 PM, Tero Kivinen wrote:
> Keith Welter writes:
>> I would not expect INVALID_SYNTAX to cause the IKE SA to be deleted
>> either.
>
> I do consider INVALID_SYNTAX fatal error, meaning the IKE SA will be
> deleted immediately after sending that response containing
> INVALID_
On Sep 7, 2009, at 4:41 PM, Tero Kivinen wrote:
> Yoav Nir writes:
>> OK. Let's try this again. Is this acceptable?
>>
>> 2.21. Error Handling
>>
>>There are many kinds of errors that can occur during IKE
>> processing.
>>If
OK. One more try:
2.21. Error Handling
There are many kinds of errors that can occur during IKE processing.
If a request is received that is badly formatted, or unacceptable
for
reasons of policy (e.g., no matching cryptographic algorithms), the
response MUST contain a Notify p
On Sep 17, 2009, at 5:33 AM, David Wierbowski wrote:
> Section 3.1.5 of RFC 4945 states that when generating an ID type of
> ID_DER_ASN1_DN that "implementations MUST populate the contents of
> ID with the Subject field from the end-entity certificate, and MUST
> do so such that a binary com
a requirement that I think could be relaxed.
Dave Wierbowski
z/OS Comm Server Developer
Phone:
Tie line: 620-4055
External: 607-429-4055
Yoav Nir ---09/17/2009 02:50:34 AM---On Sep 17, 2009, at 5:33 AM,
David Wierbowski wrote: > Section 3.1.5 of RFC 4945 states that when ge
From:
On Sep 17, 2009, at 7:03 PM, Paul Hoffman wrote:
> At 3:51 PM +0300 9/16/09, Tero Kivinen wrote:
>> For example the text could look something like this:
>> --
>
> Yoav, does Tero's proposed new text work for you?
>
> --Paul Hoffm
Hi all
The draft linked below is a problem statement draft about using
IKE&IPsec implementations in high availability and load sharing
configurations.
I will describe this at tomorrows Interim meeting.
Comments are welcome, of course, both on the list and at tomorrow's
session.
Yoav
>
>
I support advancing this document, and I think the explanations and
pseudo code are good.
I do, however, question the value of it in real life.
Security policies or the deep inspection kind usually are something
like:
- allow HTTP and HTTPS, and verify headers
- allow ICMP and DNS
- may
On Sep 24, 2009, at 9:44 PM, Paul Hoffman wrote:
At 12:13 PM -0600 9/24/09, Grewal, Ken wrote:
Proposed change
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Hi Hui
I think there is very little difference between IPv4 and IPv6 as
regards to IPsec. See below
On Oct 11, 2009, at 9:50 AM, Hui Deng wrote:
Dear IPsec forks,
May I get advice about the differnce between them:
1) IPv4 doesn't mandate the support IPsec, IPv6 also doesn't mandate
it base
A few lines above this section it already says "If the responder's
policy allows it to accept the first selector of TSi and TSr, then the
responder MUST narrow the traffic selectors to a subset that includes
the initiator's first choices."
So there is a MUST requirement to select the initia
On Nov 10, 2009, at 1:40 PM, Amjad Inamdar (amjads) wrote:
Hi,
With IKEv2 EAP authentication, there are 3 identities involved
1) IDi - IKEv2 initiator identity sent in msg-3
2) EAP identity that gateway (IKE2 responder) can request from the
client (IKEv2 initiator)
3) Authenticated EAP identi
On Nov 11, 2009, at 3:39 PM, Srinivasu S R S Dhulipala (srinid) wrote:
>
>> 2) If not same, what purpose should each of the above identities serve
>
> 1) mainly used as a hint for the gateway as to which AAA server to
> choose
> 2) It's the AAA server that may request the identity, and it's
in IKE and later in the EAP session.
On Nov 11, 2009, at 4:05 PM, Srinivasu S R S Dhulipala (srinid) wrote:
> Hi Yoav,
>
> Thanks for the quick response. Please see inline.
>
> -Original Message-
> From: Yoav Nir [mailto:y...@checkpoint.com]
> Sent: Wednesday,
Hi
If you're bissing this thing, can we please please please entirely get rid of
the requirement to use ECDSA certificates?
While the algorithms and DH groups are subject to configuration in the UI and
negotiation in IKE, the algorithm used to sign the certificates is outside the
IKE implement
On Nov 12, 2009, at 5:34 AM, Raj Singh wrote:
> The selection of AAA server will be based on IDi then EAP will happen.
> The gateway will get EAP authenticated ID from the AAA server.
> If EAP identity is different from IDi and no policy is found for EAP identity.
> The gateway should initiate de
for ECDSA certs to that list. Definitely not when they're in the
same "list" as VPN-A and VPN-B.
From: Paul Hoffman [paul.hoff...@vpnc.org]
Sent: Friday, November 13, 2009 02:58
To: Yoav Nir; Law, Laurie; ipsec@ietf.org
Subject: Re: [IPsec]
What Dan and Gregory said.
But assuming an unloaded gateway, with "normal" hardware (Any Intel, AMD or
PowerPC processor from the last 10 years or a recent ARM), then even if you use
relatively secure parameters (2048-bit DH group, 2048-bit RSA keys) the round
trip time is going to dominate. Th
+1
Even things that seem obvious like https and ftp require a lot of
considerations, like how to verify the certificate in https, or what identity
to present in ftp.
If someone wants to specify additional URL methods, they can specify then in an
I-D.
On Nov 24, 2009, at 8:24 PM, Paul Hoffman
There were several motivations listed for childless IKE SAs.
- remote access, where you create an IKE SA when the user wants to connect,
and only create child SAs in response to traffic
- authentication only over a physically secure network (not necessarily EAP,
but I think this is the use case
Hi Alper.
The "Do phase 1 first, and phase 2 as traffic demands it" motivation is from
the remote access VPN domain (though may be useful for others).
The "Do only phase 1, because we don't need encryption and MAC, just peer
authentication" motivation is from the 3GPP (though it could be useful
Section 1.4.1 also says:
"A node MAY refuse to accept incoming data on half-closed
connections but MUST NOT unilaterally close them and reuse the SPIs."
So if your peer is only responding with empty INFORMATIONAL responses to your
deletes, you're going to accumulate more and more stale inboun
ng DELETE payloads are an exception to the "you may return
> an empty INFORMATIONAL" rule.
>
> Thanks,
>Yaron
>
>
> From: ipsec-boun...@ietf.org [ipsec-boun...@ietf.org] On Behalf Of Yoav Nir
> [y...@checkpoint.com]
> Se
On Dec 16, 2009, at 6:36 AM, rahul bharadhwaj wrote:
Hi all
Could anyone let me know which crypt algo des/3des/aes should be used with
aes-xcbc-mac hashing.
As aes-xcbc-mac uses aes for authentication and integrity, is it correct to
apply des for encryption or is there any restriction.
Tha
If there is such an implementation, then it's not interoperating with all the
other implementations and should be fixed.
If someone shipped something like that, then the only reason they haven't
noticed yet, is because they (1) didn't test it well enough, and (2) their
customers are using some
On Dec 21, 2009, at 8:54 PM, wrote:
> Dan,
>
>> If we allocate new numbers to do it right then we will, in fact, live
>> forever with an ambiguous interpretation of groups 19, 20, and 21. I
>> agree we should fix the problem and not live with ambiguity. The proposal
>> to allocate new numbers
On Jan 5, 2010, at 12:27 AM, Yaron Sheffer wrote:
> Hi,
>
> We have had a few "discusses" during the IESG review of the WESP draft. To
> help resolve them, we would like to reopen the following two questions to WG
> discussion. Well reasoned answers are certainly appreciated. But plain "yes"
On Jan 7, 2010, at 9:14 AM, Charlie Kaufman wrote:
> Oh sigh!! What is it about IPsec that makes people go down this same path
> every time:
IPsec?
So I guess you haven't been following the TLS mailing list these past couple of
months.
I don't think anyone's described a practical attack on
Hi Scott
When writing remote access VPN clients (running on phones, PCs, tablets,
probably not z/OS) it's usually safe to assume that the peer (a gateway)
supports NAT-T. This is because on the real Internet, a RAS that does not
support NAT-T simply doesn't work. NATs are everywhere.
So it's p
Hi
On Jan 18, 2010, at 12:48 PM, Toshihiko Tamura wrote:
> Hi, I want to ask about simultaneous Child SA rekeying
> at section 2.8.1 in IKEv2bis.
>
> I'm sure it is convenient to support this function,
> but why is current IKEv2bis draft saying this fucntion
> as SHOULD?
> -
+1
Anybody who starts implementing IKEv2 in a few months using the new RFC should
not have to care about the history, and which notify type was added at which
point, except to know that some implementations in the field may not support
these newer notifications.
-Original Message-
From
We can't really prescribe actions for (presumably older) implementations that
don't support this spec.
Such implementations will do what it says in RFC 4306 and the clarifications
document: TEMPORARY_FAILURE is an error notification, so therefore the exchange
failed. In that case the old SA r
Agree. Certainly types 4-6 have to be removed, as they are just methods, and we
RECOMMEND not to use them. I can see some value in mentioning type 1
(Identity), because later in that same section we mention that the responder
should not send such requests. I think we should remove all the rest,
We do have this:
The
responder MAY at any time terminate the IKE exchange by sending an
EAP payload containing the Failure message.
I guess "terminate" means that the initiator does not send any more messages.
This is also on
I think remove. Also the reference to PHOTURIS
On Jan 20, 2010, at 11:01 PM, Paul Hoffman wrote:
> In 2.6, first paragraph: the historical discussion going back to the previous
> century is very confusing to a newcomer: instead of saying what a cookie is,
> we tell a story. I suggest to remove
601 - 700 of 810 matches
Mail list logo
