Subject: RE: [NSIS] draft-ietf-nsis-nslp-natfw-01

From: Tschofenig Hannes <[email-masked]>
Date: Tue, 24 Feb 2004 10:48:35 +0100

hi franck, 

thanks for your quick response: please find my comments inline:

> Hello Tschofenig,
> 
> Thank you for your replies. Please find some comments below,
> 
> > -----Original Message-----
> > From: ext Tschofenig Hannes [mailto:[email-masked]]
> > Sent: 23 February, 2004 06:36 AM
> > To: Le Franck (Nokia-NRC/Dallas); [email-masked]
> > Subject: RE: [NSIS] draft-ietf-nsis-nslp-natfw-01
> > 
> > 
> > hi frank, 
> > 
> > thanks for reading the document. please see my comments inline:
> > 
> > > Hello,
> > > 
> > > I read the NAT/Firewall NSIS Signaling Layer Protocol (NSLP) 
> > > (draft-ietf-nsis-nslp-natfw-01) and the problems as well as 
> > > the scenarios are well described.
> > thanks a lot. 
> > 
> > > 
> > > I would have some comments:
> > > 
> > > Technical comments:
> > > 
> > > 1) Looking at the Protocol Description (section 5), it is not 
> > > clear if it is currently supported or not, but it would be 
> > > useful if in addition to opening pinholes in the firewall, 
> > > the protocol could also allow to install filters in the 
> > > firewall. This would e.g. allow undesired packets to be 
> > > dropped in the network, before being forwarded over the 
> > > access link to the end nodes. This can more particularly be 
> > > useful in access networks with limited bandwidth access links.
> > 
> > our approach currently is that we start with a "deny all" 
> > policy and then
> > open pinholes for allowed traffic. 
> > your approach seems to be the other way aroung. similar as in 
> > midcom we had
> > concerns with "deny packet filters" since conflict 
> resolution is more
> > difficult. 
> 
> I agree that starting with a "deny all" policy and then 
> opening the required pinholes is more secure.
> Also combining "opening rules" and "closing rules" may be 
> difficult to manage.
> However, I was thinking that adding more flexibility to the 
> protocol would allow it to support the needs of more 
> scenarios, and therefore may make it adopted and deployed in 
> more environments.

that's certainly a good idea to look at other scenarios as well. do you have
a more detailed description of these scenarios so that we can take a closer
look at the requirements?

> 
> The default policy rules may e.g. allow some types of traffic 
> to pass the firewalls but the user does not need this 
> service. It may prefer to drop these packets at the network 
> not to waste the limited bandwidth access link resources.
> 
> > i will add this issue to our issue tracker. 
> 
> Ok, thank you.
> 
> > > 2) As another feature that could be useful, the node may be 
> > > behind a NAT and may want to reserve a public address. 
> > > However the node may not yet know the IP address of its 
> > > correspondent nodes to send the NSLP request to. E.g. this 
> > > could be the case when the node wants to receive incoming 
> > > requests (for P2P applications, Web server, etc.). The node 
> > > may also be behind a firewall, and  similarly, the node may 
> > > want to open the appropriate pinholes in the firewall to 
> > > accept incoming requests. So to summarize, it would be useful 
> > > if the node could open pinholes in the firewall, and/or make 
> > > reservation for a public IP address in a NAT without knowing 
> > > the IP address of the data sender (the node may not know it 
> > > yet), nor the IP address at the Application Server (there may 
> > > not be any Application Server) (section 4.2.1).
> > 
> > you are right. we should add this to the draft. thanks. 
> 
> Ok, thanks.
> 
> > > 3) Finally it seems that the draft requires the firewall to 
> > > forward some of the messages (such as the create one) without 
> > > performing any authentication on them. Such requirement may 
> > > present security issues since a malicious node may send many 
> > > of these messages and flood a node behind the firewall. Also 
> > > this may result in an overbilling attack in access networks 
> > > where data is charged by packet volume since the victim has 
> > > to pay for the access link utilization (delivery of these 
> > > unsolicited messages over the access link to the node).
> > 
> > in some scenario it was difficult to have authorization by 
> one of the
> > parties. authentication and signaling message security is 
> > still there. 
> > 
> > in the internet, in general, it is difficult to prevent 
> > someone from sending
> > you traffic. for ip based packet filter you cannot fully 
> > avoid that someone
> > sends packets to you since there is no cryptographic 
> > protection of the data
> > traffic. 
> 
> I agree with your comments. However current firewall 
> technology allows to drop unsolicited incoming traffic.
> Typically incoming packets are only allowed to pass the 
> firewalls if the connection was initiated by the node 
> protected (i.e. behind the firewall). This allows to block 
> flooding (e.g. UDP) by malicious nodes.

