RE: SIP as an alternative to IKE?, was: Re: [Sip] RE: TLS meaning

["Dan Wing" <[e-mail]>]

> On Nov 2, 2006, at 3:11 AM, Aki Niemi wrote:
> 
> > Rants are so much fun. Another inline.
> 
> Excellent rant, which could be summarized as "deprecate UDP". 
> I think that's an interesting suggestion. It almost sounds like 
> something I might have said myself at some timeIt would also 
> solve our large-responses problem, and our "oh my god my request 
> is too big to send in one packet" problem, and a bazillion 
> other things.
> 
> It does have a bit of susceptibility to the RST DOS attack of TCP to  
> think about,

If you're worried about that attack, you should be equally concerned
about a nearly-identical attack on UDP that seems apparent -- 
draft-jung-sipping-authentication-spit-00 discusses a solution, but
as I have posted earlier, if a UA expects all messages from its
proxy contain Authentication-Info, we may be able to solve the
same problem.

> something that DTLS does not suffer from. But 
> other than that and inertia I can think of no good reason to 
> keep using UDP.

To be clear, DTLS does not solve the large UDP problem -- DTLS 
has support for fragmentation, but only for the TLS handshake 
itself.  We could, and maybe should, invent some framing 
so that DTLS could solve that problem, too.  Adding such framing
might be appropriate if/when draft-jennings-sip-dtls-02.txt 
becomes a WG item.

> I'll note however that Robert reports that SIPit seems to indicate  
> that most implementations are dealing with fragmented UDP just fine  
> and nobody is actually noticing any problems with large packets, so  
> we may be "burning a straw witch" when we worry about fragmentation.  
> Personally, I'm far more worried about rampant complexity.

That conflicts with the conclusion of 
draft-heffner-frag-harmful-02, which is in IETF last call.

-d

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip