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

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

Hi Robert,

Please see inline.

Sven

"Hancock, Robert" <[email-masked]>@ietf.org on 17/02/2004
15:28:13

Sent by:    [email-masked]

To:    "[email-masked]'" <[email-masked]>, [email-masked],
       [email-masked]
cc:
Subject:    RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS

hi.

so far as i can tell, (it's certainly what is in my head),
it could probably be made a MUST for GIMPS implementations
that it should be possible to configure a node policy that

- no NSLP data is carried in datagram mode;
- connection mode must be secured.

in the case that the QoS-NSLP is prepared to rely entirely
on GIMPS for its security services (*which is of course an
issue for discussion at the moment*), this would therefore
seem to address the concern below, at least partially.

Sven>> Imho, the QoS NSLP should rely on GIMPS for some/most of its
security services but GIMPS alone is not sufficient because it does not
protect against compromised QNEs, only against their interconnection.

[of course, the node would no longer have the performance/
scalability properties that some people apparently desire,
because of the GIMPS behaviour when this type of policy is
in place; however, the NSLP behaviour would not need to be
redefined.]

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 14:50
> To: [email-masked]; [email-masked]
> Subject: RE: [NSIS] RMD-QoS-NSLP model draft submitted to NSIS
>
>
> 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
>

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

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

---

From: "Thanh Tra LUU" <[email-masked]>
Date: Tue, 17 Feb 2004 15:53:29 +0100

hi Sven,

> protect against compromised QNEs, only against their interconnection.

do you mean QoS-NSLP would support authentication policy elements (as rsvp)
and NTLP would support integrity elements (in rsvp) or QoS-NSLP may do all
in some cases ?

Nary Tra,
ENST, Paris.