Subject: RE: [Sip] I-D ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 8 Jun 2006 21:15:24 +0100

I guess at the very least we need to ensure that the security considerations details how this is not used as an amplification attack, such that it congests the network.

However, do we need more than this?

regards

Keith

> -----Original Message-----
> From: Scott Lawrence [mailto:[email-masked]]
> Sent: 08 June 2006 16:12
> To: Cullen Jennings
> Cc: Drage, Keith (Keith); [email-masked]
> Subject: Re: [Sip] I-D
> ACTION:draft-ietf-sip-hop-limit-diagnostics-02.txt
> 
> 
> On Wed, 2006-06-07 at 07:34 -0700, Cullen Jennings wrote:
> > I think it still has at least one serious question open - 
> that being  
> > does it help or harm?
> 
> Or more generally, does it help more than it harms?  Diagnosing bad
> routing can be a real pain - can you imagine running a network without
> traceroute?
> 
> > The example in the draft, each via is about 87 octets and 
> imagine  it  
> > had 70 hops or so. This would be a real big response - too 
> big for a  
> > UDP packet most likely. To follow the congestion safety, I 
> don't know  
> > how to deal with this. If seems that in many systems, the resource  
> > would simply be dropped because it is too large. It seems like not  
> > getting any response would be far worse than getting getting a  
> > response that did not have the debugging information.
> 
> In experiments at SIPit we found that all the proxies tested 
> clamped the
> hop limit to 20 (no one knew why this value was apparently 
> independently
> chosen by all of them - it was quite a surprise), so it does not seem
> likely that anything is going to get to 70 hops (why was such a large
> value chosen - it seems wildly unlikely to me that it would ever be
> needed in a scenario that results in success).
> 
> There is advice in the draft on how to select Vias to be returned if
> want to limit the size of the response (which might be 
> dependent on the
> transport).  Are you suggesting that something stronger is needed?
> 
> -- 
> Scott Lawrence  tel:+1-781-938-5306;ext=162 or 
> sip:[email-masked]
>   sipXpbx project coordinator - SIPfoundry    
http://www.sipfoundry.org/sipX
  Chief Architect             - Pingtel Corp. http://www.pingtel.com/

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

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 08 Jun 2006 16:28:31 -0400

On Thu, 2006-06-08 at 21:15 +0100, Drage, Keith (Keith) wrote:

> I guess at the very least we need to ensure that the security
> considerations details how this is not used as an amplification
> attack, such that it congests the network.

I'm not sure what should be said - is there some text that you think is
needed?  The response message is only going to be slightly larger than
the request it is returning (and need not be as large if the returned
request is pruned as allowed for).  That's not really an amplification
(certainly not compared to the forking loop attacks that started this
and other threads).

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Architect             - Pingtel Corp. http://www.pingtel.com/