from:"mohamed.boucadair"

Re-,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Amelia
> Andersdotter
> Envoyé : mercredi 25 avril 2018 14:37
> À : int-area@ietf.org
> Objet : Re: [Int-area] WG adoption call: Availability of Information in
> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
> 
> On 2018-04-25 13:27, mohamed.boucad...@orange.com wrote:
> >     SHOULD NOT store logs of incoming IP addresses from inbound
> >
> >   traffic for longer than three days.
> >
> >
> >
> > The above proposed text does not make sense to me. The IETF does not
> > have to make a call on such matters.
> >
> >
> >
> 
> You could have two different objections to the draft:
> 
> 1. The IETF does not, in general, recommend grace periods or time
> periods for logging, caching, etc. That's just wrong - I find loads of
> examples in old and new RFCs of recommended time-periods for data
> storage by googling.

[Med] AFAIK, there is no such IETF reco for address sharing specifications. 

> 
> 2. The time-period as suggested is wrong. For instance, as Povl
> proposed, 3 days is reasonable if it's just about shifting the log from
> the internet-facing server as such to somewhere else, and for storing
> logs at end-destination a longer period of time is necessary.
> 
> I think you're aiming for objection 1). I don't see the historical
> precedent for this assertion, and it seems to be rather about what the
> IETF would feel like. I'm open for discussion on objection 2).

[Med] Hmm. Please check 
https://mailarchive.ietf.org/arch/msg/behave/GzY46_zyxVDeKv10nGzGWM8FA34 

> 
> best,
> 
> A
> 
> > Cheers,
> >
> > Med
> >
> >
> >
> > *De :*Povl H. Pedersen [mailto:p...@my.terminal.dk]
> > *Envoyé :* mercredi 25 avril 2018 13:16
> > *À :* BOUCADAIR Mohamed IMT/OLN
> > *Cc :* int-a...@ietfa.amsl.com
> > *Objet :* Re: [Int-area] WG adoption call: Availability of Information
> > in Criminal Investigations Involving Large-Scale IP Address Sharing
> > Technologies
> >
> >
> >
> > I would keep full IP address + port info in my firewall log. Separate
> > from the webserver log. This to help the webguys not abusing collected
> > data.
> >
> > Having talked to the webguys, they use the logfiles in daily
> > operations, and they see them as necesary to provide continous
> > delivery of the services to the end user.That is another obligation we
> > have.
> > Our legal department actually suggested we keep logs for 5 years, as
> > some data must be kept that long.
> >
> > The big privacy issue here is more about abuse and losing the data
> > (move them away from the internet facing server within 3 days would be
> > a good recommendation). This must be controlled by internal company
> > rules. Not this RFC that says we must cripple data after 3 days. And 3
> > days is a stupid limit if there is a longer weekened/holidays etc.
> > Easter is an example, Thursday to monday are non-working days. That is
> > 5 days + the extra. So the 3 days should be 6 days without even
> > accounting for holidays.
> >
> >
> >
> 
> --
> Amelia Andersdotter
> Technical Consultant, Digital Programme
> 
> ARTICLE19
> www.article19.org
> 
> PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

Re-,

I think we are in agreement.

Please note there is ** NO RFC ** which mandates logs to be kept 3 days.

I guess you are referring to this text from Amelia’s I-D (which reflects the 
author’s opinion):

  SHOULD NOT store logs of incoming IP addresses from inbound
  traffic for longer than three days.

The above proposed text does not make sense to me. The IETF does not have to 
make a call on such matters.

Cheers,
Med

De : Povl H. Pedersen [mailto:p...@my.terminal.dk]
Envoyé : mercredi 25 avril 2018 13:16
À : BOUCADAIR Mohamed IMT/OLN
Cc : int-a...@ietfa.amsl.com
Objet : Re: [Int-area] WG adoption call: Availability of Information in 
Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

I would keep full IP address + port info in my firewall log. Separate from the 
webserver log. This to help the webguys not abusing collected data.
Having talked to the webguys, they use the logfiles in daily operations, and 
they see them as necesary to provide continous delivery of the services to the 
end user.That is another obligation we have.
Our legal department actually suggested we keep logs for 5 years, as some data 
must be kept that long.

The big privacy issue here is more about abuse and losing the data (move them 
away from the internet facing server within 3 days would be a good 
recommendation). This must be controlled by internal company rules. Not this 
RFC that says we must cripple data after 3 days. And 3 days is a stupid limit 
if there is a longer weekened/holidays etc. Easter is an example, Thursday to 
monday are non-working days. That is 5 days + the extra. So the 3 days should 
be 6 days without even accounting for holidays.


On Wed, Apr 25, 2018 at 11:22 AM, 
> wrote:
Re-,

Please see inline.

Cheers,
Med

De : Povl H. Pedersen [mailto:p...@my.terminal.dk]
Envoyé : mercredi 25 avril 2018 11:05
À : BOUCADAIR Mohamed IMT/OLN
Cc : int-a...@ietfa.amsl.com
Objet : Re: [Int-area] WG adoption call: Availability of Information in 
Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

If we are at say a /20 or /22 (that is 2000-8000 possible IP addresses), and we 
have the source port, then the ISP should be able to see which of these 
addresses has the given source port to our destination IP and port.
[Med] The assumption about destination IP at the provider side is broken. 
Further, logging destination IP address is not recommended. RFC6888 says the 
following:

   REQ-12: A CGN SHOULD NOT log destination addresses or ports unless
  required to do so for administrative reasons.

   Justification:  Destination logging at the CGN creates privacy
  issues.

Note also that recent advances in optimizing logs at CGNs (e.g. port set 
assignment, deterministic NAT) conflicts with maintaining a track of the 
destination IP address.

Also, there are stateless address sharing techniques which does not even 
involve a CGN (MAP-E, MAP-T, …). The information about destination IP address 
per new session is not an option.


With a timestamp, the risk of collision is low. And the police can at least 
minimize number of suspects.

[Med] If the destination IP address is not logged at the provider side (which 
is likely), the collision probability of your proposal may be bigger for 
deployments which use a low address sharing ratio (1:2, 1:4).

CGN does not break GeoIP. It still allows us to pinpoint the ISP, but might not 
allow us to pinpoint the user any closer than the breakout point.
[Med] This is exactly what we meant by broken GeoIP in 
https://tools.ietf.org/html/rfc6269#section-7

If we have an ISP, with CGN, and the police can come with a timestamp, and 
source port, and a destination ip/port, the carrier can likely determine the 
physical person. If he has say 255 possible external IP addresses in use, the 
chance of the same source port to the same destination across these is small.

With address sharing, we can't point to one physical person.
[Med] OK.
I have a dynamic public IP at home (changes rarely). It is diificult to 
pinpoint anything to me, my wife or my children. Or any user of my open WiFi 
SSID. From a legal point of view, this is impossible.
[Med] OK.
But, the privacy protection in GDPR should protect the 20 y.o. old having a 
fixed public IP, living alone. And here a fixed IP is enough for an ISP to 
locate a person (or rather a machine) with som certainty.
[Med] ISPs operating fixed networks can locate their customers/subscribers 
whatever scheme used for assigning IP addresses. The identification is based on 
the line, not IP addresses.

I think this is all a tradeoff between protecting individuals, while not 
completely giving up investigative tools - At least to do investigation with 
some statistical probability. And since you do not know which addresses are 
used by CGN, you can't handle

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

Re-,

Please see inline.

Cheers,
Med

De : Povl H. Pedersen [mailto:p...@my.terminal.dk]
Envoyé : mercredi 25 avril 2018 11:05
À : BOUCADAIR Mohamed IMT/OLN
Cc : int-a...@ietfa.amsl.com
Objet : Re: [Int-area] WG adoption call: Availability of Information in 
Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

If we are at say a /20 or /22 (that is 2000-8000 possible IP addresses), and we 
have the source port, then the ISP should be able to see which of these 
addresses has the given source port to our destination IP and port.
[Med] The assumption about destination IP at the provider side is broken. 
Further, logging destination IP address is not recommended. RFC6888 says the 
following:

   REQ-12: A CGN SHOULD NOT log destination addresses or ports unless
  required to do so for administrative reasons.

   Justification:  Destination logging at the CGN creates privacy
  issues.

Note also that recent advances in optimizing logs at CGNs (e.g. port set 
assignment, deterministic NAT) conflicts with maintaining a track of the 
destination IP address.

Also, there are stateless address sharing techniques which does not even 
involve a CGN (MAP-E, MAP-T, …). The information about destination IP address 
per new session is not an option.


With a timestamp, the risk of collision is low. And the police can at least 
minimize number of suspects.

[Med] If the destination IP address is not logged at the provider side (which 
is likely), the collision probability of your proposal may be bigger for 
deployments which use a low address sharing ratio (1:2, 1:4).

CGN does not break GeoIP. It still allows us to pinpoint the ISP, but might not 
allow us to pinpoint the user any closer than the breakout point.
[Med] This is exactly what we meant by broken GeoIP in 
https://tools.ietf.org/html/rfc6269#section-7

If we have an ISP, with CGN, and the police can come with a timestamp, and 
source port, and a destination ip/port, the carrier can likely determine the 
physical person. If he has say 255 possible external IP addresses in use, the 
chance of the same source port to the same destination across these is small.

With address sharing, we can't point to one physical person.
[Med] OK.
I have a dynamic public IP at home (changes rarely). It is diificult to 
pinpoint anything to me, my wife or my children. Or any user of my open WiFi 
SSID. From a legal point of view, this is impossible.
[Med] OK.
But, the privacy protection in GDPR should protect the 20 y.o. old having a 
fixed public IP, living alone. And here a fixed IP is enough for an ISP to 
locate a person (or rather a machine) with som certainty.
[Med] ISPs operating fixed networks can locate their customers/subscribers 
whatever scheme used for assigning IP addresses. The identification is based on 
the line, not IP addresses.

I think this is all a tradeoff between protecting individuals, while not 
completely giving up investigative tools - At least to do investigation with 
some statistical probability. And since you do not know which addresses are 
used by CGN, you can't handle them different than other IPs.
[Med] Given that you stated above that it is difficult to track an individual 
user based on the IP address, then what is the value of complicating the 
investigation by not recording the full IP address + port (for this specific 
investigation purpose)?

Having the full firewall logs as a separate supplement to webserver logs will 
allow you (in many cases) to use the truncated source IP + port to find one or 
a few possible IP addresses. Since you need data from 2 systems, they are 
Pseudonymized, and our legal department would agree it is then acceptable.

Today we keep logs for 18-24 months, and most police investigations comes to us 
12-14 months after the crime asking for more details. Sometimes for cases we 
did not know existed. We are a PCI audited level 1 retailer with a few web 
stores.

We do not have people at work every day to look in logs, so the 3 days 
retention is impossible. It may take weeks for us to discover things. If 3 days 
is to cover the weekend (no 24/7), it should instead be 30 days, as key 
employees might have the normal 21 days of holiday and a week to catch up. 
Smaller companies might not have overlapping staff skills.

On Wed, Apr 25, 2018 at 10:20 AM, 
> wrote:
Dear Povl,

Thank you for sharing your thoughts.

I have one comment and two clarification questions:

- Wouldn’t logging based /20-/22 nullify the interest to log source ports for 
investigations? Multiple subscribers may be assigned the same port in the /20 
or /22 range.

- GeoIP (whatever that means) is broken when CGNs are in use.
  - How and under which conditions an IP address + port can be used to 
point to “ONE physical person” especially when address sharing is in use?

Cheers,
Med

De : Int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

Dear Povl,

Thank you for sharing your thoughts.

I have one comment and two clarification questions:

- Wouldn’t logging based /20-/22 nullify the interest to log source ports for 
investigations? Multiple subscribers may be assigned the same port in the /20 
or /22 range.

- GeoIP (whatever that means) is broken when CGNs are in use.
  - How and under which conditions an IP address + port can be used to 
point to “ONE physical person” especially when address sharing is in use?

Cheers,
Med

De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Povl H. Pedersen
Envoyé : mercredi 25 avril 2018 09:55
À : int-a...@ietfa.amsl.com
Objet : Re: [Int-area] WG adoption call: Availability of Information in 
Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

Where I work, we keep the firewall logs with port numbers completely separate 
from the webserver logs.

Looking at article 25 of GDPR, it is clear that IP addresses are pseudonymized 
data in the firewall logs, as there are only 2 ways to connect the IP address 
to a physical person.
1. Court order to ISP etc.
2. have the web people look up the IP address in their systrem, trace requests, 
and see if they can associate it with a known user identity.

So firewall logs, unless the web people have access to them, are pseudonymized 
data. So secure by design (article 25). And we can keep them for statistics, or 
investigation purposes.

Now, the question then is, how can we keep enough data in the webserver etc log 
to be able to to actually do enough investigation ? A /16 shortening was 
suggested. I think this is too large gruping. Can not even be used for 
country/city statistical purposes. But of course we can enrich data with that 
from the likes of MaxMind, when throwing away trailing bits.

I think we need a minimum /20-/22 and source port in the logs to, with some 
degree of confidence, go from events in the webserver logs back to the firewall 
log to have necesary information for investigation/authorities. If we have a 
/20-/22 and GeoIP data, we might have a few candiates. Then this is good enough 
to ensure we can not get back to ONE physical person.

I think, that updating RFC6302 might be a bit early, and we risk that it has to 
be revised after the first court makes a decision.

If we keep RFC6302 as is, then companies can defend themself, by saying they 
use best practise.

We have another obligation as dataowners/processors. We should keep enough data 
to verify a suspected data breach, and judge the impact. If I can not see if 
1 profiles was downloaded by the same IP, or from 1 different IPs (out 
of 65535), I might not be able to fulfill some of the other requirements in 
GDPR.

I think the big question here is how the data is stored/processed, and it must 
be governed by organizational measures (policies and training). It would likely 
be illegal to use to logs to profile a person.But there can be other interests 
allowing us to keep the logs, disassociated from user profiles or other things 
that allows us to map an IP to an individual.
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

2018-04-24 Thread mohamed.boucadair

Thank you Ted for clarifying.

Please see inline.

Cheers,
Med

De : Ted Lemon [mailto:mel...@fugue.com]
Envoyé : mardi 24 avril 2018 15:26
À : BOUCADAIR Mohamed IMT/OLN
Cc : Stephen Farrell; int-area@ietf.org
Objet : Re: [Int-area] WG adoption call: Availability of Information in 
Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On Apr 24, 2018, at 9:11 AM, 
> 
> wrote:
What sort of trade-offs can be added to Dave’s document? Do you have in mind 
something like:
(1)
-Warranting that logging may be misused for tracking users?
-Logging information can be used for profiling users?
-Not logging is also an option?

I don't think Dave's document is a good starting point.   Amelia (I think it 
was Amelia) already pointed out a number of things to talk about: for example, 
if you are going to log source ports, it should be possible to log them only 
when doing so is necessary, and not log them at other times.

[Med] Sure, if the intent was to discuss logging in general. But, when it comes 
to source ports in the context of address sharing, I’m adopting a distinct 
approach: whenever a server decides to log the IP address for abuse, it has to 
maintain a record of the source. Because otherwise, its records won’t be useful 
in case an important address ratio is used.

In other words, I don’t think we can mandate to a server if and when it has to 
log source IP address.

  This is a meaningful technical point that would have clear implications in 
the code that got written.

[Med] Isn’t the code for logging source IP address already there?

  It's not just a platitude to put in the privacy considerations section.   
That's what I have in mind too.

[Med] Fair.

So yes, of course we should say "there are problems with logging source ports, 
and these are some examples of the problems doing so can cause."

TBH, if I were an open source implementor, I would just ignore any advice about 
logging source ports, so if you want the document to have any relevance in that 
space, you have to give such people a reason for doing it and a basis for doing 
as little harm as possible.

