Subject: DPD message format

From: Joachim Abrahmsén <[email-masked]>
Date: Thu, 13 Mar 2003 13:27:49 +0100

Hi everybody,

I have two questions regarding the DPD-draft.

Question 1:

In draft-ietf-ipsec-dpd-02.txt the following is stated:

 6.2 Message Exchanges 
    
   The DPD exchange is a bidirectional (HELLO/ACK) Notify message.  The 
   exchange is defined as: 
    
            Sender                                      Responder 
           --------                                    ----------- 
   HDR*, NOTIFY(R-U-THERE), HASH   ------> 
    
                                 <------    HDR*, NOTIFY(R-U-THERE- 
                                            ACK), HASH 

But RFC 2409 section 5.7 says:

        Initiator                        Responder
       -----------                      -----------
        HDR*, HASH(1), N/D      -->

i.e. the Hash-payload is before the Notification-payload, not after as
the DPD-draft suggests.

Those of you who have implemented the DPD-draft, did you follow the
example of the DPD-draft or RFC 2409?

We intend to encode the DPD-messages as RFC 2409 suggest. Will this
break any existing DPD-implemetations?

Question 2:
Although now stated explicitly, I assume that the R-U-THERE and
R-U-THERE-ACK have unrelated message-Ids in the ISAKMP-header. Is that
correct?

I think I would have treaten it as an exchange having the same
message-Id in the same sense QM has, and the IV calculated as for QM,
but that would of cause break what RFC's says about indepentent
message-Id of Informational messages. Any other reason for not doing so?
Is the role of the sequence number in the payload data to be able to map
the R-U-THERE-ACK to the corresonding R-U-THERE, as the message-Id
otherwize (if they were equal) would?

Best regards
Joachim AbrahmsÈn
Steria AB