[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Trigtran BOF



>>However, I also think that they need to come up with a security advisor. 
>
>Well, if the WG-to-be were to stick with a full investigation of
>the implicit "link up" trigger of transmitting or retransmitting a
>data packet after link up, and of doing to work to ensure that
>transport protocols understood this as a link-up trigger, then a
>security advisor might not be needed.

I actually think there are possible security issues with implicit
link-up.  Implicit link-up essentuially means the router hangs on to a
packet from each flow (however it identifies flows) that arrives after
the link goes down, and re-forwards it after the link comes back up.
The question here is that if such a packet arrives after some delay,
will any transport protocol get confused?  In theory, transport
protocols should be robust so long as the packet isn't stored longer
than the maximum segment lifetime, but it would be possible for
multiple such links each to store the packet for a while, so the
packet could then arrive *really* late.  This seems iffy to me.

I'd think I'd prefer the signal to be more explicit.  For example,
ICMP-encapsulating the delayed packet would allow the receiver to
opt-in to playing this game, so the trigtran-router wouldn't need to
be smart about which transport protocols to store packets for and
which not to.  And later routers would know not to hold on to such a
packet.

 - Mark