Subject: Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-identifier-scenarios-04

From: <[email-masked]>
Date: Wed, 23 Jul 2014 11:57:24 +0000

Hi Alissa, all,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : Int-area [mailto:[email-masked]] De la part de Suresh
>Krishnan
>Envoyé : vendredi 20 juin 2014 06:42
>À : Alissa Cooper; Internet Area
>Objet : Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-
>identifier-scenarios-04
>
>Hi Alissa,
>
>On 06/19/2014 06:38 PM, Alissa Cooper wrote:
>> I guess it is a feature of area WGs that the sequence of work items is
>> not well-defined in advance of taking up any particular work items, nor
>> are those work items correlated to WG milestones (I looked at the
>> intarea milestones, dated to 2010, so I assume milestones are not used
>> in this group).
>
>Yes. This is correct. The intarea working group does not have any
>defined milestones. Most of the work we take up is one-off kind of items
>and these are not really anticipated ahead of time.
>
>
>> In the case of the host ID work, this seems particularly
>> unfortunate. I don't think it's often the case that a draft outlining
>> solutions is published in advance of a draft that describes use cases
>> for those solutions, but that seems to be the direction of the effort
>> here.
>
>Yes. It is unfortunate. When the draft that became RFC6967 was taken up
>in intarea, it was fairly controversial (as is all work in this space)
>and no further work was anticipated. The draft in question was
>originally going through an AD sponsored route (Joel Jaeggli - OPS).
>Joel posted in intarea to get some opinions on this draft since RFC6269
>and RFC6967 were produced here. Based on the ensuing discussion Joel
>felt that the draft was better pursued in intarea.

[Med] The initial scope of RFC6967 is limited to the CGN/A+P/proxies cases as a follow-up to RFC6269. The intent at that time was not to explore whether other deployment scenarios are suffering from the same issues as in RFC6967. The scenarios draft go one step further as it tries to draw a broad picture by listing deployment scenarios that share the same root problem.

>
><snipped>
>
>> To me what would be useful here would be a document that points out new
>> problems beyond those identified in RFC 6269 that arise in
>> address-sharing or tunneled architectures not already contemplated in
>> that document. If there aren't new problems, then I'm not sure why 6269
>> is not considered a sufficient description of the problem space.

[Med] Some comments here:
* RFC6269 is cited in the scenarios drafts. 
* RFC6269 and this scenarios I-D are not conflicting. 
* Furthermore, there are new issues that are raised in the scenarios draft but are not discussed in RFC6269. We have taken into account this comment in the new revision of the draft available (see the diff https://www.ietf.org/rfcdiff?url1=draft-boucadair-intarea-host-identifier-scenarios-05&difftype=--html&submit=Go!&url2=draft-boucadair-intarea-host-identifier-scenarios-07) and also in the slides presented in the intarea session (slides 5 and 6 of http://www.ietf.org/proceedings/90/slides/slides-90-intarea-1.pdf).

 If
>> there are new problems, then between RFC 6269 and the new draft there
>> would be a fairly comprehensive list of them documented,

[Med] -06 of the draft included this text:

An exhaustive list of encountered issues for the Carrier
   Grade NAT, A+P, and Application Proxies scenarios are documented in
   [RFC6269].  In addition to those issues, some of the scenarios
   described in this document suffer from additional issues such as:

   o  Identify which policy to enforce for a subscriber/UE (e.g., limit
      access to the service based on some counters such as volume-based
      service offering); enforcing the policy will have impact on all
      hosts sharing the same IP address.
   o  Need to correlate between the internal address:port and external
      address:port to generate and therefore to enforce policies.
   o  Query a location server for the location of an emergency caller
      based on the source IP address.

In addition to this text we added also new text to explain why RFC6967 may not be appropriate for scenarios that are local to a single administrative domain: 

   This document can be used as a tool to design solution(s) mitigating
   the encountered issues.  Describing the scenario allows to identify
   what is common between the scenarios and then would help during the
   solution design phase.  Note, [RFC6967] focuses only on the CGN, A+P,
   and application proxies cases.  The analysis in [RFC6967] may not be
   accurate for some of the scenarios that do not span multiple
   administrative domains (e.g., Section 10.1).

 and that could
>> provide a foundation for figuring out how to solve some or all of them,

[Med] The scenario draft does not ambition to define solutions but the sketch the big picture of the problem space. We added this new text to the published -06:

   This document does not include any solution-specific discussion.  

>> whether some of them have existing solutions, and how potential new
>> solutions relate to embedding a unique host identifier at the network or
>> transport layer.

[Med] This draft does not assume injecting a host identifier is the only solution to mitigate encountered problems for all scenarios. We added this new text to -06 to call out this point:

   In
   particular, the document does not elaborate whether explicit
   authentication is enabled or not.  Moreover, this document does not
   discuss whether specific information is needed to be leaked in
   packets, whether this is achieved out-of-band, etc.  Those
   considerations are out of scope.

>
>I think this is a good idea.

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 23 Jul 2014 12:11:57 +0000

Hi,

I wanted to repeat my comment from the meeting. Given that at least in my read of RFC6967, there exist to sane mechanism to even exchange host IDs across the network, I don't really see why INTAREA should spend any more time on this space. 

Lars

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jul 2014 09:00:43 -0400

> I wanted to repeat my comment from the meeting. Given that at least in my read of RFC6967, there exist to sane mechanism to even exchange host IDs across the network, I don't really see why INTAREA…

Lars, the end user definitely has a trust relationship with the ISP from whom they purchase service.   Typically they have a password that works for authentication, but additionally it's common practice to use the fact that a device is connected over a particular circuit as proof that the person using the device is allowed to use the services the ISP provides.   So I am puzzled as to why this problem seems intractable to you.

As to which area ought to do this, that's obviously an open issue, since we don't even have a BoF yet.   This would certainly be a cross-area issue if the not-yet-existent working group finds that they cannot use existing technology to solve the problem.

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 23 Jul 2014 08:25:49 -0500

Hi Ted,

> As to which area ought to do this, that's obviously an open issue, since we don't even have a BoF yet.   This would certainly be a cross-area issue if the not-yet-existent working group finds that…

Dirk (cc'ed) and I had a BoF proposal (called hiaps) for IETF 89 which
was on this issue but it was more concentrated on the emergency call
use case because of an Liaison Statement that was sent from ETSI to
IETF.I also cc'ed Bruno who was involved from ETSI side.

We had withdrawn that BoF request and since then the intention was
that Intarea would do this work.

Are you recommending on getting back to hiaps?

Regards,

Behcet
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jul 2014 09:38:04 -0400

> As to which area ought to do this, that's obviously an open issue, since we don't even have a BoF yet.   This would certainly be a cross-area issue if the not-yet-existent working group finds that…

This was a lack-of-coffee error.   I was commenting about something Lars said in a completely different context about a completely different proposal.   Please disregard what I said above.   Sorry for the resulting confusion.

---

From: Brandon Williams <[email-masked]>
Date: Thu, 31 Jul 2014 15:14:13 -0400

Hi Lars,

Thanks for this clear reiteration of the concern you raised in the meeting.

Your reading of RFC6967 conflicts with mine, though I wasn't involved in 
the discussions related to adoption of that RFC. While I don't see that 
it recommends any particular one of the approaches analyzed in the 
draft, I also don't see that it rules out all of the proposals, either. 
Certainly, it indicates that some of them are problematic (e.g. any 
proposal with a high performance impact and/or low success ratio). 
However, it doesn't indicate (to me at least) that none of the solutions 
have any merit.

Has your read of RFC6967 been presented as the general int-area 
consensus in past discussions about the RFC? Or would there be some 
value in probing the list a bit more on the topic?

--Brandon

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: "Eggert, Lars" <[email-masked]>
Date: Thu, 31 Jul 2014 19:45:50 +0000

Hi Brandon,

On 2014-7-31, at 21:14, Brandon Williams <[email-masked]> wrote:
> Has your read of RFC6967 been presented as the general int-area consensus in past discussions about the RFC? Or would there be some value in probing the list a bit more on the topic?

my takeaway from the RFC as certainly has not been confirmed as the consensus of the WG, and I did't mean to imply so. Establishing any consensus would be up to the chairs.

Lars

---

From: Brandon Williams <[email-masked]>
Date: Thu, 31 Jul 2014 17:01:47 -0400

Thanks Lars. That's what I thought; I just wanted to be sure that I 
hadn't missed something by joining the discussion a bit later than others.

I would be interested in hearing more broadly from the list on the 
subject of whether RFC6967 justifies further int-area work on host 
identification. I'm not asking about any specific solution candidate, 
but rather whether the solution set as a whole shows enough promise. The 
authors of the scenarios draft think that RFC6967 justifies the 
continued work effort, but Lars and some others do not. I'd like to get 
some sense of which direction consensus is leaning in that regard.

Of course, if people have the sense that this isn't a useful line of 
inquiry, I'm receptive to that feedback too.

Thanks,
--Brandon