Re: francois' comments and why RFC4474 not used in the field

Jon Peterson <[email protected]>
Newsgroups gmane.ietf.sip
Message-ID <C608DEEC.2A287%[email protected]>

>> The only thing this attack is meant to illustrate is why it does matter who
>> sets the IP/port. I've gathered that some people in the discussion reject
>> the notion that there are any threats related to the setting the IP/port in
>> the signaling layer, so I'm trying to provide an example.
> 
> That is because, ** in conjunction with media-path validation **
> (which is the important point), the attack is prevented.

You're talking about a solution here; I'm really trying to establish that
there's a problem. The two are not mutually exclusively - ideally we will
have both a problem and a solution. I am however uncertain that we have a
common understanding of the problem.

I'm not sure I know what you mean by media-path validation, here, but I do
think that there are many important attacks against SIP that accomplish
their aims without ever establishing a media session. These include
signaling-layer attacks that would, for example, tear down the media
associated with an existing call. I have a hard time seeing how anything we
do at the media layer is salient to that - again, just speaking to high
level examples, if you accept a forged BYE request, that will presumably
convince you to tear down a call regardless of anything that media-layer
security has established. I've argued a similar requirement exists to
prevent a forged re-INVITE that just sets the IP/port to something useless.
When I hear you say that some property of media path prevents this sort of
attack, then I gather we must disagree about the problem, not just the
solution. Can you explain a bit what you mean here by media-path validation
and how it prevents the sorts of attacks I just mentioned?

Jon Peterson
NeuStar, Inc.

> -d

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.