Subject: RE: [mobile-ip] protecting BUs

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 11 Oct 2001 11:45:39 +1000

Hello Jari, 

> > No! No! A *router* on the path should only examine the IP header *and*
> > check if the immediate next-header is hop-by-hop header (in which case
> > it may need to look into this).
> > 
> > *Routers* do not care whether next header field is unknown to them.
> > 
> > The rule about dropping a packet with unknown extension header
> > conserns only the end-node.
> 
> This is the obviously the more interoperable way to interpret this.
> If all did so, there would be no problem with forwarding boxes,
> as long as no-one suggests a new value before routing header, source
> routing nodes would otherwise suffer. It is advisable trying to
> read RFCs and new proposals "the other way around" pondering what are
> the worst case interoperation implications their interpretations allow.
> 
	=> That's fair, but where do you get that impression when 
	reading RFC 2460 ? I'd like to get some idea because if 
	that is the case we should really address it on the IPng
	list. If your interpretation of the RFC is shared by other 
	implementors we should really address this. 

	Hesham

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 10 Oct 2001 21:07:58 -0700

Hesham,

>      implementors we should really address this.

If one reads the last paragraph of page 6 one can read it two ways:

Either: "With one exception, extension headers are not examined or processed
by any node along a packet's delivery path.." meaning hop-by-hop options
header. Then, "If, as a result of processing a header, a node is required
to proceed to the next header, but the Next Header value in the current
header is unrecognized..", could mean: possible existence of hop-by-hop options header "must be examined" resulting in that after IPv6 header
the "required to proceed" condition is met, but the Next Header is unknown,
this would result in the discarding rule. There is, luckily, even in this
case, the possibility to ignore this.

Or: That there is not h-b-h next header invalidates the "must be examined"
rule and one could skip an unknown number (just forwarding the packet
irrespective what garbage there is at its end). I hope this could be
the correct interpretation since the h-b-h must immediately follow the
IPv6 header. Unless someone challenges this order rule with a new header,
or someone comes with a new h-b-h option requiring proceeding to something
else, this could hopefully be the "right interpretation".

If someone observes the former, it would risk that there are boxes that
drop packets with new unknown next headers. In the latter there would not
be. Our boxes do the right thing, but can it be guaranteed so do others?
This could have been clearer in the text saying that routers must ignore
next headers other than h-b-h. But, this would not be the first RFC in
routing where "well-known" implementation guidelines help interpret the
actual text.

-Jari

---

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Oct 2001 10:25:45 +0300 (EEST)

> routing where "well-known" implementation guidelines help interpret the

This is, by no means, a trivial issue.

I'm not sure where the new Destination Options are recommended to be
placed in the header chain but coupled with e.g. Routing Header w/ traffic
engineering/multihoming/... it could get ugly:

dst addr=some non-MIPv6 router
src addr=some MIPv6 node
home address option=MIPv6 node HA
routing header=CoA of a MIPv6 node, segments left=1

Here, if HA/BU/Binding Ack/... etc. are placed before routing header,
'some non-MIPv6 router', when processing the routing header chain, will
notice an unknown header type, drop the packet and send back ICMP error.

Could get ugly.

Also, RFC2460 seems ignorant of IPv6 firewalls/packet filters which most
assuredly would like to process upto e.g. TCP header, therefore also
noticing an unknown header type.  The expected behaviour can be quickly
deduced though.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "Jari T. Malinen" <[email-masked]>
Date: Thu, 11 Oct 2001 10:49:49 -0700

Pekka Savola wrote

> This is, by no means, a trivial issue.

I guess it might be safe to conclude that depending on your ordering rule
and semantics for a new header type you can in general break all,
some, or no routers (before h-b-h, between h-b-h and rthdr, after rthdr).
Hence, a new destination header needs to be after routing headers.

> noticing an unknown header type.  The expected behaviour can be quickly

This is also a bit tricky: If FWs follow RFC2460, corporate networks
cannot receive new binding updates, if we relax it on filtering rules,
they can (requires changing old strict-RFC2460 FW boxes), right?
So is this a requirement for change in case a new dst hdr type is
accepted?

-Jari

---

From: Michael Thomas <[email-masked]>
Date: Thu, 11 Oct 2001 11:01:28 -0700 (PDT)

Uh, this is an interesting discussion and all, but
nobody's recommending that we have a new
intermediate header. The BU would be the final
header, and could just as easily be on a well
known UDP port instead of a new protocol number.

	  Mike

---

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Oct 2001 22:59:18 +0300 (EEST)

> Hence, a new destination header needs to be after routing headers.

