David Wierbowski writes:
>
> Tero, thanks for the comments and the clarification on how to read a lower
> case must. I do have a few more comments.
>
> >So implementations cannot just search uppercase "MUST/SHOULD/MAY"
> >texts and assume it is enough to make sure those are correct. It also
> >n
pasi.ero...@nokia.com writes:
> > If dpd is enabled then ikev2 counters keep updated frequently.
>
> This depends on how often you do DPD... Obviously, you want dead
> IKE_SAs to go away eventually, but e.g. 30 minute DPD interval would
> be sufficient for that. If your DPD interval was close to
Hello Tero,
Thank you for your clear answer.
It cleared up my questions.
Thanks,
Naoyoshi Ueda
2009/9/2 Tero Kivinen :
> naoyoshi ueda writes:
>> According to ikev2bis-04 section 2.1:
>> > A retransmission from the initiator
>> > MUST be bitwise identical to the original request. That is,
>
>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 to include a DELETE payload in this case?
Dave Wierbowski_
Hello Jeff,
Sorry, I withhold the product's name because of my business commitments.
However, I just say that it is not an ordinary network device like VPN gateway.
Regards,
Naoyoshi Ueda
2009/9/3 Jeff Sun :
> All in all, the qualifications of being a true retransmitted IKE
> request/response m
>>> In an IKE_AUTH
>>>exchange, or in the subsequent INFORMATIONAL exchnage, only the
>>>following notifications cause the IKE SA to be deleted or not
>>>created, without a DELETE payload:
>>>o UNSUPPORTED_CRITICAL_PAYLOAD
>>>o INVALID_SYNTAX
>>>o AUTHENTICATION_FAILED
>>
> >>> In an IKE_AUTH
> >>>exchange, or in the subsequent INFORMATIONAL exchnage, only the
> >>>following notifications cause the IKE SA to be deleted or not
> >>>created, without a DELETE payload:
> >>>o UNSUPPORTED_CRITICAL_PAYLOAD
> >>>o INVALID_SYNTAX
> >>>o AUTHENTICA
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
> Re: [IPsec] Fw: Issue #26: Missing treatment of error cases
>
> 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 a
10 matches
Mail list logo
