Subject: (ngtrans) RE: Directed broadcast in IPv6

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Dec 2001 23:37:55 +0200 (EET)

(added ngtrans@)

On Mon, 10 Dec 2001, Tony Hain wrote:
> For starters your assumption that you can reach all nodes on a remote
> link is broken, because you can't know the subnet mask, therefore the
> appropriate directed broadcast. The short answer to your question though
> is that the broadcast capability was explicitly removed from IPv6, so
> you can't.

However, there are potentially issues with transition mechanisms,
especially those using some form of automatic tunneling (which is one
reason why this, automatic bridging systems etc. may get to be a
headache).

Suppose IPv4/6 router is also a 6to4 router for a subnet, so it must 
accept IPv6-in-IPv4 packets from everywhere.

Suppose someone sends in a packet with:

src=1.2.3.4
dst=<ipv4 of the router>
protocol=41
 src6=fec0::1 (or 3ffe:ffff::1 or whatever)
 dst6=ff05::1 (or ff02::1 or whatever)
 ...

With varying levels of different src6/dst6 values.

It's possible that implementations use a "same-zone" check with non-global 
addresses, but this may or may not be the case.

This is especially nasty if hosts would listen to ff0e::1 (global
all-hosts) address (even though it would not be globally routable); there
would not be such restrictions on same zone.

The issues with automatic tunneling are discussed a little bit in:

http://www.ietf.org/internet-drafts/draft-savola-ngtrans-6to4-security-00.txt
 
(by the way, comments would be welcome ;-)

-- 
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: "Tony Hain" <[email-masked]>
Date: Mon, 10 Dec 2001 19:52:02 -0800

> reason why this, automatic bridging systems etc. may get to be a
Automatic bridging systems are ha headache, and completely orthogonal to
IPv6.

> accept IPv6-in-IPv4 packets from everywhere.
This is not a requirement.