[Med] IMHO, that part is already in 
https://tools.ietf.org/html/rfc6269#section-13.1 (Abuse Logging and Penalty 
Boxes)

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] draft-andersdotter (was RE: WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

2018-04-24 Thread mohamed.boucadair

Re-,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Amelia Andersdotter [mailto:ame...@article19.org]
> Envoyé : mardi 24 avril 2018 08:09
> À : BOUCADAIR Mohamed IMT/OLN; int-area@ietf.org
> Cc : Stephen Farrell
> Objet : Re: draft-andersdotter (was RE: [Int-area] WG adoption call:
> Availability of Information in Criminal Investigations Involving Large-Scale
> IP Address Sharing Technologies
> 
> Dear Mohamed,
> 
> See below:
> 
> On 2018-04-24 07:25, mohamed.boucad...@orange.com wrote:
> >
> > [Med] I don't have a problem with the general intent of your text, my
> concern is that you link those explicitly with RFC6302 which is misleading.
> RFC6302 has a very clear focus: address sharing.
> >
> > [Med] But how this is related to RFC6302 context?
> 
> RFC6302 is hopelessly out of date. It was specifically justified by a
> regulatory framework which no longer exists(!)

[Med] Hmm, 6302 says the following: 

   Discussions about data-retention policies are out of scope for this
   document.  

Further, if we suppose an extreme case where regulatory forbids logging source 
addresses, then 6302 won't contradict with those. 

 and it takes into account
> none of the privacy guidances given by RFC6973.
 If we mean to say the
> privacy guidelines of RFC6973 should not be applied specifically in our
> recommendations for logging to internet-facing servers, then fine.

[Med] This is subtle, 6302 is motivated by address sharing. 6302 does not 
recommend logging IP addresses per se, but if a server logs IP addresses for 
whatever reason (regulatory, prevent abuses, etc.), then it should consider the 
source port too. More discussion can be found in RFC6269. 

 If,
> however, we believe privacy guidelines apply also when we make
> recommendations to internet-facing servers (as we have done), then
> RFC6302 needs updating.

[Med] It is completely fine to have such analysis/discussion for logging in 
general, but as I said earlier 6302 has a clear scope: address sharing 
complications. 

> 
> I think this is the primary thing to establish. I'll provide more
> comments later.
> 
> best,
> 
> A
> 
> 
> --
> Amelia Andersdotter
> Technical Consultant, Digital Programme
> 
> ARTICLE19
> www.article19.org
> 
> PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

2018-04-23 Thread mohamed.boucadair

Hi Ted,

Please see inline.

Cheers,
Med

De : Ted Lemon [mailto:mel...@fugue.com]
Envoyé : lundi 23 avril 2018 17:55
À : BOUCADAIR Mohamed IMT/OLN
Cc : Stephen Farrell; int-area@ietf.org
Objet : Re: [Int-area] WG adoption call: Availability of Information in 
Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

On Apr 23, 2018, at 1:32 AM, 
mohamed.boucad...@orange.com wrote:
- **DOES NOT** define a new behavior: it relies on existing IETF RFCs.
- **DOES NOT** require logging another yet information: again, it relies on the 
various schemes discussed in existing RFCs.

If it doesn't define new behavior, why do we need it?

[Med] I confirm that Dave's I-D does not define a new behavior. It has the 
merit to discuss issues related to source ports. I do agree this is a minor 
contribution, but I like it because it is comprehensive.

Also, some of the documents you cite predate the rather extensive and evolving 
discussions that the IETF has since had on the issue of privacy.
[Med] Please note that we did already have that discussion in the past. Stephen 
suggested at that time (2014) to have a document 
(https://mailarchive.ietf.org/arch/msg/ietf-privacy/Xy0SZvTH_iU9ktlGyp8SpJZNDdQ),
 but unless I'm mistaken there is not such document.

Would you object to a new proposal that incorporated privacy issues as Stephen 
suggested in his first response on this topic?
[Med] Having a document is always welcome to assess whether what we claim is an 
issue or not. I recommend reading existing RFCs and consider carefully the 
language used; some of them was motivated by privacy considerations.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] draft-andersdotter (was RE: WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

2018-04-23 Thread mohamed.boucadair

Dear Amelia, 

Some comments about the main recommendations in draft-andersdotter: 

  SHOULD only store entire incoming IP addresses for as long as is
  necessary to provide the specific service requested by the user.

Med: This is implementation and deployment-specific. Not sure we can mandate a 
server how to service users.  

  SHOULD keep only the first two octets (of an IPv4 address) or the
  first three octets (of an IPv6 address) with remaining octets set
  to zero, when logging.

Med: A server can decide to follow this reco, but it will be difficult for the 
owner of the server to claim an abuse and help identifying responsibilities.  

Please note that RFC6302 ** does not recommend to log IP addresses** :.

   "It is RECOMMENDED as best current practice that Internet-facing
   servers logging incoming IP addresses from inbound IP traffic also
   log "

which means ** IF ** a server logs source IP address, then it has to log also 
the source port. 

  SHOULD NOT store logs of incoming IP addresses from inbound
  traffic for longer than three days.

Med: It is out of the scope of the IETF to define the duration of logs. This is 
country-specific. 

  SHOULD NOT log unnecessary identifiers, such as source port
  number, time stamps, transport protocol numbers or destination
  port numbers.

Med: Not sure to understand this one. "unnecessary identifiers" is not clear. I 
prefer the current language in 6302 which identifies the minimum set of 
information. 

  SHOULD ensure adequate log access control, with suitable
  mechanisms for keeping track of which entity accesses logged
  identifiers, for what reason and at what time.

Med: I hear you, but this is out of scope of the IETF. Access rights to 
retention data is well known and is not altered by the IETF specification. 

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Amelia
> Andersdotter
> Envoyé : lundi 23 avril 2018 10:11
> À : int-area@ietf.org
> Cc : Stephen Farrell
> Objet : Re: [Int-area] WG adoption call: Availability of Information in
> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
> 
> I've tabled a similar draft but with a different scope. Happy to discuss
> with members on the list:
> 
> https://datatracker.ietf.org/doc/draft-andersdotter-intarea-update-to-
> rfc6302/
> 
> --
> 
> Amelia Andersdotter
> Technical Consultant, Digital Programme
> 
> ARTICLE19
> www.article19.org
> 
> PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

2018-04-23 Thread mohamed.boucadair

Stephen, 

"I hope that we've learned that we need to do more thorough analyses
of the privacy implications of our work."

The discussion about privacy implications for 6302 occurred in the past either 
in intarea list or ietf-privacy: 

* https://mailarchive.ietf.org/arch/msg/int-area/uIvwbV0W4r8QhMfq1n5f5m32gO0 

Unfortunately, there is no such document that you asked for in 
https://mailarchive.ietf.org/arch/msg/ietf-privacy/Xy0SZvTH_iU9ktlGyp8SpJZNDdQ 
so that we can have something concrete to discuss. 

Cheers,
Med

> -Message d'origine-
> De : Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
> Envoyé : lundi 23 avril 2018 09:40
> À : BOUCADAIR Mohamed IMT/OLN; int-area@ietf.org
> Objet : Re: [Int-area] WG adoption call: Availability of Information in
> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
> 
> 
> Hiya,
> 
> We could trade references to existing BCPs and RFCs but I don't
> think we need to - I did not claim that the IETF had never done
> work in this space, nor that we ought not - my point was that
> such work being done at this point in time needs to take a
> broader perspective than the document concerned. (If for some
> reason it is helpful to trade references to existing BCPs and
> RFCs that argue for different approaches to privacy, I'm fine
> with doing that, but I hope it's not needed;-)
> 
> Below you say:
> 
> > The I-D inherits the same privacy implications of existing RFCs.
> 
> That would be a significant reason to not adopt the current document!
> 
> I hope that we've learned that we need to do more thorough analyses
> of the privacy implications of our work.
> 
> Cheers,
> S.
> 
> On 23/04/18 06:32, mohamed.boucad...@orange.com wrote:
> > Hi Stephen,
> >
> > The scope of this document is aligned with what the IETF has published in
> the past in this field. A list is provided below:
> >
> >1.   Identify logging as an issue in address sharing: RFC 6269
> >
> >2.   Require address sharing to enable a logging function: RFC 6269
> > and RFC 6888
> >
> >3.   Identify a minimal set of information to be logged: RFC 6269,
> > RFC 6888, and RFC 6908
> >
> >4.   Identify and discuss trade-offs of solutions to achieve logging:
> > RFC 6269, RFC 6908
> >
> >5.   Specify means to optimize logging (port range allocation,
> > deterministic NAT): draft-ietf-softwire-stateless-
> > 4v6-motivation, RFC 7596, RFC 7597, RFC 7599, RFC 7753, and
> > RFC7422
> >
> >6.   Recommend servers to log source port: RFC 6302
> >
> >7.   An initial survey of servers supporting source port logging: RFC
> > 7768 (ISE)
> >
> >8.   Retrieve NAT session loggings: draft-ietf-behave-syslog-nat-
> > logging, RFC 8158
> >
> >9.  CPU and memory issues: RFC 6908
> >
> > As such, this I-D:
> > - **DOES NOT** define a new behavior: it relies on existing IETF RFCs.
> > - **DOES NOT** require logging another yet information: again, it relies on
> the various schemes discussed in existing RFCs.
> >
> > The I-D inherits the same privacy implications of existing RFCs.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> DeÂ : Int-area [mailto:int-area-boun...@ietf.org] De la part de Stephen
> >> Farrell
> >> EnvoyÃ©Â : samedi 21 avril 2018 18:24
> >> Ã€Â : int-area@ietf.org
> >> ObjetÂ : [Int-area] WG adoption call: Availability of Information in
> Criminal
> >> Investigations Involving Large-Scale IP Address Sharing Technologies
> >>
> >>
> >> Hiya,
> >>
> >> I've read this draft and do not support adoption of a
> >> draft with this scope.
> >>
> >> I do support consideration of how law enforcement
> >> investigations can be carried out, but not without a
> >> similar level of consideration of the real trade-offs
> >> between assisting law enforcement and commercial or
> >> other surveillance. At present, the draft is nowhere
> >> near sufficient in this respect. (Despite saying that
> >> "Clearly a balance needs to be struck between individual
> >> right to privacy and law enforcement access to data
> >> during criminal investigations" the draft is anything
> >> but balanced in that respect.)
> >>
> >> I don't think that this problem is a thing that'd be
> >> reasonable to try fix after WG adoption, but needs to be
> >> handled beforehand as it's a fundamental scope issue.
> >>
> >> In other words, I believe this draft just has the wrong
> >> scope, and if adopted would be likely quite controversial
> >> before publication. In contrast, a draft that really does
> >> consider the trade-offs related to logging could be quite
> >> valuable and if it provided a balanced approach might even
> >> not be controversial.
> >>
> >> (FWIW, I might be willing to try help out a bit on a draft
> >> that did have what I think is an appropriate scope, as I do
> >> think more appropriate logging is a reasonable goal. But
> >> before accepting that offer be aware that IMO sometimes
> >> "more

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

2018-04-22 Thread mohamed.boucadair

Hi Brian, 

The issue discussed in this I-D applies each time you have to share an IPv4 
address. This covers IPv4 service continuity mechanism with IPv6-only 
connectivity such as: NAT64, DS-Lite, MAP-E, MAP-T and lw4o6. 

There is IMHO a value in socializing the IETF BCP and help 
servers/implementation fixing this.  

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Brian E
> Carpenter
> Envoyé : dimanche 22 avril 2018 07:31
> À : int-area@ietf.org
> Cc : Stephen Farrell
> Objet : Re: [Int-area] WG adoption call: Availability of Information in
> Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
> 
> On 22/04/2018 04:24, Stephen Farrell wrote:
> >
> > Hiya,
> >
> > I've read this draft and do not support adoption of a
> > draft with this scope.
> 
> I see that this draft started its life as a submission to
> the Independent Submissions editor:
> https://datatracker.ietf.org/doc/conflict-review-daveor-cgn-logging/
> The IESG is probably correct about the overlap, but I think I agree
> with Stephen that the draft is scoped as if port logging is always
> OK. That's a possible scope for an Independent Submission to
> choose, but clearly getting IETF consensus on it is another question.
> 
> However, WG adoption doesn't imply accepting the contents, only
> the topic. Actually it transforms the authors from independent actors
> into servants of the WG. So from a formal viewpoint Stephen is wrong:
> the WG can decide to completely change the scope and viewpoint of the
> draft, even if the authors disagree. I certainly think a discussion
> of the downsides is needed, and the cross-WG reviews that Stephen
> mentions.
> 
> I do have another comment about adoption. This is an IPv4 technology.
> Do we really want to spent IETF cycles on it? I'd prefer that we
> adopt https://tools.ietf.org/html/draft-george-ipv6-support-03 .
> 
>Brian
> 
> >
> > I do support consideration of how law enforcement
> > investigations can be carried out, but not without a
> > similar level of consideration of the real trade-offs
> > between assisting law enforcement and commercial or
> > other surveillance. At present, the draft is nowhere
> > near sufficient in this respect. (Despite saying that
> > "Clearly a balance needs to be struck between individual
> > right to privacy and law enforcement access to data
> > during criminal investigations" the draft is anything
> > but balanced in that respect.)
> >
> > I don't think that this problem is a thing that'd be
> > reasonable to try fix after WG adoption, but needs to be
> > handled beforehand as it's a fundamental scope issue.
> >
> > In other words, I believe this draft just has the wrong
> > scope, and if adopted would be likely quite controversial
> > before publication. In contrast, a draft that really does
> > consider the trade-offs related to logging could be quite
> > valuable and if it provided a balanced approach might even
> > not be controversial.
> >
> > (FWIW, I might be willing to try help out a bit on a draft
> > that did have what I think is an appropriate scope, as I do
> > think more appropriate logging is a reasonable goal. But
> > before accepting that offer be aware that IMO sometimes
> > "more appropriate" ought mean only logging minimal data for
> > a very short period and then thoroughly scrubbing all of
> > that:-)
> >
> > Separately, if a document on this topic is to be adopted
> > by any IETF WG, I think the adoption call ought be widely
> > circulated (esp to saag, and art-area lists) as this is a
> > topic that is likely to attract interest from various folks
> > in other areas, and it'd be much better to figure out early
> > and not late if others also see problems with this draft.
> >
> > Cheers,
> > S.
> >
> > PS: I'm not subscribed to the int-area list so please do
> > cc' me on any follow ups.
> >
> >
> >
> >
> >
> > ___
> > Int-area mailing list
> > Int-area@ietf.org
> > https://www.ietf.org/mailman/listinfo/int-area
> >
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

2018-04-22 Thread mohamed.boucadair

Hi Stephen,

The scope of this document is aligned with what the IETF has published in the 
past in this field. A list is provided below:

   1.   Identify logging as an issue in address sharing: RFC 6269

   2.   Require address sharing to enable a logging function: RFC 6269
and RFC 6888

   3.   Identify a minimal set of information to be logged: RFC 6269,
RFC 6888, and RFC 6908

   4.   Identify and discuss trade-offs of solutions to achieve logging:
RFC 6269, RFC 6908

   5.   Specify means to optimize logging (port range allocation,
deterministic NAT): draft-ietf-softwire-stateless-
4v6-motivation, RFC 7596, RFC 7597, RFC 7599, RFC 7753, and
RFC7422

   6.   Recommend servers to log source port: RFC 6302

   7.   An initial survey of servers supporting source port logging: RFC
7768 (ISE)

   8.   Retrieve NAT session loggings: draft-ietf-behave-syslog-nat-
logging, RFC 8158

   9.  CPU and memory issues: RFC 6908

As such, this I-D:
- **DOES NOT** define a new behavior: it relies on existing IETF RFCs.
- **DOES NOT** require logging another yet information: again, it relies on the 
various schemes discussed in existing RFCs.

The I-D inherits the same privacy implications of existing RFCs. 

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Stephen
> Farrell
> Envoyé : samedi 21 avril 2018 18:24
> À : int-area@ietf.org
> Objet : [Int-area] WG adoption call: Availability of Information in Criminal
> Investigations Involving Large-Scale IP Address Sharing Technologies
> 
> 
> Hiya,
> 
> I've read this draft and do not support adoption of a
> draft with this scope.
> 
> I do support consideration of how law enforcement
> investigations can be carried out, but not without a
> similar level of consideration of the real trade-offs
> between assisting law enforcement and commercial or
> other surveillance. At present, the draft is nowhere
> near sufficient in this respect. (Despite saying that
> "Clearly a balance needs to be struck between individual
> right to privacy and law enforcement access to data
> during criminal investigations" the draft is anything
> but balanced in that respect.)
> 
> I don't think that this problem is a thing that'd be
> reasonable to try fix after WG adoption, but needs to be
> handled beforehand as it's a fundamental scope issue.
> 
> In other words, I believe this draft just has the wrong
> scope, and if adopted would be likely quite controversial
> before publication. In contrast, a draft that really does
> consider the trade-offs related to logging could be quite
> valuable and if it provided a balanced approach might even
> not be controversial.
> 
> (FWIW, I might be willing to try help out a bit on a draft
> that did have what I think is an appropriate scope, as I do
> think more appropriate logging is a reasonable goal. But
> before accepting that offer be aware that IMO sometimes
> "more appropriate" ought mean only logging minimal data for
> a very short period and then thoroughly scrubbing all of
> that:-)
> 
> Separately, if a document on this topic is to be adopted
> by any IETF WG, I think the adoption call ought be widely
> circulated (esp to saag, and art-area lists) as this is a
> topic that is likely to attract interest from various folks
> in other areas, and it'd be much better to figure out early
> and not late if others also see problems with this draft.
> 
> Cheers,
> S.
> 
> PS: I'm not subscribed to the int-area list so please do
> cc' me on any follow ups.
> 
> 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] WG adoption call: Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies

2018-04-20 Thread mohamed.boucadair

Hi all,

I support this document to be adopted as an informational document.

Cheers,
Med

De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Juan Carlos 
Zuniga
Envoyé : jeudi 19 avril 2018 17:38
À : int-area
Objet : [Int-area] WG adoption call: Availability of Information in Criminal 
Investigations Involving Large-Scale IP Address Sharing Technologies


Dear all,



After some discussions on the v6ops and intarea mailing lists, the author of 
draft-daveor-cgn-logging is requesting its adoption by the IntArea WG.



Hence, we would like to start a WG adoption call for 
draft-daveor-cgn-logging-04 
https://tools.ietf.org/html/draft-daveor-cgn-logging-04.



Please indicate your preferences/comments on the mailing list. The deadline is 
May the 4th.



Best,



Juan Carlos & Wassim

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Re draft-daveor-cgn-logging-02/RFC6302

2018-04-09 Thread mohamed.boucadair

Hi Dave, 

The proposed text would work. 

Cheers,
Med

> -Message d'origine-
> De : Dave O'Reilly [mailto:r...@daveor.com]
> Envoyé : lundi 9 avril 2018 14:43
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : int-area@ietf.org
> Objet : Re: [Int-area] Re draft-daveor-cgn-logging-02/RFC6302
> 
> The only problem that I have with this is the use of the word “should” - I
> hope I’m not splitting hairs here, but I think there is a slight risk of
> "victim blaming".
> 
> Consider the scenario where the entity with the Internet-facing server (and
> therefore with the logs) is a victim of some sort of crime. They have the
> required logs but they weren’t aware that there was a time offset with
> reference to a global time source. Again, this is something that happens all
> the time. Interpreted in this context, I think an indication of what they
> should have been doing might be a bit on the strong side. What do you think?
> 
> What about this weaker-worded alternative:
> 
> “If the entity controlling the server is aware that there is an offset
> required to synchronise with a global time source, it is expected that the
> offset would be indicated by the entity while the logs were being collected.”
> 
> daveor
> 
> 
> > On 9 Apr 2018, at 07:26, 
>  wrote:
> >
> > Hi Dave,
> >
> > What about:
> >
> > "The entity which owns the server should indicate the required offset to
> synchronize with a global time source."
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Dave O'Reilly [mailto:r...@daveor.com]
> >> Envoyé : samedi 7 avril 2018 16:31
> >> À : BOUCADAIR Mohamed IMT/OLN
> >> Cc : int-area@ietf.org
> >> Objet : Re: [Int-area] Re draft-daveor-cgn-logging-02/RFC6302
> >>
> >> Hi Mohamed,
> >>
> >> I dont agree with this bit:
> >>
> >>> Adjusting the log records to synchronize with a global time source is the
> >> responsibility of the entity which owns the server.
> >>
> >> I think that both in principle and in practice this
> >> synchronisation/correction would be carried out by law enforcement as part
> of
> >> their investigation. There might, I suppose, be an expectation that a
> server
> >> operator would indicate if there was a difference between the times in
> their
> >> logs and a standard time reference but in any case the law enforcement
> >> officer is going to have to go through the logs and calibrate the times in
> >> the context of whatever matter they are investigating.
> >>
> >> The log data plus analysis/calibration would form part of the
> justification
> >> for issuing a subpoena for CGN records (depending on jurisdiction), and
> the
> >> law enforcement officer would have to be able to stand over the grounds
> for
> >> accessing the logs if the request is challenged. If the information being
> >> requested is heavily dependent on the accuracy of the times stated in the
> >> request, as might be the case if CGN was in use, one could reasonably
> expect
> >> to be asked to justify that the times indicated are accurate (with
> reference
> >> to some sort of time standard) - at which point the law enforcement
> officer,
> >> forensic analyst, or whoever gathered the evidence would need to be able
> to
> >> explain how they concluded that the times in the subpoena were the correct
> >> ones. This would presumably include any offset calibration that was
> carried
> >> out, or at least the results of an investigation to confirm that such a
> >> calibration was not required.
> >>
> >> Also, if a server operator adjusted the times in logs before providing
> them
> >> as evidence, it is not beyond the realm of possibility that the
> >> authenticity/integrity of the evidence could be challenged because the log
> >> data has been altered since it was recorded.
> >>
> >> Regards,
> >> daveor
> >>
> >>> On 6 Apr 2018, at 08:03, 
> >>  wrote:
> >>>
> >>> Hi Dave,
> >>>
> >>> Glad to see that we are in agreement.
> >>>
> >>> I don't think that those sections are needed for the reasons explained in
> >> my previous message.
> >>>
> >>> One way to avoid misinterpreting your draft as conflicting with existing
> >> RFCs is to tweak section 7.4, e.g.:
> >>>
> >>> OLD:
> >>>
> >>>  There are many reasons why it is may not be possible to record logs
> >>>  with reference to a centralised time source (e.g.  NTP).  This could
> >>>  include scenarios should as security sensitive networks, or internal
> >>>  production networks.  Times MAY OPTIONALLY be recorded with reference
> >>>  to a centralised time source (e.g.  NTP) but this is not necessary.
> >>>  As long as times are recorded consistently, it should be possible to
> >>>  measure the offset from a reference time source if required for the
> >>>  purposes of quering records at another source.  This is common
> >>>  practice in digital forensics.
> >>>
> >>> NEW:
> >>>
> >>>  There are many reasons why it may not be

Re: [Int-area] Re draft-daveor-cgn-logging-02/RFC6302

2018-04-09 Thread mohamed.boucadair

Hi Dave, 

What about: 

"The entity which owns the server should indicate the required offset to 
synchronize with a global time source."

Cheers,
Med

> -Message d'origine-
> De : Dave O'Reilly [mailto:r...@daveor.com]
> Envoyé : samedi 7 avril 2018 16:31
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : int-area@ietf.org
> Objet : Re: [Int-area] Re draft-daveor-cgn-logging-02/RFC6302
> 
> Hi Mohamed,
> 
> I dont agree with this bit:
> 
> > Adjusting the log records to synchronize with a global time source is the
> responsibility of the entity which owns the server.
> 
> I think that both in principle and in practice this
> synchronisation/correction would be carried out by law enforcement as part of
> their investigation. There might, I suppose, be an expectation that a server
> operator would indicate if there was a difference between the times in their
> logs and a standard time reference but in any case the law enforcement
> officer is going to have to go through the logs and calibrate the times in
> the context of whatever matter they are investigating.
> 
> The log data plus analysis/calibration would form part of the justification
> for issuing a subpoena for CGN records (depending on jurisdiction), and the
> law enforcement officer would have to be able to stand over the grounds for
> accessing the logs if the request is challenged. If the information being
> requested is heavily dependent on the accuracy of the times stated in the
> request, as might be the case if CGN was in use, one could reasonably expect
> to be asked to justify that the times indicated are accurate (with reference
> to some sort of time standard) - at which point the law enforcement officer,
> forensic analyst, or whoever gathered the evidence would need to be able to
> explain how they concluded that the times in the subpoena were the correct
> ones. This would presumably include any offset calibration that was carried
> out, or at least the results of an investigation to confirm that such a
> calibration was not required.
> 
> Also, if a server operator adjusted the times in logs before providing them
> as evidence, it is not beyond the realm of possibility that the
> authenticity/integrity of the evidence could be challenged because the log
> data has been altered since it was recorded.
> 
> Regards,
> daveor
> 
> > On 6 Apr 2018, at 08:03, 
>  wrote:
> >
> > Hi Dave,
> >
> > Glad to see that we are in agreement.
> >
> > I don't think that those sections are needed for the reasons explained in
> my previous message.
> >
> > One way to avoid misinterpreting your draft as conflicting with existing
> RFCs is to tweak section 7.4, e.g.:
> >
> > OLD:
> >
> >   There are many reasons why it is may not be possible to record logs
> >   with reference to a centralised time source (e.g.  NTP).  This could
> >   include scenarios should as security sensitive networks, or internal
> >   production networks.  Times MAY OPTIONALLY be recorded with reference
> >   to a centralised time source (e.g.  NTP) but this is not necessary.
> >   As long as times are recorded consistently, it should be possible to
> >   measure the offset from a reference time source if required for the
> >   purposes of quering records at another source.  This is common
> >   practice in digital forensics.
> >
> > NEW:
> >
> >   There are many reasons why it may not be possible for servers to record
> logs
> >   with reference to a global time source.  This could
> >   include scenarios such as security sensitive networks, or internal
> >   production networks. As long as times are recorded consistently, it
> should be possible to
> >   measure the offset from a traceable global time source (if required) for
> the
> >   purposes of querying records at another source. Adjusting the log records
> to
> >   synchronize with a global time source is the responsibility of the entity
> >   which owns the server.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Dave O'Reilly [mailto:r...@daveor.com]
> >> Envoyé : jeudi 5 avril 2018 16:29
> >> À : BOUCADAIR Mohamed IMT/OLN
> >> Cc : int-area@ietf.org
> >> Objet : Re: [Int-area] Re draft-daveor-cgn-logging-02/RFC6302
> >>
> >> Hi Mohamed,
> >>
> >> Thanks for your mail.
> >>
> >> I agree with you.
> >>
> >> The only reason I put these sections in here was because the IESG conflict
> >> review indicated a conflict between this document and the other two RFCs
> >> mentioned (Ref: https://datatracker.ietf.org/doc/conflict-review-daveor-
> cgn-
> >> logging/). In an effort to reconcile the feedback received with the
> content
> >> of draft-daveor-cgn-logging, I added these sections.
> >>
> >> Perfectly happy to remove them if that is the way the consensus emerges.
> >>
> >> daveor
> >>
> >>
> >>> On 5 Apr 2018, at 15:24, 
> >>  wrote:
> >>>
> >>> Hi Dave,
> >>>
> >>> I have a comment

Re: [Int-area] Re draft-daveor-cgn-logging-02/RFC6302

2018-04-05 Thread mohamed.boucadair

Hi Dave, 

I have a comment about the proposed update to RFC 6269 (the same comment 
applies for RFC6302, though). 

Actually, the proposed NEW text will require an extra effort to align 
timestamps among the server which maintains the logs, the authorities that 
relay an abuse claim, and the provider who manages the CGN. That extra effort 
has to be done by the entity managing the log server. 

From that standpoint, the proposed NEW text is no more than another example of 
"Accurate time-keeping"...which IMHO does not justify an update to the 6269. 

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Dave O'Reilly
> Envoyé : mercredi 4 avril 2018 22:26
> À : int-area@ietf.org
> Objet : Re: [Int-area] Re draft-daveor-cgn-logging-02/RFC6302
> 
> Dear all,
> 
> Further to my email below, I have revised draft-daveor-cgn-logging and
> revision -03 is now available. I have restructured the content into the form
> of recommendations.
> 
> Here’s the link: https://tools.ietf.org/html/draft-daveor-cgn-logging-03
> 
> I have also included, at sections 7.6 and 7.7, proposed amendments to RFC6302
> and RFC6269 respectively.
> 
> Regards,
> daveor
> 
> > On 20 Mar 2018, at 13:45, Dave O'Reilly  wrote:
> >
> > Dear all,
> >
> > further to presenting at IETF-101 yesterday I wanted to send a follow up
> email to see if there is interest in working on a new best current practice
> for logging at internet-facing servers.
> >
> > I hope I adequately presented the reasons why I think there needs to be
> some revision of the recommendations of RFC6302 and that there is some
> additional points to be considered in draft-daveor-cgn-logging-02.
> >
> > The current version of the document (draft-daveor-cgn-logging-02) contains
> recommendations, but it is not really in the form of a BCP. If there is
> interest, I would like to suggest, in the first instance at least, that I
> prepare a new version of the document, structured in the form of a BCP with a
> set of recommendations for discussion.
> >
> > Any feedback would be appreciated.
> >
> > Thanks and best regards,
> > daveor
> >
> > ___
> > Int-area mailing list
> > Int-area@ietf.org
> > https://www.ietf.org/mailman/listinfo/int-area
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

2017-07-20 Thread mohamed.boucadair

Good suggestion, Tom.

Thanks.

Cheers,
Med

> -Message d'origine-
> De : Tom Herbert [mailto:t...@herbertland.com]
> Envoyé : jeudi 20 juillet 2017 17:39
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Joe Touch; Olivier Bonaventure; Internet Area; tsv-a...@ietf.org
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 
> On Thu, Jul 20, 2017 at 8:26 AM,   wrote:
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Joe Touch [mailto:to...@isi.edu]
> >> Envoyé : jeudi 20 juillet 2017 16:37
> >> À : BOUCADAIR Mohamed IMT/OLN; Olivier Bonaventure; Internet Area; tsv-
> >> a...@ietf.org
> >> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> >>
> >>
> >>
> >> On 7/19/2017 10:39 PM, mohamed.boucad...@orange.com wrote:
> >> > Hi Joe,
> >> >
> >> > The text can always be worked out. This is not an IETF LC :)
> >> Agreed - I was explaining that the current text - and many of the
> >> responses in this chain, both from you and others, continues to be
> >> confusing.
> >>
> > [Med] Calling out those confusing points would help.
> >
> >> > The main point is that we are following your suggestion to define the
> >> solution as an application proxy using a dedicated port number.
> >> As feedback for the doc, that could be made more explicit, including in
> >> the title (this is an application proxy, not typically referred to as
> >> middleboxes).
> >>
> >
> > [Med] Looks like a good idea to me.
> >
> That use of the term middleboxes as opposed to proxy was also
> confusing to me. I'd also suggest not to call this a netwotk function,
> that has other connotations that don't apply here.
> 
> Tom
> 
> >> That also includes limiting the doc to using TCP app-layer APIs and
> >> describing any behavior that *might* happen at the segment level as
> just
> >> that - hypothetical, perhaps desired, but NOT the mechanism being
> >> proposed.
> >>
> >> FWIW.
> >>
> >> Joe
> >
> > ___
> > Int-area mailing list
> > Int-area@ietf.org
> > https://www.ietf.org/mailman/listinfo/int-area
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

2017-07-20 Thread mohamed.boucadair

Re-,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Joe Touch [mailto:to...@isi.edu]
> Envoyé : jeudi 20 juillet 2017 16:37
> À : BOUCADAIR Mohamed IMT/OLN; Olivier Bonaventure; Internet Area; tsv-
> a...@ietf.org
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 
> 
> 
> On 7/19/2017 10:39 PM, mohamed.boucad...@orange.com wrote:
> > Hi Joe,
> >
> > The text can always be worked out. This is not an IETF LC :)
> Agreed - I was explaining that the current text - and many of the
> responses in this chain, both from you and others, continues to be
> confusing.
> 
[Med] Calling out those confusing points would help.  

> > The main point is that we are following your suggestion to define the
> solution as an application proxy using a dedicated port number.
> As feedback for the doc, that could be made more explicit, including in
> the title (this is an application proxy, not typically referred to as
> middleboxes).
> 

[Med] Looks like a good idea to me.

> That also includes limiting the doc to using TCP app-layer APIs and
> describing any behavior that *might* happen at the segment level as just
> that - hypothetical, perhaps desired, but NOT the mechanism being
> proposed.
>
> FWIW.
> 
> Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] Open issue: rfc6040update & SFC

2017-07-20 Thread mohamed.boucadair

Bob,

You asked during your presentation whether SFC is to be marked as N/A.

I confirm. SFC encapsulation is not a transport encapsulation. ECN should be 
managed by the transport encapsulation used within an SFC-enabled domain.

You have a long list of encap protocols; it is actually cool to reduce that 
list by one :)

Cheers,
Med
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

Re-,

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch
> Envoyé : mercredi 19 juillet 2017 21:58
> À : Olivier Bonaventure; Internet Area; tsv-a...@ietf.org
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 
> 
> 
> On 7/19/2017 12:51 PM, Olivier Bonaventure wrote:
> > Joe,
> 
>  On 7/19/2017 12:41 AM, Olivier Bonaventure wrote:
> >> - IMO, TCP always needs to be able to fall back (which should be
> >> true now)
> >
> > This is not a concern with the proposed design
>  Prove that is true if/when TCP-AO is enabled.
> >>>
> >>> I don't think that TCP-AO is a use case for the proposed converters.
> >>
> >> You don't get to decide that. If you use TCP, then TCP-AO could be
> >> enabled on the client.
> >
> > The converter is not intended to be used for all TCP connections. In
> > the draft we explain how an MPTCP endpoint can bypass the converter if
> > the destination server supports MPTCP. For TCP-AO, my recommendation
> > would be that the default policy of the client would be to never use
> > the converter if TCP-AO is requested by the application.
> 
> How do you know you're using the converter?

[Med] The converter is explicilty configured (e.g., locally configured or y 
means of https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-07). 

 Is the initial connection to
> that converter?

[Med] When a connection is eligible to network-assisted MPTCP, the first 
subflow will be established via the converter. Subsequent flows will be 
established with that proxy involved. Packets are sent with destination IP 
address set to the one of the converter. 

 Or does the converter hijack (the latter is the
> implication of the text, AFAICT).
> 
> Joe
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

Hi Joe, 

The text can always be worked out. This is not an IETF LC :)

The main point is that we are following your suggestion to define the solution 
as an application proxy using a dedicated port number. 

Cheers,
Med

> -Message d'origine-
> De : Joe Touch [mailto:to...@isi.edu]
> Envoyé : mercredi 19 juillet 2017 21:46
> À : BOUCADAIR Mohamed IMT/OLN; Olivier Bonaventure; Internet Area; tsv-
> a...@ietf.org
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 
> 
> 
> On 7/19/2017 11:43 AM, mohamed.boucad...@orange.com wrote:
> > I don't understand your argument here, especially because you are the
> one who proposed me the following (check mptcp archives, April 20, 2017)
> which we endorsed in the latest version of the specification:
> >
> > "If that were the case, you'd simply be defining a new application
> service and asking for a TCP port number."
> >
> > Are you saying that you suggested us a bad design choice?
> The text I saw talks about SYN packets.
> 
> If this is at the application layer - and doesn't hijack TCP connections
> to other IP addresses - then it's fine, but then the ID is very badly in
> need of revision. I'm working off the text I saw.
> 
> Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

Re-, 

I don't understand your argument here, especially because you are the one who 
proposed me the following (check mptcp archives, April 20, 2017) which we 
endorsed in the latest version of the specification:

"If that were the case, you'd simply be defining a new application service and 
asking for a TCP port number."

Are you saying that you suggested us a bad design choice?

Thank you.

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch
> Envoyé : mercredi 19 juillet 2017 18:43
> À : Olivier Bonaventure; Internet Area; tsv-a...@ietf.org
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 
> 
> 
> On 7/19/2017 12:41 AM, Olivier Bonaventure wrote:
> > Joe,
> >
> >> - but I remain concerned with "injection piggybacking"
> >
> > To which section of the draft are you referring to ?
> It starts in the arch discussion in Sec 2:
> 
>As shown in Figure 3, the Converter places its supplied information
>inside the handshake packets.
> 
> That's what I refer to as "injection piggybacking"
> 
>With TCP, the Converter protocol places the destination address and
>port number of the final Server in the payload of the SYN.
> 
> And that is the part that violates RFC793 semantics when that SYN reaches
> the final destination rather than the server-side proxy.
> 
> To be clear, I'm not interested in further trying to "fix" this mechanism
> so it can work. It can't and it shouldn't IMO. Let's use our cycles for
> more productive things.
> 
> Joe
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

Re-,

Please see inline.

Cheers,
Med

> -Message d'origine-
> De : Joe Touch [mailto:to...@isi.edu]
> Envoyé : mercredi 19 juillet 2017 18:36
> À : BOUCADAIR Mohamed IMT/OLN; Erik Kline
> Cc : Tom Herbert; Internet Area; tsv-a...@ietf.org
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 
> 
> 
> On 7/19/2017 1:46 AM, mohamed.boucad...@orange.com wrote:
> > So making use of MPTCP to grab more resources (when available) or to
> provide better resiliency (when a network attachment is lost) will require
> both endpoints to be MPTCP-capable.
> That is both correct and appropriate.
> 
[Med] OK. 

> Doing tricks to demonstrate that an attacker (i.e., something that
> modifies TCP segments on path) can do otherwise should not be considered
> a viable alternative.

[Med] We are defining an application proxy that assist the user to maximize the 
use of its available network resources. The proxy relies on IETF defined BCPs 
(defined by behave and tsvwg) to relay TCP packets. 

> Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

Joe,

As mentioned in a previous message in this thread, TCP-AO extensions (6978) to 
pass NATs will be required otherwise TCP-AO will fail because of:

-Manipulating multiple addresses

-At least one of the source IP addresses will be rewritten.

The proxy design does not induce a new issue for TCP-AO.

Cheers,
Med

De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch
Envoyé : mercredi 19 juillet 2017 18:33
À : Olivier Bonaventure; Internet Area; tsv-a...@ietf.org
Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP




On 7/19/2017 12:41 AM, Olivier Bonaventure wrote:
- IMO, TCP always needs to be able to fall back (which should be true now)

This is not a concern with the proposed design
Prove that is true if/when TCP-AO is enabled.
Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

Re-,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Tom Herbert [mailto:t...@herbertland.com]
> Envoyé : mercredi 19 juillet 2017 17:45
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Joe Touch; tsv-a...@ietf.org; Internet Area
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 
> On Tue, Jul 18, 2017 at 11:37 PM,   wrote:
> > Hi Tom,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Tom
> Herbert
> >> Envoyé : mercredi 19 juillet 2017 00:43
> >> À : Joe Touch
> >> Cc : tsv-a...@ietf.org; Internet Area
> >> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> >>
> >> On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch  wrote:
> >> > Hi, all,
> >> >
> >> > I've noted this before, but to share with other areas:
> >> >
> >> > Although I'm not averse to middleboxes as optional optimizations, I
> find
> >> > the proposed mechanisms aren't quite optional -- they inject option
> >> > information into the SYN data. That information would poison a
> >> > connection to a legacy receiver if (more to the point, when) that
> info
> >> > isn't removed by a proxy upstream of the receiver.
> >> >
> >> > TCP must be E2E and fall back to legacy endpoints without a
> reconnection
> >> > attempt, as required by RFC793.
> >> >
> >> > These aren't generic solutions; they're attacks on a TCP connection,
> >> IMO.
> >> >
> >> I agree. This seems be akin to stateful firewalls model that impose
> >> artificial requirements on networking (like every TCP packet for a
> >> connection must got through some middlebox or the connection is
> >> dropped). We need to move things back to E2E semantics for transport
> >> protocols-- nodes that try to maintain transport state in the network
> >> should be considered the problem not the solution!
> >>
> >
> > [Med] We would love to avoid requiring adding a function in the network
> to assist devices to make use of their multiple interfaces/paths.
> Nevertheless, the situation is that servers do not support MPTCP.
> >
> > The proposed solution allows to:
> > * elect some flows to benefit from network-assisted MPTCP while avoiding
> session failures.
> > * Policies are configured to identify traffic that won't be forwarded
> via a proxy
> > * 0-RTT proxying
> > * MPTCP can be used e2e if both end points are MPTCP-capable (that is,
> the proxy is withdrawn from the path).
> > * No interference with TCP options to be negotiated between endpoints.
> >
> > Do you have in mind such use cases when you referred to the "stateful
> firewalls model"?
> 
> One of the problems with stateful firewalls (as well as transparent
> proxies) is that they require all packets for a flow to consistently
> traverse the same middlebox device. The middlebox is not addressed by
> the packet,

[Med] This is not the actual proposal. The proxy is explicitly configured so 
that all packets are sent to it directly. That is, the destination address of 
outgoing packets will be set to the one of that proxy.  

 so the assumed requirement is that packets for the flow go
> though the same network node by virtue of routing. For a firewall in a
> single-homed site to the Internet this works because the firewall is
> the only egress/ingress point to the network. If a site is
> multi-homed, then the hope is that routing of packets in both
> directions will go through the same point. But there is absolutely no
> requirement that network layer packets for a flow are always routed
> the same way, and if routing does change and packets need to flow
> through different points the session breaks.
> 

[Med] I fully agree with you. But, we are not in a transparent/implicit mode. 

> If I'm reading the draft correctly, then it has the same property of
> maintaining transport state in the network so it implies the same
> requirement that all packets for a flow follow the same path.

[Med] We don't have such requirement.  The proxy is not supposed to be on one 
of the default forwarding paths; all what we require is that it is reachable 
using any of the available paths. Subflows can be placed using any or all of 
the available paths.

> Personally,  would find it ironic that a a protocol to allow muli-path
> transport would require the network layer to be single path.
>

[Med] Sorry, but we don’t have such constraint/requirement. See my explanation 
above.

 
> Tom
> 
> >
> >> Tom
> >>
> >> > Joe
> >> >
> >> >
> >> > On 7/18/2017 3:22 PM, Olivier Bonaventure wrote:
> >> >> The working group has discussed this issue several times and today
> we
> >> >> have presented a new design that supports the creation of such
> >> >> functions to convert MPTCP connections into TCP connections and vice
> >> >> versa. The design was done with MPTCP in mind, but the proposed
> >> >> solution could be more generic and applied to other use cases than
> >> >> MPTCP. The

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

Hi Erik,

That's the intuitive approach to follow but unfortunately the situation is not 
that obvious to get into. 

Network providers do not have a control on the servers and the terminals that 
are enabled by customers behind the CPE. So making use of MPTCP to grab more 
resources (when available) or to provide better resiliency (when a network 
attachment is lost) will require both endpoints to be MPTCP-capable. 

We are in a situation where customers are provided with multiple accesses but 
these customers do only have the QoE as if they are single-connected. 

The network-assisted MPTCP is a feature to have immediately the benefits of 
MPTCP without requiring that all terminals and servers are MPTCP-capable.

The design we are advocating for allows for the use of MPTCP along the path 
when both endpoints are MPTCP-capable and to bypass the proxy when it makes 
sense.

Cheers,
Med

> -Message d'origine-
> De : Erik Kline [mailto:e...@google.com]
> Envoyé : mercredi 19 juillet 2017 10:30
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Tom Herbert; Joe Touch; Internet Area; tsv-a...@ietf.org
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 
> > [Med] We would love to avoid requiring adding a function in the network
> to assist devices to make use of their multiple interfaces/paths.
> Nevertheless, the situation is that servers do not support MPTCP.
> 
> If server infrastructures aren't supporting MPTCP, maybe that's the
> thing that needs to be looked at...if in fact it can be helped.
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

Hi Joe,

Please see inline.

Cheers,
Med

De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Joe Touch
Envoyé : mercredi 19 juillet 2017 01:12
À : Olivier Bonaventure; Internet Area; tsv-a...@ietf.org
Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP




On 7/18/2017 4:05 PM, Olivier Bonaventure wrote:
Although I'm not averse to middleboxes as optional optimizations, I find
the proposed mechanisms aren't quite optional -- they inject option
information into the SYN data. That information would poison a
connection to a legacy receiver if (more to the point, when) that info
isn't removed by a proxy upstream of the receiver.

This paragraph refers to earlier documents discussed in the MPTCP
working group. The new design does not inject option information into
the SYN data. It works like an application layer protocol that sends messages
in the SYN by using the TFO option. There is no risk of poisoning.

OK, in that case:
- I'm still not averse to middleboxes that accelerate or enhance TCP
[Med] The proposal leverages on existing IETF RFCs and BCPs to assist 
establishing communications over multiple paths even if the remote server is 
not MPTCP-capable. BTW, we integrated almost all the suggestions you made 
previously (e.g., use a dedicated service port, figure out how to use TFO to 
get TFO performance).


- IMO, TCP always needs to be able to fall back (which should be true now)
[Med] We are not interfering with this.

- but I remain concerned with "injection piggybacking"
- even if this is restricted to option space, it increases the risk of 
damaging an otherwise working connection
[Med] I don’t understand your reference to the option space.

- it flies in the face of TCP being E2E, and won't work with TCP-AO or 
IPsec, which IMO means it can't be considered part of "TCP" at all
[Med] Two comments here:

· It seems that you assume all the traffic will be systematically 
relayed to a proxy. This is not the assumption we have in the mptcp WG.

· The mechanisms you mentioned are known to have issues with NAT; 
extensions exist to soften some of them. I don’t see a new issue out there when 
it come to an network-assisted MPTCP proxy.


Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

Hi Tom,

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Tom Herbert
> Envoyé : mercredi 19 juillet 2017 00:43
> À : Joe Touch
> Cc : tsv-a...@ietf.org; Internet Area
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 
> On Tue, Jul 18, 2017 at 3:31 PM, Joe Touch  wrote:
> > Hi, all,
> >
> > I've noted this before, but to share with other areas:
> >
> > Although I'm not averse to middleboxes as optional optimizations, I find
> > the proposed mechanisms aren't quite optional -- they inject option
> > information into the SYN data. That information would poison a
> > connection to a legacy receiver if (more to the point, when) that info
> > isn't removed by a proxy upstream of the receiver.
> >
> > TCP must be E2E and fall back to legacy endpoints without a reconnection
> > attempt, as required by RFC793.
> >
> > These aren't generic solutions; they're attacks on a TCP connection,
> IMO.
> >
> I agree. This seems be akin to stateful firewalls model that impose
> artificial requirements on networking (like every TCP packet for a
> connection must got through some middlebox or the connection is
> dropped). We need to move things back to E2E semantics for transport
> protocols-- nodes that try to maintain transport state in the network
> should be considered the problem not the solution!
> 

[Med] We would love to avoid requiring adding a function in the network to 
assist devices to make use of their multiple interfaces/paths. Nevertheless, 
the situation is that servers do not support MPTCP. 

The proposed solution allows to:
* elect some flows to benefit from network-assisted MPTCP while avoiding 
session failures.
* Policies are configured to identify traffic that won't be forwarded via a 
proxy
* 0-RTT proxying
* MPTCP can be used e2e if both end points are MPTCP-capable (that is, the 
proxy is withdrawn from the path).
* No interference with TCP options to be negotiated between endpoints.

Do you have in mind such use cases when you referred to the "stateful firewalls 
model"?

> Tom
> 
> > Joe
> >
> >
> > On 7/18/2017 3:22 PM, Olivier Bonaventure wrote:
> >> The working group has discussed this issue several times and today we
> >> have presented a new design that supports the creation of such
> >> functions to convert MPTCP connections into TCP connections and vice
> >> versa. The design was done with MPTCP in mind, but the proposed
> >> solution could be more generic and applied to other use cases than
> >> MPTCP. The draft that describes the new design is available via:
> >>
> >> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-
> converters-01.txt
> >>
> >>
> >> Mirja Kuehlewind suggested to send the document on the int-area and
> >> tsv-area mailing lists to see whether other working groups could be
> >> interested by this approach.
> >
> > ___
> > Int-area mailing list
> > Int-area@ietf.org
> > https://www.ietf.org/mailman/listinfo/int-area
> 
> ___
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Review> SOCKS 6 Draft

2017-07-07 Thread mohamed.boucadair

Hi Hosnieh,

Please see inline.

Cheers,
Med

De : Hosnieh Rafiee [mailto:i...@rozanak.com]
Envoyé : jeudi 6 juillet 2017 20:09
À : BOUCADAIR Mohamed IMT/OLN; Int-area@ietf.org
Objet : Re: [Int-area] Review> SOCKS 6 Draft


Hi Mohamed,

Thanks for your email. I had two reasons:

1- I was not aware of these two documents.. I guess two less activities at 
IETF. right?!

2- I just skimmed the documents you have referred to . They talk about 
mechanisms for IP translation   and authentication and making the NAT easier.

[Med] Actually, both NAT and firewall are addressed by PCP. There is no 
assumption that a NAT must be out there.
   The Port Control Protocol (PCP) provides a mechanism to control how
   incoming packets are forwarded by upstream devices such as Network
   Address Translator IPv6/IPv4 (NAT64), Network Address Translator
   IPv4/IPv4 (NAT44), and IPv6 and IPv4 firewall devices, and a
   mechanism to reduce application keepalive traffic.

But what I do not know exactly or at least with very quick review could not 
find,  is that socks proxy also works closely with firewall and open the ports 
if the client socks wants to communicate to any service outside of the network 
and in general cases the firewall has all its port close unless otherwise the 
client ask to open a port.

[Med] Can be done using PCP, as well.

 I know that NAT has a settings to also work closely with firewall but do not 
know which one has a better performance. Further the default assumption in 
those document is that the NAT service is there.

[Med] No. RFC6887 defines PCP-controlled device as follows:

===

   PCP-Controlled Device:

  A NAT or firewall that controls or rewrites packet flows between

  internal hosts and remote peer hosts.  PCP manages the mappings on

  this device.

===

that means I do not only need to consider the implementation of NAT but also 
these documents. While for Socks, only socks standard is enough which works 
closely with Selinux for firewalling.

Now the question is which process is heavier from computation perspective, NAT 
+ this approach or a socks proxy alone that do the replacement of IP? I haven't 
done any experiment or comparison yet..

[Med] Please see above. The NAT part is not required. Actually, RFC7652 
provides the following:

==

   The mechanism described in this document meets the security

   requirements to address the Advanced Threat Model described in the

   base PCP specification [RFC6887].  This 
mechanism can be used to

   secure PCP in the following situations:



   o  On security infrastructure equipment, such as corporate firewalls,

  that does not create implicit mappings for specific traffic.

==

One more important point is that, how NAT will handle TCP connections when we 
have non reliable internet connection that breaks frequently but we cannot 
establish the TLS every single time where the connection breaks?   What I liked 
about Socks 6 that was not in socks5 is that they handled the unreliable 
connection, either by purpose or accidentally, very well since they referred to 
a document such as TCP FAST OPEN.

Further, Socks proxy is  layer 5 protocol and can handle TLS communication 
better than NAT. I am of course not talking about the case to use socks as a 
MITM for my TLS connection. That is not the purpose at all here. But NAT is 
layer 3 or maximum with some configuration layer 4 which has no flexibility to 
session layer.

[Med] I’m not sure to get your last two points.

Best,

Hosnieh






this is of course what I also need or expect to use from Socks as a kind of 
NATing but at the same time the most important thing is its interaction with 
firewall
On 07/06/2017 03:08 PM, 
mohamed.boucad...@orange.com wrote:
Hi Hosnieh,

Just out of curiosity, is there any particular reason you want to use SOCKS? 
Did you consider other protocols such as:

· https://tools.ietf.org/html/rfc6887

· https://tools.ietf.org/html/rfc7652

Thank you.

Cheers,
Med

De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Hosnieh Rafiee
Envoyé : mercredi 5 juillet 2017 21:21
À : Int-area@ietf.org
Objet : [Int-area] Review> SOCKS 6 Draft


Hello,

I quickly reviewed Socks6 document as I was waiting for any initiation to 
improve socks 5. I found it a good document, however, unfortunately the 
security is still weak and this document also did not address that but made it 
worse. I am looking for new methods of authentication as what is available in 
socks5 is just plain text and cannot protect against active attacker and also 
passive attacker if and if there is a fixed value used as a username and 
password.

Further, DDoS attack mentioned also in the draft cannot be addressed as easily 
as explained, IMHO. since the proxy server supposed to receive higher size 
messages and the attacker client can only overwhelm the socks server

Re: [Int-area] SOCKS 6 Draft

2017-07-07 Thread mohamed.boucadair

Hi Vlad,

Please see inline.

Cheers,
Med

De : Vladimir Olteanu [mailto:vladimir.olte...@cs.pub.ro]
Envoyé : vendredi 7 juillet 2017 09:19
À : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : Int-area@ietf.org; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft

Hi Mohamed,
I'm replying specifically to the parts quoted below.

SOCKS is used by explicit proxies; anything related to transparent proxies is
beyond its scope.
[Med] The definition we had so far is that "explicit proxy" means that the
client is aware about the presence of the proxy and such packets are sent
explicitly to that proxy. An explicit proxy can therefore behave either as
transparent or non-transparent. I understand, that the current design assumes
non-transparent mode.
It does not preclude the deployment of anything transparent. In other words, I
merely propose it as an alternative to MP_CONVERT.

Discussing PCP, IPv6 source address preservation, UPnP etc. makes no sense in
this context.
[Med] I disagree. The support of incoming connections is one of the
requirements of the MPTCP WG: "A session can be initiated from either end".
This is why I'm wondering how this typical flow can be achieved with SOCKS.

H<=CPE<--proxy<===RM
+--+

Cheers,
Vlad

On 7/6/2017 3:56 PM,
mohamed.boucad...@orange.com wrote:
De : Vladimir Olteanu [mailto:vladimir.olte...@cs.pub.ro]
Envoyé : mercredi 5 juillet 2017 18:39
À : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : Int-area@ietf.org; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft

On 7/5/2017 9:00 AM,
mohamed.boucad...@orange.com wrote:

De : Vladimir Olteanu [mailto:vladimir.olte...@cs.pub.ro]
Envoyé : mercredi 5 juillet 2017 01:35
À : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : Int-area@ietf.org; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft

Can you please let me know if the proposal supports the following features:

* Support incoming connections (Proxy<---Remote Host): That is the
proxy intercept a TCP connection that it transforms into an MPTCP one.
Yes. See section 7.2. The client makes a request and then has to keep the
connection to the proxy open. When the proxy accepts a connection from a remote
host, it informs the client of the remote host's address and starts relaying
data. SOCKS 5 has the exact same feature. You are limited to one incoming
connection per request, though.
[Med] In the plain mode, there is no such limitation because we are leveraging
on PCP (RFC6887).

* If such feature is supported, how a host located behind a CPE
(HostCPE-ProxyRemote Host) can instruct dynamically the CPE so that
it can forward appropriately incoming connections?
It does not have to. The connection on the host-proxy leg is initiated by the
client.
[Med] I'm not sure to understand your answer here. Let's consider that your
host is using UPnP IGD to talk with the CPE to accept incoming connections +
those connections are eligible to the MPTCP service. How the solution would
work?

* IPv6 source address/prefix preservation

I'm not sure what you mean by that.
[Med] Please see slide 18 of
https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Review> SOCKS 6 Draft

2017-07-06 Thread mohamed.boucadair

Hi Hosnieh,

Just out of curiosity, is there any particular reason you want to use SOCKS? 
Did you consider other protocols such as:

· https://tools.ietf.org/html/rfc6887

· https://tools.ietf.org/html/rfc7652

Thank you.

Cheers,
Med

De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Hosnieh Rafiee
Envoyé : mercredi 5 juillet 2017 21:21
À : Int-area@ietf.org
Objet : [Int-area] Review> SOCKS 6 Draft


Hello,

I quickly reviewed Socks6 document as I was waiting for any initiation to 
improve socks 5. I found it a good document, however, unfortunately the 
security is still weak and this document also did not address that but made it 
worse. I am looking for new methods of authentication as what is available in 
socks5 is just plain text and cannot protect against active attacker and also 
passive attacker if and if there is a fixed value used as a username and 
password.

Further, DDoS attack mentioned also in the draft cannot be addressed as easily 
as explained, IMHO. since the proxy server supposed to receive higher size 
messages and the attacker client can only overwhelm the socks server easier by 
less messages from different IP address that sounds to be a new client.  
Further, for constrained devices, there is a limitation in size of the message, 
therefore, dissimilar to socks5 that could be used also for such devices, socks 
6 cannot be used otherwise there will be limit in the information supposed to 
be sent in one message.

https://tools.ietf.org/html/draft-intarea-olteanu-socks-6-00.html

But in general, that is a good effort, keep going on!

Best,

Hosnieh


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [multipathtcp] SOCKS 6 Draft

2017-07-06 Thread mohamed.boucadair

Hi Joe,

Please see inline.

Cheers,
Med

De : Joe Touch [mailto:to...@isi.edu]
Envoyé : mercredi 5 juillet 2017 18:59
À : Vladimir Olteanu; BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : multipathtcp; Int-area@ietf.org
Objet : Re: [multipathtcp] [Int-area] SOCKS 6 Draft




