Subject: [pcp] Resolving contentious issue #2: Transaction ID

From: Alain Durand <[email-masked]>
Date: Mon, 25 Oct 2010 20:09:47 -0700

The question is Do we need a transaction ID in the PCP packet format?

It has been argued that the entire packet contain enough data that a transaction ID is not necessary.

I'd like the proponents and the opponents of Epoch to speak now and make their case.
This window of discussion is open for 2 days. (until 11pm EDT Wednesday). 

  -  Alain.

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 08:00:39 +0200

Dear all,

   I'm in favour of the transaction-ID for two reasons:

   (1) Transaction ID is meant to allow for simultaneous communications
   (i.e., ability to issue several requests in the same time to the same
   PCP Server) between the PCP Client and a PCP Server.  A PCP Client
   can de-multiplex its requests, in particular if no port number is
   included in the request/response (think about a firewall policy to
   allow all traffic coming from a trusted host, a firewall pinhole to
   accept portless protocols (i.e., no use of UDP/TCP port)).

   (2) Transaction ID allows also to prevent against "poisoned" PCP
   responses: If transaction-ID is supported, an attacker will need to
   guess in addition to the port and other information, the
   transaction-ID which makes the attack harder.

   Transaction ID can be seen as part of the loose security wall to
   protect PCP operation without requiring authenticating all PCP
   control messages (in both client and server sides).  As such
   Transaction ID must be a randomly generated by the PCP Client for
   each new PCP Request.  The value of this field must be echoed by the
   PCP Server in the response.  If a distinct Transaction ID is included
   in a received response, the PCP Client must ignore it.  The request
   must be retransmitted to the PCP Server.

   Cheers,

   Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Alain Durand
Envoyé : mardi 26 octobre 2010 05:10
À : [email-masked]
Objet : [pcp] Resolving contentious issue #2: Transaction ID

  -  Alain.
_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Oct 2010 09:10:14 +0200

In your previous mail you wrote:

=> 'need' with the meaning of 'required': no, 'need' with the meaning
of very useful in some common cases: yes.
Note the immediate consequence is IMHO it should be an IE (extension).

I'd like to get something a bit more general than a transaction ID:
an opaque (i.e., which has no internal format/semantic for the PCP
server) Information Element which can be added in a request and
which will be reflected (just copied bit by bit) by the PCP server
in the response.

This includes the transaction ID but allows the support of stateless
PCP relays (i.e., it is enough to put the state in the opaque IE
content) too. Note an opaque IE can be used for security too.

It is very useful for devices managing several requests at the
same time (a relay/proxy is a good example of such a device)
for matching a received response with a pending request.

Without this the device has to compute the request from the
response and to check one by one in pending requests for
a matching, something complex (so error prone) and inefficient.

Worse, if something like the zone ID is added in the protocol
it breaks already existing matching codes, i.e., matching codes
in intermediate devices must have a complete knowledge of the
protocol. Obviously we don't want this for PCP.

Regards

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 19:33:38 -0700

(Combined emails from Mohamed and Francis.)

[email-masked] wrote:

>    PCP Server) between the PCP Client and a PCP Server. 

That can be done without a transaction id.

> A PCP Client

All of those contain information which makes the request unique --
they have to, in order for the PCP server to process the request
(e.g., to create the mapping).

For example, a PCP client could send, back-to-back, 6 requests to get
NAT mappings internal TCP ports X, Y, and Z and requests to
get NAT mappings for internal UDP ports A, B, and C -- all
without a transaction ID, and all PCP messages sent from the same
ephemeral port.  Each of those responses is fully formed and 
contains the same information the PCP server (and NAT) needed to 
create the mapping, and thus provides exactly the same information 
back to the PCP client to match the response to the request.

>    transaction-ID which makes the attack harder.

Yes, I agree it adds some protection from an attacker spoofing
the PCP's server.  We already have 16 bits of randomness with the
client's source port for the incoming mapping and 16 bits of randomness
for the ephemeral port.  That brings PCP in line with DNS (which
has a 16 bit transaction-id and, after the Kaminsky attacks, an
ephemeral source port).  Is that enough?

> which will be reflected (just copied bit by bit) by the PCP server

