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

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

Dear Hannes

Do you mean that this requirement is different than the one 
supported by RSVPv1?
Please note that RSVPv1 performs hop-by-hop security by
using e.g., a hop-by-hop authentication
mechanism which uses an encrypted hash function.  

If that is the case (not an RSVPv1 hop-by-hop security)
then maybe we could emphasise that this 
is not a hop-by-hop authentication mechanism, but something else....

Best regards,
Georgios

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: vrijdag 8 maart 2002 17: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: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 11 Mar 2002 11:07:27 +0100

hi georgios

> Do you mean that this requirement is different than the one
the situation for rsvpv1 are more complicated if
you take the policy aware and policy unware routers into consideration.
there you have basically two "hop-by-hop" security mechanisms. the rsvp
integrity
object however provides similar functionality.

the protocol needs to have an option for hop-by-hop protection.
for some interface this protection is strongly advised whereas others
are left open to the network operator. it is the choice of the network
operator how to protect his internal network.

> mechanism which uses an encrypted hash function.
a keyed message digest

> is not a hop-by-hop authentication mechanism,
we could clearify the term hop-by-hop and mention some example of
nodes involved in the hops.

> but something else....
there are only two terms to choose from:
hop-by-hop and end-to-end. i don't want to invent a new term since it is
used in many protocols and it is not useful (i think)!

what do you think?

ciao
hannes

hannes