[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: Pekka Savola
Date: Tue, 24 May 2005 09:15:29 +0300 EEST
On Fri, 20 May 2005, Alex Zinin wrote:
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.

2. More detailed explanation of the received packet processing, including
   packet classification

3. Added IP fragment processing

4. Added handling sessions with parameters not known a priori

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.
I don't have objections to the proposed text (and I do think it makes
sense to push GTSM on standards track soon because the spec clarifies
a number of things and is very useful), but I have a couple of
observations:
 1) in 3.3, I don't think you can say "[the less specific entries] are
replaced with a more speficic entry". I think you mean in 2.3 that
when a session is torn down, the more specific entry needs to be
replaced again with less specific entries. I mean, how do you deal
with a spurious TCP session reset? These GTSM filtering engine has to
be robust enough to allow establishing a new session after the BGP
session is torn down and is being brought up again, using different
ports.
IMHO, creating the more specific entries is against the spirit of
original GTSM -- the whole point was that if you're directly
connected, you're "semi-trusted". I as an operator don't care all
that much about the port sweep threat in that case. I'd suggest
moving the "more specific filter installation" case over to an
appendix with a couple of health warnings.
At the very least, if there is consensus to keep it as is, there
should be equal amount of specification what needs to be done when
sessions fail than as when sessions are created. Further, there are
cases where one end of the session thinks the session is down, and the
other thinks it's still up -- these rules make failover more difficult
in this case.
 2) it strikes me when you describe the filtering rules that equal
kind of filtering (just without the TTL) is applicable for the
non-GTSM sessions as well, to counter the threat of an attack using
Unknown state. But I'm not sure if this spec is the right place to
stay that, maybe in an appendix..
 3) In section 3, you talk about ECMP etc. -- to me that's a pretty
non-interesting part. do people really want to run GTSM between
sessions which aren't directly connected? It doesn't seem like an
appropriate mechanism for there. The security ADs are likely going to
want to see a clearer applicability statement here. I wouldn't be sad
to see the whole TrustRadius thing eliminated or moved to appendix.
But I assume this is a moot argument.
 ...

A couple of nits:
- Security people may flinch at the use of "Trusted" classification. If another suitable name could be used, great. If not, we'll see later if this is a problem.
 - Instead of addresses in 10/8, please use 192.0.2.0/24.

--
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Rtgwg mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rtgwg

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