Subject: [mobile-ip] protecting BUs

From: Jari Arkko <[email-masked]>
Date: Wed, 10 Oct 2001 16:12:45 +0300

Dear All,

I have written a draft that discusses the various
solutions on the table for the protection of
of Binding Updates after BAKE etc has done its
job.

The goal of the draft is not so much to propose
any specific solution, but rather to document
alternatives, their advantages/disadvantages
and issues brought up in the mailing list. My
hope is that this will be useful in deciding how
to move forward. First, we have to agree that
we have all solutions, know their properties,
and that the solutions actually work. I'd very
like to wellcome all feedback on these aspects
of the draft (as well as of course comments
on which solution should be chosen and why).

The draft has been submitted to the IETF, but before
it makes it to the official directories you can access
it at

http://www.piuha.net/~jarkko/publications/draft-arkko-mipv6-bu-security-00.txt

Jari Arkko
Ericsson

---

From: "Jari T. Malinen" <[email-masked]>
Date: Wed, 10 Oct 2001 08:30:26 -0700

Hello,

Nice piece of work! Here very briefly some comments:

- On your analysis on piggybacking: A simple question: Given that
  a multitude of applications (browsing, streaming, messaging)
  over IP can have rather large variance in upper layer packet size,
  could it be that piggybacking overhead actually is a rather
  insignificant factor and the upper layer variance a much bigger
  headache? To get past that, one should be able to control the type
  of applications over such tight channels. If that is possible,
  why not consider it possible to simply recommend enabling/disabling
  of piggybacking, say, based on when using small packet size
  variance (streaming) applications? Maybe this should also be mentioned
  in the discussion?

- Addition of a New Next Header Value: Are you sure it can be done
  without any out-of-mobileip standardization work? Shouldn't there
  be analysis on the change implications of this (like you have well
  done for, e.g., IPsec modifications)? Quoting RFC2460 [Page 6]:

  > 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 by the node, it should discard the packet and send an
  > ICMP Parameter Problem message to the source of the packet, with an
  > ICMP Code value of 1 ("unrecognized Next Header type encountered")

  If any node (host or router) encounters IPv6 header, it should at least
  consider whether there is a next header with a hop-by-hop option. If
  immediately in the IPv6 header the next header field has a unknown value,
  the node cannot avoid reading this value if it checks for the h-b-h,
  shouldn't it then discard the packet according to the above?

- On other requirements for change, should it not be more clearly
  indicated that the use of home address option in all IPsec cases
  (6.2 - 6.4) mean an off-the-shelf "black box" IPsec module needs to be
  modified? If a packet is passed to such an implementation, isn't it
  currently the case that it does not know home address option but uses
  the care-of-address in the IPv6 header instead? It sounds now as if
  6.2 did not require changes (we can use current version of AH but not
  exactly current implementations, right?).

BR,

-Jari

---

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

Just some minor comments (piggybacking):

There seem to be no clear comment on that when sending data and BU packets
separately one also reserves a L2 channel more often. In addition to the
L3 payload issues, this can be a significant factor where piggybacking
can result in savings of last hop bandwidth.

[draft Ch. 7.5]
>     Firewalls  and  other similar devices should be able to process piggy-
>     backed packets, even if they have BU options in them. If they  do  not
>     let such traffic through they will also not let regular Mobile IP Home
>     Address options through, blocking all traffic. If the BUs are sent  in
>     separate packets, the firewalls have to have rules to allow this traf-
>     fic in.

Since there need to be home address options in BU packets,
and if a firewall has rules for data packets based on home address option,
why would BU packets need separate rules?

> There are no key distribution mechanisms currently designed to key -14 BSAs
is a bit strong statement: would it be more like
There are currently no established rules for keying -14 BSAs for strong
authentication using currently available key distribution mechanisms.

There is work in progress on many key distribution schemes in e.g. with some
extensions to the aaa; also one wonders why should, say, ipsra mechanisms
be completely unable to key a BSA on every movement, to provide an
independent one-time key for each BU? They would not be optimal at all,
but isn't IKE also a bit heavy on signaling?

BR,

-Jari

---

From: Markku Savela <[email-masked]>
Date: Wed, 10 Oct 2001 20:54:58 +0300

> From: "Jari T. Malinen" <[email-masked]>

>   shouldn't it then discard the packet according to the above?

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.

-- 
Markku Savela <[email-masked]>

---

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

Markku Savela wrote:
> >   immediately in the IPv6 header the next header with unknown value,

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.

-Jari

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 11 Oct 2001 10:51:01 +0200 (CEST)

>   shouldn't it then discard the packet according to the above?

You are talking about a router, right?

If the packet isn't explicitly addresses to the router then the router
should just check whether the nextheader = hbh. It must not care about
other nexthdr values.

If folks think routers should reject packets in the forwarding path
with an unknown nexthdr, how could we possibly deploy a new transport
protocol like SCTP? It has a new nexthdr value. 

