Subject: Re: moving on with issue 47 (routing vs. advertisement rights)

From: <[email-masked]>
Date: Wed, 14 Jan 2004 15:33:16 +0200

Hi Hesham,

I agree with what you say. I think your comments
also point to the direction that I'm proposing we
take, i.e., SEND ensures that certs and advertisements
agree, but that the rest of the problem is dealt
with separately.

--Jari

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Soliman Hesham <[email-masked]>
Date: Wed, 14 Jan 2004 08:35:16 -0500

Hi Jari, 

Yes. I just wanted to see if we can solve this
general problem somewhere. Perhaps this should be 
brought up beyond this WG. 

Hesham

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]]
 > Sent: Wednesday, January 14, 2004 8:33 AM
 > To: [email-masked]
 > Cc: [email-masked]
 > Subject: Re: moving on with issue 47 (routing vs. 
 > advertisement rights)
 > 
 > 
 > 
 > Hi Hesham,
 > 
****************************************************************************
*******************************************
This email may contain confidential and privileged material for the sole use
of the intended recipient.
Any review or distribution by others is strictly prohibited.  If you are not
the intended recipient please
contact the sender and delete all copies.
****************************************************************************
*******************************************

---

From: Gregory Daley <[email-masked]>
Date: Sat, 24 Jan 2004 23:11:21 +1100

Hi, 

Thanks Jari for getting to the deeper meat
of the issue.

The proposed text is sufficient.

Greg.

----- Original Message -----
From: James Kempf <[email-masked]>
Date: Saturday, January 24, 2004 3:33 am
Subject: Re: moving on with issue 47 (routing vs. advertisement rights)

> Looks fine to me. Greg, what do you think?
> 
>            jak
> 
> ----- Original Message ----- 
> From: "Jari Arkko" <[email-masked]>
> To: <[email-masked]>
> Cc: "James Kempf" <[email-masked]>; "Pekka Nikander"
> <[email-masked]>; "Greg Daley" 
> <[email-masked]>Sent: Thursday, January 22, 2004 
> 11:38 PM
> Subject: Re: moving on with issue 47 (routing vs. advertisement 
> rights)
> 
> >
> > So the currently proposed resolution is to warn the reader
> > about the use of 0/0 in certs that are used also by other
> > applications than SEND. This appears right, but I wonder
> > if it is the whole solution.
> >
> > Let me explain. We started this thread from the semantics
> > of the certificate extensions, and what SEND protocol
> > precisely does with a given prefix. Greg brought up the
> > issue of what happens if 0/0 is included for SEND purposes
> > and the same certificate is used in BGP, even if the router
> > in question is not supposed to advertise a default route.
> > The current text proposal fixes this issue, but I wonder
> > if there's another, more general problem behind the 0/0
> > case.
> >
> > For SEND, it is required that the advertised prefixes
> > are a subset of certified prefixes: Padv <= Pcert. The
> > sets need not be equal, but any "slack" Pcert-Padv creates
> > an opportunity for the routers to advertise prefixes
> > that they are really not authorized to advertise. 0/0 is
> > the extreme case of such slack. Similar rules apply to
> > other applications such as secure BGP. However, there
> > is no guarantee that the rules are exactly similar. For
> > instance, I can imagine an application where certificates
> > are used as the sole means of carrying prefix information;
> > in that case the certificates would have to contain exactly
> > the right information.
> >
> > Why are the requirements different in different applications?
> > One reason is the protocol mechanisms, such as whether
> > the certificates are or are not used as the sole means of
> > conveying the given information. Another reason is that
> > the security impacts are different. In SEND, a certificate
> > that gives too many rights leads only to a local problem in
> > the area of the ill behaving router. In BGP, one ill behaving
> > router could potentially make the whole network route incorrectly.
> >
> > In any case, I think there is a potential problem in the
> > different requirements that the applications set, even outside
> > 0/0. Basically, if the same certificate is used for different
> > applications, one needs to ensure that the prefix contents
> > are appropriate for all of them. As an example, if my router
> > has only IPv4 connectivity to the Internet and tunnels IPv6 over
> > it, it might be that the BGP certificates should contain only IPv4
> > prefixes while the SEND certificates should contain the tunneled
> > IPv6 prefixes.
> >
> > In conclusion, I would like to make the warning text a bit
> > more general than just about 0/0.
> >
> > Here's the proposal:
> >
> > Care should be taken if the certificates used in SEND are re-used
> > to provide authorization in other circumstances, for example
> > with routing gateway protocols. It is necessary to ensure that the
> > authorization information is appropriate for all applications. SEND
> > certificates may authorize a larger set of prefixes than the router
> > is really authorized to advertise on a given interface. For 
> instance,> SEND allows the use of the null prefix. This prefix 
> might cause
> verification
> > or routing problems in other applications. It is RECOMMENDED that 
> SEND> certificates containing the null prefix are only used for SEND.
> >
> > --Jari
> >
> >
> 
>