[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [NSIS] New NATFW NSLP I-D: draft-ieft-nsis-nslp-natfw-02.txt
Hello Martin,
Thank you for your comments and clarification.
Please find some additional questions below.
> -----Original Message-----
> From: ext Martin Stiemerling [mailto:stiemerling at netlab.nec.de]
> Sent: 21 June, 2004 07:14 AM
> To: Le Franck (Nokia-NRC/Dallas); nsis at ietf.org
> Subject: RE: [NSIS] New NATFW NSLP I-D:
> draft-ieft-nsis-nslp-natfw-02.txt
>
>
> Hi Frank and NSIS working group,
>
> I have to apologize for replying so late to the emails, but I
> have been
> away from email for some time.
>
> --On Montag, 24. Mai 2004 13:40 Uhr -0500 Franck.Le at nokia.com wrote:
>
> | Hello,
> |
> | Many deployment scenarios had been analyzed in details and
> important key
> | issues had also already been identified and described in
> the previous
> | version of the document. This new version of the document seems in
> | addition more structured.
>
> Thanks :-)
>
> |
> | I would have some questions to better understand the protocol, some
> | comments and some suggestions.
> |
> | 1) Questions:
> |
> | a) How are the information (e.g. protocol type, port
> numbers) relating to
> | the pinholes to be opened in the firewalls carried and
> described? The
> | previous version described some Policy Rule Object. The new
> version of
> | the document provides more details on the other objects
> (e.g. Session ID
> | object, Session Lifetime Object, External address object,
> etc.) but does
> | not seem to explain how the information related to the pinholes are
> | carried.
>
> Indeed, the previous version (-01) described the policy rule
> object more
> detailed. The policy rule object kept information about the
> data flow and
> actually just kept the same information as carried in the NTLP. So we
> stripped the policy rule object to minimum. The current idea,
> not fully
> explained in the document, is to carry additional information
> in the policy
> rule object only. Additional information is, for instance, number of
> subsequent port numbers to opened.
Ok, thank you for the clarification. I was wondering if we would not prefer to keep the information related to the pinholes separated from the NTLP layer. This would allow more flexibility for the rules (e.g. several rules could be created per message). Also, as it was proposed in the TIST (Topology-Insensitive Service Traversal) Protocol proposal, a FW object could specify the firewall rules to be created: this would allow to specify the rules based on netmask, indicate the action to be taken (ALLOW/DROP) and include the TCP flags or other parameters.
Each FW object would correspond to one firewall rule.
> |
> | b) In section "A.1 Missing Network-to-Network Trust
> Relationship", it is
> | stated that "Possibly peer-to-peer trust relationship does not exist
> | because of the large number of networks and the unwillingness of
> | administrators to have other network operators to create
> holes in their
> | firewalls without proper authorization. Hence in the
> following scenario
> | we assume a somewhat different message processing and show
> three possible
> | approaches to tackle the problem. None of these three approaches is
> | without drawbacks or constraining assumptions." but the
> three approaches
> | description seems to be missing, unless I missed some part? Is that
> | correct? Could you please describe them?
>
> Thanks for pointing this out. Section A.1 is one that has
> been moved during
> the document restructering. I have to check this in detail.
>
> |
> | 2) Suggestions
> |
> | a) As described in sections 1 and 2, a protocol to open
> pinholes can be
> | very useful. It can help to open the required dynamic
> pinholes e.g. for
> | SIP based applications. Actually it can also solve some of
> the problems
> | that exist between the Mobile IP protocols and firewalls.
> Should we add
> | this use case and add a reference to
> | http://www.ietf.org/internet-drafts/draft-le-mip6-firewalls-00.txt?
>
> Give me some time read it first and I will come back to this.
>
> |
> | b) The NSLP protocol allows an end point to open pinholes
> in firewalls.
> | Should this protocol also support the capability for end
> points to open
> | pinholes in the scenarios where the end points do not know the
> | correspondent nodes yet?
>
> This is in theory already applicable to the NATFW NSLP, but
> gives some
> problems. NSLP-wise this means that the flow information must
> be partially
> incomplete, in other words the source IP address for incoming
> flows must be
> wildcarded. So using 'reserve-create' with source IP address
> for incoming
> flow wildcarded would be your friend.
I agree with you. I was wondering if we wanted to further describe this scenario in the draft: e.g. where should the NSLP messages be sent to?
> |
> | This can be useful e.g. when an end point is in a network
> protected by a
> | firewall and would like to host a server (e.g. HTTP) or run some
> | peer-to-peer applications. Currently most firewalls would drop
> | unsolicited incoming requests. Since NSLP is already
> allowing pinholes
> | creation, I was thinking that it could be useful to extend the NSLP
> | feature to support these scenarios.
> |
> | The 3GPP2 Network Firewall Configuration and Control (NFCC)
> work will
> | probably study solutions to allow unsolicited incoming
> packets to reach
> | the protected nodes and having the NSLP support such
> features can make
> | this protocol to be adopted by 3GPP2.
> |
> | c) The NSLP protocol allows an end point to configure
> packet filters in a
> | firewall (by creating, deleting and prolonging policy
> rules). Should the
> | protocol allows an end point not only to open pinholes but also to
> | install packets filters in the firewalls?
> |
> | The default policy may e.g. allow ICMP messages to reach
> the nodes but
> | the end point may be in a cellular network where the air
> interface is a
> | limited and expensive resource. The node may prefer not to
> receive Ping
> | messages. Such capability would thus allow the nodes to install the
> | desired packet filters in the firewalls so that undesired
> data are not
> | sent over the air interface but dropped in the network.
> This is only an
> | example of the possible use cases.
>
> OK, now I see, that's what you have mentioned during the interim.
> This is a question to working group, I'll try to summarize this in a
> separate email.
>
>
> |
> | 3) Comments
> |
> | a) Overbilling: the document seems to require middleboxes
> to forward NSLP
> | messages. This may however be used by malicious nodes to
> flood a victim,
> | and force, as in the 3GPP overbilling attack, the victim to pay for
> | undesired received data. This may not be acceptable especially in
> | cellular networks where the air interface is limited and
> subscribers have
> | to pay for the bytes sent over the access link. Would it be
> possible to
> | have the sender sign the NSLP messages and have the
> firewalls verify the
> | authenticity before forwarding them? Or should we at least
> describe the
> | threat in the security consideration?
>
> You are right, NATFW NSLP must forward messages, and this
> might result in
> malicious nodes flooding NATFW NSLP nodes.
>
> This issues is currently under discussion in
> draft-fessi-nsis-natfw-threats-00.txt.
>
> Thanks for the comments,
>
> Martin
>
>
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis