From isabel@vagabundo.dit.upm.es  Wed Dec 15 17:16:54 2004
Return-Path: <isabel@vagabundo.dit.upm.es>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 6CFF116A4CF
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 15 Dec 2004 17:16:54 +0000 (GMT)
Received: from vagabundo.dit.upm.es (vagabundo.dit.upm.es [138.4.24.37])
	by mx1.FreeBSD.org (Postfix) with ESMTP id A505843D5F
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 15 Dec 2004 17:16:53 +0000 (GMT)
	(envelope-from isabel@vagabundo.dit.upm.es)
Received: from vagabundo.dit.upm.es (localhost [127.0.0.1])
	by vagabundo.dit.upm.es (8.13.1/8.13.1) with ESMTP id iBFIM1Gt000796;
	Wed, 15 Dec 2004 19:22:01 +0100 (CET)
	(envelope-from isabel@vagabundo.dit.upm.es)
Received: (from isabel@localhost)
	by vagabundo.dit.upm.es (8.13.1/8.13.1/Submit) id iBFIM0c9000795;
	Wed, 15 Dec 2004 19:22:00 +0100 (CET)
	(envelope-from isabel)
Message-Id: <200412151822.iBFIM0c9000795@vagabundo.dit.upm.es>
Date: Wed, 15 Dec 2004 19:22:00 +0100 (CET)
From: Antonio Tapiador del Dujo <atapiador@dit.upm.es>
Reply-To: Antonio Tapiador del Dujo <atapiador@dit.upm.es>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Wrong behaviour of IFF_LINK2 bit in 6in6 gifs?
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         75121
>Category:       kern
>Synopsis:       Wrong behaviour of IFF_LINK2 bit in 6in6 gifs?
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Dec 15 17:20:27 GMT 2004
>Closed-Date:    
>Last-Modified:  Sat Jul 23 02:23:38 GMT 2005
>Originator:     Antonio Tapiador del Dujo
>Release:        FreeBSD 5.3-RELEASE i386
>Organization:
DIT - UPM
>Environment:
System: FreeBSD vagabundo.dit.upm.es 5.3-RELEASE FreeBSD 5.3-RELEASE #1: Tue Dec 14 21:08:08 CET 2004 root@vagabundo.dit.upm.es:/usr/src/sys/i386/compile/MH-4 i386


	
>Description:
I'm researching on IPv6 multihoming.
I need a generic 6in6 tunnel interface that accepts packets from any source, so I tried with the IFF_LINK2 as said in gif(4), but it didn't work.
Looking at the code, I found out the address checks are done regardless of the IFF_LINK2 (netinet6/in6_gif.c, line 318)
Shouldn't these checks take into account the IFF_LINK2?
Moving them inside the next if works as I expected.

>How-To-Repeat:
	
>Fix:

	


>Release-Note:
>Audit-Trail:

From: Gleb Smirnoff <glebius@freebsd.org>
To: Antonio Tapiador del Dujo <atapiador@dit.upm.es>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/75121: Wrong behaviour of IFF_LINK2 bit in 6in6 gifs?
Date: Tue, 18 Jan 2005 13:57:51 +0300

   Antonio,
 
 On Wed, Dec 15, 2004 at 07:22:00PM +0100, Antonio Tapiador del Dujo wrote:
 A> >Description:
 A> I'm researching on IPv6 multihoming.
 A> I need a generic 6in6 tunnel interface that accepts packets from any source, so I tried with the IFF_LINK2 as said in gif(4), but it didn't work.
 A> Looking at the code, I found out the address checks are done regardless of the IFF_LINK2 (netinet6/in6_gif.c, line 318)
 A> Shouldn't these checks take into account the IFF_LINK2?
 A> Moving them inside the next if works as I expected.
 
 No they shouldn't. Perhaps you have some misconfiguration with your tunnels.
 If you have tunnel configured as X <-> Y on machine A, then you MUST have
 tunnel configured Y <-> X on machine B. This is requirement for gif protocol.
 Otherwise you will have odd and undefined behavior, when multiple tunnels
 terminate on one box.
 
 The IFF_LINK2 means that incoming tunnel packets may come from interface
 different to interface we use for sending out tunnel packets.
 
 If you don't mind, I close the PR.
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE

From: Antonio Tapiador del Dujo <atapiador@dit.upm.es>
To: Gleb Smirnoff <glebius@freebsd.org>
Cc: Antonio Tapiador del Dujo <atapiador@dit.upm.es>,
	FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/75121: Wrong behaviour of IFF_LINK2 bit in 6in6 gifs?
Date: Tue, 18 Jan 2005 13:51:01 +0100

 --6TrnltStXW4iwmi0
 Content-Type: text/plain; charset=iso-8859-1
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 El martes, 18 de enero de 2005, a las 13:57:51, Gleb Smirnoff escribi=F3:
 >   Antonio,
 >=20
 > On Wed, Dec 15, 2004 at 07:22:00PM +0100, Antonio Tapiador del Dujo wrote:
 > A> >Description:
 > A> I'm researching on IPv6 multihoming.
 > A> I need a generic 6in6 tunnel interface that accepts packets from any s=
 ource, so I tried with the IFF_LINK2 as said in gif(4), but it didn't work.
 > A> Looking at the code, I found out the address checks are done regardles=
 s of the IFF_LINK2 (netinet6/in6_gif.c, line 318)
 > A> Shouldn't these checks take into account the IFF_LINK2?
 > A> Moving them inside the next if works as I expected.
 >=20
 > No they shouldn't. Perhaps you have some misconfiguration with your tunne=
 ls.
 > If you have tunnel configured as X <-> Y on machine A, then you MUST have
 > tunnel configured Y <-> X on machine B. This is requirement for gif proto=
 col.
 > Otherwise you will have odd and undefined behavior, when multiple tunnels
 > terminate on one box.
 
 I know, but this an interesting element for several multihoming solutions,
 as discused in draft-huitema-multi6-ingress-filtering-00.txt
 
 > The IFF_LINK2 means that incoming tunnel packets may come from interface
 > different to interface we use for sending out tunnel packets.
 
 gif(4) man page talks about ingress filtering:
 "Ingress filtering can be turned off by IFF_LINK2 bit."
 that has to do with source addresses (RFC 2893, section 4.3)
 Then maybe this is a gif(4) man page bug.=20
 
 > If you don't mind, I close the PR.
 =20
 Anyway I don't see why not to give the choice, because somebody who sets=20
 IFF_LINK2 knows what is doing (or maybe not :)).
 
 Cheers.
 
 --=20
 EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
 
 --6TrnltStXW4iwmi0
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: Digital signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.4 (GNU/Linux)
 
 iD8DBQFB7QY1AeZK4jlfl3cRApiCAKCj4iAxRPmDept5e/BJHlZHwCl5iwCgjXmv
 I5z/oTMsJ0nhXBCfKChmXIs=
 =EppZ
 -----END PGP SIGNATURE-----
 
 --6TrnltStXW4iwmi0--

From: Gleb Smirnoff <glebius@freebsd.org>
To: Antonio Tapiador del Dujo <atapiador@dit.upm.es>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/75121: Wrong behaviour of IFF_LINK2 bit in 6in6 gifs?
Date: Tue, 18 Jan 2005 17:06:25 +0300

   Antonio,
 
 On Tue, Jan 18, 2005 at 01:51:01PM +0100, Antonio Tapiador del Dujo wrote:
 A> > The IFF_LINK2 means that incoming tunnel packets may come from interface
 A> > different to interface we use for sending out tunnel packets.
 A> 
 A> gif(4) man page talks about ingress filtering:
 A> "Ingress filtering can be turned off by IFF_LINK2 bit."
 A> that has to do with source addresses (RFC 2893, section 4.3)
 A> Then maybe this is a gif(4) man page bug. 
 
 Yes, it is I think. Section 4.3 speaks about other kind of filtering.
 
 A> > If you don't mind, I close the PR.
 A>  
 A> Anyway I don't see why not to give the choice, because somebody who sets 
 A> IFF_LINK2 knows what is doing (or maybe not :)).
 
 gif(4) is based on RFC 2893, but does not implements it. We do not support
 loose endpoints of a tunnel, or a list of accepted endpoints.
 
 I think we should correct the manpage and close PR. I'm not sure that
 driver will survive removing the check for matching endpoints. If you are going
 to implement RFC 2893 in full scope, you are welcome :)
 
 I will ask ume to look at this PR.
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE

