Re: [CGA-EXT] [draft-ietf-csi-send-cert-01] Review

Roque Gagliano <roque@lacnic.net> Wed, 09 December 2009 11:22 UTC

Return-Path: <roque@lacnic.net>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31FF43A689E for <cga-ext@core3.amsl.com>; Wed, 9 Dec 2009 03:22:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.048
X-Spam-Level:
X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7B7DI4PMG-y for <cga-ext@core3.amsl.com>; Wed, 9 Dec 2009 03:22:09 -0800 (PST)
Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id 90C073A6986 for <cga-ext@ietf.org>; Wed, 9 Dec 2009 03:22:08 -0800 (PST)
Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.78]) by mail.lacnic.net.uy (Postfix) with ESMTP id A2280308499; Wed, 9 Dec 2009 09:21:53 -0200 (UYST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Roque Gagliano <roque@lacnic.net>
In-Reply-To: <729b68be0912080842p282dec29o85a0fb1a97ebfddb@mail.gmail.com>
Date: Wed, 09 Dec 2009 12:21:47 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <71E21E5B-02FE-4A26-8503-01605E9373D9@lacnic.net>
References: <729b68be0912080842p282dec29o85a0fb1a97ebfddb@mail.gmail.com>
To: Jean-Michel Combes <jeanmichel.combes@gmail.com>
X-Mailer: Apple Mail (2.1077)
X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information
X-LACNIC.uy-MailScanner: Found to be clean
X-LACNIC.uy-MailScanner-SpamCheck:
X-LACNIC.uy-MailScanner-From: roque@lacnic.net
Cc: cga-ext@ietf.org
Subject: Re: [CGA-EXT] [draft-ietf-csi-send-cert-01] Review
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2009 11:22:10 -0000

Jean Michel,

Thank you very much for your review. We need to update the draft after the comments received in Hiroshima and will include your suggestions.

Some comments inline.

Roque

On Dec 8, 2009, at 5:42 PM, Jean-Michel Combes wrote:

> Hi,
> 
> here are some comments/questions regarding the draft:
> 
> o Section 4, p7
> Typo:
> s/(i.e. and end user could deploy SEND without the need of RPKI
> deployment in its ISP)/(i.e. an end user could deploy SEND without the
> need of RPKI deployment in its ISP)
> 
Good.

> "This model MAY include ULA addresses."
> I would add a reference to the RFC 4193.
> 
Good.

> o Section 5.1, p8
> IMHO, it should be clearer:
> s/"This certificate will be obtained from the publication point of
> certificate defined as trust anchor."/"This certificate will be
> obtained from the publication point of the trust anchor certificate."
> BTW, as you used "EE" term at the beginning of the section, why not to
> use the rest of the terminology specified in [draft-ietf-sidr-ta-02]
> (i.e. ETA, RTA)?
> 
Good, I will. This section is the one that I was planning to revisit.

> "The identification for the Trust Anchor Material will be included in
> the Name Type Field of the ICMP Trust Anchor Option as decribed in RFC
> 3971 and MUST always to refer to a certificate that includes as RFC
> 3779 address extension."
> s/as decribed in RFC 3971/as described in RFC 3971

Good.

> What do you mean by "MUST always to refer to a certificate that
> includes as RFC 3779 address extension."?
> Because, as far as I understood the RPKI structure
> [draft-ietf-sidr-ta-02], normally, the device validating the router's
> EE cert has only an ETA cert which doesn't contain a RFC 3779 Address
> Extension (this last one refers to a RTA which contains a RFC 3779
> Address Extension). Am I correct?

Here is the thing. When you use a non RFC3779 Cert as a trust anchor, there is no IP resources in your TA certificate (the ETA). Someone needs to fetch the RTA cert (the one that has IP resources). 

We have two options, either the host does it or the router does it.

I believe that making the router to do it is problematic because the router is always expecting a TA that has IP resources and there is no way to reach the ETA from the RTA as the RTA is self-signed. So, my proposal is that in the SEND TA option the certificate that is referred always has to have IP resources in it and the host needs to make sure it can fetch it.

Regards,

Roque.

> 
> Thanks in advance for your reply.
> 
> Best regards.
> 
> JMC.
> _______________________________________________
> CGA-EXT mailing list
> CGA-EXT@ietf.org
> https://www.ietf.org/mailman/listinfo/cga-ext

-------------------------------------------------------------
Roque Gagliano
LACNIC
roque@lacnic.net
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE