Re: [Masque] Adoption call for "Requirements for a MASQUE Protocol to Proxy IP Traffic"

[Magnus Westerlund <[e-mail]>]

Hi,
(As individual)

I think this adoption call is a premature. I think the WG need to agree to the
general scope of what IP proxying in MASQUE means before we can adopt a document
on its requirement. Yes, the WG will need a working document, we likely do not
need to publish it as the resulting scope of the solution anyway should be
descirbed in the solution document that I expect the WG to produce eventually.

To make it clear why I think we should agree on a few aspects before adopting a
requirements document I would like to bring up a significant discussion point
for draft-cms-masque-ip-proxy-reqs. In setion 2 the document states:

2.  Use Cases

   There are multiple reasons to deploy an IP proxying protocol.  This
   section discusses some examples of use cases that MUST be supported
   by the protocol.

And the subsections include the following:

2.1.  Consumer VPN
2.2.  Point to Point Connectivity
2.3.  Point to Network Connectivity
2.4.  Network to Network Connectivity

The first three I think have very similar solution space and big overlap in
functionality requried to safely do them. However, the one I really think we
need to discuss more indept before agreeing to do it is: 

2.4 Network to Network Connectivity.

So from my point of view the solution for this can fall into two main
categoriezs. 

A) The MASQUE server is the owner of the network prefix being proxied

B) The MASQUE server proxies any network prefix given by client

The reason for dividing it up like this is to look at what is required to safely
deploy these two differnt versions. 

In A) the MASQUE server gives the MASQUE client and its local network a prefix
that is has been assigned to hand out for this purpose and where the upstream
router has a route for the whole prefix that the MASQUE server uses to hand out.
In this case source address validation for the MASQUE server is easy. By only
forwarding source address from the prefix handed out there are no risks for
source address spoofing through the MASQUE server. Also, from a routing
perspective the route to the prefixes the MASQUE server uses is a primary route
and one which network adimns have a chance of doing attestation of ownership for
the address space. 

In B) if the MASQUE client can inject any network prefix to the MASQUE server we
have just created a tool for avoiding source address validation, or we need to
have a solution where the MASQUE server can verify the source address ownership
to the client. Secondly, this allows then route injection into the routing
system that are likely to go all the way to BGP in the general case. 

I think I understand Google's use case and why they push this, and from their
perspective this is done using internal network resources and networks prefixes
that they will control and they can authorize. However, from a general MASQUE
solution this do require a security solution and discussion of this security
threat realted to source address validation, and impact on routing. Thus, the
scope of the work if B) is included is significant larger and will take longer
time. 

I would propose that B) is not taken on initially and is for future
consideration. With that I requirements 3.4, 3.5, 3.6 can be modified and
simplified. 

I also think that not having a discussion of addressing architecture and
implications on routing by network proxying, which is what Section 4.1 states
will result in a solution that will not be published. So also that needs to be
addressed. 

The below question will also show that I think this document needs to mature a
bit prior to adoption. 

 
I also have some questions on the draft:

A. In Section 3.4:

   Similarly, to support the network-
   to-network use case, the server will be able to request assignment of
   an IP address range from the client, and the client will either
   assign a range or decline the request.

Can you elaborate why the Server would need an IP address from the Client's
network? The client will need to be a gateway in the client side network to be
able to receive the traffic to forward, but I don't see why the server needs
appear as that gateway?

B. Section 3.6:

I do understand the need for some identify. The server first of all to allow the
client to determine it is communicating with the right MASQUE server. However
for the identification of the client, is that likely at all to be a domain
name?Isn't that a user name, or some other form of authorization to use the
resource. 

C. Section 3.8 in this context I think there are more than the endpoint that
needs authoriztion if network to network proxying would happen. Also, extension
to OAUTH, doesn't that require work in another WG. It looks like more
explanation of what the needs are that prompt the need for extending the
authorization protocol. 

D. Section 3.10

I don't see an issue with a tunnel protocol being used without flow control. If
one overwhelm either of the MASQUE client or server that is equal to congestion
in the network. However, in the meeting I got the impression there was
consideration to disable congestion control also. Is this or not a requ

E. Section 3.11

I think a general VPN use would from a traffic pattern would be distinguishable
from encrypted HTTP Web traffic. Is only wire format the goal here?

F. Section 3.14

Do I interpret this section correctly that it requires a IP session to be split
from a client to two servers? If that is the case that will imply additional
functionality for path selection on a sub IP session flow level to avoid
reordering within such subflows. 

Does this also need some additional concerns if someone deploys the servers
under different networks, resulting in multi-homing scenarios where outgoing and
returning traffic for sub-flows ends up in different paths? In general you will
get some traffic steering concerns to deal with. 

To me this requirement appears to potentially imply quite a bit of more
functionality to work. 


Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Mobile [phone]
Torshamnsgatan 23           |
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------