Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5)

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Wed, 13 Mar 2002 11:46:20 +0100

Hi Hannes

What I mean is the following.
If some QoS domain will use aggregated reservation states
and if the lifetime requirement has to be supported by the domain,
then new per flow reservation lifetime states have to be created 
in this domain.

Best Regards,
Georgios

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: woensdag 13 maart 2002 11:06
To: Georgios Karagiannis (ELN); 'Hancock, Robert'; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5)

hi
>
> Hi Hannes
>
> What about saying something like:
> The initiator of the NSIS protocol can require
> the support of the hop-by-hop security feature.
because of the chain-of-trust assumption it is not possible for the
initiator
to require that all providers provide some sort of protection. every node
can
only decide whether it has to include a security protection or not. if the
receiver requires the protection and no such protection is present then the
request is not processed and an error message is returned.

> However, an administrator of a QoS domain is able to
> deactivate this feature, when the NSIS protocol
> is used within its administrative QoS domain.
true. an administrator of a qos domain may decide to require authenticated
qos signaling messages at the borders and not within the nodes of the core
network.

how about this (modified) requirement?

5.8.5 The QoS signaling protocol must allow for hop-by-hop security.

Hop-by-hop security enables authentication, integrity, possibly
confidentiality and replay protection of QoS signaling messages exchanged
between two QoS aware network elements. The chain-of-trust principle then
allows non-neighboring nodes to trust each other based on the existing trust
of neighboring nodes.

If, however, a network element along the path is not participating in the
QoS signaling i.e. a QoS unaware or ignorant node (e.g. because the QoS
signaling message are transmitted over a non-QoS signaling aware cloud) then
neither QoS nor QoS protocol specific security mechanisms are executed by
this node. Furthermore a network provider may also decide (independently of
other involved parties) not to use hop-by-hop protection of the signaling
messages between every QoS aware node within his own administrative domain
(e.g. because other security mechanisms are in place or because of a strong
trust assumption). In this case the hop-by-hop security is relaxed and
hop-by-hop security is only used between QoS aware nodes which are also QoS
security aware.

Hop-by-hop security allows intermediate nodes that actively participate in
the QoS protocol to modify the messages as required by the QoS processing.
Note that this requirement does not exclude end-to-end or network-to-network
security of a QoS reservation request. End-to-
end security between the initiator and the responder may be used to provide
protection of non-mutable data fields. Network-to-network security refers to
the protection of messages over various hops but not in an end-to-end manner
i.e. protected over a particular network.

ciao
hannes

> Best Regards,
> Georgios

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

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 13 Mar 2002 13:05:54 +0100

hi georgios!

> then new per flow reservation lifetime states have to be created
but where do you see the problem for hop-by-hop security?

ciao
hannes