i have read your draft and you refer to firewalls performing stateful
inspection. 
if both end hosts are behind such firewalls then there is a problem if you
require both hosts to start first. for the nat case this is also difficult
and requires the data receiver to start signaling first (i.e., to create a
nat binding) but the firewall case is more complicated since you might
create state at a firewall which is subsequently not used for the incoming
data traffic. this means that the end host would have to know the topology. 

> 
> What I was trying to say is that requiring the firewall to 
> forward the unsolicited nslp messages before performing any 
> authentication may allow malicous nodes to flood the nodes 
> behind the firewalls, threat that is more difficult to execute today.

we are not trying to have the messages unprotected. it is only the problem
that they are unauthorized. you can compare this to the qos signaling case
where you would create a qos reservation without knowing where to get the
money from. to address this issue we suggested to require that both nodes
have to contribute to the authorization. 

i will show you an example (from section 3.1 of
draft-ietf-nsis-nslp-natfw-01):

   +----------------------+              +--------------------------+
   |                      |              |                          |
   |          Network A   |              |              Network B   |
   |                      |              |                          |
   |            +---------+   Missing    +---------+                |
   |      +-///-+ Middle- |    Trust     | Middle- +-///-+          |
   |      |     |  box 1  |   Relation-  |  box 2  |     |          |
   |      |     +---------+     ship     +---------+     |          |
   |      |               |     or       |               |          |
   |      |               | Authorization|               |          |
   |      |               |              |               |          |
   |      |   Trust       |              |      Trust    |          |
   |      | Relationship  |              |  Relationship |          |
   |      |               |              |               |          |
   |      |               |              |               |          |
   |      |               |              |               |          |
   |   +--+---+           |              |            +--+---+      |
   |   | Host |           |              |            | Host |      |
   |   |  A   |           |              |            |  B   |      |
   |   +------+           |              |            +------+      |
   +----------------------+              +--------------------------+

suppose we both want to communicate (host a and host b). now, middlebox 1
and middlebox 2 can certainly protect signaling messages (inter-domain) but
why should network b trust network a to install packet filters (they are,
for example, different companies). network b might not even know host a -
authentication would not be very helpful in this case. 

what you can do is to authorize packet filter creation locally at network a
(authorized by host a) and in network b (authorized by host b). since we
have path-coupled signaling it is necessary to perform this step end-to-end
rather than locally. 

> 
> > the term "overbilling attack" is already used in the 3gpp for 
> > a different
> 
> Thank you for pointing this out. I actually re-used the term 
> "overbilling" since as in 3gpp, the attack results in the 
> victim having to pay for packets it has not requested for.

ok. i guess nsis nat/fw nslp could be used in this area. 

i tried to add this issue to the issue tracker but you mentioned several
issues here: 
- the overbilling attack: nsis could be helpful to address the overbilling
attack to some extend (as a solution). 
- nsis message authentication: i hope i was able to describe that we
authenticate signaling messages. we should actually be more specific which
entity we want to authenticate since a number of nodes are involved in nsis
signaling. 
- authorization issues: we described a few possible solutions in the draft.
currently we favor one where both nodes contribute to the authorization
decision but this is certainly subject to discussion. 

> 
> > context but i agree that there might be a problem 
> > (particularly if you pay
> > for receiving traffic). 
> 
> May be, it can be useful to describe it in the "security 
> consideration" section.

that's true. 

i have read your draft <draft-le-mip6-firewalls-00.txt>. i agree with the
issues in the draft and i think that nsis nat/fw signaling could be helpful
there. 
a reference to your draft (and some discussions) would certainly fit into
the migration draft. i think you could add a discussion of the symmetric
nats in your description since the problems are similar. maybe a reference
to <draft-savola-v6ops-firewalling-01.txt> would not hurt. 

ciao
hannes

> Thank you,
> Franck 

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