Subject: Under IESG review: draft-ietf-pkix-x509-ipaddr-as-extn-03.txt

From: Alex Zinin <[email-masked]>
Date: Mon, 24 Nov 2003 12:05:39 -0800

I asked for a defer on this document to make sure routing folks have a
chance to look at this, as it talks about IP address range and AS#
authorization.

If you have issues, please get back to me within a week.

-- 
Alex
http://www.psg.com/~zinin/

---

From: Alex Zinin <[email-masked]>
Date: Fri, 6 Feb 2004 11:51:58 -0800

Russ, Sue-

 I'm forwarding the replies from Russ and Steve to the comments
 you provided on the draft in subj. Please check.

 Thanks.

-- 
Alex

Subject: My thoughts on the draft-ietf-pkix-x509-ipaddr-as-extn-03 comments
From: Russ Housley <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Date: Mon, 12 Jan 2004 13:06:39 -0500

Alex:

>From: Russ White <[email-masked]>
>
>-- Section 2.1, in the examples of systems that could use such a
>certificate, they could add soBGP as an example.

Absolutely NOT.  As we discussed at the Minneapolis IETF meeting, soBGP is 
not acceptable to many operators..  We do not want to link these documents.

>-- Section 2.1.2 seems like it's unecessary to me. Is there any situation
>where you would want to actually represent a block as a range, rather than
>as a set of individual address spaces, or even a summary covering all of
>them?

The document says why.  It allows "a more concise representation" by 
encoding the range.  It is just a way to make the certificate extension 
smaller.

>-- Sections 2.2.3.1, 2, and 3 don't seem to be of any use--the address
>family is ipv6 or ipv4, which I thought was covered above in the different
>types of addresses which could be encoded. And I can't imagine anyone
>assigning authorization for a SAFI, since that' essentially just a topology
>within an AFI (?).

I do not have enough experience in this area to respond for the authors.

>-- The entire draft assumes IANA will issue these cert's followed by
>subcerts by the RIR's. What if anyone in the chain doesn't want to
>participate? Should the draft provide the option for other forms of
>authorization? In other words, it should be up to the receiver to trust the
>signer has the authorization to sign, rather than up to the draft writers
>to enforce who can and cannot sign a certificate.

I do not think this is a issue in this context.  IANA is the root of the 
network address assignment hierarchy.  The system does not work if IANA and 
the RIRs do not do their job properly.  We gotta trust them.

>From: Susan Hares <[email-masked]>
>
>What I'm not qualified to chat on:
>         "inherit" mechanism in ASN.1.  I'm
>         a little fuzzy on how that all should work.

The inherit mechanism seems straightforward to me.  The document says:

    If the IPAddressChoice CHOICE contains the inherit element, then the
    set of authorized IP addresses for the specified AFI and optional
    SAFI is taken from the issuer's certificate.

>1st - AS - 4 bytes should be assigned now.
>         It would be good to start at this point to
>         use a TLV structure for AS's.

A TLV encoding is used that supports integer values of any size:

    ASId ::= INTEGER

>2nd - RDI's are supported in ISO, but
>         not really used in the BGP deployments.
>         Is this X.509 trying to support the very few
>         IDRP implementations?

I think we want to allow flexibility when it does not add confusion or too 
much complexity.  In this case, I do not see a problem.  Am I missing 
something?

>3rd - Private AS may be repeated many times
>         in practice.  How does this specification deal
>         with private AS?  Something should be set in
>         light of AS confederations.

I do not have enough experience in this area to respond for the authors.

>4th - Appendix C - is a useful description of the ASN.1
>                          encoding.  Could C be extended or
>                         a new mechanism to indicate how the
>                         "inherit" function would be useful.
>
>         [I for one would like to see the mechanisms of
>          inherit in an appendix.]

I do not think that this is much work, but I do not think it will add much 
to the clarity of the document either.

>5th - an ASN.1 expert should review this text to determine
>         If the Choice fields allow "non-specific" (or two
>         different types given the same sequence) of encodings.
>         Choice fields with the inherit may/may not lead to this.

I have personally compiled the ASN.1 module.

