Re: [pcp] strengthening PCP with Mapping Nonce

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

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