Hi Greg, Sorry, I was on vacation, thus a late reply marked by [MSC].
> Hi ALTO extension folks, as I'll not be making it up to Vancouver :-( , here > are some questions/comments. > These comments/questions are from the perspective of creating an ALTO > topology service (suitable for large bandwidth and SDN applications). > http://tools.ietf.org/html/draft-scharf-alto-vpn-service-01 > ALTO for VPNs: Way back when we started talking about "topology" like > extensions. The concept of ALTO for "controlled or partially controlled" > environments was floated. It seems that a VPN type of service would be the > exemplar of such an environment and hence pave the way for "restricted > environment" use of ALTO. Questions: Are there specific additions to the > REST API to offer this some kind of security, i.e., to keep others from > gaining information about a customers VPN? Or would a general approach to > security of this interface be specified? [MSC] Yes, indeed, the exposure of a VPN topology from the network service provider to the VPN customer is a much more controlled environment than use of ALTO in the public Internet. draft-scharf-alto-vpn-service-01 basically argues in favor of running one ALTO server instance for each VPN customer, protected by authentication and authorization mechanisms (e.g. HTTPS-based). In simple use cases we currently believe that the existing ALTO REST interface is sufficient from a security perspective, e.g., as long as we use the vanilla map or ECS services for a simple L3VPN. But I am not a security expert. Access control may get more complicated e.g. if the same customer runs several VPNs, if there is multi-homing, etc. We have not fully analyzed the security implications of more complex VPN use cases. Also, there are further subtle differences between public Internet and VPNs. For instance, unlike in the public Internet, a VPN customer knows (or at least could know) some basic properties of the topology that the ALTO server would expose. For instance, a customer could know what VPN endpoints exists, and there is no need for topology abstraction regarding endpoints. As a result, some of the ISP privacy concerns typical for the public Internet might not apply to VPNs. For instance, an ISP might be more willing to expose fine-granular ALTO maps of a VPN. But there are also new challenges. For instance, if a VPN offers SLA guarantees, a customer could try to use ALTO guidance to audit SLA compliance of the network service provider. But in my current understanding this mostly affects the information that the ALTO server exposes, not the REST interface itself. Finally, keep in mind that one of the key differences between public Internet and VPNs is the use of identifiers. An IP address may not be the only or not the best way to address a VPN endpoint. This certainly has implications on the ALTO REST interface, but not necessarily regarding security. My 2 cents... Michael _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
