[email protected]
[Top] [All Lists]

Re: Comments on draft-ietf-rtgwg-rfc3682bis-05.txt

Subject: Re: Comments on draft-ietf-rtgwg-rfc3682bis-05.txt
From: Alex Zinin
Date: Tue, 12 Jul 2005 16:06:25 -0700
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.


Rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>