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.
Matt,
In respect to a Notify ERROR TYPES & the IKE_AUTH response with IDr,
[CERT+] & AUTH payload inclusion, NO_PROPOSAL_CHOSEN,
SINGLE_PAIR_REQUIRED, TS_UNACCEPTABLE and NO_ADDITIONAL_SAS are Notify
ERROR TYPES that would generally still include the IDr, [CERT+] & AUTH
payload in the respon
Hello all,
As IKEv2bis-02 defines in Appendix C, the proper way to notify a requester
that there was an error in creating a Child SA using the IKE_AUTH exchange
is:
error in Child SA <-- IDr, [CERT+],
creationAUTH,
N(error),
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
Matthew Cini Sarreo writes:
> You still need the IDr and AUTH payloads in the reply. This is needed as
> INVALID_SYNTAX is authenticated and encrypted.
INVALID_SYNTAX is fatal error meaning that other end didn't follow the
protocol specification, and the IKE SA is going to be removed anyways,
and
Lakshminath Dondeti writes:
> > I still do not think making the 1 RT protocol to 2 RT protocol in that
> > case would really cause any noticeable effect to the actual handover.
>
> How do you know this?
Because 10ms-100ms is MUCH less than 10 seconds or so I usually see as
DHCP delays on WLAN net
Narayanan, Vidya writes:
> This is really just a terminology issue. Most of the use cases in
> that document are applicable to resumption. In fact, the current
> solution for resumption is based on what was produced as a result of
> that problem statement (combined with Yaron's draft at the time)
Hi Matt,
Buy as per Youv, we should not process the request.
Is that means, that we will not process the request but send IDr and AUTH
payloads ?
Thanks,
Raj
On Wed, Apr 22, 2009 at 2:48 PM, Matthew Cini Sarreo wrote:
> Hello Raj,
>
> You still need the IDr and AUTH payloads in the reply. This
Hi Matt/Youv,
Thanks for your reply.
I will conclude as IKE_AUTH exchange MUST have TSi and TSr payload. We MUST
NOT process IKE_AUTH packet without TSi and TSr and we should reply with
INVALID_SYNTAX notification without IDr, AUTH, TSi and TSr payloads.
Regards,
Raj
On Wed, Apr 22, 2009 at 1:11
Hello Raj,
You still need the IDr and AUTH payloads in the reply. 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 MUST
> NOT pr
Paul Hoffman writes:
> Since its first draft, the IKEv2 bis document has had flags for
> where new text came from RFC 4718, such as "{{ Clarif-6.1 }}" and
> "{{ Clarif-4.2}}". Using a related notation, we have also marked
> where text that originally existed in the top-heavy listing of
> notificati
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
12 matches
Mail list logo
