Subject: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt

From: Jari Arkko <[email-masked]>
Date: Mon, 18 Feb 2008 12:13:26 -0800

Hi all,

I have posted a draft that suggests a modification of the rules
regarding Alternate Care-of Address checking. The rationale for the
change is in the draft -- it is something that came up during the
interim; there are closed networks that apply Mobile IPv6 and ingress
filtering, and it would be useful in those networks to be able to be
strict about what addresses the option can contain.

The big question is if something today relies on the option value being
able to differ from the source IP address. The draft talks about this as
well and preliminarily I do not see a problem. But I would appreciate
discussion on this.

Jari

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Title           : Verifying Correctness of Alternate Care-of Address Option
> 	Author(s)       : J. Arkko
> 	Filename        : draft-arkko-mext-rfc3775-altcoa-check-00.txt
> 	Pages           : 6
> 	Date            : 2008-02-18
>
> This document revises the RFC 3775 rules on how Alternate Care-of
> Address option is processed.  Alternate Care-of Address option is
> used to carry the current care-of address inside a Mobility Header
> message.  This is used in addition to the source address in the
> packet in order to ensure that the care-of address is protected by
> IPsec ESP, the security mechanism that protects Mobility Header
> messages.  Unfortunately, RFC 3775 did not require verification that
> the source address and care-of address are the same.  This document
> adds that requirement.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-arkko-mext-rfc3775-altcoa-check-00.txt
>   

_______________________________________________
MEXT mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mext

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 18 Feb 2008 14:38:53 -0800 (PST)

Hi Jari,

For seperating the control and data plane, there are some folks
who are thinking of using Alt-CoA option to carry a different
address than what is in the source address of the field. There
seem to be some proposals in WiMAX, applying PMIP and with the
functional split of MAG, using this option for registering the
tunnel endpoint which is on a different entity. That wont work
with this new restriction. Not sure, if we can control this
enforcement using a config option. Personally, I dont have any
issue with this change.

Regards
Sri

---

From: "Benjamin Lim" <[email-masked]>
Date: Tue, 19 Feb 2008 10:35:36 +0800

Hi Jari,

Two questions.

1) In section 3, 

> If the address in the Alternate Care-of Address option 
> is not the same as either the home address or the Source 
> Address field in the IPv6 header of the Binding Update 
> packet, then by default the receiving node MUST send 
> back a Binding Acknowledgement with status code 
> TBD-BY-IANA (mismatching source address)."

Does the HA/CN send this BA to the address specified in the BU source
address field or the the address specified in the AltCoA field?

2) Does the MN need to reply something back to the HA/CN when receiving this
BA mesage?

Regards,
Benjamin Lim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jari Arkko
> Sent: Tuesday, February 19, 2008 4:13 AM
> To: [email-masked]
> Subject: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt
> 
> Hi all,
> 
> I have posted a draft that suggests a modification of the 
> rules regarding Alternate Care-of Address checking. The 
> rationale for the change is in the draft -- it is something 
> that came up during the interim; there are closed networks 
> that apply Mobile IPv6 and ingress filtering, and it would be 
> useful in those networks to be able to be strict about what 
> addresses the option can contain.
> 
> The big question is if something today relies on the option 
> value being able to differ from the source IP address. The 
> draft talks about this as well and preliminarily I do not see 
> a problem. But I would appreciate discussion on this.
> 
> Jari
> 
> > Address option is processed.  Alternate Care-of Address 
> option is used 
> > to carry the current care-of address inside a Mobility 
> Header message.  
> > This is used in addition to the source address in the 
> packet in order 
> > to ensure that the care-of address is protected by IPsec ESP, the 
> > security mechanism that protects Mobility Header messages.  
> > Unfortunately, RFC 3775 did not require verification that 
> the source 
> > address and care-of address are the same.  This document adds that 
> > requirement.
> >

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 19 Feb 2008 10:15:53 +0100

Hi Sri,

There was such a proposal in WiMAX, but this was before PMIP6 work in the IETF. Current discussions in WiMAX do not mention alt-CoA in this context.

OTOH, any MAG could have a control plane blade and several data plane blades, so the concept is generally applicable. 

regards
domagoj

> Behalf Of Sri Gundavelli
> Sent: 18. veljaca 2008 23:39
> To: Jari Arkko
> Cc: [email-masked]
> Subject: Re: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt
> 
> Hi Jari,
> 
> For seperating the control and data plane, there are some 
> folks who are thinking of using Alt-CoA option to carry a 
> different address than what is in the source address of the 
> field. There seem to be some proposals in WiMAX, applying 
> PMIP and with the functional split of MAG, using this option 
> for registering the tunnel endpoint which is on a different 
> entity. That wont work with this new restriction. Not sure, 
> if we can control this enforcement using a config option. 
> Personally, I dont have any issue with this change.
> 
> Regards
> Sri
> 
> 
> > The big question is if something today relies on the option value 
> > being able to differ from the source IP address. The draft 
> talks about 
> > this as well and preliminarily I do not see a problem. But I would 
> > appreciate discussion on this.
> >
> > Jari
> >

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Feb 2008 07:07:08 -0800

Premec, Sri,

Distributed MN or MAG implementations might indeed have a need to use
multiple source addresses. Its not clear to me though that there are
cases where you simply cannot use one source address and care-of address
consistently. E.g., can a control plane blade send a packet with a
source address that belongs to a data plane blade? Input from
implementors sought on this.

Of course, if all else fails you can configure this check off.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 19 Feb 2008 07:54:35 -0800

Benjamin,

Thanks for your review.

> address field or the the address specified in the AltCoA field?

I have assumed that RFC 3775 Section 9.5.4 rules will apply. I will add
an explicit statement about this. Note that the 9.5.4 rules imply a
number of things, including for instance, that the message is sent to
the source address (unless source was a multicast address).

> 2) Does the MN need to reply something back to the HA/CN when receiving this
No, general rules from RFC 3775 Section 11.7.3 apply:

      ... the mobile node can take steps to correct the cause of the
error and
      retransmit the Binding Update ...

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Feb 2008 08:00:38 -0800 (PST)

Hi Jari,

> implementors sought on this.

In the blade architecture systems, probably this is common as 
Premec pointed out. I do not think, using the source of the data plane
in the control packets will help, as the BA will not come back to
the control endpoint. All that will be there in the data card will
be some routing state.

> Of course, if all else fails you can configure this check off.

Sure

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 19 Feb 2008 08:04:37 -0800 (PST)

Hi Premec,

> There was such a proposal in WiMAX, but this was before PMIP6 work in the IETF. Current discussions in WiMAX do not mention alt-CoA in this context.

Ok. If its not being used, that's good.

> OTOH, any MAG could have a control plane blade and several data plane blades, so the concept is generally applicable.

Yes, I agree.

Sri

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Feb 2008 17:56:57 +0100

In your previous mail you wrote:

   
=> there is a known case: in the return to home it is useful to have
different source and care-of addresses. For instance the source address
can be a link-local address when the care-of address is by definition
the home address.
So I propose to relax your new requirement by:
 1- accepting the source address or the home address as a valid care-of
  address;
 2- make the check policy-based with the check "on" for the default policy
  ("on" ::= perform the check and reject the BU when it fails).

Thanks

[email-masked]

PS: 1- is already in the IPsec between MN and CN I-D (as it removes the
return routability check it must not open the door to fake care-of attacks.
 The rrcookie I-D provides a router routability check at the CN initiative
so it allows a less drastic policy (i.e., perform the check and when it
fails use the rrcookie to valid the new care-of).
_______________________________________________
MEXT mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mext

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 20 Feb 2008 11:29:27 -0800

Hi Jari,

I believe the original motivation for the alt CoA option was
for the mobile node to be able to bind a new care-of address
to its home address if it knows ahead of time that it would
be soon handing over the access network where the new care-of
address is valid. (I need to check with Charlie, this what I
remember though).

But we never found a use for the above. So we almost
deprecated it once.

But later on, when IPsec ESP was mandated for protecting a
Binding Update, the alt CoA option was needed to protect the
care-of address (since ESP offers no protection to the IPv6
header).

So considering this, I am ok with requiring the HA to check
if the address in the alt CoA option matches with the source
address in the IPv6 header.

This shouldn't impact FMIPv6 or DS-MIPv6. In DS-MIPv6, its
the IPv4 CoA option that carries the IPv4 care-of address.
In FMIPv6, the PAR is aware of the new CoA. However, we might
need some explicit text in 4068bis to make sure the PAR would
process the Fast BU even if the address in the alt CoA option
is different from the source address. I will check with Rajeev.

Finally, should we handle this as part of 3775bis?

Vijay

---

From: Romain KUNTZ <[email-masked]>
Date: Thu, 21 Feb 2008 10:57:51 +0100

Hello,

On 2008/02/18, at 21:13, Jari Arkko wrote:
> being
> able to differ from the source IP address.

I think the current MCoA draft (http://tools.ietf.org/html/draft-ietf-monami6-multiplecoa-05 
) allows (or at least does not prevent) the use of the alternate-coa  
option e.g. to register a CoA from one interface with a BU sent from  
another interface.

Section 6.3

       *  If C flag is not set and an alternate care-of address is
          present, the care-of address is taken from the Alternate
          Care-of address mobility option.

Regards,

-- 
Romain KUNTZ
[email-masked]
Louis Pasteur University - Networks and Protocols Team

---

From: "Singh Ajoy-ASINGH1" <[email-masked]>
Date: Thu, 21 Feb 2008 14:27:52 -0500

Hi, Jari / All. 

Sorry for delayed response. I also think there is an use case for
alt-CoA in PMIPv6 context. 
So, I support the idea of keeping this in current MIPv6 spec. 
 
Regards,
Ajoy 

From: "Premec, Domagoj" <domagoj.premec at siemens.com> 
Date: Tue, 19 Feb 2008 10:15:53 +0100 
Cc: mext at ietf.org 
Thread-index: Achyf0tycxiME4i+Tbu0RFrhEOZ5OgAVDlRw 
Thread-topic: [MEXT] draft-arkko-mext-rfc3775-altcoa-check-00.txt 

------------------------------------------------------------------------
--------

Hi Sri,

There was such a proposal in WiMAX, but this was before PMIP6 work in
the IETF. Current discussions in WiMAX do not mention alt-CoA in this
context.

OTOH, any MAG could have a control plane blade and several data plane
blades, so the concept is generally applicable. 

regards
domagoj

> From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org] On 
> Behalf Of Sri Gundavelli
> Cc: mext at ietf.org

