Subject: Re: DT's review of draft-ietf-send-ipsec-01.txt

From: Jari Arkko <[email-masked]>
Date: Wed, 09 Jul 2003 13:47:42 +0300

Dave,

Sorry for the delay in answering the rest of the issues.
I've been on "vacation" (mostly painting and other household
chores) for a while.

> 1) Section 6 states:
>    > Similarly, the router, which is already connected to the network, can
>    > if necessary communicate off-link and construct the certificate
>    > chain.
> 
>    This should be clarified with "in some cases".  If the router is
>    not connected to the Internet, this may not be possible.

Right.

> 2) Sections 6.1 and 6.2 describe an Identifier field, but does not specify how
>    it is set in a solicitation or in an unsolicited advertisement.  E.g.
>    if it is always set to 1, it doesn't seem very useful.  Likewise, if 
>    each host starts with 1 and increments, it's also less useful 
>    since hosts can collide.  I think it should be randomly generated if 
>    possible.

Ok.

> 3) Sections 6.3 and 6.4 both specify options with a variable-length
>    field followed by padding.  However, they use two different encodings
>    for no good reason.  One specifies the length of the field, and the
>    other specifies the length of the padding.  Instead, both options
>    should be consistent.

Right. Lets change 6.4.

> 4) Section 6.4 says:
>    >  When the Name Type field is set to 1, the Name field contains the
>    >  Fully Qualified Domain Name of the trusted root, for example
>    >  "trustroot.operator.com".
> 
>    More guidance is needed to prevent interoperability problems.
>    Is the string null-terminated (I assume no)?
>    Are internationalized domain names legal?  What is the encoding?
>    (UTF-8?  Unicode? ...)

I see your point. Is there a good example where FQDN usage has
been fully specified?

> 5) Section 6.5 says:
>    > RFC 3281.  If the GeneralName attribute is a dNSName, it MUST be
>    > resolvable to a global unicast address assigned to the router.  If
>    > the GeneralName attribute is an iPAddress, it MUST be a global
>    > unicast address assigned to the router.  For purposes of
> facilitating
> 
>    For people not familiar with X.509, is it easy to explain in 1-2
>    sentences what it is used for?  (That is, why is it a MUST above?) 
>    As is, it sounds suspiciously like a security hole.

I agree that more explanation is required. The intentin of the
IP address is to provide a check against the router's IP address
in the cert.

> 6) Section 6.5.1 says:
>    >  This field MUST contain a list of prefixes that the router is
>    >  authorized to route, or the  unspecified  prefix  if  the  router
> 
>    This wording is particularly problematic.  Routers route packets
>    not prefixes.  They _advertise_ prefixes in RA's and in routing protocols.
>    It's similarly unclear whether the prefix list is what remote
>    prefixes it's allowed to advertise as off-link routes in RA's (e.g.
>    ::/0 if it can be a default router on the link), or whether the prefix
>    list is what local prefixes it's allowed to advertise as on-link routes
>    in RA's.  I'm guessing the latter, but I can think of arguments for
>    restricting both.

Right. It should have said advertise. And yes, it should probably be
the latter case for the advertisements.

> 7) Sections 6.6 and 6.7 appear to contradict each other.
>    6.6 says:
>    > SHOULD send an advertisement without any certificates.  In this case
>    > the router SHOULD include the Trusted Root options which were
>    > solicited.
>    Hence the Trusted Root option is legal in an advertisement.
> 
>    6.7 says:
>    > packet processed in the normal manner.  The only defined option that
>    > may appear is the Certificate option.  An advertisement that passes
>    Hence the Trusted Root option is not legal in an advertisement.

Right. 6.7 should be corrected.

> 8) Section 7.1.2 and reference [27] contradict each other.
>    7.1.2 says:
>    >    CGAParameters ::= SEQUENCE {
>    >      publicKey      SubjectPublicKeyInfo,
>    >      auxParameters  CGAAuxParameters OPTIONAL }
>    whereas [27] now has the opposite order.
>    It would be better to not copy the definition here at all, and just 
>    refer to [27] for the definition.

Ok.

> 9) Section 7.1.3 talks about a minbits parameter.  It doesn't really
>    say how the value should be determined.  Some guidance would be
>    helpful.

Perhaps [27] can help here? Maybe add a reference?

> 10) 7.1.4 says:
>    >  source address.  A packet that has already been seen from the same
>    >  source with the same Timestamp field value MUST be silently
>    >  discard.
> 
>    Since the granularity of the field is in milliseconds, you need to
>    specify that a node must not send two SEND messages during the same
>    millisecond.  However, this restriction may be problematic in some 
>    scenarios.

Hmm... Yes, I agree that this could be problematic. Is a better
granularity needed, say microsecond?

--Jari

--------------------------------------------------------------------
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: "Dave Thaler" <[email-masked]>
Date: Fri, 11 Jul 2003 15:09:31 -0700

> I see your point. Is there a good example where FQDN usage has

I will defer to others on this question.  You might start with
RFC 3491, but I have heard some say there are still ambiguities.

-Dave