Subject: [MEXT] Document Shepherd review of draft-ietf-mext-rfc3775bis-05

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 1 Apr 2010 10:49:49 -0700

I am the document shepherd for this document and I have the following comments that I would like to see addressed before requesting publication as an RFC. 

--julien

Section 5.1:
------------

   Automatic key management with IKE [7] or IKEv2 [44] MAY be supported.
   When IKE is used, either the security policy database entries or the
   Mobile IPv6 processing MUST unequivocally identify the IKE phase 1
   credentials which can be used to authorize the creation of security
   associations for protecting Binding Updates for a particular home
   address.  How these mappings are maintained is outside the scope of
   this specification, but they may be maintained, for instance, as a
   locally administered table in the home agent.  If the phase 1
   identity is a Fully Qualified Domain Name (FQDN), secure forms of DNS
   may also be used.

Without debating whether we want to stop reference IKE and only reference IKEv2 (I think we should), all the text following the first sentence is present word to word in Section 4.4 of RFC 3776. Thus I think we can safely remove it.

[...]

   When IKE version 1 is used with preshared secret authentication
   between the mobile node and the home agent, aggressive mode MUST be
   used.

   The ID_IPV6_ADDR Identity Payload MUST NOT be used in IKEv1 phase 1.

This is also covered in RFC 3776 and can be removed.

Section 5.2.4. Cryptographic Functions:
---------------------------------------

   In this specification, the function used to compute hash values is
   SHA1 [14].  Message Authentication Codes (MACs) are computed using
   HMAC_SHA1 [29] [14].  HMAC_SHA1(K,m) denotes such a MAC computed on
   message m with key K.

I just want to give everybody a heads up that we did not extended MIPv6 to support crypto agility during this revision of the protocol. Was this a conscious choice? If it is hopefully it is acceptable... 

Section 9.5.1. Receiving Binding Updates:
-----------------------------------------

   o  If the Lifetime specified in the Binding Update is not zero, then
      this is a request to cache a binding for the home address.  If the
      Home Registration (H) bit is set in the Binding Update, the
      Binding Update is processed according to the procedure specified
      in Section 10.3.1; otherwise, it is processed according to the
      procedure specified in Section 9.5.2.

   o  If the Lifetime specified in the Binding Update is zero or the
      specified care-of address matches the home address for the
      binding, then this is a request to delete the cached binding for
      the home address.  In this case, the Binding Update MUST include a
      valid home nonce index, and the care-of nonce index MUST be
      ignored by the correspondent node.  The generation of the binding
      management key depends then exclusively on the home keygen token
      (Section 5.2.5).  If the Home Registration (H) bit is set in the
      Binding Update, the Binding Update is processed according to the
      procedure specified in Section 10.3.2; otherwise, it is processed
      according to the procedure specified in Section 9.5.3.

There is an issue with the half-removal of the care-of address / home address match condition for deregistration. It's been removed in first paragraph but kept in the second which I think is inconsistent. See corresponding section of RFC 3775 that said:

   o  If the Lifetime specified in the Binding Update is nonzero and the
      specified care-of address is not equal to the home address for the
      binding, then this is a request to cache a binding for the home
      address.  If the Home Registration (H) bit is set in the Binding
      Update, the Binding Update is processed according to the procedure
      specified in Section 10.3.1; otherwise, it is processed according
      to the procedure specified in Section 9.5.2.

   o  If the Lifetime specified in the Binding Update is zero or the
      specified care-of address matches the home address for the
      binding, then this is a request to delete the cached binding for
      the home address.  In this case, the Binding Update MUST include a
      valid home nonce index, and the care-of nonce index MUST be
      ignored by the correspondent node.  The generation of the binding
      management key depends then exclusively on the home keygen token
      (Section 5.2.5).  If the Home Registration (H) bit is set in the
      Binding Update, the Binding Update is processed according to the
      procedure specified in Section 10.3.2; otherwise, it is processed
      according to the procedure specified in Section 9.5.3.

Bottom line is the two paragraphs should be consistent; either we remove the match from both, or we keep in both as in RFC 3775, but doing it half-way does not seem acceptable. I suggest we keep the older text, as I do not see what would be the purpose of creating a binding for the home address at the home address in the context of 3775bis.

Section 18.2 Informative References:
------------------------------------

   [44]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
         RFC 4306, December 2005.

   [45]  Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
         IKEv2 and the Revised IPsec Architecture", RFC 4877,
         April 2007.

These two references should be normative (references to RFC 2409 and RFC 3776 are.) Also, is it really the intent that we keep IKEv1 as an alternative to IKEv2 in this specification?

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 05 Apr 2010 13:52:06 -0700

Hello Julien,

Comments below:

On 4/1/2010 10:49 AM, Laganier, Julien wrote:

> Without debating whether we want to stop reference IKE and
> only reference IKEv2 (I think we should), all the text
> following the first sentence is present word to word in
> Section 4.4 of RFC 3776. Thus I think we can safely remove it.

Fine with me :-)

> This is also covered in RFC 3776 and can be removed.

Also fine with me.

> I just want to give everybody a heads up that we did not
> extended MIPv6 to support crypto agility during this revision
> of the protocol. Was this a conscious choice? If it is
> hopefully it is acceptable...

Seems a shame to me to suggest using these powerful tools
for establishing security associations, and still prohibit
any measure of cryptoagility.

How about adding a few weasel words, for example:

    By default in this specification, the function used to compute
    hash values is SHA1 [14].  Message Authentication Codes (MACs)
    are then computed using HMAC_SHA1 [29] [14].  HMAC_SHA1(K,m)
    denotes such a MAC computed on message m with key K.

> There is an issue with the half-removal of the care-of address /
> home address match condition for deregistration. It's been removed
> in first paragraph but kept in the second which I think is
> inconsistent. See corresponding section of RFC 3775 that said:
>
> Bottom line is the two paragraphs should be consistent; either we
> remove the match from both, or we keep in both as in RFC 3775, but
> doing it half-way does not seem acceptable. I suggest we keep the
> older text, as I do not see what would be the purpose of creating
> a binding for the home address at the home address in the context
> of 3775bis.

As I understand it, the consensus position was to go with the
opposite polarity.  I do remember there was a long discussion
about it several years ago.  It might have been resolved even
before we started keeping track of issues on the issue tracker,
because right now I don't have a pointer to the discussion
without going back through a lot of old emails.  So, unless I
am remembering this wrong or unless a new consensus develops,
I'll fix the second paragraph to be consistent with the first
one.

I'm O.K. either way, depending on what the others in the
working group want.

> These two references should be normative (references to RFC 2409 and
> RFC 3776 are.) Also, is it really the intent that we keep IKEv1 as
> an alternative to IKEv2 in this specification?

I'll be happy to fix this according to whatever
people decide.  I'm assuming that "normative" does
not mean "must implement".

Regards,
Charlie P.

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 8 Apr 2010 13:39:37 -0700

Following up on CoA==HoA test below:

Charles E. Perkins wrote:
> >     o  If the Lifetime specified in the Binding Update is not zero,
> >        then this is a request to cache a binding for the home address. 
> >        [...]  
> >
> >        binding, then this is a request to delete the cached binding
> >        for the home address.  [...]
> >
> >     o  If the Lifetime specified in the Binding Update is nonzero and
> >        the specified care-of address is not equal to the home address for
> >        the binding, then this is a request to cache a binding for the
> >        home address. [...]
> >
> >        binding, then this is a request to delete the cached binding
> >        for the home address. [...]
> >

I'll be fine fixing the second paragraph to be consistent with the first one. If we do so, 
it becomes possible for a MN to register a binding where the CoA==HoA. This is fine with me as well, but we need to define the semantic of such a binding. 

When the CoA==HoA, no tunneling is necessary for delivery of packets so we should specify that neither the MN, nor the HA, nor the CN (when RO is in use) are using tunneling when transmitting packets.

On the receiving side, since there does not seem to be harm, I'd tentatively propose to follow the "be conservative in what you send and liberal in what you accept" credo and accept packets tunneled with CoA==HoA. (Or is there any harm?)

What do people think?
 
--julien

---

From: <[email-masked]>
Date: Thu, 8 Apr 2010 22:51:16 +0200

Hi Julien,

Comments inline:

On 4/8/10 2:39 PM, "ext Laganier, Julien" <[email-masked]> wrote:

> it becomes possible for a MN to register a binding where the CoA==HoA. This is
> fine with me as well, but we need to define the semantic of such a binding.

What would be the use case for keeping a binding cache entry for the MN when
the CoA==HoA?

Basically if the MN is on the HL, the BCE in the HA for the MN should (MUST)
be deleted. 

