Subject: RE: [NSIS] Security threats

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 3 Mar 2003 17:58:36 +0100

hi ruediger

please see my comments inline:

> 
> Hi Hannes,
> 
> I'm having a less complex scenario in mind and add an 
> example below, clarifying what I'd like get. 
> Additional remarks in line.
> 
> Regards, Rüdiger
> 
> Here you mean NSLP, I guess.
> H|a number of nsis nodes along the path support a ntlp. 
> | however, for firewall signaling only some of them
> | need to be involved in the protocol processing
> | since the remaining nodes are, for example, qos aware nodes 
> | (qos nslps). 
> | 
> | the question is now:  
> | would we like to skip the qos nodes when we do firewall
> | signaling and address only those nodes which are able
> | to process the firewall signaling messages?
> |
> | my preference: 
> | we should skip nodes which do not support a particular nslp 
> | implementation.
> 
> If I remember right, we agreed on the Interim that NTLP
> is processing all NTLP messages regardless of local NSLP
> support.

i cannot recall this agreement. 

the scenario would look like: 

NSLP                       NSLP
NTLP    NTLP      NTLP     NTLP
 A       B         C        D 

nsis messages would address nodes A, B, C and D although they are processed
only by the NSLP? 

> 
> H|this simplifies security handling, refresh message handling 
> | and reliability handling and provides improvements for
> | message processing. the drawback is that the discovery
> | procedure needs to include some capability functionality
> | (i.e. the discovery message says: "i would like to discover
> | the next firewall along the path.").
> 
> I'm not sure whether that holds. A domain gateway router 
> may support QoS-NSLP but no firewall-NSLP. The carrier 
> may be interested in keeping unauthenticated signaling 
> messages out of his domain in general. That isn't 
> possible with your proposal (unless the gateway supports 
> all NSLPs - which I don't feel to be useful).

this is an artifically created example. how likely is it that a provider
installs a firewall in the middle of the network and not at the end. you can
also create strange network configurations. 

btw, you would always drop unauthenticated signaling messages. every node
which receives signaling messages from the outside should provide
authentication and authorization. 

to support your scenario you could give the gateway router (qos-nslp) an
artificial firewall nslp functionality by allowing this node to also
particate in firewall-nslp signaling although firewall functionality (i.e.
packet filter installation) is not provided. 

>  
> Finally, my example. Lets assume a customer network with two
> sites, making a QoS reservation to be used for VoIP calls 
> accross a carrier network. To limit his backbone signaling 
> processing requirements the carrier may prefer to stay out 
> of per VoIP call signaling. So aggregation is applied between 
> his edge nodes. Let's ignore how that is done with regard to 
> QoS. With regard to signaling it means that the carrier 
> routers only maintain state for a single reservation between 
> the two customer sites. Per VoIP call NSIS state maintenance 
> is restricted to the customer domain. Still, all related NSIS 
> signaling messages traverse the carrier network. Path coupled, 
> meaning NSIS path coupled (i.e. downstream and especially 
> upstream).  Correct?  

i try to summarize what you just said without voip terminology:

a) aggregation in the core network - signaling for this region
b) per-flow signaling messages should be hidden in the core 

is this right?

to provide (a) a protocol would need to start and end anywhere. in this case
between the ingress and the egress router.
for (b) it is benefitial to provide support that intermediate nodes do not
particate in the signaling exchange for the per-flow signaling message. 

this can be accomplished for example by addressing the correct nodes (which
is not suggested) or to skip intermediate nodes during the discovery
process.

what do you think?  

> If only hop by hop security is available, the 
> carriers NTLP still must process all per VoIP call signaling 
> messages.

if the discovery process does not skip the intermediate nodes (ntlp nodes)
in the carrier network then they are still processed at the ntlp layer
although nslp layer processing might not be required.

taking your firewall example from above you would also protect the
end-to-end signaling messages in the carrier network. if the ntlps in the
carrier process the signaling messages then some people might argue that you
need protection between the nslp nodes. this is clearly not end-to-end
protection but not as simple as peer-to-peer protection since you would need
to discover the two nslps which communicate over a number of ntlps which
requires discovery at the nslp layer. security protection can only be
provided at the application layer in this case (e.g. cms). 

hence my suggestion: 
- skip intermediate nodes. do not process end-to-end messages at
intermediate nodes at all since it is not necessary. 
- since they are then not participating in the signaling then the security
process can simply skip them. 

ciao
hannes
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Geib, Ruediger" <[email-masked]>
Date: Tue, 4 Mar 2003 09:26:24 +0100

Hello Hannes,

again, comments in line.

Regards, Rüdiger

|R> If I remember right, we agreed on the Interim that NTLP
| > is processing all NTLP messages regardless of local NSLP
| > support.
| 
H| i cannot recall this agreement. 
| 
| the scenario would look like: 
| 
| NSLP                       NSLP
| NTLP    NTLP      NTLP     NTLP
|  A       B         C        D 
| 
| nsis messages would address nodes A, B, C and D although they 
| are processed only by the NSLP? 

R: That's how I understood it.