>From: Tony Tauber [mailto:[email-masked]]
> > -- Section 2.1.2 seems like it's unecessary to me. Is there any
> > situation where you would want to actually represent a block as a
> > range, rather than as a set of individual address spaces, or even a
> > summary covering all of them?
>
>I've been thinking about that one, too.
>
>First I thought of a prefix as the logical way to represent such a
>thing; however, addresses are actually assigned in ranges.  Prefixes
>are more of a routing idea, right?  A range is what's assigned.  The
>"owner" is then free to advertise whatever prefixes they want within
>that range (or to delegate further).

I think that Tony is suggesting that the document is correct.

> > -- The entire draft assumes IANA will issue these cert's followed by
> > subcerts by the RIR's. What if anyone in the chain doesn't want to
> > participate? Should the draft provide the option for other forms of
> > authorization? In other words, it should be up to the receiver to
> > trust the signer has the authorization to sign, rather than up to
> > the draft writers to enforce who can and cannot sign a certificate.
>
>Agreed.  Perhaps some verbiage  indicating that the main use considered is
>in the public Internet but that these certs could be used in a private
>setting also.

I guess this makes sense.  IANA is the root for the public 
Internet.  Private communities need to pick an appropriate alternative if 
they want to use this tool.

>Last, since 4-byte ASNs are likely in the future, should 4-bytes be
>set aside now?

The syntax already support it as described above,  Some text in the 
document could be changed to make this clear.

Russ

Subject: Re: My thoughts on the draft-ietf-pkix-x509-ipaddr-as-extn-03 comments
From: Stephen Kent <[email-masked]>
To: Russ Housley <[email-masked]>, Alex Zinin <[email-masked]>
Cc: Stephen Kent <[email-masked]>
Date: Mon, 19 Jan 2004 14:27:37 -0500

Alex & Russ,

There were a few unresolved issues that Russ asked us to address re 
your exchange.  here are our responses:

>>-- Sections 2.2.3.1, 2, and 3 don't seem to be of any use--the address
>>family is ipv6 or ipv4, which I thought was covered above in the different
>>types of addresses which could be encoded. And I can't imagine anyone
>>assigning authorization for a SAFI, since that' essentially just a topology
>>within an AFI (?).

IANA maintains a registry for address types.  The certificate extension
uses SAFI to enable the extension to be used with other addresses, 
e.g., E.164.  If folks only use IPv4 and IPv6 addresses, that is ok, 
the other possible values will not appear in certificates and ought 
not cause any confusion.

>>-- The entire draft assumes IANA will issue these cert's followed by
>>subcerts by the RIR's. What if anyone in the chain doesn't want to
>>participate? Should the draft provide the option for other forms of
>>authorization? In other words, it should be up to the receiver to trust the
>>signer has the authorization to sign, rather than up to the draft writers
>>to enforce who can and cannot sign a certificate.
>
>I do not think this is a issue in this context.  IANA is the root of 
>the network address assignment hierarchy.  The system does not work 
>if IANA and the RIRs do not do their job properly.  We gotta trust 
>them.

The primary focus of the RFC is the use of this extension in 
hierarchies, exactly equivalent to the existing hierarchies used for 
address prefix and As number allocation. However, it is possible to 
use the extension in private net contexts if the operators of such 
nets want to take advantage of the mechanism. It would be a local 
matter to configure trust anchors (a technical, PKI term for public 
keys and associated data used in cert path validation) to recognize 
authorities other than IANA, RIRs, and ISPs.  We can modify the text 
to note this:

1.  Introduction

    This document defines two X.509 v3 certificate extensions that allow
    representation of the transfer of the right to use IP addresses and
    autonomous system identifiers from one organization to other
    organizations.  The primary use for these extensions is in the
    public Internet, where IANA is the root that delegates resources
    through the regional Internet registries (RIRs) to Internet service
    providers (ISPs) and to user organizations. However, these extensions and
    the associated processing mechanisms can be employed in private networks,
    under the auspices of a private PKI representing such delegation.

>>2nd - RDI's are supported in ISO, but
>>         not really used in the BGP deployments.
>>         Is this X.509 trying to support the very few
>>         IDRP implementations?
>
>I think we want to allow flexibility when it does not add confusion 
>or too much complexity.  In this case, I do not see a problem.  Am I 
>missing something?

