Re: [APPS-REVIEW] Review of HTTP Binding for DSKPP

Hi Barry,

Barry Leiba wrote:
>> I am not sure whether the separate port number idea will find a lot of
>> excitement since the downside is that a network operator that just 
>> does not
>> care about the specific protocol (even through he does not mind 
>> allowing end
>> hosts to run it) will essentially block it.
>
> Hannes, I'm not sure I understand what you're saying here, so maybe 
> you should explain more.  What I read it as saying is that you don't 
> like using a separate port because you *want* to sneak through 
> firewalls without telling the firewall administrators.  There be 
> dragons, and that was Chris's point.  A protocol that looks like HTTP 
> but is used for a different purpose should be on a different port.
>
> Actually, I've had this argument with people within my company too, 
> and it might be that we aren't clear about what the port-number list 
> *is*: it should be more like a list that maps *applications*, rather 
> than *protocols*, to ports.  In most cases, that's the same.  But with 
> SMTP and HTTP, at least, it's not.
>
I agree that it would be nice to allow administrators to make these type 
of decisions.

In other areas in the IETF folks also had the idea that the network 
administrators are going to configure their networks in such a way that 
the protocols would work. SIP and NAT/Firewall traversal is a good 
example. It took a while to realize that this is not a good approach.

DSKPP is an application layer protocols that allows an end point to 
retrieve keying material for usage with other protocols. Typically, the 
client on an end host will interact with a server in it's home network.
If I am in a hotel network and want to obtain new keying material for 
usage with my VPN client and the network administrator of the hotel 
network does not know the port number used by DSKPP then it might happen 
that I just cannot use the protocol.

Now, there are also other protocols flying around in this space; 
actually a large number of protocols in this identity management space 
that happen to run on top of HTTP without using an additional port (at 
least to my knowledge).

I don't see why these protocol should work in all environments (where 
HTTP traffic is allowed to bypass a middlebox) but a protocol developed 
within the IETF isn't just because there is this idea of a "clean 
architecture".

Does my reasoning make sense to you?

Ciao
Hannes

> Barry

_______________________________________________
APPS-REVIEW mailing list
APPS-REVIEW@ietf.org
https://www1.ietf.org/mailman/listinfo/apps-review