Subject: Re: (ngtrans) Re: RFC 3056

From: [email-masked]
Date: Fri, 01 Feb 2002 18:23:10 +0100

Pekka Savola wrote:
> 
> Note: moved to ngtrans.
> 
> On Fri, 1 Feb 2002, Brian E Carpenter wrote:
> > I'm not sure about Pekka's answer, because I'm not sure what the question is.
> >
> > The outer IPv4 packet is just a normal packet from the 6to4 router, so its
> > IPv4 source address is the IPv4 address of the sending interface on the
> > 6to4 router.
> 
> I disagree: I think it's quite essential that IPv4 address (for 6to4
> _router_, naturally) be set to the same as the embedded IPv6 address (for
> security checks, for example).

Indeed, this is also suggested in following quote from the security
section:

   If this is for
   any reason felt to be a security risk (for example, if IPv6 spoofing
   is felt to be more likely than IPv4 spoofing), then additional source
   address based packet filtering could be applied.  A possible
   plausibility check is whether the encapsulating IPv4 address is
   consistent with the encapsulated 2002:: address. 

> 
> For example: assume 6to4 router has two interfaces: 1.2.3.4 and 5.6.7.8
> and only one prefix 2002:0102:0304::/48.  (In this case, to get
> redundancy, one should have two 6to4 pseudo-interfacs with two addresses.)
> 
> I think, from RFC3056 chapter 3 (second last sentence) it's required that
> sending IPv4 address be set to 1.2.3.4 _even if_ interface 1.2.3.4 is down
> and the packet would be sent through 5.6.7.8.
> 
> > The inner IPv6 packet has an IPv6 source address which is that
> > of the originating IPv6 host. If the router is a normal 6to4 router, that
> > will be an IPv6 address starting with 2002:v4addr where v4addr is the source
> > IPv4 address of the 6to4 router. If the router is a 6to4 relay router,
> > the IPv6 source address could be any valid unicast IPv6 address (except for
> > a few odd cases such as link local).
> >
> > As Pekka says, this is an ngtrans topic.
> >
> >    Brian
> >
> >
> > Pekka Savola wrote:
> > >
> > > On Fri, 1 Feb 2002 [email-masked] wrote:
> > > > When reading RFC 3056 (6 to 4 strategy), I have 2 questions I could not
> > > > get answered. Consider the router that originates the IPv4 tunnel. Which
> > > > IP address should this router use as the source IP addres in its IPv4
> > > > encapsulation header:
> > > >
> > > > * Should this address be the router id of this router?
> > > > Or
> > >
> > > If router-id is V4ADDR in 2002:V4ADDR.
> > >
> > > > * Should the source IPv4 address be derived from the source IPv6 address
> > > > Or
> > > > ...?
> > >
> > > Yes.
> > >
> > > See RFC3056 Chapter 3:
> > >
> > >    IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4
> > >    protocol type of 41, the same as has been assigned [MECH] for IPv6
> > >    packets that are tunneled inside of IPv4 frames.  The IPv4 header
> > >    contains the Destination and Source IPv4 addresses.  One or both of
> > >    these will be identical to the V4ADDR field of an IPv6 prefix formed
> > >    as specified above (see section 5 for more details).  The IPv4 packet
> > >    body contains the IPv6 header and payload.
> > >
> > > (btw, this is ngtrans, rather than ipng, material)
> > >
> > > --
> > > 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
> >
> 
> --
> 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

-- 
Dirk Ooms                       mailto:[email-masked]
                                tel:+32 3 2404732
Network Strategy Group (NSG)    http://aww.alcatel.com/nsg
Alcatel                         http://www.alcatel.com

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 1 Feb 2002 11:41:16 -0800

> > sending IPv4 address be set to 1.2.3.4 _even if_ interface 1.2.3.4
is
> down
> What is the point in sending a packet with the src set to an interface
> that is down? If the other end tries to return a packet it will be
> routed to the dead interface.

That is one of the bogus effects of the ingress check at the tunnel
endpoint: in order to enable ingress check by the tunnel endpoint, you
have to spoof an address at the sender side...

Note however that if you send a packet from IPv6 2002:1.2.3.4 and
1.2.3.4 is down, chances are that the responses will be sent to 1.2.3.4
and will just be lost, whatever the address you place in the IPv4 tunnel
source. If you want a robust set-up for a large site, and you have
multihoming, then you need stateless routers that all listen to an
"anycast" address (e.g. 1.2.3.4) and all source packets from that same
address. Indeed, you have to make sure that the provider(s) with which
you multi-home the site will let you do that.

-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 3 Feb 2002 12:08:28 -0800

If you want to encourage paranoid checks, then you have to develop a way
to support them. Maybe a form of challenge: "prove me that your are a
real relay router"; response: "sure, is is my relay router certificate,
signed by the grand poobah of 6t04." Or something of that nature.
Indeed, deployment issues can be interesting.

-- Christian Huitema

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Sunday, February 03, 2002 7:15 AM
> To: Christian Huitema
> Cc: [email-masked]; Pekka Savola; [email-masked];
> [email-masked]
> Subject: Re: (ngtrans) Re: RFC 3056
> 
> Christian,
> 
> Your rules are good. When we revise 3056, they should go in.
> 
> However, I continue to believe that a paranoid site might well also
> build an ACL of trusted relays (rather as a personal firewall builds
> a list of acceptable ports). This site would not accept incoming relay
> traffic by default; the first packet from a new relay would trigger
> a human decision.
> 
>    Brian
> 
> Christian Huitema wrote:
> >
> > The passage of RFC 3056 about security is a bit weak. It does say:
> >
> >    If this is for
> > But it also adds that you can't do the check for packets that went
> > through a relay router. Brian mentioned having a list of the
addresses
> > of relay routers, but that is not realistic either: given hot-potato
> > routing, the packets are ditched to the nearest relay that
advertises
> > 2002::/16; how can you get a list of all routers that do that in all
> > ISPs?
> >
> > The security rules should in fact be rewritten as follow:
> >
> > 1) If the IPv6 source address is in a 2002::/16 domain, the IPv4
source
> > address should be consistent with it.
> >
> > 2) If the IPv6 source address is not in a 2002::/16 domain, and if
the
> > destination address is in the 2002::/16 domain, then the IPv4
> > destination should be consistent with the IPv6 destination. The
source
> > IPv4 address should not really be checked.
> >
> > 3) If neither the IPv6 source address not the IPv6 destination
address
> > is in the 2002::/16 domain, then special rules apply -- the packets
> > should not be relayed, unless some form of ACL explicitly enables
this
> > combination of IPv4 and IPv6 source and destination addresses.
> >
> > As far as relay routers are concerned, they should only accept from
IPv4
> > the packets that meet rule (1).
> >
> > The reason for not checking the source IPv4 address in (2) is the
> > difficulty of either maintaining a list of all router addresses. The
> > only way to bypass that would be to use an anycast address as a
source
> > address, but anycast source addresses can only be deployed by
relaxing
> > ingress filtering for such addresses, which mean in practice that
they
> > can be easily spoofed. If these addresses can be spoofed, then using
> > them is worse than not checking at all; at a minimum, using a
> > topologically valid source address allows for logging and tracing.
> >
> > -- Christian Huitema