Subject: Re: [NSIS] Open Issues: Peer-to-Peer Protection

From: Bob Braden <[email-masked]>
Date: Tue, 5 Nov 2002 16:54:48 GMT

*> 
  *> I am not sure what we need to protect end-to-end can you give some example 
  *> applications for other then peer-to-peer
  *> 
  *> Marcus
  *> 
  *> --On Dienstag, 5. November 2002 09:35 +0100 Hannes Tschofenig 
  *> <[email-masked]> wrote:
  *> 
  *> > hi
  *> >
  *> > i guess that there is no doubt that a signaling protocol like NSIS must at
  *> > least offer peer-to-peer protection. it was often mentioned that more than
  *> > peer-to-peer protection might also be required. should there be a
  *> > requirement which states something similar?
  *> >
  *> > ciao
  *> > hannes
  *> >

Marcus,

I don't think it is so much a matter of need as it is of ability. 
Security wonks always feel uncomfortable about the transitive trust
model implied by pure hop/hop integrity.  They point out that if any
link in the chain is penetrated, then the whole path is penetrated.
They would like a digital signature from the signaling initiator that
can be checked at every node along the path.  (Never mind the CPU cost
of that... ;-( )  Unfortunately, the nature of signaling is that in
general the contents of the signaling -- the SAPU -- changes in some
way from hop to hop along the path.  So the best you can do is to sign
the invariant parts of the SAPU -- e.g., the session designation.
There is no other known solution to the general problem of E2E
protection of signaling messages.

This problem arose big time in the active networks research program,
and Sandy Murphy will be first to admit that she didn't solve it.

Bob Braden

  *> > _______________________________________________
  *> > nsis mailing list
  *> > [email-masked]
  *> > https://www1.ietf.org/mailman/listinfo/nsis
  *> 
  *> 
  *> 
  *> --------------------------------------
  *> Dr. Marcus Brunner
  *> Network Laboratories
  *> NEC Europe Ltd.
  *> 
  *> E-Mail: [email-masked]
  *> WWW:    http://www.ccrle.nec.de/
  *> Phone: +49 (0) 6221 905 11 29
  *> personal home page: http://www.brubers.org/marcus
  *> 
  *> 
  *> _______________________________________________
  *> 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: Steven Berson <[email-masked]>
Date: Tue, 5 Nov 2002 09:45:37 -0800 (PST)

> protection of signaling messages.

This is not quite true.  Signing each change to the message will solve 
the general problem of E2E protection of signaling messages.  With 
each change signed, there is no dependence on transitive trust.

Steve

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 6 Nov 2002 10:11:47 +0100

hi steve, hi bob.

please see my comments inline.

> > of that... ;-( )
a digital signature by the signaling message initiator is not necessarily
required. i see that there is a problem with cpu costs etc.

>  Unfortunately, the nature of signaling is that in
> > way from hop to hop along the path.
true. some things. some other things don't.

  So the best you can do is to sign
> > protection of signaling messages.

i intentionally avoided the term end-to-end protection. non peer-to-peer
protection is not necessary end-to-end protection.

you can take a look at the following figure to see the possible options:

             ****************************************
              *                                      *
              *                                      *
         +----+-----+       +----------+        +----+-----+
   +-----+ Router   +-------+ Router   +--------+ Router   +-----+
   |     |    1     |       |    2     |        |    3     |     |
   |     +----------+       +----+-----+        +----------+     |
   |                             ~                               |
   |                             ~                               |
   |                             ~                               |
   |                             ~                               |
   |                             ~                               |
   |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~                               |
   |  ~                                                          |
   |  ~                                                          |
+--+--++                                                      +--+---+
| Host +//////////////////////////////////////////////////////+ Host |
|  A   |                                                      |  B   |
+------+                                                      +------+

 Legend:
  -----: Peer-to-Peer Trust Relationship
  /////: End-to-End Trust Relationship
  *****: Middle-to-Middle Trust Relationship
  ~~~~~: End-to-Middle Trust Relationship

i intentionally avoided the term end-to-end protection. non peer-to-peer
protection is not necessary end-to-end protection.

for example:
the rsvp integrity object is used in two places:
a) to protect the entire rsvp message (=peer-to-peer security)
b) to protect the policy object (=something other than peer-to-peer).

another example:
protecting local information

authorization tokens would be another form of non peer-to-peer protection.

whether to have support for end-to-end protection is a different issue. i
argue that you do not need to have end-to-end security because the protocol
behavior (e.g. proxy behavior, acting on behalf of someone else, initiating
signaling message everywhere, modification of messages along the path, etc.)
might not be simply possible. if some sort of end-to-end negotiation should
take place then this could experience e2e protection.
i tend to avoid e2e security protection. pure end-to-end issues should be
done with end-to-end protocols (not with nsis).

> each change signed, there is no dependence on transitive trust.
depending on the protocol behavior this creates a solution which is not
scalable and a performance disaster.
> > and Sandy Murphy will be first to admit that she didn't solve it.

ciao
hannes