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

From: <[email-masked]>
Date: Wed, 14 Jan 2004 13:12:29 +0200

I have reviewed this thread again, and I have made a few
conclusions:

  o  It seems that we agree about Greg's scenario where a router may
     get a single certificate that covers more one of its interfaces.
     This is important for practical purposes. It implies that the set
     of prefixes in the RA may be a subset of the prefixes in the
     cert.

  o  There is a related non-SEND issue: an ingress filtering and default
     router problem exists even if you do not consider SEND at all.
     This has to do with the relationship of ingress filtering and
     default router selection. If put my cable and DSL boxes on the
     same network at home, hosts will route my packets more or less
     randomly through both routers -- but since the ISPs employ
     ingress filtering, packets with a source prefix from the other
     ISP will be dropped. Therefore, hosts should send packets with a
     prefix P preferrably through routers that are somehow known to
     recognize the prefix P.

     Router selection draft does not appear to help here, because
     it only deals with destination prefixes, not source prefixes.
     I am not aware of any other IPv6 feature which would help
     either.

     In the long run, this means that IPv6/multi6/send/someone has
     to solve this, probably even for the case that SEND is not
     used.

  o  The key question is whether the default router selection should
     be modified in SEND or not?

     Draft 01 does not modify this behaviour. It simply says that
     if the advertised and certified prefixes don't match, another
     default router should be used. This still leaves the possibility
     that the routers ingress filter aggressively according to their
     own advertised prefixes, and packets sent with other prefixes
     from the link are dropped. But as Greg pointed out, the SEND
     certs ensure that advertisements are right, and if you see an
     advertisement from the router then you are sure that it will
     not ingress filter those prefixes.

     If we stick with this, it implies that SEND solves the problem
     only partially, i.e., we ensure that the advertisements and
     other options are authenticated and authorized. But we do not
     modify the default router selection, that would have to be done
     by someone else.

     I think that would be appropriate, particularly when such
     modification outside SEND could be used without SEND.

If this looks reasonable, then the following modifications in
the draft are needed:

   If the network operator wants to constrain which routers support
   particular prefixes, routers SHOULD be configured with certificates
   having prefixes listed in the prefix extension.  Routers so
   configured MUST advertise exactly the prefixes for which they are
   certified.

=>

   If the network operator wants to constrain which routers support
   particular prefixes, routers SHOULD be configured with certificates
   having prefixes listed in the prefix extension.  Routers so
   configured MUST advertise the prefixes for which they are
   certified, or a subset thereof.

See also the diffs at:

  http://www.arkko.com/publications/send/issues/issue47diff.html

I have a -02 strawman available at:

  http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt

In addition, we need to work in ipv6/multi6/somewhere on the
ingress filtering problem.

Comments?

--------------------------------------------------------------------
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, 14 Jan 2004 08:18:36 -0800

Jari,

I agree with the change.

Wrt. getting further work on the ingress filtering issue, when I do the
document writeup for the INT area ADs I will mention that the WG considered
this problem and decided it was out of scope for SEND, but believe it should
be addressed in another WG and not simply dropped.

            jak

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, January 14, 2004 3:12 AM
Subject: moving on with issue 47 (routing vs. advertisement rights)

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 14 Jan 2004 10:34:59 -0800

Jari,

I looked at the latest version you posted below. A couple of
questions..

In section 6.1.1,

   The X.509 IP address extension MUST contain at least one
   addressesOrRanges element.  This element MUST contain an
   addressPrefix element with an IPv6 address prefix for a prefix the
   router or the intermediate entity is authorized to advertise.  If
the
   entity is allowed to route any prefix, the used IPv6 address prefix
   is the null prefix, 0/0.

-  The first part says nothing about routing for the prefix. It says
".. authorized to
    advertise". If we don't want to use it for routing at all, then
can we be explicit ?
    Or i am confused with the resolution here, as the next line talks
about routing
    for the prefix also. In any case, it should be explicitly stated
here.

-  If the IPv6 address prefix is the null prefix, then you can't
validate the prefix like
    other prefixes, right ? If we can't, we should mention this
explicitly.

In section 7.3,

certified,
   or a subset thereof.

The use of the word "support" is confusing in the first line. Did you
mean "support routing .." ?

   Network operators that do not want to constrain particular routers
to
   specific prefixes SHOULD configure routers with certificates
   containing either the null prefix or no prefix extension at all.

Did you mean "routers to route specific prefixes" ?

thanks
mohan

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Jan 2004 00:18:41 +0200

