RE: Two security issues from IETF #57

Silverton Aron-C1710C <[email protected]>
Newsgroups gmane.ietf.rserpool
Message-ID <[email protected]>
Hi Maureen,

Comments inline.

[email protected] wrote:
> The security discussion at IETF #57 raised two issues that we agreed
> would be brought to the list for comment. 
> 
> Issue #1
> TLS or IPsec mandatory to implement?
> 
> The security design team consensus was that the network designer
> could either use TLS or IPsec as mandatory to implement for ENRP-PE
> and ENRP-ENRP communication.  The PU-ENRP was previously decided to
> be mandatory to implement TLS for reasons of interoperability.   
> Direction from the ADs and consensus in the meeting was that one
> security mechanism should be made mandatory to implement for all.  It
> was agreed to select TLS as mandatory to implement by those attending
> the meeting.  Do the people on the list agree? 

Agree.  
    
> 
> Issue #2
> Security of ENRP server registrations and ENRP to ENRP communications
> 

<snip>

 It was agreed to
> restrict the ENRP database to secure registrations only and secure
> communications between ENRP servers OR insecure registrations only by
> those attending the meeting.  Do the people on the list agree?  

I'm not sure that I understand what was agreed upon.  Are we talking about
two modes of operation:

(1) Secure registrations only and secure ENRP-ENRP traffic, and
(2) Insecure registrations only and insecure ENRP-ENRP traffic?

My feeling is that ENRP-ENRP should be secured in any case, but this may not
be practical.  This will have an affect on the use of multicast between ENRP
servers and I believe that we should discuss this during the next security
design team meeting.  (I have previously sent an email regarding this to the
design team members.)  My thought would be to disallow use of multicast in
ENRPv1, but leave a section in the draft explaining how it could be used
properly with secure multicast.  Perhaps by ENRPv2, there will be a secure
IGMP or something similar.  Developing our own custom secure multicast
option should not be an option in my opinion. 

In all likelihood, an operator with a closed system (not traversing the
Internet) will probably choose to do whatever they want in terms of
ENRP-ENRP security and multicast.
   
> 
> Comments?
> 
> -- maureen
> 

Regards,

Aron
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.