> addresses, but this may or may not be the case.
It was my belief that this was discussed in Dave Thaler's ID on
multicast over 6to4. It appears that the document expired due to an
oversight by the chairs... :(
I just talked to Dave and he will resubmit.

> would not be such restrictions on same zone.
According to 2373 your choice of multicast address is reserved to begin
with, but why wouldn't that be routable? You appear to have a model for
multicast over NBMA that assumes the lower layer is not global. I
understand there may be a problem with scaling the number of tunnels,
but this is not a protocol problem.

Your discussion about a 6to4 host seems to be implementation specific,
and there are implementations that do have the host aware of 6to4.

Your discussion about what should not happen are already in RFC 3056
security issues.

Your discussion of the disallowed addresses is in RFC 3056, specifically
the point that RFC 1918 addresses are not valid.

I have to go now, but the document seems to be based on some
misunderstanding of the existing 6to4 RFC, and the existing address
architecture RFC. If those are sufficiently unclear that several people
this document is needed to help, we should either revisit the text in
those, or move your document to a high priority work item to reduce the
confusion.

Tony

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Dec 2001 17:35:58 +0200 (EET)

> but this is not a protocol problem.

New addrarch draft says ff0e::/16 is global-scope.
 
I took this as an example of delivering packets to an IPv6 node when it 
might not be possible to do so directly (example: link-local addresses).

> and there are implementations that do have the host aware of 6to4.

Why would a host have any reason to be 6to4 aware?  I sure would like to
know more of this.  AFAICS that implementation wouldn't be honouring RFC 
3056 definition of 6to4 host:

         an IPv6 host which happens to have at least one 6to4 address.
         In all other respects it is a standard IPv6 host.

> Your discussion about what should not happen are already in RFC 3056

Some are, some aren't.  But the main point was, that RFC 3056 rules were a 
little abstract (and as a matter of fact, wrong in one sentence), so that 
they were basically unimplementable and rather non-understandable.  This 
is noted in the introduction.
 
> the point that RFC 1918 addresses are not valid.

Private addresses are just one, problem, there just for completeness.
 
> those, or move your document to a high priority work item to reduce the

I fail to see what misunderstandings those would be.  Only issue I can
come up with (for some portions) is how implementations inject packets
from tunneling to the IPv6 stack.  That is, can we assume that "same-zone"  
forwarding applies.  That is, site-local and link-locals would not be a
problem with tunneling.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Dec 2001 17:47:33 +0100

Pekka Savola wrote:
...
...
> is noted in the introduction.

There's no harm in an informational document making the RFC 3056 security
rules more explicit, although the details are certainly implementation
dependent. However, I can't find in your draft a clear reference to the
sentence in 3056 that you believe is wrong.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Dec 2001 17:39:52 +0100

Pekka Savola wrote:
...
>          In all other respects it is a standard IPv6 host.

A host that includes a router (or router-like functionality) can perfectly
well behave like a 6to4 router as far as the outside world is concerned. "6to4
aware host" is really a shorthand for this. 

  Brian

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Dec 2001 19:42:16 +0200 (EET)

> aware host" is really a shorthand for this. 

Ah ok, 6to4 routers are also 6to4 hosts by definition then.  IMO, an
inprecise definition.

(yeah, probably most "6to4 hosts" on dialup etc. are really 6to4 routers)

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 11 Dec 2001 09:42:24 -0800

> New addrarch draft says ff0e::/16 is global-scope.
Where? What I see on page 16 is:
    Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
                                     ...
                                      FF0E:0:0:0:0:0:0:0
                                      FF0F:0:0:0:0:0:0:0

   The above multicast addresses are reserved and shall never be
   assigned to any multicast group.

> might not be possible to do so directly (example: link-local
I am not seeing your scenario. Could you send a picture?

>          In all other respects it is a standard IPv6 host.
The RFC 3056 context of a 6to4 host is one that receives an RA which
contains a 6to4 format prefix. It is also possible that the host has no
IPv6 router, but includes that function within itself. In the strict
sense the functions are separate, but the fact that they are in the same
box results in the case where a 6to4 host may have a 6to4
pseudo-interface.

> That is, site-local and link-locals
> would not be a
> problem with tunneling.
Link local is not to be forwarded off link in any case, and I have
always believed that site-locals don't go out over the global tunnel
interface, but there doesn't appear to be a specific statement about
that in the current documents.

Tony

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Dec 2001 19:48:29 +0200 (EET)

> sentence in 3056 that you believe is wrong.

It's not noted in the draft, but it was mentioned on ngtrans list.

In security considerations:

                                                           A possible
   plausibility check is whether the encapsulating IPv4 address is
   consistent with the encapsulated 2002:: address.  If this check is
   applied, exceptions to it must be configured to admit traffic from
   relay routers (Section 5).  

The latter sentence makes no sense and is confusing, as the only packets 
coming from relay have the native source address, not 2002::/16, and 
destination need not be excepted if it is checked.

I haven't checked all of SecConsiderations with a microscope, but that 
one struck my eye immediately.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Dec 2001 19:27:22 +0100

> destination need not be excepted if it is checked.

Sorry, I think you are wrong. If the source of a packet is a normal
6to4 router, the outer IPv4 source address must be consistent(*) with the
V4ADDR of the source address in the embedded 2002:: packet. 
But if the source of the packet is a 6to4 relay, the inner source address
may be a native IPv6 address that would fail the consistency check,
so the check must be skipped. That's what the second sentence says.

(*) consistent does not mean equal. The real problem with this check
is that you need to know *all* the V4ADDR values that might be valid,
in multihomed cases. 

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Dec 2001 20:56:05 +0200 (EET)

> V4ADDR of the source address in the embedded 2002:: packet. 

This is an issue with multihomed, but that does not affect discussion
here.

Anyway, multihomed IMO probably should select IPv4 address that matches
matches the prefix.  I see little reason to support the asymmetry (one
6to4 prefix, multiple IPv4 addresses).  In multihoming scenario, this
would be useful only when one connection fails, but then the return 
packets could not be delivered anyway.

> so the check must be skipped. That's what the second sentence says.

The sentence refers to:

whether the encapsulating IPv4 address is consistent with the encapsulated 
2002:: address.

1) You cannot receive IPv6 packets from *relay* which have 2002::/16
prefix.  If you do, someone is using 6to4 improperly.  We agree on this.

2) How do you check that 3ffe:ffff::1 is consistant with an IPv4 address?

You cannot check *consistancy* unless the addresses are of form
2002:<anything at all> and <IPv4 anything at all>.  Only 2002 and IPv4 can
be compared.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Dec 2001 16:42:39 +0100

> This is an issue with multihomed, but that does not affect discussion

It has absolutely nothing to do with multihoming, except for my
footnote(*) on the meaning of "consistent".
> prefix.  If you do, someone is using 6to4 improperly.  We agree on this.

Actually, the relay (according to RFC 3056) is a 6to4 router that also has a
native IPv6 interface. It certainly can source 2002: packets from its own
site, as well as native source addresses from the native interface.
You can apply the consistency check, but not to relayed packets with
a native source address. 

> 2002:<anything at all> and <IPv4 anything at all>.  Only 2002 and IPv4 can

Yes. 3056 says nothing different. I see no error in the 3056 text.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Dec 2001 11:23:32 +0200 (EET)

>    assigned to any multicast group.

draft-ietf-ipngwg-addr-arch-v3-07.txt

2.7 Multicast Addresses
[...]
	scop is a 4-bit multicast scope value used to limit the scope of
	the multicast group.  The values are:
[...]
             E  global scope

> I am not seeing your scenario. Could you send a picture?

Consider Target Node T has two interfaces with two addresses, 
respectively: 2002:0102:0304::1 and 3ffe:ffff:1::1.  The first one is 
"public" and the second is "private".  3ffe:ffff:1::/64 is not routed 
except locally.

Target node T has not enabled packet forwarding between interfaces, or it 
is being strictly limited by firewall policies.

If Attacker A pings 2002:0102:0304::1 it works no problems.  If attacker 
pings 3ffe:ffff:1::1, there is no reply as the network is not reachable to 
the Internet on purpose.

Now, attacker A can craft a packet as follows:

ipv4 source=<something>
ipv4 destination=1.2.3.4
protocol=41
 ipv6 source=<something>
 ipv6 destination=3ffe:ffff:1::1
 [payload follows]

Target node T decapsulated the IPv4 packet and delivers the IPv6 packet to 
3ffe:ffff:1::1 without complaints.  This would not have been possible 
without automatic tunneling mechanisms.

This issue is similar to "Routing Header" discussion in:

http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01.txt

> box results in the case where a 6to4 host may have a 6to4

I wonder why this definition was chosen.  But regardless, the discussion 
applies, just imagine "6to4 host" being "6to4 host which is not 6to4 
router".  

> that in the current documents.

Addrarch 2.5.8 says site-locals must not be forwarded outside of site, and 
upon receipt, should be dropped.

A problem is that one does not know how tunneling is implemented.  If one 
receives a packet from a tunnel, does one apply all the same checks one 
would if the packet had come from the wire?  Or does the implementation 
somehow push the packet through in some quicker way?

Site/link locals are just a curiousity that might or might not work,
depending on the implementation; most of these apply to global addresses
as well, but would require more discussion of the topology.  There are
other issues, like being able to inject IPv6 packets with hop limit = 255
from anywhere in the Internet.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Dec 2001 11:52:57 +0200 (EET)

> You can apply the consistency check, but not to relayed packets with

I meant relay as a box that has relay functinality.  Local packets are of 
course fine, and the consistancy check applies there so that is no 
problem.

But the sentence IMO basically says:

"there are packets [referring to 2002 prefix] coming from relay which
must not be checked".

By referring to 2002, the consistancy check might not be performed for
_2002_ addresses (which it should not receive except for the local ones
where the check would apply), thus relays becoming a source for
inconsistant 2002 packets.

