Hi Prashant,
As per RFC 5996, Initiator sending AUTHENTICATION_FAILED would be sufficient
in case of peer's authentication failure:
Sec. 2.21.2 Error Handling in IKE_AUTH
...
If the error occurs on the initiator, the notification MAY be
returned in a separate INFORMATIONAL exchange, usually wit
Hi Group,
What is the expected behavior if as a responder we do not receive TSi and
TSr in IKE_AUTH exchange ?
Shall we go ahead and establish IKEv2 SA ? If yes, shall we send out TSi and
TSr ?
Or we should reject the packet ?
If we reject the packet during packet validation with doing ID and AUTH
TAX. This would
> require the message ID and the checksum to be valid. Note that this has (may
> only) be sent in an encrypted response.
>
> Please correct me if I am wrong.
>
> Regards,
> Matt
>
>
>> 2009/4/22 raj singh
>>
>>> Hi Group,
>>>
>&
ated and encrypted INVALID_SYNTAX notification over
> the IKE_SA that has just been authenticated seems to be correct.
>
> Regards,
> Matt
>
>
>>
>> 2009/4/22 raj singh
>>
>>> Hi Matt,
>>>
>>> There is possibility of just IKEv2 SA ge
stion 2, the text refers to a child SA creation that failed, not
> to one that was never attempted.
>
> Of course it is possible to generate that effect - propose non-existant
> cryptographic algorithms, or IPv7 addresses in the selectors, but that IMO
> is a misuse of the protocol.
>
ply. This is needed as
> INVALID_SYNTAX is authenticated and encrypted.
>
>
> Regards,
> Matt
>
> 2009/4/22 raj singh
>
>> Hi Matt/Youv,
>>
>> Thanks for your reply.
>> I will conclude as IKE_AUTH exchange MUST have TSi and TSr payload. We
>&
Hi Tero,
It make sense.
The same point i want to make, if we as a responder are not going to process
the packet,
there is NO need to add IDr and AUTH with INVALID_SYNTAX during IKE_AUTH.
Regards,
Raj
On Wed, Apr 22, 2009 at 4:43 PM, Tero Kivinen wrote:
> Matthew Cini Sarreo writes:
> > You sti
Hi Matt,
I agree with Jeff.
Sending INVALID_SYNTAX notify with no payload and immediately delete IKEv2
SA will be good idea in case of malformed IKE_AUTH request.
As SA is still unauthenticated, sending DELETE notify will cause another
problems.
Thanks,
Raj
On Thu, Apr 23, 2009 at 2:04 AM, J.
Hi Yoav,
If check for mandatory payloads per exchange type is MUST, if it fails we
MUST return INVALID_SYNTAX, why we are not saying it explicitly in the draft
? Putting it clearly in the draft make more sense and avoids many
confusions.
Thanks,
Raj
On Wed, May 6, 2009 at 7:24 PM, Yoav Nir wro
Hi Team,
One more question.
The INVALID_SYNTAX notify in response to missing payload in IKE_AUTH should
be send encrypted using DH keys or unencrypted ?
Thanks,
raj
On Fri, May 15, 2009 at 10:12 AM, raj singh wrote:
> Hi Yoav,
>
> If check for mandatory payloads per exchange type is
Hi Anil,
Please find my reply inline.
On Tue, May 19, 2009 at 10:55 AM, Anil Maguluri <
anil.magul...@lntinfotech.com> wrote:
>
> Hi All,
>
> I would like to know what are the different certificates to support in
> IKEv2?
raj> The most commonly supported certificate forms are:
http://tools.ie
ndatory to develop VPN based PKI system?
>
> Regards,
> Anil Kumar Maguluri
>
>
>
>
> *Raj Singh *
>
> 05/19/2009 11:28 AM
> To
> Anil Maguluri
> cc
> ipsec@ietf.org Subject
> Re: [IPsec] IKEv2 Certificate Information
>
>
>
>
> H
Hi Yoav,
1. In section5, why we need N[ADDITIONAL_TS_POSSIBLE] when we want to create
child sa?
2. Also, please mention clearly in draft that what should be the behavior of
responder if a faulty initiator sends modified IKE_AUTH request, even if
responder has not send IKE_AUTH_NO_CHILD VID payload
Hi Emre,
IKE SA is bi-directional i.e. one SA is used in both directions, initiator
to responder and responder to initiator.
CHILD_SAs i.e. IPsec SAs (AH, ESP) are uni-directional, one in each
direction. So we 2 IPsec SAs per connection.
Thanks,
Raj
On Fri, May 22, 2009 at 7:41 PM, Gunduzhan, Em
Hi Yoav,
On Sun, May 24, 2009 at 3:38 PM, Yoav Nir wrote:
> 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. T
Hi Emre,
On Tue, May 26, 2009 at 6:38 PM, Gunduzhan, Emre
wrote:
> Steve,
>
> Thanks for the clarification. So, at the end of the initial IKE_AUTH
> exchange, there will (typically) be a pair of CHILD SAs created, one in each
> direction, is this correct?
>
Yes.
> That is, you never create a
Hi Vijay,
I have some question on ikev2-redirect-10 draft.
In section 5,
--
Once the client sends an acknowledgment to the gateway, it SHOULD
delete the existing security associations with the old gateway by
sending an Informational message with a DELETE payload. The gateway
MAY
Hi Vijay,
On Thu, May 28, 2009 at 3:24 AM, Vijay Devarapalli wrote:
> Hi,
>
> On 5/26/09 10:10 PM, "Raj Singh" wrote:
>
> > Hi Vijay,
> >
> > I have some question on ikev2-redirect-10 draft.
> >
> > In section 5,
> > --
> >
A gentle reminder.
On Thu, May 28, 2009 at 8:37 AM, Raj Singh wrote:
> Hi Vijay,
>
> On Thu, May 28, 2009 at 3:24 AM, Vijay Devarapalli wrote:
>
>> Hi,
>>
>> On 5/26/09 10:10 PM, "Raj Singh" wrote:
>>
>> > Hi Vijay,
>> >
>> &
Hi Team,
I agree with Pasi.
Regards,
Raj
On Fri, Jun 5, 2009 at 5:12 PM, wrote:
> Vijay Devarapalli wrote:
>
> > > And having these two cases is more complex than having just one
> > > (IKE_SA is not used for any more exchanges). What benefits does
> > > this additional complexity (both in spe
Hi Yoav,
Please find my inputs:
1. In section 3:
.
A supporting responder that advertised the VID payload in the
IKE_INIT response MUST process a modified IKE_AUTH request, and MUST
reply with a modified IKE_AUTH response. Such a responder MUST NOT
reply with a modified IKE_AUT
Hi Yoav,
On Thu, Jun 18, 2009 at 11:24 AM, Raj Singh wrote:
> Hi Yoav,
>
> Please find my inputs:
>
> 1. In section 3:
>
> .
>
>A supporting responder that advertised the VID payload in the
>IKE_INIT response MUST process a modified IKE_AUTH request
Hi Padam,
It possible and avoidable by configuring a policy on client for MAX no. of
REDIRECTs.
Draft has a mention of this scenario in Section 10.
With Regards,
Raj
On Wed, Jul 1, 2009 at 4:24 PM, Padmakumar AV wrote:
> Hi Vijay,
>
> I have a doubt regarding the usage of redirect during INIT
r to a victim or another node or do continuous
> redirects. I don't understand how the spokes resolve this problem by having
> a policy at the spoke side to restrict the maximum number of redirects as
> its final plan is to connect to a hub.
>
> Thanks
> Padmakumar
>
&g
Hi Team,
I think we can have Introduction and IKE Protocol View [today's Sec.
1.2-1.5] as Section 1 and move Usage scenario to IKE Protocol Details and
Variations.
Usage scenario can make more sense after brief protocol description and it's
difference with IKEv1.
Regards,
Raj
On Thu, Jul 2, 2009
Hi Yoav,
Mostly the Initiator will decide that it wants to bring UP only IKE SA
without child SA.
But currently there is no notify/VID from Initiator to Responder to indicate
that initiator wants to bring only IKE SA. Even if responder does not
supports "childless IKE_AUTH", it will process IKE_SA
ks,
>
> Yaron
>
>
> ------
>
> *From:* ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] *On Behalf
> Of *Raj Singh
> *Sent:* Friday, July 03, 2009 16:51
> *To:* Yoav Nir
> *Cc:* ipsec@ietf.org
> *Subject:* Re: [IPsec] FW: I-D
;
> Thanks,
>
> Yaron
>
>
> --
>
> *From:* Raj Singh [mailto:rsjen...@gmail.com]
> *Sent:* Saturday, July 04, 2009 13:37
> *To:* Yaron Sheffer
> *Cc:* Yoav Nir; ipsec@ietf.org
>
> *Subject:* Re: [IPsec] FW: I-D Action:draft-nir-ipsecme-childless-00.txt
>
>
>
work at initiator and responder. Its can see goodness in idea.
When initiator has dummy proposal ready, the initiator need not to send
childless notify/VID payload.
>
>
>
> From: Raj Singh [rsjen...@gmail.com]
> Sent: Friday, July 03, 2009 16:51
> To: Yoav Ni
Hi Tero,
Thanks for your valuable inputs.
Please find re inputs inline.
On Wed, Jul 8, 2009 at 1:00 AM, Tero Kivinen wrote:
> Raj Singh writes:
> > Your suggestion of having "critical" bit set on childless notify/VID
> payload
> > from initiator in IKE_SA_I
>
>
> Alternatively, we could adopt Yaron’s suggestion, and make a new payload,
> with a critical bit turned on or off according to requirement level. I don’t
> like having empty payloads, but I can’t back up this dislike with any good
> argument.
>
>
>
> Maybe when
> > and whether subsequent child SAs should be permitted. This does still
> have
> > a problem where the initiator requires that the IKE_AUTH be childless and
> > the responder does not support the extension.
> >
> > Alternatively, we could adopt Yaron's sugge
Hi Group,
According to IKEv2bis-04, section 2.3
-
An IKE endpoint MUST NOT exceed the peer's stated window size for
transmitted IKE requests. In other words, if the responder stated
its window size is N, then when the initiator needs to make a re
ally not happen in the
> above scenario, because once the network is back, the responder will also
> reply to #17.
>
>
>
> Hope this helps
>
>
> --
>
> *From:* ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] *On Behalf
> Of *Ra
Hi Group,
I have question regarding security considerations with NAT-T scenario in
IKEv2.
According to ikev2-bis-04, section 2.23
---
There are cases where a NAT box decides to remove mappings that
are still alive (for examp
Hi Tero,
On Thu, Jul 30, 2009 at 2:16 PM, Tero Kivinen wrote:
> Raj Singh writes:
> > 1. Initiator is behind N(P)AT and float the port to (4500, 4500)
> >
> > and send IKE_AUTH with source port 4500 now N(P)AT changes source port
> > as 1024 but there is a man-in
Hi Yaron,
Also, there are use cases when application needs more than 1 IP address for
internal purpose.
With current ikev2bis, this is possible as we can request address after
session establishment using CP[CFG_REQUEST] in INFORMATIONAL exchange.
If we say that we want to support in ONLY IKE_AUTH
needs more than 1 IP
> address?
>
> Yoav
>
> On Aug 26, 2009, at 6:08 AM, Raj Singh wrote:
>
> Hi Yaron,
>
> Also, there are use cases when application needs more than 1 IP address for
> internal purpose.
> With current ikev2bis, this is possible as we can reques
Hi Bhasker,
This document will help you:
http://www.ipsec-howto.org/ipsec-howto.pdf
*It has sample configs for racoon.
*Thanks & Regards,
Raj
On Thu, Aug 27, 2009 at 6:53 PM, Bhaskar Dutta wrote:
> On Thu, Aug 27, 2009 at 5:43 PM, Tero Kivinen wrote:
> >
> > Bhaskar Dutta writes:
> > > Does
Hi Keith,
It has been already discussed on the list that each exchange has some
mandatory payload types.
Firstly, the exchange packet should be checked that it contains all
mandatory payload for that exchnage
then it should check each payload before actually processing the packet.
In your example
; Regards,
Raj
On Sun, Sep 6, 2009 at 6:39 AM, Raj Singh wrote:
> Hi Keith,
>
> It has been already discussed on the list that each exchange has some
> mandatory payload types.
> Firstly, the exchange packet should be checked that it contains all
> mandatory payload for that exch
Hi David,
On Thu, Sep 17, 2009 at 8:03 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 b
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 deletion of the SA.
Also, if policy is found based on EAP
Hi Team,
According to me, High Availability needs protocol level support from IKEv2
due to windowing and sequence numbers in IPsec.
This will enhance performance and avoid proprietary versions of different
vendors. Here we can discuss various problem and solution of IPsec and HA,
which surely need
Hi Team,
According to me, we need to support this draft as WG item as it appears to
enhance the failure detection time.
Currently, there are many scenarios, in which we detect and delete stale SA
only by max. re-transmits.
I would like to review this draft.
Regards,
Raj
2009/11/29 Yaron Sheffer
Hi Alper,
On Fri, Dec 18, 2009 at 5:19 AM, Alper Yegin wrote:
> Hi,
>
> I'm hoping by now it is understood that "childless IKE SA" is just a
> technical detail of what is really on the table. The proposal on the table
> is "designing a network access authentication protocol based on IKEv2".
> T
Hi Syed,
On Mon, Dec 28, 2009 at 5:51 PM, Syed Ajim Hussain wrote:
>
>
> Hi All
>I have some doubt about NAT With IPSEC/IKE ,
>
> Example Take a Topology :
>
> IKE_PEER1 --- NAT1 NAT2 Server---IKE_PEER3
> (1.1.1.1) | (1.1.1.10) (2.1.1.1) (2.1.1.2) (
*
*
*
*
Section 1.2. The Initial Exchanges
Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
exchanges (known in IKEv1 as Phase 1). These initial exchanges
normally consist of four messages, though in some scenarios that
number can grow. All communications using
Hi Team,
I agree with Tero explanation and Valery objection as well.
There is discrepancy between 3.5 and 4.
1. Section 4 mandates certificates but section 3.5 doesn't.
2. Its seen in practice that some implementation uses IP addresses as
default ID even though they are
using certificate based aut
On Fri, Jan 22, 2010 at 5:15 PM, Tero Kivinen wrote:
>
> Raj Singh writes:
> > I agree with Tero explanation and Valery objection as well.
> > There is discrepancy between 3.5 and 4.
>
> Not really. Not all requirements needs to be in one place. One place
> can s
Hi Paul,
A system can detect NAT mapping removal from CHANGED source port from
authenticated IKE PACKET.
A system can detect NAT mapping removal from CHANGED source port of
UDP encapsulated packet from authenticated IPsec PACKET.
Also, system knows in process of NAT detection, where it is behind
I support this change.
On Wed, Feb 3, 2010 at 4:22 AM, Dan McDonald wrote:
> On Tue, Feb 02, 2010 at 02:49:11PM -0800, Paul Hoffman wrote:
>> In a few places in the new section 2.23.1 in IKEv2bis, it says that one
>> must have a trigger packet when starting negotiation. This assumption
>> should
Hi Paul, Ticket Issue#174 opened for it. Regards, Raj
-- Forwarded message --
From: Paul Hoffman
Date: Wed, Feb 3, 2010 at 9:41 AM
Subject: Re: Issue : Regarding EAP identity
To: Raj Singh
Cc: Yaron Sheffer
At 9:09 AM +0530 2/3/10, Raj Singh wrote:
Hi Paul,
In ikev2bis07
P-GTC, there’s no need for a separate
> “authenticated identity”. In these cases the IKE responder should simply use
> the original IDi for policy lookup.
>
>
>
> Thanks,
>
> Yaron
>
>
>
> *From:* ipsec-boun...@ietf.org [mailto:ipsec-boun..
;
> Unless there is a single policy for all authenticated users, you 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 Sheff
in a position to see that but our shared friend here
> can vouch for me." How do you think that's gonna fly? Not too well, I'd
> imagine.
>
> On a lighter note: It will be like flying without passport. :-)
With Regards,
Raj
> regards,
>
> Dan.
>
> On Thu,
Hi Paul,
One clear change is that updating the address, port info is changed from
authenticated packet
to integrity protected packet.
Does this change is to allow recovery from NAT mapping removal during
establishment of IKEv2 SA
e.g. with EAP authentication, during retransmission of IKE_AUTH exch
Hi Team,
When IRAC requests an internal address from IRAS.
Now IRAS gets the address for IRAC and applies some local policies and
fails.
In this case which notify is it should send INTERNAL_ADDRESS_FAILURE or
generic NO_PROPOSAL_CHOSEN?
IKEv2 SA comes up in both cases.
Please provide your views.
2010/2/8 Tero Kivinen
> Raj Singh writes:
> > One clear change is that updating the address, port info is changed from
> > authenticated packet
> > to integrity protected packet.
>
> In this case that does not really matter.
>
> > Does this change is to all
>
>
> >
> > regards,
> >
> > Dan.
> >
> > On Tue, February 9, 2010 2:53 am, Alper Yegin wrote:
> > > Dan,
> > >
> > > I'm not aware of any such document.
> > >
> > > Alper
> > >
> > >
&
Hi Yoav,
On Fri, Feb 19, 2010 at 3:22 AM, Yoav Nir wrote:
> Hi all.
>
> There are only three issues this time, because this is the last batch.
>
> Issue #173 - Trigger packets should not be required
> ===
> In a few places in the new section 2.23.1
Hi Sean,
Section 5. IANA Considerations can be reworded in-line with ikev2bis.
5. IANA Considerations
IANA has already registered the type and value for AES-CTR.
Name Number Defined In
ENCR_AES_CTR 13 (RFC3686 <
+1
I agree with Dan.
On Wed, Mar 24, 2010 at 1:16 PM, Dan Harkins wrote:
>
> On Tue, March 23, 2010 7:24 pm, Yoav Nir wrote:
> >
> > On Mar 23, 2010, at 6:05 PM, Dan Harkins wrote:
> >
> >>
> >> Hi,
> >>
> >> "hot standby" implies a box sitting ("hot") twiddling its thumbs doing
> >> little bu
Hi Team,
The similar scenarios are beautifully handled by Redirect RFC-5685.
The Redirect RFC emphasize on client-gateway terminology, which is typical
use of Redirect mechanism in IKEv2 where Gateway redirects client to another
less loaded gateway but at the same time RFC is also applicable to
ro
re right in ignoring this case. I'm saying that
> you can only get the protocol that you want if you define the requirements
> clearly up front.
>
> Thanks,
>Yaron
>
>
> On 29.3.2010 16:58, Raj Singh wrote:
>
>> Hi Team,
>>
>> The similar
Hi Jaemin,
If initiator narrows down the TSr, then
1. the responder is not aware of initiator has narrowed down TSr and if it
initiates a traffic which is from a broader section of range which Initiator
has not accepted, there will data black-hole.
2. I think, better solution will be, If initiator
t; to the difference of protocol ID and violation of the intended policy.
>
> Can initiator remove the above case and follow the RFC?
>
> I'm looking forward to the experts' responses.
>
> Thanks in advance.
>
> From My iPhone
>
> 2010. 6. 20. 오후 2:36 Raj Singh 작성
hat we can discuss this draft with more details in Maastricht meeting.
Regards,
Raj Singh
On Fri, Jun 18, 2010 at 11:56 AM, Yaron Sheffer wrote:
> Hi,
>
> As promised, we have started a design team on IPsec HA. Paul and I have
> asked Raj Singh to lead the team. His job is to make sure
he draft as soon as submission window re-opens.
Please read the draft and give you comments before Maastricht meeting.
Regards,
Raj
On Sun, Jul 11, 2010 at 4:39 PM, Raj Singh wrote:
> Hi Group,
>
> We would like to present the HA design team's output for IPsec Cluster
> Solutio
On Sun, Sep 5, 2010 at 11:56 AM, Yoav Nir wrote:
>
> 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 mes
Hi Pekka,
Thanks for your comments. Please find my reply inline.
Best Regards,
Raj
On Mon, Sep 6, 2010 at 11:13 AM, Pekka Riikonen wrote:
>
> From the draft:
>
> There were some concerns about the current window sync process. The
> concern was to make IKEv2 window sync optional but we b
Hi Yaron,
Thanks for comments. We will address them in next version.
On Thu, Oct 14, 2010 at 2:27 PM, Yaron Sheffer wrote:
> Hi,
>
> the new draft is a good realization of our discussions since the previous
> version. Please see a few comments below. My main point is that if you
> choose to impl
Hi Tero,
Thanks for the comments.
Opened Ticket #204 for format error in notification payload.
Regarding the second issue. Some clarification is needed:
The text meant that the message containing IKEV2_MESSAGE_ID_SYNC
notification is allowed with message id zero only.
This doesn't mean that messa
Hi Yaron,
Thanks for the comments, Ticket#205 create to track this.
On Thu, Nov 11, 2010 at 8:46 PM, Yaron Sheffer wrote:
> Hi,
>
> it seems to me we have created an overly complicated solution for replay
> protection of the Msg ID = 0 messages. Specifically, I think both the
> failover counter
74 matches
Mail list logo
