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

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Fri, 8 Mar 2002 20:57:46 +0100

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!

Best regards,
Georgios

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

Hi,

Exactly. The requirement relates to 'NSIS hops' i.e. the signalling between QI and first QC, or between a pair of QCs, or between QC and last QR. I don't see any reason for NSIS to specify security requirements for entities that don't take part in NSIS signalling.

We might say that some QC pairs don't need a security relationship, e.g. if they're in the same domain. (I guess this is more the scenario Georgios is referring to???) But we need to be careful here: I think what we would actually be saying is that interiors of domains can be protected from unauthorised traffic so they can assume that they can trust any NSIS signalling they get. In that case, we should define very carefully how this shielding is done.

I see a close parallel here with routing protocol security. Basic IGPs (RIP, OSPF, ...) usually have an authentication capability, but as an option. Do people actually use these options? (Would they be prepared to admit it if they didn't? In today's uncertain world, would they be better off if they did?)

robert h.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: 08 March 2002 16:30
> To: Georgios Karagiannis (ELN); [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] 5.8.5 requirement (Section 5.8.5)
> 
> 
> dear georgios!
> 
> > Dear Marcus
> 
> > Another problem, requirement:
> > "The QoS signaling protocol must allow for hop-by-hop 
> security" in Section
> 5.8.5
> 
> > I do not agree that all intermediate routers located in a 
> communication
> path
> > should support this requirement.
> > However, I agree that some nodes, e.g., end host, Access 
> routers, proxies,
> centralised resource
> > managers need to support security issues;
> 
> > Therefore, I propose to either  remove this requirement or 
> emphasisse that
> this requirement
> > is not hop-by-hop but applied on certain specialised nodes, 
> e.g., .end
> host, access routers, centralised
> > resource managers....
> 
> The requirement of section 5.8.5 "The QoS signaling protocol 
> must allow for
> hop-by-hop security" does not
> necessarily mean that every router must enforce hop-by-hop security
> protection. a qos protocol must however
> support mechanisms that allow hop-by-hop security mechanism to be used
> between qos signaling aware nodes.
> 
> > Best regards,
> > Georgios
> 
> ciao
> hannes
> 
> 
> _______________________________________________
> 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: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 11 Mar 2002 11:07:27 +0100

hi georgios

> NSIS. Not all the intermediate routers should process the hop-by-hop
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