On 7/5/2017 9:39 AM, Vladimir Olteanu wrote:
 It can also be stacked as many times as desired for arbitrarily long proxy 
chains. However:
 * We avoid using the SYN's payload as extra option space (which, I think, goes 
against TCP's core philosophy).
[Med] This is also true for MP_CONVERT Information Element which is not a TCP 
option, but a data supplied for proxy purposes in the SYN payload.
Fair enough, but this is not a purely layer 5+ protocol. It seems that you are 
strongly tied to TFO (between the client and the proxy). MP_CONVERT must be 
part of the SYN's payload, because the following SYN+ACK depends on the 
contents of MP_CONVERT and signals that the remote server has accepted your 
connection.

The biggest impact of including non-data information in the SYN payload area is 
that it completely defeats graceful fallback for SYN receivers that don't 
support the option. As you note, it can be *more* safe when tied to out-of-band 
context (e.g., prior TFO support), but TCP has NO requirement that such context 
is absolutely maintained across different connections. You might be speaking to 
a different stack or demuxed off to a different virtual host behind a load 
balancer.

Ultimately, putting any non-data info in the SYN payload violates the 
requirement that TCP options can be ignored by receivers that don't support 
them *without* impacting the ability of *that* connection attempt to succeed.
[Med] You are right... if we are talking about TCP options that are inserted in 
the payload of the SYN to every remote peer. This is not the case for the MPTCP 
proxy case: this is about proxy-supplied data that is sent to the proxy, which 
is provisioned by the provider. Proxy-supplied data is not received by the 
remote peer.


Joe
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] SOCKS 6 Draft

2017-07-06 Thread mohamed.boucadair

Hi Vladimir,

Please see inline.

Cheers,
Med

De : Vladimir Olteanu [mailto:vladimir.olte...@cs.pub.ro]
Envoyé : mercredi 5 juillet 2017 18:39
À : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : Int-area@ietf.org; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft


Hi Mohamed,

It's great to talk this through. I've inlined my answers.

Cheers,

Vlad

On 7/5/2017 9:00 AM, 
mohamed.boucad...@orange.com wrote:
Hi Valdimir,

Thank you for your answer.

Please see inline.

Cheers,
Med

De : Vladimir Olteanu [mailto:vladimir.olte...@cs.pub.ro]
Envoyé : mercredi 5 juillet 2017 01:35
À : BOUCADAIR Mohamed IMT/OLN; David Schinazi
Cc : Int-area@ietf.org; multipathtcp
Objet : Re: [Int-area] SOCKS 6 Draft

Hi Mohamed,

No problem. BTW, your work on MPTCP Plain Mode has, in fact, served as 
inspiration for SOCKS 6.

When coupled with TFO on the client-proxy leg, SOCKS 6 also has a 0-RTT 
overhead.
[Med] Glad to see that we are pursuing the same goal. That's said I'm not sure 
about the 0-RTT in the current proposal given this text that puts a dependency 
on the server side:
   In the fast case, when authentication is properly set up, the proxy
   attempts to create the socket immediately after the receipt of the
   request, thus achieving an operational conection in one RTT (provided
   TFO functionality is available at the client, proxy, and server).

Oops, we meant to say a data response in 1 RTT (e.g. HTTP GET, then HTTP OK).

 It can also be stacked as many times as desired for arbitrarily long proxy 
chains. However:
 * We avoid using the SYN's payload as extra option space (which, I think, goes 
against TCP's core philosophy).
[Med] This is also true for MP_CONVERT Information Element which is not a TCP 
option, but a data supplied for proxy purposes in the SYN payload.
Fair enough, but this is not a purely layer 5+ protocol. It seems that you are 
strongly tied to TFO (between the client and the proxy).
[Med] TFO is not required. We are in the explicit mode where the proxy is 
provisioned by the provider to the client/CPE. That proxy is prepared to 
receive data in the first SYN of an MPTCP connection. In order to detect 
misbehaving proxies, the content of CONVERT is echoed in SYN-ACK. Absent that 
information, the client/CPE will avoid using that proxy for subsequent 
network-assisted MPTCP exchanged till a timer is expired or a new proxy is 
configured.

MP_CONVERT must be part of the SYN's payload, because the following SYN+ACK 
depends on the contents of MP_CONVERT and signals that the remote server has 
accepted your connection.
[Med] Yes.


 The magic number at the start of the MP_CONVERT element implies that if any 
MPTCP stream happens to start with 0xFAA8FAA8, the client should not use TFO.
[Med] This can be fixed by registering a service port for the proxy service 
because, after all, the ultimate destination port is conveyed in the MP_CONVERT.
I think this is more sensible.
[Med] Agree. BTW, this is one of the advices made by Joe. This is now part of 
the CONVERT design.


I think moving up the protocol stack is a more desirable alternative.
 * We support authentication. Connections to the proxy can also be initiated 
from networks outside of the operator's control (e.g. home WiFis).
[Med] Authentication/authorization can be supported by various means. This 
depends on the deployment scheme.

 * SOCKS 6 is easier to extend. If the client needs to request some special 
behavior from the proxy (e.g. what packet scheduler to use), all we have to do 
is define (and standardize) a new SOCKS option.
[Med] That's also true for MP_CONVERT Information Element. You can define new 
"Types" if needed.
Can you please let me know if the proposal supports the following features:

· Support incoming connections (Proxy<---Remote Host): That is the 
proxy intercept a TCP connection that it transforms into an MPTCP one.
Yes. See section 7.2. The client makes a request and then has to keep the 
connection to the proxy open. When the proxy accepts a connection from a remote 
host, it informs the client of the remote host's address and starts relaying 
data. SOCKS 5 has the exact same feature. You are limited to one incoming 
connection per request, though.
[Med] In the plain mode, there is no such limitation because we are leveraging 
on PCP (RFC6887).



· If such feature is supported, how a host located behind a CPE 
(HostCPE-ProxyRemote Host) can instruct dynamically the CPE so that 
it can forward appropriately incoming connections?
It does not have to. The connection on the host-proxy leg is initiated by the 
client.
[Med] I'm not sure to understand your answer here. Let's consider that your 
host is using UPnP IGD to talk with the CPE to accept incoming connections + 
those connections are eligible to the MPTCP service. How the solution would 
work?


·

Re: [Int-area] SOCKS 6 Draft

2017-07-04 Thread mohamed.boucadair

Hi Vladimir, all,

(focusing only on this part of the message).

I do fully agree that shortening MPTCP connections setup is key. Having 0-RTT 
is an important requirement for this effort. Achieving it without out-of-band 
signaling would be even ideal.

Can you please elaborate on the benefits of your proposal compared to 
https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf
 which allows to achieve 0-RTT proxying.

Thank you.

Cheers,
Med

De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Vladimir Olteanu
Envoyé : vendredi 30 juin 2017 23:37
À : David Schinazi
Cc : Int-area@ietf.org
Objet : Re: [Int-area] SOCKS 6 Draft


Hi David,
[SNIP]

- Out of curiosity, what specific use case are you using this protocol for?

We are looking into using MPTCP on mobile devices to "bind" 4G/LTE and WiFi. 
Mobile data networks have high latency, hence the drive to shave off as many 
RTTs as possible and to take advantage of TFO, at least on the client-proxy leg.

Cheers,
Vlad
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] draft-boucadair-ip-version-5-8-9-historic

2016-03-19 Thread mohamed.boucadair

Hi Brian, 

The purpose is not have this I-D published as an RFC but to follow the 
procedure as per bullet 2 of 
https://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html. 

Can you take care of creating a status-change document for these RFCs?

Thank you.

Cheers,
Med

> -Message d'origine-
> De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Brian
> Haberman
> Envoyé : jeudi 17 mars 2016 13:43
> À : int-area@ietf.org
> Objet : Re: [Int-area] draft-boucadair-ip-version-5-8-9-historic
> 
> This is a fine thing to do, but it does not require an I-D to do it. An
> AD can create a status-change document that moves the three RFCs
> mentioned in the draft to Historic status. Any justification for the
> move can be included in the status-change document. Here is an example
> of one that was done recently:
> 
> https://datatracker.ietf.org/doc/status-change-service-mappings-to-
> historic/
> 
> Regards,
> Brian
> 
> On 3/17/16 3:32 AM, mohamed.boucad...@orange.com wrote:
> > Dear all,
> >
> > We do think it is time to move those specifications to Historic and
> deallocate the IP version numbers.
> >
> > Comments are welcome.
> >
> > Cheers,
> > Med
> >
> >> -Message d'origine-
> >> De : I-D-Announce [mailto:i-d-announce-boun...@ietf.org] De la part de
> >> internet-dra...@ietf.org
> >> Envoyé : mercredi 16 mars 2016 16:34
> >> À : i-d-annou...@ietf.org
> >> Objet : I-D Action: draft-boucadair-ip-version-5-8-9-historic-00.txt
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >>
> >>
> >> Title   : Reclassification of ST (IP version 5), PIP
> (IP
> >> version 8) and TUBA (IP version 9) to Historic
> >> Authors : Mohamed Boucadair
> >>   Christian Jacquenet
> >>Filename: draft-boucadair-ip-version-5-8-9-historic-00.txt
> >>Pages   : 5
> >>Date: 2016-03-16
> >>
> >> Abstract:
> >>This document reclassifies ST (IP version 5), PIP (IP version 8) and
> >>TUBA (IP version 9) to Historic status.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-boucadair-ip-version-5-8-9-
> >> historic/
> >>
> >> There's also a htmlized version available at:
> >> https://tools.ietf.org/html/draft-boucadair-ip-version-5-8-9-historic-
> 00
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of
> >> submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >> ___
> >> I-D-Announce mailing list
> >> i-d-annou...@ietf.org
> >> https://www.ietf.org/mailman/listinfo/i-d-announce
> >> Internet-Draft directories: http://www.ietf.org/shadow.html
> >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > ___
> > Int-area mailing list
> > Int-area@ietf.org
> > https://www.ietf.org/mailman/listinfo/int-area
> >

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2014-07-23 Thread mohamed.boucadair

Hi Alissa, all,

Please see inline.

Cheers,
Med

-Message d'origine-
De : Int-area [mailto:int-area-boun...@ietf.org] 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-05difftype=--htmlsubmit=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

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

2014-07-23 Thread mohamed.boucadair

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
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Logging Recommendations for Internet-Facing Servers

2014-06-17 Thread mohamed.boucadair

Hi SM,

RFC6302 should be positioned in its context: i.e., how to meet regulatory 
requirements in some countries when address sharing is in use. A discussion on 
the background (with a concise discussion on solution flavors and some hints on 
time duration to store log data) is available at: 
http://tools.ietf.org/html/rfc6269#section-12 and 
http://tools.ietf.org/html/rfc6269#section-13.1.

The reco in RFC6302 aims to ease handling abuse claims and avoid revealing the 
identity of a large number of subscribers. FYI, the penal procedure in France 
has been updated in August 2013 to take into account address sharing in 
particular, see for instance 
http://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI28053220cidTexte=LEGITEXT06071154
 where additional information should be provided in addition to the IP 
address for abuse claims).

Privacy-related considerations and other side effects of storing IP addresses 
(including IP tracking) should be discussed IMHO independently of RFC6302. For 
example, the concrete case led by the CNIL in France: 
http://www.cnil.fr/linstitution/actualite/article/article/ip-tracking-conclusions-de-lenquete-conjointe-menee-par-la-cnil-et-la-dgccrf/?tx_ttnews[backPid]=91cHash=6c52ebf7fc988c0c7fe49410c4e69342.
 

Cheers,
Med

-Message d'origine-
De : Int-area [mailto:int-area-boun...@ietf.org] De la part de S Moonesamy
Envoyé : lundi 16 juin 2014 11:48
À : Alain Durand; Igor Gashinsky; Donn Lee; Scott Sheppard
Cc : Linus Nordberg; int-area@ietf.org
Objet : [Int-area] Logging Recommendations for Internet-Facing Servers

Hello,

In the wake of the revelations about surveillance there has been some
concerns about RFC 6302.  I would be grateful if the authors of RFC
6302 could review the comments at
http://www.ietf.org/mail-archive/web/ietf-privacy/current/msg00454.html
and provide some feedback.

Regards,
S. Moonesamy

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2014-06-13 Thread mohamed.boucadair

Hi SM,

Please see inline.

Cheers,
Med

-Message d'origine-
De : S Moonesamy [mailto:sm+i...@elandsys.com]
Envoyé : mercredi 11 juin 2014 21:10
À : BOUCADAIR Mohamed IMT/OLN; Tirumaleswar Reddy (tireddy); int-
a...@ietf.org
Objet : RE: [Int-area] Call for adoption of draft-boucadair-intarea-host-
identifier-scenarios-04

Hi Med,
At 07:24 11-06-2014, mohamed.boucad...@orange.com wrote:
   The INTAREA working group
 previously worked on a RFC about potential solutions for revealing a
 host identifier.   Are the potential solutions discussed in RFC 6967
 inadequate?

[Med] The effort in RFC6967 does not ambition to pick a solution but
to conduct an analysis effort with a focus on the CGN case. That
case is only one among others defined in the scenario draft.
Identify and document the use cases is a first step to actually
understand the problem we are talking about. This is a contribution
to clarify the big picture of this problem space.

I left in my previous comment as it may be easier for the reader to
understand the discussion.

The previous comment mentioned potential solutions discussed in RFC
6967.  In my opinion the above response does not provide an answer
to the question.

[Med] The analysis of the solutions discussed in RFC6967 was drawn with a 
particular focus on Carrier-Grade NAT (CGN), application proxies, or Address 
plus Port (A+P). (Excerpt from RFC6967) + an ** Internet-wide ** scope. Some 
parts of that analysis is inappropriate for some cases that are restricted to 
** a single administrative domain **. For example, using an IP option is not a 
viable solution for the Internet-wide cases, but this option can be 
investigated further for the single domain case. 


You made an interesting point, i.e. clarify the big picture.  I read
the RFCs coming from INTAREA.  There was one about Issues with IP
Address Sharing in June 2011.  There is another one about Analysis
of Potential Solutions for Revealing a Host Identifier (HOST_ID) in
Shared Address Deployments in June 2013.  Now there is a draft about
Host Identification: Use Cases.  I haven't seen a discussion of
that big picture on this mailing list.  My understanding of the
documents is that the working group is make a case (the word is used
loosely) for host identification.

[Med] The documents produced so far by intarea focus on address sharing (read 
CGNs, A+P). The scenarios draft aims to provide the big picture view by 
gathering a list of cases that suffer from similar problems that we abstracted 
as host identification problem. The inventory of these cases is IMHO useful 
to understand the problem space and avoid restricting it to the single CGN 
case. It also provides a tool to rationalize the solution design effort: For 
example, the current situation is that one who reads RFC7239 won't be able to 
link it effort to RFC6967! 


[Med] Privacy is not out of scope as I mentioned in a previous
message. Nevertheless, privacy implications may depend on the
targeted use case. The considerations in RFC6967 can be completed
with new ones if any.

Ok.  I assume that the working group has the expertise and energy to
do that work.

[Med] What we declared out of scope is solution-oriented aspects. We
wanted to have a very focused document.

This is what I read from the draft:

   It is out of scope of this document to argue in favor or against the
use cases listed in the following sub-sections.

