Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated

From: [email-masked]
Date: Thu, 18 Jul 2002 00:46:40 +0300

Hi Michael,
>  > 	then I see no reason for the MUST.
> 
> Sez RFC 2119:
> 
> 6. Guidance in the use of these Imperatives
> 
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.
> 
> Given that MIPv6 will interoperate without binding
> code in CN's, it looks pretty much like a SHOULD
> to me. Indeed, the protocol would not be robust if
> it didn't consider the case of a non-conformant CN.

I think we want to ask is, is it the right thing to do?  For 
proper protocol functioning, will this lead to the correct
behavior.  If we think it is important, the MUST is OK.  The
spec does contain a mechanism to support existing implementations
of IPv6, which means the protocol designers are doing their
jobs.

As I see it, we should focus on the behavior & if it is the
right thing to do, then we should do it.  

John

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 Jul 2002 15:21:46 -0700 (PDT)

> of IPv6, which means the protocol designers are doing their

   I think we're straying into a "good" as in
   "good for the overall health of the Internet"
   kind of good, rather than a "good" as in will
   the protocol operate correctly. For the former,
   I think you need to have extremely compelling
   motivation, as well as a lot of evidence that
   the health of the net will be imperiled if *all*
   nodes don't implement a particular function, which
   is what is at issue here.

   Frankly, I don't think that there is any evidence
   that the net would be substantially harmed if RO
   wasn't widely implemented and/or enabled. Indeed, 
   I think  there's good reason to believe that many/most
   nodes will not enable RO even if their kernel
   implements it. In some cases, it's likely to be
   a nice and useful optimization, but I really
   don't see it as a "if we don't do this the net
   will fall apart". As such, SHOULD seems like it
   strikes the right balance.

	       Mike

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Jul 2002 16:34:56 -0700

Mike, 

RO is a SHOULD, it is not a MUST in the current draft. we were 
not talking about route optimization. we were talking about 
processing a HAO. in the current spec HAO MUST be processed but 
not accepted if it cant be verified. verification can be in the 
form of checking for a valid BCE (created securely), IPsec 
protected data session, same trusted domain (where you dont 
expect people to do reflection attacks), the tagging proposal 
from Rajeev and Charlie, smart ingress filtering from Francis 
Dupont, etc...

processing a HAO is simply replacing the source address with
the contents of the HAO. earlier it is used to be a MUST without
the verification step. IPv6 WG was okay with that. but people 
indentified some reflection attacks that are possible if you 
blindly accept unverified home address option. so now, it is a
MUST with the verification step.

regards
Vijay

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 Jul 2002 16:55:23 -0700 (PDT)

> from Rajeev and Charlie, smart ingress filtering from Francis 

   Oh, OK. Sorry about that. Still if the code
   isn't in the CN, the MN should still be able
   to operate correctly, right? That still seems
   to me to be a SHOULD rather than a MUST for the
   same reasons in my reply to John.

   I guess the long and short of this is that I'm
   somewhat skeptical of putting general node
   requirements in the MIP draft since it's
   probably not the first place one would be
   looking to figure out if they were an IPv6
   compliant node. If it's really, really vital
   for the health of the net, yadda, yadda, it
   would be better to put it in a general v6 node
   requirements RFC, don't you think?

		Mike

---

From: [email-masked]
Date: Thu, 18 Jul 2002 09:12:50 +0900

>MUST with the verification step.

	IPv6 wg OKed HAO in draft 5 or 6.  HAO changed a lot since then,
	and i think it not reasonable for you to think that new-HAO is also
	OKed automaticalliy.

itojun

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Jul 2002 17:23:40 -0700

>         and i think it not reasonable for you to think that new-HAO is also

new-HAO?? the format has not changed. neither has the processing.
it is still a destination option. how is it new? infact it has 
been made secure by the new verification step.

infact, (IMO) there is no need for this new verification step if
we have smart ingress filtering as described by Francis Dupont
in
http://www.ietf.org/internet-drafts/draft-dupont-ipv6-ingress-filtering-00.txt.
Francis is probably around somewhere. can you please talk to him?

Vijay

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 17 Jul 2002 20:27:32 -0400

i'm in violent agreement.  HAO processing should not be a MUST.