> Yes. 3056 says nothing different. I see no error in the 3056 text.

Ok, I guess this is one of those way of thinking issues; whether the 
'consistancy check' is basically:

1)

 consistancy_check(ipv6, ipv4) {
   if (bits 16-47 of ipv6 equal ipv4)
     return true
   else
     return false
 }

or:

2)

 consistancy_check(ipv6, ipv4) {
   if prefix of ipv6 is 2002 {
     if (bits 16-47 of ipv6 equal ipv4)
       return true
     else
       return false 
   }
   else
     return true  // because consistancy is not defined for non-2002
 }

That is, what's the defined consistancy between native ipv6 and ipv4 
addresses.

Thus skipping the consistancy check becomes a bit of a blur.

---

From: Robert Elz <[email-masked]>
Date: Thu, 13 Dec 2001 17:39:43 +0700

Date:        Thu, 13 Dec 2001 11:23:32 +0200 (EET)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | If Attacker A pings 2002:0102:0304::1 it works no problems.  If attacker 
  | pings 3ffe:ffff:1::1, there is no reply as the network is not reachable to 
  | the Internet on purpose.

Unless it is carefully filtered, it is reachable, just harder.  Relying
on failing to advertise routes as an alternative to filtering is folly.

  | Target node T decapsulated the IPv4 packet and delivers the IPv6 packet to 
  | 3ffe:ffff:1::1 without complaints.

If the address is supposed to be filtered, the filters need to apply
to decapsulated packets just as much as regular ones.   If you set up
(or permit) a tunnel to by-pass firewalls, you get exactly what you should
get (in many cases, that is sensible service...)

  | A problem is that one does not know how tunneling is implemented.  If one 
  | receives a packet from a tunnel, does one apply all the same checks one 
  | would if the packet had come from the wire?

One certainly should.   A tunnel interface is just an interface, the
same as any other - except that by having it (and having it available)
you know that you're admitting packets that other firewalls might not
have noticed, thus you need to use extra care with filtering.

  | There are
  | other issues, like being able to inject IPv6 packets with hop limit = 255
  | from anywhere in the Internet.

Huh?  if you're forwarding a packet that has been decapsulated from a
tunnel, you certainly better be decrementing the TTL first (even if you're
just forwarding it to a local - internal - interface).  The tunnel
is just a link like any other.  You wouldn't be forwarding a packet from
ethernet to somewhere else without decrementing its TTL, nor should you
from a tunnel.

kre

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Dec 2001 14:50:35 +0200 (EET)

> on failing to advertise routes as an alternative to filtering is folly.

It is only available from local network (that is, where you can add e.g. 
'route add -host 127.0.0.1 <some node>' anyway).

> get (in many cases, that is sensible service...)

People often make the rules wrong (e.g. filter on the outbound interface 
only).  Not IETF's fault though.

But my take is, filtering in this kind of scenario is not that 
commonplace.  It should not have to be done in every node (see routing 
header debate).

> have noticed, thus you need to use extra care with filtering.

I wonder if all implementations do this.
 
> ethernet to somewhere else without decrementing its TTL, nor should you

Sure, if you're physically forwarding the packet, hop limit is 
decremented.

Incoming tunneled packets can arrive via the outbound interface to tunnel
interface with hop limit = 255.  The spec says the _sender_ decrements hop
limit by one, so one can forge packets here.  

Yhe hop limit is not decremented, if the target node (e.g. the internal
interface address) itself receives the packet, IIRC.  If it's forwaderded
off the node, sure it's decremented.

This can be IMO rather dangerous as more and more services are using "hop 
limit = 255" as an (additional) weak authentication method.  Fortunately, 
at least most services require additional proof, e.g. use of link-local 
addresses.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Dec 2001 15:23:25 +0100

> "there are packets [referring to 2002 prefix] coming from relay which

Oh, I see your problem now. But the [...] is not implied by the text
as I read it. However, since I wrote it too, maybe other people see
that implication, which wasn't intended.

   Brian