[Int-area] My comments on draft-boucadair-intarea-nat-reveal-analysis-04 from the meeting

[Hannes Tschofenig <[e-mail]>]

Hi all, 

I wanted to repeat my comments on the draft from the working group session because I raised my hand when Suresh asked whether this document is a good starting point as a WG item. 

My comments on the microphone concerned two aspects: 

* Scope

At the beginning of the presentation the purpose of the document was advertised to the audience as telling others about the implication of address sharing (because people do not know about that). The expected audience was seen as both inside the IETF (the MTCP group was described as a group that is in need to lean about NATs) and outside the IETF. RFC 6269 already does this. 

It was also stated in the draft as well as in the presentation that recommendations regarding the solutions will be provided. During the working group session I believe we reached an agreement that the document would only document existing solutions and not provide recommendations on what to use for what specific application usages).

Here my concern was that documenting solutions to an unspecified range of problems is somewhat difficult when you talk about pros and cons. During the presentation alone more than three application domains were mentioned, namely denial of service attacks, charging, and authentication without having to re-type the password (a SSO type of solution). Some of you would agree with me that the solution space to only these three application scenarios is much larger than what is described in the document. 

I called it "stupid" to use the IP address for authentication purposes and the presenters made jokes about that statement (in the wrong believe I think they are stupid). Clearly, Joe and Pierre also do not believe that the source IP address can be used for authentication today anymore because that is the main statement of their draft - you have to at least consider the source port as well. I encourage those who believe in these types of "authentication" mechanisms to come to the OAuth working group meeting tomorrow to hear how other people in the industry do authentication today. 

(Btw, I am not the first who had made the observation that IP address for authentication is not such a great idea. Have a look at Steve Bellovin's publication from 1989 with the title "Security Problems in the TCP/IP Protocol Suite".)

* Privacy

The document cites draft-morris-privacy-considerations-03, which is good, but from the writeup in Section 1.2 I had gotten the impression that the authors do not believe in privacy and therefore wash it away with statements like: 
"
   The HOST_ID does not reveal more privacy information than what the
   source IP address does in a non-shared address environment (see
   [I-D.morris-privacy-considerations]).
"

Even if the authors do not believe in privacy (or and maybe other  design properties as well) there may still other people out there who find it important to consider it particularly if it has the potential to void other IETF work.

I would like to avoid the mistake that was made with RFC 6302: on one hand the authors of RFC 6302 assumed that readers have no clue about networking and don't know that they also have to log port numbers (in addition to IP addresses) but on the other hand they assumed they will know a lot about the privacy implications of logging. How likely is that? 

Ciao
Hannes