|
Replies:
22
-
Last Post:
Oct 9, 2005 6:16 AM
by: seb
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Sep 29, 2005 2:59 PM
|
|
This is both a reminder that this design review is still ongoing, and a
notification that I'm extending this design review to Friday Oct. 7.
The document is available here:
http://opensolaris.org/os/community/networking/iptun-design.pdf
Thanks,
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Sep 29, 2005 5:39 PM
in response to: seb
|
|
Sebastien Roy wrote On 09/29/05 14:59,:
> http://opensolaris.org/os/community/networking/iptun-design.pdf
Seb, here are my comments:
Overall, I think this is a great design for tunnels and a much-
needed improvement. Well done.
Section 7:
I'd like a little more detail on the tunnel-specific fanout and how
it interacts with IPsec. Do we support multiple independent tunnels
between a pair of hosts? I think this is only meaningful with IPsec,
so if it's not supported for plain tunnels, that's fine. But when
using IPsec, does the tunnel-specific fanout reference the IPsec data
to know to which tunnel a packet applies? Or is all of this taken care
of as a side-effect of already having a conn_t affiliation?
Section 8:
Maybe I'm a dreamer, but according to the DLPI spec, the SAP name space
is supposed to be provider-specific. I understand why you want to
choose the same numbers for IPv4 and IPv6 that Ethernet uses, but I
wish the text at least didn't encourage the concept of "a well-known
DLSAP number space for all DLPI devices." Yes, I know our IP
implementation couldn't easily support links that used a different
number space without adding some new infrastructure to look up SAPs in
a link-specific way. I just hate to see bad design get further
sedimented. All I'm asking for here is for that sentence to be changed
to something like "Because of assumptions made in the current IP code,
the DLPI provider will use the same SAP numbers for IPv4 and IPv6 as
Ethernet drivers."
I think it makes sense to fail, rather than ignore, requests to bind to
a SAP that you know you don't implement (anything other than 0800 and
86DD). If we someday allow other protocols over IP tunnels this
failure will be useful information.
I disagree with the assertion that DL_PROMISC_SAP and DL_PROMISC_PHYS
can be treated the same. DL_PROMISC_SAP should wildcard the SAP portion
of the receive filter, allowing a single DLS user to receive packets
for any SAP. This does not imply that it should receive packets
transmitted by other users of this DLS provider to the remote peer.
DL_PROMISC_PHYS does imply that. Also, you could interpret
DL_PROMISC_SAP (at least in raw mode) to accept any packet that arrives
over an IPsec tunnel, even if it's not IPPROTO_ENCAP or IPPROTO_IPV6.
This might help when diagnosing weird tunnel problems with snoop.
What do received IPsec packets look like in raw mode? Pre-decrypt or
post? ESP/AH header(s) still in place or removed?
Section 10:
Will svc:/milestone/network depend on svc:/network/iptun? I think it
should.
Section A:
Figure 3's representation of the queue relationships is not
technically correct. ill_wq is a pointer, and it does not point to
the dld's queue, but to the IP module's write queue, whose q_next
points to the dld's write queue. I know you're trying to simplify
this to capture just the relevant concepts here but I think you could
keep it simple and technically correct by replacing the names of the
pointers with the conceptual names of the queues:
s/ill_rq/IP read queue/ . Or add a small box to represent each
queue:
ill_t
ill_name mytunnel0
ill_mactype DL_IP
ill_rq ----> [read queue] <----+
ill_wq ----> [write queue] --+ |
| |
dld_str_t | |
ds_rq ----> [read queue] <--+ |
ds_wq ----> [write queue] ----+
ds_dc ...
Anyway, don't you have the ds_rq and ds_wq names (or the arrows
attached to them) swapped in figures 3 and 4 (and in my above
variation)?
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
491
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Sep 29, 2005 6:32 PM
in response to: mditto
|
|
On Thu, Sep 29, 2005 at 05:39:52PM -0700, Mike Ditto wrote:
>
> Section 7:
>
> I'd like a little more detail on the tunnel-specific fanout and how
> it interacts with IPsec. Do we support multiple independent tunnels
> between a pair of hosts? I think this is only meaningful with IPsec,
> so if it's not supported for plain tunnels, that's fine. But when
> using IPsec, does the tunnel-specific fanout reference the IPsec data
> to know to which tunnel a packet applies? Or is all of this taken care
> of as a side-effect of already having a conn_t affiliation?
Tunnels connect "external" addresses A and B. (These were "tsrc" and "tdst"
in the old ifconfig(1m) syntax.)
I can't speak for Seb as to non-IPsec protected tunnels, but the IPsec Tunnel
Reform project (independent of Clearview to the best of our knowlege right
now) will be able to differentiate between flows on a single tunnel
interface. You should read the Tunnel Reform document (link posted today on
this very list) to see those details.
Dan
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Sep 29, 2005 6:48 PM
in response to: mditto
|
|
On Thu, 2005-09-29 at 20:39, Mike Ditto wrote:
> Overall, I think this is a great design for tunnels and a much-
> needed improvement. Well done.
Thanks. The comments are appreciated.
>
>
> Section 7:
>
> I'd like a little more detail on the tunnel-specific fanout and how
> it interacts with IPsec.
The way that IPsec interacts with the fanout will be no different than
the way it does today. Each tunnel is still represented by a conn_t,
the only difference is that those conn_t's are now in their own special
IP tunnel fanout rather than in the generic raw socket fanout.
> Do we support multiple independent tunnels
> between a pair of hosts?
No, and that has never worked properly. You can configure such tunnel
interfaces, but all packets are received on a single tunnel interface
due to the ambiguity of the demultiplexing information. Section 15
talks about this in the context of mipagent(1M), which wrongly depends
on this. This bug documents the problem:
4152864 Configuring two tunnels with the same tsrc/tdst pair works.
This project will fix this bug and prohibit such a configuration. I'll
make that more clear in the documentation for dladm create-iptun and
libiptun.so's iptun_create() function.
> I think this is only meaningful with IPsec,
> so if it's not supported for plain tunnels, that's fine. But when
> using IPsec, does the tunnel-specific fanout reference the IPsec data
> to know to which tunnel a packet applies? Or is all of this taken care
> of as a side-effect of already having a conn_t affiliation?
Today, this fanout is done using the outer IP addresses in the packet,
not the IPsec data. This won't change. The only way to safely
configure a tunnel (any kind of tunnel) between the same two nodes is to
differentiate the tunnels using different tunnel source and tunnel
destination addresses.
>
> Section 8:
>
> Maybe I'm a dreamer, but according to the DLPI spec, the SAP name space
> is supposed to be provider-specific. I understand why you want to
> choose the same numbers for IPv4 and IPv6 that Ethernet uses, but I
> wish the text at least didn't encourage the concept of "a well-known
> DLSAP number space for all DLPI devices." Yes, I know our IP
> implementation couldn't easily support links that used a different
> number space without adding some new infrastructure to look up SAPs in
> a link-specific way. I just hate to see bad design get further
> sedimented. All I'm asking for here is for that sentence to be changed
> to something like "Because of assumptions made in the current IP code,
> the DLPI provider will use the same SAP numbers for IPv4 and IPv6 as
> Ethernet drivers."
Ok, I'll make that change.
>
> I think it makes sense to fail, rather than ignore, requests to bind to
> a SAP that you know you don't implement (anything other than 0800 and
> 86DD). If we someday allow other protocols over IP tunnels this
> failure will be useful information.
It's not that the requests are ignored. They succeed, but no packets
currently match those other SAPs. As a generic framework, Nemo doesn't
have a clue as to what the SAP address spaces are for all possible mac
types...
>
> I disagree with the assertion that DL_PROMISC_SAP and DL_PROMISC_PHYS
> can be treated the same. DL_PROMISC_SAP should wildcard the SAP portion
> of the receive filter, allowing a single DLS user to receive packets
> for any SAP. This does not imply that it should receive packets
> transmitted by other users of this DLS provider to the remote peer.
> DL_PROMISC_PHYS does imply that.
Agreed.
> Also, you could interpret
> DL_PROMISC_SAP (at least in raw mode) to accept any packet that arrives
> over an IPsec tunnel, even if it's not IPPROTO_ENCAP or IPPROTO_IPV6.
> This might help when diagnosing weird tunnel problems with snoop.
This one flew over my head. I have no idea what you mean here. The
IPsec processing of a tunneled packet occurs long before the tunnel sees
it on the receive side, and after the tunnel has transmitted it on the
send side. If you look at the diagram on page 14, the lower instance of
ip does all of the IPsec processing. The iptun driver only sees packets
that are in the clear.
You can snoop on the underlying physical interface if you want to see
the packet as it came in off of the wire before IPsec processing.
Really, after clearview, there will be four places in the stack where
you'll have the opportunity to observe packets using snoop. Here's an
example for a tunnel named sebpunchin0 that has been configured with a
tunnel source that is configured on ip's bge0 interface:
-----------
| ip | <----------- /d
> What do received IPsec packets look like in raw mode? Pre-decrypt or
> post? ESP/AH header(s) still in place or removed?
All evidence of IPsec processing has vanished by the time the iptun
driver gets the packet. If the packet looked like this on the wire:
encrypted
__________________
[outer ip] - [esp] - [inner ip] - [udp]
It will look like this to the iptun driver:
in-the-clear
------------------
[outer ip] - [inner ip] - [udp]
>
>
> Section 10:
>
> Will svc:/milestone/network depend on svc:/network/iptun? I think it
> should.
>
Ok.
>
> Section A:
>
> Figure 3's representation of the queue relationships is not
> technically correct. ill_wq is a pointer, and it does not point to
> the dld's queue, but to the IP module's write queue, whose q_next
> points to the dld's write queue.
That's true, and as you state below, I was representing the concept.
> I know you're trying to simplify
> this to capture just the relevant concepts here but I think you could
> keep it simple and technically correct by replacing the names of the
> pointers with the conceptual names of the queues:
> s/ill_rq/IP read queue/ . Or add a small box to represent each
> queue:
>
> ill_t
> ill_name mytunnel0
> ill_mactype DL_IP
> ill_rq ----> [read queue] <----+
> ill_wq ----> [write queue] --+ |
> | |
> dld_str_t | |
> ds_rq ----> [read queue] <--+ |
> ds_wq ----> [write queue] ----+
> ds_dc ...
Ok, that's a good suggestion, will do.
>
> Anyway, don't you have the ds_rq and ds_wq names (or the arrows
> attached to them) swapped in figures 3 and 4 (and in my above
> variation)?
I do indeed. I blame insufficient supply of coffee that day. :-)
Thanks Mike.
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
976
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device
Driver design review extension (Oct. 7)
Posted:
Sep 29, 2005 7:01 PM
in response to: seb
|
|
On Thu, 2005-09-29 at 21:48, Sebastien Roy wrote:
> Today, this fanout is done using the outer IP addresses in the packet,
> not the IPsec data. This won't change. The only way to safely
> configure a tunnel (any kind of tunnel) between the same two nodes is to
> differentiate the tunnels using different tunnel source and tunnel
> destination addresses.
This may have to be weakened again to allow NAT traversal for multiple
nodes behind the same NAT (they'll share the same tsrc and tdst ip, but
will have different port numbers and SPI's inside the UDP.
But it gets worse. SPI's expire and the UDP port numbers may change
due to NAT-alzheimers, so we may have to dig a little further to find a
real selector...
- Bill
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Sep 29, 2005 7:07 PM
in response to: sommerfe
|
|
On Thu, 2005-09-29 at 22:01, Bill Sommerfeld wrote:
> On Thu, 2005-09-29 at 21:48, Sebastien Roy wrote:
> > Today, this fanout is done using the outer IP addresses in the packet,
> > not the IPsec data. This won't change. The only way to safely
> > configure a tunnel (any kind of tunnel) between the same two nodes is to
> > differentiate the tunnels using different tunnel source and tunnel
> > destination addresses.
>
> This may have to be weakened again to allow NAT traversal for multiple
> nodes behind the same NAT (they'll share the same tsrc and tdst ip, but
> will have different port numbers and SPI's inside the UDP.
Can that be implemented using a single tunnel and fine grained policy
with multiple SA's?
>
>
> But it gets worse. SPI's expire and the UDP port numbers may change
> due to NAT-alzheimers, so we may have to dig a little further to find a
> real selector...
If multiple tunnels are really needed when this is implemented,
additional parameters would need to be added to the fanout to
disambiguate between the tunnels that have identical tunnel sources and
destinations. That could be added in the future. Today, that's a
misconfiguration as the ambiguity is very real.
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
491
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Sep 29, 2005 7:35 PM
in response to: seb
|
|
On Thu, Sep 29, 2005 at 10:07:55PM -0400, Sebastien Roy wrote:
> On Thu, 2005-09-29 at 22:01, Bill Sommerfeld wrote:
> > On Thu, 2005-09-29 at 21:48, Sebastien Roy wrote:
> > > Today, this fanout is done using the outer IP addresses in the packet,
> > > not the IPsec data. This won't change. The only way to safely
> > > configure a tunnel (any kind of tunnel) between the same two nodes is to
> > > differentiate the tunnels using different tunnel source and tunnel
> > > destination addresses.
> >
> > This may have to be weakened again to allow NAT traversal for multiple
> > nodes behind the same NAT (they'll share the same tsrc and tdst ip, but
> > will have different port numbers and SPI's inside the UDP.
>
> Can that be implemented using a single tunnel and fine grained policy
> with multiple SA's?
Yes. In fact, RFC 3948 says that for Tunnel Mode, it's not a big difference
from basic RFC 2401 & friends' Tunnel Mode:
> For tunnel mode, both ends SHOULD NOT send original addresses to the other
> end.
And for *this* discussion, we don't care about Transport Mode.
> > But it gets worse. SPI's expire and the UDP port numbers may change
> > due to NAT-alzheimers, so we may have to dig a little further to find a
> > real selector...
>
> If multiple tunnels are really needed when this is implemented,
> additional parameters would need to be added to the fanout to
> disambiguate between the tunnels that have identical tunnel sources and
> destinations. That could be added in the future. Today, that's a
> misconfiguration as the ambiguity is very real.
In Tunnel Reform, we fix this by selecting on the Inner IP addresses. The
only worry here comes in cases which have identical *inner* addresses but on
different *outer* addresses. (See "Tunnel Mode Conflict" in RFC 3948 for an
example.)
I don't think we're in any real danger. We just have to twist things a
little to get multiple flows over a single "tsrc A tdst B" IP tunnel
instance.
Dan
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Sep 30, 2005 3:41 PM
in response to: seb
|
|
Sebastien Roy wrote:
> Today, this fanout is done using the outer IP addresses in the packet,
> not the IPsec data. This won't change. The only way to safely
> configure a tunnel (any kind of tunnel) between the same two nodes is to
> differentiate the tunnels using different tunnel source and tunnel
> destination addresses.
OK, I'll accept that this isn't changing the behavior.
> It's not that the requests are ignored. They succeed, but no packets
> currently match those other SAPs. As a generic framework, Nemo doesn't
> have a clue as to what the SAP address spaces are for all possible mac
> types...
OK, if the decision to reject the bind would have to be made in the
framework, then I guess it's not worth the trouble.
>>Also, you could interpret
>>DL_PROMISC_SAP (at least in raw mode) to accept any packet that arrives
>>over an IPsec tunnel, even if it's not IPPROTO_ENCAP or IPPROTO_IPV6.
>>This might help when diagnosing weird tunnel problems with snoop.
>
> This one flew over my head. I have no idea what you mean here. The
> IPsec processing of a tunneled packet occurs long before the tunnel sees
> it on the receive side, and after the tunnel has transmitted it on the
> send side. If you look at the diagram on page 14, the lower instance of
> ip does all of the IPsec processing. The iptun driver only sees packets
> that are in the clear.
Yes, but is there any way the iptun driver can ever see packets that are,
after decryption, some proto other than IPPROTO_ENCAP or IPPROTO_IPV6?
E.g. what happens if a peer running some alien IPsec implementation is
misconfigured to send transport mode traffic on the tunnel's IPsec SAs?
If so, it would of course be wrong for the iptun driver to pass such
packets upstream to either of the IPv4 or IPv6 SAPs, but it would be nice
to be able to snoop the decrypted packets so you can have some idea
what's going on.
>>What do received IPsec packets look like in raw mode? Pre-decrypt or
>>post? ESP/AH header(s) still in place or removed?
>
>
> All evidence of IPsec processing has vanished by the time the iptun
> driver gets the packet. If the packet looked like this on the wire:
>
> encrypted
> __________________
> [outer ip] - [esp] - [inner ip] - [udp]
>
> It will look like this to the iptun driver:
>
> in-the-clear
> ------------------
> [outer ip] - [inner ip] - [udp]
OK. And I hope that proto in outer ip been changed to IPPROTO_ENCAP or
IPPROTO_IPV6 if it had been AH or ESP so that snoop can parse it normally.
Thanks,
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Sep 30, 2005 7:47 PM
in response to: mditto
|
|
On Fri, 2005-09-30 at 18:41, Mike Ditto wrote:
> >>Also, you could interpret
> >>DL_PROMISC_SAP (at least in raw mode) to accept any packet that arrives
> >>over an IPsec tunnel, even if it's not IPPROTO_ENCAP or IPPROTO_IPV6.
> >>This might help when diagnosing weird tunnel problems with snoop.
> >
> > This one flew over my head. I have no idea what you mean here. The
> > IPsec processing of a tunneled packet occurs long before the tunnel sees
> > it on the receive side, and after the tunnel has transmitted it on the
> > send side. If you look at the diagram on page 14, the lower instance of
> > ip does all of the IPsec processing. The iptun driver only sees packets
> > that are in the clear.
>
> Yes, but is there any way the iptun driver can ever see packets that are,
> after decryption, some proto other than IPPROTO_ENCAP or IPPROTO_IPV6?
No. Only ip-in-ip packets make it to the tunnel fanout in the lower
instance of ip. By then, they've been decrypted. Maybe I'll add more
text to describe how the fanout works to make this more clear.
> E.g. what happens if a peer running some alien IPsec implementation is
> misconfigured to send transport mode traffic on the tunnel's IPsec SAs?
IPsec will drop the packet because of a policy failure. The packet will
never make it to the ip fanout. The SA is not what causes the packet to
be fanned out to an IP tunnel. It's the fact that the next header
(after decryption) is IPv4 or IPv6.
> If so, it would of course be wrong for the iptun driver to pass such
> packets upstream to either of the IPv4 or IPv6 SAPs, but it would be nice
> to be able to snoop the decrypted packets so you can have some idea
> what's going on.
Except that that packet gets dropped by the IPsec policy code before it
ever makes it up to the tunnel driver. Just because you have an SA that
allows you to decrypt a packet doesn't mean that packet should be
processed by the rest of the stack. IPsec policy tells you if the
decrypted packet should have been encrypted using that SA in the first
place.
>
> >>What do received IPsec packets look like in raw mode? Pre-decrypt or
> >>post? ESP/AH header(s) still in place or removed?
> >
> >
> > All evidence of IPsec processing has vanished by the time the iptun
> > driver gets the packet. If the packet looked like this on the wire:
> >
> > encrypted
> > __________________
> > [outer ip] - [esp] - [inner ip] - [udp]
> >
> > It will look like this to the iptun driver:
> >
> > in-the-clear
> > ------------------
> > [outer ip] - [inner ip] - [udp]
>
> OK. And I hope that proto in outer ip been changed to IPPROTO_ENCAP or
> IPPROTO_IPV6 if it had been AH or ESP so that snoop can parse it normally.
Yes, it is.
Thanks,
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Sep 30, 2005 8:12 PM
in response to: seb
|
|
On Fri, 2005-09-30 at 22:47, Sebastien Roy wrote:
> > OK. And I hope that proto in outer ip been changed to IPPROTO_ENCAP or
> > IPPROTO_IPV6 if it had been AH or ESP so that snoop can parse it normally.
>
> Yes, it is.
I should add that IPsec ESP processing does that today, and we're not
changing that. If you're curious take a look at esp_strip_header().
This really has nothing to do with IP tunneling, but with ESP processing
in IPsec.
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Oct 3, 2005 6:50 PM
in response to: seb
|
|
On Thu, 2005-09-29 at 21:48, Sebastien Roy wrote:
> > Section 10:
> >
> > Will svc:/milestone/network depend on svc:/network/iptun? I think it
> > should.
> >
>
> Ok.
Correction, doing this would introduce a cyclical dependency, as its
current dependencies are:
$ svcs -d milestone/network
STATE STIME FMRI
disabled 16:37:13 svc:/network/ipfilter:default
online 16:37:15 svc:/network/loopback:default
online 16:37:26 svc:/network/physical:default
It doesn't depend on network/inital, and if it depends on network/iptun,
it will then implicitly depend on network/initial. This would be a
significant change in behavior. In fact, network/initial depends on
milestone/network:
$ svcs -d network/initial
STATE STIME FMRI
online 16:37:16 svc:/system/filesystem/usr:default
online 16:37:19 svc:/system/cryptosvc:default
online 16:37:20 svc:/milestone/devices:default
online 16:37:26 svc:/milestone/network:default
A service that depends on network/initial therefore can't also have
milestone/network as a dependent.
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Oct 4, 2005 9:57 AM
in response to: seb
|
|
Sebastien Roy wrote On 10/03/05 18:50,:
> A service that depends on network/initial therefore can't also have
> milestone/network as a dependent.
Good point. I was worried about the fact that tun interfaces are
currently plumbed before milestone/network and won't be after this
project, but that shouldn't actually be a problem. Aside from the
practical dependency loop problem, I was being too aggressive in
what milestone/network should cover.
milestone/network represents initialization of the networking stack
such that APIs are available for applications to start up and "safe"
in the sense that packet filtering policy is being enforced, but it
doesn't guarantee that all local addresses are configured nor that
any particular links or routes are usable yet.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Oct 4, 2005 10:05 AM
in response to: mditto
|
|
On Tue, 2005-10-04 at 12:57, Mike Ditto wrote:
> Sebastien Roy wrote On 10/03/05 18:50,:
> > A service that depends on network/initial therefore can't also have
> > milestone/network as a dependent.
>
> Good point. I was worried about the fact that tun interfaces are
> currently plumbed before milestone/network and won't be after this
> project, but that shouldn't actually be a problem.
Right, and to be clear, that's because tunnel configuration currently
happens after milestone/network, and that will still be the case with
this design.
> Aside from the
> practical dependency loop problem, I was being too aggressive in
> what milestone/network should cover.
It's not clear what the original intent was. Do you know where the
documentation resides that covers what milestone/network means?
>
> milestone/network represents initialization of the networking stack
> such that APIs are available for applications to start up and "safe"
> in the sense that packet filtering policy is being enforced, but it
> doesn't guarantee that all local addresses are configured nor that
> any particular links or routes are usable yet.
Yes, that's evidently what it does based on its dependencies, but I'm
not sure how meaningful that actually is... I'll investigate this
further.
Thanks,
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Oct 4, 2005 4:01 PM
in response to: seb
|
|
Sebastien Roy wrote On 10/04/05 10:05,:
> It's not clear what the original intent was. Do you know where the
> documentation resides that covers what milestone/network means?
It was discussed on the greenline alias during the Solaris IP Filter
project but I can't find any record of those discussions. I think
the semantics of most milestones are considered unstable and aren't
really documented much beyond the description in the service
manifests. Here's what milestone/network.xml says:
<description>
<loctext xml:lang='C'>
Basic network APIs are functional and it
is safe to establish listening sockets
without security vulnerabilities.
</loctext>
</description>
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Oct 4, 2005 5:16 PM
in response to: mditto
|
|
On Tue, 2005-10-04 at 19:01, Mike Ditto wrote:
> Here's what milestone/network.xml says:
>
> <description>
> <loctext xml:lang='C'>
> Basic network APIs are functional and it
> is safe to establish listening sockets
> without security vulnerabilities.
> </loctext>
> </description>
IPsec policy hasn't been loaded by milestone/network, so I'm not sure
what the latter part of that description implies. In any case, thanks
for the information.
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
491
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Oct 4, 2005 5:23 PM
in response to: seb
|
|
On Tue, Oct 04, 2005 at 08:16:25PM -0400, Sebastien Roy wrote:
> On Tue, 2005-10-04 at 19:01, Mike Ditto wrote:
> > Here's what milestone/network.xml says:
> >
> > <description>
> > <loctext xml:lang='C'>
> > Basic network APIs are functional and it
> > is safe to establish listening sockets
> > without security vulnerabilities.
> > </loctext>
> > </description>
>
> IPsec policy hasn't been loaded by milestone/network, so I'm not sure
> what the latter part of that description implies.
Actually... it has! Doesn't milestone/network depend on network/initial?
Right now, the ipsecconf(1m) command that reads /etc/inet/ipsecinit.conf is
part of network/initial's start method.
When RFE 6185380 is finished, the decoupled IPsec services will be lined up
in a manner such that milestone/network still cannot be reached until IPsec
policy (if specified in /etc/inet/ipsecinit.conf) has been loaded.
Dan
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Oct 4, 2005 5:30 PM
in response to: danmcd
|
|
On Tue, 2005-10-04 at 20:23, Dan McDonald wrote:
> > IPsec policy hasn't been loaded by milestone/network, so I'm not sure
> > what the latter part of that description implies.
>
> Actually... it has! Doesn't milestone/network depend on network/initial?
No, it's the other way around. network/initial depends on
milestone/network...
> Right now, the ipsecconf(1m) command that reads /etc/inet/ipsecinit.conf is
> part of network/initial's start method.
Right, and my point was that because this is run after
milestone/network, the milestone's claims in its description are
somewhat inaccurate.
>
> When RFE 6185380 is finished, the decoupled IPsec services will be lined up
> in a manner such that milestone/network still cannot be reached until IPsec
> policy (if specified in /etc/inet/ipsecinit.conf) has been loaded.
It would be nice if the IPsec service was run before network/physical,
but I digress. As far as tunnels are concerned, it depends on
network/physical, and whatever service loads IPsec policy and keys which
currently happens to be network/initial.
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
110
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Oct 4, 2005 7:10 PM
in response to: seb
|
|
Sebastien Roy wrote On 10/04/05 17:30,:
> Right, and my point was that because this is run after
> milestone/network, the milestone's claims in its description are
> somewhat inaccurate.
Yes, I hope that will be fixed when IPsec startup is fully SMF-ized.
And note that milestone/network only (claims to) guarantee that there
isn't a hole that bypasses the policy, it doesn't guarantee that there
is actually any connectivity. So, for example, IKE wouldn't have to
be running, maybe keys wouldn't have to be loaded, but the SPD should
be in effect by that time.
-=] Mike [=-
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design
review extension (Oct. 7)
Posted:
Oct 5, 2005 7:13 AM
in response to: mditto
|
|
Mike Ditto wrote:
> Sebastien Roy wrote On 10/04/05 10:05,:
>
>>It's not clear what the original intent was. Do you know where the
>>documentation resides that covers what milestone/network means?
>
>
> It was discussed on the greenline alias during the Solaris IP Filter
> project but I can't find any record of those discussions.
For those internal, that thread's at:
http://taxman.eng/mail-archives/greenline-iteam/msg15370.html
Though basically the discussion here is accurate (which one would expect
since Mike was one of the authors of the proposal ;-).
Dave
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
123
From:
Registered:
6/15/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver design review extension (Oct. 7)
Posted:
Oct 8, 2005 11:17 AM
in response to: seb
|
|
Seb,
my comments are based on your latest doc dated 10/4/2005.
section 4.2.1 (page 4):
configured-ipv4 or ipv4 -
if these two mean the same thing then I think it's better to have
only one of them as the 'type' argument. in the dladm manpage, you
can explain that ipv4 means configured-ipv4.
same comment for configured-ipv6/ipv6 and automatic/auto
section 4.2.4 (page 6):
to be consistent with other dladm show-* commands, it's better to
use -p instead of -m.
section 4.2.5 (page 6):
maybe you can add down-iptun as well. this might be useful when you
want to shutdown the iptun service.
section 4.3.1 (page 7):
maybe you can add more info in the show_link output.
e.g.:
punchin0 type: IP tunnel mtu: 1480 tunnel type: ipv4
section 7.1 (page 13):
I am interested to know how you generate the macname. I suppose it
will be of the form iptun/<number> according to the clearview
naming treatise. is the <number> sequentially assigned? if so,
if someone creates a bunch of tunnels (using -t) before starting
the iptun service, will iptun_up() fail because the macnames in
iptun.conf are already taken? to avoid this problem, the iptun driver
probably needs to consult some global macname-to-linkname table
before generating the macname.
section 9:
other minor changes you might need are:
-make non-ethernet macs not aggregatable.
-disallow vlan creation on non-ethernet macs.
(both of these should only require checking dl_mac_type in the
right places)
-make dld_str_rx_raw(), str_mdata_raw_put(), not strip/insert vlan
tags for non-ethernet macs.
eric
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Clearview IP Tunneling Device Driver
design review extension (Oct. 7)
Posted:
Oct 8, 2005 1:15 PM
in response to: tlc
|
|
Eric,
Thanks for your comments.
On Sat, 2005-10-08 at 14:17, Eric Cheng wrote:
> section 4.2.1 (page 4):
>
> configured-ipv4 or ipv4 -
> if these two mean the same thing then I think it's better to have
> only one of them as the 'type' argument. in the dladm manpage, you
> can explain that ipv4 means configured-ipv4.
> same comment for configured-ipv6/ipv6 and automatic/auto
I don't have a strong feeling about this, I'll take your suggestion.
>
> section 4.2.4 (page 6):
>
> to be consistent with other dladm show-* commands, it's better to
> use -p instead of -m.
Ah, yes. I missed the other show commands' use of -p. I'll change it.
>
> section 4.2.5 (page 6):
>
> maybe you can add down-iptun as well. this might be useful when you
> want to shutdown the iptun service.
I originally had a down-iptun, but removed it because I couldn't really
think of a use for it. There's no reason to tear down tunnels when the
system shuts down, so how would it be used?
>
> section 4.3.1 (page 7):
>
> maybe you can add more info in the show_link output.
> e.g.:
> punchin0 type: IP tunnel mtu: 1480 tunnel type: ipv4
show-iptun shows the tunnel specific information.
>
> section 7.1 (page 13):
>
> I am interested to know how you generate the macname. I suppose it
> will be of the form iptun/<number> according to the clearview
> naming treatise. is the <number> sequentially assigned? if so,
> if someone creates a bunch of tunnels (using -t) before starting
> the iptun service, will iptun_up() fail because the macnames in
> iptun.conf are already taken? to avoid this problem, the iptun driver
> probably needs to consult some global macname-to-linkname table
> before generating the macname.
The iptun driver will pick unique numbers. These sorts of conflicts
will be easy to reconcile, and part of the information required to
specify how this will work is in the Vanity Naming design document which
has yet to be reviewed here. Basically, persistent mappings of link
names to mac names will be stored by the vanity naming subsystem. If a
temporary tunnel happens to request a macname that is already being used
by a persistent tunnel, mac_register() will return an error and the
iptun driver can attempt to use a different identifier for that tunnel.
Once the Vanity Naming document has gelled, I'll revisit this issue in
this design document.
>
> section 9:
>
> other minor changes you might need are:
>
> -make non-ethernet macs not aggregatable.
> -disallow vlan creation on non-ethernet macs.
> (both of these should only require checking dl_mac_type in the
> right places)
Ok, I'll specify that.
> -make dld_str_rx_raw(), str_mdata_raw_put(), not strip/insert vlan
> tags for non-ethernet macs.
I originally had that in the design doc, but we determined that because
those functions shouldn't be doing that even for Ethernet macs, this bug
should just be fixed independently of this project.
Thanks again,
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
123
From:
Registered:
6/15/05
|
|
|
|
Re: Re: Clearview IP Tunneling Device Driver design review extension (Oct. 7)
Posted:
Oct 9, 2005 4:46 AM
in response to: seb
|
|
> > section 4.2.5 (page 6):
> >
> > maybe you can add down-iptun as well. this might be
> useful when you
> > want to shutdown the iptun service.
>
> I originally had a down-iptun, but removed it because
> I couldn't really
> think of a use for it. There's no reason to tear
> down tunnels when the
> system shuts down, so how would it be used?
>
I don't think it's needed either. but for symmetry, it might be
better to have 'svcadm disable iptun' undo what 'svcadm enable iptun' does.
> >
> > section 4.3.1 (page 7):
> >
> > maybe you can add more info in the show_link
> output.
> > e.g.:
> > punchin0 type: IP tunnel mtu: 1480 tunnel
> type: ipv4
>
> show-iptun shows the tunnel specific information.
>
I thought it was a little odd to leave the 4th column blank when
all other link types show extra info there. I am fine with leaving it blank.
> > -make dld_str_rx_raw(), str_mdata_raw_put(), not
> strip/insert vlan
> > tags for non-ethernet macs.
>
> I originally had that in the design doc, but we
> determined that because
> those functions shouldn't be doing that even for
> Ethernet macs, this bug
> should just be fixed independently of this project.
>
agreed. this could be fixed as part of 6292043.
eric
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Re: Clearview IP Tunneling Device Driver
design review extension (Oct. 7)
Posted:
Oct 9, 2005 6:16 AM
in response to: tlc
|
|
On Sun, 2005-10-09 at 07:46, Eric Cheng wrote:
> I don't think it's needed either. but for symmetry, it might be
> better to have 'svcadm disable iptun' undo what 'svcadm enable iptun' does.
Agreed. The down-iptun subcommand will simply temporarily delete all
tunnels. I'll update the doc to reflect that.
>
> > >
> > > section 4.3.1 (page 7):
> > >
> > > maybe you can add more info in the show_link
> > output.
> > > e.g.:
> > > punchin0 type: IP tunnel mtu: 1480 tunnel
> > type: ipv4
> >
> > show-iptun shows the tunnel specific information.
> >
>
> I thought it was a little odd to leave the 4th column blank when
> all other link types show extra info there. I am fine with leaving it blank.
Ok, I'll leave it the way it is. I think this output will get re-worked
anyway with the Vanity Naming component.
>
> > > -make dld_str_rx_raw(), str_mdata_raw_put(), not
> > strip/insert vlan
> > > tags for non-ethernet macs.
> >
> > I originally had that in the design doc, but we
> > determined that because
> > those functions shouldn't be doing that even for
> > Ethernet macs, this bug
> > should just be fixed independently of this project.
> >
>
> agreed. this could be fixed as part of 6292043.
Right.
Thanks Eric,
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
