Some quasi-nits regarding the presentation, followed by more substantive
observations:
On page 3, you do an accounting for the level of amplification and total
22 responses for a spoofed INVITE. But of course, if the spoofed call
can be directed to a UA that will answer (voicemail, anyone?), there can
be far more than 22 RTP packets generated.
On page 7, the process of resending a response that was initially
rejected with a 4XX is discussed. This should be clarified by noting
that the resent request is a further fork of the original request, which
is much different than the resending operation that is done by a UAC in
response to a 401/407 response. In particular, the CSeq is not
incremented.
In the discussion, the terms "the client" and "the server" are used,
which would lead people to think of SIP elements in the normal way. But
in this case, each input or output address/port/transport triple of an
element functions separately: A cookie used to send from a triple can
only be used to send from that triple, and similarly, the client must
cache known valid cookies for each destination triple separately.
The proposed syntax for cookie is described in the text as using "-" as
a separator, but the BNF uses ":". "-" should be used, as ":" is
invalid in a "token".
The example shows a request being sent with a value-less cookie
parameter, though the BNF immediately above does not allow such a
parameter. More importantly, such a value-less parameter does nothing
useful: If the client will accept requests without cookies, a request
without the parameter will be accepted. If the client will not accept
requests without cookies, a request without the parameter will elicit a
4XX response, which can be used to resend the request.
In regard to reusing the branch parameters of the initial request in the
resent request -- please do not do that. Implementations already depend
on proper uniqueness of branch parameters. In particular, a client that
indexes its transaction states by branch value may respond to the resent
request with the response that was given to the initial request, viz.,
4XX.
In regard to client address triples: For security, the client must
generate a cookie that is valid for the address to which the response
will be sent. And validating the cookie requires that the address from
which the request is sent matches the address within the cookie.
Together, these require "symmetric signaling", that responses always go
to the same address from which their requests came, or more exactly, the
address from which the resent request will come. In any case, the
interaction with the SIP rules in section 18.2.2 need to be enunciated
more clearly:
o Otherwise (for unreliable unicast transports), if the top Via
has a "received" parameter, the response MUST be sent to the
address in the "received" parameter, using the port indicated
in the "sent-by" value, or using port 5060 if none is specified
explicitly. If this fails, for example, elicits an ICMP "port
unreachable" response, the procedures of Section 5 of [4]
SHOULD be used to determine where to send the response.
o Otherwise, if it is not receiver-tagged, the response MUST be
sent to the address indicated by the "sent-by" value, using the
procedures in Section 5 of [4].
As Shamik notes, the cookie needs to be used not only to validate that
the request comes from the address contained in the cookie, but also to
validate the requested "sent-by" value, the address to which the
response to the later request is to be sent.
Actually, the cookie isn't needed to validate where the request comes
from, but only to validate where the response will be sent. This allows
us to escape the requirement for symmetric signaling described above --
cookies are generated based on the *destination* of the 4XX, and are
validated against the *response destination address* not the *request
source address*. This still has the required security property -- the
client can only obtain the cookie for a destination D if D cooperates in
capturing the cookie and providing it to the client. This does render
unusable the clause "If this fails...", because the client has to know
absolutely what the response destination will be.
(Or can the requester provide multiple cookies for multiple possible
destinations?)
Of course, this mechanism only give benefit if servers start enforcing
cookies, which can't be done until clients implement them. But the
mechanism can be phased in, in that client implementations can be
deployed first.
Dale
_______________________________________________
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
