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 <mci...@gmail.com>wrote:

> 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 <rsjen...@gmail.com>
>
>> 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 PM, Yoav Nir <y...@checkpoint.com> 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 child SA failed for
>>> whatever reason (bad selectors, no proposal chosen), we don't allow for an
>>> IKE_AUTH exchange that is missing the child payloads.
>>>
>>> An IKE_AUTH request without the TSi and TSr payloads is
>>> considered malformed, and so MUST NOT be processed. Instead, you should
>>> reply with INVALID_SYNTAX
>>>
>>> As to question 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.
>>>
>>> Yoav
>>>
>>> Raj Singh wrote:
>>>
>>> Hi Matt,
>>>
>>> Let me re-phrase my questions:
>>> 1. If there is no TSi and TSr payload in IKE_AUTH exchange, whether we go
>>> ahead and process IKE_AUTH payloads or not ?
>>> 2. Appendix C: IKE_AUTH: Error in CHILD SA creation. It will come into
>>> picture if we process the packet.
>>>     If we go ahead and process the packet, according to appendix C, we
>>> SHOULD/MUST establish the IKE SA ?
>>>     Looks like, if we go ahead to process the IKE_AUTH packet with no TSi
>>> and TSr, we can establish the IKEv2 SA.
>>>
>>> I request more experts to comment.
>>>
>>> Thanks for your reply.
>>>
>>> Regards,
>>> Raj
>>>
>>> On Wed, Apr 22, 2009 at 12:08 PM, Matthew Cini Sarreo 
>>> <mci...@gmail.com>wrote:
>>>
>>>>   Hello Raj,
>>>>
>>>> According to Appendix C, for IKE_AUTH:
>>>>
>>>>    error in Child SA  <--  IDr, [CERT+],
>>>>    creation                AUTH,
>>>>                               N(error),
>>>>                               [V+]
>>>>
>>>> So sending an authenticated 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 <rsjen...@gmail.com>
>>>>>
>>>>>> Hi Matt,
>>>>>>
>>>>>> There is possibility of just IKEv2 SA gets established during IKE_AUTH
>>>>>> and IPsec SA getting established via CREATE_CHILD_SA.
>>>>>> The question is what behavior RFC mandate ? What you think ?
>>>>>>
>>>>>> Thanks for your reply.
>>>>>>
>>>>>> Regards,
>>>>>> Raj
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 22, 2009 at 11:40 AM, Matthew Cini Sarreo <
>>>>>> mci...@gmail.com> wrote:
>>>>>>
>>>>>>>  In IKE_AUTH TSi and TSr are mandatory, so it is not possible to
>>>>>>> omit them from an authentication exchange message, as there would be no 
>>>>>>> way
>>>>>>> for the SA to know what traffic should be forwarded through the SA.
>>>>>>>
>>>>>>> It seems that the correct error message would be INVALID_SYNTAX. 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 <rsjen...@gmail.com>
>>>>>>>>
>>>>>>>>>  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 payload processing, what ERROR should be send ?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Raj
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> IPsec mailing list
>>>>>>>>> IPsec@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> Email secured by Check Point
>>>
>>>
>>
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to