ietf
[Top] [All Lists]

RE: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-mm-wg-effect-encrypt-09)

2017-04-12 04:03:46
Re-,

Please see inline. 

Cheers,
Med

-----Message d'origine-----
De : Stephen Farrell [mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie]
Envoyé : mercredi 12 avril 2017 10:35
À : BOUCADAIR Mohamed IMT/OLN; Dave Dolson; Martin Thomson; 
ietf(_at_)ietf(_dot_)org
Cc : draft-dolson-plus-middlebox-benefits(_at_)tools(_dot_)ietf(_dot_)org
Objet : Re: draft-dolson-plus-middlebox-benefits (was RE: Review of draft-
mm-wg-effect-encrypt-09)


Hiya,

On 12/04/17 09:13, mohamed(_dot_)boucadair(_at_)orange(_dot_)com wrote:
Hi Stephen,

Please see inline.

Cheers, Med

-----Message d'origine----- De : Stephen Farrell
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie] Envoyé : mardi 
11 avril 2017
20:34 À : Dave Dolson; BOUCADAIR Mohamed IMT/OLN; Martin Thomson;
ietf(_at_)ietf(_dot_)org Cc :
draft-dolson-plus-middlebox-benefits(_at_)tools(_dot_)ietf(_dot_)org 
Objet : Re:
draft-dolson-plus-middlebox-benefits (was RE: Review of draft-
mm-wg-effect-encrypt-09)



On 11/04/17 13:03, Dave Dolson wrote:
Regarding "benefits", these devices clearly have perceived
benefits

I do not agree that the IETF ought described perceived benefits as
if the claimed benefits accrue as hoped for.

[Med] I'm afraid it is hoped for some functions. For example, the
IETF specified in the past many functions to provide specific
services (called benefit in draft-dolson) such as NAT64 (IPv4 service
continuity).

I'm not sure that s/benefits/services/g in the document text
would work, so I don't accept that argument. If you meant
something else, I'm not sure what.


If you don't perceive that function as a "benefit", can you please
answer the following:

* Because your operator is running out of IPv4 addresses, it decides
to give you an IPv6 prefix without enabling any function in the
network. Won't you call the hotline of that operator to claim that
you don't access to most of Internet resources and that something is
to be fixed otherwise you will unsubscribe?

* When you are attending an IETF meeting, I assume you are using
IPv6-only SSID. Do you volunteer to opt-out from NAT64 in the coming
meeting?

I did not argue that no middlebox ever provided any benefit

[Med] Cool. This is not what I understood from your initial comment: "...if the 
claimed benefits accrue as hoped for"
                                                                                
                          ^^^^^^^^^^
to anyone so I don't know how answering the above questions
would help.

[Med] I helps to understand what we can call "beneficial" or not. Having 
concrete examples is helpful. 


But in case it does help: yes, firewalls have provided some
benefits over the years. I suspect those are now diminishing
but could be wrong. I don't know if it's gotten to the point
that firewalls are more of a benefit or a scourge today. (Having
just had the fun of installing a stun/turn server to get two
browsers to chat with one another, I can freshly attest to the
"pointless scourge" aspect as I didn't have to ask the f/w
admins anything to get around the useless barrier they were
in this particular case;-)

It might be possible to do studies and produce data that'd help
the community decide that question (f/w utility vs. scourge) and
that could be a useful activity, if done objectively. That last
(objectivity) seems hard though, as it seems there are many folks
who find being objective in this space difficult (on all sides).

[Med] Yes, that's a collective effort to be made by all. In the meantime, we 
need to remember that IETF is supposed to do ENGINEERING. 

I've no idea if similar studies and data could help with
(re-)evaluating other aspects of middlebox deployment claimed
utility.

And again, I see no utility at all in a statements along the
lines that "firewalls are beneficial because they can do X."

S.



That is far too
close to marketing. In a contentious case like this, I can see why
someone may feel that's useful as a form of balance or part of a
larger debate, but in the end I think we need to step back and take
an engineering approach.

[Med] Fully agree. This is why we need to understand the intended
usage to have a reference for any engineering approach.


S

to those who deploy them. My view is that the document should
explain that perspective for readers who lack the operator
perspective. The intent was not to mandate or recommend
deployments.

David Dolson ‎ Original Message From:
mohamed(_dot_)boucadair(_at_)orange(_dot_)com Sent: Tuesday, April 11, 
2017 7:48
AM To: Stephen Farrell; Martin Thomson; ietf(_at_)ietf(_dot_)org Cc:
draft-dolson-plus-middlebox-benefits(_at_)tools(_dot_)ietf(_dot_)org 
Subject: RE:
draft-dolson-plus-middlebox-benefits (was RE: Review of
draft-mm-wg-effect-encrypt-09)


Hi Stephen,

Please see inline.

Cheers, Med

-----Message d'origine----- De : Stephen Farrell
[mailto:stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie] Envoyé : 
mardi 11 avril
2017 10:51 À : BOUCADAIR Mohamed IMT/OLN; Martin Thomson;
ietf(_at_)ietf(_dot_)org Cc :
draft-dolson-plus-middlebox-benefits(_at_)tools(_dot_)ietf(_dot_)org 
Objet :
Re: draft-dolson-plus-middlebox-benefits (was RE: Review of
draft- mm-wg-effect-encrypt-09)


Hi Med,

On 11/04/17 09:15, mohamed(_dot_)boucadair(_at_)orange(_dot_)com wrote:
I hope that the IETF never publishes
draft-dolson-plus-middlebox-benefits; it makes claims
about the benefits of specific solutions for different use
cases with the goal of justifying those solutions.

[Med] I'm afraid this is speculating about the intent of
draft-dolson. Assured this is not the purpose of that
document. The motivation is to document current practices
without including any recommendation or claiming these
solutions are superior to others.

Just to note that I completely agree with Martin's
interpretation of the thrust of this draft and I totally fail
to see how your argument above can be justified given that
draft title, abstract and even filename (and also the
content;-).

[Med] "beneficial" is derived from the initial request that
motivated this draft (excerpt from the abstract):

At IETF97, at a meeting regarding the Path Layer UDP Substrate
(PLUS) protocol, a request was made for documentation about the
benefits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ that
might be provided by permitting middleboxes to have some
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
visibility to transport-layer information.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

When the abstract
says "This document summarizes benefits" then I cannot
interpret that as other than being intended to justify the uses
described.

[Med] I would prefer if we can avoid to "interpret", but raise
questions to the authors if there is a doubt. The document does
not provide a recommendation or claims this is the only way to
achieve the technical goals. It does only reflect some deployment
reality together with some motivations.


A fairly thorough re-write to aim to describe the pros and
cons would be a different and more useful document.

[Med] There are already many RFCs that discuss the issues/cons (I
can cite this RFC I co-authored
https://tools.ietf.org/html/rfc6269 for the CGN case). What is
needed IMHO is something else: understand the requirements that
led to deploy some of these functions.

Similarly a draft
that strives to neutrally describe existing reality could maybe
be useful (*)

[Med] This is the intent of draft-dolson.

but one that only describes middlebox friends with
"benefits" is not IMO beneficial ;-)

[Med] The intent is not to "sell something" but to understand
the technical needs so that hopefully we can have a reference for
future solution-oriented discussions. If a given function can be
provided without involving an on-path device, this would be great
for operators (optimize CAPEX/OPEX is our motto).


Cheers, S.

(*) That is the argument for draft-mm-effect-encrypt, for which
I do support publication (apparently in disagreement with
Martin in that case:-)







<Prev in Thread] Current Thread [Next in Thread>