From: Hajimu UMEMOTO <ume@freebsd.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc: Antonio Tapiador del Dujo <atapiador@dit.upm.es>,
	Gleb Smirnoff <glebius@freebsd.org>
Subject: Re: kern/75121: Wrong behaviour of IFF_LINK2 bit in 6in6 gifs?
Date: Thu, 20 Jan 2005 19:57:12 +0900

 Hi,
 
  A> > The IFF_LINK2 means that incoming tunnel packets may come from interface
  A> > different to interface we use for sending out tunnel packets.
  A> 
  A> gif(4) man page talks about ingress filtering:
  A> "Ingress filtering can be turned off by IFF_LINK2 bit."
  A> that has to do with source addresses (RFC 2893, section 4.3)
  A> Then maybe this is a gif(4) man page bug. 
  
 glebius>  Yes, it is I think. Section 4.3 speaks about other kind of filtering.
 
 No, manpage of gif(4) is correct.  Ingress filtering is for preventing
 IP address spoofing of outer src address and dest address.
 
 Sincerely,
 
 --
 Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
 ume@mahoroba.org  ume@{,jp.}FreeBSD.org
 http://www.imasy.org/~ume/

From: Antonio Tapiador del Dujo <atapiador@dit.upm.es>
To: Hajimu UMEMOTO <ume@freebsd.org>
Cc: FreeBSD-gnats-submit@freebsd.org,
	Antonio Tapiador del Dujo <atapiador@dit.upm.es>,
	Gleb Smirnoff <glebius@freebsd.org>
Subject: Re: kern/75121: Wrong behaviour of IFF_LINK2 bit in 6in6 gifs?
Date: Tue, 25 Jan 2005 15:57:48 +0100

 --xgyAXRrhYN0wYx8y
 Content-Type: text/plain; charset=iso-8859-1
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 El jueves, 20 de enero de 2005, a las 19:57:12, Hajimu UMEMOTO escribi=F3:
 > Hi,
 >=20
 >  A> > The IFF_LINK2 means that incoming tunnel packets may come from inte=
 rface
 >  A> > different to interface we use for sending out tunnel packets.
 >  A>=20
 >  A> gif(4) man page talks about ingress filtering:
 >  A> "Ingress filtering can be turned off by IFF_LINK2 bit."
 >  A> that has to do with source addresses (RFC 2893, section 4.3)
 >  A> Then maybe this is a gif(4) man page bug.=20
 > =20
 > glebius>  Yes, it is I think. Section 4.3 speaks about other kind of filt=
 ering.
 >=20
 > No, manpage of gif(4) is correct.  Ingress filtering is for preventing
 > IP address spoofing of outer src address and dest address.
 
 But now IFF_LINK2 does not turn off ingress filter.
 Either kernel code or man page should be modified because one is=20
 inconsistent with the other.
 
 --=20
 EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
 
 --xgyAXRrhYN0wYx8y
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: Digital signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.4 (GNU/Linux)
 
 iD8DBQFB9l5sAeZK4jlfl3cRAkiXAKCNOJJJ14hg5t38tx2peZDwNSPZxgCfY/nH
 EF+CLPc6lE3q577AsTnLjjM=
 =JyoO
 -----END PGP SIGNATURE-----
 
 --xgyAXRrhYN0wYx8y--

From: Hajimu UMEMOTO <ume@freebsd.org>
To: Antonio Tapiador del Dujo <atapiador@dit.upm.es>
Cc: Hajimu UMEMOTO <ume@freebsd.org>,
	FreeBSD-gnats-submit@freebsd.org, Gleb Smirnoff <glebius@freebsd.org>
