Subject: [Rserpool] Security design team conference call

From: [email-masked]
Date: Tue, 5 Aug 2003 13:54:20 -0500

The security design team will have a conference call to discuss this issue and other security related issues.  I'm suggesting either Aug. 14 or Aug. 18 as possible dates at 10AM EST USA.

Please send me e-mail if you wish to join us and indicate what date would be good for you.  Or you can suggest another time.

-- maureen

-----Original Message-----
From: ext Silverton Aron-C1710C [mailto:[email-masked]]
Sent: Wednesday, July 23, 2003 11:26 AM
To: Stillman Maureen (NVO-NIC/Ithaca); [email-masked]'
Subject: RE: [Rserpool] Two security issues from IETF #57

Hi Maureen,

Comments inline.

[email-masked] 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

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool