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. If it doesn't match, it's an invalid message. ________________________________ From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Matthew Cini Sarreo Sent: Tuesday, April 07, 2009 12:52 PM To: ipsec@ietf.org Subject: [IPsec] IKEv2: Question on INFORMATIONAL exchange response motivation
Hello, While reading through ikev2 bis 02 (this is most certainly not something new that surfaced in this document), section 1.4, par 3 states: "Messages in an INFORMATIONAL exchange contain zero or more Notification, Delete, and Configuration payloads. The Recipient of an INFORMATIONAL exchange request MUST send some response (else the Sender will assume the message was lost in the network and will retransmit it). That response MAY be a message with no payloads. The request message in an INFORMATIONAL exchange MAY also contain no payloads. This is the expected way an endpoint can ask the other endpoint to verify that it is alive." I would like to ask the reason behind this. As "live peer detection" is done by sending an empty INFORMATIONAL exchange (Encrypted Payload with no payloads), wouldn't it better to have a response be constructed in such a way so that the requesting peer can explicitly "know" that this INFORMATIONAL exchange is a confirmation of the request sent? This way, the requester would have to parse the response, and not decrypt the message, discover that there is no payload in the Encrypted Payload, check if the message is marked as a response and assume it is a confirmation of a request. Would a message ID be used to check the corresponding request? And if then the message ID on the responder (to the INFORMATIONAL exchange) somehow got messed up and does not match what the requester is expecting? Regards, Matt Email secured by Check Point
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
