[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [NSIS] new draft about security threats for the NAT/firewall NSLP
Hi Hannes,
Thank you for your reply.
> > I agree with you that similar problem may exist with other
> protocols.
> > However, the damages that can be caused by the NAT FW NSLP
> > protocol can be more important since the NAT FW NSLP allows
> > the end node to open any
> > ports/pinholes: if the external node and the node within the
> > network protected by the firewall are complices, they might
> > create the pinholes and specify the ports to launch attacks
> > to future victims.
>
> i would like to avoid giving other people the perception that we are
> creating a protocol which introduces new threats and attacks
> which are not
> available today. we are not introducing new vulnerabilities with the
> nat/firewall nslp. i think my ipsec example showed this. we
> are additionally
> not able to overcome the limitations of packet filters (if we
> only signal
> packet filters).
I agree that with current protocols, similar problems can occur: a node protected behind a firewall may do web browsing with a node in the external network. The pinholes (for HTTP) needs to be created in the firewall (upon detection of the inner node's HTTP request). If the inner node disconnects abruptly, the pinholes in the firewall remain until the lifetime expire.
The pinholes were however created specifically for HTTP, whereas I am afraid that with NAT FW NSLP, if the inner and outer nodes are complices, they may open pinholes for some specific ports that can then be used to launch other attacks. The pinholes can be created for the ports the malicious nodes want, and to launch attacks against nodes that may later come in the network protected by the firewall (the inner and outer nodes create the pinholes, and then the inner node disconnects without sending a delete message, but leave the pinholes in the firewall).
I was thinking that today, if one wants to open specific ports in the firewall to launch some attacks to future visitors(e.g. spread viruses, use Torjan horses), it is difficult if not, not possible.
I hope this clarifies the scenarios I had in mind.
Could you please elaborate your example with IPsec?
> it is good to document this threat. after we listed all the
> threats we need
> to think which threats are important to us and how we address them.
> therefore we will derive a few security requirements and decide how to
> provide security mechanisms at the nat/firewall nslp.
I agree.
> > Such pinholes can be used to spread
> > viruses, trojan horses or other malicious attacks.
> the nat/firewall work cannot provide protection against those attacks.
> however, other protocols cannot provide this capability either.
Yes. I was not asking the NAT FW NSLP to protect against such attacks, but I was just saying that the NAT FW NSLP might allow such threats and was therefore suggesting to document it. As mentioned in the previous e-mail, networks which deploy NAT FW NSLPs can then adopt different methods to prevent these attacks.
Franck
> > Also the NAT FW protocol allows the end points to specify the
> > lifetime of the pinholes which may be set to an extended value.
> yes, but the network nodes are allowed to modify the
> lifetime. this is part
> of the authorization decision computed.
>
> ciao
> hannes
>
> >
> > Would you agree?
> >
> > Franck
> >
> > > -----Original Message-----
> > > From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig at siemens.com]
> > > Sent: 08 June, 2004 11:14 AM
> > > To: Le Franck (Nokia-NRC/Dallas)
> > > Cc: nsis at ietf.org
> > > Subject: RE: [NSIS] new draft about security threats for the
> > > NAT/firewall NSLP
> > >
> > >
> > > hi franck,
> > >
> > > i think it could be useful to add this issue to the threats
> > document.
> > > it would, however, be fair to state that it might be an
> issue with
> > > other protocols as well.
> > >
> > > ciao
> > > hannes
> > >
> > > > Hi Hannes,
> > > >
> > > > I agree with you that the data sender can detect when the data
> > > > receiver is replaced. However the data sender may be a
> malicious
> > > > node with bad intentions, and therefore may decide not to stop
> > > > sending data but may take advantage of the pinholes to
> > launch some
> > > > attacks on the victim.
> > > >
> > > > For the solutions, I was not suggesting any specific one.
> > > > Actually, depending on the network environment, different
> > solutions
> > > > can most probably be adopted: if a network entity can
> detect that
> > > > the previous data receiver has disconnected and released the IP
> > > > address (e.g. in 3G networks), the network entity could
> > inform the
> > > > firewall which will remove the pinholes.
> > > >
> > > > But again, I was not suggesting any specific solution. I
> > was instead
> > > > wondering if such threat should be documented so that
> people who
> > > > decide to deploy NAT FW NSLP can be aware of the
> > potential threats
> > > > and analyze solutions to prevent them.
> > > >
> > > > Franck
> > > >
> > > > > -----Original Message-----
> > > > > From: ext Hannes Tschofenig
> > [mailto:Hannes.Tschofenig at siemens.com]
> > > > > Sent: 08 June, 2004 02:21 AM
> > > > > To: Le Franck (Nokia-NRC/Dallas)
> > > > > Cc: nsis at ietf.org
> > > > > Subject: RE: [NSIS] new draft about security threats for the
> > > > > NAT/firewall NSLP
> > > > >
> > > > >
> > > > > hi franck,
> > > > >
> > > > > i agree with you that this is a possible threat.
> > > > >
> > > > > how imagine nsis uses where the data receiver does not
> > > support nsis
> > > > > (only the initiator and the firewall). the same situation
> > > can occur
> > > > > but this scenario shows more similarities with ipsec usage:
> > > > >
> > > > > NSIS ------------> NSIS -----------> Data
> > > > > Initiator Firewall Receiver
> > > > > = IKE = IKE
> > > > > Initiator Responder
> > > > >
> > > > > now, if the data receiver is replaced by some other
> > entity (as you
> > > > > described) then the data sender will just no recognize it.
> > > > > application layer
> > > > > interaction, however, will reveal this issue.
> > > > >
> > > > > the solution to this "problem" is: use end-to-end
> > protected data
> > > > > traffic.
> > > > > this cannot be provided by nsis.
> > > > >
> > > > > ciao
> > > > > hannes
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Franck.Le at nokia.com [mailto:Franck.Le at nokia.com]
> > > > > > Sent: Montag, 07. Juni 2004 16:09
> > > > > > To: Tschofenig Hannes
> > > > > > Cc: nsis at ietf.org
> > > > > > Subject: RE: [NSIS] new draft about security
> threats for the
> > > > > > NAT/firewall NSLP
> > > > > >
> > > > > > Hi Hannes,
> > > > > >
> > > > > > Thank you for your comments.
> > > > > >
> > > > > > In addition to the potential threat discussed below, I
> > > > was wondering
> > > > > > if the following scenario, which does not seem to be
> > > described in
> > > > > > the draft, may represent another threat or not:
> > > > > >
> > > > > > An external node in the Internet (node 1) may send a
> > > > Create message
> > > > > > to a node (node 2) protected by a firewall. Node 2 may
> > > > reply with a
> > > > > > Path Succeeded that will create the rules in the firewall
> > > > (or vice
> > > > > > versa i.e.
> > > > > > node 2 sends the Create message and node 1 replies with
> > > the Path
> > > > > > Succeeded message).
> > > > > >
> > > > > > Node 2 may then disconnect from the network (e.g. for
> > mobility
> > > > > > reasons, or deliberately) without sending a Delete message.
> > > > > >
> > > > > > The pinholes may therefore remain in the firewall until the
> > > > > > expiration time which may be long.
> > > > > >
> > > > > > If a node (node 3) arrives in the network protected by
> > > > the firewall,
> > > > > > it may be assigned the IP address previously allocated
> > > to node 2.
> > > > > > The external node (node 1) may then take advantage of the
> > > > pinholes
> > > > > > in the firewall to flood node 3, or launch other
> > > attacks against
> > > > > > node 3, depending on the installed firewall rules.
> > > > > >
> > > > > > Would you agree that this scenario can represent a threat?
> > > > > > Should it also be documented?
> > > > > >
> > > > > > Franck
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: ext Hannes Tschofenig
> > > > [mailto:Hannes.Tschofenig at siemens.com]
> > > > > > > Sent: 30 May, 2004 02:42 PM
> > > > > > > To: Le Franck (Nokia-NRC/Dallas); ali.fessi at netlab.nec.de
> > > > > > > Cc: nsis at ietf.org
> > > > > > > Subject: RE: [NSIS] new draft about security
> > threats for the
> > > > > > > NAT/firewall NSLP
> > > > > > >
> > > > > > >
> > > > > > > hi franck,
> > > > > > >
> > > > > > > you are right with your observation that we have
> envisioned
> > > > > > scenarios
> > > > > > > where the nsis nat/firewall signaling message needs to
> > > > > traverse the
> > > > > > > firewall to allow both endpoints to authorize the creation
> > > > > > of policy
> > > > > > > rules. this circumstance might be exploited for the
> > > attack you
> > > > > > > mentioned.
> > > > > > >
> > > > > > > regarding your reference to the "3GPP2 Network Firewall
> > > > > > Configuration
> > > > > > > and Control specification" document. i remember that this
> > > > > document
> > > > > > > focused on scenarios which go beyond the functionality
> > > > currently
> > > > > > > offered by the current nat/fw nslp specification. it might
> > > > > > be useful
> > > > > > > to see where nsis could be helpful.
> > > > > > >
> > > > > > > ciao
> > > > > > > hannes
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Franck.Le at nokia.com [mailto:Franck.Le at nokia.com]
> > > > > > > > Sent: Samstag, 29. Mai 2004 00:00
> > > > > > > > To: ali.fessi at netlab.nec.de
> > > > > > > > Cc: nsis at ietf.org
> > > > > > > > Subject: RE: [NSIS] new draft about security
> > > threats for the
> > > > > > > > NAT/firewall NSLP
> > > > > > > >
> > > > > > > > Hello Ali,
> > > > > > > >
> > > > > > > > Thank you for your reply.
> > > > > > > >
> > > > > > > > I agree with you that a malicous node who wants to
> > > > exhaust the
> > > > > > > > battery and the network resources of a victim can use
> > > > > any type of
> > > > > > > > traffic to flood the victim. Most firewalls typically
> > > > > > block incoming
> > > > > > > > unsolicited data in order to avoid such threat.
> > > > > > > > (Unsolicited messages can actually create more
> damages in
> > > > > > cellular
> > > > > > > > networks as outlined in the 3GPP2 Network Firewall
> > > > > > Configuration and
> > > > > > > > Control specification).
> > > > > > > >
> > > > > > > > The natfw-nslp, on the contrary, require firewalls to
> > > > > forward the
> > > > > > > > nslp messages.
> > > > > > > > Such requirement may therefore open the door for
> > flooding.
> > > > > > > > Since this requirement is specific of natfw-nslp and
> > > > > > because of such
> > > > > > > > requirement, this type of attack is possible, I was
> > > > thinking it
> > > > > > > > could useful to report the threat in the "Security
> > > > > > Threats for the
> > > > > > > > NAT/Firewall NSLP" draft or at least in the security
> > > > > > consideration
> > > > > > > > of the "NAT/Firewall NSIS Signaling Layer Protocol
> > > > > (NSLP)" draft.
> > > > > > > >
> > > > > > > > Would you agree?
> > > > > > > >
> > > > > > > > Franck
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: ext Ali Fessi [mailto:ali.fessi at netlab.nec.de]
> > > > > > > > > Sent: 28 May, 2004 02:13 PM
> > > > > > > > > To: Le Franck (Nokia-NRC/Dallas)
> > > > > > > > > Cc: nsis at ietf.org
> > > > > > > > > Subject: Re: [NSIS] new draft about security
> > > > threats for the
> > > > > > > > > NAT/firewall NSLP
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Franck,
> > > > > > > > >
> > > > > > > > > thanks for reading the draft and thanks for
> > your feedback.
> > > > > > > > >
> > > > > > > > > We focused the draft on the way how unauthorized users
> > > > > > > > could use the
> > > > > > > > > natfw-nslp to install policy rules for their
> advantage,
> > > > > > > > since this is
> > > > > > > > > our main concern.
> > > > > > > > >
> > > > > > > > > About the threat that you suggested: i think it is not
> > > > > > > specific for
> > > > > > > > > the natfw-nslp. You could flood the victim with any
> > > > > > kind of data
> > > > > > > > > traffic if you want to exhaust his battery or the
> > > > > > > resources of his
> > > > > > > > > access network.
> > > > > > > > > i don't think that this threat fits well in the
> > document.
> > > > > > > > >
> > > > > > > > > ciao, Ali.
> > > > > > > > > --
> > > > > > > > > Ali Fessi
> > > > > > > > > NEC Network Laboratories Kurfürsten-Anlage
> > > 36, D-69115
> > > > > > > > Heidelberg
> > > > > > > > > Phone: (+49) 6221 9051151 Email:
> > > ali.fessi at netlab.nec.de
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Franck.Le at nokia.com wrote:
> > > > > > > > >
> > > > > > > > > >Hello,
> > > > > > > > > >
> > > > > > > > > >Thank you for the internet draft. It is a good
> > > > document that
> > > > > > > > > can be helpful when designing the security
> solutions for
> > > > > > > the NAT/FW
> > > > > > > > > NSLP. Many of the threats have been identified and
> > > > > > described. The
> > > > > > > > > following one is however not mentioned but might be
> > > > > > relevant: The
> > > > > > > > > NAT/FW NSLP requiring firewalls to forward NSLP
> > > messages, a
> > > > > > > > malicious
> > > > > > > > > node may keep sending NSLP messages to a
> > target. This may
> > > > > > > > consume the
> > > > > > > > > access network resources of the victim, drain the
> > > > > > battery of the
> > > > > > > > > victim's terminal and may force the victim to
> > pay for the
> > > > > > > received
> > > > > > > > > although undesired requests (especially in cellular
> > > > networks).
> > > > > > > > > >
> > > > > > > > > >Would you agree with this threat? Should it be
> > > included in
> > > > > > > > > the document as well?
> > > > > > > > > >
> > > > > > > > > >Thank you,
> > > > > > > > > >
> > > > > > > > > >Franck
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >>-----Original Message-----
> > > > > > > > > >>From: nsis-bounces at ietf.org
> > > > > > > > > [mailto:nsis-bounces at ietf.org]On Behalf Of
> > > > > > > > > >>ext Ali Fessi
> > > > > > > > > >>Sent: 25 May, 2004 11:56 AM
> > > > > > > > > >>To: nsis at ietf.org
> > > > > > > > > >>Cc: Martin Stiemerling; Tschofenig Hannes
> > > > > > > > > >>Subject: [NSIS] new draft about security
> > threats for the
> > > > > > > > > NAT/firewall
> > > > > > > > > >>NSLP
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>Dear all,
> > > > > > > > > >>
> > > > > > > > > >>after some discussions within the NAT/firewall
> > > NSLP team,
> > > > > > > > we decided
> > > > > > > > > >>to make a full analysis of the security
> > threats for the
> > > > > > > > NAT/firewall
> > > > > > > > > >>NSLP before we continue.
> > > > > > > > > >>
> > > > > > > > > >>We submitted a new draft "Security Threats for the
> > > > > > > > > NAT/Firewall NSLP".
> > > > > > > > > >>
> > > > > > > > > >>If you want to have a look at it before it becomes
> > > > > > > > available in the
> > > > > > > > > >>I-D repository, please have a look at:
> > > > > > > > > >>
> > > > > > > > >
> > > > >
> >>ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-fessi-nsis-na
> > > > > > > > > >>tfw-threats-00.txt
> > > > > > > > > >>
> > > > > > > > > >>Comments are very welcome!!
> > > > > > > > > >>Thanks,
> > > > > > > > > >>Ali.
> > > > > > > > > >>--
> > > > > > > > > >>Ali Fessi
> > > > > > > > > >>NEC Network Laboratories Kurfürsten-Anlage
> > > > 36, D-69115
> > > > > > > > > Heidelberg
> > > > > > > > > >>Phone: (+49) 6221 9051151 Email:
> > > > ali.fessi at netlab.nec.de
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>_______________________________________________
> > > > > > > > > >>nsis mailing list
> > > > > > > > > >>nsis at ietf.org
> > > > > > > > > >>https://www1.ietf.org/mailman/listinfo/nsis
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > nsis mailing list
> > > > > > > > nsis at ietf.org
> > > > > > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> > _______________________________________________
> > nsis mailing list
> > nsis at ietf.org
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
>
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis