Greg Daley: 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. -------------------- James Kempf: > 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. I will put them on the review list for the draft. > 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. 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. > 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. I'm not sure I understand, could you explain more? -------------------- Mohan Partsarathy: > Note: Null prefix != empty set. Null prefix is more like the set of all > possible prefixes. 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 ? >> > In section 7.3, >> > >> > 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. >> > >> > 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" ? > > 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). I agree with this. > 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 Sounds okay now. -------------------- Greg Daley: > 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. 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. >> 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. > > 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 -------------------- James Kempf: > 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 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. > 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. >> >> >> > >> > >> > 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 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. -------------------- Greg Daley: > 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. indeed > 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. 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. >> 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. >>>> >>> >>> >>> 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 >> > > > > 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. That's my belief too, so I'm glad if we're able to use the same certs. -------------------- Pekka Nikander: > - 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. 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. > 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. Agreed. -------------------- James Kempf: 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? -------------------- James Kempf: 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. -------------------- Pekka Nikander: >> 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. > > > 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. -------------------- Greg Daley: > 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. > 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 Daley: 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. -------------------- Greg Daley: 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... ) -------------------- James Kempf: 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. > 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... OK. -------------------- Greg Daley: That's better, thanks. -------------------- Pekka Nikander: 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. -------------------- James Kempf: 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. -------------------- Jari Arkko: 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. -------------------- Pekka Nikander: Ok to me. -------------------- James Kempf: Looks fine to me. Greg, what do you think? -------------------- Greg Daley: Thanks Jari for getting to the deeper meat of the issue. The proposed text is sufficient. -------------------- -------------------- -------------------- --------------------