Subject: Re: [Idr] Next revision of AS_HOPCOUNT

From: [email-masked]
Date: Wed, 11 Jan 2006 10:52:47 -0500 (EST)

Another aspect of decrementing hop count vs "absolute" path length.

If one uses a decrementing hop count and there is a security
mechanism in place that tries provides protections that would
allow ASes many hops away to verify the integrity of what
you sent (i.e., the portion of what they receive that is
what you sent), then the hop count would have to be excluded
from that protection.  It would be legitimately changing,
so you could not protect its integrity.

That probably would leave open opportunities for bad/stupid/broken
guys to modify the field inappropriately, with ill effect.

(Like the TTL field in IP is not covered by IPSEC because it
changes at each hop.)

If one had an static absolute path length, its integrity could be
protected over many hops.

--Sandy

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

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Jan 2006 11:33:16 -0500

> guys to modify the field inappropriately, with ill effect.

The other main mechanism which restricts route propagation (the  
NO_EXPORT community string attribute) is trivial to strip from  
routes, overriding the intentions of the previous AS in the path. In  
general, surely every AS has a legitimate case for modifying the  
attributes on prefixes to suit its own needs.

What kind of modification would you consider inappropriate?

> protected over many hops.

I would expect any AS to be able to remove an AS_PATHLIMIT attribute  
if that suited their local policy, substituting a new one if desired.  
In that context, I'm not sure what integrity there is to preserve?

Joe

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 11 Jan 2006 11:40:10 -0500

> attributes on prefixes to suit its own needs.

Some might argue the appropriateness of stripping the current
well known communities as potential security issues.  At best, you're
outright ignoring your peer's requirements to not propagate things.
However, rpsec might be a better place for this particular operational
discussion.

> In that context, I'm not sure what integrity there is to preserve?

One component would simply be ensuring that someone doesn't put 
someone else's AS number in the hoplimit field.  The mechanism
by which your ensure that integrity is probably better discussed in
rpsec.

(However, I'll agree with Sandy that this makes things "easier" for
some of the things we've discussed on rpsec.)

The behavior of mis-setting values in this field are already
discussed with Tony's usual wit in the security considerations of
the draft. :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Jan 2006 12:04:45 -0500

On 11-Jan-2006, at 11:40, Jeffrey Haas wrote:

> well known communities as potential security issues.

True; however, many operators might also argue that their ability to  
impose their own policy on the routes they choose to accept and  
propagate is more important.

> At best, you're

Perhaps it's more realistic to call them "requests" rather then  
"requirements".

> However, rpsec might be a better place for this particular operational

Agreed; apologies for the tangent.

Joe

---

From: Danny McPherson <[email-masked]>
Date: Wed, 11 Jan 2006 10:26:44 -0700

On Jan 11, 2006, at 10:04 AM, Joe Abley wrote:
>
> True; however, many operators might also argue that their ability  
> to impose their own policy on the routes they choose to accept and  

Absolutely.

I suspect many operators (I know of several first hand) that reset all
community values received from eBGP peers and MAY reapply well-
known communities on ingress, but avoid carrying any additional
communities that have no meaning within their routing domain (e.g.,
to avoid effects on update packing, etc..).

-danny