Subject: Re: kern/75121: Wrong behaviour of IFF_LINK2 bit in 6in6 gifs?
Date: Wed, 26 Jan 2005 00:30:53 +0900

 Hi,
 
 >>>>> On Tue, 25 Jan 2005 15:57:48 +0100
 >>>>> Antonio Tapiador del Dujo <atapiador@dit.upm.es> said:
 
 atapiador> But now IFF_LINK2 does not turn off ingress filter.
 atapiador> Either kernel code or man page should be modified because one is 
 atapiador> inconsistent with the other.
 
 No, it does.  You can find following chunk in in6_gif.cgif_validate6()
 in6_gif.c:
 
 	/* ingress filters on outer source */
 	if ((sc->gif_if.if_flags & IFF_LINK2) == 0 && ifp) {
 
 The check you pointed out is not an ingress filter.
 
 Sincerely,
 
 --
 Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
 ume@mahoroba.org  ume@{,jp.}FreeBSD.org
 http://www.imasy.org/~ume/

From: Antonio Tapiador del Dujo <atapiador@dit.upm.es>
To: Hajimu UMEMOTO <ume@freebsd.org>
Cc: Antonio Tapiador del Dujo <atapiador@dit.upm.es>,
	FreeBSD-gnats-submit@freebsd.org, Gleb Smirnoff <glebius@freebsd.org>
Subject: Re: kern/75121: Wrong behaviour of IFF_LINK2 bit in 6in6 gifs?
Date: Tue, 25 Jan 2005 17:19:11 +0100

 --JgQwtEuHJzHdouWu
 Content-Type: text/plain; charset=iso-8859-1
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 I think I'm leaving this, because I'm going mad...
 Sorry if I'm wrong, but:
 
 El mi=E9rcoles, 26 de enero de 2005, a las 00:30:53, Hajimu UMEMOTO escribi=
 =F3:
 > Hi,
 >=20
 > >>>>> On Tue, 25 Jan 2005 15:57:48 +0100
 > >>>>> Antonio Tapiador del Dujo <atapiador@dit.upm.es> said:
 >=20
 > atapiador> But now IFF_LINK2 does not turn off ingress filter.
 > atapiador> Either kernel code or man page should be modified because one =
 is=20
 > atapiador> inconsistent with the other.
 >=20
 > No, it does.  You can find following chunk in in6_gif.cgif_validate6()
 > in6_gif.c:
 >=20
 > 	/* ingress filters on outer source */
 > 	if ((sc->gif_if.if_flags & IFF_LINK2) =3D=3D 0 && ifp) {
 >=20
 > The check you pointed out is not an ingress filter.
 
 You said: "Ingress filtering is for preventing IP address spoofing of=20
 outer src address and dest address."
 
 The check you point out is for the interface, as Glib said:
 "The IFF_LINK2 means that incoming tunnel packets may come from
 interface different to interface we use for sending out tunnel packets."
 
 Packets with src or dest addresses spoofed are dropped before:
 
         /*
          * Check for address match.  Note that the check is for an incoming
          * packet.  We should compare the *source* address in our configura=
 tion
          * and the *destination* address of the packet, and vice versa.
          */
         if (!IN6_ARE_ADDR_EQUAL(&src->sin6_addr, &ip6->ip6_dst) ||
             !IN6_ARE_ADDR_EQUAL(&dst->sin6_addr, &ip6->ip6_src))
                 return 0;
 
 --=20
 EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
 
 --JgQwtEuHJzHdouWu
 Content-Type: application/pgp-signature; name="signature.asc"
 Content-Description: Digital signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.4 (GNU/Linux)
 
 iD8DBQFB9nF/AeZK4jlfl3cRAp6dAJ96Ds9YSYPMdun6vawVVogOpjhdEwCglMHI
 dBjlCKcScsxz1EAN/G3tfMI=
 =NnAh
 -----END PGP SIGNATURE-----
 
 --JgQwtEuHJzHdouWu--
>Unformatted:
