Re: [pcp] strengthening PCP with Mapping Nonce

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

> -----Original Message-----
> From: Zhangzongjian (Thomas) [mailto:[e-mail]]
> Sent: Monday, August 27, 2012 11:59 PM
> To: Dan Wing; [e-mail]
> Cc: 'Stuart Cheshire'
> Subject: RE: [pcp] strengthening PCP with Mapping Nonce
> 
> > If there is a UPnP-PCP interworking function in the CPE router,
> > I would expect the CPE router would prohibit PCP clients within
> > the home from communicating directly with the PCP server in the
> > CGN.  However, the PCP working group has not yet finished the
> > UPnP-PCP document, so I dunno if/how the working group will conclude
> > on this problem.
> >
> It seems strange to prohibit PCP clients from communicating directly
> with PCP server.

Yes, I agree that would be strange.  But the current plan for PCP
proxying has the PCP client only communicate with its local (closest)
PCP server, and not communicate with every upstream PCP server.  So
blocking that communication would be in line with the current plan
for PCP proxying.  However, that current plan for PCP proxying might 
change if it doesn't work properly with PCP authentication or 
with asymmetric routing or some other new problem.

-d


> Sorry, I make a mistake on adding THIRD_PARTY question.
> 
> Regards
> Thomas
> 
> 
> 
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:[e-mail]]
> > Sent: Tuesday, August 28, 2012 1:28 AM
> > To: Zhangzongjian (Thomas); [e-mail]
> > Cc: 'Stuart Cheshire'
> > Subject: RE: [pcp] strengthening PCP with Mapping Nonce
> >
> > > -----Original Message-----
> > > From: Zhangzongjian (Thomas) [mailto:[e-mail]]
> > > Sent: Friday, August 24, 2012 7:22 PM
> > > To: Dan Wing; [e-mail]
> > > Cc: 'Stuart Cheshire'
> > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce
> > >
> > > Dear Wing
> > > Replay on line
> > >
> > > > -----Original Message-----
> > > > From: Dan Wing [mailto:[e-mail]]
> > > > Sent: Saturday, August 25, 2012 12:19 AM
> > > > To: Zhangzongjian (Thomas); [e-mail]
> > > > Cc: 'Stuart Cheshire'
> > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce
> > > >
> > > > > -----Original Message-----
> > > > > From: Zhangzongjian (Thomas) [mailto:[e-mail]]
> > > > > Sent: Friday, August 24, 2012 1:06 AM
> > > > > To: Dan Wing; [e-mail]
> > > > > Cc: 'Stuart Cheshire'
> > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce
> > > > >
> > > > > > In -27, we have tentatively added:
> > > > > >
> > > > > >   When such
> > > > > >   an intervening non-PCP-aware inner NAT is detected,
> mappings
> > > must
> > > > > >   first be created by some other means in the inner NAT,
> before
> > > > > >   mappings can be usefully created in the outer PCP-
> controlled
> > > NAT.
> > > > > >   Having created mappings in the inner NAT by some other
> means,
> > > the
> > > > > PCP
> > > > > >   client should then use the inner NAT's External Address as
> the
> > > > > Client
> > > > > >   IP Address, to signal to the outer PCP-controlled NAT that
> the
> > > > > client
> > > > > >   is aware of the inner NAT, and has taken steps to create
> > > mappings
> > > > > in
> > > > > >   it by some other means, so that mappings created in the
> outer
> > > NAT
> > > > > >   will not be a pointless waste of state.
> > > > > >
> > > > >
> > > > > Dear Wing
> > > > >
> > > > > I think I understand your proposal, but there still are some
> > > questions.
> > > > >
> > > > > 1. How did PCP client (host) detect that there are two levels
> NAT
> > > > > (Inner NAT and Out NAT)?   PCP client need to know this first
> of
> > > all.
> > > >
> > > > It can use UPnP IGD, NAT-PMP, or HTTP screen-scraping to
> communicate
> > > > with the in-home residential NAT and get a mapping.  Then, it can
> > > > use traceroute or some other technique to learn the internal IP
> > > > address of the CGN, and send it a PCP request.
> > > >
> > > Thomas=>
> > > Getting a mapping does not mean there is a inner NAT in CPE.  For
> > > example, the CPE supports UPnP-PCP interworking function.
> >
> > If there is a UPnP-PCP interworking function in the CPE router,
> > I would expect the CPE router would prohibit PCP clients within
> > the home from communicating directly with the PCP server in the
> > CGN.  However, the PCP working group has not yet finished the
> > UPnP-PCP document, so I dunno if/how the working group will conclude
> > on this problem.
> >
> >
> > > Learning the IP address of CGN means there is a CGN, but it does
> not
> > > mean it is the second NAT. it may be the first NAT or the third
> NAT.
> > >
> > >
> > > > >   How could the PCP client know the inner NAT is an unsupported
> PCP
> > > > > device.
> > > >
> > > > It doesn't know, and it doesn't care if the in-home residential
> > > > NAT supports PCP or not.  The attack works as long as the in-home
> > > > residential NAT allows the PCP request from the attacker's IP
> > > > address to the CGN's PCP server address.
> > > >
> > > > > If inner NAT supports PCP, it will find the PCP request is a
> > > > > malformed packet. It may discard the packet as the error packet
> or
> > > > > packet from an attacker.
> > > >
> > > > In the attack scenario, the in-home residential NAT ('inner NAT')
> > > does
> > > > not support PCP.
> > > >
> > > > And, even if it did, the attacker's PCP packet is not being sent
> to
> > > > the in-home residential NAT -- the attacker's PCP packet has a
> > > > destination address that is the PCP server in the ISP's network
> > > > (the CGN).
> > >
> > > Thomas=>
> > > Yes you are right. I mean when inner NAT has PCP proxy function, it
> may
> > > add a third party option. It won't know use source IP address or
> PCP
> > > Client's IP address in request header as the third party option
> value.
> > > PCP proxy may discard the PCP request packet as the illegal packet.
> > > Then the PCP client has to know whether CPE (inner NAT device)
> support
> > > PCP. If CPE does, it can't send the request packet with different
> > > source IP address and PCP Client's IP address. Or else it can do.
> >
> > The inner NAT has no reason to add THIRD_PARTY, because the PCP
> > request would come from the same IP address as the "PCP Client
> > Source IP Address" in the PCP request.  And the current text in
> > pcp-base prohibits it from doing so, anyway.
> >
> >
> > > > >   PCP client also need to know the Out NAT support PCP.
> > > >
> > > > Yes, the attack is a PCP attack, and relies on the CGN supporting
> > > PCP.
> > > >
> > > >
> > > > > 2. You said that " mappings must first be created by some other
> > > means
> > > > > in the inner NAT". What is the means? Manually or dynamically?
> > > >
> > > > Any of these would work: (a) UPnP IGD, (b) NAT-PMP, (c) screen-
> > > > scraping HTTP to the NAT's HTTP server, or (d) a human reading
> > > > the CLI or HTTP of the NAT and manually configuring the host
> > > > to send the proper PCP message.
> > > >
> > > > >  I am afraid there will be a coincident lifetime problem.  For
> > > example
> > > > > the lifetime of MAP in Out NAT is 12 hour, but the lifetime of
> MAP
> > > in
> > > > > inner NAT is 1  hour. What will happen when inner NAT MAP's
> > > lifetime
> > > > > expired.
> > > >
> > > > The lifetime of the mapping in the in-home residential NAT
> doesn't
> > > > matter for this attack.
> > > >
> > > Thomas=>
> > > You are right, it has nothing to do with attack.
> > > I mean when we take consideration of two level NATs on draft-PCP-
> base,
> > > there will be a lifetime disaccord problem. When the lifetime of
> > > mapping entry in inner NAT expired, the mapping entry in outer NAT
> > > still active.
> >
> > Sure.  Not much we can do about that.  (I see Sam answered this
> > point in more detail over the weekend.)
> >
> > -d
> >
> >
> > > The remote user can't access the server on PCP client
> > > host, but it seems that CGN works better.
> > >
> > >
> > >
> > >
> > > >
> > > > > 3. The Inner NAT function on CPE may be shut down for some
> reasons,
> > > how
> > > > > could the PCP client know the dynamic change on CPE?
> > > >
> > > > If the in-home residential NAT is bridging (and is not a NAT),
> this
> > > > PCP attack is not possible.
> > > >
> > > Thomas=>
> > > Right, but PCP client needs to know whether inner NAT shuts down to
> > > decide whether it constructs PCP request's PCP Client's IP address
> with
> > > source address or external IP address from inner NAT. I think there
> are
> > > varies reason that user will shut down NAT or turn on NAT function
> on
> > > CPE.
> > >
> > >
> > > >
> > > > > 4.How could the PCP client know the external IP address on
> inner
> > > NAT?
> > > >
> > > > UPnP IGD, NAT-PMP, or screen-scraping the HTTP, or a human
> reading
> > > > the CLI or HTTP.
> > > >
> > > Thomas=>
> > > I remember that UPnP can get the IP address on WAN interface. But
> > > external IP address is a address pool of NAT. IP address on WAN and
> > > external IP address of pool may be the different IP address.
> > > I am not sure in this field. If there are an external IP in UPnP
> > > packets, it will be ok.
> > >
> > >
> > >
> > > > > 5.Is it possible that there are more than one external IP
> address
> > > > > (maybe a private IP address) on inner NAT external Pool? For
> > > example,
> > > > > different external IP for different service.
> > > >
> > > > If the victim and the attacker have different IP addresses, from
> the
> > > > perspective of the carrier's PCP server, this specific PCP attack
> is
> > > > not possible.  That occurs if the in-home residential CPE is not
> > > > NATing (as described in (3)) or if separate IP addresses are
> assigned
> > > > to each possible attack & victim host pair.
> > > Thomas=> It is ok
> > >
> > > >
> > > > -d
> > > >
> > > >
> > > > > Regards
> > > > > Thomas
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Dan Wing [mailto:[e-mail]]
> > > > > > Sent: Friday, August 24, 2012 12:49 AM
> > > > > > To: Zhangzongjian (Thomas); [e-mail]
> > > > > > Cc: 'Stuart Cheshire'
> > > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Zhangzongjian (Thomas)
> [mailto:[e-mail]]
> > > > > > > Sent: Wednesday, August 22, 2012 6:59 PM
> > > > > > > To: Dan Wing; [e-mail]
> > > > > > > Cc: 'Stuart Cheshire'
> > > > > > > Subject: RE: [pcp] strengthening PCP with Mapping Nonce
> > > > > > ...
> > > > > > > Thomas=>
> > > > > > > Do you mean that the home NAT does not support PCP client,
> PCP
> > > > > proxy
> > > > > > > and upnp-pcp interworking?
> > > > > >
> > > > > >
> > > > > > Correct -- the home NAT, in this attack scenario, is the home
> NAT
> > > > > > that is currently for sale at the local computer store, which
> do
> > > > > > not support PCP and do not know anything about PCP.
> > > > > >
> > > > > >
> > > > > > > But, how could the victim host create the MAP entries?
> > > > > >
> > > > > > The victim's host supports PCP in its application (or its
> > > > > > operating system), which sends the PCP request to the CGN
> > > > > > directly.
> > > > > >
> > > > > >
> > > > > > > As you know the home NAT will change the source IP address
> of
> > > PCP
> > > > > > > request from hosts. This will result to mis-match with "
> PCP
> > > > > Client's
> > > > > > > IP Address" in PCP request heard. Then  PCP server will
> return
> > > an
> > > > > > > ADDRESS_MISMATCH error without creating MAP entry.
> > > > > >
> > > > > > The PCP client in the (victim) host can overcome that by
> placing
> > > the
> > > > > > WAN address of the NAT into the PCP Client IP Address field
> of
> > > the
> > > > > > PCP packet.
> > > > > >
> > > > > > In -27, we have tentatively added:
> > > > > >
> > > > > >   When such
> > > > > >   an intervening non-PCP-aware inner NAT is detected,
> mappings
> > > must
> > > > > >   first be created by some other means in the inner NAT,
> before
> > > > > >   mappings can be usefully created in the outer PCP-
> controlled
> > > NAT.
> > > > > >   Having created mappings in the inner NAT by some other
> means,
> > > the
> > > > > PCP
> > > > > >   client should then use the inner NAT's External Address as
> the
> > > > > Client
> > > > > >   IP Address, to signal to the outer PCP-controlled NAT that
> the
> > > > > client
> > > > > >   is aware of the inner NAT, and has taken steps to create
> > > mappings
> > > > > in
> > > > > >   it by some other means, so that mappings created in the
> outer
> > > NAT
> > > > > >   will not be a pointless waste of state.
> > > > > >
> > > > > > -d
> > > > > >
> > > > > >
> > > > > > > Draft-ietf-pcp-base-26 tells something about mis-match.
> Below
> > > are
> > > > > > > copied from last paragraph of chart 8.2 for reference.
> > > > > > >
> > > > > > > The PCP server compares the source IP address (from the
> > > received IP
> > > > > > >    header) with the field PCP Client IP Address.  If they
> do
> > > not
> > > > > match,
> > > > > > >    the error ADDRESS_MISMATCH MUST be returned.  This is
> done
> > > to
> > > > > > detect
> > > > > > >    and prevent accidental use of PCP where a non-PCP-aware
> NAT
> > > > > exists
> > > > > > >    between the PCP client and PCP server.  If the PCP
> client
> > > wants
> > > > > such
> > > > > > >    a mapping it needs to ensure the PCP field matches its
> > > apparent
> > > > > IP
> > > > > > >    address from the perspective of the PCP server.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -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