RE: [Trigtran] TRIGTRAN Justification

Hi, Yogesh,

I have some notes (inline) - thanks for your helpful thoughts...

Spencer

> -----Original Message-----
> From: Yogesh.Swami@nokia.com [mailto:Yogesh.Swami@nokia.com]
> Sent: Wednesday, January 15, 2003 1:41 PM
> To: carlw@mcsr-labs.org; Spencer Dawkins; trigtran@ietf.org
> Subject: RE: [Trigtran] TRIGTRAN Justification
> 
> 
> Hi,
> 
> I have a couple of questions/comments based on these E-mails
> (these issues might have already been addressed, but I was unable
> to access the link that Spencer provided; can someone point me to
> the right link?). Here are my questions/comments:
> 
> --  Is TRIGTRAN only considering TCP, or can other transport
> protocols such as RTP over UDP, or raw UDP with TFRC, also make use of
> it?

As one data point - I've been asked by one streaming media vendor (hint, hint) for help with mobiles that can't sent RTCP messages when they're not reachable (there's nothing that tells the RTP sender that this is happening).

I can't tell you that TRIGTRAN needs to take this on, or that this is a solvable problem. I'm just passing the request through to the mailing list.

> 
> --  If it's supposed to help other protocols like RTP over UDP, or
> UDP using TFRC for rate control, then we need to keep in mind that
> unlike TCP, RTP does not have a protocol field in the IP
> header. This means that given a stream of UDP packets, one cannot
> *reliably* say if these packets belong to a RTP session, of if
> they belong to some other protocol on top of UDP which just
> happens to have the same format (It's good to be a little paranoid
> while designing a new protocol, so don't bite off my head if you
> think that the probability of such collisions are small) This also
> means that TRINGTRAN routers cannot be stateful (i.e., one cannot
> estimate RTT etc for a "flow"--whatever that means).
> 
> The framework should indicate such issues, or advise against using
> TRIGTRAN for UDP applications...
> 
> --  If it's supposed to work only for TCP then it will be useful
> to consider how it will work in the presence of IPSec tunnels. Of
> course we can just say that it will not work with IPSec, but that
> doesn't sound right (to me). Shouldn't IETF protocols work in the
> presence of all the other IETF protocols.

Yes, we definitely need to think about tunnels.

My immediate take is that, I don't know why TRIGTRAN shouldn't work, although a Transport IPSEC security gateway would have to relay the trigger (but it knows the relationship between the interior destination IP address and the tunnel, so this seems possible). But let's keep the question open, for now.

> 
> --  Since TRIGTRAN is only advisory, it should not have signals
> for which the transport layer does not have an in band counter
> part. For example, handoff has no in band counterpart for TCP/UDP
> and therefore such signals should not be present (but if they are
> present then it SHOULD be ignored by the transport)

You know... I'm hoping it doesn't work this way, because the problem we're dealing with, for TCP, is that there's only one defined inband signal (ACK clocking, or the lack thereof). But we're keeping explicit error notification on the "high-hanging fruit" list, so we certainly haven't demonstrated a need for lots of new signals yet.

> 
> --  Also, for DoS attacks, TRIGTRANS should not only protect the
> transport protocol, but it must protect itself, too. (This is
> obvious, but it's probably useful to point it out explicitly.)
> From the age-old example, one needs to consider how to handle IPv4
> fragmentation; how to respond to multiple anomalies etc so that
> the network is not flooded with TRIGTRAN messages..., etc.

I think "what to do when you receive the SECOND TRIGTRAN message" has to be defined as part of any response mechanism. Good input.

> 
> Thanks in advance for your response.
> 
> Thanks
> Best Regards
> Yogesh
_______________________________________________
Trigtran mailing list
Trigtran@ietf.org
https://www1.ietf.org/mailman/listinfo/trigtran