Subject: [netlmm] Comments on draft-muhanna-netlmm-grekey-option-01

From: Suresh Krishnan <[email-masked]>
Date: Thu, 03 Apr 2008 15:00:37 -0400

Hi Authors,
   I read through this document and it looks good. I have a couple of 
comments that probably require some text changes. I have proposed some 
text to explain my intentions. Feel free to use it if you agree.

Section 6.1
===========
Definition of GRE Key Identifier:
"four-byte field  containing the Reverse GRE Key Identifier.
or eight-byte containing the Forward and Reverse GRE keys
respectively. The values of zero and all-ones are reserved."

This is not entirely true. Since if asymmetric keys are in use this will 
also contain the Forward GRE key when the option is carried from the MAG 
to the LMA.

I would revise the text to say

Gre Key Identifier
"When the length field is 6: It contains a four-byte field containing 
either the Forward GRE Key Identifier or the Reverse GRE Key Identifier.
When the length field is 10: It contains an eight-byte field containing 
the Forward GRE key identifier followed by the Reverse GRE key identifier.
The GRE key identifiers zero and all-ones are reserved."

IANA Considerations
===================

The document defines two new Status codes for the BA but does not 
request them from the IANA. Also do not assume that you will get the 
values 148 and 149(Especially since they have already been allocated to 
RFC4866 :-)). Call them TBA1 and TBA2. Please add the following text 
into the IANA considerations section

"This document defines two new Binding Acknowledgement status codes TBA1 
and TBA2 as described in Section 6.2. This document requests that these 
two codes be allocated from the "Status Codes" registry of the Mobility 
IPv6 Parameters located at 
http://www.iana.org/assignments/mobility-parameters
and that the numeric value of these codes be greater than 128.

De-registration behavior
========================

This document does not talk about de-registration behavior at all. What 
does a MAG do when it is sending a dereg BU? What does the LMA do when 
it receives the dereg BU etc. This section also needs to specify whether 
the GRE key identifiers will be released for reuse immediately or after 
a delay.

Thanks
Suresh
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 3 Apr 2008 12:14:26 -0700

Hi Suresh,

Thanks for the comments.

> -----Original Message-----
> From: Suresh Krishnan [mailto:[email-masked]] 
> Sent: Thursday, April 03, 2008 12:01 PM
> To: Ahmad Muhanna; Mohamed Khalil; Sri Gundavelli; Kent Leung (kleung)
> Cc: [email-masked]
> Subject: Comments on draft-muhanna-netlmm-grekey-option-01
> 
> Hi Authors,

We need to think a bit more on if we need to support asymmetric
keys or just simplify and have one key in both directions. Based
on that, we need to fix this text.

> The GRE key identifiers zero and all-ones are reserved."

Sure. This needs to be fixed.

> De-registration behavior

Good points. We will address them.

Regards
Sri

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Thu, 3 Apr 2008 17:15:54 -0400

Hi Sri,

Please see inline...

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Sri Gundavelli
> Sent: Thursday, April 03, 2008 2:14 PM
> To: 'Suresh Krishnan'; 'Ahmad Muhanna'; 'Mohamed Khalil'; 'Kent Leung
> (kleung)'
> Cc: [email-masked]
> Subject: Re: [netlmm] Comments on
draft-muhanna-netlmm-grekey-option-01
> on that, we need to fix this text.
[KC>] Suresh is right. We need the ability to provide forward and
reverse GRE keys independently. Both the endpoints should be able to
pick their own GRE keys.

> > and that the numeric value of these codes be greater than 128.
[KC>] Whether GRE keys are released immediately after sending or
receiving a dereg is an implementation issue, IMHO.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 3 Apr 2008 14:28:44 -0700

Hi Kuntal,

> reverse GRE keys independently. Both the endpoints should be able to

That support is there in the draft today. However, there was a
comment on if this should be simplified. If there is a value and
a need for this, sure, we can retain this.

> receiving a dereg is an implementation issue, IMHO.

Well, we may have to specify how the peers release the keys after
the dereg. This is in the context of the mobility state and what
is retained. Its implicit to me that the key state is released
along with the binding state upon dereg. Any ways, we will try
to clarify this .. as needed.

Thanks
Sri

> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."