So, a cookie which is meaningless to the server and echoed to the
client.  SCTP has such a thing (cookie, cookie-echo).  Although 
called transaction-id in draft-wing-softwire-port-control-protocol, 
that was exactly the function of its transaction-id.  It had no 
meaning or purpose to the server, it was simply copied from the
request into the response.

> content) too. Note an opaque IE can be used for security too.

So the state is copied into the cookie, sortof like how TCP SYN
cookies copy state into the cookie?

> a matching, something complex (so error prone) and inefficient.

The PCP client, upon receiving the PCP response, looks at the 
inside-IP-address (typically its own address, unless it created
a mapping for another host) and then walks a list of 
inside-port-number (or a hash table if it has a zillion 
PCP mappings).  That is the sort of same thing a NAT does for 
*every* packet it NATs.

For IPv4, this is 48 bits (inside IPv4 address, inside port)
validated and looked up.

Transaction ID would change this to 32 (?) bits or something,
but now the PCP client will avoid examining / validating the 
inside IPv4 address and inside port -- because the transaction
id is all it thought it needs.  So, we shouldn't be returning
all that 'redundant' information in the PCP response if 
a transaction id is added, because it gets into a weird 
situation of where the transaction id matches, but some
other field doesn't match.

> protocol. Obviously we don't want this for PCP.

I know the purpose of zone-ID, but I don't follow this problem.

-d

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 07:44:33 +0200

Hi Dan,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 04:34
À : BOUCADAIR Mohamed NCPI/NAD/TIP; 'Alain Durand'; [email-masked]; 'Francis Dupont'
Objet : RE: [pcp] Resolving contentious issue #2: Transaction ID

Med: only if the port is present, otherwise no sure how you can do the matching.

Med: Yes for TCP/UDP but my point was about "porteless" protocols.

Med: Having random transaction ID (32 bits) and random source port will be make it harder: guessing a value of 48 bits will be hard. Then, you can ask why not 64 bits ;-) but guessing a value from 281474976710656 is already acceptable. No?

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 2010 09:10:25 +0200

=> I don't argue a transaction ID is required, just it is very useful
in some cases including IWF/proxy/relay, which are supposed to
be very common.

=> the information which makes the request unique can include things
like a zone-id so it becomes hard to write a lightweight proxy
(think about silicon) which doesn't break if such a thing is
introduced.

   ... sent from the same ephemeral port.

=> this is an alternative (IMHO pretty poor alternative) to
a transaction ID. It is really what we want?

   That brings PCP in line with DNS (which
   has a 16 bit transaction-id and, after the Kaminsky attacks, an
   ephemeral source port).  Is that enough?
   
=> in the case of DNS this was shown to be not enough.

=> you can use the term you'd like: I don't think there is a very
well-defined one. About the transaction ID it suggests a fixed size
and to change for each transaction, the cookie has less constraints.

   
=> yes, in this case the cookie is a state cookie (BTW I tried this
and it works pretty well).

   
=> yes and this lookup takes at least 40 % of the whole time
so is clearly what limits the performance/scalability of a NAT.

=> note for a iwf/proxy/relay the lookup key is not bound to
a defined number of fields about of things like zone-id.

=> it would change to what is needed if you'd like to minimize it.

=> no, I don't argue we should or may avoid to return 'redundant'
information.

   
   
=> am I clearer now?

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 00:55:12 -0700

> Med: only if the port is present, otherwise no sure how you can do the

There can only be one PCP request outstanding with a port [e.g., UDP, TCP]
(for a port-oriented protocol getting or deleting a mapping), and,
similarly, one PCP request outstanding without a port [e.g., RSVP] (for a
non-port-oriented protocol getting or deleting a mapping).  Retransmissions
look exactly the same for both protocols-with-a-port and
protocols-without-a-port.  There is no loss of functionality when attempting
to use PCP to map a protocol that doesn't use port numbers (e.g., RSVP).

-d

> Med: Having random transaction ID (32 bits) and random source port will
> be make it harder: guessing a value of 48 bits will be hard. Then, you
> can ask why not 64 bits ;-) but guessing a value from 281474976710656
> is already acceptable. No?
>