> 
> When the CoA==HoA, no tunneling is necessary for delivery of packets so we
> should specify that neither the MN, nor the HA, nor the CN (when RO is in use)
> are using tunneling when transmitting packets.

I don't understand what needs to be specified? If the MN is on the HL there
is no tunnelling. Maybe I am missing something?

> 
> On the receiving side, since there does not seem to be harm, I'd tentatively
> propose to follow the "be conservative in what you send and liberal in what
> you accept" credo and accept packets tunneled with CoA==HoA. (Or is there any
> harm?)

IMO when CoA==HoA, there is no BCE at the HA and there is no tunnelling on
the UL/DL. This should be the expected behavior.

-Raj

> 
> What do people think?
> 
> --julien
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 8 Apr 2010 13:52:50 -0700

Following up on crypto-agility for BU to correspondent nodes below:

>     denotes such a MAC computed on message m with key K.

Since SHA1 is used to send binding updates to correspondent nodes, and because we can't assume an a-priori agreement between a MN and an arbitrary CN on the Internet, the above text does not practically enable a MN and a CN to use a function other than SHA-1 without compromising interoperability. 

So this text still doesn't enable crypto-agility but at least does not prohibit it. 

Enabling crypto-agility would require the MN and CN to agree on which function to use to compute hash values. A strawman would be for the MN to include a list of supported functions in HoTI and CoTI, and for the CN to select the strongest it supports and signals it back in the HoT and CoT.

What do people think? Is this something worth pursuing in this revision of 3775bis or is it better deferred to an additional specification? 

(FWIW, my own experience is that the IESG can be picky about hard-coding use of a specific cryptographic function in a protocol specification.)

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 8 Apr 2010 14:02:17 -0700

Hi Raj,

[email-masked] wrote:
> > I'll be fine fixing the second paragraph to be consistent with the
> > first one. If we do so, it becomes possible for a MN to register 
> > a binding where the CoA==HoA. This is fine with me as well, but we 
> > need to define the semantic of such a binding.
> 
> What would be the use case for keeping a binding cache entry for the MN
> when the CoA==HoA?

In a strict MIPv6/3775 context, there is no usecase and I was simply commenting on Charlie's proposal to align the second paragraph on the first one, that is, remove both instances of the HoA==CoA test. But see also below...
 
> Basically if the MN is on the HL, the BCE in the HA for the MN should
> (MUST) be deleted.

I agree this seems natural in a strict MIPv6/3775 context. However, since RFC 3775 was published the MEXT WG has also published RFC 5648 to support multiple Care-of addresses registrations. RFC 5648 makes it possible to have some sort of binding with CoA == HoA (Simultaneous Home and Visited Link Operation), so the situation is not as clear as it used to be.
  
> > When the CoA==HoA, no tunneling is necessary for delivery of packets
> > so we should specify that neither the MN, nor the HA, nor the CN (when RO
> > is in use) are using tunneling when transmitting packets.
> 
> I don't understand what needs to be specified? If the MN is on the HL
> there is no tunnelling. Maybe I am missing something?
 
This is true with RFC 3775, but if we remove the HoA==CoA test as proposed by Charlie, then there can be a binding for which HoA==CoA. I am commenting on what to specify when such a binding is used and, as you note, no tunneling is required.

> > On the receiving side, since there does not seem to be harm, I'd
> > tentatively propose to follow the "be conservative in what you send and
> > liberal in what you accept" credo and accept packets tunneled with CoA==HoA. 
> > (Or is there any harm?)
> 
> IMO when CoA==HoA, there is no BCE at the HA and there is no tunnelling
> on the UL/DL. This should be the expected behavior.

See above.

FWIW - just trying to have consistency in our specs.

--julien

---

From: <[email-masked]>
Date: Thu, 8 Apr 2010 23:20:52 +0200

Hi Julien,

>>> Charles E. Perkins wrote:

-snip-snip-

> In a strict MIPv6/3775 context, there is no usecase and I was simply
> commenting on Charlie's proposal to align the second paragraph on the first
> one, that is, remove both instances of the HoA==CoA test. But see also
> below...

Agree about there not being any usecase for basic MIPv6 as per 3775.

> I agree this seems natural in a strict MIPv6/3775 context. However, since RFC
> 3775 was published the MEXT WG has also published RFC 5648 to support multiple
> Care-of addresses registrations. RFC 5648 makes it possible to have some sort
> of binding with CoA == HoA (Simultaneous Home and Visited Link Operation), so
> the situation is not as clear as it used to be.

