On Sun, Apr 10, 2011 at 01:29:21AM +1000, Geoff Huston wrote: | | On 09/04/2011, at 3:49 AM, Pradosh Mohapatra wrote: | | >> not sure if mandating a single transport is needed at all. | >> | >> since the pros and cons of the various transport protocols | >> (TCP, TCP-MD5, TCP-AO, IPSec, SSH) are well understood, why not simply | >> enumerating the choices and leave it to the operator's local security policy | >> which one to deploy ? | >> | >> IMO you cannot dictate local security policy as they are different between | >> operators. also if the level of containment is sufficiently enough (e.g. | >> local-cache only reachable through vrf, not accessible through internet | >> it is perfectly reasonable even to load your cache records using vanilla TCP.) | > | > I have no problem listing various transports. I thought there was a suggestion to | > keep one of them mandatory to encourage better interoperability. That makes | > some sense. | | Frankly the interoperability argument is a very strong one for me. Yes, at every | step and with every component of this design we could enumerate a laundry list | of possible technologies, but, frankly, it seems like a less than useful exercise | of constructing complexity and threatening interoperability of the resultant | system. If the intention is to produce robust specifications that allow cleanly | interoperable implementations then it makes sense for me to produce a | specification that makes specific selections from the choice set.
the question is *what* is that we try to standardize ? - is it 1. the application level communication protocol between caches and routers 2. the application level communication protocol between caches and routers and the transport ? i do not really buy the interop argument as early interop testing has showed that there are already several transports available to carry the rtr-cache protocol (BTW including vanilla TCP.) furthermore how should one read the spec ? - is a rtr-cache protocol implementation doing IPSEC *not* compliant and if so what are the technical arguments against it ? in the spirit of good layering we should really focus on the application protocol and not trying to crawl down the entire stack and securing each and every layer. where does it stop ? i mean shall we include DoS mitigation schemes at L3 and L2 ? clearly not - that is the operators choice and so is to take care of transport level security. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