there was no intent to support IDRP per se, but rather to provide a general
framework for representing authorization info relative to address and AS number
delegation. Our initial focus was S-BGP, but SEND is also a candidate for this
PKI, and the support for other address types enables broader use, as 
noted above. So, unless the RDI provision

>
>>3rd - Private AS may be repeated many times
>>         in practice.  How does this specification deal
>>         with private AS?  Something should be set in
>>         light of AS confederations.
>
>I do not have enough experience in this area to respond for the authors.

So long as private AS's are used only within local contexts, we can 
accommodate their use via this mechanism. As noted above, one can add 
trust anchors, locally, and in this fashion an ISP can represent 
itself as the owner of private AS IDs. if an UPDATE with a private AS 
is sent outside the purview of the ISP that created the private AS, 
then there would have to be co-ordination between ISPs to be able to 
make use of S-BGP in conjunction with these private AS IDs.

>>1st - AS - 4 bytes should be assigned now.
>>         It would be good to start at this point to
>>         use a TLV structure for AS's.
>
>A TLV encoding is used that supports integer values of any size:
>
>    ASId ::= INTEGER

just for added clarity:

3.2.3.10.  Type ASId

    The ASId type is an INTEGER.  Note that ASN.1 INTEGERs can express
both AS identifiers that are unsigned 16-bit quantities or unsigned
32-bit (or larger) quantities without change to the syntax.

Are there are more questions we need to address?

Steve

---

From: Russ White <[email-masked]>
Date: Mon, 9 Feb 2004 07:57:04 -0500 (Eastern Standard Time)

> Absolutely NOT.  As we discussed at the Minneapolis IETF meeting, soBGP
> is not acceptable to many operators..  We do not want to link these
> documents.

<Steve==S-BGP>, so this reply doesn't surprise me at all. Of course,
Listen-Whisper could also be included as an example, but I suppose since
S-BGP is the _only_ acceptable solution for BGP security....

> encoding the range.  It is just a way to make the certificate extension

10.1.0.0/16 is larger than 10.1.0.0 through 10.1.255.255? Since a summary
is a range (the two are precisely the same thing), I consider this a
distinction without a difference.

> network address assignment hierarchy.  The system does not work if IANA
> and the RIRs do not do their job properly.  We gotta trust them.

> they want to use this tool.

The system should work without the RIR's, if it needs to. I don't see any
point in limiting it--who knows if the RIR's will be the root in 10 years
time, and private usage may abound, as Tony has suggested. I don't see the
problem with opening this text up some, even through a parenthetical,
stating that "some top level authority within the context of the
internetwork," must sign these certs.

> A TLV encoding is used that supports integer values of any size:

I don't follow... ? I don't see how this supports 4 byte numbers, and I
don't see any reason why the current TLV couldn't be have the space added
to it, rather than being forced to create a new tlv later (?).

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Feb 2004 15:33:09 -0500

Russ,

>S-BGP is the _only_ acceptable solution for BGP security....

Russ Housely, not I, was the author of this comment.

>distinction without a difference.

The document did not propose encoding a prefix in the character 
string format you noted above, although it described that convention 
as background. Sorry if that caused confusion.  While the prefix 
notation is convenient for people to view and write, it is not so 
attractive for the machine-based comparisons used to determine 
whether one range is a subset of another. So, the proposed format in 
2.1.2 is a sequence that defines the low and high values for the 
range, which is easy to encode and to process, and it is unique, 
which is critical for the DER encoding for certs.  The UI for a CA or 
RA can accept the prefix notation format if that turns out to be a 
better format for a UI.

>internetwork," must sign these certs.

Yes, one could use the extension in a purely private context, but for 
the public Internet it is essential that the CAs be authoritative for 
the extension data not arbitrary, "trusted" entities. BTW, the RIRs 
are not the "roots" but rather 2nd tier CAs in this scheme, under 
IANA.

>to it, rather than being forced to create a new tlv later (?).

