Subject: Re: IRIP version 4 (Part 2)

From: [email-masked]
Date: Mon, 15 Mar 1999 20:09:29 GMT

Continued from section 3.2 Fanout and Queued Transactions

Under 3.1.9 SWITCH:

  There are a few references to the "greeting message" but there is no
clear description of it or its format.  Is it like IMAP or POP3 or just a
reply code or some arbitrary text sequence??

Under 3.2 Fanout and Queued Transactions:

>A trusted relationship between two IRIP servers means that one server
>can queue transactions for the other server and deliver them some time
>later. If IRIP server B trusts A, then A can queue requests for B. If A
>does not trust B then B cannot accumulate requests for A.

Why cant there be a queue between non-trusted hosts?  This happens for
stuff like SMTP mail so what is wrong w/it here?  Affraid for data
integrity?  Some other motiviation?

>In IRIP the reply code to the RECIPIENT
>command indicates whether or not a reply will be made in real-time.
>This allows the sender to abort the request if necessary.

Upon further reflection I dont think this is 100% guaranteed.  For example,
Server A establishes a link to Server B to do fan out and reflects this in
its RECIPIENT reply code.  The sender then begins to send ICALDATA.  In the
mean time, Server B goes down (or the link to it is lost, etc).  There is
now no way that Server A can return a real-time reply apart from saying
"Sorry but Ive had to queue this up for Server B".

Under 3.3 Bi-Directional Queue Operation:

Another example of why 2 servers may not be able to immediately establish a
session is that the admin has configured some policy to prevent this.  For
example, in some European countries a modem connection may be long distance
and they want to restrict these kinds of connections to being at night
only.  As a result, the requests get queued until evening before being pass
along; there may be no intermediate 3rd host.

>The firewall in
>front of B.foo.com prevents external connection on the IRIP server
>port. Similarly, the firewall in front of D.bar.com also prevents
>connections on the IRIP server port.

Be sure to clarify that the firewalls are prohibiting INBOUND iRIP
connections, not OUTBOUND.  Otherwise you would need to be using some
protocol proxy as well (ala SOCKS).

>A trust
>relationship between the intermediate IRIP server and the endpoint
>servers (B.foo.com and D.bar.com) is desirable but not required.

This conflicts w/your original assertion above that I already challenged...

Hmm, just what would prevent server katt.pcweek.com from authenticating to
the server C.foobar.com and then doing DEQUEUE irip://B.foo.com/... and
sucking down data that it should not have access to?  There seems to be no
restriction or control over what CALID a sender can DEQUEUE to in the
queueing model.  Am I missing something or did noone else notice this?

Under 3.4 Reply Codes:

>In addition to those defined in [ITIP], [IRIP] defines the following
>error codes:
[Snip]
>2.0    STATOK                  Operation was successfully performed.

Actually, isn't 2.0 already defined in iTIP?  (Its not new to iRIP.)

>2.0.4 WILL-ATTEMPT             The specified Calendar is not here
>                               but An attempt will be made to deliver
>                               the request or reply to the Calendar
>                               anyway. There is a trust relationship
>                               between this IRIP server and the
>                               IRIP server for the target calendar.
>2.0.5  TRUSTED-WILL-QUEUE      The specified Calendar cannot be
>                               contacted directly and a trust
>                               relationship exists between this server
>                               and the server on which the Calendar
>                               exists. The request or reply will be
>                               queued and delivered to the target
>                               calendar when its IRIP server contacts
>                               this server and issues the SWITCH
>                               command.
>2.0.6  WILL-ATTEMPT            The specified Calendar is not here
>                               but an attempt will be made to deliver
>                               the request or reply to the Calendar
>                               anyway. The

The meaning of 2.0.4 and 2.0.6 are the same.  Looks like some oversight in
the editing process or merging of some comments.

The descriptions for these  reply codes explicitly indicates that there is
a trust relationship or not w/the remote host.  Does this need to really be
done?  If so, then we need to have some 'non-trusted' equivalents!

There appears to be some missing text for the last part of 2.0.6; the
dangling The.

>8.3    DATE TOO LARGE          A DATETIME value was too large to be
>                               represented on this Calendar.

Make this more generic to be more like "Date out of Bounds" to indicate
that a DATETIME value was before the MINDATE of the server or after its
MAXDATE (since these are now required capabilities).  ("Too large" implies
> MAXDATE or you are a Un*x programmer).  You could then merge it with 8.4
which has a better description.

