Garrett D'Amore writes: > James Carlson wrote: > > At a minimum, such an approach means that we end up with the same > > IPsec and IP Filter policy bypass as we saw with IB SDP, as well as > > unclear TX interaction, and all of that requires additional > > documentation and PAC advice. > > > > I'm not sure I understand here. The embedded environment is not equipped > to participate in IPsec. If the customer *administratively* enables AMT > (which is, IIRC, off-by-default),
OK; "off by default" was one of the missing bits. > Assignment of addresses, and whether to share IP addresses or not (by > default it does share!) is done using BIOS configuration screens typically. I'd like to understand that better. Solaris can have multiple IP addresses on a single interface, and can use VLANs and other virtualization techniques, as well as IP address configuration that comes by way of DHCP and other mechanisms. How does this device know which address to use? As for my comment above, the fact that this device pulls packets out of band means that configured Solaris IP Filter policies are bypassed: if you set the system up to filter out particular hosts, that policy will _NOT_ work for the AMT. That's a surprising result, at least to me. The system will just ignore those filters. All of this also begs a question about what the loopback proxy is for ... > As far as interfaces go, the HTTP/SOAP interfaces are "AMT project > private" in normal ARC parlance, or, at worst, they could be called > Volatile. Sure. I figured they were actually "Committed Private" for Intel -- as they'd have to be in some format that can deal with upgrade issues. I wasn't so concerned with that. I was more concerned with the security mechanism. > * management of the LMS service, in particular how does it get started, > stopped, etc. (I'd like to see a full specification of the SMF facility, > is it standalone or inetd started, etc.) Agreed. > - AMT may not operate properly with NWAM, for the same reasons (project > team please confirm/elaborate here) (I'm not sure this precisely is an > ARC matter, either.) Projects that don't interoperate correctly or that are incompatible with each other _are_ important architectural details and are also things that we (as a system vendor) have to document for users. I doubt this will work right with TX labeled packets, so that's probably off the table. I see no mention of IPv6, so perhaps that's off as well. IP Filter and IPsec policies are ignored for the AMT traffic because there's no way for the host to implement them. The same goes for NAT and port redirection. Solaris port aggregation and can't work for similar reasons. IPMP _might_ not work right. If the address used by the AMT is marked "nofailover" rather than being a normal data address we might be able to get away with it. It's unclear. I have no idea if Solaris VLAN support is affected. Nor do I know what happens to a project that introduces an 802.1X authenticator -- likely, the port security switch is ineffective because that'd also be in Solaris software. > I think all these bits can be resolved, and done so satisfactorily in > the context of a fasttrack. However, I don't think it will be the end of > the world (or even particularly bad for any particular business needs) > if this case were derailed into a full case. All I'm interested in are the details. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
