Subject: RE: [dhcwg] RE: Issue/Solution for Confirm-Reply - Remainder

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 12 Sep 2007 23:40:34 -0400

RFC 3315 didn't really cover this complex situation with respect to Comfirm.

I think you have several choices.

Probably the best is to send three Confirms (two with DAP key and one without). Now, a separate question is whether to just include the bindings obtained under the same "DAP key" or all bindings. I would suggest just sending the bindings obtained with the "DAP key":
- Confirm with K1 with IA1 bindings
- Confirm with K2 with IA2 bindings
- Confirm with No DAP with IA3 bindings

Of course, the REPLYs you’d process would also require the corresponding key?. So, if the original server hasn't shared the key with other servers, you may only receive a reply (for K1 or K2) if that server is up. 

It may also be more appropriate in this complex situation to use alternative techniques to determine whether you're still on the same link or use the Confirm as a limited hint depending on how "trusted" it is.

You could also send a single CONFIRM with all of the bindings. Though that might open you up to Denial-of-Service, so best to just the results just as one more hint in the decision.

- Bernie

-----Original Message-----
From: S.SenthilKumar (Huawei) [mailto:[email-masked]] 
Sent: Friday, August 31, 2007 4:51 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [dhcwg] RE: Issue/Solution for Confirm-Reply - Remainder

Dear All

I would appreciate if somebody could clarify or Provide pointers for the issue regarding Confirm-Reply (RFC3315) that I had sent earlier (Refer the attached mail).

Thanking you,

Regards
SenthilKumar.S

Disclaimer: This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

-----Original Message-----
From: S.SenthilKumar (Huawei) [mailto:[email-masked]] 
Sent: Monday, August 27, 2007 5:48 PM
To: [email-masked]'
Cc: [email-masked]'; [email-masked]'
Subject: FW: Issue/Solution for Confirm-Reply

Dear All
Please suggest how to resolve this issue.
Configuration
　　Assume that IA1, IA2 and IA3 were present in the same interface
　　* IA1 has binding with Server S1 and K1 is the DAP key in use for the current session
　　* IA2 has binding with Server S2 and K2 is the DAP key in use for the current session
　　* IA3 has binding with Server S3 and No DAP Authentication (Client has accepted Advertise without Authentication Option as it is enabled in the local configuration)
　　* And all the IAs leased.

As per RFC, Confirm message has to be sent to the server containing all the IAs present in the interface. But in this case how, Which Key has to be used, whether DAP Option has to be present. 

18.1.2. Creation and Transmission of Confirm Messages
The client MUST include a Client Identifier option to identify itself to the server.  The client includes IA options for all of the IAs assigned to the interface for which the Confirm message is being sent.  The IA options include all of the addresses the client currently has associated with those IAs.  The client SHOULD set the T1 and T2 fields in any IA_NA options, and the preferred-lifetime and valid-lifetime fields in the IA Address options to 0, as the server will ignore these fields.

Solution I had devised is that Confirm can be send on the basics of IA i.e confirm will carry only one IA (IA_NA or IA_TA)

Advantages of the solution
1. If Not on link status is received in the Reply received in response to Confirm, Only the address present in the IA will be released
2. Authentication - Confirm-Reply transaction will also be part of the session (Solicit-Advertise till Release/Decline of the last address)
Disadvantages of the solution
1. Multiple Confirm message will be send from the client (Also loads the server)
2. RFC Conformance - I’m not sure about this as “ALL” is mentioned in the RFC.

Let me know your views.

Thanking you,

Regards
SenthilKumar.S

Disclaimer: This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg