Re: Last Call: <draft-ietf-sidr-rpki-rtr-19.txt> (The RPKI/RouterProtocol) to Proposed Standard

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

 



----- Original Message -----
From: "Russ Housley" <housley@xxxxxxxxxxxx>
To: "Danny McPherson" <danny@xxxxxxx>
Cc: "IETF" <ietf@xxxxxxxx>
Sent: Wednesday, December 21, 2011 7:06 PM
>
> >> 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.

Tom Petch






>
> Russ
> _______________________________________________
> 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]