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

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 8 Mar 2002 19:47:31 -0000

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
>

---

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

Sorry Hannes, 
 
I think I mixed up the number of the requirement :-) 
This reply is a reply to the e-mail sent by Marco.
Therefore, in a while I will re-send this reply  to Marco.
Regarding your proposal I think the description of the requirement 
is going into the right direction,
but I will need some more time to think if I can understand all 
the possible implications.

Best regards,
Georgios

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: woensdag 13 maart 2002 13:06
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 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.
but where do you see the problem for hop-by-hop security?

ciao
hannes
> Best Regards,
> Sent: woensdag 13 maart 2002 11:06
> To: Georgios Karagiannis (ELN); 'Hancock, Robert'; [email-masked]
> Cc: [email-masked]
> 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
> >
>