So please tell me that I'm reading your note incorrectly.

  Erik

---

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

> So please tell me that I'm reading your note incorrectly.

A new upper layer is easy since it is at the end of the packet,
I was more thinking in general terms if you add a new header to
any place in the ordering. Before routing hdr and esp. before
hop-by-hop there would be problems.

-Jari

---

From: Markku Savela <[email-masked]>
Date: Thu, 11 Oct 2001 21:53:53 +0300

> hop-by-hop there would be problems.

I repeat, *ROUTERS* only look at IP header and possibly
hbh.

ROUTER is not looking for routing header in IPv6. That is the function
of the node identified by the destination address of the IP header.

Firewall is something else than a ROUTER. If it wants to look through
all headers, it needs to know them. But, "core" routers do not need
this info.

---

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

> of the node identified by the destination address of the IP header.

Uhh.

When a packet with routing header reaches the destination (possibly a
ROUTER, e.g. in certain traffic engineering/multihoming etc. needs), it
will need to know the type of all headers before Routing Header so it can
swap the addresses etc.

One has to keep this in mind if you'd put a new shiny header before
routing header.

> all headers, it needs to know them. But, "core" routers do not need

Sure.  You must be aware of how RFC2460 was supposed to be implemented to
get this right.

In practise firewalls are routers, because they surely are _not_ hosts as
they perform forwarding between interfaces.

It does not matter if the firewalling happens in core network or elsewhere
in the packet trail (e.g. near the border/access routers) -- if the packet
is dropped, it is dropped.

-- 
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: Erik Nordmark <[email-masked]>
Date: Tue, 16 Oct 2001 14:36:11 +0200 (CEST)

> hop-by-hop there would be problems.

Huh?

How can the supposed router know where the end of the packet is
when the h-b-h header contains a next hdr value which the router
doesn't recognize? The next hdr = 254 could be a new transport protocol
or a new intermediate next hdr, but if the router doesn't know 254
it doesn't know.

In any case, if everybody follows this advise
in RFC 1122 the problem goes away as far as I can tell.

      1.2.2  Robustness Principle

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability [IP:1]:

                "Be liberal in what you accept, and
                 conservative in what you send"

  Erik

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 16 Oct 2001 11:07:26 -0700

> or a new intermediate next hdr, but if the router doesn't know 254

The comment was about ordering rules; if a new header were to be
required too early in the ordering, it would change how a node needs to
scan the packet before it sees e.g. hop-by-hop header or in case a node
does source routing, a routing header. If the packet is beyond routing
header by the ordering rules, it's transparent and a router or
source-routing node does not ever need to look its type. So, as you
say, a legacy node would not know unknown type, it would not observe
the new rule and not go beyond the packet. E.g. if a new header would
be before routing header by its ordering rule, a source routing node 
wouldn't scan to the routing header thus missing it.

But as discussed, this wouldn't be a problem if a new header is beyond
routing header in its ordering rules (such as an upper layer whose ordering would require it to be at end).

>                  conservative in what you send"

Very much agreed, which kind of brings me back to the start of this
discussion. Though new headers could be nice, avoiding new headers
would be even more conservative. In case of protecting the BU with
IPsec, this would suggest favoring the UDP port approach over a new
header type.

And, if this is applied to piggybacking, accepting a piggybacked BU
is liberal, sending one would need dynamic enabling/disabling of it.
In case of IPsec, disable it, add the UDP port, in case of application
specific protection, allow it, do not add that UDP as upper layer.

-Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 16 Oct 2001 21:57:34 +0200 (CEST)

> source-routing node does not ever need to look its type.

What about packets that don't have a routing header?
The ordering rules doesn't require that every extension header be present
in every packet.

Thus if a packet with IPv6 header and h-b-h header arrives at the router
and the h-b-h header has a next hdr = 254 (or some other undefined value)
what do you think the router will do?

Same question if the packet has an IPv6 header with next hdr = 254.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Oct 2001 23:18:29 +0300 (EEST)

> what do you think the router will do?

In case dst=Router:

Discard the packet as it cannot process it far enough to see whether it 
should process it itself or keep forwarding (rt header).

Else:

Forward the packet.  Router only cares about h-b-h, and is allowed to be 
present only once.

> Same question if the packet has an IPv6 header with next hdr = 254.

In case of dst=Router:

Discard the packet as nxt header value is unknown, and further processing 
is not known.

Else:

Forward the packet, because next hdr was not 0, thus indicating h-b-h and 
must-be-processed-by-router.

---

From: "Jari T. Malinen" <[email-masked]>
Date: Tue, 16 Oct 2001 14:32:44 -0700

> Same question if the packet has an IPv6 header with next hdr = 254.

I believe Pekka explained the practical operation; the ordering rules
afffect when one needs to look ahead (beyond other possible packets)
to see particular packets.

-Jari