[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: David Meyer
Date: Tue, 12 Jul 2005 16:16:47 -0700
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
> doc.
> >  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
[email protected]
<Prev in Thread] Current Thread [Next in Thread>