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

From: Gregory Daley <[email-masked]>
Date: Wed, 21 Jan 2004 23:17:47 +1100

Hi Pekka and James,

----- Original Message -----
From: Pekka Nikander <[email-masked]>
Date: Wednesday, January 21, 2004 6:43 pm
Subject: Re: moving on with issue 47 (routing vs. advertisement rights)

> >>> I don't like this.  I'm afraid that this would allow "wrong" type
> >>> of certificates to be used for SEND.  Maybe not a major security
> >>> issue, but anyway something that should be avoided.
> >>>
> >>> Given that, I can live with the MAY you proposed provided that
> >>> there is a cross reference to the security consideration 
> section at
> >>> the spot and good explanation of the problem in the sec cons.
> >>>
> >>> But I still would prefer 0/0.  My interpretation of the current
> >>> text is that the semantics are clear, and I didn't quite 
> understand>>> how Greg found them confusing (sorry Greg).  But I 
> haven't been
> >>> able to follow too closely.
> >>
> >> Ok.
> >>
> >> What about if we say that a router MAY use a certificate with an
> >> address range extension 0/0 only if router is not part of a domain
> >> with certified delegation from IANA? Otherwise, the address range
> >> extension MUST NOT have value 0/0.
> 
> I'd prefer a SHOULD NOT.  I do see valid operational reasons for 0/0.
> 
> If a site does have a certified delegation from IANA, that delegation
> basically limits the address range.  Quoting the draft:
> 
> >    If an addressPrefix or addressRange is not contained within the
> >    delegating authority's prefixes or ranges, the client MAY 
> attempt to
> >    take an intersection of the ranges/prefixes, and use that
> >    intersection.  If the addressPrefix in the certificate is the 
> null>    prefix, 0/0, such an intersection SHOULD be used.  (In 
> that case the
> >    intersection is the parent prefix or range.)
> 
> In other words, a 0/0 certificate with a parent certificate basically
> means that the address range from the parent certificate is used.
> 
> I admit that the text may be confusing and hard to read for anyone
> that haven't happened to read anything about the tag intersections
> in SPKI (on which the text is based), and probably should be reworded.
> 
> Unfortunately I don't have cycles right now to suggest rewording.

Fair enough.

I'll try to work out if there's _really_ an issue 
as opposed to if there may be an issue.

> >> This means that the router is
> >> advertising a default route (which would typically be ok for a
> >> border router) but it will not propagate outside the domain.
> >
> > Sorry, I meant "would be ok for an access router" not a border 
> router. 
> > An
> > access router typically provides default routes for nodes on its 
> > subnet.
> 
> I didn't understand this part.

I'll get back to you with a problem breakdown,
which should clear up the issue (or whether there
is one).

Greg

--------------------------------------------------------------------
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: "James Kempf" <[email-masked]>
Date: Wed, 21 Jan 2004 09:03:09 -0800

Hi Greg,

Since you raised the issue about the wording in draft 02, it would be
helpful if you could suggest some text to resolve it. We would like to send
the draft to WG Last Call and to the review board as soon as possible, so it
would be most helpful if you could post something to the list in the next
couple days.

I think we are otherwise in agreement on basic technical points.

Thanx.

            jak

----- Original Message ----- 
From: "Gregory Daley" <[email-masked]>
To: "Pekka Nikander" <[email-masked]>
Cc: "James Kempf" <[email-masked]>;
<[email-masked]>; "Mohan Parthasarathy"
<[email-masked]>; <[email-masked]>; "Jari Arkko"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, January 21, 2004 4:17 AM
Subject: Re: moving on with issue 47 (routing vs. advertisement rights)

---

From: Greg Daley <[email-masked]>
Date: Thu, 22 Jan 2004 11:08:48 +1100

Hi James,

> I think we are otherwise in agreement on basic technical points.

How about the following text?

The above check SHOULD be done for all certificates in the chain. If any 
of the checks fail, the client MUST NOT accept the certificate. The 
client also needs to perform validation of advertised prefixes as 
discussed in Advertised Prefixes.

+ Care should be taken if the certificates used in SEND are
+ re-used to provide routing authorization in other circumstances
+ (for example with dynamic routing protocols).  It is currently
+ unclear if the presence of a (0/0) addressPrefix element which is
+ not a subset of the CA's authorized prefixes would cause
+ verification or routing problems with other protocols.
+
Since it is possible that some PKC certificates used with SEND do not 
immediately contain the X.509 IP address extension element, an 
implementation MAY contain facilities that allow the prefix and range

---
I'm not sure how s-bgp handles things for iBGP, and the papers seem to
concentrate on path verification for eBGP...

Greg.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 21 Jan 2004 17:02:11 -0800

> + verification or routing problems with other protocols.

I'd suggest:

    Care should be taken if the certificates used in SEND are re-used
    to provide routing authorization in other circumstances
    (for example with routing gateway protocols), since it is
    currently unclear if the presense of a (0/0) addressPrefix element
    which is not a subset of the CA's authorized prefixes would
    cause verification or routing problems with other protocols.
    Consequently, it is recommended that SEND certificates 
    containing a (0/0) prefix SHOULD only be used for SEND.

> concentrate on path verification for eBGP...

OK.

            jak

---

From: Greg Daley <[email-masked]>
Date: Thu, 22 Jan 2004 13:55:29 +1100

Hi James,

>     containing a (0/0) prefix SHOULD only be used for SEND.

That's better, thanks.

Greg

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 22 Jan 2004 09:48:34 +0200

>     containing a (0/0) prefix SHOULD only be used for SEND.

Looks good.

Minor textual modifications:

     Care should be taken if the certificates used in SEND are re-used
     to provide routing authorization in other circumstances
     (for example with routing gateway protocols), since it is
     currently unclear if the presense of a (0/0) addressPrefix element,
     which is not a subset of the CA's authorized prefixes, would
     cause verification or routing problems with other protocols.
     Consequently, it is RECOMMENDED that SEND certificates
     containing a (0/0) prefix are only used for SEND.

--Pekka

---

From: "James Kempf" <[email-masked]>
Date: Thu, 22 Jan 2004 08:56:20 -0800

>      containing a (0/0) prefix are only used for SEND.

Well, according to RFC 2119 SHOULD and RECOMMENDED essentially mean the same
thing as far as normative language goes:

    3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
       may exist valid reasons in particular circumstances to ignore a
       particular item, but the full implications must be understood and
       carefully weighed before choosing a different course.

so I'm fine with that.

If there are no other issues, then I'd suggest that Jari put this text into
a 03 draft along with a few editorial changes we've been accumulating. We
can start WG Last Call as soon as he's got the draft complete and available.

            jak

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Jan 2004 09:39:09 +0200

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

---

From: Pekka Nikander <[email-masked]>
Date: Fri, 23 Jan 2004 09:50:21 +0200

> certificates containing the null prefix are only used for SEND.

Ok to me.

--Pekka

---

From: "James Kempf" <[email-masked]>
Date: Fri, 23 Jan 2004 08:33:37 -0800

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)