[Med] The current version of the scenarios draft includes some cases that can 
be considered as deployment-specific (see for instance the case of offering 
Provider Wi-Fi by re-using CPE resources Use Case#4). These case are listed 
because authors are aware of such plans: a concrete example Use Case#4 
corresponds to what is mentioned in slide 12 of 
www.3gpp.org/ftp/workshop/2011-11-09_3GPP_BBF_SFO/Docs/3BF-11046.zip. The 
sentence you quoted is a warning that the authors are not taking position for 
these deployments. 


That is different from the above response.

I'll wait for the Working Group Chairs to take their decision.

Regards,
S. Moonesamy

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2014-06-11 Thread mohamed.boucadair

Hi SM, 

Please see inline.

Cheers,
Med

-Message d'origine-
De : S Moonesamy [mailto:sm+i...@elandsys.com]
Envoyé : vendredi 6 juin 2014 14:56
À : BOUCADAIR Mohamed IMT/OLN; Tirumaleswar Reddy (tireddy); int-
a...@ietf.org
Objet : RE: [Int-area] Call for adoption of draft-boucadair-intarea-host-
identifier-scenarios-04

Hi Med,
At 00:59 06-06-2014, mohamed.boucad...@orange.com wrote:
[Med] FWIW, the scenarios draft is not a HOST_ID specification document.

[snip]

[Med] Having a dedicated section for privacy is a signal that we
have those issues on our radar. Our analysis at this stage is that
RFC6967 includes a decent discussion that is still valid for this
use cases document. If you think that additional concerns are to be
discussed, please don't hesitate to share them. We will consider
updating the document accordingly.

[snip]

[Med] There is no mention of HOST_ID in this draft. Furthermore,
the current text says the following:
   The document does not elaborate whether explicit authentication is
enabled or not.

Solution-specific discussions are out of scope. The main mission of
the document is to help identifying use cases where there are
difficulties to enforce per-host policies due to the presence of
address sharing or the use of tunnels.

[snip]

[Med] Documenting misuses should be definitely in scope.
Contributions are more than welcome.

 From the above (quoted text) I understand that there are
difficulties to enforce policies and those difficulties have not be
discussed or addressed in IETF RFCs.

[Med] Yes. 

  The INTAREA working group
previously worked on a RFC about potential solutions for revealing a
host identifier.   Are the potential solutions discussed in RFC 6967
inadequate?

[Med] The effort in RFC6967 does not ambition to pick a solution but to conduct 
an analysis effort with a focus on the CGN case. That case is only one among 
others defined in the scenario draft. Identify and document the use cases is a 
first step to actually understand the problem we are talking about. This is a 
contribution to clarify the big picture of this problem space. 

  I don't think the question is out of scope given that
the draft references RFC 6967.

[Med] Privacy is not out of scope as I mentioned in a previous message. 
Nevertheless, privacy implications may depend on the targeted use case. The 
considerations in RFC6967 can be completed with new ones if any.


If the mission is to identify use cases, why are discussions about
the use cases (see Section 2) out of scope?

[Med] What we declared out of scope is solution-oriented aspects. We wanted to 
have a very focused document.


The lack of host identification does not affect host
connectivity.  This scenarios draft makes the case for the lack of
host identification being the cause of problems.

[Med] The draft focuses only on scenarios where complications arise. The 
problem may be abstracted from other perspective but the host identification is 
a valid angle IMHO. 

  Do the problems
affect the internet or are they limited cases?

[Med] Implication on connectivity depends on the use cases. For example, a 
service that black list a full IP address  or rate limit based on the source IP 
address will impact a lot of customers; access to services won't be granted. 


Regards,
S. Moonesamy

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

2014-06-11 Thread mohamed.boucadair

Hi Stephen,

Please see inline.

Cheers,
Med

-Message d'origine-
De : Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Envoyé : vendredi 6 juin 2014 17:59
À : BOUCADAIR Mohamed IMT/OLN; Ted Lemon
Cc : Brian E Carpenter; ietf-priv...@ietf.org; int-area@ietf.org
Objet : Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers


Hi Med,

On 06/06/14 12:41, mohamed.boucad...@orange.com wrote:
 [Med] I'm not sure about this Ted. There are other initiatives that
 try to solve the issue for particular use cases, see for instance
 this effort for HTTP:
 http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10. The
 rationale of the host identifier scenarios document is to group all
 use cases suffering from the same problem instead of focusing on one
 single case. This allows having a big picture view of the problem
 space.

I think XFF is actually a good example of why we ought not adopt
this work.

[Med] I provided Forward as an example to illustrate there is a need to have 
a big picture view rather than focusing on specific use case. This draft does 
not suggest to adopt XFF or Forward at all. There is a need to understand the 
problem space and identify deployment scenarios where encountering 
complications.


XFF is widely deployed already but somewhat flakey in terms of
interop so the authors of the above draft aimed to produce a spec
that just addressed interop. (*) That was adopted by an area WG
without (IMO) ever really considering the privacy implications,
and definitely without any effort having been made to develop a
more privacy-friendly mechanism (which could have been done, again
IMO) to solve what were the claimed use-cases.

[Med] Wouldn't be this effort an opportunity to promote those solutions you are 
advocating for? The proxy use case (not limited to HTTP) is listed as a typical 
scenario. If there are other better solutions that solves your privacy 
concerns, why not documenting them? 

 By the time it
got to the IESG that was in practice unfixable and after some
fairly painful discussions it ended up with 4 abstain ballots,
including mine. [1] (For those who quite reasonably don't need
to care about IESG balloting, an abstain means approximately
yuk.:-)

Of course that all also pre-dated BCP188 and the last year's
shenanigans so I'd hope we have learned to not keep doing that.

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.

S.

[1]
https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/ballot/

(*) To be clear: I think the authors were genuinely just
trying to fix what they saw as an interop problem.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

2014-06-11 Thread mohamed.boucadair

Re-,

Please see inline.

Cheers,
Med

-Message d'origine-
De : ietf-privacy [mailto:ietf-privacy-boun...@ietf.org] De la part de
Stephen Farrell
Envoyé : samedi 7 juin 2014 15:21
À : Dan Wing
Cc : ietf-priv...@ietf.org; Internet Area; Joe Touch
Objet : Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers


Hi Dan,

On 07/06/14 02:38, Dan Wing wrote:

 Stephen,

 It seems NAPT has become IETF's privacy feature of 2014 because
 multiple users are sharing one identifier (IP address and presumably
 randomized ports [RFC6056], although many NAPT deployments use
 address ranges because of fear of compressing log files).  As a
 former co-chair of BEHAVE it is refreshing to see the IETF embracing
 NAPT as a desirable feature.

Embracing seems like significant overstatement to me, but maybe
that's understandable given how calmly NAT is generally debated.

NATs have both good and bad properties. The slightly better privacy
is one of the good ones.

Recognising that reality is neither embracing nor refreshing IMO,
nor does it mean NAPT is (un)desirable overall. (That's an argument
I only ever watch from the side-lines thanks:-)

 However, if NAPT provides privacy and NAT Reveal removes it, where
 does that leave a host's IPv6 source address with respect to BCP188?

 Afterall, an IPv6 address is quite traceable, even with IPv6 privacy
 addresses (especially as IPv6 privacy addresses are currently
 deployed which only obtain a new IPv6 privacy address every 24 hours
 or when attaching to a new network).  If BCP188 does not prevent
 deployment of IPv6, I would like to understand the additional privacy
 leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of
 IPv6+privacy_address.

I'm frankly amazed that that's not crystal clear to anyone who
has read all 2.5 non-boilerplate pages of the BCP. Or even just
the last two words of the 1-line abstract (hint: those say where
possible.)

Yes, source addresses leak information that affects privacy. But
we do not have a practical way to mitigate that. So therefore
BCP188 does not call for doing stupid stuff, nor for new laws of
physics (unlike -04 of the draft we're discussing;-)

[Med] FWIW, this draft does not hint solutions but it aims to describe 
scenarios with problems. I understand you have concerns with privacy but this 
is not an excuse to abuse and characterize this effort as stupid. Privacy 
implications should be assess on a per use case basis (see for example cases 
where all involved entities belong to same administrative entity). Furthermore, 
the document (including -04) says the following : the document does not 
elaborate whether explicit authentication is enabled or not.


Adding new identifiers with privacy impact, as proposed here, is
quite different.

[Med] I have already clarified this point: the scenario draft does not propose 
any identifier!


S.

PS: If someone wants to propose what they think is a practical
way to mitigate the privacy issues with source addresses, please
write a draft first and then start a separate thread somewhere.



 -d


___
ietf-privacy mailing list
ietf-priv...@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-privacy

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2014-06-06 Thread mohamed.boucadair

Hi SM,

Please see inline.

Cheers,
Med

-Message d'origine-
De : Int-area [mailto:int-area-boun...@ietf.org] De la part de S Moonesamy
Envoyé : jeudi 5 juin 2014 17:20
À : Tirumaleswar Reddy (tireddy); int-area@ietf.org
Objet : Re: [Int-area] Call for adoption of draft-boucadair-intarea-host-
identifier-scenarios-04

Hi Tiru,
At 07:57 05-06-2014, Tirumaleswar Reddy (tireddy) wrote:
My interest in this draft is that it helps solve the problem of
identifying host after NAT to enforce identity based policies.

Ok.

FYI - I am also the co-author of the draft.

I noticed that. :-)

According to RFC 6967:

   HOST_ID specification document(s) should explain the privacy impact

[Med] FWIW, the scenarios draft is not a HOST_ID specification document. 

of the solutions they specify, including the extent of HOST_ID
uniqueness and persistence, assumptions made about the lifetime of
the HOST_ID, whether and how the HOST_ID can be obfuscated or
recycled, whether location information can be exposed, and the impact
of the use of the HOST_ID on device or implementation fingerprinting.

 From draft-boucadair-intarea-host-identifier-scenarios-05:

   Privacy-related considerations that apply to means to reveal a host
identified are discussed in [RFC6967].  This document does not
introduce additional privacy issues than those discussed in
[RFC6967].

It does not look like the privacy impact has been considered by the
authors of the document.

[Med] Having a dedicated section for privacy is a signal that we have those 
issues on our radar. Our analysis at this stage is that RFC6967 includes a 
decent discussion that is still valid for this use cases document. If you think 
that additional concerns are to be discussed, please don't hesitate to share 
them. We will consider updating the document accordingly. 


HOST_ID is an identifier, which according to the use cases, can be
used in many places.

[Med] There is no mention of HOST_ID in this draft. Furthermore, the current 
text says the following:
   The document does not elaborate whether explicit authentication is
   enabled or not.

Solution-specific discussions are out of scope. The main mission of the 
document is to help identifying use cases where there are difficulties to 
enforce per-host policies due to the presence of address sharing or the use of 
tunnels. 

  Anyone in the spying business would welcome
such an identifier.  Will the authors be taking that into
consideration or is it out of scope?

[Med] Documenting misuses should be definitely in scope. Contributions are more 
than welcome.


Regards,
S. Moonesamy

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

2014-06-06 Thread mohamed.boucadair

Hi Ted,

As far as this document is concerned, we are open to address technical 
concerns. It will be helpful if these concerns are specific enough and 
hopefully in reference to 
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05.

Adding a discussion on potential misuses can be considered to address the 
comment from Stephen if those are not redundant with the text already in 
http://tools.ietf.org/html/rfc6967#section-3.  

Cheers,
Med

-Message d'origine-
De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Ted Lemon
Envoyé : jeudi 5 juin 2014 23:27
À : Brian E Carpenter
Cc : ietf-priv...@ietf.org; int-area@ietf.org; Stephen Farrell
Objet : Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

On Jun 5, 2014, at 4:28 PM, Brian E Carpenter brian.e.carpen...@gmail.com
wrote:
 I have to call you on that. WG adoption is not approval. It's agreement
 to work on a topic. It is not OK to attempt a pocket veto on adoption
 because you don't like the existing content.

WG adoption is a pretty heavy action.   It states that the WG has consensus
to work on the document, and weighs heavily in the consensus evaluation
during WGLC.   If there are problems with the document, part of the
adoption process should be the identification of those flaws and an
agreement to address them.   So bringing up those flaws during the adoption
process is crucial to the process.

It's also worth noting that the INTAREA working group is a special working
group, with an extremely broad charter, which is moderated by the fact that
in order for work to be done by the working group, the Internet Area ADs
have to approve the work.

So needless to say I at least am watching keenly to see if Stephen's
objections are being addressed, and likely won't approve the adoption of
the work if they aren't.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

2014-06-06 Thread mohamed.boucadair

Re-,

Please see inline.

Cheers,
Med

-Message d'origine-
De : Ted Lemon [mailto:ted.le...@nominum.com]
Envoyé : vendredi 6 juin 2014 12:48
À : BOUCADAIR Mohamed IMT/OLN
Cc : Brian E Carpenter; ietf-priv...@ietf.org; int-area@ietf.org; Stephen
Farrell
Objet : Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

On Jun 6, 2014, at 4:11 AM, mohamed.boucad...@orange.com wrote:
 Adding a discussion on potential misuses can be considered to address the
comment from Stephen if those are not redundant with the text already in
http://tools.ietf.org/html/rfc6967#section-3.

The document hasn't been adopted yet, so we can avoid security issues
simply by not adopting it.

[Med] I'm not sure about this Ted. There are other initiatives that try to 
solve the issue for particular use cases, see for instance this effort for 
HTTP: http://tools.ietf.org/html/draft-ietf-appsawg-http-forwarded-10. The 
rationale of the host identifier scenarios document is to group all use cases 
suffering from the same problem instead of focusing on one single case. This 
allows having a big picture view of the problem space. 

   Talking about what the security considerations
section might do to ameliorate the harm isn't in scope yet.   First we need
to decide whether there is more harm than good done by adopting and
publishing the document!

[Med] Fair enough. 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

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

2014-06-05 Thread mohamed.boucadair

Hi Suresh,

Thank you for initiating this call.

FWIW, the latest version is -05 not -04: 
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05.

Unsurprisingly, I'm supportive to see this work adopted in intarea as a 
companion effort to RFC6269 and RFC6967.

Cheers,
Med

De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Suresh Krishnan
Envoyé : jeudi 5 juin 2014 06:21
À : Internet Area
Objet : [Int-area] Call for adoption of 
draft-boucadair-intarea-host-identifier-scenarios-04


Hi all,

   This draft was originally intended to be published as an AD sponsored 
submission from the OPS area, but the authors have expressed their interest to 
continue this work in the intarea wg given that RFC6269 and RFC6967 originated 
here. The draft has been updated to address the issues brought up during 
earlier discussions on the wg mailing list and the latest version of the draft 
is available at



http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04



This call is being initiated to determine whether there is WG consensus towards 
adoption of draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea 
WG draft. Please state whether or not you're in favor of the adoption by 
replying to this email. If you are not in favor, please also state your 
objections in your response. This adoption call will complete on 2014-06-19.



Regards

Suresh  Juan Carlos

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

2014-06-05 Thread mohamed.boucadair

Hi Stephen,

You referred in your message to an old version. The latest version of the 
document does not include any requirement, it is only an inventory of use cases 
when problems are encountered. The latest version is available at: 
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05.

Some of these use cases are restricted to a single administrative domain while 
others span multiple domain. Privacy concerns are really important; these are 
discussed in RFC6967.

The use cases are not theoretical ones, but are those where complications 
arise. Explicitly calling out security risks (including privacy ones) will 
benefit to this work. It is really helpful to understand the use cases and call 
out any potential risks rather than speculating without actual understanding of 
what the problem is.

This document is the opportunity to record security and privacy concerns that 
apply to these use cases. The content of the document is not frozen. Adopting 
it as a WG document will undoubtedly enrich it and benefit from other 
perspectives that those of the authors. 

Cheers,
Med

-Message d'origine-
De : ietf-privacy [mailto:ietf-privacy-boun...@ietf.org] De la part de
Stephen Farrell
Envoyé : jeudi 5 juin 2014 14:48
À : Hannes Tschofenig; int-area@ietf.org
Cc : ietf-priv...@ietf.org; Zuniga, Juan Carlos
Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hiya,

On 05/06/14 08:05, Hannes Tschofenig wrote:
 If you want to review a document with privacy implications then
 have a look at the NAT reveal / host identifier work (with
 draft-boucadair-intarea-host-identifier-scenarios-04 currently in
 a call for adoption).

 I had raised my concerns several times now on the mailing list and
 during the meetings.

I share those concerns. And adopting this without any consideration
of BCP188 would fly in the face of a very recent, very thoroughly
discussed, IETF consensus. For something like this, the onus ought
IMO be on the proposers to have done that work before asking for
adoption. Based on the draft, they clearly have not done that.

We could also ask to add more use-cases:

use-case#12: spy on everyone more easily, TEMPORA++
use-case#13: sell data that's even more fine-grained than clickstreams
use-case#14: expose your n/w internals to help on path attackers
use-case#15: track hosts from which people emit dangerous utterances
use-case#16: block hosts from which people emit dangerous utterances
use-case#17: charge me more for using two of my computers in my house

The set of use-cases presented very much contradicts the explicit
claim in the draft that no position is being taken as to the merits
of this. IMO that argues strongly to not adopt this.

One could also comment on the requirements that seem to
require new laws of physics or are otherwise pretty odd:

REQ#1: seems to require knowing from packets passing by that
a device is a trusted device (and REQ#15 says that can be
done with 16 bits;-) Hmm... are those qubits maybe?

REQ#5: *all* IP packets MUST have a HOST_ID... but presumably
without a flag day. Hmm...

REQ#6: says this is a transport thing. Eh, why ask INT-AREA?

REQ#10+REQ#11: MUST be intradomain only but MUST also be inter
domain. Hmm...

REQ#18: receiver MUST enforce policies like QoS. Huh?

Such a frankly bogus list of requirements also means that
this is not something that ought be adopted in the IETF.

I also think that this proposal has previously been proposed
in other ways and not adopted. Such forum-shopping is yet
another reason to not adopt it, and certainly not as an
area wg thing without any broader IETF-wide consideration.
(As an aside: having to play whack-a-mole with such repeat
proposals is one of the downsides of area wgs. Not sure
if anything can be done about that though.)

In summary: ignoring BCP188, the selection-bias in use
cases, the badly thought out requirements and forum
shopping are all independently sufficient reasons to
not adopt this. And of course that doesn't include all
the other issues with potential solutions listed in
RFC6967 (the reference to which is oddly to the I-D and
not the RFC).

My conclusion: this one ought go to /dev/null same as the
previous attempts to shop the same thing into other parts
of the IETF.

S



 Ciao Hannes


  Original Message  Subject:  [Int-area] Call for
 adoption of draft-boucadair-intarea-host-identifier-scenarios-04
 Date:Thu, 5 Jun 2014 04:20:56 + From:Suresh Krishnan
 suresh.krish...@ericsson.com To:   Internet Area
 int-area@ietf.org



 Hi all,

 This draft was originally intended to be published as an AD
 sponsored submission from the OPS area, but the authors have
 expressed their interest to continue this work in the intarea wg
 given that RFC6269 and RFC6967 originated here. The draft has been
 updated to address the issues brought up during earlier
 discussions on the wg mailing list and the latest

Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers

2014-06-05 Thread mohamed.boucadair

Re-,

I have two comments:

(1)

If one missed the following sentences in -04 Below is listed as set of
requirements to be used to characterize
each use case (discussed in Section 3): and Once this list is stabilized,
each use case will be checked against
these requirements., then the requirements list can be seen as odd. I agree
the wording is not so that clear. The initial intent was to identify the ones
from the list that apply for each use case. That effort was abandoned in -05 to
focus on the description of the use cases where problems are encountered.

(2)

Privacy concerns are not ignored. A section is present in the draft to recall
some privacy-related issues:
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05#section-15.
If there are other concerns not already covered, it will be relay helpful to
explicit them.

The document does not include any solution discussion but focuses only on the
description of deployment use cases where problems are encountered.

Cheers,
Med

-Message d'origine-
De : Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie]
Envoyé : jeudi 5 juin 2014 15:24
À : BOUCADAIR Mohamed IMT/OLN; Hannes Tschofenig; int-area@ietf.org
Cc : ietf-priv...@ietf.org; Zuniga, Juan Carlos
Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers

Hi Med,

On 05/06/14 14:11, mohamed.boucad...@orange.com wrote:
Hi Stephen,

You referred in your message to an old version.

That was the one for which the adoption call was issued. I
guess just a typo.

I looked quickly at the diff between 04 and 05 and my
conclusion remains the same and most of my comment I think
still apply, despite the removal of the odd requirements
section.

The latest version of
the document does not include any requirement, it is only an
inventory of use cases when problems are encountered. The latest
version is available at:
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-
scenarios-05.

Some of these use cases are restricted to a single administrative
domain while others span multiple domain. Privacy concerns are really
important; these are discussed in RFC6967.

The use cases are not theoretical ones, but are those where
complications arise. Explicitly calling out security risks (including
privacy ones) will benefit to this work. It is really helpful to
understand the use cases and call out any potential risks rather than
speculating without actual understanding of what the problem is.

This document is the opportunity to record security and privacy
concerns that apply to these use cases. The content of the document
is not frozen. Adopting it as a WG document will undoubtedly enrich
it and benefit from other perspectives that those of the authors.

Cheers, Med

-Message d'origine- De : ietf-privacy
[mailto:ietf-privacy-boun...@ietf.org] De la part de Stephen
Farrell Envoyé : jeudi 5 juin 2014 14:48 À : Hannes Tschofenig;
int-area@ietf.org Cc : ietf-priv...@ietf.org; Zuniga, Juan Carlos
Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers

Hiya,

On 05/06/14 08:05, Hannes Tschofenig wrote:
If you want to review a document with privacy implications
then have a look at the NAT reveal / host identifier work
(with draft-boucadair-intarea-host-identifier-scenarios-04
currently in a call for adoption).

I had raised my concerns several times now on the mailing list
and during the meetings.

I share those concerns. And adopting this without any consideration
of BCP188 would fly in the face of a very recent, very thoroughly
discussed, IETF consensus. For something like this, the onus ought
IMO be on the proposers to have done that work before asking for
adoption. Based on the draft, they clearly have not done that.

We could also ask to add more use-cases:

use-case#12: spy on everyone more easily, TEMPORA++ use-case#13: sell
data that's even more fine-grained than clickstreams use-case#14:
expose your n/w internals to help on path attackers use-case#15:
track hosts from which people emit dangerous utterances
use-case#16: block hosts from which people emit dangerous
utterances use-case#17: charge me more for using two of my computers
in my house

The set of use-cases presented very much contradicts the explicit
claim in the draft that no position is being taken as to the merits
of this. IMO that argues strongly to not adopt this.

One could also comment on the requirements that seem to require new
laws of physics or are otherwise pretty odd:

REQ#1: seems to require knowing from packets passing by that a device
is a trusted device (and REQ#15 says that can be done with 16
bits;-) Hmm... are those qubits maybe?

REQ#5: *all* IP packets MUST have a HOST_ID... but presumably without
a flag day. Hmm...

REQ#6: says this is a transport thing. Eh, why ask INT-AREA?

REQ#10+REQ#11: MUST be intradomain only but MUST also be inter
domain. Hmm...

REQ#18: receiver MUST enforce policies like

[Int-area] TR: I-D Action: draft-boucadair-intarea-host-identifier-scenarios-05.txt

2014-04-17 Thread mohamed.boucadair

Dear all,

The new version of the draft tries to address most of the comments received so 
far. 

Cheers,
Med

-Message d'origine-
De : I-D-Announce [mailto:i-d-announce-boun...@ietf.org] De la part de 
internet-dra...@ietf.org
Envoyé : vendredi 11 avril 2014 15:28
À : i-d-annou...@ietf.org
Objet : I-D Action: draft-boucadair-intarea-host-identifier-scenarios-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Host Identification: Use Cases
Authors : Mohamed Boucadair
  David Binet
  Sophie Durel
  Bruno Chatras
  Tirumaleswar Reddy
  Brandon Williams
  Behcet Sarikaya
  Li Xue
Filename: 
draft-boucadair-intarea-host-identifier-scenarios-05.txt
Pages   : 21
Date: 2014-04-11

Abstract:
   This document describes a set of scenarios in which host
   identification is problematic.  The document does not include any
   solution-specific discussion.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-intarea-host-identifier-scenarios/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-boucadair-intarea-host-identifier-scenarios-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

2014-03-11 Thread mohamed.boucadair

Hi Brian,

Please see inline.

Cheers,
Med

-Message d'origine-
De : Int-area [mailto:int-area-boun...@ietf.org] De la part de Brian E
Carpenter
Envoyé : jeudi 6 mars 2014 19:03
À : joel jaeggli
Cc : hi...@ietf.org; Internet Area; draft-boucadair-intarea-host-
identifier-scenar...@tools.ietf.org
Objet : Re: [Int-area] request to consider sponsoring
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-
scenarios-04

a) Since this is fixing some of the damage done by NAT, it's
really unfinished business for BEHAVE, which if iirc was a
Transport Area WG. Just saying...

[Med] It is not only about NAT but address sharing in general (including A+P
and proxies). Issues are also encountered when tunnels are in use.

b) The word privacy doesn't appear in the draft. Discussing
privacy aspects is clearly essential if there is any thought of
advancing this work. Actually I doubt if such a host ID is ever
going to be acceptable from a privacy point of view, unless the
end system is at liberty to change it at random (like RFC 4941).

[Med] A pointer to http://tools.ietf.org/html/rfc6967#section-3 can be added to
the draft.

c) A hard-nosed argument is that since we want to sunset IPv4,
it's time to stop working on ways of making NAT solutions work
better. Is there anything in the use cases that can't be fixed by
native IPv6?

[Med] The document includes some cases involving IPv6 (e.g., proxies, NPTv6,
NAT64). See the table in
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04#section-4.2.
The text can be made more clearer.

(The use case in expired draft
http://tools.ietf.org/html/draft-sarikaya-fmc-prefix-sharing-usecase-01
is not at all convincing to me, especially when adding the privacy
argument. It actually seems to describe a bug in 3GPP. But in any case,
the draft appears to suggest mitigations.)

Regards
Brian

On 07/03/2014 05:28, joel jaeggli wrote:
Greetings int-area and hiaps-mailing-list folks,

I realize that this is midweek at the IETF, however this question is not
far from several discussions I've had this week.

I have been asked to consider AD sponsoring
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-
scenarios-04

In the process of considering doing so I'd like to get some input with
respect to:

A. The appetite for pursuing some or any of this work in existing
working groups, and in particular within the INT area.

B. A consensus basis for moving beyond RFC 6269 into active work in this
area.

C. How we address concerns raised by the IETF community expressed
through draft-farrell-perpass-attack when evaluating scenarios and
beginning to address requirements and solution-space.

Obviously these are complex questions and I do not expect that we will
arrive at answers easily nor does work on this or other drafts depend on
answering them, however it's part of the dialog.

Thanks
joel

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] [hiaps] request to consider sponsoring http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04

2014-03-11 Thread mohamed.boucadair

Hi Ted,

It is out of scope of the document to specify solutions but to enumerate the 
set of cases where issues will be encountered. The use cases identified so far 
are not specific to a given administrative domain as captured in 
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-04#section-4.2
 

+---+--+-+---+
|  Use Case | IPv4 |IPv6 | Single Administrative |
|   |  |--+--|   Domain  |
|   |  |Client|Server|   |
+---+--+--+--+---+
|CGN|  Yes |Yes(1)|  No  | No|
|A+P|  Yes |  No  |  No  | No|
| Application Proxy |  Yes |Yes(2)|Yes(2)| No|
|   Provider Wi-Fi  |  Yes |  No  |  No  |Yes|
|PCC|  Yes |Yes(1)|  No  |Yes|
| Femtocells|  Yes |  No  |  No  | No|
| Cellular Networks |  Yes |Yes(1)|  No  |Yes|
|  Overlay Networks |  Yes |Yes(3)|Yes(3)| No|
|  Emergency Calls  |  Yes | Yes  |Yes   | No|
|TDF|  Yes | Yes  |  No  |Yes|
|FMC|  Yes |Yes(1)|  No  | No|

Given these use cases, operational considerations such as the performance 
impact induced by a solution to convey host_id should be taken into account. 
These impacts are solution-specific an deployment-sceptic.

For cases where functional elements belonging to several administrative domains 
are involved, standardized means are key.

Cheers,
Med

-Message d'origine-
De : hiaps [mailto:hiaps-boun...@ietf.org] De la part de Ted Lemon
Envoyé : jeudi 6 mars 2014 19:13
À : Brian E Carpenter
Cc : Joel Jaeggli; hi...@ietf.org; Internet Area; draft-boucadair-intarea-
host-identifier-scenar...@tools.ietf.org
Objet : Re: [hiaps] [Int-area] request to consider sponsoring
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-
scenarios-04

It also seems doubtful that this would be useful outside the carrier
network, since service providers would have to implement it and middleboxes
would have to support it, neither of which is something we can depend on.
Inside of the carrier network, solutions like A+P at the very least are
quite easy to track algorithmically, so this solution is overkill.

And of course I agree with all the points you made, Brian.

___
hiaps mailing list
hi...@ietf.org
https://www.ietf.org/mailman/listinfo/hiaps

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

[Int-area] draft-boucadair-connectivity-provisioning-protocol-01

2013-10-08 Thread mohamed.boucadair

Dear all,

An updated version of this document is available online.

Comments are welcome.

Cheers,
Med

-Message d'origine-
De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la 
part de internet-dra...@ietf.org
Envoyé : mardi 8 octobre 2013 11:12
À : i-d-annou...@ietf.org
Objet : I-D Action: draft-boucadair-connectivity-provisioning-protocol-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Connectivity Provisioning Negotiation Protocol (CPNP)
Author(s)   : Mohamed Boucadair
  Christian Jacquenet
Filename: 
draft-boucadair-connectivity-provisioning-protocol-01.txt
Pages   : 37
Date: 2013-10-08

Abstract:
   This document specifies the Connectivity Provisioning Negotiation
   Protocol (CPNP) which is used to facilitate the dynamic negotiation
   of service parameters between a Customer and a Provider.  As such,
   CPNP is a generic protocol that can be used for various negotiation
   purposes that include (but are not necessarily limited to)
   connectivity provisioning services, storage facilities, CDN (Content
   Delivery Networks) footprint, etc.

   CPNP can be extended with new Information Elements.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-protocol

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-protocol-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-boucadair-connectivity-provisioning-protocol-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt

2013-07-19 Thread mohamed.boucadair

Hi Charles, 

Please see inline.
Cheers,
Med

-Message d'origine-
De : Charles Eckel (eckelcu) [mailto:ecke...@cisco.com]
Envoyé : jeudi 18 juillet 2013 22:07
À : BOUCADAIR Mohamed OLNC/OLN; Reinaldo Penno (repenno); int-area@ietf.org
Objet : RE: [Int-area] FW: New Version Notification for draft-eckert-
intarea-flow-metadata-framework-01.txt

Hi Med,

Thank you for your review and corresponding comments. Please see inline.

 -Original Message-
 From: mohamed.boucad...@orange.com
 [mailto:mohamed.boucad...@orange.com]
 Sent: Thursday, July 18, 2013 5:11 AM
 To: Reinaldo Penno (repenno); Charles Eckel (eckelcu); int-area@ietf.org
 Subject: RE: [Int-area] FW: New Version Notification for draft-eckert-
intarea-
 flow-metadata-framework-01.txt

 
 IMHO, it would be useful if the document elaborates on deployment
aspects
 and what are the facilitators to ease adoption of such approach. For
 example, why an application relying on HTTPS would sent a non-encrypted
 flow characterization message for analytic purposes? What is the role
of
 a CPE in such model?
 
 
 [RP] I believe the end-point making the request for flow characteristics
 will be the CPE in many cases where the applications is not metadata
 aware. In other words, the CPE makes the request on behalf of
applications.
 [Med] I'm more interested in this CPE flavor (managed CPE) since it
avoids
 relying on applications to benefit from the added value of this approach.
This
 is worth be discussed in the document too.

