Re: [networking-discuss] UNH Requirement for ipsecv3
On Thu, Oct 28, 2010 at 02:39:00AM -0700, Naveen surisetty wrote: > One of the UNH Requirement for Ipsecv3 compatibility specifies the following > >There should be a facility to configure different incoming and outgoing > SA?s >based on ICMPV6 Type and Code Realistically, what real-world problem are you trying to solve by doing this? But to continue... >SA1-Incoming for Echo Request with 3DES/SHA1 >SA2-Incoming for Echo Reply with AES/SHA1 >SA3-Outgoing for Echo Request with 3DES/SHA256 >SA4-Outgoing for Echo Reply with AES/AESXXCBC You used ipsecconf(1M)'s code/type keywords, right? ECHO/ECHO-Reply is a bit special in our code, because we always reflect the reply's policy. This allows clearetext pings for diagnostic purposes. See here: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/ip/ip6.c#icmp_send_reply_v6 for the code. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] 6965774 bound the interface index in IP to [1, 65535]
On Tue, Jul 27, 2010 at 03:52:32PM -0400, Sebastien Roy wrote: > On 07/27/10 03:30 PM, Dan McDonald wrote: > >Someone mentioned IKE earlier in this thread. IKE _only_ uses the > >sockaddr_dl's index to create an appropriate listener for an IPv6 link-lock > >address. > > I thought it used sockaddr_in6 with sin6_scope_id for this (which > funnily enough is a 32-bit field). Only when starting up. If an IPv6 interface comes up later, in.iked discovers it using RTM_NEWADDR/RTM_CHGADDR messages. It's a bug, but a lower-priority one, because if you're bringing up that many IPv6 addresses after the fact, you're probably not using IKE on them (e.g. IPv6-in-IPv? tunnels). Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] 6965774 bound the interface index in IP to [1, 65535]
On Tue, Jul 27, 2010 at 03:22:27PM -0400, James Carlson wrote: > The only thing that's really affected by this problem is the old BSD > routing socket interface. In the case of adding a route, you can always > use the interface name instead of the ifIndex (sockaddr_dl supports > both), and that works fine. In the case of receiving a "surprising" > truncated rtm_index value, you can do the smart thing and validate all > potentially matching interface information you've got, as dhcpagent > already does by doing a comparison under a 0x mask. Someone mentioned IKE earlier in this thread. IKE _only_ uses the sockaddr_dl's index to create an appropriate listener for an IPv6 link-lock address. Someone did file a bug against IKE not to use the index, but we pushed it low because in practice very few use link-local IPv6 with IKE. IKEv2, BTW, doesn't have this problem, because it's not constricted by an old OEM protocol engine that needed per-address sockets to do the right thing. FYI, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Invalid host name resolving when IPv6 is enabled
On Fri, Jun 25, 2010 at 04:29:48PM +0200, Andrej Podzimek wrote: > Well 'dig' returns correct answers. So the bad responses do not come from > the name server. The bad responses are only produced by > gethostbyname()/getaddrinfo(), probably due to incorrect configuration. > (All works fine on Linux and FreeBSD on the same machine.) What does the entry for "ipnodes" say in /etc/nsswitch.conf? It should match "hosts": everywhere(~)[0]% egrep 'ipnodes|hosts' /etc/nsswitch.conf # DNS for hosts lookups, otherwise it does not use any other naming service. # "hosts:" and "services:" in this file are used only if the hosts: files dns mdns # Note that IPv4 addresses are searched for in all of the ipnodes databases # before searching the hosts databases. ipnodes: files dns mdns everywhere(~)[0]% Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Interesting issue: Cisco Nexus and Solaris NFS/UDP
On Tue, Jun 22, 2010 at 03:29:23PM -0400, James Carlson wrote: > > The Cisco Nexus 7k ships with this setting enabled by default: "hardware ip > > verify fragment". This is some security feature which purpose I don't > > understand. But what I do know is that this setting appears to cause the > > Nexus to drop IP packets that have the Don't Fragment (DF) bit set and a > > non-zero offset. I've verified this behavior by observing packet traces on > > the NFS client and the NFS server and can see packets with DF set and > > non-zero offsets getting dropped by the switch. > > That sounds crack-headed to me. > > Even when (or _especially_ when) the DF bit is set, it's expected and > acceptable to have the _sender_ emitting fragments. The DF bit is an > instruction to intermediate routers -- "please don't fragment this _any > further_" -- it is not something that the destination host or any > intermediate node has any business whatsoever attempting to "verify." I'm sure this is one of those firewall "security features" that drive we host vendors crazy. Your best bet, Alex, is to follow Jim's advice and use NFSv3 over TCP. You should also consider disable the "ip verify fragment" stuff from your cisco. Those cycles and/or HW heat-dissipation are better spent forwarding packets. Dan p.s. Been a happy Deere customer. ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] OpenSolaris zone as router & DHCP server?
On Tue, Jun 22, 2010 at 01:08:31PM -0400, James Carlson wrote: > I've never used NAT with non-global zones (just with external devices -- > my OpenSolaris box acts as the default gateway/firewall for the rest of > my network), but I'm sure someone else here has and can give details. Hi... I'm Someone Else. :) My "router" zone does NAT, serves DHCP, and its NAT configuration redirects certain services to certain other zones via conventional NAT port-mapping. It's worked out pretty well for me thus far. Again, just RTFM for normal node operations, and apply it to your exclusive-stack zone. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] OpenSolaris zone as router & DHCP server?
On Tue, Jun 22, 2010 at 08:40:26AM -0700, Ben wrote: > Hi all, > > I have an OpenSolaris 2009.06 box with five NICs. I want to create a zone > with two exclusive NICs and use it as my DHCP server and router. > > First of all, if this possible? Oh hell yes! ;) I do this at home already. > Secondly, if it is, how do I do it? (I know about configuring the zone, > it's just the DHCP server and router bit I'm stuck on) Thirdly, once I've > created the zone and configured it as a DHCP server, how can I create > static IPs for machines based on their MAC address? You'll have to RTFM on your appropriate DHCP server (Sun's/Oracle's or ISC) for those sorts of mapping questions. Configuring a router for a zone is just like doing it for a single-machine instance. > I have had a look and I've found some stuff for Solaris 9 and Solaris 10, > but I'm not sure how much of this is still relevant. Follow the S10 single-node instructions for starters. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] How to ignore DF-Bit?
On Mon, Jun 07, 2010 at 04:07:00PM +0200, Kai Krebber wrote: > Mmh - either I misunderstood the whole PMTUD-concept or I poorly > explained my situation: I assumed the problem was on the *external* network, not the internal one. > Sending Mailserver<->Solaris<->(ipsec-tunnel)<->VPN-Gateway<->receiving > mailserver > > Here's the snoop on the wan-interface (i.e. towards the sending > mailserver): > > 216.104.20.23 -> 213.172.123.138 SMTP C port=58657 Received: from out02 > 213.172.123.138 -> 216.104.20.23 ICMP Destination unreachable (Needed to > fragment: next hop MTU = 1402) > 216.104.20.23 -> 213.172.123.138 SMTP C port=59044 Received: from out02 > 213.172.123.138 -> 216.104.20.23 ICMP Destination unreachable (Needed to > fragment: next hop MTU = 1402) > : > > > 1)Sending mailserver sends Packet with 1450 Byte and DF bit set. 1460, no? > 2)Solaris would have to frag the packet to get it thru the tunnel, but > DF bit is set. So Solaris sends back the icmp need to frag (with next > hop MTU=1402) to the sending mailserver. > 3) sending mailserver ignores info and keeps sending big packets. > > Lowering the MTU on the tunnel interfaces wouldn't change the situation > - it only would lower the next hop MTU info in the icmp-Packet, wouldn't > it? Yes. I didn't realize your problem was on the *inside* network. You have no influence here? You could try this on the encrypting gateway: ndd -set /dev/ip ip_path_mtu_discovery 0 but I'm not sure off the top of my head if that setting will just not send ICMP NEEDS_FRAGMENTATION, or if it also ignores the DF bit. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] How to ignore DF-Bit?
On Mon, Jun 07, 2010 at 02:47:37PM +0200, Kai Krebber wrote:
> Hi!
>
>
> We have an Opensolaris 2009.6 - System acting as a router and
> terminating an IPSec-Tunnel. The IPSec-Tunnel obviously has an impact on
> the MTU.
> Some Internet servers do send large packets with DF bit set (typical
> PMTUD), but ignore the icmp 'dest unreachable / need to frag' - packets,
> Solaris sends out inreply (or maybe a firewall in front of the server
> blocks these icmp packets).
>
> So I'd rather accept suboptimal fragmentation than the situation, I
> currently have, i.e. the sender keeps on sending their too big packets
> and finally gives up.
>
> Not sure, how to tackle this.
>
> Since we can't parent everybody out there to please not block these icmp
> packets, we have to work around the issue.
>
> Ideally Solaris sends out the icmp type 3 code 4 as normal and if the
> same senders sends another packet with the same (too big) size (i.e. a
> simple retransmit), Opensolaris ignores the DF-bit and fragments the
> packet to get it thru the tunnel.
>
> How would I get there without rewriting the Solaris network stack? Maybe
> this problem is more common then I thought and there is already a
> workaround available?
Lots of poorly-configured firewalls drop PMTUD. :(
Have you considered explicitly lowering the MTU of your tunnel(s) ("ifconfig
ip.tun0 mtu 1376")? That way, the only nodes who need to worry about PathMTU
discovery are *internal* nodes, which you presumably have more control over?
Dan
___
networking-discuss mailing list
networking-discuss@opensolaris.org
Re: [networking-discuss] ospf via ipsec tunnels
On Tue, Apr 20, 2010 at 10:09:28PM +0200, Kai Krebber wrote: > Any idea, why the default route doesn't get redistributed? I thought any manually-added routes to be injected needed to be configured in quagga instead of via other system routing repositories. A quagga wizard can confirm/deny this, however. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] ospf via ipsec tunnels
Looks like Paul beat me to the list...
On Tue, Apr 20, 2010 at 07:47:51PM +0200, Kai Krebber wrote:
> r...@kunde003-wan:~# cat /etc/inet/ipsecinit.conf
> {tunnel ip.tun0 negotiate tunnel laddr 0.0.0.0/0 raddr 192.168.100.0/30}
> ipsec {encr_algs 3des encr_auth_algs sha1 sa shared}
> {tunnel ip.tun1 negotiate tunnel laddr 0.0.0.0/0 raddr 103.0.0.0/24} ipsec
> {encr_algs 3des encr_auth_algs sha1 sa shared}
>
>
> The current config doesn't reflect my actual requirement (i.e. reaching the
> LAN 120.0.0.0/24 behind the remote router). For now I'm concerned to get
> OSPF working, hence I tailored the ipsec config to guarantee reachability
> between the tunnel interfaces.
If you change raddr to 0.0.0.0/0, do things still work in unicast? If so,
they will definitely start working with multicast too.
Or you could add this entry:
# Give mcast a chance...
{tunnel ip.tun0 negotiate tunnel laddr 0.0.0.0/0 raddr 224.0.0.0/4} \
ipsec { }
I'm curious to know which SAs the Juniper OSPF traffic used, and what
"ipseckey get spi dst " says about their ISRC/IDST values.
Dan
___
networking-discuss mailing list
networking-discuss@opensolaris.org
Re: [networking-discuss] ospf via ipsec tunnels
On Tue, Apr 20, 2010 at 07:39:03PM +0200, Kai Krebber wrote: > 2010/04/20 11:31:07 OSPF: Hello received from [192.168.100.1] via > [ip.tun0:192.168.100.2] > 2010/04/20 11:31:07 OSPF: src [192.168.100.1], > 2010/04/20 11:31:07 OSPF: dst [224.0.0.5] > 2010/04/20 11:31:07 OSPF: Hello sent to [224.0.0.5] via > [ip.tun0:192.168.100.2]. Does your tunnel's IPsec policy have anything to say about multicast packets? If not, they'll DROP. Add policies for your mcast packets that match the other tunnel policy w.r.t. actions. You'll generate distinct SAs, but it'll probably work. Do the Juniper-originated multicast packets use a distinct SA from your other tunnel traffic? Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Port forwarding to non-global zones and external IPs - recipe? (snv_134)
> In brief: Want to send all WAN traffic to one interface in a given (global? > non-global?) zone, effectively making it the DMZ. From there, wish to > implement port forwarding to specific vnics, each on its own non-global > zone, on Box 'A'. In addition, we'd like to forward specific ports (80? > 443?) to IP addresses external to the openSolaris box; Boxes 'B', 'C', etc. I do this already on my home server. In the context of a different problem: http://blogs.sun.com/danmcd/entry/do_a_pkg_image_update I use ipfilter in the "router" zone, which is nonglobal. > Does anyone know of a specific recipe? Running a router/NAT/whatever in a non-global zone and using ipfilter is a good start. On my own home server, I have two physical NICs, one is connected to the Internet, the other is connected to my internal switch. Zones on the internal switch have VNICs over the physical NIC that's plugged in. I don't use resource controls, but each VNIC plugged into the internal switch could have such controls on 'em, I suppose. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Using tun interface with dladm and flowadm
On Thu, Mar 25, 2010 at 07:20:41PM +0100, Antoine Benkemoun wrote: > Ok I understand. > > I am trying to limit the bandwidth of the users coming out of my OpenVPN > VPN. Is this possible with flowadm ? If all of the flows using OpenVPN share the same port (e.g. 443, which is SSL), you can use flowadm and restrict traffic on that port. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Using tun interface with dladm and flowadm
On Thu, Mar 25, 2010 at 07:05:36PM +0100, Antoine Benkemoun wrote: > Thank you for your quick answer. > > I am running OpenSolaris 2009.06. I realize that this is not a sufficient > answer but I have no idea how to find out what my build is... My login > banner displays "snv_111b November 2008". I guess this is an older build. > How would I upgrade to a newer build ? Do you know a good tutorial for this > ? You reparent your publisher to pkg.opensolaris.org/dev. > I installed the Universal Tun/Tap driver from this source : > http://vtun.sourceforge.net/tun/. My goal is to use OpenVPN. Is the iptun > interface you mention compatible with OpenVPN ? Ahhh yes. That driver is IP-over-SSL, and is not a Generic Lan Driver (GLDv3) device. The iptun driver is merely IP-in-IP, but it does present as a GLDv3 device, so it can be flow-sliced, virtualized, or anything else you want. You can then use ipsecconf(1M) to set up tunnel-mode IPsec on a particular IP-in-IP device. Standard question: What problem are you trying to solve? Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Using tun interface with dladm and flowadm
On Thu, Mar 25, 2010 at 06:27:48PM +0100, Antoine Benkemoun wrote: > I would like to use flowadm to do some bandwidth management on a tun > interface. The problem is that it is not recognized by the dladm utility. It > appears in *ifconfig -a* but not in *dladm show-link*. Do you mean iptun(7d) that went back in build 125? That should be there. My build 135 system shows it: (0)# dladm show-link LINKCLASS MTUSTATEBRIDGE OVER e1000g0 phys 1500 up -- -- iwh0phys 1500 down -- -- ip.tun0 iptun 1402 up -- -- (0)# > Is this normal ? Did I miss something ? What version are you running again? Are you actually running S10? Or are you talking about some other tun? Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Nomination of Dan McDonald to core-contributor status in the networking community
On Tue, Feb 09, 2010 at 04:57:47PM -0800, Nicolas Droux wrote: > Closing the loop on this... Thank you. > Dan, you have have the required votes (three +1's from existing Core > Contributors, and no objections) for becoming a Core Contributor of the > Networking Community. Could you please explicitly accept your nomination and > agree to the following policy: > > http://wiki.genunix.org/wiki/index.php/OGB_2009/007 I accept the nomination, and the electoral responsibilities that go along with it. Thanks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] VNICs over nge, bge, or does it matter?
Garrett -- That was my gut reaction, but I didn't want to predispose anyone. I also have had face-to-face advise that matched your recommendation. So it sounds like nge0 goes out to the Internet. (I will also find out this way if the Ethernet port on the Verizon FiOS ONT is 100Mbit or GigE.) Thanks! Dan -- This message posted from opensolaris.org ___ networking-discuss mailing list networking-discuss@opensolaris.org
[networking-discuss] VNICs over nge, bge, or does it matter?
Hey folks! My home server has two NIC ports an nge0 and a bge0 (Tyan S2866 mobo). I'm going to dedicate one to an external network, and slice the other among three internal network zones (Internal-only server, Internal-side of NAT, and proxy-ARP + VPN server). Which should I slice into VNICs? Does it matter? I thought perhaps one driver or piece of HW might lend itself to VNICs better than the other. Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] IPSec interoperability between Solaris and Windows XP
On Thu, Dec 24, 2009 at 12:17:45PM +0530, Krishna Mohan wrote: > I’ve used preshared > key – “asdfghjklqwertyuiopzxcv” in Windows XP and the same key converted to > hexadecimal “666473616b6a68676577716c757974727a706f690a766378” been used in > solaris. > > I’ve also tried as “echo “asdfghjklqwertyuiopzxcv” > | tr –d ‘\n’ | od –t x” You're byteswapping. asdf isn't 66647361, it's 61736466. You did this on an x86 box, which stores words in byteswapped (little-endian) order. See this blog entry for important safety tips on mistakes like this: http://blogs.sun.com/danmcd/entry/endian_independence_not_just_for You should do this for your od: od -tx1 which will spit things out one byte at a time, neatly avoiding byteswapping. Try again without the byteswapping (and without the newline, you got that part right). Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] New project proposal: Shim6: Level 3 Multihoming Shim Protocol for IPv6
On Fri, Dec 04, 2009 at 01:30:59AM -0800, Erik Nordmark wrote: > >It's certainly good that there's progress, but if it turns out to be > >another Mobile IP ... > > Folks have been complaining about the fact that an IP address is both > a locator and identifier for at least 20 years. Hence the RRG effort > around ID/Locator separation. But at the same time the Internet is so > full of inertia (due to existing technical practises, existing > business models, etc) that it isn't clear if *any* radical changes > can be deployed. > > The benefits of Shim6 and MPTCP is that they can be deployed at the > edge, hence they don't need approval from the operators. And they are > a very nice fit for the multihomed laptop with a WiFi plus a Cellular > interface. > > The benefits of LISP is that is it deployed by the operators. > > Fundamental question is whether the users at the edge or the > operators have more incentives to deploy something new. I'm slightly > more optimistic about the edge. I didn't want to bring up LISP (or any other ID/Locator split proposals) explicitly, but thank you for doing so, and for making a clear case for the advantages of Shim6. I don't think you need it, but since I just got this networking core-contributor grant, I figure I ought to use it: ACK for Shim6. Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
[networking-discuss] Contributor/core-contributor grants for Team IPsec
On 11/20/09 15:45, darren.r...@sun.com wrote: > > On (11/20/09 17:02), Sebastien Roy wrote: > >> On Fri, 2009-11-20 at 12:00 -0800, Darren Reed wrote: > >>> In light of Dan McDonald's previous and ongoing work in IPsec, I'd like > >>> to nominate him for core-contributor status in the networking > >>> community. > > > > +1 > > And that makes 3 +1's (Sebastien Roy, James Carlson, Swmini Varadhan.) > > Congratulations, Dan, welcome to the fold. Thanks (assuming I'm not jumping the gun over anyones objections...). I took a look at the grants of other Team IPsec members: UserNetworking grant markfen Contributor (EXPIRED 2009-02-24) pwernau Contributor (EXPIRED 2009-02-24) sommerfeld Contributor (EXPIRED 2009-02-24) vkotal None Assuming I haven't jumped the gun over anyone's objections, I would like to nominate refreshed grants: FOR CORE CONTRIBUTOR: Bill Sommerfeld (sommerfeld), Mark Fenwick (markfen) FOR CONTRIBUTOR: Paul Wernau (pwernau), Vladimir Kotal (vkotal) I can provide supporting documentation (code contributions, etc.) for each if you wish. I will also note that being listed in "contributor" may have meant declining "core contributor" status by choice. Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
[networking-discuss] Thank you folks for IKEv2 consensus!
On Fri, Nov 20, 2009 at 11:35:00AM -0500, Dan McDonald wrote: > Hello networking and security communities! > > I would like to request sponsorship from BOTH communities for the following > project (this is also the introduction to the in-progress design document): I'm assuming (correctly?) no objections and I've seen core-contributor +1s from: Networking --> seb, carlsonj, sowmini Security --> darrenm, gww, gbrunett This should be enough for both communities. Thank you very much! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Request for community sponsorship --> IKEv2
On Fri, Nov 20, 2009 at 11:35:00AM -0500, Dan McDonald wrote: > Hello networking and security communities! > > I would like to request sponsorship from BOTH communities for the following > project (this is also the introduction to the in-progress design document): > > The Internet Key Exchange Protocol, version 2 (IKEv2), is used to > mutually authenticate two parties and derive Internet Protocol > Security (IPsec) keying material. It is a successor protocol to IKE > (referred to in here as IKEv1), which was implemented originally in > Solaris 9 as documented by PSARC case 199/166. IKEv2 is currently > specified by RFC 4306, along with clarifications in RFC 4718. A new > Internet-Draft (referred to here as IKEv2bis) attempts to unify 4306 > and 4718, along with solving additional issues. When there is > ambiguity, this design will follow the guidance of IKEv2bis. > > I would like sponsorship from both, as most IPsec technologies straddle both > communities. Oooh, I'm not sure if I'm allowed, but since I am a core-contributor in security, I would like to give a +1 if and only if I'm allowed. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
[networking-discuss] Request for community sponsorship --> IKEv2
Hello networking and security communities! I would like to request sponsorship from BOTH communities for the following project (this is also the introduction to the in-progress design document): The Internet Key Exchange Protocol, version 2 (IKEv2), is used to mutually authenticate two parties and derive Internet Protocol Security (IPsec) keying material. It is a successor protocol to IKE (referred to in here as IKEv1), which was implemented originally in Solaris 9 as documented by PSARC case 199/166. IKEv2 is currently specified by RFC 4306, along with clarifications in RFC 4718. A new Internet-Draft (referred to here as IKEv2bis) attempts to unify 4306 and 4718, along with solving additional issues. When there is ambiguity, this design will follow the guidance of IKEv2bis. I would like sponsorship from both, as most IPsec technologies straddle both communities. Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] need vpn tunnel configuration help
On Thu, Nov 19, 2009 at 04:23:11PM -0500, Jim Barker wrote: > I posted my log with the Vendor IDs that were reported and the only > thing I recognized was "Cisco Unity", does that lend a hint as to > the answer you needed? Not quite, but you answer more later... > I also saw a reference to XAUTH and this link is currently working with a > Checkpoint s...@office 500 which I am trying to replace with this Solaris > machine. Do you need to enter some sort of passphrase to bring up your Checkpoint box? If so, you're probably actually USING XAUTH. (The Vendor ID just means there's support there.) > I am trying to use this as a router. Ahhh, now this gets much more interesting. We may need to take this offline because of details, but I'm going to need some information. This includes: - Network prefixes on your side? - Network prefixes on the side of the cisco? - External (Internet) addresses being used on your side and on the cisco's side. - What IKE and IPsec parameters are you using? Please repond in unicast if you're worried about using real IP numbers. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] need vpn tunnel configuration help
On Thu, Nov 19, 2009 at 12:47:22PM -0800, Jim Barker wrote: > I know this is an old posting, but I ran into the exact same problem > connecting to a Cisco device. Does anyone know of how to get the IPSec > available on Solaris 10 update 7 to work when attempting to communicate to > a Cisco device? Technically, you should be asking your Sun Support people about any Solaris 10 release, and not this alias. I can tell you how to configure OpenSolaris, and quite frankly, whatever I say here will have a good chance of working with S10 as well. I'll need to know some specifics. - Is this a "cisco vpn" server (i.e. secure remote access for a single machine)? If so, you are out of luck, as they use IKEv1 extensions (XAUTH and CFG) that we do not implement. - If you are trying to access an internal network without XAUTH and CFG extensions, we'll need to know a bit more details. Are you using OpenSolaris as a router, or as a single machine that plugs-in to a bigger internal network? Hope this helps, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] messages on console
On Tue, Oct 27, 2009 at 04:02:39PM +0100, Fred wrote: > Hi all. > > I red there is no problem with it but I'd like to fix this. I keep receiving > on console in different servers the following: > > Oct 27 14:43:09 sapaxdb02 ip: [ID 390400 kern.notice] dst AC1F2F5B src > 7F01 Hmmm. This looks like someone from outside is trying to send IP datagrams with src == 127.0.0.1 (which is a big-endian 0x7f01). Can you snoop(1M) and see if these are actually originating from the wire? Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Start of code review for IP datapath refactoring
This bit of review only covers the XIPSEC comments in the refactor-review webrev. usr/src/uts/common/inet/ip.h * Yes, we really need these because they are filled in during the finding of a policy and subsquent SA, and they get placed into the ACQUIRE record. Also, with IKEv2 coming down the stretch, we'll want the original packet's selectors, even if the SPD rule's selectors are a superset. This is to enable IKEv2 traffic-selector narrowing. usr/src/uts/common/inet/sadb.h * SA_FORM_UNIQUE_ID() is an expression often passed into a function. It'd be hard to split this out into tunnel vs. transport. usr/src/uts/common/inet/ip/icmp.c * if ip_output_attach_policy() returns NULL, the packet didn't pass IPsec policy on the outbound side (e.g. an explicit drop rule). ipdrop's been invoked in these cases. Perhaps EHOSTUNREACH or EPERM? The former is used by TX when these sorts of policy failures occur. It could also be ENOMEM if allocations were a problem. usr/src/uts/common/inet/ip/ip.c * FireEngine broke ipsec_override_persocket_policy and we never recovered. Ideally we should have a way to restricting per-socket policy from overriding the SPD, even if we don't do it by default today. Lose the comment, but we need to fix this S10 regression at some point. I swore I filed a bug, but I can't find one so I guess I didn't. This isn't a problem specific to refactor. usr/src/uts/common/inet/ip/ip6_input.c * Yes, and you already do the right thing by passing the ira to icmp_param_problem_nexthdr_v6(), which will do the new-world version of ipsec_in_to_out for packet protection. * You may wish to do an early AH check, as is done in the IPPROTO_ROUTING case. usr/src/uts/common/inet/ip/ip6_output.c * Same ansewer as icmp.c. usr/src/uts/common/inet/ip/ip_input.c * IRAF_ESP_UDP_PORTS is for NAT-Traversal. These should be treated like ESP packets, even though they're in UDP. * Not sure about tsol_accept_raw. * Am sure that we keep the inner header for iptun purposes. usr/src/uts/common/inet/ip/ip_output.c * If you're picking different source addresses, you'll probably need a separate ixas UNLESS the sending socket is using per-socket policy. usr/src/uts/common/inet/ip/ip_sadb.c * ipl isn't always set if it's an unconnected socket. usr/src/uts/common/inet/ip/ipsecah.c * You could replace ah_rput() with putnext. * You're right about the comment in ah_insert_prop() it's based on the list of actions in the rule or socket that got slammed on to the acquire record. * The sync-on-stack stuff has been addressed in my work on refactor-gate. * Thanks for catching the double-free. usr/src/uts/common/inet/ip/ipsecesp.c * Same replies as in ipsecah.c usr/src/uts/common/inet/ip/sadb.c * inidle_overflow is correct in sadb_buf_pkt. usr/src/uts/common/inet/ip/spd.c * I thought we took care of conn_ref before cleaning conn_latch_in_action. Did we not fix that? * Perhaps renaming ipsec_check_global_policy is a good idea, but you shouldn't get stuck doing it. * I have a fix for 2437. usr/src/uts/common/inet/iptun/iptun.c * 2804 -- this was what was discovered with 6886919. You need to always call ipsec_tun_inbound() and ipsec_tun_outbound() to check global. Unless what surrounded it changed such that 6886919 doesn't exist. usr/src/uts/common/inet/sctp/sctp_common.c * You probably do need to redo policy, but there's an open bug on SAs and SCTP: 6330149 SCTP doesn't work with "sa unique". and there are probably others. usr/src/uts/common/inet/sctp/sctp_conn.c * See the aforementioned IPsec + SCTP bug. :( usr/src/uts/common/inet/sctp/sctp_cookie.c * This logic applies IPsec? Is this an SCTP-equivalent of a reset? If so, then yes, reflecting the policy is right. Otherwise, you only send (and accept) the packet based on the global or per-socket policy. usr/src/uts/common/inet/sctp/sctp_error.c * Same here as sctp_cookie.c. usr/src/uts/common/inet/sctp/sctp_hash.c * Ooh, that's an onnv bug. You should pass in ipha and ip6h to ipsec_check_inbound_policy() and lose the v4-only check. usr/src/uts/common/inet/sctp/sctp_input.c * Same here as with sctp_hash. usr/src/uts/common/inet/tcp/tcp.c * I'm not sure about just trusting the SYN. It shouldn't matter, but the hairs on the back of my head go up if we don't do the full inherit-policy thing. ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] What is this code's history and reason for being here still?
And for bonus points...
Do this:
main()
{
setup_func();
test_func();
}
where setup_func is something like this:
void
setup_func(void)
{
uint32_t garbage[] = {0xdeadbeef, 0xfeedface, 0xbaddcafe,
/* at least 128 bytes of garbage */};
int i;
for (i=0 ; i < (sizeof (garbage) / sizeof (uint32_t)); i++)
printf("Garbage %d, 0x%ux\n", garbage[i]);
}
that way, you'll have a clobbered stack.
Dan
___
networking-discuss mailing list
networking-discuss@opensolaris.org
Re: [networking-discuss] What is this code's history and reason for being here still?
Try it on SPARC too with the same flags the kernel would use. Don't take any chances with this one. And disassemblies might be nice, too. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] IPsec question: Start of code review for IP datapath refactoring
On Wed, Sep 30, 2009 at 05:34:49AM -0700, Erik Nordmark wrote: > I went and looked at onnv-gate and there is no such thing in the receive > side for global policy for a clear-text packet. > > If a clear-text packet comes into ip_input it calls > if (ip_iptun_input(NULL, mp, ipha, ill, ire, ipst)) > i.e., no M_CTL. > > Then the packet is passed to iptun_input that looks at IPsec policy iff > there is an M_CTL. > > Thus a cleartext tunneled packet plus just a global IPsec policy doesn't > result in a policy check for iptun in Nevada. > > TCP and UDP input does check for a global policy (in ip_tcp_input and > ip_udp_input). > > Is the above a bug in Nevada? It seems to be. I'll confirm this later in the morning. BTW, ipsec_tun_inbound() is supposed to be called regardless of whether or not there's an M_CTL present or not. It contains checking for global policy too if an ipsec_tun_pol_t isn't hanging off the iptun_t. > In any case, IP datapath refactoring behaves the same as Nevada in this > case. I need to confirm the breakage. Also, I don't recall the "ipsec" variable in iptun_input() being in earlier revs of in-development clearview-iptun. Actually, it may have been a cleanup attempt that didn't account for something. Regardless, it does look like a bug (possibly a serious security hole, actually). Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Code review: 6713844 inetd core dump bugs with incorrect xml file
I'll sponsor you. (And I'll say it on request-sponsor as well.) Dan -- This message posted from opensolaris.org ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Default TCP window size -- why still 48k?
On Tue, Sep 01, 2009 at 12:34:47PM -0500, Nicolas Williams wrote: > Well, IIRC Solaris tries to track window scale, and path MTU, in the > IRE. But how can the OS know whether an app will be doing bulk > transfers and so needs large buffers? Ideally we could make the buffers > (and window scale) dynamic. The scale is dynamic -- but it maxes out at 48k right now. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Default TCP window size -- why still 48k?
On Thu, Aug 27, 2009 at 10:12:33AM +0800, Kacheong Poon wrote: >> So at 10Mbit, that: >> >> 125 bytes * 0.185sec == 231250 bytes. >> >>> I think the default should be changed. >> >> Perhaps to 256k then? (It would cover your case that way.) > > > I guess that should be fine for most usage. Filed bug 6877986. The hard part is getting data to see if 256k is enough. NOTE: this would be a short/medium-term fix. The LONG-TERM solution is to do something RTT-based and dynamically determine limits. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] [clearview-discuss] Clearview IP Tunneling code-review [due August 12]
On Mon, Aug 31, 2009 at 10:18:14AM -0400, Sebastien Roy wrote: > > > >* 949-991: The locking here might be fine, but I can't make > > heads > > > > or tails of it. Seems like a lot of IPsec machinery is > > directly > > > > exposed to consumers. > > > > > > DEFER: There is quite a bit of direct manipulation of internal data > > > structures from the IPsec implementation here, but I don't think there's > > > much that I can do about it short of implementing a higher level kernel > > > API for this stuff (there doesn't appear to be one). > > > > OK. In general, it seems like an IPsec API layer is missing. > > Is seems so, yes. There *is* an API layer for per-endpoint policy (IP_SEC_OPT socket option) -- and indeed prior to IPsec Tunnel Reform, this codepath took the passed-in ipsr and rebundled it as a T_OPTMGMT_REQ to be passed to IP. Post-Tunnel-Reform, policy enforcement had to be moved up into the decapsulation path, because for Tunnel-Mode protection, enforcement decisions require knowlege of inner-packet fields. The fanout logic in IP for the outer-header doesn't know if the tunnel is enforcing full Tunnel Mode, or not. It was a question of where to put the mess, and I decided in Tunnel Reform to put the mess in the tunnelling code. The API you desire can't be used. You could move iptun_set_sec_simple() and friends out of iptun.c, but then someone would complain that iptun internals are in the IPsec code. Someone must lose. (If you really think it needs relocation, put it in spd.c.) > > > >* 1079-1092: Punting this to the hapless caller via EAGAIN > > > > complicates the interface with an implementation artifact. > > > > Seems like another mechanism is needed here. (IIRC, GLDv3 > > > > ioctls are not allowed to block, which means the mechanism > > > > might need to be quite a bit different.) > > > > > > DEFER: I've brought this up with the IPsec team and Erik Nordmark, and > > > the consensus was that since we'll never run into this problem (you need > > > IPsec keys and policy to use IPsec tunnels, and the creation of those > > > objects will have loaded IPsec before tunnels are created), it was not > > > worth my re-architecting how IPsec is loaded at this point. > > > > If we can never get here, then I'd think this would be a panic(). If we > > can get here, then is EAGAIN really good enough? > > We can get here, but only under contrived scenarios. You'd have to set > IPsec policy on the tunnel without having created any IPsec keys nor > started IKE nor loaded any other global IPsec policy. When we create > tunnels during boot, those other things are done first. When IPsec > tunnels are created by something like a VPN, those things are also done > first. It would only be in a case where someone is playing around and > doing things out of order that this would come up. They'd get EAGAIN, > and indeed, trying again would work. Boot-time dependencies should be (Seb, I asked you this explicitly offline) such that EAGAIN doesn't happen during boot-time. Here's how you could get EAGAIN: 1.) Boot system with NO IPsec policy. 2.) Before doing anything else, plumb a tunnel like so: ifconfig ip.tun0 plumb foo bar tsrc o-foo tdst o-bar \ encr_algs aes encr_auth_algs sha512 up You can reduce the chances of EAGAIN happening by waiting for the loader thread to finish (say a kernel-sleep of 100-500ms) and checking ipsec_failed() and ipsec_loaded() a second time. Ultimately, we want to reduce the cruft in ifconfig(1M), right? We might as well not worry too much about the path that only occurs via ifconfig(1M) features that in the medium- or long-term we wish to discard. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Default TCP window size -- why still 48k?
On Thu, Aug 27, 2009 at 10:12:33AM +0800, Kacheong Poon wrote: >> So at 10Mbit, that: >> >> 125 bytes * 0.185sec == 231250 bytes. >> >>> I think the default should be changed. >> >> Perhaps to 256k then? (It would cover your case that way.) > > I guess that should be fine for most usage. Cool! I *thought* there was an RFE already filed. Perhaps not. Does anyone else in the peanut gallery have any thoughts? Thanks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Default TCP window size -- why still 48k?
On Thu, Aug 27, 2009 at 09:54:05AM +0800, Kacheong Poon wrote: > Dan McDonald wrote: > >> Am I on crack? Or is this sensible. One other OS seems to have theirs >> default to 512k. I'd personally prefere 1MB, but can be swayed. Hmmm, my data on other platforms is stale or incorrect. I see 64k on MacOS X: mactavish(~)[0]% sysctl -a | grep tcp | grep space kern.exec: unknown type returned net.inet.tcp.sendspace: 65536 net.inet.tcp.recvspace: 65536 mactavish(~)[0]% > Just wondering, how is the 1MB number obtained? Two words: Thin Air. :) > As an example > of client usage, I use VPN to connect back to the US Sun network > from Hong Kong. Punchin? (just curious) > The path also goes through some NAT box. I use a xDSL link with > 30Mbps/10Mbps (down/up) speed. The RTT is ~185ms to machines in Santa > Clara. So at 10Mbit, that: 125 bytes * 0.185sec == 231250 bytes. > I think the default should be changed. Perhaps to 256k then? (It would cover your case that way.) Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Default TCP window size -- why still 48k?
9 months ago, I asked: On Thu, Nov 20, 2008 at 02:10:45PM -0500, Dan McDonald wrote: > shell(~)[0]% ndd -get /dev/tcp tcp_xmit_hiwat > 49152 > shell(~)[0]% ndd -get /dev/tcp tcp_recv_hiwat > 49152 > shell(~)[0]% > > Why are our TCP window sizes by default so small? Many transactions are > performed these days over either long-distances, with latency-inducing > encryption from IPsec or some VPN middlebox/middleware, or worse, with one or > more layers of latency-inducing middleboxes like NATs in between. Given recent discussion on another list about performance of a network-centric service, I have to wonder how much of those problems are related to wicked-small window sizes. I do realize that the long-term Right Answer (TM) is some sort of auto-tuning mechnanism, but in the short term, it shouldn't be rocket science to put back larger default values into the ON gate. Am I on crack? Or is this sensible. One other OS seems to have theirs default to 512k. I'd personally prefere 1MB, but can be swayed. Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] [clearview-discuss] Clearview IP Tunneling code-review [due August 12]
On Wed, Aug 26, 2009 at 01:06:30PM -0400, Sebastien Roy wrote: > > * 840: Function name seems too general. Moreover, it seems like > > there's one or more missing IPsec utility functions, as this > > code looks tedious and repetitious. > > ACCEPT: It is, and I also noticed that it inserts IPsec policy for both > IPv4 and IPv6, which doesn't make sense to me. A tunnel can only > transmit one or the other depending on its type. This code look > identical to the ipsec_set_req() code that sets per-socket policy. I've > created an ipsec_insert_policy() in ip.c that this and ipsec_set_req() > now both call. You should move ipsec_insert_policy() into spd.c, not ip.c. spd.c also links into ip, and such an IPsec policy function is best contained in spd.c. Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Solaris Router Discovery
On Sat, Jun 27, 2009 at 12:23:19AM -0700, Ben Rockwood wrote: > So my question is... given that it seems switch vendors such as Force10 > aren't supporting IRDP any more, and RIPv2 is generally considered taboo by > network administrators, what options do I have for router discovery? I'm pretty sure the latest version of in.routed performs all of the tasks in.rdiscd used to do... ... yep, it sure does. Here: http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/cmd-inet/usr.sbin/in.routed/rdisc.c Hope this helps, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
[networking-discuss] (new, improved) SMALL(er) CODE REVIEW - 6845208
Earlier I wrote: On Thu, May 28, 2009 at 11:33:03AM -0400, Dan McDonald wrote: > On Tue, May 26, 2009 at 11:32:39PM -0400, Dan McDonald wrote: > > > > I have a webrev that you, Jiri, and the rest of the networking community > > should see: > > > > http://cr.opensolaris.org/~danmcd/6845208/ > > > > The bug involves something I put in right after IPsec Tunnel Reform. > > Unfortunately, I fixed it poorly, but nobody seemed to notice until you > > started pushing out near-MTU UDP/IPv6 with ESP datagrams. I've improved on it thanks to several code reviewers. Please visit the above URL again, and know that it passed the near-MTU ping cases (for both ICMPv6 and UDP) as well as IKE-STC. Thanks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] bug fix for code review
On Tue, Jun 02, 2009 at 10:50:44AM -0400, sowmini.varad...@sun.com wrote:
> On (06/02/09 10:20), James Carlson wrote:
> >
> > It'd be nice to be doing bit tests with "!" rather than "== 0". The
> > former seems much more legible to me.
> >
>
> Do you mean this:
>
> if (!(nce->nce_flags & NCE_F_PERMANENT)) {
I think he does. For flag-values, this is probably preferred.
> (I have seen both styles used in the code, in different places)
Interesting, but I agree with Jim, as your example here illustrates.
Dan
___
networking-discuss mailing list
networking-discuss@opensolaris.org
Re: [networking-discuss] Lost/dropped messages whensendingIPv6/IPsec UDP datagrams
On Fri, May 29, 2009 at 09:27:59AM +0200, Jiri Klimes wrote:
> >-max_frag) {
> >+max_frag && connp != NULL &&
> >+(flags && IP6I_DONTFRAG)) {
> > /*
> > * IPsec headers will push the packet over
> > the
> > * MTU limit. Issue an ICMPv6 Packet Too
> > Big
> > * message for this packet if the
> > upper-layer
> > * that issued this packet will be able to
> Oops, looks like ugly typo: (flags && IP6I_DONTFRAG) should be (flags &
> IP6I_DONTFRAG) ;-)
> Besides that, it looks good for me.
Good catch. I've updated the webrev.
Dan
___
networking-discuss mailing list
networking-discuss@opensolaris.org
Re: [networking-discuss] Lost/dropped messages when sendingIPv6/IPsec UDP datagrams
On Thu, May 28, 2009 at 02:33:20PM -0400, Dan McDonald wrote:
> Thank you! I'll spin a new fix. Watch the webrev for a change.
I've updated the webrev, and it's much smaller/cleaner now, the diffs can
even fit in an e-mail...
@@ -11151,11 +11151,12 @@
/* Do IPSEC processing first */
if (mctl_present) {
int extra_len = ipsec_out_extra_length(first_mp);
if (ntohs(ip6h->ip6_plen) + IPV6_HDR_LEN + extra_len >
-max_frag) {
+max_frag && connp != NULL &&
+(flags && IP6I_DONTFRAG)) {
/*
* IPsec headers will push the packet over the
* MTU limit. Issue an ICMPv6 Packet Too Big
* message for this packet if the upper-layer
* that issued this packet will be able to
Thanks Seb!
Dan
___
networking-discuss mailing list
networking-discuss@opensolaris.org
Re: [networking-discuss] Lost/dropped messages when sendingIPv6/IPsec UDP datagrams
On Thu, May 28, 2009 at 02:10:03PM -0400, Sebastien Roy wrote: > Right, but I'm confused about why the behavior of the system (whether or > not the packet is dropped and whether or not an ICMPv6 packet makes it > up the stack) is now a function of whether or not IPsec policy happens > to be in use. That seems arbitrary, and doesn't make sense to me. When IPsec isn't in use, there's no case where IPsec overhead will cause the packet to fragment. We want to send a hint up to TCP to lower the MTU, but for UDP and other transports, we still want the packet to be transmitted. In cleartext, it's simple: - Send w/o fragmentation. - Send w/fragmentation. With IPsec, we need to signal to MTU-aware transports that they need to back off because IPsec shrinks their MTU. At the same time, we do NOT want to have non-MTU-aware transports have packets drop. This is a distinct check that occurs prior to IPsec processing. > > This was causing DROPPED PACKETS if they are of certain sizes (within > > default-IPsec-overhead of MTU). The filer found it with UDP. I reproduced > > it with ICMPv6 (ping) as well. > > > > Does this clarify things? > > A little, but I still question the fix. In the non-IPsec case, when the > packet is too big, we only call icmp_pkt2big_v6() and drop the packet if > IP6I_DONTFRAG is set (see the code at 6). > Why would this be any different if IPsec happens to be in use? Why would > we need to call ip_ulp_cando_pkt2big() when IPsec is in use, but not when > it's not in use? In other words, if this is indeed the correct fix, then > there should be a call to ip_ulp_cando_pkt2big() in the non-IPsec case at > 6 as well, no? No... and you point out why... > Conversely, if you argue that the code at 6 is correct for the > non-IPsec case, then logically, ip_ulp_cando_pkt2big() is not needed, > and the IPsec case you're changing should look exactly like 6. > ... yes. I believe we have all the data we need to make that decision there. Thank you! I'll spin a new fix. Watch the webrev for a change. Thanks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Lost/dropped messages when sendingIPv6/IPsec UDP datagrams
On Thu, May 28, 2009 at 11:51:42AM -0400, Sebastien Roy wrote:
> But the fix only calls the ip_ulp_cando_pkt2big() when doing IPsec
> processing in ip_wput_ire_v6(). The local generation of ICMPv6
> packet-too-big messages is not specific to IPsec, so I'm wondering why
> the fix (or the underlying problem for that matter) would be specific to
> IPsec.
Because the codepath I'm fixing only happens for packets that will be
IPsec-protected. Let's look at one particular diff with a bit more
context...
}
ip_wput_frag_v6(mp, ire, reachable, connp,
caller, max_frag);
return;
}
/* Do IPSEC processing first */
if (mctl_present) {
int extra_len = ipsec_out_extra_length(first_mp);
if (ntohs(ip6h->ip6_plen) + IPV6_HDR_LEN + extra_len >
- max_frag) {
+ max_frag && ip_ulp_cando_pkt2big(nexthdr)) {
/*
* IPsec headers will push the packet over the
* MTU limit. Issue an ICMPv6 Packet Too Big
* message for this packet if the upper-layer
* that issued this packet will be able to
* react to the icmp_pkt2big_v6() that we'll
* generate.
*/
icmp_pkt2big_v6(ire->ire_stq, first_mp,
max_frag, B_FALSE, B_TRUE, zoneid, ipst);
we will only every ENTER this path if:
* The packet length is not big enough to fragment by itself (see the
prior call to ip_wput_frag_v6().).
* The packet length AFTER IPsec processing *is* big enough to
fragment.
This was causing DROPPED PACKETS if they are of certain sizes (within
default-IPsec-overhead of MTU). The filer found it with UDP. I reproduced
it with ICMPv6 (ping) as well.
Does this clarify things?
Dan
___
networking-discuss mailing list
networking-discuss@opensolaris.org
[networking-discuss] SMALL CODE REVIEW - 6845208
On Tue, May 26, 2009 at 11:32:39PM -0400, Dan McDonald wrote: > > I have a webrev that you, Jiri, and the rest of the networking community > should see: > > http://cr.opensolaris.org/~danmcd/6845208/ > > The bug involves something I put in right after IPsec Tunnel Reform. > Unfortunately, I fixed it poorly, but nobody seemed to notice until you > started pushing out near-MTU UDP/IPv6 with ESP datagrams. The above webrev's changes have passed IKE-STC, while fixing the bug-filer's bug with my reproductions. (I'd like to get confirmation from him.) In the meantime -- can someone please check out the diffs at the above webrev? Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Lost/dropped messages when sendingIPv6/IPsec UDP datagrams
Wow! Almost 2 months. I'm VERY sorry about the latency here. On Tue, Apr 07, 2009 at 01:10:36PM +0200, Jiri Klimes wrote: > >Thank you for the data. We'll make sure we can reproduce it ourselves, > >put you on the bug report, and make sure the code-review is out on > >cr.opensolaris.org. If you have a fix that works, we'll also gladly review & > >help test it. > > > > Hope the data help you. Unfortunately I don't have any fix myself. I'm > still not sure where the problem actually lies and not much familiar with > OpenSolaris source. I have a webrev that you, Jiri, and the rest of the networking community should see: http://cr.opensolaris.org/~danmcd/6845208/ The bug involves something I put in right after IPsec Tunnel Reform. Unfortunately, I fixed it poorly, but nobody seemed to notice until you started pushing out near-MTU UDP/IPv6 with ESP datagrams. I've tested the edge-cases that you have pointed out. I'm now kicking off some IKE-STC runs that should exercise things enough to verify I haven't broken the orignal post-tref bugfix. Thanks for your patience, Jiri! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] comments needed: torching old networking project pages
On Fri, May 22, 2009 at 03:33:31PM -0400, James Carlson wrote: > All of which are easily available elsewhere. They were in the ARC > review. > > > Tunnel Reform project has a design document and links to code reviews, > > which can be helpful. > > The same. Heck, the project team (Dan McDonald) already said he was > cool with ditching the site, so the objection seems odd to me. The design doc(s) should be in the ARC folder. If it isn't, *that's* a bug. As for code-reviews, I have pointers to webrevs for code-reviews, and perhaps the tref-discuss archives are still there. I told Jim I was okay losing the page, because all of what's there can be reconstituted if people want to see it. It sounds to me, Garrett, like you've made the best possible argument for an "archives" directory in which all of these can land. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] nwam persistent static route
On Wed, May 20, 2009 at 02:39:00AM -0600, Jim Walker wrote: > Is there a way on OpenSolaris to make the default route > be persistent across reboots? I don't know how NWAM would interact with it, but if you use the "-p" option to route, things persist across boots. route -p add default Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] On building recvfromto() and sendfromto() with port-only UDP sockets
On Mon, May 18, 2009 at 10:00:34PM +0200, Darren Reed wrote: > The question I've got to ask is, why is the IKE daemon receiving packets for > so many different IP addresses? Because it has to. > Is it a required part of some protocol spec? Yep. > Or is it an application design thing? Yep. > Or...? Or it's either that or open a socket per address like in.iked(1M) is forced to do today. :-P When you throw IPv6 into the equation, it's a MUST (to use IETF-speak). Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] On building recvfromto() and sendfromto() with port-only UDP sockets
On Mon, May 18, 2009 at 08:45:49AM -0400, James Carlson wrote: > Kacheong Poon writes: > > James Carlson wrote: > > > Yep. You could call it IP_PKTINFO. ;-} > > > > Just wondering, are those apps requiring this kind > > of usage performance sensitive? I can't speak to every app, just mine. I think Jim nails it... > I'd be rather surprised if applications needing this sort of feature > are significantly affected by anything related to ancillary data > (compared both to the other work they typically do, and compared to > the overhead issues of having to deal with very large numbers of > peers), but the definitive test would be to create an experimental > new interface for this and then measure to see if there is any > noticable overall improvement. ... I'm talking about an IKE daemon, where most of its time (if it's spending time) is doing expensive Diffie-Hellman and/or RSA operations. Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] On building recvfromto() and sendfromto() with port-only UDP sockets
On Thu, May 14, 2009 at 03:38:54PM -0400, James Carlson wrote:
> > If so, I'm golden. :)
>
> I think so. Besides, I still can't quite figure out how setting
> source port on a per-packet basis would work or why you'd ever want to
> have it. I *think* it'd be similar to binding that port, but that
> means a scan through all the conn_ts on every packet, and when you're
> done, all you'd have is garbage -- you'd be using a port that's not
> actually bound, *or* you'd be absconding with someone else's port.
I was thinking about UDP 500 and UDP 4500, both of which are properly bound
ports belonging to in.ike{,v2}d. I am indeed golden.
Thanks again for your patience,
Dan
___
networking-discuss mailing list
networking-discuss@opensolaris.org
Re: [networking-discuss] On building recvfromto() and sendfromto() with port-only UDP sockets
> That's exactly what this feature was designed to *avoid*.
>
> You can have a single socket bound to address INADDR_ANY and port 500,
> and use that one socket to send replies to clients, and use the proper
> source address (and port 500) on each.
Thanks for your patience. I think I got it...
If I have UDP socket 's' bound to INADDR_ANY/500, can I do something like
(pardon my abstraction):
init_cmsg(&msg);
add_data(&msg, data, len);
add_name(&msg, peers_sockaddr_ptr); /* Assume len from sa_family */
add_ancillary(&msg, IP{,V6}_PKTINFO, my_specific_local_addr)
rc = sendmsg(s, &msg, 0);
and it'll send a UDP datagram that looks like:
IP (my_specific_local_addr -> peer_addr) + UDP (500, peer_port) + data
correct?
If so, I'm golden. :)
Thanks,
Dan
___
networking-discuss mailing list
networking-discuss@opensolaris.org
Re: [networking-discuss] On building recvfromto() and sendfromto() with port-only UDP sockets
On Thu, May 14, 2009 at 02:40:42PM -0400, James Carlson wrote: > Yep. You could call it IP_PKTINFO. ;-} But does that take into account the local port? Or do I have to protect my local bound-to-port-500 socket with a mutex to prevent multiple sending threads from stepping on each others' toes? Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] On building recvfromto() and sendfromto() with port-only UDP sockets
On Thu, May 14, 2009 at 02:34:29PM -0400, Sebastien Roy wrote: > On Thu, 2009-05-14 at 14:12 -0400, Dan McDonald wrote: > > - Insert something into the sendmsg() path that explicitly sets the > > local IP & port for a single datagram. > > > > This involves kernel modifications, which would be awful if > > anyone requested such a daemon to run on older kernels. > > This is the cleanest and most sensible approach, IMO. A new ancillary > data type that specifies the source address and/or port makes sense to > me. > > There has to be forward progress in the kernel as necessary. We can't > always say that we can't introduce new features because consumers of > those features might need them on versions of the OS that don't have > those features, that doesn't make sense to me. Those are good arguments. Some customers may disagree with you (especially those who listen to their high-priced consultants who think you should never/rarely upgrade), but that's not a topic for *this* list. :) > > - Use a raw socket and construct the whole IP and UDP headers. > > > > Can we do this for packet transmission? I know we can for > > ICMP headers ala. ping(1M), but can we for UDP as well? > > You can do that, but I don't think you should. This introduces > irrational implementation-specific privilege constraints on the > consumers of the API, and it also bypasses the UDP port space altogether > allowing applications to tromp on port numbers that may be in use by > real UDP applications. Keep in mind that an IKE daemon will require a lot of privileges anyway, PLUS it would only reflect back traffic bound for its already (properly) bound port(s). Also, the previously-mentioned kernel modification would either require privilege (to limit soure-address spoofing) or require in-kernel checks for local-address goodness. I'm thinking raw-sockets for the short term and bringup, and in the longer-term, perhaps building a more appropriate ancillary data type. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
[networking-discuss] On building recvfromto() and sendfromto() with port-only UDP sockets
Consider a threaded IKE daemon that has a socket open and bound to a local port 500. (We'll leave out 4500 because the same issues apply there modulo setting UDP_NAT_T_ENDPOINT...) Now let's consider that this threaded daemon must not just receive all packets for local port 500, but send them back with the same source/destination addresses as received. An existing open-source IKE implementation has provided these functions: extern int recvfromto(int s, void *buf, size_t buflen, int, struct sockaddr *from, int *fromlen, struct sockaddr *to, int *tolen); extern int sendfromto(int s, const void *buf, size_t buflen, struct sockaddr *from, struct sockaddr *to); (Please ignore the missing "flags" for now... ;) The implementation of recvfromto() is relatively straightforward using X/Open sockets and the IP_RECVDSTADDR or the IPV6_RECVPKTINFO for IPv4 and IPv6 respectively. The implementation of sendfromto() poses a tricky problem. There is no explicit set-local-source option in the IPv4 codepath, and IPv6 has hints about local-address selection (via IPV6_SRC_PREFERENCES), but nothing explicit. The open-source code chose to create a new socket, bind to the local port-and-address, and then perform a sendto(). The problem with this approach is documented in their comments: /* * Use newly opened socket for sending packets. * NOTE: this is unsafe, because if the peer is quick enough * the packet from the peer may be queued into sendsock. * Better approach is to prepare bind'ed udp sockets for * each of the interface addresses. */ Their "better approach" is employed by our IKEv1 daemon, but it has problems with file-descriptor limits (when many local addresses exist), and needing to monitor routing-socket behavior for local-address additions and deletions. What I would like to know is how one can build sendfromto() without having to resort one socket per local address. Some ideas that occur to me, all of which involve employing a secondary transmission socket, and all of which may be utterly bogus, include: - After a successful sendto(), call shutdown() on the dedicated sending socket, then read any lingering datagrams using recvfromto() and inject them into the packet-processing code. This assumes that I understand how shutdown() works, which may be completely wrong. I thought shutdown() detatched the socket from the network (in other words, nuked the conn_t) but kept any data queued up intact. - Insert something into the sendmsg() path that explicitly sets the local IP & port for a single datagram. This involves kernel modifications, which would be awful if anyone requested such a daemon to run on older kernels. - Use a raw socket and construct the whole IP and UDP headers. Can we do this for packet transmission? I know we can for ICMP headers ala. ping(1M), but can we for UDP as well? Any clues are appreciated. Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] A pass-0 review of Brussels Phase II (with IPsec Bias (TM)! ; )
On Tue, Apr 07, 2009 at 02:43:35PM -0400, Girish Moodalbail wrote:
> Thanks Dan, for your comments.
Again, pardon my latency.
>> - Where does this fit in with the Clearview IP Tunneling work?
>
> We will be able to create IP interfaces on the IP tunnel links created
> via "Clearview IP Tunneling work"
Good.
> Great. The plan is to get few consumers start using the library
> libipadm.so.1 (as identified in the design doc). Once we have sufficient
> features (in subsequent phases of ipadm) we will have more consumers
> using this library.
We can talk offline about a Brussels-happy punchind.
>> - I see that there is absolutely no *_algs support ala. ifconfig(1M).
>>I do not mind EOL-ing these, but I do need to see an agenda for
>>how. This may be more dladm-level than ipadm, but it is something
>>we need to take into account.
>
> The eventual goal is to achieve the new mantra => 'ipadm' will be the
> new 'ifconfig'.
Got it.
> For now (first phase) 'ifconfig' will not be made obsolete. The *_alg
> support will be present in ifconfig(1M) as it is today. We will not carry
> forward the *_algs support in 'ipadm' as 'ipsecconf' is the right place
> for people to configure it.
Okay, so *_algs goes away no later than when ifconfig(1M) does. Good.
BTW, for folks in the audience with existing *_algs ifconfig deployments. If
you have:
ifconfig ip.tun0 . encr_algs encr_auth_algs
You merely need to make that an entry in /etc/inet/ipsecinit.conf
(i.e. ipsecconf(1M) input):
# Use IP-in-IP with transport-mode IKE negotiation
{ tunnel ip.tun0 negotiate transport } ipsec \
{ encr_algs encr_auth_algs }
You can always see that style on any tunnel today with:
ipsecconf -ln -i
>> - I assume the "-t" equivalent will be in the library as well, right?
>
> Yes
Cool.
Dan
___
networking-discuss mailing list
networking-discuss@opensolaris.org
[networking-discuss] A pass-0 review of Brussels Phase II (with IPsec Bias (TM)! ; )
Hello! First off, I apologize for not getting this to you sooner. Thanks for the reminder. Second off, I will need to spend more time with the spec, but I did want to put some immediate reactions and questions up. So here's what I saw upon a quick browse through the document: - Where does this fit in with the Clearview IP Tunneling work? - There are other consumers of this API. IKEv2 (or IKEv1 IKE-CFG support) would use these as well to create tunnel interfaces. The good news is that I don't see anything so far that would be a hinderance, and in fact, stability here would help a LOT. (We can test these APIs with punchind, BTW.) - I see that there is absolutely no *_algs support ala. ifconfig(1M). I do not mind EOL-ing these, but I do need to see an agenda for how. This may be more dladm-level than ipadm, but it is something we need to take into account. - I assume the "-t" equivalent will be in the library as well, right? - I have mixed feelings about EOL-ing XRESOLV. Nobody uses it, but for IP-over- XRESOLV can provide a better way for to implement ARP or ARP-like functionality. (XRESOLV + PF_ROUTE was the inspiration for PF_KEY.) I'll give a more careful read and see if anything else comes up. Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] QUICK Makefile review: 64-bit IKE (and 64-bit usr/lib/inet)
On Tue, Apr 07, 2009 at 10:40:13AM -0400, James Carlson wrote: > Dan McDonald writes: > > It's not clean to isolate sparcv7 as not-needed. > > I think you should be able to do this with something like: > > SUBDIRS= > $(INTEL_BLD)SUBDIRS += $(MACH) > $(BUILD64)SUBDIRS += $(MACH64) > > There might be other ways to do it. Oooh, I like that, and feel bad I didn't figure that out myself. Where did you find this? > > Also, take a look at the internal closed-source webrev to see how I follow > > others' Makefiles logic: > > > > http://zhadum.east/~danmcd/ike64.closed/ > > I'm still not wild about wasting time to build an object that can't > possibly be used, and that will never be tested. Can't argue with you there... I've uploaded new webrevs (both internal and external) that *should* take care of things (e.g. the elimination of $CLOSED/cmd/cmd-inet/usr.lib/in.iked/sparc/), but I need to do some nightlies to verify. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] QUICK Makefile review: 64-bit IKE (and 64-bit usr/lib/inet)
On Tue, Apr 07, 2009 at 09:57:30AM -0400, James Carlson wrote: > > sparcv7 has been removed from the pkgdefs and put in the > > exception_list_sparc > > file. > > You shouldn't have to do that. I don't see why a sparcv7 version is > being built at all. I looked at how 64&32 bit binaries get built normally by commands that need both. Makefiles have entries like this: SUBDIRS=$(MACH) $(BUILD64)SUBDIRS += $(MACH64) and this: clean clobber: $(SUBDIRS) It's not clean to isolate sparcv7 as not-needed. Examples include dtrace(1M) (which needs 32-bit sparc) and sort(1) (which doesn't). It seems that sort(1) does Makefile things in its sparc/ directory to prevent a sparcv7 /usr/bin/sort, but it still installs a 32-bit one in /usr/xpg4/bin/. Also, take a look at the internal closed-source webrev to see how I follow others' Makefiles logic: http://zhadum.east/~danmcd/ike64.closed/ > > I chose to keep it all 64-bit aligned AND 64-bit multiples save basic > > identity-style enums, which only appear as parts of larger structures. > > You might be depending on compiler artifacts to do that, but I'll > give. Thanks. (I think what I'm doing guards against variable-behaving compiler artifacts.) Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] QUICK Makefile review: 64-bit IKE (and 64-bit usr/lib/inet)
On Fri, Apr 03, 2009 at 10:32:48AM -0400, James Carlson wrote: > In usr/src/pkgdefs/SUNWcsu/prototype_sparc: why is there a sparcv7 > version of this code? We don't have any supported v7 platforms, and > don't build that way. sparcv7 has been removed from the pkgdefs and put in the exception_list_sparc file. > Nit on SUNWcsl/prototype_sparc (and possibly others): use alphabetic > order when possible; libipp doesn't come before libike. Fixed reordering in all prototype_* files. > usr/src/lib/libipsecutil/common/ikedoor.h > > It's unclear whether all of the padding here is needed for anything > but perhaps time_t; do these things actually resolve differently in > LP64? I did several compiler runs, and in 64-bit binaries, some padding was *implicitly* introduced between a uint32_t and a large array, and sometimes between two structures. I chose to keep it all 64-bit aligned AND 64-bit multiples save basic identity-style enums, which only appear as parts of larger structures. > usr/src/cmd/cmd-inet/usr.lib/Makefile.lib > > 39-40,45-46,51-52: I'd rather see these things in Targetdirs than > hidden in makefile rules. This could be simplified. Fixed! These changes are all on the webrev now: http://cr.opensolaris.org/~danmcd/ike64/ Thanks Jim for your diligence. If anyone else has some comments, please speak up soon. I will then re-run IKE-STC and then do some punchin-server deployment. Thanks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Lost/dropped messages when sending IPv6/IPsec UDP datagrams
> IMHO, it has something to do with fragmentation: > a) message is short - no need to fragment - everything is OK > > b) message is of middle length (it < 1500 without, but > 1500 after > including IPsec headers) - ICMPv6 Packet Too Big is generated to self - but > I don't see the ICMP in wireshark nor in a raw socket (icmpd from Stevens > UNP book); I see the ICMP in a dtrace script as dropped incoming IPsec > packet. > The original datagram is not sent out and seen anywhere. > > c) message is large (> 1500 bytes) - message is fragmented via > ipsec_out_process() - everything is OK > > My concern is case b). > I would consider it a bug as the message being sent is silently dropped. > What is the reason for fragmentation longer (> 1500) packets automatically, > but dropping shorter? This is IPv6 only? Can you use ping's sizes, e.g.: ping -svn ipv6-destination <#-of-packets> ? > Well, OpenSolaris behaves almost the same as the Solaris Update 5; i.e. the > packets of about 1414 bytes of data are dropped and ICMPv6 Packet Too Big > is generated to self. Gotcha. > However there is a diference in function call trace of sento() - produced by > DTrace: > On Solaris 10 Update 5 there are different call stacks that leads me to > description above. > OpenSolaris' call stacks are the same for the good and failing case, which is > strange for me. Hmmm, it looks like > mctl_present is false at > http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/inet/ip/ip6.c > ~ line 11129 and that's why > ipsec_out_process() is not called and the flow goes to ip_xmit_v(). > > In the attachment you can find 3 files: > sol10_ok.txt- sendto() dtraced when sending short packet on Solaris > Update 5 > sol10_bad.txt - sendto() dtraced when sending packet, which is lost on > Solaris Update 5 > osol.txt- sendto() dtraced when sending packet (for both good and bad > case) on OpenSolaris > > > How to reproduce: > 1. Set an IPsec SA > 2. Set an IPsec policy > 3. Send a UDP packet of 1414 bytes of payload Thank you for the data. We'll make sure we can reproduce it ourselves, put you on the bug report, and make sure the code-review is out on cr.opensolaris.org. If you have a fix that works, we'll also gladly review & help test it. Thanks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] help neede to set up ipsec with AH and ESP combined
On Sun, Apr 05, 2009 at 11:05:12AM -0700, Jean Paul Degabriele wrote:
> Hi I am trying to setup an IPsec VPN with AH in transport mode followed by
> ESP in tunnel mode. i.e the encapsulation is as follows: IP-ESP-IP-AH-ULP
You cannot do that on forwarded packets.
> In general all packets are being protected by ESP in tunnel mode, however
> AH is only being applied to packet originating from the local interface of
> one gateway to the local interface of the other gateway. Meaning that AH is
> not being applied to packets originating from machines on the local
> network.
That means things are working as designed.
> # AH transport mode
> {raddr 192.168.103.0/24} ipsec {auth_algs hmac-md5 sa shared}
That policy entry only applies to packets originating from or destined to the
node in question.
> # ESP Tunnel mode
> {tunnel ip.tun0 negotiate tunnel raddr 192.168.103.0/24 laddr
> 192.168.102.0/24} ipsec {encr_algs aes sa shared}
This one applies to any packet forwarded through ip.tun0.
The only way you can get AH + ESP on forwarded packets is to have:
IP + AH + ESP + [IP + data]
and you'd then need to lose the transport-mode entry, and add "auth_algs" to
the tunnel-mode entry.
Dan
___
networking-discuss mailing list
networking-discuss@opensolaris.org
Re: [networking-discuss] QUICK Makefile review: 64-bit IKE (and 64-bit usr/lib/inet)
On Fri, Apr 03, 2009 at 10:32:48AM -0400, James Carlson wrote: > Dan McDonald writes: > > To that end, I've modified usr/src/cmd/cmd-inet/usr.lib/Makefile.lib, which > > is what I would like people to check at: > > > > http://cr.opensolaris.org/~danmcd/ike64/ > > The high-level question is probably just "why?" Is there some benefit > in running as 64 bit for this application? Two benefits: Solves Y2038 (imagine the 30-year 4kbit certificate) and allows 64-bit versions of bignum routines to be used. > In usr/src/pkgdefs/SUNWcsu/prototype_sparc: why is there a sparcv7 > version of this code? We don't have any supported v7 platforms, and > don't build that way. I see other apps built this way, but perhaps those access 32-bit sparc binaries in some way (e.g. dtrace, mdb). What's the recommendation in this case? Use isaexec but only install sparcv9? > Nit on SUNWcsl/prototype_sparc (and possibly others): use alphabetic > order when possible; libipp doesn't come before libike. Someone besides me messed this up, so there's more sorting than just that local area. > usr/src/lib/libipsecutil/common/ikedoor.h > > It's unclear whether all of the padding here is needed for anything > but perhaps time_t; do these things actually resolve differently in > LP64? Yes, yes they do! If ikeadm (32-bit) is talking to in.iked (64-bit) the mismatches in alignment and padding become criticial. > 439: this padding doesn't make sense. The element following in the >structure is an array of 'char', which needs only byte >alignment, not 64-bit. Compile with -m64 and you get a differenet sizeof (that-structure). Weird, I know, but true. > 738: ditto. See above. > usr/src/cmd/cmd-inet/usr.lib/Makefile.lib > > 39-40,45-46,51-52: I'd rather see these things in Targetdirs than > hidden in makefile rules. This could be simplified. Right now, I'm following the established pattern in Makefile.lib. I'm not sure how to properly set up Targetdirs, but am glad to receive clues on how. Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
[networking-discuss] QUICK Makefile review: 64-bit IKE (and 64-bit usr/lib/inet)
I'm here for the makefile reality checking. Our IKE is closed-source (sorry 'bout that folks), but as I'm looking at IKEv2 options, it occurs to me that they should build and run in 64-bit mode. Since no /usr/lib/inet/ daemons run 64-bit today, I figured I'd make our current in.iked run 64-bit to test the infrastructure. To that end, I've modified usr/src/cmd/cmd-inet/usr.lib/Makefile.lib, which is what I would like people to check at: http://cr.opensolaris.org/~danmcd/ike64/ There are other bits-and-pieces there as well, but it's the Makefile.lib that really needs the review cycles. I have the closed-source stuff internal viewing URL (again, sorry to non-Sun community folks) available upon request. Thanks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Solaris Bridging design review [18-25 March 2009]
On Thu, Mar 26, 2009 at 05:50:48PM -0400, Sebastien Roy wrote: > I think the scenario that's been floated around is one where a > non-global zone has Internet connectivity, but the global zone does not. > In this scenario, a VPN link is created from the non-global zone between > its public IP address and the VPN concentrator, and the inner IP > interface for this VPN would be managed from the global zone. In this > scenario, the global zone has no Internet connectivity at all, but has > connectivity to the private network. Yes. That's the optimal state, because presumably the outside attackers would be more hostile than the inside ones. (That may not necessarily be the case, though, given recent reports about the rise of inside attackers.) > # dladm show-iptun > LINKTYPE SOURCE DESTINATION > internet/vpn0 ipv4 my-public-ipvpn-public-ip > # dladm set-linkprop -p zone=global internet/vpn0 > # dladm show-iptun > LINKTYPE SOURCE DESTINATION > vpn0ipv4 my-public-ipvpn-public-ip > # ifconfig vpn0 plumb my-private-ip vpn-private-ip up > > We're not there yet. I didn't think we'd be that far yet. Is global-attached-to-Internet (global zone is attached to the RED network) possible, or at the very least easier? Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Request for feedback: Link Layer Discovery Design
On Tue, Mar 10, 2009 at 03:29:57PM -0500, Jason King wrote: > I haven't heard any disagreement on that, just should there be a > method (outside of svccfg or libsmf calls) to manipulate them? If so, > what form should it take. Currently, there's an additional dladm > subcommand proposed for that, but is that optimal or needed? Sorry for not catching the crux of your question earlier. Again IMHO, I don't think you need addtional commands or dladm stuff for such global defaults. IMHO you should keep the globals exclusively in SMF, especially given they don't seem to me to be GLOBALLY tweaked often. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Request for feedback: Link Layer Discovery Design
On Tue, Mar 10, 2009 at 03:09:43PM -0500, Jason King wrote: > Unfortunately, it still leaves the question of what to do about global > LLDP properties. Unless I misread the rbridge documentation you > pasted, it doesn't look like the rbridge model will map completely > (per link: yes, global: no) since there's only one daemon. According to your design page (reposted for context): http://www.opensolaris.org/os/project/lld/design/ You have timer-type parameters in the lldp-global/ space. I'm guessing that since you can instantiate link-specific versions of these as mentioned in the lldp-link section of your above design page, you want a place where systemwide default values live. > Just thinking out loud, while the standard strongly implies that they > should be able to be manipulated, they are likely to be infrequently > touched (and generally uninteresting), would it be bad from an admin > point of view to just leave them in SMF with no corresponding method > to manipulate them in dladm? IMHO SMF is an *optimal* place to put such systemwide defaults. Just make sure you document them in the lldd(1M) man page appropriately, and mention the the order of preference is: 1.) link-specific (per Jim's rbridges-inspired suggestion with dladm). 2.) SMF That's my $0.02 anyway... Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] NAT and IPsec, who is first in Solaris?
On Tue, Feb 17, 2009 at 06:33:05AM -0800, Hao Wu wrote: > Thanks! Actually I only used the transport mode of IPsec here to protect > the traffic between two hosts. I have 3 hosts, say A, B and C, and A > cannot reach C. So I configure NAT on B, and define rdr rule to redirect > all the traffic destining to some port on B to C. Besides, I hope the > communication between A and B to be secured, so I choose IPsec transport > mode. Now once I configure IPsec, rdr rules will not take effect. Do we > have any other options to implement such scenario (or other methods to > encrypt the traffic between two hosts) ? Because we probably have > hundreds of hosts like C belonging to different network , we don't want > to run hundreds of SSH processes to do remote port forwarding, or > created hundreds of IPsec tunnels (VPN) between A and B for accessing > different networks via B. Any help will be appreciate! You could create one tunnel and use routing to access all of the different networks over B, no? A picture might be nice here, actually. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Finishing up the contributors list as well
On Tue, Feb 17, 2009 at 09:02:28AM -0800, Thirumalai Srinivasan wrote: > Sunay Tripathi wrote: >> danmcd,Dan McDonald,20,networking,Networking,2009-02-24 00:32:45 >> carolg,Carol Gayo,20,networking,Networking,2009-02-24 00:32:45 >> anders,Anders Persson,20,networking,Networking,2009-09-05 15:21:03 >> >> I vote to approve the above as is. >> > +1 Sunay, Seb, and Thiru == 3. I accept. Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] NAT and IPsec, who is first in Solaris?
On Mon, Feb 16, 2009 at 06:40:31PM -0800, Hao Wu wrote: > Does it means we could implement policy NAT including TCP/UDP port using > IPsec NAT-traversal? I don't think so. The PFHOOKS that ipfilter uses still occur after IPsec happens. Sorry, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] NAT and IPsec, who is first in Solaris?
On Mon, Feb 16, 2009 at 05:12:34PM -0800, Hao Wu wrote: > If we configure NAT and IPsec on the same system. an incoming packets > undergoes IPsec or NAT first in Solaris? If NAT first, some policy NAT > rules incluing TCP/UDP port will not be applied. NAT is first on inbound, and last on outbound. You are correct about the rules, BTW. But IPsec NAT-traversal does work (even in transport mode). Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Different IPsec bug --> 6799166
On Mon, Feb 02, 2009 at 04:03:37PM -0500, James Carlson wrote: > > It does seem weak, no? Fixed. The IPPROTO_ROUTING case is extra annoying, > > but also contorts appropriately now. > > The same comment is still at line 8840 ... I don't think it applies Yanked. > anymore. In fact, given the code at lines 8855-8867, it's unclear if > this code does anything. It advances along the mblk chain. Consider a (common) case like: mp1 (IPv4, IPv6) + mp2 (Hop-by-hop, ICMP6) I start in mp1, and then have to advance to mp2. mp2 will be nice and aligned, and we have no need for the annoyance of lines 8855-67. 8855-67 guard against real crud like: mp1 (IPv4, IPV6, one-byte-of-hop-by-hop) + mp2(rest-of-HBH, ICMP6) > For lines 8856 and 8862, does this code compile? If it does, then > that's surprising. -= and += shouldn't work when both terms are > pointers. I was waiting for an additional review answer before I spun up a local compile. I now have fixed those two lines with uintptr_t casts, added my additional review answer (another reviewer suggested static DTrace probes in bad-packet cases), and updated the webrev. Thanks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Different IPsec bug --> 6799166
On Fri, Jan 30, 2009 at 04:30:34PM -0500, James Carlson wrote: > ip6.c: > > 8825: this looks a little too clever; I think the right code would > be simply: > > if ((uint8_t *)ip6h < current_mp->b_wptr && > (uint8_t *)ip6h >= current_mp->b_rptr) > > (We care that the pointer lands in the "current" mblk, not the size > of the pointed-to object.) > > (It'd be simpler just to require the caller to pass you the right > mblk. He must know it; otherwise, he couldn't have given you ip6h. > Doing that would get rid of this loop and the next issue entirely.) I had to reinspect the callers. Sometimes (noteably when inbound ICMP error messages need policy inspections) the passed-in IP headers to IPsec policy functions sometimes aren't at the beginning mblk in a chain. In this case, however, they all are outbound and within the first block of the chain. > 8835: should be an ASSERT. If someone gives you an ip6h pointer > along with an mblk from some different packet, then you're doomed. ICMP errors may have this problem, but that's on the inbound side. I've removed the code in question. > 8852: seems a little weak; how can you assume this? It does seem weak, no? Fixed. The IPPROTO_ROUTING case is extra annoying, but also contorts appropriately now. > 8859: looks more like "goto done" to me. Agreed. The webrev: http://cr.opensolaris.org/~danmcd/6799166-postreview/ will have your changes (and one others') included. Thank you! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Code review -- 6777776
On Fri, Jan 30, 2009 at 03:24:41PM -0500, Dan McDonald wrote: > Fixed in: > > http://cr.opensolaris.org/~danmcd/676-postreview/ I've actually mainlined 676's changes into the original webrev url: http://cr.opensolaris.org/~danmcd/676/ I'm building nightlies and will be running IKE-STC on DEBUG bits shortly after those builds complete. Assuming IKE-STC goes well, I will RTI. Thanks folks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Code review -- 6777776
On Fri, Jan 30, 2009 at 02:36:53PM -0500, Peter Memishian wrote: > > Like this? > > > >ASSERT(DB_TYPE(ipsec_mp) == M_CTL); > >ASSERT(io->ipsec_out_type == IPSEC_OUT); > >ASSERT(ipsec_mp->b_cont != NULL); > >ASSERT(DB_TYPE(ipsec_mp->b_cont) == M_DATA); > > Right. Fixed in: http://cr.opensolaris.org/~danmcd/676-postreview/ How does that look now, folks? Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
[networking-discuss] Different IPsec bug --> 6799166
Another discovered-by-prolonged-use bug involves IPv6 and IPsec. Specifically, the ip_get_dst_v6() function makes the (faulty) assumption about packets being single-mblk. Here's a fix: http://cr.opensolaris.org/~danmcd/6799166/ which has survived two IKE-STC runs w/o leaks or panics. It needs some additional testing (specifically for the use case which FOUND the bug initially). It also has one XXX KEBE comment/question that needs answering, about how to log or otherwise note a bad input packet. I'd appreciate any inputs on answering this question. Thanks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Code review -- 6777776
On Fri, Jan 30, 2009 at 02:22:49PM -0500, Peter Memishian wrote: > Using the DB_TYPE() macro would make this a bit less error-prone. Like this? ASSERT(DB_TYPE(ipsec_mp) == M_CTL); ASSERT(io->ipsec_out_type == IPSEC_OUT); ASSERT(ipsec_mp->b_cont != NULL); ASSERT(DB_TYPE(ipsec_mp->b_cont) == M_DATA); Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] Code review -- 6777776
On Fri, Jan 30, 2009 at 10:20:51AM -0800, Erik Nordmark wrote: >> Here's the webrev: >> >> http://cr.opensolaris.org/~danmcd/676/ > > ipsecesp.c would hit an assertion failure if you were to run this, because > db_type can't be both a M_CTL and an M_DATA. > > 2307 ASSERT(ipsec_mp->b_datap->db_type == M_CTL); > 2308 ASSERT(io->ipsec_out_type == IPSEC_OUT); > 2309 ASSERT(ipsec_mp->b_cont != NULL); > 2310 ASSERT(ipsec_mp->b_datap->db_type == M_DATA); Doh! Forgot the ->b_cont... ASSERT(ipsec_mp->b_datap->db_type == M_CTL); ASSERT(io->ipsec_out_type == IPSEC_OUT); ASSERT(ipsec_mp->b_cont != NULL); ASSERT(ipsec_mp->b_cont->b_datap->db_type == M_DATA); That's what I meant to say. My tester used non-DEBUG bits, and I was waiting for more review prior to an IKE-STC run. (I've two other bugfix wads, and this was not first.) > For the inbound_task using ipsec_in_stackid I'm having a hard time > convincing myself that ipsec_in_stackid is always set. Does it need to be > set before we kick off inbound_task? lpkt always has its stackid set. See sadb_set_lpkt() in sadb.c (part of this bugfix) for where it is done. > Or would it be better to only set ipsec_in_stackid in the 3 or so places > where we set ipsec_in_ns? (i.e., remove the two places we currently set it > in favor of those three.) Now THAT might be a better idea. We'd need to add spd.c to the changeset, and put it in the two places (ipsec_in_alloc() and ipsec_out_to_in()) ipsec_in_ns is set today. I've posted a rewhacked webrev to take into account your suggestions: http://cr.opensolaris.org/~danmcd/676-postreview/ Is that what you had in mind? If so, I'll go off to the IKE-STC races. Thanks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
[networking-discuss] Code review -- 6777776
I think my last request on this got lost, so let me try again. I've got two kernel bugfixes: 676 NAT-T keepalive transmission shouldn't directly call ipsec_wput_ipsec_out() 6779183 AH and ESP taskq handlers have to remember the netstack ID. that need review. Last time I put these out, people reminded me of netstack hold/release issues. I think I nailed those. Also (more importantly) I've followed suit with the asynchronous EF calls and preserved the instance number, knowing that I need to guard against a zone's destruction during the setup and asynchronous return. Here's the webrev: http://cr.opensolaris.org/~danmcd/676/ it's a hard one to reproduce, but one user had been able to get his box to panic pretty regularly on 676, but now doesn't with my replacement bits. Thanks for your review cycles, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] New project proposal: IP Datapath Refactoring
Pardon the top-post, but I think the Security community will be interested
in this project too because complexity is the enemy of security, and this
project reduces complexity.
And as a core contributor in Security, I ACK/+1 this project for endorsing
this project. (The project team can deem this endorsement inappropriate if
they wish.)
Dan
On Wed, Jan 28, 2009 at 03:07:57PM -0800, Erik Nordmark wrote:
> We would like to start the IP datapath refactoring project.
> We are requesting endorsement from the the networking community.
>
> Thanks,
> Erik
>
>
> -- OPENSOLARIS PROJECT PROPOSAL --
>
>
> Project Name:
> IP Datapath Refactoring
>
> Project Synopsis:
> Simplify the IP Datapaths to make them more understandable and evolvable
>
>
> Project Purpose:
>
> The IP datapaths are extemely hard to follow both at the micro level
> (ip_output_options and ip_wput_ire, and ip_input) and at the macro level
> (an outbound packet needing IPsec and ARP resolution goes through an odd
> number of steps).
>
> That makes it hard to even fix bugs in that code, let alone getting it
> to perform. This has resulted improving performance by creating numerous
> fast paths, which are subsets of the full datapaths. This further makes
> maintenance of the code a hazardous activity.
> The root cause of the complexity is that ip_newroute introduces
> asynchrony in the wrong part of the code. Tradionally ARP is done at the
> very bottom of the IP output side, but to avoid a separate ARP table
> lookup Solaris has an IRE_CACHE entry which is created to include the
> ARP information. This is done early in ip_output because the IRE_CACHE
> is also used to pick an IP source address in some cases (unconnected UDP
> and RAWIP sockets) and we need the IP source address early (before doing
> IPsec etc).
>
> We need to move the ARP-related asynchrony to the bottom of IP output to
> get the output datapaths be more sane, and it also makes sense to
> disassociate source address selection from routing/IRE lookup. (In 1991
> the source address selection was simpler than today to the association
> made some sense. But with IPMP, IPv6, shared-IP zones etc the source
> address selection can't simply be associated with the route.)
>
> A side effect of ip_newroute is that we need to carry various
> information from the transport protocols to the point after ip_newroute
> is done. We've created various ways to put this information in the
> messages so that they can be queued with the packets waiting for ARP
> resolution; the ip6i_t is there for this purpose as well as the
> ipsec_{in,out}_t which is currently used for more than just IPsec. There
> are also ad-hoc places we scribble information (b_prev, etc).
>
> Note that the ip6i_t and M_CTL are also used to carry information
> between the transport protocols (for both the input and output path).
> But after Fireengine in S10 introduced direct function calls between the
> transports and IP we are no longer limited to passing a message using
> putnext. Hence we can relatively easily add function call arguments up
> and down between the transports and IP and have those function call
> arguments carry the meta-data associated with the packet (an example of
> meta-data is that on the receive side the transports need the incoming
> interface - the ill_t - to handle IP_RECVPKTINFO and IPv6 link-local
> addresses correctly.)
>
> Having looked at the dependencies that unravel when ip_newroute is
> removed it turns out that the whole concept of IRE_CACHE isn't needed
> any more. We can do more efficient caching (and S10 already does for
> TCP) by caching the IRE and NCE (neighb or cache entry containing ARP
> information) in the conn_t.
>
> This results in the removal of
> ip_newroute*
> IRE_CACHE
> ip6i_t
> M_CTL usage, including ipsec_out_t and ipsec_in_t
> Various b_prev usage in the ip_input side
> and the addition of
> ip_xmit_attr_t - the transmit attributes passed to ip_output
> ip_recv_attr_t - receive attributes passed up to the ULP (and used
> internally
> in IP)
> A new way to track dependencies when IREs are added and removed
> Using nce_t for ARP information (we do this partially today; mostly for
> the
> IPv4 forwarding paths)
>
> Current prototyping indicates that about 30,000 lines of code can be
> removed as a result of these changes (combined with the ARP/IP merge
> pieces).
>
> The discussion will take place on the existing
> networking-discuss@opensolaris.org list.
>
>
> Proposed Community Sponsors:
> Networking
>
>
> Participants:
> Project lead:
> Erik Nordmark
>
> Other Participants:
> Sowmini Varadhan
> Yunsong (Roamer) Lu
> Nitin Hande
>
>Other interested participants: please speak up. We have some
>prototype code, and contributions of review time, bug fixes, or
>testing are very we
[networking-discuss] Bug fix review #1 (the hard one): 6777776 & 6779183
Hello! This is the first of two distinct sets of bugfixes. I had asked for review previously on: 676 NAT-T keepalive transmission shouldn't directly call ipsec_wput_ipsec_out() 6779183 AH and ESP taskq handlers have to remember the netstack ID. and was reminded about netstack reference holds and releases. I think I have recitfied that situation, and I have kept hold of netstack IDs as new things go asynchronous, to match other current asynchronous behavior in IPsec. The webrev is here: http://cr.opensolaris.org/~danmcd/676/ I'd like someone outside of Team IPsec to review and approve this before I putback, just as added protection. Thanks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] [brussels-dev] ipadm wish-list
On Mon, Jan 26, 2009 at 09:50:24AM -0500, Sebastien Roy wrote: > > If we think we can finish this (libipadm with persistence and being used > > by ifconfig) by the next minor release then we can at least consider > > making persistent the only way - even when ifconfig is used as the CLI. > > While it could be considered, I think it would be too risky a change > even for a Minor release, and maybe even for a Major release. I don't > think it would be acceptable to require 3rd party software to be > modified to undo unwanted persistent configuration. Thank you Seb. > On a related note, if ipadm is the preferred way to configure a system, > what is the programmatic model for IP configuration from shell scripts > in this new world order? Surely, knowing that there exists software > that dynamically configures IP interfaces on the fly with no need (nor > want) for persistent configuration (think VPN server), then a > persistent-only ipadm by itself won't be very friendly. Even SMF, the very model of persistence, has its "-t" option for temporary/transient settings. > If we want such software to migrate to ipadm and not use ifconfig for > perpetuity, then what is the story for such software? One obvious > answer is that ipadm needs to support temporary configuration. There > may be other answers. ipadm the command may be persistent, but libipadm MUST not be exclusively persistent, or apps that configure transient network configurations will find ways around libipadm. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] IP Instances disappearing behind IPsec's back, plus review of 6777776
There's a new rewhack of 676 at: http://cr.opensolaris.org/~danmcd/676/ Biggest changes are responding to this: On Tue, Dec 02, 2008 at 09:32:34PM -0800, Erik Nordmark wrote: > > I'm not very happy about this type of code: > 1049 ((ipsec_in_t *)lpkt->b_rptr)->ipsec_in_stackid = > 1050 ahstack->ipsecah_netstack->netstack_stackid; > > It should be cheap to always set the stackid when the larval pkt is added. which I've now done, as well as eliminating changes to sadb.h for a smaller set of changed files. Given that some EF providers call KM_SLEEP and may hang up unloading of IP instances for a long-ish period of time, I kept the mark-and-get semantics introduced with IP Instances in the *_kcf_callback() functions. Nightlies are running now, and if they are like the last batch, they'll be clean. Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] IP Instances disappearing behind IPsec's back, plus review of 6777776
On Wed, Dec 03, 2008 at 08:03:27AM -0500, James Carlson wrote: > > The reason for that is that it is hard to avoid refcnt leaks, and the > > question whether the kcf callback can take a long time - so long it > > would hold up cleaning up the netstack_t. But perhaps that isn't an > > issue. If you know that all kcf calls always results in a callback then > > you can hold a ref. > > I'd much prefer to see a ref hold here rather than looking up the ID > again; there's no question that it'll work right across stack > tear-down/restart. > > If things can "disappear" inside kcf, then that may be a different > problem ... Adding crypto-discuss to the thread... ... I believe KCF losing a submitted mblk chain IS a possibility, which is why there's an index-and-check scheme. Also, IIRC, at least one well-understood HW provider's timeout can be measured in seconds. That same HW provider is known to call kmem_alloc() with KM_SLEEP set also. :( Crypto-heads --> Can you confirm/deny what I just said about KCF? Or what I said about that well-understood HW provider? Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] IP Instances disappearing behind IPsec's back, plus review of 6777776
Okay! I've spun nightlies now and will be running IKE-STC on 'em soon, but here is an improved webrev with a new bug: http://cr.opensolaris.org/~danmcd/676/ and the new bug is: 6779183 AH and ESP taskq handlers have to remember the netstack ID. For now, I stuck with the existing *_kcf_callback() strategy of tagging the packet with the netstack ID, followed by a followup check and refhold. I didn't perform a refhold prior to the asynchrony because I figured the original IP Instance putback didn't do a refhold across the asynchrony of crypto for a reason. I know there's serious rewhacking of the IP datapath occurring, so it's possible some of these sources of double-locking that 676 exposes will disappear, but I'd like folks to take a look at the here-and-now fix. Thanks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] IP Instances disappearing behind IPsec's back, plus review of 6777776
On Mon, Dec 01, 2008 at 05:11:21PM -0800, Erik Nordmark wrote:
> Of course, if you take Jim's suggesting to hold a ref for each
> taskq_dispatch, then you will never get to ipsecesp_ddi_destroy() with
> references around.
Perhaps, then, we do the same thing with esp_kcf_callback()? Currently,
there's an ipsec_{in,out}_stackid field that perhaps does not need to be
there if, and only if, we netstack_hold() before calling EF asynchronously.
So the fix becomes far more interesting than simply fixing the lock-held
problem. This is cool!
Thanks Jim and Erik!
Dan
___
networking-discuss mailing list
networking-discuss@opensolaris.org
[networking-discuss] IP Instances disappearing behind IPsec's back, plus review of 6777776
Hello folks! As background, please consult the following webrev: http://cr.opensolaris.org/~danmcd/676/ You'll notice that for the actual bugfix, my taskq callback function checks and verifies that the IP instance of the packet still exists. The taskq is instantiated once for ESP, so I figured checking for IP Instances disappearing (as we do with esp_kcf_callback() and its callers) is a good idea. Since I used the taskq, however, I looked at the other taskq callers, and the only other callbacks are ipsecesp.c:inbound_task() (and its ipsecah counterpart) and sadb_clear_buf_pkt(). Both of those are called after key management (e.g. IKE) finish SADB_UPDATE or SADB_ADD entries respectively. Is it theoretically possible for an instance to get nuked between taskq submission and taskq callback execution? If so there's an additional bug lurking where we must have the aforementioned taskq callbacks (and their setup routines) record the netstack ID, ala. esp_kcf_callback() and the new code introduced by my fix for 676. Please pipe up on both the review and my question! Thanks, Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] setting ipsec tunnel mode programmatically
On Tue, Nov 25, 2008 at 04:10:08AM -0800, Rafi Kiel wrote:
> Hi
Hello!
> How can I configure tunnel mode SA/SP (with manual keying)
> programmatically?
Our ipsecconf(1M) doesn't enable tunnel-mode where the inner and outer
addresses match. We do have a self-encapsulation enabler in the IP_SEC_OPT
socket option.
> The transport mode SA/SP creation is demonstrated in the ipsecconf &
> ipseckey utils source code available on the opensolaris but it does not
> help (at least I understand it that way) how to work in tunnel mode.
typedef struct ipsec_req {
uint_t ipsr_ah_req;/* AH request */
uint_t ipsr_esp_req; /* ESP request */
uint_t ipsr_self_encap_req;/* Self-Encap request */
uint8_t ipsr_auth_alg; /* Auth algs for AH */
uint8_t ipsr_esp_alg; /* Encr algs for ESP */
uint8_t ipsr_esp_auth_alg; /* Auth algs for ESP */
} ipsec_req_t;
You need to set ipsr_self_encap_req.
> I need it for UDP encapsulation of ESP tunnels (NAT traversal) and (in my
> case) the tunnel gateway is just the same host that actually generates the
> "to be encrypted" packets. That is the tunneling is not applied on the
> forwarded packets but packets generated locally.
Is the other end also its own tunnel gateway address? If not, you may wish
to consider just configuring a tunnel with a distinct inner address and doing
it that way.
Also, if you're manually-adding NAT-Traversal SAs, you'll need to specify
parameters like, "encap udp".
> Any links?
We lack in support for self-encapsulated Tunnel Mode because we've found most
of our customers use Transport Mode for end-to-end protection. Unless the
packet is being forwarded post-decapsulation, Tunnel Mode is a waste of
sizeof(IP-header) bytes and injects known plaintext into the packet.
If the packet *is* being forwarded at one end post-decapsulation, it's
sensible to assign an "inner address" to the end that isn't forwarding. For
example:
lo0: flags=2001000849 mtu 8232
index 1
inet 127.0.0.1 netmask ff00
e1000g0: flags=201000843 mtu 1500
index 2
inet A.B.C.4 netmask fff8 broadcast A.B.C.7
ether a:b:c:d:e:f
ip.tun0: flags=10008d1 mtu 1402
index 3
inet tunnel src A.B.C.4 tunnel dst X.Y.Z.9
tunnel security settings --> use 'ipsecconf -ln -i ip.tun0'
tunnel hop limit 60
inet 10.2.2.2 --> 10.1.1.1 netmask
Dan
___
networking-discuss mailing list
networking-discuss@opensolaris.org
Re: [networking-discuss] ip.tun0 and the same subnets
On Fri, Nov 21, 2008 at 08:23:57AM -0500, Dan McDonald wrote: > > How can I create a tunnel between 2 subnets with the same addresses? For > > example 10.2.3.0/24. > > So you want 10.2.3.0/24 to go over ip.tun0? Using your example above as the > already-plumbed tunnel, just add a route: Upon further review, you can also have both ends be on the same subnet. ifconfig ip.tun0 10.2.3.1 10.2.3.2 . route add 10.2.3.0/24 10.2.3.2 and switch "10.2.3.1" and "10.2.3.2" in the above example for the other side. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] ip.tun0 and the same subnets
> the documentation says that I can create a tunnel between 2 different > subnetworks, for example 10.1.2.0/24 and 10.2.3.0/24: > > ifconfig ip.tun0 10.1.2.1 10.2.3.1 tsrc 192.168.1.10 tdst 192.168.2.10 > > How can I create a tunnel between 2 subnets with the same addresses? For > example 10.2.3.0/24. So you want 10.2.3.0/24 to go over ip.tun0? Using your example above as the already-plumbed tunnel, just add a route: route add 10.2.3.0/24 10.2.3.1 Or am I missing something? Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
[networking-discuss] Default TCP window size -- why still 48k?
shell(~)[0]% ndd -get /dev/tcp tcp_xmit_hiwat 49152 shell(~)[0]% ndd -get /dev/tcp tcp_recv_hiwat 49152 shell(~)[0]% Why are our TCP window sizes by default so small? Many transactions are performed these days over either long-distances, with latency-inducing encryption from IPsec or some VPN middlebox/middleware, or worse, with one or more layers of latency-inducing middleboxes like NATs in between. Thanks! Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] OpenVPN and IPSec
In that case, it's what Jim mentioned before -- a case of module-name overload causing ip.tun0 to probably load the wrong "tun". Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] OpenVPN and IPSec
On Mon, Nov 17, 2008 at 01:29:31PM +0100, Piotr Jasiukajtis wrote: > Blastwave's 'tun' driver is loaded at the boot time but when I type > 'ifconfig ip.tun0 plumb' the machine is almost halted. Reset is the only way > to go... "almost halted"... does that mean if you boot on kmdb you cannnot even break into kdmb? A system dump would be most useful here. > It's SXCE101 + latest Crossbow BFU on 64bit x86 machine. Ahh, even stranger. Did you compile OpenVPN (which obviously introduces kernel modules) with Crossbow and its headers (which may have changed kernel data structures)? Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] OpenVPN and IPSec
On Fri, Nov 14, 2008 at 10:23:59AM +0100, Piotr Jasiukajtis wrote: > > Can I use OpenVPN (tun driver from the Blastwave) and VPN IPSec (ip.tun) in > the same time on the same machine? It depends. The built-in IPsec can be configured to be narrow enough such that your OpenVPN stuff should not get tripped up by IPsec policy. Combine that with proper routing, and you should be okay. If anything will get you, it'll be the routing. If you connect to two private nets where both share common RFC 1918 prefixes, your client will get VERY confused. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] GLDv3 / nemo is cool
On Wed, Oct 29, 2008 at 08:53:59PM +0100, Nils Goroll wrote: > This is great, thanks to all who have contributed to and are still working > on getting such good kernel services into OpenSolaris. Tell your non-OpenSolaris friends about how Nemo is --> we are, after all, looking to grow OpenSolaris! :) Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
Re: [networking-discuss] ILB design doc ( revision 1.0) has been posted
First off, I'm behind on reading the design doc, and for that I apologize. OTOH, I am one of the "IPsec guys" Darren refers to, so let me jump in quickly. On Mon, Oct 27, 2008 at 02:16:45PM -0700, Sangeeta Misra wrote: > >>> Dropping fragmented packets is not acceptable. Talk to > >>> the IPsec guys for some tips on mitigating this problem. > >>> This will come back to bite us if it is implemented like > >>> this. > >> > >> > >> We are aware of several ways to handle this. But we > >> opt to defer this. In practice, this should only affect > >> UDP traffic. And not supporting fragment should not > >> exclude the use of ILB for all UDP apps. So we leave > >> this as an RFE for the next phase of the project. > > > > Correction: in theory this should only impact UDP traffic, > > in practice it affects UDP *and* TCP traffic. > > > As Kacheong has mentioned handling of fragments will be done post Phase > 1 delivery as an RFE. Is this a design review or a code review? If the former, you should have time to address this. I don't know if you've all taken a look at the bottom bunch of functions in $SRC/common/inet/ip/spd.c, but we have the "Fragment Cache" that used to live in SunScreen. It's currently used for fragment caching and checking for IPsec Tunnel Mode packets, but Paul (and he's the fragcache wizard) and I have inspected the code and it wouldn't take TOO much to generalize it to solve your ILB problems. I've Bcc:ed Paul in case he wants to dive deeper, but ILB could: * Split out the fragcache code into its own source file. * Instantiate a fragcache_t whereever you need it. (After I review the whole design doc, I may be able to tell you exactly where!) * Use the fragcache code to solve your IP fragment problems. Dan ___ networking-discuss mailing list networking-discuss@opensolaris.org
[networking-discuss] Dan's small Volo review
I apologize for not having review all of the files touched by Volo. What follows is what I have reviewed. Thanks, Dan = (Cut up to and including here.) = Reviewer Name: Dan McDonald Document/Module Title: Volo Document/Module Author: Rao Shoaib, Anders Persson, and friends Document/Module Version/Date: 6 October 2008 Reviewer Preparation Time: 6+ hours Unfortunately, these files did not receive any review cycles. usr/src/uts/common/fs/sockfs/sockcommon.c usr/src/uts/common/fs/sockfs/sockcommon.h usr/src/uts/common/fs/sockfs/sockcommon_sops.c usr/src/uts/common/fs/sockfs/sockcommon_subr.c usr/src/uts/common/fs/sockfs/sockcommon_vnops.c usr/src/uts/common/fs/sockfs/socknotify.c usr/src/uts/common/fs/sockfs/sockparams.c usr/src/uts/common/fs/sockfs/socktpi_impl.h usr/src/uts/common/fs/sockfs/sockvnops.c usr/src/uts/common/inet/ip/icmp.c usr/src/uts/common/inet/ksocket/ksocket.c usr/src/uts/common/inet/ksocket/ksocket_impl.h usr/src/uts/common/inet/ksocket/ksocket_mod.c usr/src/uts/common/inet/sctp/sctp.c usr/src/uts/common/inet/sctp/sctp_bind.c usr/src/uts/common/inet/sctp/sctp_common.c usr/src/uts/common/inet/sctp/sctp_conn.c usr/src/uts/common/inet/sctp/sctp_cookie.c usr/src/uts/common/inet/sctp/sctp_impl.h usr/src/uts/common/inet/sctp/sctp_input.c usr/src/uts/common/inet/sctp/sctp_notify.c usr/src/uts/common/inet/sctp/sctp_opt_data.c usr/src/uts/common/inet/sctp/sctp_output.c usr/src/uts/common/inet/sctp/sctp_shutdown.c usr/src/uts/common/inet/sctp_itf.h usr/src/uts/common/inet/sockmods/sockmod_sctp.c usr/src/uts/common/inet/sockmods/sockmod_sdp.c usr/src/uts/common/inet/sockmods/socksctp.c usr/src/uts/common/fs/sockfs/socksctp.c usr/src/uts/common/inet/sockmods/socksctp.h usr/src/uts/common/fs/sockfs/socksctp.h usr/src/uts/common/inet/sockmods/socksctpsubr.c usr/src/uts/common/fs/sockfs/socksctpsubr.c usr/src/uts/common/inet/sockmods/socksdp.c usr/src/uts/common/fs/sockfs/socksdp.c usr/src/uts/common/inet/sockmods/socksdp.h usr/src/uts/common/fs/sockfs/socksdp.h usr/src/uts/common/inet/sockmods/socksdpsubr.c usr/src/uts/common/inet/squeue.c usr/src/uts/common/io/ib/clients/rds/rds_opt.c usr/src/uts/common/io/ib/clients/rds/rdsddi.c usr/src/uts/common/io/ib/clients/sdp/sdpddi.c usr/src/uts/common/io/sock_conf.c usr/src/uts/common/io/strplumb.c usr/src/uts/common/netinet/icmp6.h usr/src/uts/common/os/fio.c usr/src/uts/common/os/modconf.c usr/src/uts/common/os/strsubr.c usr/src/uts/common/smbsrv/smb_kproto.h usr/src/uts/common/smbsrv/smb_ktypes.h usr/src/uts/common/sys/Makefile usr/src/uts/common/sys/ksocket.h usr/src/uts/common/sys/modctl.h usr/src/uts/common/sys/socket.h usr/src/uts/common/sys/socket_proto.h usr/src/uts/common/sys/socketvar.h usr/src/uts/common/sys/sockio.h usr/src/uts/common/sys/squeue.h usr/src/uts/common/sys/squeue_impl.h usr/src/uts/common/sys/stream.h usr/src/uts/common/sys/strsubr.h usr/src/uts/common/syscall/sendfile.c usr/src/uts/intel/Makefile.intel.shared usr/src/uts/intel/ia32/ml/modstubs.s usr/src/uts/intel/icmp/Makefile usr/src/uts/intel/icmp/icmp.global-objs.debug64 usr/src/uts/intel/ip/ip.global-objs.debug64 usr/src/uts/intel/ip/ip.global-objs.obj64 usr/src/uts/intel/ksocket/Makefile usr/src/uts/intel/rts/Makefile usr/src/uts/intel/rts/rts.global-objs.debug64 usr/src/uts/intel/smbsrv/Makefile usr/src/uts/intel/socksctp/Makefile usr/src/uts/intel/socksdp/Makefile usr/src/uts/intel/tcp/Makefile usr/src/uts/intel/udp/Makefile usr/src/uts/sparc/Makefile usr/src/uts/sparc/Makefile.sparc.shared usr/src/uts/sparc/icmp/Makefile usr/src/uts/sparc/icmp/icmp.global-objs.debug64 usr/src/uts/sparc/ip/ip.global-objs.debug64 usr/src/uts/sparc/ip/ip.global-objs.obj64 usr/src/uts/sparc/ksocket/Makefile usr/src/uts/sparc/ml/modstubs.s usr/src/uts/sparc/rts/Makefile usr/src/uts/sparc/rts/rts.global-objs.debug64 usr/src/uts/sparc/smbsrv/Makefile usr/src/uts/sparc/socksctp/Makefile usr/src/uts/sparc/socksdp/Makefile usr/src/uts/sparc/tcp/Makefile usr/src/uts/sparc/udp/Makefile usr/src/uts/common/inet/tcp/tcp.c usr/src/uts/common/inet/tcp/tcp_fusion.c usr/src/uts/common/inet/tcp/tcp_opt_data.c usr/src/uts/common/inet/tcp/tcpddi.c usr/src/uts/common/inet/tcp_impl.h usr/src/uts/common/inet/tcp_stack.h . . . usr/src/cmd/cmd-inet/usr.bin/netstat/unix.c usr/src/cmd/cmd-inet/usr.sbin/soconfig.c usr/src/cmd/mdb/Makefile.common usr/src/cmd/mdb/common/modules/genunix/vfs.c usr/src/cmd/mdb/common/modules/sockfs/sockfs.c usr/src/cmd/mdb/intel/amd64/sockfs/Makefile usr/src/cmd/mdb/sparc/v9/Makefile usr/src/pkgdefs/SUNWhea/prototype_com usr/src/pkgdefs/SUNWibsdp/postinstall usr/src/pkgdefs/SUNWibsdp/preremove usr/src/pkgdefs/SUNWibsdp/prototype_i386 usr/src/pkgdefs/SUNWibsdp/prototype_sparc usr/src/pkgdefs/SUNWmdb/prototype_i386 usr/src/pkgdefs/SUNWmdb/prototype_sparc usr/src/pkgdefs/SUNWmdbr/prototype_i386 usr/src/pkgdefs/SUNWmdbr/prototype_sparc usr/src/pkgdefs/common_files/i.sock2path usr/src/uts/Makefile.uts usr/src/uts/common/Makefile.files usr
