Re: [pcp] strengthening PCP with Mapping Nonce

["Zhangzongjian (Thomas)" <[e-mail]>]

> 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.

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