[cue] Agreed. This is what we describe as Proxy originated information in
section 3.1.4.1 (http://tools.ietf.org/html/draft-eckert-intarea-flow-
metadata-framework-01#section-3.1.4.1). Does this address your concern?

[Med] Yes and No. I would prefer if concrete deployment examples are discussed 
(e.g., managed CPE for instance). 

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt

2013-07-19 Thread mohamed.boucadair

Hi Reinaldo,

IMHO, deployment considerations are key aspects if you want this model to fly. 
Having the material in one document is better (at least in early stages to 
socialize the proposed framework within IETF). 

Cheers,
Med

-Message d'origine-
De : Reinaldo Penno (repenno) [mailto:repe...@cisco.com]
Envoyé : vendredi 19 juillet 2013 13:33
À : BOUCADAIR Mohamed OLNC/OLN; Toerless Eckert (eckert)
Cc : Charles Eckel (eckelcu); int-area@ietf.org
Objet : Re: [Int-area] FW: New Version Notification for draft-eckert-
intarea-flow-metadata-framework-01.txt

Hi Med,

I agree with you that we need to cover in more detail the managed CPE
deployments but I wonder if this is the best document to do it.

Maybe a use-cases draft based on very concrete scenarios would be best.

Thanks,

Reinaldo


On 7/19/13 4:57 AM, mohamed.boucad...@orange.com
mohamed.boucad...@orange.com wrote:

Dear Toerless,

Please see inline.

Cheers,
Med

-Message d'origine-
De : Toerless Eckert [mailto:eck...@cisco.com]
Envoyé : vendredi 19 juillet 2013 05:13
À : BOUCADAIR Mohamed OLNC/OLN
Cc : Reinaldo Penno (repenno); Charles Eckel (eckelcu); int-area@ietf.org
Objet : Re: [Int-area] FW: New Version Notification for draft-eckert-
intarea-flow-metadata-framework-01.txt

On Thu, Jul 18, 2013 at 02:11:21PM +0200, mohamed.boucad...@orange.com
wrote:
 [RP] I believe the end-point making the request for flow
characteristics
 will be the CPE in many cases where the applications is not metadata
 aware. In other words, the CPE makes the request on behalf of
applications.
 [Med] I'm more interested in this CPE flavor (managed CPE) since it
avoids relying on applications to benefit from the added value of this
approach. This is worth be discussed in the document too.

See section 3.1.4.1 which talks about proxies. The problem really is
where
the proxied information comes from. If the proxy is doing DPI inspection
to
deduce it or some configured mappings, then it's likely going to be
unreliable
(encryption) or suffer from problems in getting it provisioned.

[Med] Section 3.1.4.1 as it is does not provide decent discussion of
these deployment issues and considerations. Sketching the expected
behavior of such intermediary functions would even be better. This
applies also for the other deployment-related issues I listed in my
initial e-mail.


To me these inspecting proxies are a way to get a foot in the door with
the method while it takes its time to persuade app-developers (or
middleware
like browsers) to signal the information explicitly (couple of years
?...).

 [Med] The question is not whether a secure transport is used or not but
to what extent the flow description is accurate (e.g., send fake flow
description, systematically request treatment with higher priority,
etc.).

Right. That was the intention of 3.1.4.2. Ultimately the network taking
action on the metadata needs to trust the authenticated identity
associated with the attributes to not lie about the attributes - OR
enforce the semantic of the attributes signalled.

[Med] this discussion about trust is worth to be elaborated further in
the document. For sure, this point will be raised by others.

Cheers
Toerless

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt

2013-07-18 Thread mohamed.boucadair

Dear Charles, all,

The idea of an application sending flow characterization messages to the 
network is interesting. This is an idea which is worth to be discussed and 
challenged. Thank you for writing this document.

The proposed framework makes sense in some contexts but I'm afraid it does not 
solve the limitations you listed in the document (e.g., avoid some 
classification functions in the network). The framework as it is won't simplify 
the network side since in addition to legacy tools, a new function to intercept 
the flow characterization messages will be needed. The benefit of the approach 
depends on the willing of application developers to signal the flow 
characteristic to the network. 

IMHO, it would be useful if the document elaborates on deployment aspects and 
what are the facilitators to ease adoption of such approach. For example, why 
an application relying on HTTPS would sent a non-encrypted flow 
characterization message for analytic purposes? What is the role of a CPE in 
such model? How to trust the data sent by an application? These are examples of 
points which should be further discussed in the document. 

If the purpose of the document is not to claim the limitations you identified 
will be mitigated but instead this framework is an additional tool at disposal 
for implementers/operators/etc to ease service ordering and delivery, then a 
note should be added to the draft. This will be helpful to avoid any confusion.

Personally, I'm not a fun of solutions which requires explicit resource 
invocation before making use of a subscribed service. This mode should not be 
generalized (it does make sense if a very few services rely on that mode). I 
understand there are deployment cases which would rely on such mode but this 
should be discussed in the document too. 

I didn't understood well why the encoding is discussed in this document. The 
focus should be on the information model not data models (which are 
protocol-specific).

Cheers,
Med

-Message d'origine-
De : int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] De la
part de Charles Eckel (eckelcu)
Envoyé : lundi 15 juillet 2013 23:07
À : int-area@ietf.org
Objet : [Int-area] FW: New Version Notification for draft-eckert-intarea-
flow-metadata-framework-01.txt

We have submitted and would appreciate comments on the following draft. It
provides a framework for applications and network devices to communicate
characteristics and service attributes for traffic flow. One aspect we
anticipate to be of particular interest to this audience is the use of
IPFIX in the information model we defined.

Cheers,
Charles

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, July 15, 2013 1:41 PM
To: Toerless Eckert (eckert); Amine Choukir (amchouki); Reinaldo Penno
(repenno); Charles Eckel (eckelcu)
Subject: New Version Notification for draft-eckert-intarea-flow-metadata-
framework-01.txt


A new version of I-D, draft-eckert-intarea-flow-metadata-framework-01.txt
has been successfully submitted by Toerless Eckert and posted to the
IETF repository.

Filename:   draft-eckert-intarea-flow-metadata-framework
Revision:   01
Title:  A Framework for Signaling Flow Characteristics between
Applications and the Network
Creation date:  2013-07-15
Group:  Individual Submission
Number of pages: 17
URL: http://www.ietf.org/internet-drafts/draft-eckert-intarea-
flow-metadata-framework-01.txt
Status:  http://datatracker.ietf.org/doc/draft-eckert-intarea-flow-
metadata-framework
Htmlized:http://tools.ietf.org/html/draft-eckert-intarea-flow-
metadata-framework-01
Diff:http://www.ietf.org/rfcdiff?url2=draft-eckert-intarea-
flow-metadata-framework-01

Abstract:
   This document provides a framework for communicating information
   elements (a.k.a. metadata) in a consistent manner between
   applications and the network to provide better visibility of
   application flows, thereby enabling differentiated treatment of those
   flows.  These information elements can be conveyed using various
   signaling protocols, including PCP, RSVP, and STUN.




The IETF Secretariat

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt

2013-07-18 Thread mohamed.boucadair

Hi Reinaldo, 

Please see inline. 

Cheers,
Med

-Message d'origine-
De : Reinaldo Penno (repenno) [mailto:repe...@cisco.com]
Envoyé : jeudi 18 juillet 2013 12:41
À : BOUCADAIR Mohamed OLNC/OLN; Charles Eckel (eckelcu); int-area@ietf.org
Objet : Re: [Int-area] FW: New Version Notification for draft-eckert-
intarea-flow-metadata-framework-01.txt

Hi Med,

Thanks for your review. Inline with [RP]

On 7/18/13 6:13 AM, mohamed.boucad...@orange.com
mohamed.boucad...@orange.com wrote:

Dear Charles, all,

The idea of an application sending flow characterization messages to the
network is interesting. This is an idea which is worth to be discussed
and challenged. Thank you for writing this document.

The proposed framework makes sense in some contexts but I'm afraid it
does not solve the limitations you listed in the document (e.g., avoid
some classification functions in the network). The framework as it is
won't simplify the network side since in addition to legacy tools, a new
function to intercept the flow characterization messages will be needed.

[RP] Interception is only needed with some transports. We should certainly
highlight that.

The benefit of the approach depends on the willing of application
developers to signal the flow characteristic to the network.


[RP] Yes. I believe this is somewhat a chicken and egg thing. Because such
functionality was never truly available in the network, there was no
incentive to applications developers.
[Med] Makes sense. This is why I see this approach as a new tool in addition to 
existing ones rather than presenting it will remove immediately some of the 
limitations of current designs. This can be highlighted in the document.  




IMHO, it would be useful if the document elaborates on deployment aspects
and what are the facilitators to ease adoption of such approach. For
example, why an application relying on HTTPS would sent a non-encrypted
flow characterization message for analytic purposes? What is the role of
a CPE in such model?


[RP] I believe the end-point making the request for flow characteristics
will be the CPE in many cases where the applications is not metadata
aware. In other words, the CPE makes the request on behalf of applications.
[Med] I'm more interested in this CPE flavor (managed CPE) since it avoids 
relying on applications to benefit from the added value of this approach. This 
is worth be discussed in the document too. 


How to trust the data sent by an application? These are examples of
points which should be further discussed in the document.


[RP] I think this depends on the transport. Some transports like PCP or
STUN have some built-in authentication.
[Med] The question is not whether a secure transport is used or not but to what 
extent the flow description is accurate (e.g., send fake flow description, 
systematically request treatment with higher priority, etc.).




If the purpose of the document is not to claim the limitations you
identified will be mitigated but instead this framework is an additional
tool at disposal for implementers/operators/etc to ease service ordering
and delivery, then a note should be added to the draft. This will be
helpful to avoid any confusion.

Personally, I'm not a fun of solutions which requires explicit resource
invocation before making use of a subscribed service.


[RP] Me neither. I was hoping the draft did not come as that. The idea
here is that any metadata could be send before or after connection is
established and reservation is not required at all. In other words,
applications will work as always have but could request metadata service
if they so desire. If request is denied, everything continues to work as
is.


This mode should not be generalized (it does make sense if a very few
services rely on that mode). I understand there are deployment cases
which would rely on such mode but this should be discussed in the
document too.

I didn't understood well why the encoding is discussed in this document.
The focus should be on the information model not data models (which are
protocol-specific).

Cheers,
Med

-Message d'origine-
De : int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] De la
part de Charles Eckel (eckelcu)
Envoyé : lundi 15 juillet 2013 23:07
À : int-area@ietf.org
Objet : [Int-area] FW: New Version Notification for draft-eckert-intarea-
flow-metadata-framework-01.txt

We have submitted and would appreciate comments on the following draft.
It
provides a framework for applications and network devices to communicate
characteristics and service attributes for traffic flow. One aspect we
anticipate to be of particular interest to this audience is the use of
IPFIX in the information model we defined.

Cheers,
Charles

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
Sent: Monday, July 15, 2013 1:41 PM
To: Toerless Eckert (eckert); Amine Choukir (amchouki); Reinaldo Penno
(repenno); Charles Eckel (eckelcu)
Subject:

Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios

2013-05-07 Thread mohamed.boucadair

Dear Joshua,

Apologies for the delay to answer this message.

I see your point. I will add it to the list of items to be considered for the 
next iteration of the document. 

BTW, -03 already included some of requirements which cover security aspects 
(see for instance REQ#1, REQ#2, REQ#3, REQ#9). Once we have a stable 
requirements list, we will identify the requirements which are valid for each 
use case: 
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-03#section-4.1
 

Cheers,
Med

-Message d'origine-
De : Joshua Shire [mailto:jsh...@hyduke.com] 
Envoyé : vendredi 25 janvier 2013 08:17
À : BOUCADAIR Mohamed OLNC/OLN; f...@ietf.org; int-area@ietf.org
Cc : draft-boucadair-intarea-host-identifier-scenar...@tools.ietf.org
Objet : RE: draft-boucadair-intarea-host-identifier-scenarios

Hello,

I do not believe a pointer to 
http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analys
is-04#section-3  will be satisfactory for the security 
considerations section. 

http://www.ietf.org/rfc/rfc3552.txt  states that when writing 
a security considerations section, the process ...should be 
approached as an effort to perform due diligence in 
describing all known or foreseeable risks and threats to 
potential implementers and users. Normally we see RFCs 
describing more applied topics such as protocols, so the 
specific language and examples given in the above mentioned 
RFC may not seem directly applicable. However, in spirit, 
the document seems clear in requiring all RFCs to examine in 
detail their potential security impact.

As I'm sure we're all aware, some of the use cases identified 
are purposefully implemented to maintain the confidentiality 
of a client's identity (e.g. NAT to obfuscate the structure of 
an enterprise network, Open-Wifi to conceal the identity of a 
client under threat of persecution [or prosecution], etc.). 

Thus, in identifying these scenarios as sharing the issue of 
host identification, the author would seem to be required to 
discuss the potential security implications of treating the 
lack of host identification as such, rather than a desirable feature.

Thanks,

Joshua Shire
Information Systems Manager
Hyduke Energy Services Inc.

-Original Message-
From: int-area-boun...@ietf.org 
[mailto:int-area-boun...@ietf.org] On Behalf Of 
mohamed.boucad...@orange.com
Sent: Monday, December 03, 2012 2:08 AM
To: f...@ietf.org; int-area@ietf.org
Cc: draft-boucadair-intarea-host-identifier-scenar...@tools.ietf.org
Subject: [Int-area] draft-boucadair-intarea-host-identifier-scenarios

Dear all,

We submitted an updated version of this draft to list use 
cases which encounter the issue of host identification. The 
following use cases are discussed in the draft:

   (1)  Carrier Grade NAT (CGN)
   (2)  A+P (e.g., MAP )
   (3)  Application Proxies
   (4)  Provider Wi-Fi
   (5)  Policy and Charging Architectures
   (6)  Cellular Networks
   (7)  Femtocells
   (8)  Overlay Networks (e.g., CDNs)

The document does not include any solution-specific 
discussion. Its main goal is to identify the use cases and 
describe them. 

If you think your use case is not included in this version, 
please share it with us. 

Comments are welcome. 

Cheers,
Med


-Message d'origine-
De : i-d-announce-boun...@ietf.org 
[mailto:i-d-announce-boun...@ietf.org] De la part de 
internet-dra...@ietf.org Envoyé : lundi 3 décembre 2012 08:26 
À : i-d-annou...@ietf.org Objet : I-D Action: 
draft-boucadair-intarea-host-identifier-scenarios-02.txt


A New Internet-Draft is available from the on-line 
Internet-Drafts directories.


   Title   : Host Identification: Use Cases
   Author(s)   : Mohamed Boucadair
  David Binet
  Sophie Durel
  Tirumaleswar Reddy
  Brandon Williams
   Filename: 
draft-boucadair-intarea-host-identifier-scenarios-02.txt
   Pages   : 14
   Date: 2012-12-02

Abstract:
   This document describes a set of scenarios in which host
   identification is required.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-intarea-host-i
dentifier-scenarios

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-boucadair-intarea-host-identif
ier-scenarios-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-boucadair-intarea-host-i
dentifier-scenarios-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or 
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
Int-area mailing list
Int-area@ietf.org

Re: [Int-area] IP Connectivity Provisioning Profile (draft-boucadair-connectivity-provisioning-profile)

2013-04-11 Thread mohamed.boucadair

Dear all,

We edited an I-D which proposes a global framework making use of the 
Connectivity Provisioning Profile. The document is available here:
http://tools.ietf.org/html/draft-sin-sdnrg-sdn-approach-02 

I'm sharing this information as it may be of interest of this working group.

Comments are more than welcome on both I-Ds.

Cheers,
Med


On 10/12/2012 05:20 AM, mohamed.boucad...@orange.com wrote:
 Dear all,
 
 We submitted this new I-D which may be of interest of this WG. 
 
 This is an effort trying to capture and expose the IP 
connectivity service provided by the network layer to upper 
services, to adjacent networks, offered/delivered to 
customers, etc. The document focuses on the definition of the 
CPP itself and does not discuss for instance how this is 
translated into configuration data/policies to be enforced in 
underlying nodes.
 
 Abstract:
This document describes the Connectivity Provisioning 
Profile (CPP)
and proposes a CPP Template to capture IP connectivity 
requirements
to be met in the context of delivery of services (e.g.  
Voice over IP
or IP TV) which are to be plugged upon an IP/MPLS infrastructure.
The CPP defines the set of IP transfer parameters to be 
supported by
the underlying IP/MPLS transport network together with a 
reachability
scope and bandwidth/capacity needs.  Appropriate 
performance metrics
such as one-way delay, one-way delay variation are used to
characterize an IP transfer service.  Both global and restricted
reachability scopes can be captured in the CPP.
 
Having the generic CPP template allows for (1) automating 
the process
of service negotiation and activation, thus accelerating service
provisioning, (2) setting the (traffic) objectives of Traffic
Engineering functions and service management functions and (3)
enriching service and network management systems with 'decision-
making' capabilities based on negotiated/offered CPPs.
 
 
https://datatracker.ietf.org/doc/draft-boucadair-connectivity-p
rovisioning-profile
 
http://tools.ietf.org/html/draft-boucadair-connectivity-provisi
oning-profile-02
 
 
 Comments are welcome.
 
 Cheers,
 Med
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-08.txt

2013-04-11 Thread mohamed.boucadair

Dear all,

This version integrates a second set of comments received during the IESG 
review. The main changes are as follows:

* Clarify the use of HOST_ID common to all interfaces is out of scope
* Provide more explanation for the Proxy case
* Record two additional limitations for the IP Option case
* Add a new bullet to record the encountered issue when the tcp options space 
is exhausted
* Rename HOST_ID to HOST_IDENT as HOST-ID is confusing for OPS (it is used to 
bind a license).

Cheers,
Med

-Message d'origine-
De : int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] De la
part de internet-dra...@ietf.org
Envoyé : jeudi 11 avril 2013 16:11
À : i-d-annou...@ietf.org
Cc : int-area@ietf.org
Objet : [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-
08.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Internet Area Working Group Working Group
of the IETF.

   Title   : Analysis of Solution Candidates to Reveal a Host
Identifier (HOST_IDENT) in Shared Address Deployments
   Author(s)   : Mohamed Boucadair
  Joe Touch
  Pierre Levis
  Reinaldo Penno
   Filename: draft-ietf-intarea-nat-reveal-analysis-08.txt
   Pages   : 23
   Date: 2013-04-11

Abstract:
   This document is a collection of solutions to reveal a host
   identifier (denoted as HOST_IDENT) when a Carrier Grade NAT (CGN) or
   application proxies are involved in the path.  This host identifier
   could be used by a remote server to sort out the packets by sending
   host.  The host identifier must be unique to each host under the same
   shared IP address.

   This document analyzes a set of solution candidates to reveal a host
   identifier; no recommendation is sketched in the document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-analysis-08


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-07.txt

2013-04-10 Thread mohamed.boucadair

Dear all,

This version integrates the first set of comments received during the IESG 
review. The main changes are:

* Add a sentence to clarify why no recommendation is included
* Add a sentence to clarify a host can be any computer located behind a CPE or 
directly connected to an address-sharing function
* Remove Section 1.1 and dispatch the bullets in the core text of Section 3
* Add a sentence to the privacy section to say an address-sharing function can 
be configured with different end-users policies
* Clarify what is meant by encrypted traffic in Table 1
* Add a sentence to the privacy section to request specification document to 
check whether location information may/may not be exposed using HOST_ID 
solutions
* Add a new items for the TCP option to mention it may interfere with the use 
of Fast Open extension
* Add some pointers to behave documents.
* Other minor edits.

Cheers,
Med

-Message d'origine-
De : int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] De la
part de internet-dra...@ietf.org
Envoyé : mercredi 10 avril 2013 10:58
À : i-d-annou...@ietf.org
Cc : int-area@ietf.org
Objet : [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-
07.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
 This draft is a work item of the Internet Area Working Group Working Group
of the IETF.

   Title   : Analysis of Solution Candidates to Reveal a Host
Identifier (HOST_ID) in Shared Address Deployments
   Author(s)   : Mohamed Boucadair
  Joe Touch
  Pierre Levis
  Reinaldo Penno
   Filename: draft-ietf-intarea-nat-reveal-analysis-07.txt
   Pages   : 22
   Date: 2013-04-10

Abstract:
   This document is a collection of solutions to reveal a host
   identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or
   application proxies are involved in the path.  This host identifier
   could be used by a remote server to sort out the packets by sending
   host.  The host identifier must be unique to each host under the same
   shared IP address.

   This document analyzes a set of solution candidates to reveal a host
   identifier; no recommendation is sketched in the document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-analysis-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] NAT reveal analysis IETF Last Call comments

2013-03-11 Thread mohamed.boucadair

Hi Suresh, all,

A new version incorporating the requested changes is online:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-analysis-06

Please see inline.

Cheers,
Med 

-Message d'origine-
De : int-area-boun...@ietf.org 
[mailto:int-area-boun...@ietf.org] De la part de Suresh Krishnan
Envoyé : dimanche 10 mars 2013 18:56
À : Internet Area
Objet : [Int-area] NAT reveal analysis IETF Last Call comments

Hi all,
  These comments were received on the IETF discussion list during the
IETF last call.

http://www.ietf.org/mail-archive/web/ietf/current/msg77707.html
http://www.ietf.org/mail-archive/web/ietf/current/msg77273.html


Thanks
Suresh



 Original Message 
Subject: Re: Last Call: draft-ietf-intarea-nat-reveal-analysis-05.txt
(Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID)
in Shared Address Deployments) to Informational RFC
Date: Mon, 25 Feb 2013 11:33:07 -0800
From: SM s...@resistor.net
To: i...@ietf.org

At 11:06 22-02-2013, The IESG wrote:
The IESG has received a request from the Internet Area 
Working Group WG
(intarea) to consider the following document:
- 'Analysis of Solution Candidates to Reveal a Host 
Identifier (HOST_ID)
in Shared Address Deployments'
   draft-ietf-intarea-nat-reveal-analysis-05.txt as 
Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2013-03-08. Exceptionally, 
comments may be

My comments should not be read as a statement of support. :-)

In Section 1:

  Section 3 discusses privacy issues common to all HOST_ID solutions.
   It is out of scope of this document to elaborate on privacy issues
   specific to each solution.

I suggest explaining what HOST_ID is.

Med: As HOST_ID is introduced in Section 2, the new text is now:

   Section 3 discusses privacy issues common to all candidate solutions.
   It is out of scope of this document to elaborate on privacy issues
   specific to each solution.


In Section 2:

  HOST_ID does not reveal the identity of a user, a subscriber or an
   application.

I suggest adding an explanation for that statement.

Med: The new text is:

   HOST_ID is not designed to reveal the identity of a user, a
   subscriber, or an application.  HOST_ID is designed to identify a
   host under a shared IP address.


In Section 4.4.1:

  For HTTP, Forwarded header 
([I-D.ietf-appsawg-http-forwarded]) can be
   used to display the original IP address when an address sharing
   device is involved.

A HTTP proxy is not an address sharing device in my opinion.

Med: The document does not say an http proxy is an address sharing device. 
Section 4 analyzes the scenario where the address sharing function is able to 
inject such header.

Section 2 says:

   Within this document, we assume the address-sharing function injects
   the HOST_ID. 


  The address sharing device has to strip all included Forwarded
   headers before injecting their own.

In Section 4.4.2:

 Injecting Forwarded header also introduces some implementation
  complexity if the HTTP packet is at or close to the MTU size.

What is a HTTP packet?

Med: Changed to HTTP message. 


Regards,
-sm







___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

2013-02-13 Thread mohamed.boucadair

Re-,

Please see inline.

Cheers,
Med

-Message d'origine-
De : Brian Haberman [mailto:br...@innovationslab.net]
Envoyé : mercredi 13 février 2013 16:04
À : BOUCADAIR Mohamed OLNC/OLN
Cc : int-area@ietf.org;
draft-ietf-intarea-nat-reveal-analy...@tools.ietf.org
Objet : Re: [Int-area] AD evaluation:
draft-ietf-intarea-nat-reveal-analysis