True. With MCoA the situation does change. But since RFC5648 is an
enhancement to basic MIP6 functionality, it would be fine to allow the
capability which preserves a binding at the HA when CoA==HoA in that spec.

An HA implementation supporting RFC5648 would allow it.

In the context of RFC3775, I think it would be preferable to simply delete
the BCE for the MN when CoA==HoA.

> This is true with RFC 3775, but if we remove the HoA==CoA test as proposed by
> Charlie, then there can be a binding for which HoA==CoA. I am commenting on
> what to specify when such a binding is used and, as you note, no tunneling is
> required.

Okay.. Understand now :)

However I am not convinced that in 3775 there is a need to remove the
HoA==CoA test. I agree that the text should be made consistent.

> FWIW - just trying to have consistency in our specs.

Always a good thing.

-Raj

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 Apr 2010 14:26:10 -0700

Hello Julien,

On 4/8/2010 1:52 PM, Laganier, Julien wrote:

> Enabling crypto-agility would require the MN and CN to agree
> on which function to use to compute hash values. A strawman
> would be for the MN to include a list of supported functions
> in HoTI and CoTI, and for the CN to select the strongest it
> supports and signals it back in the HoT and CoT.
>
> What do people think? Is this something worth pursuing
> in this revision of 3775bis or is it better deferred to
> an additional specification?

I could probably write up something for this without
too much trouble.  However, I wouldn't want to make
the design unless there was consensus to add the feature.
I reckon it would be two new extensions (e.g., "Offer"
and "Accept").  Presumably it's only needed for one of
HoTI or CoTI, right?

Regards,
Charlie P.

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 8 Apr 2010 14:28:51 -0700

Hello Charlie,

> the design unless there was consensus to add the feature.

Agree.

> and "Accept").  Presumably it's only needed for one of

Yeah. It's safer in HoTI/HOT since it's protected by the MN-HA security association on the visited link.

--julien

---

From: <[email-masked]>
Date: Thu, 8 Apr 2010 23:42:22 +0200

Hi Charlie,

IMO, anything to do with RO is best left for another spec.

-Basavaraj

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 8 Apr 2010 15:09:59 -0700

Raj,

The rationale here isn't to extend RO per se, it's to add crypto-agility in case it's a requirement, notably to pass IESG review. Maybe our AD can give us some guidance here...

--julien

[email-masked]

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 13 Apr 2010 16:52:02 -0700

Hi Raj and Julien,

> the BCE for the MN when CoA==HoA.

I agree with Raj.  RFC5648 overwrites this part as an extension.
RFC3775 itself doesn't need this function, unless someone wants to keep the extra MN information in BC regardless of MN's location. 

regards,
ryuji

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 13 Apr 2010 17:54:35 -0700

Hello Ryuji -

Ryuji Wakikawa [mailto:[email-masked]]
> <[email-masked]> wrote:

<huge snip>

> > In the context of RFC3775, I think it would be preferable to simply
> > delete the BCE for the MN when CoA==HoA.
> 
> RFC3775 itself doesn't need this function, unless someone wants to keep
> the extra MN information in BC regardless of MN's location.

If we do so, let's do it in a consistent way then and keep the HoA==CoA test in both offending paragraphs of 3775bis.

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 15 Apr 2010 10:00:51 -0700

All,

Ryuji Wakikawa wrote:
> > enhancement to basic MIP6 functionality, it would be fine to allow
> > the capability which preserves a binding at the HA when CoA==HoA in
> > that spec.
> >

My reading of the current list discussion seems to indicate that rough consensus (Raj and Ryuji vs. nobody) is to keep the CoA==HoA test. Other thoughts on the topic?

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 28 Apr 2010 11:44:41 -0700

Folks,

I am going to declare rough consensus for keeping CoA==HoA test as a valid BU deregistration trigger tomorrow COB PDT. It's time to speak up if you disagree.

--julien

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Laganier, Julien
> Sent: Thursday, April 15, 2010 10:01 AM
> To: Ryuji Wakikawa; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [MEXT] CoA==HoA test (Was: Re: Document Shepherd review of
> draft-ietf-mext-rfc3775bis-05)
> 
> All,
> 
> Ryuji Wakikawa wrote:
> >
> > Hi Raj and Julien,
> >
> > [...]
> >
> My reading of the current list discussion seems to indicate that rough
> consensus (Raj and Ryuji vs. nobody) is to keep the CoA==HoA test.
> Other thoughts on the topic?
> 
> --julien

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Wed, 28 Apr 2010 23:39:45 -0500