Mohan,

>    router or the intermediate entity is authorized to advertise. If the
>     advertise". If we don't want to use it for routing at all, then can we be explicit ?
>     Or i am confused with the resolution here, as the next line talks about routing
>     for the prefix also. In any case, it should be explicitly stated here.

I agree that this needs to fixed. I forgot this part.

> -  If the IPv6 address prefix is the null prefix, then you can't validate the prefix like
>     other prefixes, right ? If we can't, we should mention this explicitly.

I'm not sure I understand this. It seems like we need to
define the null prefix to be 0/0 so that any further delegation
would work correctly, in case prefixes are used there and we need
to ensure that delegated prefixes are subsets of the original
prefixes.

Note: Null prefix != empty set. Null prefix is more like the set of all
possible prefixes.

>    configured MUST advertise the prefixes for which they are certified,
>    or a subset thereof.
> 
>    Network operators that do not want to constrain particular routers to

I agree that these parts are confusing as well.

I guess our earlier discussion with James about the routing vs.
advertisement rights started from the fact that it was unclear
whether the certs give routing or advertisement rights. James
then argued that (a) PKIX drafts talk about routing rights and
that (b) there's no real difference between routing and advertisement
rights. Actually, I think advertisement rights must be a subset
of routing rights (even if the advertising router does not offer
itself as a default router).

In the new agreement that we had, the ingress filtering problem
is shifted to someone else. This implies that we have no use for
the specific routing rights check. However, we still have a use
for the advertisement rights check, which per above are a subset
of the routing rights. In conclusion, I think the text should say
the certs carry routing rights, and that advertisements must fall
within the routing rights.

Here's the modified draft:
   http://www.arkko.com/publications/send/issues/issue47diff.html
   http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt

--Jari

---

From: "James Kempf" <[email-masked]>
Date: Wed, 14 Jan 2004 14:31:40 -0800

Jari,

I agree with your proposal for specifying that advertising rights are a
subset of routing rights.

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: "Mohan Parthasarathy" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Wednesday, January 14, 2004 2:18 PM
Subject: Re: moving on with issue 47 (routing vs. advertisement rights)

about routing
here.
validate the prefix like
explicitly.

---

From: Greg Daley <[email-masked]>
Date: Thu, 15 Jan 2004 12:39:21 +1100

Hi Jari,

> Note: Null prefix != empty set. Null prefix is more like the set of all

At a first glance this seems OK to me.
(Explicitly indicating this seems like the way to go)

We'll need to check with the PKIX and SxBGP people
to ensure that we understand the existing semantics
for using the 0/0 prefix in a certificate when the
AFI is 0x0002 (IPv6) and there is no SAFI.

These certificates as defined at the moment apply
to all IPv6 routing (No SAFI), and so the presence
of a default route authorization in a certificate
for SEND could mean something else in BGP.

Otherwise, we will need to define a new SAFI for
last hop routing which will partition the
effect of these changes to only apply to SEND
(at the cost of requiring another IPAddressFamily).

There is a block of SAFIs (up to 64) which is allocated
as FCFS, if this helps.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 Jan 2004 08:12:49 -0800

Greg,

> AFI is 0x0002 (IPv6) and there is no SAFI.

I will put them on the review list for the draft.

> for SEND could mean something else in BGP.

I don't believe networks typically do RFC 2461 Router Advertisement directly
on the Internet, thus the certs applying to interfaces on which 2461
advertising is done would typically be different from the certs used for
SxBGP. They both use the same extension format and I would expect that they
would both use the same cert chain, however. But perhaps I am missing
something.

> There is a block of SAFIs (up to 64) which is allocated

I'm not sure I understand, could you explain more?

            jak

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 15 Jan 2004 10:24:06 -0800

> Note: Null prefix != empty set. Null prefix is more like the set of all
I was trying to apply the example given in section 6.1.1. What would the certificate
issued by isp_group.com have if i see a null prefix in the isp_foo.com's certificate ?
Your example shows how one should do the IP address check in the certificate
chain. Does it directly apply to null prefix ?

> itself as a default router).
I agree with this.

>    http://www.arkko.com/publications/send/drafts/draft-send-ndopt.txt
Sounds okay now.

-mohan

---

From: Greg Daley <[email-masked]>
Date: Fri, 16 Jan 2004 09:42:01 +1100

Hi James,

> would both use the same cert chain, however. But perhaps I am missing

I think the issue is not that RA messaging will
be be on the Internet, although I'd guess that
the ability to route a prefix (being delegated
to a particular public key) would only be signed
once by a CA.

