Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS

From: [email-masked]
Date: Tue, 17 Feb 2004 15:49:36 +0200

Hi Attila,

Nary Tra's email also raised a question in my mind:

> 3. In the last paragraph of 2(protocol model), 'they are not able to
> establish and maintain security associations with their neighbors, which
> means, they can only be applied in a trusted domain'. The stateless does not
> mean no security association.  In rsvp, the sa is not specified how it can
> create (maybe by ike, manual) and which node is the next rsvp-aware node.

In an IESG review of a SIGTRAN document of mine, the IESG (specifically
the Security Area Director) said that the IESG will not standardize 
anything with the 'trusted domain' concept.  The Security AD commented
that compromised nodes in a 'trusted network' have caused far more
serious problems than is always documented.  For example, a disgruntled
employee with a key to the server room can do a lot of hacking.  With this
in my mind, I think that you will have to rethink this part of your
draft.  You need to be able to provide a mechansims of how neighbors
can establish & maintain security associations.  This does not mean
that a security association always must be used, but the the possibility
for creating a security association is mandatory, in my opinion.

thanks,
John

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 17 Feb 2004 15:49:40 +0100

Hi John

> for creating a security association is mandatory, in my opinion.

The RMD QoS-NSLP model draft is just specifying a QoS model that can be used
in combination with the QoS-NSLP protocol.
The QoS-NSLP protocol, independently of the used QoS model,
should be able to establishsh & maintain security associations between
certain neighbours (e.g., edge nodes) in such a way that the
end to end security association will not brake.

Best Regards,
Georgios

---

From: Steven Blake <[email-masked]>
Date: Wed, 18 Feb 2004 17:41:03 -0500

> for creating a security association is mandatory, in my opinion.

The notion of "trusted domain" is inherent in the Diffserv architecture
(RFC 2475).  Any sort of service assurance within a network is dependent
on the ability to condition the traffic at the edges according to the
service provisioning policy of the network operator.  Diffserv cannot
work as intended unless the boundary of the network is "air-tight" with
respect to admitting traffic with certain DSCP markings.

The RMD-QoS-NSLP draft introduces a signaling mechanism by which
admissions control can be implemented and the traffic conditioning at
the domain boundary can be more carefully configured (e.g., to achieve
higher utilization at a certain service assurance level).  I see this as
very much in line with the Diffserv architecture in the sense that the
only additional requirement on the boundary QNEs is to ensure that
rogue signaling messages don't enter the domain (this is not mentioned
specifically in the draft but should be).

Imposing hop-by-hop security associations as a mandatory operating mode
for QoS-NSLP will make that protocol just as useful as RSVP/Intserv in
the Internet; i.e., not very.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                +1 919-472-9913