Subject: RE: [Sip] WGLC for referred-by

From: "Mary Barnes" <[email-masked]>
Date: Fri, 20 Jun 2003 11:36:12 -0500

There were a couple points that I made on the list around the -01 version
that don't seem to have been addressed
http://www1.ietf.org/mail-archive/working-groups/sip/current/msg07955.html
and I couldn't find that they had been responded to on the list in the
archives: 

Editorial Nits:
-------------------
- References: authid-body and cc-transfer need upversioning.

Other items:
--------------------------------------
- Section 2.3: Last paragraph: should this be a MUST (reject an otherwise
well-formed request with an invalid token)?   Reasonably, one should, but
perhaps there are users that would still like to be able to decide
themselves, thus I would suggest this be stated similar to the previous
paragraph as:

"The refer target SHOULD reject an otherwise well-formed request with an
invalid Referred-By token (see Section 4) with a 429 error response. If the
agent chooses to proceed with the request and provides any information from
the Referred-By header to its user as part of processing the request, it
MUST notify the user that the information was determined to be invalid." 

My reasoning is that it just seems that if an optional parm is mucked up (in
general or from a security perspective), then following the adage of being
generous in what you accept ...that whether to accept the request, provided
that it is warned that it's bad,  should still be up to the user.  This also
seems consistent with the MAYs in the previous 2 paragraphs. I do understand
the reasoning that you'd want to let the Referrer know and that by allowing
the request, you're actually bypassing the security put in place to keep the
bad guys from mucking with the messages, but again since it's optional, it
just seems that you can't make it stronger than a SHOULD. 

- Section 4.1:  2nd paragraph suggesting that "A target SHOULD verify the
request...".  I don't think this is useful since retargeting makes this
check not meaningful.  UNLESS, of course, you're using History-Info.  With
History-Info, you could verify that the Refer-To matches one of the
Targeted-to-URIs (and of course, this implies that this information has all
been sent securely, not mucked with by the proxies, etc.). 

Regards,
Mary.  

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Thursday, June 19, 2003 1:39 PM
To: [email-masked]
Cc: [email-masked]; Jon Peterson; Dean Willis; 'Robert Sparks'
Subject: [Sip] WGLC for referred-by

Hello Everyone,

I would like to begin a Working Group last call on:

http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-02.txt

WGLC will end on Friday July 18th.

thanks,
-rohan

_______________________________________________
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

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: 20 Jun 2003 14:17:48 -0500

> and I couldn't find that they had been responded to on the list in the

Hmm - I'm generating this using the xmlrefs stuff from xml2rfc and
I _did_ update my copy of that content before building this doc. 
Something is broken. I'll fix it when I cut the version that pulls
out the "changes since" section.

I failed to respond to the following two points on list. This was not
intentional, and I apologize.

> just seems that you can't make it stronger than a SHOULD. 

This situation for this clause is different from the preceding MAYs.

Here, you _know_ you've got something invalid, where the two earlier
paragraphs deal with the case that you have data that you have no
indication of its integrity one way or another.

If the token is invalid, something's gone wrong and it will be
sufficiently hard to tell whether that's due to attack or implementation
error, that the action needs to be to return an error.

Diving into this just a little more deeply:

Well, you've got two classes of possible "invalidity".

1) The signature is not valid. Here, you have now way to know what
   got mucked with. No way to know if the failure is related to an
   optional parameter or something important. Clearly, this condition 
   warrants only rejection.

2) The signature is valid, but the contents of the token don't
   match the request. You or I might be able to inspect the message
   and make an educated decision about the safety of accepting
   the request. Ordinary people won't have that skill. (Ordinary
   devices currently aren't making it easy for me to get the
   information I would need to make that educated decision anyhow).
   So, again, rejection is warranted.

> been sent securely, not mucked with by the proxies, etc.). 

There is a lot of information present than just the Request-URI that
can be validated. The method, requested end-to-end headers, etc.