On Tue, Jul 12, 2005 at 04:06:25PM -0700, Alex Zinin wrote:
> Dave, folks-
> Using my own message to "distill" comments as promised.
> I will also send separate messages on a couple of topics.
> See inline below, please. Opinions welcome.
> Friday, May 20, 2005, 9:34:10 AM, Alex Zinin wrote:
> > Dave, et al-
> > I've reviewed the draft with the "PS spec" glasses on and have several
> > proposed changes.
> > Here's the summary:
> > 1. Spelled out the assumptions about receive-path filtering capabilities
> > and resource separation in the routers.
> I would like to drop my suggested text about managing the filtering
> database. How exactly GTSM packet category is identified is not important.
> Dave, please feel free to use the rest of proposed text for section 2.3,
> i.e., about resource separation, etc. if you feel this will improve the
> > 2. More detailed explanation of the received packet processing, including
> > packet classification
> Pekka had a comment on TrustRadius--that he would vote for getting rid of
> it all together. It would probably make sense if we didn't have the
> multi-hop option in the doc. As long as we have and describe it, it seems
> that the TrustRadius concept gives a nice generalization for receive-side
> packet processing. I would like to hear what people think on this.
> Regarding the rest of my comments: I think the doc would benefit from
> clearly specifying:
> - steps added to IP pkt sending and receiving procedures
> - packet classification that GTSM yields
> - default GTSM policy settings
> If I wanted to minimize my original proposed text to what's essential, I
> would probably go with the following:
> If GTSM is enabled for a protocol session, the following steps are added
> to the IP packet sending and reception procedures:
> Sending protocol packets:
> The TTL field in all IP packets used for transmission of messages
> associated with GTSM-enabled protocol sessions MUST be set to 255.
> // add words on ttl and the forwarding engine based on Alia's comment
> Receiving protocol packets:
> The GTSM packet identification step associates each received packet
> addressed to the router's control plane with one of the following
> three trustworthiness categories:
> - Unknown: these are packets that cannot be associated with any
> registered GTSM-enabled session, and hence GTSM cannot make any
> judgement on the level of risk associated with them.
> - Trusted: these are packets that have been identified as belonging
> to one of the GTSM-enabled sessions, and their TTL values are
> within the expected range.
> - Dangerous: these are packets that have been identified as belonging
> to one of the GTSM-enabled sessions, but their TTL values are NOT
> within the expected range, and hence GTSM believes there is a risk
> that the packets have been spoofed.
> The exact policies applied to packets of different classifications are not
> postulated in this document and are expected to be configurable.
> However, by default, the implementations:
> o SHOULD ensure that packets classified as Dangerous do not compete for
> resources with packets classified as Trusted or Unknown.
> o MUST NOT drop (as part of GTSM processing) packets classified as
> Trusted or Unknown.
> o MAY drop packets classified as Dangerous.
> If GTSM is applied to a protocol session that is expected to always run
> between directly connected peers, the value of TrustRadius SHOULD be set to
> zero, thus limiting the TTL range to a single value of 255.
> The value of TrustRadius for non-direct protocol sessions is not specified
> in this document and SHOULD be configurable.
> > 3. Added IP fragment processing
> I will send a separate message on this
> > 4. Added handling sessions with parameters not known a priori
> Is this useful? Please comment.
> > I'd like to encourage people to read through the text below and see if
> > there are any objections on what the document say MUST, SHOULD, or MAY
> > be done.
Thanks Alex. I'll look it over.
Regarding TrustRadius: I have never been a big propoent
of the TrustRadius stuff, simply because the coverage
provided by GTSM is greatly diminished for TrustRadius > 0.
OTOH, TrustRadius does provide a potentally useful
generalization for receive side processing (as you
mention). Do others have comments on this?
Rtgwg mailing list