Sorry for the late response. IMO, lifetime set to zero should be the only
deregistration BU from the mobile node. Using the HoA = CoA test for
de-registration has caused a lot of confusion in the past.

A few months ago, we discussed this issue in detail and concluded that
lifetime set to zero indicates a deregistration BU. What has changed since
then?

Vijay

On 4/15/10 10:00 AM, "Laganier, Julien" <[email-masked]> wrote:

> consensus (Raj and Ryuji vs. nobody) is to keep the CoA==HoA test. Other
> thoughts on the topic?
> 
> --julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 29 Apr 2010 07:32:50 -0700

Hi Vijay,

Devarapalli, Vijay wrote:
> 
> Sorry for the late response. IMO, lifetime set to zero should be the
> only deregistration BU from the mobile node. Using the HoA = CoA test for
> lifetime set to zero indicates a deregistration BU. What has changed
> since then?

There has been no intent to change the semantic of a BU with lifetime set to zero to indicate deregistration, that should stay as it is.

However, RFC3775 also considers a BU with CoA sets to HoA as a sufficient condition to deregistration (i.e., lifetime can be non-zero), and we were discussing whether to remove this or not. The current RFC3775 bis has it half-ways and is inconsistent.

There are two options on the table: 

- Keep the semantic as in 3775

- Remove the HoA == CoA test as sufficient condition for registration. If we go this way, we also have to specify what to do when the HA receives a binding with HoA == CoA, we can't just remove the test alone. Since you're in favor of removing this test, what would you suggest the HA does when it receives a BU with non-zero lifetime and set CoA == HoA? Send an error? Deregister the binding?

Thanks.

--julien

---

From: "Devarapalli, Vijay" <[email-masked]>
Date: Thu, 29 Apr 2010 12:03:01 -0500

Hi Julien,

On 4/29/10 7:32 AM, "Laganier, Julien" <[email-masked]> wrote:

> There has been no intent to change the semantic of a BU with lifetime set to
> zero to indicate deregistration, that should stay as it is.

I should have said it is a deregistration BU *only* if the lifetime is set
to zero. This is what we concluded a few months ago.
 
> - Remove the HoA == CoA test as sufficient condition for registration. If we
> go this way, we also have to specify what to do when the HA receives a binding
> with HoA == CoA, we can't just remove the test alone. Since you're in favor of
> removing this test, what would you suggest the HA does when it receives a BU
> with non-zero lifetime and set CoA == HoA? Send an error? Deregister the
> binding?

We had discussed this too. The HA is supposed to send a binding ack with
error status if the HoA is set to CoA and the lifetime is not zero. I don't
have access to my email archive right now (had to change email servers four
months ago). I forgot what error status we had decided on.

Vijay

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 29 Apr 2010 10:34:42 -0700

Devarapalli, Vijay wrote:
> >> only deregistration BU from the mobile node. Using the HoA = CoA
> >> test for de-registration has caused a lot of confusion in the past.
> >>
> >> A few months ago, we discussed this issue in detail and concluded
> >> that lifetime set to zero indicates a deregistration BU. What has
> >> changed since then?
> >
> > There has been no intent to change the semantic of a BU with lifetime
> > set to zero to indicate deregistration, that should stay as it is.
> 
> I should have said it is a deregistration BU *only* if the lifetime is
> set to zero. This is what we concluded a few months ago.

Ok.
 
> > - Remove the HoA == CoA test as sufficient condition for registration.
> > If we go this way, we also have to specify what to do when the HA receives
> > a binding with HoA == CoA, we can't just remove the test alone. Since you're
> > in favor of removing this test, what would you suggest the HA does when it
> > receives a BU with non-zero lifetime and set CoA == HoA? Send an error? 
> > Deregister the binding?
> 
> We had discussed this too. The HA is supposed to send a binding ack
> with error status if the HoA is set to CoA and the lifetime is not zero.
> I don't have access to my email archive right now (had to change email servers
> four months ago). I forgot what error status we had decided on.

OK.

Charlie also pointed out to an earlier conclusion but I couldn't find anything in the issue tracker. I personally don't care which way to go, but we need all cases to be covered in 3775bis. 

If we go the way you suggest we concluded earlier, we need to agree on text and choose error code.

What are other people on the list thinking?

--julien