I' guessing this comment is a result of confusion about how ASN.1 
encodes integers. By declaring a variable to be an integer in ASN.1, 
the code generated for populating the variable and for reading will 
be able to accommodate a range of integer sizes. Thus both 2 and 4 
bytes AS IDs are accommodated automatically, and even bigger ones 
could be represented in the future, via this convention.

Steve

---

From: Russ White <[email-masked]>
Date: Mon, 9 Feb 2004 15:45:13 -0500 (Eastern Standard Time)

> The document did not propose encoding a prefix in the character string
> format you noted above, although it described that convention as
> background. Sorry if that caused confusion.  While the prefix notation is
> convenient for people to view and write, it is not so attractive for the
> machine-based comparisons used to determine whether one range is a subset
> of another.

After thinking about this, it really doesn't matter if both ways of
representing a prefix block are in there--more flexibility is probably
better, in the long run. :-)

> Yes, one could use the extension in a purely private context, but for the
> public Internet it is essential that the CAs be authoritative for the
> extension data not arbitrary, "trusted" entities. BTW, the RIRs are not
> the "roots" but rather 2nd tier CAs in this scheme, under IANA.

Perhaps there should be a parenthetical about private usage?

> I' guessing this comment is a result of confusion about how ASN.1 encodes
> integers. By declaring a variable to be an integer in ASN.1, the code
> generated for populating the variable and for reading will be able to
> accommodate a range of integer sizes. Thus both 2 and 4 bytes AS IDs are
> accommodated automatically, and even bigger ones could be represented in
> the future, via this convention.

Okay, that's fine...

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Tue, 10 Feb 2004 10:33:09 -0500

>better, in the long run. :-)

I don't want to unduly prolong this discussion, but I do want to be 
clear about this issue; the I-D provides exactly only one way to 
represent an individual address block in a certificate extension. The 
ability to provide different ways of specifying prefixes via UIs is 
what I think you are referring to, right?

>Perhaps there should be a parenthetical about private usage?

No problem. we already revised the text to say:

1.  Introduction

    This document defines two X.509 v3 certificate extensions that allow
    representation of the transfer of the right to use IP addresses and
    autonomous system identifiers from one organization to other
    organizations.  The primary use for these extensions is in the
    public Internet, where IANA is the root that delegates resources
    through the regional Internet registries (RIRs) to Internet service
    providers (ISPs) and to user organizations. However, these extensions
    and the associated processing mechanisms can be employed in
    private networks, under the auspices of a private PKI
    representing such delegation.

Steve

---

From: Russ White <[email-masked]>
Date: Tue, 10 Feb 2004 17:16:02 -0500 (Eastern Standard Time)

> I don't want to unduly prolong this discussion, but I do want to be clear
> about this issue; the I-D provides exactly only one way to represent an
> individual address block in a certificate extension. The ability to
> provide different ways of specifying prefixes via UIs is what I think you
> are referring to, right?

Why shouldn't the cert allow the representation of an address range as a
prefix/length pair? In the original concept, were the draft authors
thinking that you would always treat the ip address space as a number
range, and say, for instance: 10.1.0.0 (through) 10.1.255.255? When you say
that addresses are given out in ranges, do you mean they are given out this
way?

Can anyone think of an instance where a registry would give out 10.1.0.0
(through) 10.1.255.1, or some other odd space? If the range is 10.1.0.0
through 10.1.255.0, do you just assume the .255 on the end, since that
seems to be what makes sense?

I think the prefix lengths are a requirement to make sense of the address
space, in normal usage.

:-)

Russ

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Feb 2004 09:07:36 -0500

>that addresses are given out in ranges, do you mean they are given out this

I explained this in my previous response, but let me try again.  The 
prefixes are represented in certs in a fashion that allows for easy 
comparisons for subset relationships. The low-high range 
representation can accommodate any address block, so there is no loss 
of generality when one adopts that representation. There was NEVER 
any intent to represent an address block as a value and a mask length 
in a cert. the text in the I-D merely described that convention as 
background.

>I think the prefix lengths are a requirement to make sense of the address

I don't disagree that value and mask length make for a good UI 
convention, but there is no need to offer that as a separate encoding 
in the certs per se.  having multiple ways to encode the same info 
leads to confusion and greater complexity in the security critical 
code that has to accommodate multiple representations.

Steve