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

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Mon, 11 Mar 2002 11:36:58 +0100

Hi Hannes

What about saying something like:
The initiator of the NSIS protocol can require 
the support of the hop-by-hop security feature.
However, an administrator of a QoS domain is able to
deactivate this feature, when the NSIS protocol 
is used within its administrative QoS domain.

Best Regards,
Georgios

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

hi georgios

> Hi Robert

> It is also exactly to what I am referring, when I am referring
> to hop-by-hop security. There will be intermediate  routers that will use
> NSIS. Not all the intermediate routers should process the hop-by-hop
> security option!
but we cannot formulate this as a requirement.
the requirement can only be that a qos signaling protocol must provide a
hop-by-hop security
element. for some parts of the path (for example within a administrativek
domain)
the network service provider may choose not to use it e.g. because of the
strong trust
assumtpions, because of other security mechanisms deployed etc. without
knowing the
constrainsts and the architecture of service provider's network it should be
assumed that
the provided security mechanisms are deployed.

some questions that usually arise are:

- why do we think that such a protection is necessary?

in general, without the requirement for a minimum of a security protection
it is possible to inject faked messages (and other types of attacks).

- are there possibilities when to relax this requirement?

if a network service provider thinks for example that his core-network is
"secure" and no
adversary is able to inject bogus signaling messages into the network (e.g.
because only
authenticated are allowed to enter the domain) then he may do so.
this change does not "destroy" the hop-by-hop requirement. it only changes
the number of
nodes participating in the hop-by-hop protection (i.e. because the service
providers feels
that the core network should only represent one hop). you may argue that
there is a question
of what is considered to be a hop. this is actually true!

- are these mechanisms performance intensive?

usually hop-by-hop protection is achieved by using an keyed message digest
such as SHA-1,
RIPEMD-160 or MD5 computed over the entire message including a replay
protection field.
these algorithms are known to be very fast.

- is it difficult to establish the security association within the
core-network (between
neighboring routers.

our current view is that such a security association establishment is not
too difficult
because of
* the trust relationship within the core network (run by a single network
provider)
* the limited number of security associations required (only neighboring
routers need to
  have a security association with each other)

the security association between the user and a node in the network is in
general more difficult
to established.

(if i use the term router i refer to a router participating in the qos
signaling.)

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 11:06:25 +0100

hi
> 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.

> 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