Re: Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/RouterProtoco

> > > > Once process by the server, a protocol that provides authentication and
> integrity protection is used between the server and router.  From the Table of
> Contents, the choices are clear:
> > > >   7.1.  SSH Transport
> > > >   7.2.  TLS Transport
> > > >   7.3.  TCP MD5 Transport
> > > >   7.4.  TCP-AO Transport
> > > >
> > > > I would personally prefer that the TCP MD5 choice not be used, but the
> model is clear.
> > > > This approach lets the server handle that certificate path construction,
> signature checking, and revocation checking.  It seems desirable to offload
> these potentially expensive operations, while preserving the integrity of the
> subset of the information actually needed by the router.
> > > Right, so precisely back to my original concern:
> > >
> > > "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."
> > Maybe I misunderstood your concern.  The operator's server to the operator's
> routers only involves the operator's internal network.  While I would 
> personally
> prefer a mandatory-to-implement mechanism, I can see that operators do not
> necessarily want prescriptive statements on this part of the specification.
>
> Russ
>
> The question of where the servers would be located, locally or somewhere out 
> on
> the Internet, was raised during the development of this document and the 
> answer
> was, we do not know; so I think that if you only regard it as secure when only
> an internal network is involved, then that needs calling out in the Security
> Considerations.
I agree.

Russ

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf