Subject: Re: [Idr] Next revision of AS_HOPCOUNT

From: [email-masked]
Date: Thu, 12 Jan 2006 18:20:34 -0500 (EST)

>Please see section 5.2.  We clearly state that AS_HOPCOUNT may
>be used in a proxy fashion.

Should the text I quoted from elsewhere in the document be
modified to be consistent?

>I believe that it's a rush to the other side of the spectrum to say that
>no integrity security is needed.  There are a number of mutable
>attributes necessary for fully functioning BGP (e.g., AS_PATH,
>communities).  Hopefully whatever solution RPSEC selects to
>protect these attributes will also be useable for AS_HOPCOUNT or
>AS_PATHLIMIT.

The AS_PATH is mutable, but the decision of what mutations are
permitted is one of the stumbling blocks in determining a solution.

If you go by the "MUST/MUST NOT" in the bgp spec, you come up with
one idea of what is permitted.  If you go by the what vendors
allow you to configure your routers to do, you come
up with a much different idea of what is permitted.

But whichever modification rule for AS_PATH you follow, there
may not be sufficient match to the semantics of the HOPCOUNT/PATHLIMIT
to make the security protections for AS_PATH also protect the
HOPCOUNT/PATHLIMIT.

You imply you think that there is integrity required.  But the
conclusion I've reached from other email is that people want any
AS to be allowed to strip, replace, or modify the HOPCOUNT/PATHLIMIT.
What sort of integrity do you see that would still allow that?
(Question, not dig.  Really - what integrity requirement do you see?
Limitation on who could strip/replacy/modify?)

--Sandy

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Tony Li <[email-masked]>
Date: Thu, 12 Jan 2006 16:04:41 -0800

Sandy,

> modified to be consistent?

Please see the revised version when I am permitted to post it.  If you
have comments on that version, then we should discuss them.

> to make the security protections for AS_PATH also protect the

That is true.  However, as there are no proposed mechanisms for
AS_PATH, I don't see much point in arguing about whether the
not-yet-proposed semantics are sufficient or not.

> Limitation on who could strip/replacy/modify?)

Well, as I tried to point out, I think that you're leaping to all  
sorts of
conclusions, mostly unwarranted.  With regard to AS_PATHLIMIT,
I would like to see several properties.  For one example, if an
AS attaches AS_PATHLIMIT, I would like to know that the AS number
that it attaches is its AS number and no other.

There are a number of other security properties that I would like to  
see,
but again, they are general properties that should be applicable to all
BGP path attributes, not just AS_PATHLIMIT.  As such, I would prefer
to discuss them as part of RPSEC.

Tony

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 13 Jan 2006 09:33:10 -0500

> What sort of integrity do you see that would still allow that?

I may be misusing security taxonomy, but I think the property we'd
be interested in for this case is accountability.  Knowing who
made the change is often a good start to take some form of action
when someone acts contrary to your expectations.

-- 
Jeff Haas 
NextHop Technologies

---

From: John Leslie <[email-masked]>
Date: Fri, 13 Jan 2006 13:04:56 -0500

> have comments on that version, then we should discuss them.

   Will somebody please own up to telling Tony he may not publish the
revised draft to the list?

   This is taking on a Kafka-esque feeling that we're expected to
agree we have consensus on something before we're allowed to find
out what it is we're consenting to.

--
John Leslie <[email-masked]>

---

From: Tony Li <[email-masked]>
Date: Fri, 13 Jan 2006 10:42:01 -0800

> revised draft to the list?

This was the directive of our esteemed chairs.  Apparently this is now
the modus operandi of the IETF when one wants to re-architect
a draft.

> out what it is we're consenting to.

I wholeheartedly agree.  Furthermore, I'm trying to play by the rules
as stated, which for those that know me, adds to the surreal
tableau.

;-)

Tony