* [RFC] GTSM for IPv6
@ 2010-03-19 16:56 Stephen Hemminger
2010-03-19 18:02 ` Pekka Savola
2010-03-22 7:27 ` YOSHIFUJI Hideaki
0 siblings, 2 replies; 6+ messages in thread
From: Stephen Hemminger @ 2010-03-19 16:56 UTC (permalink / raw)
To: David Miller,
YOSHIFUJI Hideaki / 吉藤英明; +Cc: netdev
This patch implements Generalized TTL Security Mechanism for IPv6.
It is not tested, but I am putting it out to get feedback about:
* is this the API (setsockout IPV6_MIN_HOPS) that we want to use
* compatibility with IPv4
* minor growth of socket packet info structure
Also RFC doesn't explicitly address GTSM on IPV6.
Maybe the RFC editors think the problem will magically no longer exist
in IPv6 world because everyone will be using IPsec.
---
include/linux/in6.h | 3 +++
include/linux/ipv6.h | 3 ++-
net/ipv6/ipv6_sockglue.c | 12 ++++++++++++
net/ipv6/tcp_ipv6.c | 17 ++++++++++++++---
4 files changed, 31 insertions(+), 4 deletions(-)
--- a/net/ipv6/tcp_ipv6.c 2010-03-19 09:05:48.038329597 -0700
+++ b/net/ipv6/tcp_ipv6.c 2010-03-19 09:51:12.293647330 -0700
@@ -349,6 +349,12 @@ static void tcp_v6_err(struct sk_buff *s
if (sk->sk_state == TCP_CLOSE)
goto out;
+ np = inet6_sk(sk);
+ if (ipv6_hdr(skb)->hop_limit < np->min_hops) {
+ NET_INC_STATS_BH(net, LINUX_MIB_TCPMINTTLDROP);
+ goto out;
+ }
+
tp = tcp_sk(sk);
seq = ntohl(th->seq);
if (sk->sk_state != TCP_LISTEN &&
@@ -357,8 +363,6 @@ static void tcp_v6_err(struct sk_buff *s
goto out;
}
- np = inet6_sk(sk);
-
if (type == ICMPV6_PKT_TOOBIG) {
struct dst_entry *dst = NULL;
@@ -1675,6 +1679,7 @@ ipv6_pktoptions:
static int tcp_v6_rcv(struct sk_buff *skb)
{
struct tcphdr *th;
+ struct ipv6hdr *hdr;
struct sock *sk;
int ret;
struct net *net = dev_net(skb->dev);
@@ -1701,12 +1706,13 @@ static int tcp_v6_rcv(struct sk_buff *sk
goto bad_packet;
th = tcp_hdr(skb);
+ hdr = ipv6_hdr(skb);
TCP_SKB_CB(skb)->seq = ntohl(th->seq);
TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +
skb->len - th->doff*4);
TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);
TCP_SKB_CB(skb)->when = 0;
- TCP_SKB_CB(skb)->flags = ipv6_get_dsfield(ipv6_hdr(skb));
+ TCP_SKB_CB(skb)->flags = ipv6_get_dsfield(hdr);
TCP_SKB_CB(skb)->sacked = 0;
sk = __inet6_lookup_skb(&tcp_hashinfo, skb, th->source, th->dest);
@@ -1717,6 +1723,11 @@ process:
if (sk->sk_state == TCP_TIME_WAIT)
goto do_time_wait;
+ if (hdr->hop_limit < inet6_sk(sk)->min_hops) {
+ NET_INC_STATS_BH(net, LINUX_MIB_TCPMINTTLDROP);
+ goto discard_and_relse;
+ }
+
if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
goto discard_and_relse;
--- a/include/linux/in6.h 2010-03-19 09:40:24.788957033 -0700
+++ b/include/linux/in6.h 2010-03-19 09:41:41.432704471 -0700
@@ -265,6 +265,9 @@ struct in6_flowlabel_req {
#define IPV6_PREFER_SRC_CGA 0x0008
#define IPV6_PREFER_SRC_NONCGA 0x0800
+/* RFC5082: Generalized Ttl Security Mechanism */
+#define IPV6_MIN_HOPS 73
+
/*
* Multicast Routing:
* see include/linux/mroute6.h.
--- a/include/linux/ipv6.h 2010-03-19 09:26:17.368329255 -0700
+++ b/include/linux/ipv6.h 2010-03-19 09:27:03.929206412 -0700
@@ -348,6 +348,7 @@ struct ipv6_pinfo {
* 010: prefer public address
* 100: prefer care-of address
*/
+ __u8 min_hops;
__u8 tclass;
__u32 dst_cookie;
--- a/net/ipv6/ipv6_sockglue.c 2010-03-19 09:35:40.488016906 -0700
+++ b/net/ipv6/ipv6_sockglue.c 2010-03-19 09:39:57.948026685 -0700
@@ -766,6 +766,14 @@ pref_skip_coa:
break;
}
+ case IPV6_MIN_HOPS:
+ if (optlen < sizeof(int))
+ goto e_inval;
+ if (val < 0 || val > 255)
+ goto e_inval;
+ np->min_hops = val;
+ retv = 0;
+ break;
}
release_sock(sk);
@@ -1114,6 +1122,10 @@ static int do_ipv6_getsockopt(struct soc
val |= IPV6_PREFER_SRC_HOME;
break;
+ case IPV6_MIN_HOPS:
+ val = np->min_hops;
+ break;
+
default:
return -ENOPROTOOPT;
}
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RFC] GTSM for IPv6
2010-03-19 16:56 [RFC] GTSM for IPv6 Stephen Hemminger
@ 2010-03-19 18:02 ` Pekka Savola
2010-03-22 3:16 ` David Miller
2010-03-22 7:14 ` YOSHIFUJI Hideaki
2010-03-22 7:27 ` YOSHIFUJI Hideaki
1 sibling, 2 replies; 6+ messages in thread
From: Pekka Savola @ 2010-03-19 18:02 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller,
YOSHIFUJI Hideaki / 吉藤英明, netdev
On Fri, 19 Mar 2010, Stephen Hemminger wrote:
> Also RFC doesn't explicitly address GTSM on IPV6.
> Maybe the RFC editors think the problem will magically no longer exist
> in IPv6 world because everyone will be using IPsec.
Hmm. When I was editing the RFC, I seem to have put in some text about
IPv6 (i.e. difference in TTL vs Hop Count naming). As far as I know,
there is no other difference :-)
In IPV6_MIN_HOPS hops would seem to point toward the "number of hops"
which is logically the opposite: 255-$value. So maybe
IPV6_MIN_HOPCOUNT is better. But I can live with it either way :-)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] GTSM for IPv6
2010-03-19 18:02 ` Pekka Savola
@ 2010-03-22 3:16 ` David Miller
2010-03-22 7:14 ` YOSHIFUJI Hideaki
1 sibling, 0 replies; 6+ messages in thread
From: David Miller @ 2010-03-22 3:16 UTC (permalink / raw)
To: pekkas; +Cc: shemminger, yoshfuji, netdev
From: Pekka Savola <pekkas@netcore.fi>
Date: Fri, 19 Mar 2010 20:02:48 +0200 (EET)
> On Fri, 19 Mar 2010, Stephen Hemminger wrote:
>> Also RFC doesn't explicitly address GTSM on IPV6.
>> Maybe the RFC editors think the problem will magically no longer exist
>> in IPv6 world because everyone will be using IPsec.
>
> Hmm. When I was editing the RFC, I seem to have put in some text about
> IPv6 (i.e. difference in TTL vs Hop Count naming). As far as I know,
> there is no other difference :-)
>
> In IPV6_MIN_HOPS hops would seem to point toward the "number of hops"
> which is logically the opposite: 255-$value. So maybe
> IPV6_MIN_HOPCOUNT is better. But I can live with it either way :-)
Stephen, make whatever decision your deem appropriate about
the name and resubmit this for net-next-2.6, thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] GTSM for IPv6
2010-03-19 18:02 ` Pekka Savola
2010-03-22 3:16 ` David Miller
@ 2010-03-22 7:14 ` YOSHIFUJI Hideaki
1 sibling, 0 replies; 6+ messages in thread
From: YOSHIFUJI Hideaki @ 2010-03-22 7:14 UTC (permalink / raw)
To: Pekka Savola; +Cc: Stephen Hemminger, David Miller, netdev
(2010/03/20 3:02), Pekka Savola wrote:
> On Fri, 19 Mar 2010, Stephen Hemminger wrote:
>> Also RFC doesn't explicitly address GTSM on IPV6.
>> Maybe the RFC editors think the problem will magically no longer exist
>> in IPv6 world because everyone will be using IPsec.
>
> Hmm. When I was editing the RFC, I seem to have put in some text about
> IPv6 (i.e. difference in TTL vs Hop Count naming). As far as I know,
> there is no other difference :-)
>
> In IPV6_MIN_HOPS hops would seem to point toward the "number of hops"
> which is logically the opposite: 255-$value. So maybe IPV6_MIN_HOPCOUNT
> is better. But I can live with it either way :-)
>
Or, how about IPV6_MAX_HOPS, then? :-)
--yoshfuji
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFC] GTSM for IPv6
2010-03-19 16:56 [RFC] GTSM for IPv6 Stephen Hemminger
2010-03-19 18:02 ` Pekka Savola
@ 2010-03-22 7:27 ` YOSHIFUJI Hideaki
2010-03-28 15:57 ` Stephen Hemminger
1 sibling, 1 reply; 6+ messages in thread
From: YOSHIFUJI Hideaki @ 2010-03-22 7:27 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev, YOSHIFUJI Hideaki
(2010/03/20 1:56), Stephen Hemminger wrote:
> Also RFC doesn't explicitly address GTSM on IPV6.
> Maybe the RFC editors think the problem will magically no longer exist
> in IPv6 world because everyone will be using IPsec.
> ---
> include/linux/in6.h | 3 +++
> include/linux/ipv6.h | 3 ++-
> net/ipv6/ipv6_sockglue.c | 12 ++++++++++++
> net/ipv6/tcp_ipv6.c | 17 ++++++++++++++---
> 4 files changed, 31 insertions(+), 4 deletions(-)
Why don't we have code for other protocols such as
UDP etc? We already have similar protection in NDP,
It seem to make sense.
And, as many other socket options (such as IPV6_UNICAST_HOPS
etc.) do, please accept value of -1 to set the system's
default (0 so far).
x < -1: return an error of EINVAL
x == -1: use kernel default
0 <= x <= 255: use x
x >= 256: return an error of EINVAL
We may also want to have sysctl for it.
Regrads,
--yoshfuji
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RFC] GTSM for IPv6
2010-03-22 7:27 ` YOSHIFUJI Hideaki
@ 2010-03-28 15:57 ` Stephen Hemminger
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Hemminger @ 2010-03-28 15:57 UTC (permalink / raw)
To: YOSHIFUJI Hideaki; +Cc: David Miller, netdev
On Mon, 22 Mar 2010 16:27:24 +0900
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> wrote:
> (2010/03/20 1:56), Stephen Hemminger wrote:
> > Also RFC doesn't explicitly address GTSM on IPV6.
> > Maybe the RFC editors think the problem will magically no longer exist
> > in IPv6 world because everyone will be using IPsec.
>
> > ---
> > include/linux/in6.h | 3 +++
> > include/linux/ipv6.h | 3 ++-
> > net/ipv6/ipv6_sockglue.c | 12 ++++++++++++
> > net/ipv6/tcp_ipv6.c | 17 ++++++++++++++---
> > 4 files changed, 31 insertions(+), 4 deletions(-)
>
> Why don't we have code for other protocols such as
> UDP etc? We already have similar protection in NDP,
> It seem to make sense.
>
> And, as many other socket options (such as IPV6_UNICAST_HOPS
> etc.) do, please accept value of -1 to set the system's
> default (0 so far).
>
> x < -1: return an error of EINVAL
> x == -1: use kernel default
> 0 <= x <= 255: use x
> x >= 256: return an error of EINVAL
>
> We may also want to have sysctl for it.
The choice was made with IPv4 to follow the precedent of FreeBSD.
And it makes sense to me to have IPv6 follow what IPv4 did.
It doesn't make sense as a sysctl value since the value is associated
with a socket. It requires both sides to cooperate and the path
has to be known. The sender sets the hop count to 255 and the receiver
knows the sender is at most N hops away. The receiver then sets the
MIN_HOPCOUNT value to 255 - N.
Implementing GTSM for UDP, SCTP, DCCP is left as an exercise for
the reader. It can't be done in the IP layer since the IP layer
does not a socket and shouldn't be looking it up.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-03-28 22:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-19 16:56 [RFC] GTSM for IPv6 Stephen Hemminger
2010-03-19 18:02 ` Pekka Savola
2010-03-22 3:16 ` David Miller
2010-03-22 7:14 ` YOSHIFUJI Hideaki
2010-03-22 7:27 ` YOSHIFUJI Hideaki
2010-03-28 15:57 ` Stephen Hemminger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).