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

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 23 Feb 2004 13:36:28 +0100

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 will add this issue to our issue tracker. 

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

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

the term "overbilling attack" is already used in the 3gpp for a different
context but i agree that there might be a problem (particularly if you pay
for receiving traffic). 

> 
> References:
> 
> A protocol such as the NSLP could help solving some of the 
> problems identified in draft-le-mip6-firewalls-00.txt. As a 
> suggestion, this draft could be referred to, to complement 
> the use cases of this protocol, and the problems/challenges 
> this protocol could help solving (section 3)

thanks for pointing to this draft.

ciao
hannes

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

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