Re: [IETF] Re: Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/Router Protocol) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Dec 20, 2011, at 6:00 PM, Danny McPherson wrote:

> 
> I'm kinda surprised the security ADs are OK with this in a brand new connection-oriented protocol meant to increase security of the network:
> 
> S.7:
> 
> "Caches and routers MUST implement unprotected transport 
> over TCP using a port, rpki-rtr, to be assigned, see Section 12.
> Operators SHOULD use procedural means, ACLs, ... to reduce 
> the exposure to authentication issues."

Yup. 

Just below the text that you included there is: "If available to the operator, caches and routers SHOULD use one of the following more protected protocols." and a list of things including AO, SSH, TCP MD5, IPSEC, TLS. 

Sections 7.1. (SSH Transport), 7.2.  (TLS Transport), 7.3.  (TCP MD5 Transport) and 7.4.  (TCP-AO Transport) provide more information on using these.

The Security Considerations section also say:
      ...
      So the strength of the trust relationship and the transport
      between the router(s) and the cache(s) are critical.  You're
      betting your routing on this.
      …
      Transports which can not provide the necessary authentication and
      integrity (see Section 7) must rely on network design and
      operational controls to provide protection against spoofing/
      corruption attacks.

I'm sure that the authors would have preferred to simply say "Use TCP-AO", and saved themselves a bunch of typing (and Security warnings, etc) -- it is obvious that they are not tying to gloss over the concerns.

Unfortunately not all OSs support TCP-AO…. Well then, it seems that, as routers already support SSH it should be simple to wrap a TCP stream, yes? Unfortunately no -- not all implementations have a simple library type model. Same things for IPSec / TLS, etc.

In an ideal world there would be ubiquitous, secure, fast, cheap, reliable, unencumbered transport security -- unfortunately we are not there (yet). Folk who have support for secure transports available should use them, but if I don't, I'd still like to have the option to deploy this.

The perfect is the enemy of the good.

> -danny

Warren.

> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]