Subject: [Int-area] L. Eggert's comment (draft-boucadair-intarea-host-identifier-scenarios)

From: <[email-masked]>
Date: Wed, 23 Jul 2014 12:32:37 +0000

Hi all,

Lars raised a point about draft-boucadair-intarea-host-identifier-scenarios that is basically to question whether it is worth continuing this effort if no viable solutions can be designed to solve this problem.

I do agree this is a fair point. I have several comments to make here:

*         The lack of a recommendation in RFC6967 should not be interpreted as there is no working solution.

*         The analysis in RFC6967 is specific to particular cases that span many administrative domains (read CGN). So, the drawbacks of several solutions discussed in RFC6967 are irrelevant for scenarios that are restricted to a single administrative domain (or where an administrative relationship is setup between involved parties).

*         The IETF recognizes there are solutions for specific applications: RFC7239 was published after RFC6967!

*         Some solutions such as the use of an IP option are viable ones when involved devices are under the control of the same administrative entity.

*         Some of the scenarios can be solved by protocol extensions (e.g., http://tools.ietf.org/html/draft-boucadair-pcp-nat-reveal-01, querying the MIB in http://tools.ietf.org/html/draft-ietf-behave-nat-mib-11, announcing port sets http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-01, etc.) without requiring injecting an identifier in the packet.

*         I know Lars is not supportive to the use of a TCP option, but IMHO the use of a tcp option is superior to RFC7239. The TCP option is a working solution for the TCP proxy, https and other scenarios.

*         Stephen (Farrel) mentioned in the list he has concerns with RFC7239 and a better solution that would preserve privacy should be considered.

The rationale in the scenarios draft is as follows: instead of advancing specifications that are scoped to a specific scenario, it is worth having a means that will help linking all these scenarios to hopefully make common solutions possible.

Cheers,
Med

---

From: <[email-masked]>
Date: Wed, 23 Jul 2014 12:42:23 +0000

I figure out this text: "and a better solution that would preserve privacy should be considered." may not reflect exactly the point made by Stephen, so I'm inserting his words:

"I'd be delighted if those who could get a better solution

implemented/deployed were to attempt to try to address the

privacy issues with XFF but it seems that at least in that

case relevant folks don't care (sufficiently;-) deeply about

our privacy to go do that."

Cheers,
Med

De : Int-area [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 23 juillet 2014 14:33
À : Internet Area ([email-masked])
Cc : [email-masked]
Objet : [Int-area] L. Eggert's comment (draft-boucadair-intarea-host-identifier-scenarios)

Hi all,

·         The lack of a recommendation in RFC6967 should not be interpreted as there is no working solution.

·         The analysis in RFC6967 is specific to particular cases that span many administrative domains (read CGN). So, the drawbacks of several solutions discussed in RFC6967 are irrelevant for scenarios that are restricted to a single administrative domain (or where an administrative relationship is setup between involved parties).

·         The IETF recognizes there are solutions for specific applications: RFC7239 was published after RFC6967!

·         Some solutions such as the use of an IP option are viable ones when involved devices are under the control of the same administrative entity.

·         Some of the scenarios can be solved by protocol extensions (e.g., http://tools.ietf.org/html/draft-boucadair-pcp-nat-reveal-01, querying the MIB in http://tools.ietf.org/html/draft-ietf-behave-nat-mib-11, announcing port sets http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-01, etc.) without requiring injecting an identifier in the packet.

·         I know Lars is not supportive to the use of a TCP option, but IMHO the use of a tcp option is superior to RFC7239. The TCP option is a working solution for the TCP proxy, https and other scenarios.

·         Stephen (Farrel) mentioned in the list he has concerns with RFC7239 and a better solution that would preserve privacy should be considered.

Cheers,
Med

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jul 2014 01:07:56 +1200

Hi Med,

On 24/07/2014 00:32, [email-masked] wrote:
...
> *         The IETF recognizes there are solutions for specific applications: RFC7239 was published after RFC6967!

It isn't really a surprise that a specific application layer can add
any information about the path that it wants to application layer messages,
nor that these additions can nullify any privacy protection built into
lower layers. SMTP has done this very effectively for many years.
RFC 7239 is way for HTTP to do the same...

I don't see that as very informative about the issue of generic
Internet-layer host ID issues, but it is very informative about the
chances of globally enforcing privacy protection.

   Brian

---

From: joel jaeggli <[email-masked]>
Date: Wed, 23 Jul 2014 09:23:24 -0400

On 7/23/14, 8:42 AM, [email-masked] wrote:
> I figure out this text: “and a better solution that would preserve
> privacy should be considered.” may not reflect exactly the point made by
> Stephen, so I’m inserting his words:
> 
>  
> 
> “I'd be delighted if those who could get a better solution
> 
> our privacy to go do that.”

The proposal for a HIAPS bof staked out a particular position with
respect to this

  "First it has to be ensured that the server on the receiver side is
well justified
  to receive the   information. Next it will be granted that the
communication is
  not visible to on-path observers using the most state-of-art ways of
securing
  the communication."

I found that acceptable, it is however incompatible with some of the
proposed solutions.

> Cheers,
> 
> Med
> 
>  
> 
> *De :*Int-area [mailto:[email-masked]] *De la part de*
> [email-masked]
> *Envoyé :* mercredi 23 juillet 2014 14:33
> *À :* Internet Area ([email-masked])
> *Cc :* [email-masked]
> *Objet :* [Int-area] L. Eggert's comment
> (draft-boucadair-intarea-host-identifier-scenarios)
> 
>  
> 
> Hi all,
> 
>  
> 
> Lars raised a point about
> draft-boucadair-intarea-host-identifier-scenarios that is basically to
> question whether it is worth continuing this effort if no viable
> solutions can be designed to solve this problem.
> 
>  
> 
> ·         The lack of a recommendation in RFC6967 should not be
> interpreted as there is no working solution.
> 
> ·         The analysis in RFC6967 is specific to particular cases that
> span many administrative domains (read CGN). So, the drawbacks of
> several solutions discussed in RFC6967 are irrelevant for scenarios that
> are restricted to a single administrative domain (or where an
> administrative relationship is setup between involved parties).
> 
> ·         The IETF recognizes there are solutions for specific
> applications: RFC7239 was published after RFC6967!
> 
> ·         Some solutions such as the use of an IP option are viable ones
> when involved devices are under the control of the same administrative
> entity.
> 
> ·         Some of the scenarios can be solved by protocol extensions
> (e.g., http://tools.ietf.org/html/draft-boucadair-pcp-nat-reveal-01,
> querying the MIB in
> http://tools.ietf.org/html/draft-ietf-behave-nat-mib-11, announcing port
> sets http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-01,
> etc.) without requiring injecting an identifier in the packet.
> 
> ·         I know Lars is not supportive to the use of a TCP option, but
> IMHO the use of a tcp option is superior to RFC7239. The TCP option is a
> working solution for the TCP proxy, https and other scenarios.
> 
> ·         Stephen (Farrel) mentioned in the list he has concerns with
> RFC7239 and a better solution that would preserve privacy should be
> considered.
> 
>  
> 
> The rationale in the scenarios draft is as follows: instead of advancing
> specifications that are scoped to a specific scenario, it is worth
> having a means that will help linking all these scenarios to hopefully
> make common solutions possible.
> 
>  
> 
> Cheers,
> 
> Med
> 
> 
> 
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: <[email-masked]>
Date: Wed, 23 Jul 2014 13:33:07 +0000

Hi Joel,

This is indeed acceptable, in particular, for scenarios that are specific to a single administrative domain or that requires an agreement between the entity that owns the information and the one that will make use of that information. 

Cheers,
Med

>-----Message d'origine-----
>De : joel jaeggli [mailto:[email-masked]]
>Envoyé : mercredi 23 juillet 2014 15:23
>À : BOUCADAIR Mohamed IMT/OLN; Internet Area ([email-masked])
>Objet : Re: [Int-area] L. Eggert's comment (draft-boucadair-intarea-host-
>identifier-scenarios)
>
>> I figure out this text: "and a better solution that would preserve
>> privacy should be considered." may not reflect exactly the point made by
>> Stephen, so I'm inserting his words:
>>
>>
>>

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Jul 2014 10:04:20 -0700

I'd like to add some context from my viewpoint:

On 7/23/2014 5:32 AM, [email-masked] wrote:
> ·The lack of a recommendation in RFC6967 should not be interpreted as
> there is no working solution.

Agreed. The WG decided not to make a recommendation - but that also 
means that the analysis in that doc should not be taken as a 
recommendation either. This doc claims that RFC6967 says that a TCP 
solution may be possible, but that was based on only one candidate TCP 
approach *and* the TCP approach was considered roughly equivalent to 5 
of the other 7 approaches.

> ·The analysis in RFC6967 is specific to particular cases that span many
> administrative domains (read CGN). So, the drawbacks of several
> solutions discussed in RFC6967 are irrelevant for scenarios that are
> restricted to a single administrative domain (or where an administrative
> relationship is setup between involved parties).

Or behind home NATs.

Joe