[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,
i'll check if i understand correctly by asking
Is this actually a generic threat which applies to
any firewall configuration method where the network 'behind'
the firewall uses any mechanism for dynamic address
assignment (which could cause addresses to be
re-assigned)?
If so, we should document it (in that form). It may
not be specific to the NATFW NSLP; however, there
may be deployment considerations related to it which
could usefully be captured somewhere (in this case,
I think it would be that there should be some
interdependency between the soft-state lifetime of
the address assignment mechanism and of the NATFW
NSLP state management.)
r.
> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig at siemens.com]
> Sent: 09 June 2004 12:33
> To: Franck.Le at nokia.com
> Cc: nsis at ietf.org
> Subject: RE: [NSIS] new draft about security threats for the
> NAT/firewall NSLP
>
>
> hi franck,
>
> thanks for your quick response.
>
> > Hi Hannes,
> >
> > Thank you for your comments.
> >
> > 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).
>
> 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.
>
> > 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.
>
> > 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
>
_______________________________________________
nsis mailing list
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis