Re: [pcp] strengthening PCP with Mapping Nonce

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: Zhangzongjian (Thomas) [mailto:[e-mail]]
> Sent: Wednesday, August 22, 2012 12:59 AM
> To: Dan Wing; [e-mail]
> Cc: 'Stuart Cheshire'
> Subject: RE: [pcp] strengthening PCP with Mapping Nonce
> 
> Dear wing
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Dan
> > Wing
> > Sent: Saturday, August 18, 2012 8:51 AM
> > To: [e-mail]
> > Cc: 'Stuart Cheshire'
> > Subject: [pcp] strengthening PCP with Mapping Nonce
> >
> > We incorporated changes to draft-ietf-behave-pcp-base from IESG
> review.
> >
> > After reading the PCP restrictions in REQ-9-A through E in
> > draft-ietf-behave-lsn-requirements-09 (copied below for reference),
> we had a
> > productive phone call this week between Stuart Cheshire, Simon
> Perreault,
> > Sam Hartman, and myself.  During that discussion, we found a way to
> > strengthen security of PCP against a specific attack and hopefully
> soften
> > some of the restrictions in both draft-ietf-behave-lsn-requirements
> (REQ-9-A
> > through E) and draft-ietf-pcp-base for the PCP Basic Threat Model,
> when PCP
> > is not using authentication.
> >
> > To achieve this, we need to improve how draft-ietf-pcp-base handles
> Mapping
> > Nonce values.  Currently, draft-ietf-pcp-base is pretty silent on how
> and
> > when the PCP client chooses its Mapping Nonce value, and says this
> about
> > server processing, which sort of implies the PCP client is free to
> change
> > the Mapping Nonce value whenever it likes,
> > http://tools.ietf.org/html/draft-ietf-pcp-base-26#section-11.3,
> >
> >    The PCP server only needs to remember one Mapping Nonce value for
> >    each mapping (that is, the most recent Mapping Nonce value
> overwrites
> >    the previous Mapping Nonce value).
> >
> > We would replace the above text with something like:
> >
> >    If the Internal port, Protocol, and Internal Address match an
> >    existing explicit dynamic mapping, but the Mapping Nonce does not
> >    match, the request MUST be rejected with a NOT_AUTHORIZED error
> with
> >    the Lifetime of the error indicating duration of that existing
> >    mapping.  The PCP server only needs to remember one Mapping Nonce
> >    value for each explicit dynamic mapping.
> >
> > with this change (and corresponding text for the PCP client's
> generation of
> > a Mapping Nonce, and corresponding text for PEER), we avoid the
> attack
> > described in detail below.
> >
> >
> > Attack:  The attack is a traffic-stealing attack.  The diagram below
> may
> > help with the textual description.  The attack scenario is where
> there is a
> > CGN running PCP and a home NAT not running PCP, and two hosts on
> separate
> > networks behind the same home NAT.  The hosts are on separate
> networks.
> > One
> > host is running a server (the victim) on the wired network, the other
> host
> > is the attacker on the guest Wi-Fi network.  The host running the
> server has
> > a mapping created in the NAT, which was created with UPnP IGD or
> created
> > manually, and has a PCP-created mapping in the CGN.  The attacker
> uses
> > UPnP
> > IGD, NAT-PMP, STUN (RFC5389), or STUNT
> > (http://nutss.gforge.cis.cornell.edu/stunt.php) to create a mapping
> in the
> > home NAT and learn the home NAT's "WAN" address.  The attacker
> > formulates a
> > PCP MAP request with the NAT's WAN address in the PCP Client IP
> Address
> > field, Lifetime=0, and sends that to the CGN, deleting the CGN's
> existing
> > mapping that goes to the victim machine.  That attack packet is sent
> without
> Thomas=>
> Why does not the home NAT use the third party option?

In the above attack scenario, the home NAT does not support PCP at
all.

And, if it did, there is no need for THIRD_PARTY if all traffic
is NAT'ed to one IP address, as typically occurs with a residential
NAT.

-d

> When home NAT receives a PCP MAP request with lifetime=0 from attacker,
> it should add a third party option with the attacker's IP address in
> this option. When CGN gets the PCP request, it will use the third party
> option address as the source address to search the MAP entries. Then
> the attacker can't delete the MAP entry created by victim.
> 
> 
> > address spoofing.  120 seconds later (per REQ-8 of
> > draft-ietf-behave-lsn-requirements-09), the attacker sends a new PCP
> MAP
> > request to try to acquire the (old) mapping of the victim host.  In
> this
> > way, the attacker steals incoming traffic intended to go to the
> victim host.
> >
> >
> > Diagram:
> >
> >                   +-------------+    +----------+
> >   attacker -------+             |    |          |
> >   (guest network) |             |    |          |
> >                   |   home NAT  +----+    CGN   +----{Internet}
> >   victim ---------+(without PCP)|    |(with PCP)|
> >   (wired network) |             |    |          |
> >                   +-------------+    +----------+
> >
> >
> > Please provide us feedback.  I expect to publish -27 soon with these
> > changes, but we are doing some text coordination before publishing -
> 27.
> >
> > -d
> >
> > -----
> >
> >    REQ-9:  A CGN MUST implement a protocol giving subscribers
> explicit
> >            control over NAT mappings.  That protocol SHOULD be the
> Port
> >            Control Protocol [I-D.ietf-pcp-base], in which case the
> PCP
> >            server MUST obey the following constraints on its
> behavior:
> >
> >            A.  It MUST NOT permit the lifetime of a mapping to be
> >                reduced beyond its current life or be set to zero
> >                (deleted).
> >
> >            B.  It MUST NOT permit a NAT mapping to be created with a
> >                lifetime less than the lifetime used for implicit
> >                mappings.
> >
> >            C.  It MUST NOT support the THIRD_PARTY option except for
> >                requests received from "trusted" sources where it is
> >                impractical for those sources to be spoofed.
> >
> >            D.  The MAP opcode MAY be permitted if the recommendation
> > of
> >                endpoint independent filtering behavior described in
> >                REQ-7 is adopted; the map opcode MUST NOT be permitted
> > in
> >                other circumstances.  These constraints MAY be relaxed
> if
> >                a security mechanism consistent with PCP's Advanced
> >                Threat Model (see Section 17.2 of [I-D.ietf-pcp-base])
> is
> >                used; this is expected to be rare for CGN deployments.
> >
> >            E.  Mappings created by PCP MUST follow the same
> deallocation
> >                behavior (REQ-8) as implicitly mapped traffic.
> >
> >
> > _______________________________________________
> > pcp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/pcp
> 
> Best regards
> Thomas