---

From: Heikki Mahkonen <[email-masked]>
Date: Fri, 22 Feb 2008 08:32:58 +0200

Hi,

>           Care-of address mobility option.

==> The MCoA draft uses the C flag to indicate whether it is a
BU message for a bulk or single registration. If the C flag is not set
the BU is a single registration and the CoA must be taken from the Alt.
CoA option. In this case I think it must be the same as the source
address of the BU message (MN has only one CoA). If the C flag is set,
CoAs for each binding are taken from the BID options. In the bulk case I
think that the Alt. CoA option is omitted altogether. At least the MCoA
draft says that "...The alternate care-of address option MUST be omitted
when ESP is used to protect a binding update." (Section 5.4 Binding Bulk
Registration). If for some reason the MN doesn't use ESP and adds Alt.
CoA option I think that it must have same CoA as source address and in
Alt. CoA option.

So therefore I don't think that the new Alt. CoA check draft intervenes
with the MCoA draft...

BR,

Heikki

---

From: Heikki Mahkonen <[email-masked]>
Date: Fri, 22 Feb 2008 08:55:32 +0200

Hi,

> So, I support the idea of keeping this in current MIPv6 spec. 
==> In PMIP case there might be use for Alt. CoA option (at least when
using HW that has separated CPs and UPs). The use of Alt. CoA option is
also described in the PMIPV6 draft. However, PMIPv6 uses Proxy Binding
Updates and Acknowledgments so the new checking in the new draft doesn't
need to be applied for PMIPv6, rigtht? I mean the draft says that "When
an Alternate Care-of Address option is present in a Binding Update
message, perform the following additional test:".

If this new check is also needed for the PMIPv6, then I think PMIPv6
requires a new option to carry the CoA used for signaling (address of
the CP) inside the ESP protected part of the message. Then the Alt. CoA
option can be used to carry the address for the PMIPv6 tunnel endpoint
(address of the UP). Never the less, I think that the CP needs to know
the address of the UP to add it into the Alt. CoA option, so I guess it
would be doable to use the same UP address also for signaling (as a
source address of the PBU)...

BR,

Heikki

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 22 Feb 2008 13:30:43 +0100

Hi Heikki,

> Never the less, I think that the CP needs to know the 
> address of the UP to add it into the Alt. CoA option, so I 
> guess it would be doable to use the same UP address also for 
> signaling (as a source address of the PBU)...

By using the same address for CP and UP the CP messages would arrive at the user plane blade which is not able to deal with them. 

In addition, if the LMA would send unsolicited messages to the MAG (like Binding Revocation), the LMA needs to save two different CoAs in the BCE: one for signalling (source IP) and another for data plane (alt-CoA).

regards
domagoj

> Behalf Of Heikki Mahkonen
> Sent: 22. veljaca 2008 07:56
> To: [email-masked]
> ==> In PMIP case there might be use for Alt. CoA option (at 
> least when using HW that has separated CPs and UPs). The use 
> of Alt. CoA option is also described in the PMIPV6 draft. 
> However, PMIPv6 uses Proxy Binding Updates and 
> Acknowledgments so the new checking in the new draft doesn't 
> need to be applied for PMIPv6, rigtht? I mean the draft says 
> that "When an Alternate Care-of Address option is present in 
> a Binding Update message, perform the following additional test:".
> 
> If this new check is also needed for the PMIPv6, then I think 
> PMIPv6 requires a new option to carry the CoA used for 
> signaling (address of the CP) inside the ESP protected part 
> of the message. Then the Alt. CoA option can be used to carry 
> the address for the PMIPv6 tunnel endpoint (address of the 
> UP). Never the less, I think that the CP needs to know the 
> address of the UP to add it into the Alt. CoA option, so I 
> guess it would be doable to use the same UP address also for 
> signaling (as a source address of the PBU)...
> 
> BR,
> 
> Heikki

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Feb 2008 17:18:33 +0100

Francis,

>   ("on" ::= perform the check and reject the BU when it fails).

OK -- thanks for this. I actually already changed this due to someone
else's comment. The text now reads:

"If the address in the Alternate Care-of Address option is not the same
as either the home address or the Source Address field in the IPv6
header of the Binding Update packet, then ..."

Jari