HAO is not useful without verification and largely pointless unless
you're doing route optimization and can support a binding cache which
is large enough to be meaningful.  

Given that there's already a way for a node to indicate "no thank you"
(icmp parameter problem) and given (like every other "interesting"
extension we've attempted at the IP layer) that there will likely be
HAO "black holes" due to firewall policy and/or dusty embedded code, I
don't see the value of forcing nodes to even spend the extra effort to
parse enough of the HAO to generate a different error.

MN's will need to have code to parse the parameter problem form of the
error; why burden them with additional code to parse the other way to
encode the error message?

					- Bill

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 17 Jul 2002 17:35:15 -0700

Hello Itojun,

The home address option is the same in format as the
previous version.  The additional requirement now is
only that now it's required to be secured somehow.

Regards,
Charlie P.

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Jul 2002 17:38:16 -0700

> is large enough to be meaningful.

the point is this verification can be done in many ways. 

the point is processing of HAO gives you triangular routing,
which is much better than reverse tunneling.

talking about "black holes", the combination of reverse tunneling
and route optimization is likely to cause loss of packets.

with triangular routing and route optimization, you dont lose 
packets.

anyway, I dont want to get into the argument, triangular routing Vs
reverse tunneling.

regards
Vijay

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 17 Jul 2002 20:56:32 -0400

> the point is this verification can be done in many ways. 

but a correspondent node may only run services which won't benefit
from route optimization (i.e,. "hit and run" short exchanges typical
of a DNS server).

Let's assume the measured binding cache hit rate is 0% for a
particular server -- doens't it make sense from an efficiency
standpoint to be able to disable the binding cache and the HAO
verification on that server?

				- Bill

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Jul 2002 18:01:35 -0700

> verification on that server?

have you read the latest MIPv6 spec? there is an explicit code
in the Binding Ack which says "Route Optimization unnecessary
due to low traffic". the CN just has to refuse the binding with 
this code.

the spec also says the MN should not run route optimization if
the traffic is low/short. it can use its CoA.

regards
Vijay

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 17 Jul 2002 21:09:27 -0400

> have you read the latest MIPv6 spec? 

I have, in fact read the spec.

> there is an explicit code in the Binding Ack which says "Route
> Optimization unnecessary due to low traffic". the CN just has to
> refuse the binding with this code.

So, existing nodes will reportedly refuse the binding with an "icmp
parameter problem" message.  Why do we need a second encoding for the
same message?  Isn't it better to just have one encoding?

						- Bill

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Jul 2002 18:25:20 -0700

> same message?  Isn't it better to just have one encoding?

are we mixing up route optimization and HAO? 

the first encoding is for earlier IPv6 implementations.

the second encoding is for nodes (which normally support RO), that
dont want to do RO currently for some reason.

Vijay

ps: I trimmed the cc list

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Jul 2002 04:24:29 +0200

In your previous mail you wrote:

=> this is not true, now the HAO must be verificable/verified.

=> this solution was rejected by the DT... In fact even the verification
concept (from a Charlie Perkins' attempt to avoid mandatory BCE check)
is at the margin of the DT decision.

Regards

[email-masked]

PS: I believe Pekka can summarize his ideas about CoA stuff at the
alternate security of Mobile IPv6 bar BOF.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Jul 2002 04:32:57 +0200

=> this battle was lost some months ago. You can even get some
people who don't believe the Internet is a metric space
(i.e., verifies the triangulat inequality)!

=> so do I.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Jul 2002 05:39:45 +0300

>    requirements RFC, don't you think?

That _is_ actually the intention. We tried to formulate
section 8.2. (RO requirements) in the MIPv6 draft so that
it describes what you have to do to support RO, but not
when you have to support it. And we are expecting the node
requirements document to say MAY/SHOULD/MUST for the RO
feature. I think that's the right place to make the
determination. Ok?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Jul 2002 05:50:26 +0300

> been made secure by the new verification step.

The processing has changed in the sense that there is a new
verification step. Basically, we don't accept unverified HAOs,
either an SA or RR BCE must exist before they can be used.
This limits in a sense the use of the HAO in a completely free
way, as it used to be. (The most efficient routing case, RO,
is of course still supported and that's what we hope will be
used in most cases.)

(Back in the old versions of the draft, HAO needed to be a MUST
because otherwise interoperability would have failed.)

Jari

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Jul 2002 09:25:39 -0500

Michael,
  I do not understand why you are insisting on SHOULD? If IETF is not 
against having such MUSTs as in this case, let's have it. How can a 
revolutionary technology such as MIPv6 allow HA reverse tunneling like 
MIPv4 does?
  Another benefit will be to mandate HAO in any new implementations. 
Becasue of all these, I think that we should (or MUST) keep the MUST 
there, what the heck?

Regards,

-- 
Behcet

---

From: "Pascal Thubert" <[email-masked]>
Date: Thu, 18 Jul 2002 23:51:13 +0200

Face it: Many of today's large web servers will not want to maintain binding
caches. Because:
- They are clustered (see my previous mail on this thread)
- Visits are short and unrelated (the caches are not reused)
- RR reduces the throughput and the response time
- They may even blindly accept the Home Address option since the AAA takes place
at session level anyway using cookies and such.

How much of the global IP traffic does this represent today? What will mobile
devices do at least in the short term? We must provide a way for servers to
simply and politely decline RO. We may want to permit triangular routing. The
minimum we can do to ease IPv6 transition is at least to allow the current v4
applications to run in equivalent conditions.

It's a SHOULD.

Pascal

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Behcet Sarikaya
Sent: Thursday, July 18, 2002 4:26 PM
To: Michael Thomas
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated

Michael,

Regards,

--
Behcet

---

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Jul 2002 00:08:03 +0300

> - RR reduces the throughput and the response time

The current spec allows CNs to decline a RO/RR request.
This is of course necessary, we couldn't mandate that they
have sufficient memory etc. in all cases to handle these
requests.

> at session level anyway using cookies and such.

Most likely we can't do this. Earlier analysis indicated that unverified
home address option could lead to reflection attacks.

> applications to run in equivalent conditions.

Yes, and they can decline RO already now. Triangular routing will only be
allowed under a special condition (existing SA), which I think is probably
not compatible with your scenario of web servers.

> It's a SHOULD.

I'm not really arguing against that...

Jari

---

From: "Pascal Thubert" <[email-masked]>
Date: Fri, 19 Jul 2002 11:16:47 +0200

Hi Jari:

What I'm trying to get here:

1) SHOULD in 9.1. I support a requirement introduced in this thread. The
requirement is to legalize hosts that would not support MIP for valid reasons. I
provided examples where I think it's needed. I also believe there should be a
little rewording in section 9.1 to come with it.
2) Minimize the content of the SHOULD. I propose a slight change in the draft in
order to decline RO at RR test time in an architected fashion as opposed to side
effect of ICMP errors. At this point, the binding flow is not part of the SHOULD
anymore.