Even if multiple certificates are applied to
a router, I'd guess that these would be for different
security domains/interfaces, so no (explicit) overlap
in authorized prefixes authority would exist in any pair
of a router's certificates (except when changing to new
certs).

The Advertisement of this prefix (say with BGP)
into the routing cloud could therefore use the
same certificate as SEND uses to verify
authorization over routing from/to that prefix.

Since the proposal is to use the Address Family
(IPv6) with no sub-address family, including the
0/0 prefix may indicate that the router is
allowed to advertise default routes into the
routing cloud.

> I'm not sure I understand, could you explain more?

RFC 2858 (Multiprotocol extensions for BGP)
defines the AFI/SAFI notation, and how it's
interpreted in BGP.

This document has an IANA considerations section
which allows allocation of SAFIs 64-127 as
first come first served through the IANA.
That is, if we need one, there's no need for IETF
approval.

Alternatively, SAFI can be assigned with IETF Consensus,
when SEND is published.  If the BGP people say
it's necessary, I'd guess that it wouldn't be a problem.

Details can be found at:

http://www.iana.org/assignments/safi-namespace

Greg

---

From: "James Kempf" <[email-masked]>
Date: Fri, 16 Jan 2004 13:53:10 -0800

Greg,

> allowed to advertise default routes into the

I think I understand your point now. If the border routers are configured
with certificates for a particular address range, then the access routers
should, logically, always be configured with certificates for a subset of
the address range advertised by the border routers, not 0/0. Right?

The assumption behind the 0/0 prefix extension is that the certificates in
the access routers won't be used for BGP, that is, that the access routers
are not participating in BGP, though that might not be a valid assumption if
the access routers are termination points of an iBGP session.

The primary issue here is that we would like the SEND certificates to be
easily deployable without having to deploy sBGP certs, and we would like
some indication that the router is allowed to route any prefix if sBGP is
not deployed. If sBGP is deployed, then the SEND certificates should
naturally reflect a subset of the prefixes the domain is allowed to route
(which could be exactly the same as in the certificates on the border
routers, if the access router is allowed to route anything).

How about this:

- if certificates are being used on border routers, then the SEND certs MUST
contain an IP Address Delegation extension, and the advertised prefixes MUST
be a subset of those advertised for the domain.

- if certificates are not being used on border routers, then the SEND certs
MAY omit the IP Address Delegation extension if the router is allowed to
route any prefix.

This would eliminate the confustion about 0/0 being a default route.

I think we can word this such that we don't have any normative dependence on
a particular secure BGP proposal.

> http://www.iana.org/assignments/safi-namespace

I don't think we need a new SAFI. The forwarding being indicated by the SAFI
are exactly the same as those for the BGP certs.

            jak

---

From: Greg Daley <[email-masked]>
Date: Mon, 19 Jan 2004 12:22:41 +1100

Hi James,

> the access routers are termination points of an iBGP session.

indeed :)

> a particular secure BGP proposal.

This sounds good to me.

So long as the trust chain goes back to an authority
we trust to make these decisions, it may be OK.

> are exactly the same as those for the BGP certs.

That's my belief too, so I'm glad if we're able
to use the same certs.

Greg

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 19 Jan 2004 12:16:45 +0200

James,

> MAY omit the IP Address Delegation extension if the router is allowed 

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.

One of the biggest problems with many of the current (and especially
those build already some time ago) certificate approaches are
too lax semantics.  That is, it should be immediately clear from
a certificate what it is good for.  If a certificate does not contain
an IP Address Delegation extension, some other type of certificate
could be used for SEND.  That may be bad.

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.

> are exactly the same as those for the BGP certs.

Agreed.

--Pekka

---

From: "James Kempf" <[email-masked]>
Date: Tue, 20 Jan 2004 14:14:09 -0800

> 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. 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.

Greg, what do you think?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 20 Jan 2004 14:25:30 -0800

----- Original Message ----- 
From: "James Kempf" <[email-masked]>
To: "Pekka Nikander" <[email-masked]>
Cc: <[email-masked]>; "Mohan Parthasarathy"
<[email-masked]>; <[email-masked]>; "Jari Arkko"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, January 20, 2004 2:14 PM
Subject: Re: moving on with issue 47 (routing vs. advertisement rights)

> would typically be ok for a border router) but it will not propagate
outside

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.

            jak

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 21 Jan 2004 09:43:52 +0200

>> 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.

>> 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.
>

I didn't understand this part.

--Pekka