| > H|this simplifies security handling, refresh message handling 
| > | and reliability handling and provides improvements for
| > | message processing. the drawback is that the discovery
| > | procedure needs to include some capability functionality
| > | (i.e. the discovery message says: "i would like to discover
| > | the next firewall along the path.").
| > 
|R> I'm not sure whether that holds. A domain gateway router 
| > may support QoS-NSLP but no firewall-NSLP. The carrier 
| > may be interested in keeping unauthenticated signaling 
| > messages out of his domain in general. That isn't 
| > possible with your proposal (unless the gateway supports 
| > all NSLPs - which I don't feel to be useful).
| 
| this is an artifically created example. how likely is it that 
| a provider installs a firewall in the middle of the network
| and not at the end. you can also create strange network
| configurations.

I'm not talking UNI, I'm talking NNI. What you call "artificial" 
is called peering router in the company I'm working for. We're 
operating a few of them. Generally I'm not 
contributing to NSIS to solve philosophical problems.
 
H|btw, you would always drop unauthenticated signaling 
| messages. every node which receives signaling messages 
| from the outside should provide authentication and
| authorization. 

Yes.
 
H|to support your scenario you could give the gateway router 
| (qos-nslp) an artificial firewall nslp functionality by
| allowing this node to also particate in firewall-nslp
| signaling although firewall functionality (i.e.
| packet filter installation) is not provided.

The peering router definitely isn't the place where to add useless
features. I'm favouring a good protocol design instead of 
patchwork.
  
|R> Finally, my example. Lets assume a customer network with two
| > sites, making a QoS reservation to be used for VoIP calls 
| > accross a carrier network. To limit his backbone signaling 
| > processing requirements the carrier may prefer to stay out 
| > of per VoIP call signaling. So aggregation is applied between 
| > his edge nodes. Let's ignore how that is done with regard to 
| > QoS. With regard to signaling it means that the carrier 
| > routers only maintain state for a single reservation between 
| > the two customer sites. Per VoIP call NSIS state maintenance 
| > is restricted to the customer domain. Still, all related NSIS 
| > signaling messages traverse the carrier network. Path coupled, 
| > meaning NSIS path coupled (i.e. downstream and especially 
| > upstream).  Correct?  
| 
H|i try to summarize what you just said without voip terminology:
| 
| a) aggregation in the core network - signaling for this region
| b) per-flow signaling messages should be hidden in the core 
| 
| is this right?

Absolutely.

H|to provide (a) a protocol would need to start and end 
| anywhere. in this case between the ingress and the egress
| router.
| for (b) it is benefitial to provide support that intermediate 
| nodes do not particate in the signaling exchange for
| the per-flow signaling message. 
| 
| this can be accomplished for example by addressing the 
| correct nodes (which is not suggested) or to skip
| intermediate nodes during the discovery process.
| 
| what do you think?  

I'm favouring skipping. However NTLP message authentication 
must work.
 
|R> If only hop by hop security is available, the 
| > carriers NTLP still must process all per VoIP call signaling 
| > messages.
| 
H|if the discovery process does not skip the intermediate nodes 
| (ntlp nodes) in the carrier network then they are still
| processed at the ntlp layer although nslp layer processing
| might not be required.
| 
| taking your firewall example from above you would also protect the
| end-to-end signaling messages in the carrier network. if the 
| ntlps in the carrier process the signaling messages then some
| people might argue that you need protection between the nslp
| nodes. this is clearly not end-to-end protection but not as
| simple as peer-to-peer protection since  you would need
| to discover the two nslps which communicate over a number of 
| ntlps which requires discovery at the nslp layer. security
| protection can only be provided at the application layer in
| this case (e.g. cms). 
| 
| hence my suggestion: 
| - skip intermediate nodes. do not process end-to-end
|   messages at intermediate nodes at all since it is
|   not necessary. 
| - since they are then not participating in the signaling then
|   the security process can simply skip them. 

Allright with me. To some it up, we need a discovery protocol 
and a security mechanism working from A to B, only knowing 
that A and B support the same NSLP. The latter may not be 
simple and I'd favour an attempt distinguishing various 
architectures: say A and B may be part of the same 
Intranet, Extranet and finally Internet. The reason for 
that is if A and B belong to the same Intranet, their 
security architecture may be the same. A security/trust
relation between both of them may exist or be established
easily. That can't be assumed if A and B are any two hosts
connected to the Internet.
_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 4 Mar 2003 10:46:23 +0100

hi ruediger

> contributing to NSIS to solve philosophical problems.

good to hear that. 

> | from the outside should provide authentication and

i guess we have agreement on the security protection for messages comming
from the outside. 

> features. I'm favouring a good protocol design instead of 

i share your view. i am also in favor of an approach which skips nsis nodes
which have nothing todo with the signaling processing. a good place to add
such a functionality is in the discovery phase. 

> I'm favouring skipping. However NTLP message authentication 

i also agree with you. 

security at the ntlp has a number of advantages (epecially if you use
channel security). 

> connected to the Internet.

whether a node is from your local network can be derived from the ip
address/fqdn. the edge has to know that it is a edge.

to differentiate at the discovery phase between Intranet, Extranet and
finally Internet is difficult. this requires some scoping -> see ipv6
discussions. 

ciao
hannes