Since 9.4.6 should not occur, I suppose that an ICMP error would be fine in that
case. The problem is that the politically correct way to decline RO at the
moment seems to be binding Ack with code 130   Insufficient resources
(correct?), which requires support for BU. Since we are foreseeing the
overloading of the RR test as a capability negociation mechanism (e.g. C1),
could we not just architect something to negotiate Bind capabilities there
already?

The discussion about whether binding cache and Home Address option are
necessarily coupled is yet an other one, which is related to C1 and C2. I tried
to give an example where they could be separated by using piggy backing instead
of an SA, but that discussion is not needed right now. I started that to
decouple the RR test and the binding flow a little bit more.

Pascal

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jari Arkko
Sent: Thursday, July 18, 2002 11:08 PM
To: Pascal Thubert
Cc: Behcet Sarikaya; Michael Thomas; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated

Jari

---

From: [email-masked]
Date: Sun, 21 Jul 2002 07:41:37 +0900

>only that now it's required to be secured somehow.

	no it is not.  also option type # got changed
	draft 04-06: type, length and an IPv6 address, type # = "196???"
	draft 07: type, length, an IPv6 address and suboptions,
		type # = "196???"
	draft 08-16: type, length, an IPv6 address and suboptions, type # = 201
	draft 17-18: type, length and an IPv6 address, type # = 201

	note that existence/non-existence of suboption will affect validation
	of incoming messages.

	no wonder vendors ship without HAO support, it is impossible to
	support something that changes this often.  as for *BSD/KAME, it is
	decided that we won't merge anything related to mobile-ip6 into main
	*BSD distribution until mobile-ip6 becomes RFC (so it won't show up
	onto ExtremeWare, JunOS, MacOS X, ...).
	if i remember correctly WinXP is shipping with HAO support, i'm not
	sure which draft it is based.

itojun

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 21 Jul 2002 08:55:43 -0700

Hello Itojun,

Your argument is not very convincing:

>         draft 07: type, length, an IPv6 address and suboptions,

These drafts are many years old.  I reckon the base IPv6 specifications
have a number of features that have changed more than the HAO
option has changes since these very old drafts.

>         draft 17-18: type, length and an IPv6 address, type # = 201

There is no difference.  There were no valid suboptions defined for
earlier drafts, even though the field was shown as possibly there
for future suboptions.  In the drafts after 16, a reasonable implementation
should still allow for future suboptions that don't exist yet.

>         sure which draft it is based.

I hope things change after we have Proposed Standard and a number
of interoperable implementations.  I regret that your experience has
caused discomfort.  However, it is the nature of IETF Internet Drafts
that they often change.  Even Proposed Standards change.  In fact,
if I remember right, there is even now some movement towards
changing the Draft Standard about site local addresses.

Regards,
Charlie P.

---

From: [email-masked]
Date: Mon, 22 Jul 2002 06:28:11 +0900

>should still allow for future suboptions that don't exist yet.

	i don't think draft 17/18 implementation will allow suboptions.
	see the 17/18 languge about HAO option length.  if we follow this,
	there's no chance we will see suboptions.
	you have to take a security stance.  having loose inbound packet
	validation == more chances for security vulnerabilities.
	draft 17/18 implementations that allow option length != 16 are buggy.

>      Option Type
>
>         201 = 0xC9
>
>      Option Length
>
>         8-bit unsigned integer.  Length of the option, in octets,
>         excluding the Option Type and Option Length fields.  This field
>         MUST be set to 16.

>changing the Draft Standard about site local addresses.

	when moving from PS to DS, they *remove* functionality.  they usually
	don't mandate new things.  your example above does not convince me.

	i'm very concerned about the use of MUST for HAO since mobile-ip6 draft
	18 is trying to mandate new thing to all IPv6 (RFC2460) implementations.
	SHOULD for HAO is okay for me, but MUST for HAO is unacceptable at
	this stage of RFC2460-based IPv6 deployment.

itojun

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Jul 2002 05:39:45 +0300

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 22 Jul 2002 18:46:40 -0700

Itojun,

there have never been any suboptions defined for the home address
option.

>         note that existence/non-existence of suboption will affect validation

when there is no vaild sub-option defined, I would expect one 
to write code which would drop the packet, if the packet came 
with some sub-option.

>         support something that changes this often.  

it has been an internet draft so far. people who implement internet
drafts do it knowing very well that it could change.

> as for *BSD/KAME, it is

okay. fair enough.

regards
Vijay

---

From: [email-masked]
Date: Tue, 23 Jul 2002 12:06:07 +0900

>to write code which would drop the packet, if the packet came 

	one problem is that draft 07-16 are silent about HAO processing
	when unknown suboption is attached.  from the language in draft 16,
	i guess receiver should ignore suboptions if they are unknown to them
	(otherwise we cannot allow "future extension" - old implementation
	will not be able to talk with new implementation), but i could be wrong.

	anyways, the above is not the main focus of this discussion.

itojun

---
      Sub-Options

         Additional information, associated with this Home Address
         option, that need not be present in all Home Address options
         sent.  This use of sub-options also allows for future
         extensions to the format of the Home Address option to be
         defined.  Currently, no valid sub-options are defined for use
         in a Home Address option.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 23 Jul 2002 03:27:36 +0200 (CEST)

> the point is this verification can be done in many ways. 

Vijay,

I don't think any of these "many ways" are "MUST implement by every IPv6 node"
thus it seems odd that the HAO itself is "MUST implement by every IPv6 node".

  Erik