On 2/12/13 5:34 AM, mohamed.boucad...@orange.com wrote:
 Dear Brian,

 Many thanks for the detailed review.

 Please see inline.

 Cheers, Med

 -Message d'origine- De : int-area-boun...@ietf.org
 [mailto:int-area-boun...@ietf.org] De la part de Brian Haberman
 Envoyé : lundi 11 février 2013 22:12 À : int-area@ietf.org;
 draft-ietf-intarea-nat-reveal-analy...@tools.ietf.org Objet :
 [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

 All, I have completed my AD evaluation for the above draft and
 have some feedback for the group.  I will focus on the substantive
 comments for the time being since some of them may result in
 re-written text in places.  I will follow up with the document
 authors on editorial nits and such at a later time.

 1. It is obvious from the way certain sections of text are written
 that the original intent was to make a recommendation on which of
 the described approaches should be used to disambiguate between
 multiple hosts behind a NAT/CGN.  Given that the document is now
 simply a characterization of those mechanisms, I would suggest
 spending some time cleaning up the Abstract, Section 1.1, and
 Section 2 so that they focus on the task of describing the
 mechanisms, rather than mentioning abstract requirements for those
 mechanisms. There are concrete suggestions a little later in this
 note.

 Med: It is true there was a version of the document which includes a
 recommendation but the initial intent of the document was to analyze
 candidate solution. I updated the text to make it explicit: I changed
 the text in the sections you mentioned. In particular, the change in
 the abstract is:

 OLD:

 This document analyzes a set of solution candidates to mitigate some
 of the issues encountered when address sharing is used.  In
 particular, this document focuses on means to reveal a host
 identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application
 proxies are involved in the path.  This host identifier must be
 unique to each host under the same shared IP address.

 NEW:

 This document is a collection of solutions to reveal a host
 identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or
 application proxies are involved in the path.  This host identifier
 is used by a remote server to sort out the packets by sending host.
 The host identifier must be unique to each host under the same
 shared IP address.

 This document analyzes a set of solution candidates to reveal a host
 identifier; no recommendation is sketched in the document.


The above text is a good addition to the document.


 2. The mechanisms described in this draft fall into two broad
 categories, deployed and proposed. Those in the former category can
 be characterized based on actual usage scenarios, which would
 benefit the table shown in Figure 3. The latter should be described
 in terms of what they are proposed to do, but cannot be assessed
 against the same metrics as the other groups.

 Med: Figure 3 includes this note:

 (2)  This solution is widely deployed.

 Can you explicit what change you want to be added? Thanks.


Isn't the IP-ID approach also used in some deployments?

I would suggest re-ordering the table so that deployed approaches are
collected together (and labeling them as deployed).  If the HTTP
Forwarded header is the only deployed approach, I would simply add a
note for the others stating whether they are a documented
proposal or a
theoretical construct.

Med: I added these two notes:

 (7)  The solution is a theoretical construct.
 (8)  The solution is a documented proposal.

And updated the table accordingly.




 3. The Requirements Language section should be removed.  As an
 Informational document describing mechanisms, there is no need to
 leverage 2119 keywords.

 Med: Done.


Ok.


 4. It would be useful if the third paragraph of Section 1.1 was
 expanded to discuss the risks in more detail.  In fact, it may be
 clearer to understand this draft if the problem statement came
 before the context (Section 2).

 Med: I changed the text as follows:

 OLD:

 The sole use of the IPv4 address is not sufficient to uniquely
 distinguish a host.  As a mitigation, it is tempting to investigate
 means which would help in disclosing an information to be used by
 the remote server as a means to uniquely disambiguate packets of
 hosts using the same IPv4 address.

 NEW:

 In particular, some servers use the source IPv4 address as an
 identifier to treat some incoming connections differently.  Due to
 the deployment of CGNs (e.g., NAT44 [RFC3022], NAT64 [RFC6146]),
 that address will be shared.  In particular, when a

Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

2013-02-13 Thread mohamed.boucadair

Hi Behcet,

I have two comments:

* Host identification issue is valid for any address sharing mechanism. This is 
why the introduction mentions already the following:

   As reported in [RFC6269https://tools.ietf.org/html/rfc6269], several 
issues are encountered when an IP
   address is shared among several subscribers.  These issues are
   encountered in various deployment contexts: e.g., Carrier Grade NAT
   (CGN), application proxies or A+P 
[RFC6346https://tools.ietf.org/html/rfc6346].

* RFC6346 is provided as an example of a solution making use of port sets. You 
are right, other solutions (than a+p) can be considered but having one pointer 
to a solution example is just fair. No need to be exhaustive here.

Cheers,
Med

De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
Envoyé : mercredi 13 février 2013 17:36
À : Suresh Krishnan
Cc : Brian Haberman; draft-ietf-intarea-nat-reveal-analy...@tools.ietf.org; 
int-area@ietf.org
Objet : Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

Hi Suresh,

On Wed, Feb 13, 2013 at 12:56 AM, Suresh Krishnan 
suresh.krish...@ericsson.commailto:suresh.krish...@ericsson.com wrote:
Hi Behcet,

On 02/12/2013 05:57 PM, Behcet Sarikaya wrote:
 Hi Suresh,

 On Mon, Feb 11, 2013 at 6:08 PM, Suresh Krishnan
 suresh.krish...@ericsson.commailto:suresh.krish...@ericsson.com 
 mailto:suresh.krish...@ericsson.commailto:suresh.krish...@ericsson.com 
 wrote:

 Hi Brian,
   Thanks for the review. I wanted to clarify three points that you
 raised and I will ask the authors take care of the rest.

 On 02/11/2013 04:11 PM, Brian Haberman wrote:
  7. In Section 4.1.2, it would be good to describe any issues that the
  approach has with the original use of the Identification field for
  fragmentation reassembly.  If a middlebox changes the ID field, weird
  things can/will happen if those packets are fragmented somewhere.

 Agree. I think this is precisely the reason that the mechanism for
 putting the HOST_ID in the IP-ID is a non-starter.

  11. Is Section 4.6 theoretical or is there a specific reference
 that can
  be added for this technique?

 There are several mechanisms that use port sets for IPv4 address
 sharing. A+P (RFC6346) is one such mechanism.

 Section 4.6 is not about about A+P. In A+P there is also the use of a
 shared public IPv4 address.

Right. But section 4.6 is about assigning port sets and Brian asked if
that was any specific mechanisms that assigned port sets. A+P does so.
Not sure about what you mean by In A+P there is also the use of a
shared public IPv4 address. This is the reason why we need a HOST_ID at
all.


I think that this draft is not about A+P (don't ask me why, ask Med :-) ).
The correct reference for Section 4.6 would be BBF document WT-146 on 
Subscriber Sessions


Regards,

Behcet
Thanks
Suresh


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

2013-02-13 Thread mohamed.boucadair

Re-,

Please see inline.

Cheers,
Med


De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com]
Envoyé : mercredi 13 février 2013 18:01
À : BOUCADAIR Mohamed OLNC/OLN
Cc : Suresh Krishnan; Brian Haberman; 
draft-ietf-intarea-nat-reveal-analy...@tools.ietf.org; int-area@ietf.org
Objet : Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

Hi Med,

On Wed, Feb 13, 2013 at 10:43 AM, 
mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote:
Hi Behcet,

I have two comments:

* Host identification issue is valid for any address sharing mechanism.

I am not sure on A+P?
[Med] both A+P and NAT-based address sharing solutions are covered by rfc6269. 
host identifier is just a means to distinguish hosts under the same IP address. 
It does not matter how address sharing is implemented.

A+P requires point-to-point link, right?
This is why the introduction mentions already the following:

   As reported in [RFC6269https://tools.ietf.org/html/rfc6269], several 
issues are encountered when an IP
   address is shared among several subscribers.  These issues are
   encountered in various deployment contexts: e.g., Carrier Grade NAT
   (CGN), application proxies or A+P 
[RFC6346https://tools.ietf.org/html/rfc6346].

* RFC6346 is provided as an example of a solution making use of port sets. You 
are right, other solutions (than a+p) can be considered but having one pointer 
to a solution example is just fair. No need to be exhaustive here.

Again, I am not sure if Section 4.6 describes what A+P says?
[Med] That section says non overlapping port sets are assigned to hosts sharing 
the same IP address. The text does not describe if the shared address is also 
configured to those hosts or if there is a NAT in the host, etc. These are 
implementation variants. There is no value to provide such details in that 
section. Adding a ref to A+P is just fair. This does not preclude other 
contexts.

Regards,

Behcet



___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

2013-02-12 Thread mohamed.boucadair

Dear Brian,

Many thanks for the detailed review.

Please see inline.

Cheers,
Med

-Message d'origine-
De : int-area-boun...@ietf.org
[mailto:int-area-boun...@ietf.org] De la part de Brian Haberman
Envoyé : lundi 11 février 2013 22:12
À : int-area@ietf.org;
draft-ietf-intarea-nat-reveal-analy...@tools.ietf.org
Objet : [Int-area] AD evaluation:
draft-ietf-intarea-nat-reveal-analysis

All,
  I have completed my AD evaluation for the above draft and have
some feedback for the group.  I will focus on the substantive comments
for the time being since some of them may result in re-written text in
places.  I will follow up with the document authors on editorial nits
and such at a later time.

1. It is obvious from the way certain sections of text are
written that
the original intent was to make a recommendation on which of the
described approaches should be used to disambiguate between multiple
hosts behind a NAT/CGN.  Given that the document is now simply a
characterization of those mechanisms, I would suggest spending
some time
cleaning up the Abstract, Section 1.1, and Section 2 so that
they focus
on the task of describing the mechanisms, rather than mentioning
abstract requirements for those mechanisms. There are concrete
suggestions a little later in this note.

Med: It is true there was a version of the document which includes a 
recommendation but the initial intent of the document was to analyze candidate 
solution. I updated the text to make it explicit: I changed the text in the 
sections you mentioned. In particular, the change in the abstract is:

OLD:

   This document analyzes a set of solution candidates to mitigate some
   of the issues encountered when address sharing is used.  In
   particular, this document focuses on means to reveal a host
   identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application
   proxies are involved in the path.  This host identifier must be
   unique to each host under the same shared IP address.

NEW:

   This document is a collection of solutions to reveal a host
   identifier (denoted as HOST_ID) when a Carrier Grade NAT (CGN) or
   application proxies are involved in the path.  This host identifier
   is used by a remote server to sort out the packets by sending host.
   The host identifier must be unique to each host under the same shared
   IP address.

   This document analyzes a set of solution candidates to reveal a host
   identifier; no recommendation is sketched in the document.


2. The mechanisms described in this draft fall into two broad
categories, deployed and proposed. Those in the former category can be
characterized based on actual usage scenarios, which would benefit the
table shown in Figure 3. The latter should be described in
terms of what
they are proposed to do, but cannot be assessed against the
same metrics
as the other groups.

Med: Figure 3 includes this note:

 (2)  This solution is widely deployed.

Can you explicit what change you want to be added? Thanks.


3. The Requirements Language section should be removed.  As an
Informational document describing mechanisms, there is no need to
leverage 2119 keywords.

Med: Done.


4. It would be useful if the third paragraph of Section 1.1
was expanded
to discuss the risks in more detail.  In fact, it may be clearer to
understand this draft if the problem statement came before the context
(Section 2).

Med: I changed the text as follows:

OLD:

   The sole use of the IPv4 address is not sufficient to uniquely
   distinguish a host.  As a mitigation, it is tempting to investigate
   means which would help in disclosing an information to be used by the
   remote server as a means to uniquely disambiguate packets of hosts
   using the same IPv4 address.

NEW:

   In particular, some servers use the source IPv4 address as an
   identifier to treat some incoming connections differently.  Due to
   the deployment of CGNs (e.g., NAT44 [RFC3022], NAT64 [RFC6146]), that
   address will be shared.  In particular, when a server receives
   packets from the same source address, because this address is shared,
   the server does not know which host is the sending host [RFC6269].
   The sole use of the IPv4 address is not sufficient to uniquely
   distinguish a host.  As a mitigation, it is tempting to investigate
   means which would help in disclosing an information to be used by the
   remote server as a means to uniquely disambiguate packets of hosts
   using the same IPv4 address.


5. Section 2

* The Observation text should provide some brief examples of
how and why
special treatment is needed/provided.

Med: I updated the text with an example:

   Policies relying on source IP address which are enforced by some
   servers will be applied to all hosts sharing the same IP address.
   For example, blacklisting the IP address of a spammer host will
   result in all other hosts sharing that address having their access to
   the requested service restricted.  [RFC6269] describes the

Re: [Int-area] AD evaluation: draft-ietf-intarea-nat-reveal-analysis

2013-02-12 Thread mohamed.boucadair

Hi Suresh,

Please see inline.

Cheers,
Med
 

-Message d'origine-
De : Suresh Krishnan [mailto:suresh.krish...@ericsson.com] 
Envoyé : mercredi 13 février 2013 07:17
À : Brian Haberman
Cc : int-area@ietf.org; 
draft-ietf-intarea-nat-reveal-analy...@tools.ietf.org
Objet : Re: [Int-area] AD evaluation: 
draft-ietf-intarea-nat-reveal-analysis



 * Shouldn't there be an additional metric that covers the 
impact/cost of
 needing client or middlebox code changes?

 * Where did the 100% success ratio for IP-ID come from?  
There have been
 documented cases of OSes setting the Identification field 
to zero.  If
 that is true, the success ratio can't be 100% can it?

 This technique involves the translator (and not the sender) 
setting the
 IP-ID field. That is why it can still work with OSes on 
senders setting
 the IP-ID to zero.
 
 You still have the issue of the middlebox setting that ID to 
something
 that potentially impacts fragmentation reassembly.  So, I would still
 like to know how that 100% success ratio was collected.

Makes sense. I read the test result % to mean successful connection
establishment and identification. Med, can you elaborate a bit on what
exactly was tested and what the success % means.


Med: I made the following changes: 

OLD: 

   o  Success ratio indicates the ratio of successful communications
  when the option is used.  Provided figures are inspired from the
  results documented in [Options].

NEW:

   o  Success ratio indicates the ratio of successful communications
  with remote servers when the HOST_ID is injected using a candidate
  solution.

And added this NEW text:

   Provided success ratio figures for TCP and IP options are inspired
   from the results documented in [Options]
   [I-D.abdo-hostid-tcpopt-implementation][ExtendTCP].

   The provided success ratio for IP-ID is theoretical; it assumes the
   address sharing function follows the rules in [RFC6864] to re-write
   the IP Identification field.

   Since PROXY and HIP are not widely deployed, the success ratio to
   establish a communication with remote servers using these protocols
   is low.

   The success ratio for ICMP-based solution is implementation-specific
   but it is likely to be close to 100%.  A remote server which does not
   support the ICMP-based solution will ignore received companion ICMP
   messages.  An upgraded server will need to hold accepting a session
   until receiving the companion ICMP message.  The success ratio
   depends on how efficient the solution is implemented at the server
   side.

   The success ratio for IDENT solution is implementation-specific but
   it is likely to be close to 100%.  A remote server which does not
   support IDENT will accept a session establishment request following
   its normal operation.  An upgraded server will need to hold accepting
   a session until receiving the response to IDENT request it will send
   to the host.  The success ratio depends on how efficient the solution
   is implemented at the server side.


Cheers;
Med
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios

2012-12-11 Thread mohamed.boucadair

Hi Tina,

Thank you for the clarification. I updated the draft with a pointer to SLNAT44.

I prefer to not modify fig.6 (keep it simple + we are not dealing with
signalling flows issued from the UE).

Thanks for the review.

Cheers,
Med

De : Tina TSOU [mailto:tina.tsou.zout...@huawei.com]
Envoyé : lundi 10 décembre 2012 20:04
À : BOUCADAIR Mohamed OLNC/OLN
Cc : George, Wes; f...@ietf.org; int-area@ietf.org;
draft-boucadair-intarea-host-identifier-scenar...@tools.ietf.org
Objet : Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios

Dear Med et al,
In line...

Thank you,
Tina

On Dec 9, 2012, at 10:57 PM,
mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com
mohamed.boucad...@orange.commailto:mohamed.boucad...@orange.com wrote:

Hi Tina,

Many thanks for the comments.

Please see inline.

Cheers,
Med

De : Tina TSOU [mailto:tina.tsou.zout...@huawei.com]
Envoyé : vendredi 7 décembre 2012 08:16
À : BOUCADAIR Mohamed OLNC/OLN
Cc : George, Wes; f...@ietf.orgmailto:f...@ietf.org;
int-area@ietf.orgmailto:int-area@ietf.org;
draft-boucadair-intarea-host-identifier-scenar...@tools.ietf.orgmailto:draft-boucadair-intarea-host-identifier-scenar...@tools.ietf.org
Objet : Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios

Dear Med et al,
In general, I like the current version. Some comments are below.

1. From my understanding, this document provides the use cases for the
issues and analysis in draft-ietf-intarea-nat-reveal-analysis. Is it correct?
If it is , I suggest this document be referenced in nat-reveal-analysis.
[Med] nat-reveal-analysis draft inherits its scope from RFC6269. The use cases
draft adopts a more generic scope in which host identification issue is
encountered (this can be caused by address sharing, tunnelling, involvement of
multiple administrative entities, etc.).

2. Regarding this document, in the section of CGN use case, the stateless
NAT44 case should be included.
[Med] Do you mean 1:1 NAT?

[Tina] I meant the case in this document:
http://datatracker.ietf.org/doc/draft-tsou-stateless-nat44/, did not mean to
just promote my own draft though.

3. For A+P section, the MAP/Lw4over6 cases may be considered.
[Med] OK. I will add a pointer to MAP and Lw4over6 as examples.

4. In figure 6, the UE may have an interface with AF to initiate the
session request, e.g., SIP.
[Med] What does that mean? The goal of fig.6 is to illustrate the case where
there is a host identification issue.

[Tina] In section 7, it says The main issue is: PCEF, PCRF and AF all receive
information bound to the same UE but without being able to correlate between
the piece of data visible for each entity.
In PCRF architecture, the AF receives service request from the UE for service
establishment, which is one of the ways for AF to receive UE information, e.g.,
user ID. To make the architecture more generic, there should be an interface
between AF and UE.

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] draft-boucadair-intarea-host-identifier-scenarios

2012-12-04 Thread mohamed.boucadair

Dear Wes,

Thank you for your comments. 

Please see inline. 

Cheers,
Med 

-Message d'origine-
De : George, Wes [mailto:wesley.geo...@twcable.com] 
Envoyé : mardi 4 décembre 2012 21:09
À : BOUCADAIR Mohamed OLNC/OLN; f...@ietf.org; int-area@ietf.org
Cc : draft-boucadair-intarea-host-identifier-scenar...@tools.ietf.org
Objet : RE: draft-boucadair-intarea-host-identifier-scenarios

I've read this draft, and I think the use case list is 
reasonably complete.

However, it's really unclear to me what the value of this 
draft might be in its current form, and what its intended 
audience might be. Cataloging use cases is not all that 
helpful by itself without an end goal in mind, and that end 
goal is not clear from the draft.

Med: The goal of this draft is what is described in Section 2:

The goal is to
   identify scenarios the authors are aware of and which share the same
   issue of host identification.

   This document does not include any solution-specific discussion.
   This document can be used as a tool to design solution(s) mitigating
   the encountered issues.  Having a generic solution which would solve
   the issues encountered in these use cases is preferred over designing
   a solution for each use case.  Describing the use case allows to
   identify what is common between the use cases and then would help
   during the solution design phase.

Next updates of this draft will:
* include a discussion section to assess whether the issue is valid for 
IPv4-only or it applies also for IPv6
* include a discussion text to clarify whether each use case is valid within 
one single administrative domain or not
* include a discussion text to identify use cases which share the same 
requirements (this will help in designing the solution) 
* add additional use cases if any

At given point in time we need to draw conclusions about the following:
(1) are these use cases valid ones?
(2) if this is a real technical problem, what the IETF can do to solve the 
issue?
(3) if there is interest in this area, how to organize the work for the 
solution space.

 The scope is deliberately 
very narrow and references other drafts that discuss some of 
the surrounding issues with address sharing and unique 
identifiers, and so there is very little text in each section 
beyond a basic description. Even when you think of this in 
terms of follow-on drafts such as a gap analysis or problem 
statement or solution drafts, one wonders how useful it is to 
spread this across multiple drafts. So why not simply 
incorporate this list into one of the referenced general 
drafts on host identification, such as nat-reveal-analysis and 
then broaden that draft so that it considers and addresses the 
other use cases as appropriate?

Med: As I mentioned above, we don't want to include any solution-specific 
discussion to this draft. The text is shortened in purpose.


Otherwise, I think that the draft needs to be much clearer 
about the unique issues and considerations for each use case, 
especially those that are somehow distinct from those covered 
in nat-reveal-analysis so that it can serve as a better input 
to any potential solutions addressing this problem.

Med: Fully agreed. This will be added to the next rev of the draft.


I also believe that if this draft is to remain a standalone 
document, the authors need to make at least some attempt at 
discussing security and privacy considerations here, even if 
it is mainly to refer the reader to more in-depth discussions 
of the matter in other drafts.

Med: Agree. A pointer to 
http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-04#section-3 
will be added to the next rev of the draft. The text will also include some 
discussion for use cases which are restricted to one single administrative 
domain.


 Again, here is an area where 
being clear about the specific considerations for each use 
case is important, identifying whether the other drafts 
discuss things so that they are applicable to all of the use 
cases, or if the use cases are unique in any number of ways 
that will mean that they have unique privacy and security 
considerations.

Thanks,

Wes George

 -Original Message-
 From: int-area-boun...@ietf.org [mailto:int-area-boun...@ietf.org] On
 Behalf Of mohamed.boucad...@orange.com
 Sent: Monday, December 03, 2012 4:08 AM
 To: f...@ietf.org; int-area@ietf.org
 Cc: draft-boucadair-intarea-host-identifier-scenar...@tools.ietf.org
 Subject: [Int-area] draft-boucadair-intarea-host-identifier-scenarios

 Dear all,

 We submitted an updated version of this draft to list use cases which
 encounter the issue of host identification. The following 
use cases are
 discussed in the draft:

(1)  Carrier Grade NAT (CGN)
(2)  A+P (e.g., MAP )
(3)  Application Proxies
(4)  Provider Wi-Fi
(5)  Policy and Charging Architectures
(6)  Cellular Networks
(7)  Femtocells
(8)  Overlay Networks (e.g., CDNs)

 The document does not

[Int-area] draft-boucadair-intarea-host-identifier-scenarios

2012-12-03 Thread mohamed.boucadair

Dear all,

We submitted an updated version of this draft to list use cases which encounter 
the issue of host identification. The following use cases are discussed in the 
draft:

   (1)  Carrier Grade NAT (CGN)
   (2)  A+P (e.g., MAP )
   (3)  Application Proxies
   (4)  Provider Wi-Fi
   (5)  Policy and Charging Architectures
   (6)  Cellular Networks
   (7)  Femtocells
   (8)  Overlay Networks (e.g., CDNs)

The document does not include any solution-specific discussion. Its main goal 
is to identify the use cases and describe them. 

If you think your use case is not included in this version, please share it 
with us. 

Comments are welcome. 

Cheers,
Med


-Message d'origine-
De : i-d-announce-boun...@ietf.org [mailto:i-d-announce-boun...@ietf.org] De la 
part de internet-dra...@ietf.org
Envoyé : lundi 3 décembre 2012 08:26
À : i-d-annou...@ietf.org
Objet : I-D Action: draft-boucadair-intarea-host-identifier-scenarios-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title   : Host Identification: Use Cases
Author(s)   : Mohamed Boucadair
  David Binet
  Sophie Durel
  Tirumaleswar Reddy
  Brandon Williams
Filename: 
draft-boucadair-intarea-host-identifier-scenarios-02.txt
Pages   : 14
Date: 2012-12-02

Abstract:
   This document describes a set of scenarios in which host
   identification is required.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-intarea-host-identifier-scenarios

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-boucadair-intarea-host-identifier-scenarios-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] IP Connectivity Provisioning Profile (draft-boucadair-connectivity-provisioning-profile)

2012-10-12 Thread mohamed.boucadair

Dear Scott,

As currently defined in draft-boucadair-connectivity-provisioning-profile, IRS 
level is not in the scope. 

IRS does not intervene in the same level as the proposed CPP but some IRS 
actions (e.g., tweak RIB entries, add a new routing topology (using MT-ISIS or 
MT-OSPF) or adding a new routing instance (OSPF-MI), etc.) can be used to put 
into effect a CPP...These actions can be also enforced using COPS or NETCONF or 
any other provisioning mechanism. Also, note translating a CPP into a network 
configuration may not be limited to routing actions: forwarding actions and 
resource control filters may be required too. 

As I see it, IRS is a tool among others which can be invoked to put into effect 
a CPP. 

Cheers,
Med 

-Message d'origine-
De : Scott Brim [mailto:s...@internet2.edu] 
Envoyé : vendredi 12 octobre 2012 15:33
À : BOUCADAIR Mohamed OLNC/OLN
Cc : int-area@ietf.org
Objet : Re: [Int-area] IP Connectivity Provisioning Profile 
(draft-boucadair-connectivity-provisioning-profile)

Would it be interesting to subsume IRS under this?

https://datatracker.ietf.org/doc/draft-atlas-irs-problem-statement/

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Nat Reveal Analysis

2012-08-21 Thread mohamed.boucadair

Re-,

If /128 is used to enforce the policies then there is no issue at all.
 
The point is that using /128 to black list a spammer for instance is not 
efficient; that's why it is likely servers will use the first 64 bits (or even 
/56) to install a filterthe damage can be restricted to a home premises or 
a large number of customers when NPTv6 is used or any other deployment context 
requiring the share the first 64 bits.

Does this makes sense to you?

Cheers,
Med

-Message d'origine-
De : Joel M. Halpern [mailto:j...@joelhalpern.com] 
Envoyé : mardi 21 août 2012 15:49
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Internet Area
Objet : Re: [Int-area] Nat Reveal Analysis

Thank you for your prompt attention.
I have removed the agreed items.
I am still confused by the proposed new IPv6 text.
The text says that if a server uses short prefixes it will apply the 
policy too coarsely.
On the one hand, that is true even if NPT66 is not used.
On the other, the solution is already present.  Use the full 128 bits. 
This does not require any new mechanisms.

Yours,
Joel

On 8/21/2012 1:35 AM, mohamed.boucad...@orange.com wrote:
 Dear Joel,

 Thank you for the review.

 Please see inline.
 Cheers,
 Med

 -Message d'origine-
 De : int-area-boun...@ietf.org
 [mailto:int-area-boun...@ietf.org] De la part de Joel M. Halpern
 Envoyé : lundi 20 août 2012 22:52
 À : Internet Area
 Objet : [Int-area] Nat Reveal Analysis

 My thanks to the authors for submitting a revised version of
 draft-ietf-intarea-nat-reveal-analysis-03.

 I have looked at this document, and have a few comments.
 First, thank you for removing the explicit recommendation.

 I find section 2.1 on IPv6 applicability somewhat 
confusing.  The most
 common technique I know of for topology hiding, NPT66, does so in a
 fashion that does not conflate identities.  As such, it is 
not obvious
 that there is an IPv6 problem.  It seems that this short
 section should
 either be removed or elaborated.

 Med: I updated the text as follows:

 OLD:

 Some of the issues mentioned in Section 2 are 
independent of IPv4 vs.
 IPv6.  Even in IPv6, address sharing can be used for a variety of
 reasons (e.g., to hide network topology, to defeat hosts from
 offering network services directly, etc.).

 NEW:

 Some of the issues mentioned in Section 2 are 
independent of IPv4 vs.
 IPv6.  Even in IPv6, address sharing can be used for a variety of
 reasons (e.g., to hide network topology, to defeat hosts from
 offering network services directly, etc.).

 An example is an NPTv6 translator [RFC6296] using a prefix longer
 than /56 for its algorithmic address mapping.  In such 
context, if a
 remote server enforces policies (e.g., blacklist a 
misbehaving user)
 based on the first 48 or 56 bits, several IPv6 hosts will be
 impacted.

 Is the new text better?

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-04.txt

2012-08-21 Thread mohamed.boucadair

Re-,

This version integrates the comments from J. Halpern. Many thanks to Joel for 
the review. 

A diff is provided below to see the changes.


Cheers,
Med

-Message d'origine-
De : i-d-announce-boun...@ietf.org 
[mailto:i-d-announce-boun...@ietf.org] De la part de 
internet-dra...@ietf.org
Envoyé : mardi 21 août 2012 17:19
À : i-d-annou...@ietf.org
Cc : int-area@ietf.org
Objet : I-D Action: draft-ietf-intarea-nat-reveal-analysis-04.txt


A New Internet-Draft is available from the on-line 
Internet-Drafts directories.
 This draft is a work item of the Internet Area Working Group 
Working Group of the IETF.

   Title   : Analysis of Solution Candidates to 
Reveal a Host Identifier (HOST_ID) in Shared Address Deployments
   Author(s)   : Mohamed Boucadair
  Joe Touch
  Pierre Levis
  Reinaldo Penno
   Filename: draft-ietf-intarea-nat-reveal-analysis-04.txt
   Pages   : 22
   Date: 2012-08-21

Abstract:
   This document analyzes a set of solution candidates to mitigate some
   of the issues encountered when address sharing is used.  In
   particular, this document focuses on means to reveal a host
   identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application
   proxies are involved in the path.  This host identifier must be
   unique to each host under the same shared IP address.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-
analysis-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Nat Reveal Analysis

2012-08-20 Thread mohamed.boucadair

Dear Joel,

Thank you for the review. 

Please see inline. 
Cheers,
Med 

-Message d'origine-
De : int-area-boun...@ietf.org 
[mailto:int-area-boun...@ietf.org] De la part de Joel M. Halpern
Envoyé : lundi 20 août 2012 22:52
À : Internet Area
Objet : [Int-area] Nat Reveal Analysis

My thanks to the authors for submitting a revised version of 
draft-ietf-intarea-nat-reveal-analysis-03.

I have looked at this document, and have a few comments.
First, thank you for removing the explicit recommendation.

I find section 2.1 on IPv6 applicability somewhat confusing.  The most 
common technique I know of for topology hiding, NPT66, does so in a 
fashion that does not conflate identities.  As such, it is not obvious 
that there is an IPv6 problem.  It seems that this short 
section should 
either be removed or elaborated.

Med: I updated the text as follows:

OLD:

   Some of the issues mentioned in Section 2 are independent of IPv4 vs.
   IPv6.  Even in IPv6, address sharing can be used for a variety of
   reasons (e.g., to hide network topology, to defeat hosts from
   offering network services directly, etc.).

NEW:

   Some of the issues mentioned in Section 2 are independent of IPv4 vs.
   IPv6.  Even in IPv6, address sharing can be used for a variety of
   reasons (e.g., to hide network topology, to defeat hosts from
   offering network services directly, etc.).

   An example is an NPTv6 translator [RFC6296] using a prefix longer
   than /56 for its algorithmic address mapping.  In such context, if a
   remote server enforces policies (e.g., blacklist a misbehaving user)
   based on the first 48 or 56 bits, several IPv6 hosts will be
   impacted.

Is the new text better?



Minor:
 Is there a reason that the analysis in section 5 is in a 
different 
order than the columns of the table in section 4?  It would help the 
reader if they proceeded in the same order.

Med: The table is updated to follow the same order as in Section 5. The order 
is Section 5 follows the protocol layering. 

 Also, did the authors consider reversing the order of sections 4 
and 5?  In trying to read the very useful summary at the end 
of section 
4, I found that I kept needing to read ahead to section 5, and then go 
back to the summary.

Med: I reversed the order of these 2 sections in my local copy. The new ToC is:

   4.  Detailed Solutions Analysis  . . . . . . . . . . . . . . . . .  7
   5.  Solutions Analysis: Synthesis  . . . . . . . . . . . . . . . . 15



 In the description in 5.1 of the IP-ID function, it seemed to me 
that the server would need to know in all cases whether or not this is 
being used.  I can imagine mechanisms to provide that 
information.  But 
the text implies that only some variants of IP-ID need such additional 
information.  Am I missing some obvious reason why it is not always 
necessary?

Med: The advert mechanism is needed for all schemes. I updated the text to 
avoid that confusion.

OLD:


   A variant of this approach relies upon the format of certain packets,
   such as TCP SYN, where the IP-ID can be modified to contain a 16 bit
   HOST_ID.  Address sharing devices performing this function would
   require to indicate they are performing this function out of band,
   possibly using a special DNS record.

NEW:

   A variant of this approach relies upon the format of certain packets,
   such as TCP SYN, where the IP-ID can be modified to contain a 16 bit
   HOST_ID.

   Address sharing devices performing this function would require to
   indicate they are performing this function out of band, possibly
   using a special DNS record.



Nit: Is section 4.1 (requirements on the solution) really privacy 
related recommendations?  Would it make sense to call it that, 
and maybe 
move it into section 3 (privacy)?

Med: Done. The updated ToC is now:

   3.  HOST_ID and Privacy  . . . . . . . . . . . . . . . . . . . . .  6
 3.1.  Privacy-related Requirements . . . . . . . . . . . . . . .  7



I believe the concerns raised above can be easily addressed, and once 
done this document seems to be ready for advancement.

Med: Thanks.



Yours,
Joel M. Halpern
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] I-D Action: draft-ietf-intarea-nat-reveal-analysis-03.txt

2012-08-07 Thread mohamed.boucadair

Dear all,

The main changes are:

* Remove the recommendation text
* Add a new solution using an out-of-band mechanism (IDENT)
* Add a reference to A+P
* Several editorial changes to integrate the comments received during WGLC

A diff link is provided below. 

Cheers,
Med


-Message d'origine-
De : i-d-announce-boun...@ietf.org 
[mailto:i-d-announce-boun...@ietf.org] De la part de 
internet-dra...@ietf.org
Envoyé : mardi 7 août 2012 15:52
À : i-d-annou...@ietf.org
Cc : int-area@ietf.org
Objet : I-D Action: draft-ietf-intarea-nat-reveal-analysis-03.txt


A New Internet-Draft is available from the on-line 
Internet-Drafts directories.
 This draft is a work item of the Internet Area Working Group 
Working Group of the IETF.

   Title   : Analysis of Solution Candidates to 
Reveal a Host Identifier (HOST_ID) in Shared Address Deployments
   Author(s)   : Mohamed Boucadair
  Joe Touch
  Pierre Levis
  Reinaldo Penno
   Filename: draft-ietf-intarea-nat-reveal-analysis-03.txt
   Pages   : 22
   Date: 2012-08-07

Abstract:
   This document analyzes a set of solution candidates to mitigate some
   of the issues encountered when address sharing is used.  In
   particular, this document focuses on means to reveal a host
   identifier (HOST_ID) when a Carrier Grade NAT (CGN) or application
   proxies are involved in the path.  This host identifier must be
   unique to each host under the same shared IP address.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-nat-reveal-analysis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-nat-reveal-
analysis-03


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02

2012-08-01 Thread mohamed.boucadair

Dear SM,

Please see inline. 

Cheers,
Med 

-Message d'origine-
De : SM [mailto:s...@resistor.net] 
Envoyé : mercredi 1 août 2012 00:15
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : int-area@ietf.org
Objet : RE: [Int-area] Comments on 
draft-ietf-intarea-nat-reveal-analysis-02

Hi Med,
At 01:17 AM 7/26/2012, mohamed.boucad...@orange.com wrote:
Med: The issue is described in detail in RFC6269:


In addition, there are web tie-ins into different 
blacklists that web
administrators subscribe to in order to redirect users 
with infected
machines (e.g., detect the presence of a worm) to a URL that says
Hey, your machine is infected!.  With address sharing, someone
else's worm can interfere with the ability to access the 
service for
other subscribers sharing the same IP address.

That's not an issue; it's more of an action which may be taken once 
the relevant host is identified.

Med: That's the point, if there is not identifier to disambiguate hosts sharing 
the same address, all these users will be impacted.


Thinking aloud, this is more like creating a problem by sharing the 
same identifier and creating another identifier to solve that 
problem. :-)

Med: IPv4 address sharing is already deployed but still the widely 
deployed model is to assign public IP addresses to customers. Would 
you be OK with changing due to the introduction of CGNs to due to 
the massive introduction of CGNs?

If the technology has significant deployment, it does not make that 
difference whether it is introduced or massively introduced.  I 
suggest using the word deployed to keep it simple.

Med: OK. The text is updated accordingly.


Med: I'm mainly thinking about NPTv6 (RFC6296).

I am not keen on seeing this in IPv6 unless we are already running 
out of IPv6 addresses. :-)

Med: NPTv6 does not deal with IP address depletion. Multi-homed enterprise site 
may for instance be tempted to play with that kind of techniques. I'm not 
advocating for it not arguing against. The document does only raise the point. 


Med: Host Identity Protocol. A reference is provided in the draft.

I suggest expanding on first use (RFC Editor nits).

Med: Done.


Med: X-Forwarded-For. The acronym is expanded in the draft but in 
Section A.8.1. I will make sure it is expanded in first use.

Ok.

Med: Could you please indicate what is not fair about that 
sentence? Thanks.

I would not compare solutions at different layers and qualify them as 
a fair comparison.

Med: The purpose of the draft is to analyse and compare between alternative 
channels to convey the HOST_ID information. A set of criteria to assess the 
efficiency of each channel to solve encountered issues is used for that 
purpose.  


Med: XFF allows to prepend a list of IP addresses when several 
address sharing, application proxies, etc. are in the path. The term 
compatible is used to indicate XFF can be used in that scenario. If 
you have any better wording, please advise. Thanks.

I'll get back to you on this.

Med: Anonymity may be provided; see for instance the TOR service.

There was some discussion about privacy and identifiers for another 
draft.  You might end up getting in a long discussion about 
the privacy angle.

Med: XFF is for instance an HTTP header, via is a SIP header, etc. 
Would it be better if we change Application Header to Application 
Protocols Headers?

If I recall correctly, the term is message header fields.

Med: I wanted to have a generic title in which Application is mentioned. I 
will use Inject Application Protocol Message Headers. I can change it if 
there are better suggestions. Thanks.


Regards,
-sm

P.S. Sorry for being short. 


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02

2012-07-27 Thread mohamed.boucadair

Hi Behcet,

The argument I heard in Paris meeting for including a recommendation is to help 
vendors to select the solution to implement in their devices. They can not 
provide the same feature using 8 implementation options. That argument makes 
sense to me. 

Now, as I said earlier, I will remove or maintain that section according to the 
guidance from the WG. 

Cheers,
Med 

-Message d'origine-
De : Behcet Sarikaya [mailto:sarikaya2...@gmail.com] 
Envoyé : jeudi 26 juillet 2012 19:09
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Suresh Krishnan; Internet Area
Objet : Re: [Int-area] Completion of working group last call 
for draft-ietf-intarea-nat-reveal-analysis-02

On Thu, Jul 26, 2012 at 3:25 AM,  mohamed.boucad...@orange.com wrote:
 Dear Suresh, all,

 After reading received comments, the major point we need to 
discuss is whether the WG wants to remove Section 3.3 or 
maintain it. I'm waiting for a feedback from the WG for the 
direction to take. I will implement any change requested by the WG.


Section 3.3 seems to give preference to one specific solution, as such
it is against the whole spirit of this document.

I suggest removing it.

Behcet
 Cheers,
 Med


-Message d'origine-
De : int-area-boun...@ietf.org
[mailto:int-area-boun...@ietf.org] De la part de Suresh Krishnan
Envoyé : vendredi 20 juillet 2012 20:56
À : Internet Area
Objet : [Int-area] Completion of working group last call for
draft-ietf-intarea-nat-reveal-analysis-02

Hi all,
  After going through the responses to the WGLC, it is clear that the
draft is not ready to go forward in the publication process. We will
discuss further steps for this draft at the Vancouver meeting.

Thanks
Suresh  Julien
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

 ___
 Int-area mailing list
 Int-area@ietf.org
 https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02

Dear Joe, all,

Apologies for the delay to answer (I was out of office).

I have no problem to remove Section 3.3 if this is what the WG wants. As a 
reminder, I added that section after the Paris meeting in accordance with what 
I heard in the meeting: more voices in favour of adding a recommendation. I 
sent a notification to the mailing list mid-april to acknowledge this change. 

Now, I'm waiting for a feedback from the WG to maintain or to remove Section 
3.3.

Cheers,
Med


-Message d'origine-
De : int-area-boun...@ietf.org 
[mailto:int-area-boun...@ietf.org] De la part de Joe Touch
Envoyé : vendredi 6 juillet 2012 02:17
À : Suresh Krishnan
Cc : Internet Area
Objet : Re: [Int-area] ACTION REQUIRED: Extending working 
group last call for draft-ietf-intarea-nat-reveal-analysis-02

As a co-author, I didn't want to remain silent per se, so I'll 
at least 
be public in my view.

I think the doc is good, but I do take Alissa's concerns to point - it 
might be preferable to remove section 3.3 and leave this doc as a 
comparison of solutions, and avoid any recommendation of a way forward 
at this point.

Joe

On 6/27/2012 8:57 AM, Suresh Krishnan wrote:
 Hi all,
The WGLC on this draft ended with no comments at all. In 
this context,
 we cannot assume that silence equates to consent. In order for this
 draft to progress, we need people to read the draft and provide their
 opinions on whether the draft is ready. To enable people to 
comment, the
 last call period is extended until Friday July 6, 2012.

 Thanks
 Suresh and Julien

 On 06/08/2012 10:06 AM, Suresh Krishnan wrote:
 Hi all,
This message starts a two week intarea working group last call on
 advancing the draft about Analysis of Solution Candidates 
to Reveal a
 Host Identifier (HOST_ID) in Shared Address Deployments as an
 Informational RFC. The draft is available at

 http://www.ietf.org/id/draft-ietf-intarea-nat-reveal-analysis-02.txt
 http://tools.ietf.org/html/draft-ietf-intarea-nat-reveal-analysis-02

 Substantive comments and statements of support/opposition 
for advancing
 this document should be directed to the mailing list. Editorial
 suggestions can be sent directly to the authors. This last call will
 conclude on June 22, 2012.

 Regards,
 Suresh  Julien
 ___
 Int-area mailing list
 Int-area@ietf.org
 https://www.ietf.org/mailman/listinfo/int-area

 ___
 Int-area mailing list
 Int-area@ietf.org
 https://www.ietf.org/mailman/listinfo/int-area


___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] ACTION REQUIRED: Extending working group last call for draft-ietf-intarea-nat-reveal-analysis-02

Dear Lars,

Please see inline.

Cheers,
Med 

-Message d'origine-
De : int-area-boun...@ietf.org 
[mailto:int-area-boun...@ietf.org] De la part de Eggert, Lars
Envoyé : vendredi 6 juillet 2012 09:40
À : Alissa Cooper
Cc : Internet Area
Objet : Re: [Int-area] ACTION REQUIRED: Extending working 
group last call for draft-ietf-intarea-nat-reveal-analysis-02

On Jul 5, 2012, at 22:48, Alissa Cooper wrote:
 With the changes to this draft in the -02 version, I'm 
having a little trouble seeing its purpose. It basically now 
seems like a shell for the recommendation in 3.3, with the 
analysis stuffed into appendices. But given that there is no 
stable proposal for the actual TCP option to be implemented, 
what is the purpose for advancing this document right now? I 
think I've heard that folks needed to know what to 
implement, but does this document really resolve that problem 
given that even within the space of TCP-option-based solutions 
for this, there are multiple different proposals, none of 
which has been standardized? This document made more sense 
when it was just a comparison of the different potential 
solutions spaces.

Fully agree with Alissa. An comparison of options would be 
fine. But 3.3 and other text go beyond a comparison.

Med: FYI I added Section 3.3 after the Paris meeting where I asked the question 
whether we need to add a recommendation or not. It seems to me I heard more 
voices for having a recommendation in the document. A notification has been 
sent to this mailing list in mid-april. Anyway, I'm open to record the 
consensus of the WG: maintain or remove that section. 


I also don't understand why INTAREA is entertaining work that 
is clearly intending to define new TCP options.

Med: This draft is not about the TCP option but to analyze a set of solutions 
to solve a problem already documented in RFC6069. 


 None of the 
-abdo- drafts have been presented in TCPM or even discussed on 
the mailing list. (My guess is that the authors know that this 
would never get traction in TCPM and are venue shopping.)


Med: I checked tcpm agenda, draft-abdo will be presented in tcpm in Vancouver. 


Lars
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02


Dear Wes,

Please see inline.
Cheers,
Med 

-Message d'origine-
De : int-area-boun...@ietf.org 
[mailto:int-area-boun...@ietf.org] De la part de Wesley Eddy
Envoyé : mardi 10 juillet 2012 01:26
À : Tina TSOU
Cc : int-area@ietf.org
Objet : Re: [Int-area] Comments on 
draft-ietf-intarea-nat-reveal-analysis-02

I read the document and came to rather different conclusions (see
below):

On 7/9/2012 4:41 PM, Tina TSOU wrote:
 I reviewed this draft and I found it very detailed about the various
 ways of including a HOST ID. Considering the number of users 
that share
 the same IPv4 address, there is an increasing importance of 
the HOST ID.
 Though it is discussed in the introduction about the various
 implications of not having HOST IDs, in my opinion, there should be a
 little more explanation of the problems faced if there is no HOST ID
 included. Moreover, the main concern is security issue. It is very
 difficult to identify a particular user, when there are a number of
 users with different private IP addresses sharing the same 
public address.


I agree with you that if the document is pursued, it should include
more discussion of what the problems are with not having a host ID;
the current text seems like handwaving to me.

Med: The issues have been already documented in RFC6269. The draft includes 
pointers to some sections from that draft.


  I don't personally
think it is very well motivated, and from my standpoint there is
absolutely no reason to pursue a solution.  It would be enough to
simply have the analysis documented as to why all of the considered
approaches COMPLETELY STINK.

But aside from that, I disagree with you on purpose of whatever is
being attempted here.  The document is about identifying hosts, and
you mention users.  These are not the same thing.  Which do you want
to identify?  In my opinion, anything related to users (and not hosts)
should be completely out of scope.

Med: Agreed. The notion of user is out of scope of 
draft-ietf-intarea-nat-reveal-analysis.



Further, I think the problem has to perhaps be refined to
disambiguating between different hosts using the same IP address
versus trying to semi-uniquely identify the hosts.  The problems
described are due to aliasing, and unique identification is a
rather strong means of de-aliasing.


 The TCP option is another good way to include the HOST ID in 
case of TCP
 and UDP communications. 


Surely there's a typo there, since it does not work at all in the
case of UDP.

I disagree with the overall recommendation of the document, since
it presumes that a solution is required, among other flaws with it.

Med: The recommendation has been added after the Paris meeting. I asked during 
the presentation whether we need to add a reco or not: I heard voices for 
having a reco.  


Additionally, it is not particularly clear how this can work for
multiple layers of sharing (e.g. CGN), though draft-abdo seems to
think that CGN is a single layer of sharing.

Med: Good point. draft-abdo focuses on ds-lite model and as such there is only 
one level of NAT. Even in such scenario, the CGN is configured to strip an 
existing HOST_ID option since this information is not trusted. For double NAT 
scenario, only the external IP address after the first NAT is important to be 
passed by the second NAT.


-- 
Wes Eddy
MTI Systems
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Comments on draft-ietf-intarea-nat-reveal-analysis-02

Dear SM,

Apologies for the delay to answer. 

Please see inline.

Cheers,
Med  

-Message d'origine-
De : int-area-boun...@ietf.org 
[mailto:int-area-boun...@ietf.org] De la part de SM
Envoyé : samedi 7 juillet 2012 10:41
À : int-area@ietf.org
Objet : [Int-area] Comments on 
draft-ietf-intarea-nat-reveal-analysis-02

Hello,

I have a few comments on draft-ietf-intarea-nat-reveal-analysis-02.

In Section 1.1:

   Examples of such issues are listed below:

 Redirect users with infected machines to a dedicated portal

Why is this an issue?

Med: The issue is described in detail in RFC6269:


   In addition, there are web tie-ins into different blacklists that web
   administrators subscribe to in order to redirect users with infected
   machines (e.g., detect the presence of a worm) to a URL that says
   Hey, your machine is infected!.  With address sharing, someone
   else's worm can interfere with the ability to access the service for
   other subscribers sharing the same IP address.



   The risk of not mitigating these issues are: OPEX increase for IP

I suggest expanding OPEX on first use.

Med: Done. 


In Section 2:

   Tomorrow, due to the introduction of CGNs (e.g., NAT44
[RFC3022], NAT64 [RFC6146]), that address will be shared.

Isn't IPv4 shared addresses already in use in the wild?

Med: IPv4 address sharing is already deployed but still the widely deployed 
model is to assign public IP addresses to customers. Would you be OK with 
changing due to the introduction of CGNs to due to the massive introduction 
of CGNs?


In Section 2.1:

   A solution to reveal HOST_ID is also needed in IPv6 deployment.

I suggest soliciting feedback from V6OPS about this.

The draft already mentions that the issue is caused by IPv4 address 
sharing.  It then goes on to suggest that address sharing can be used 
for IPv6.  That is going to create the same problem there and argue 
for the solution mentioned in this draft.

Med: I'm mainly thinking about NPTv6 (RFC6296). 


In Section 3.2:

   Requires the client and the server to be HIP-compliant and HIP
infrastructure to be deployed.

What's HIP?

Med: Host Identity Protocol. A reference is provided in the draft.


   XFF is de facto standard deployed and supported in operational
networks

What's XFF?

Med: X-Forwarded-For. The acronym is expanded in the draft but in Section 
A.8.1. I will make sure it is expanded in first use.


   From an application standpoint, the TCP Option is superior to XFF/
Forwarded-For since it is not restricted to HTTP.

That doesn't sound like a fair comparison.

Med: Could you please indicate what is not fair about that sentence? Thanks.  


   Nevertheless XFF/Forwarded-For is compatible with the presence of
address sharing and load-balancers in the communication path.

What is the meaning of compatible in here?

Med: XFF allows to prepend a list of IP addresses when several address sharing, 
application proxies, etc. are in the path. The term compatible is used to 
indicate XFF can be used in that scenario. If you have any better wording, 
please advise. Thanks.


In Section 4:

   some users realize privacy benefits associated with IP address
sharing, and some may even take steps to ensure that NAT
functionality sits between them and the public Internet.

What are the privacy benefits of IP address sharing?

Med: Anonymity may be provided; see for instance the TOR service.


In skimmed over the appendix.  What's Application Headers?

Med: XFF is for instance an HTTP header, via is a SIP header, etc. Would it 
be better if we change Application Header to Application Protocols Headers?


This draft would benefit from cross-area review.  It needs more work 
in my humble opinion.

Regards,
-sm




___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area

Re: [Int-area] Completion of working group last call for draft-ietf-intarea-nat-reveal-analysis-02