After routing header, definitely, as Hesham noted.

> So is this a requirement for change in case a new dst hdr type is

As a matter of fact, to clarify, looking at RFC2460 4.2. and MIPv6 -14..

BU, BAck, HA, etc. are indeed Destination Options Header options, not
extension headers (the interpretation under debate with ipng@ was about
ext header processing IIRC), there is some hope for some of them at least.

If the option type begins with '00', the specified behaviour is to skip
over the option and continue processing if the option was not recognized.

So it would appear:

BU: 198 ==> whole packet dropped if the option is not recognized
BAck: 7 ==> ok
Breq: 8 ==> ok
HA: 201 ==> whole packet dropped if the option is not recognized

How the firewalls would interpret this is up to the implementors, I
suppose.  I hope to be able to write an I-D about new challenges of IPv6
for firewall/packet filter implementors at some point, unless there's
already some work going on on the subject.

---

From: "Jari T. Malinen" <[email-masked]>
Date: Thu, 11 Oct 2001 13:56:05 -0700

> ext header processing IIRC), there is some hope for some of them at least.

Yes, depending on whether they are mandatory or optional in practice
(see below).
 
> suppose.

This is how things look in practice when universal support is missing.
Once new headers are introduced it is even harder to convince every box
to do this soon. Originally I guess it was thought every node is a CN
understanding BU and HA. Then, all the above would be accepted always,
the optimistic interpretations of having a MUST in a standard.

> I hope to be able to write an I-D about new challenges of IPv6

This would be of interest to many people, especially if components
of IPv6 such as moblity much longer are in flux. Also, given that routers
(by practical meaning of the term, not by RFC2460 definition..) should
allow for future extendibility of IPv6, more generic rules how to
cope with optional, or MUST extensions not yet such in practice,
would be good to have.

-Jari

---

From: "Jari T. Malinen" <[email-masked]>
Date: Thu, 11 Oct 2001 14:06:58 -0700

> known UDP port instead of a new protocol number.

I believe this would make it practically impossible to
even consider piggybacking. At least with UDP, you can't
have two upper layers (if by UDP port you mean inserting
a UDP hdr). I believe the potential new header should be
intermediate, and after a routing header. Even better if
no new header would be needed.

-Jari

---

From: Michael Thomas <[email-masked]>
Date: Thu, 11 Oct 2001 14:30:13 -0700 (PDT)

> no new header would be needed.

This entire discussion started because you said
there was a problem with a new protocol type being
proposed to allow use of IPsec. The proposal was
to eliminate piggybacking too, mainly because RFC
2401 doesn't have the ability to deal with options
as part of the selector mechanism. Thus this
entire discussion is moot.

		     Mike

---

From: "Jari T. Malinen" <[email-masked]>
Date: Thu, 11 Oct 2001 15:26:47 -0700

> entire discussion is moot.

Let us call "problem" as some requirements for change introduced.
For hosts they undisputably exist, for routers, excluding
firewalls, maybe not. Introducing new headers may require some
discussion in the ipv6 wg, though.
I believe Jari Arkko did a nice work outlining 4 alternative
ways of protecting the BU. All of them do not call for the
removal of piggybacking, nor for the addition of a new hdr.
And if one adds a header, why design it so that piggybacking
becomes impossible if a more flexible design is possible.
But, maybe it is good stop discussing it here, I am sure
we will still hear enoug of this from implementors etc.

-Jari

---

From: Michael Thomas <[email-masked]>
Date: Thu, 11 Oct 2001 18:05:50 -0700 (PDT)

Jari T. Malinen writes:
 > removal of piggybacking, []

   The primary reason the analysis of piggybacking is in
   there is because removal of piggybacking is what is
   necessary to make IPsec work. Hence, this entire 
   discussion is moot because nobody's talking about
   creating a new middle header.

	    Mike

---

From: "Jari T. Malinen" <[email-masked]>
Date: Thu, 11 Oct 2001 19:12:29 -0700

>    creating a new middle header.

For alternative 4 one could imagine a variant with piggybacking
and IPsec mutually exclusive. New hdr type for the selector problem,
middle header to enable piggybacking when using application specific
protection.

-Jari

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 15 Oct 2001 11:40:18 -0400

Michael Thomas wrote:

>    necessary to make IPsec work.

So what is wrong with having BU/Back on separate packets possibly on a
different protocol field? This is how Mobile IPv4 works. Afterall
BU/Back are registration, i.e. control packets so there are conceptual
gains, i.e. protocol design is better,  to be made this way.

> Hence, this entire

Why is the discussion moot?

Regards,

--
Behcet