[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,
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