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

From: [email-masked]
Date: Mon, 23 Feb 2004 11:18:08 -0600

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.

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.

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.

> 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.

> 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.

Thank you,

Franck 

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