There is no 10.3 reply code but there is a 10.4 and 10.5.  What happened to
is?  If its gone, move 10.5 down to be 10.3, otherwise add it back into the
table.

I dont have iCal handy to refer to it but does:
>10.1   REFERRAL                Accompanied by an alternate address.
really belong in the 10.x class of reply code?  Isnt it more appropo to be
in the "FYI" category rather than a "Severe error" category (ala 10.4 Quota
exceeded)?

Under 5.1 Spoofing:

>The [ITIP] paradigm allows any modifications to data by its Organizer,
>which maps to the [SASL] authorization identity.

I must have missed this discussion on how my SASL authId got mapped to an
iTIP property.  Can somone point me to where this is discussed.

>This means that
>authorizing with appropriate identities over [IRIP] will allow read and
>write access to any item in the Receiver's database.

Id say that the "will allow" is really "may allow"; subject to some
policies or other ACL mechanism.  If an authId is not the Organizer, they
should not have any access to some other Organziers entries.

>The choice of accepted authentication mechanisms can reduce the
>security risk. The ANONYMOUS mechanism allows a greater level of
>interoperability, in that any Sender can connect anonymously, but
>greatly increases the security risk for the same reason.

It makes sense to expressly preclude _any_ anonymous user (if permitted
into an iRIP server) from doing any modifications to existing entries.  I
cannot think of any scenario where Id want to let any anonymous user to be
able to drop stuff onto my calendar but maybe others can.  The only action
I can think of that I may actually like to permit would be busytime
lookups...  Should tightening the noose around what an anonymous user can
do be part of iRIP?  Ill defer to Bob or Paul on the security aspects of
that...

Under 5.3 Connection Flooding

>Servers should be configurable to timeout unused connections.

Since you raised the issue, just when is an iRIP connection considered
"unused" and timed out?  Is there such a critter as an idle iRIP connection
that an iRIP server can close down?  Is there any way for an iRIP client to
keep a connection alive w/o doing actual commands like RECEIVE and then
ABORT?

Under 6.3 Fanout Requests:

  It would be helpful to readers to see a 'failure' case as well.  How
about an example of failing for some reason (ie: over quota, etc).

Under 6.3.2 Referral On Fanout:

  The text in the draft said that for referrals and some other error cases
no ICALDATA would be handled for the failed RECIPIENT.  Given that, why
does the sender S need to ABORT the sequence when it gets the "10.1
irip://E.xyz.com/david99"? It should consider it an automatic failure and
just issue a new RECIPIENT w/the referral address.  Or did I miss a reason
for having to ABORT and restart this all??  (This was done in a later
example).

In the example under 6.4.1 the text says:
>This request will
>be delivered the next time the IRIP server on D.bar.com connects to the
>IRIP server on B.foo.com and issues a SWITCH command.

Now Im curious how the iRIP server D.bar.com will know to retrieve
(DEQUEUE) requests for irip://D.bar.com/david unless it polls for all
calendars on B.foo.com or the authID used on the SWITCH is that of
irip://D.bar.com/david.  Just how does D handle DEQUEUEing for several
calendars on it from B??

Ive sent editorials OOB but I think we have some stuff to chew on for now.

Bruce

---

From: [email-masked] (Steve Mansour)
Date: Thu, 25 Mar 1999 08:44:12 -0800

comments, continued

> iTIP property.  Can somone point me to where this is discussed.

Yea, Paul's gonna write that up. He's got a big write-up on that. He's gonna
answer all your questions. Piece of cake, real simple too  :-)

This is the authorization concern I referred to in the first part of my reply
to this message, and I brought this up at the ietf meeting.  We don't know how
you map information between authentication credentials (like a digital
certificate we referred to in iMIP :-) and a calendar address. We had not even
begun to try making a link between users and calendars until CAP. It is
becoming clear that we may have to address this in a real-time protocol like
iRIP as well. Paul has some ideas on how we might want to attack this problem.

Still waiting to see those ideas Paul :-)

> do be part of iRIP?  Ill defer to Bob or Paul on the security aspects of

You should be able to inhibit this sort of behavior, but do you *really* want
to preclude it? You believe there are no circumstances, anywhere, ever, that
would require anonymous access to write iRIP requests to a calendar?

I don't like spam mail, but I would fight to keep e-mail inboxes publicly
writable.

> "unused" and timed out?

We haven't actually set a time. I guess I had assumed it would be configurable.
We might want to suggest one.

How's this for a first guess:  Any iRIP connection that has seen no activity
for 30 seconds should be dropped.

> Is there such a critter as an idle iRIP connection

I suppose they could issue a CAPABILITY command. We should probably add a NOOP
command, eh? That's what we've proposed for CAP.

> about an example of failing for some reason (ie: over quota, etc).

Agreed. I'll add one.

> irip://E.xyz.com/david99"?

it does not need to. It can continue if it wants.

> It should consider it an automatic failure and

It aborted because the sender wanted to abort.  It was just meant to show how
an abort might occur.  Based on your comments, I can see how people would
interpret that example as though there were other reasons for aborting. I'll
change the example.

> irip://D.bar.com/david.  Just how does D handle DEQUEUEing for several

I'm very confused by your question. There is no DEQUEUE going on at all.
iRIP://B.foo.com/ contacted irip://D.bar.com/ and sent the message directly to
irip://D.bar.com/david .  No queuing was done at all.

> Ive sent editorials OOB but I think we have some stuff to chew on for now.

Thanks, as always, for reviewing this draft so closely.  Your questions and
comments are a big help!

-Steve

---

From: Bob Mahoney <[email-masked]>
Date: Thu, 25 Mar 1999 12:05:17 -0500

I don't know if any of you picked up a copy of "Internet Protocol 
Journal" at the Minneapolis meeting, but it contained an excellent 
overview of secure e-mail, S/MIME, and PGP.  As we start in on some 
of these discussions, people might find this a really useful article.

It's available on the net as a .pdf file.  Go to:

http://www.cisco.com/warp/public/759/ipj_2-1.pdf

The article is:

Secure E-Mail: Problems, Standards, and Prospects
by Marshall T. Rose and David Strom

Enjoy...

-Bob

---

From: John Stracke <[email-masked]>
Date: Mon, 29 Mar 1999 19:25:56 +0000

Steve Mansour wrote:

> [...]

I don't think a protocol spec should require (or recommend) timeouts.  It should
have a mechanism for the server (or the client) to use to perform a timeout
gracefully (and to find out whether the other end intends to use that mechanism),
but it should be silent on when to use it.  That's too much of an
implementation/policy decision.

> command, eh? That's what we've proposed for CAP.

This is getting into the usual keepalives issue, which comes up in lots of
protocols.  Short summary: A argues that they need to be able to close idle
connections for efficiency; B insists on the ability to keep the connection open
if it's Not Really Idle; C points out that the keepalives start destroying the
efficiency; WG dissolves into chaos.

The classic case is TCP, where you *can* turn on keepalives, but they consume
bandwidth and CPU time, and can actually wind up killing the connection needlessly
(if the network flakes out, the keepalives don't get through, and the connection
gets dropped; without the keepalives, the connection might have survived until the
network came back).

I would suggest that we have the mechanism for dropping idle connections, but
servers SHOULD NOT use it on a strict timer basis; for example, a server which is
not having load problems should not be dropping connections.  Given this, there's
no good justification for a client to use keepalives (since they'll be dropped
only if it's realio-trulio necessary), so we should leave them out.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: [email-masked] (Steve Mansour)
Date: Mon, 29 Mar 1999 11:42:15 -0800

> only if it's realio-trulio necessary), so we should leave them out.

Can you suggest what this mechanism would be?  How it might work?

-Steve

---

From: John Stracke <[email-masked]>
Date: Mon, 29 Mar 1999 19:49:36 +0000

Steve Mansour wrote:

> John Stracke wrote:
>
> > I would suggest that we have the mechanism for dropping idle connections,
>

Something simple--say, a "dropping idle connection" message from the server, followed
by a close of the TCP connection.

---

From: John Stracke <[email-masked]>
Date: Mon, 29 Mar 1999 20:32:52 +0000

Steve Mansour wrote:

> By "dropping idle connection" message, I take it you mean an unsolicited reply code.

Yes.

---

From: [email-masked] (Steve Mansour)
Date: Mon, 29 Mar 1999 12:27:59 -0800

> by a close of the TCP connection.

By "dropping idle connection" message, I take it you mean an unsolicited reply code. For
example, if 2.99 was the reply code for "dropping idle connection", it would go like
this?

R:  2.99
R: <drops the tcp connection>

-Steve