Subject: Re: review of draft-ietf-send-ipsec-01.txt (substantial)

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

Hello Francis and many thanks for your valuable
comments! Please find some responses inline for the
substantive issues, the editorial ones come in the
next e-mail.

I have Cced Pekka as I think he'll have to answer
some of the certificate and security considerations
questions.

>  - same (comment)
> 
>    approach involves the use of IPsec AH [3] to secure all
> 
>   => don't forget than the IPsec WG still wants to phase out AH,
>      that was voted at a previous IETF meeting. So I suggest you
>      ask the IESG to *not* make AH historic in a close future.
>      IMHO IPsec guys should be happy as soon as AH in no more
>      mandatory...

This related to the NDoption vs. AH discussion as well. Lets take
that decision first, then come back to this if necessary.

>  - same (comment)
> 
>       but not both.  A security association is uniquely identified by a
>       triple consisting of a Security Parameter Index (SPI), an IP
>       Destination Address, and a security protocol (AH or ESP)
>       identifier [2].
> 
>   => (note that this is discussed in the document). RFC 2401bis is supposed
>   to use only the SPI. IMHO you have to show this document to Stephen Kent
>   in order to support both 2401 and 2401bis context. ESPv3 draft can give
>   good hints if you don't want to read the whole IPsec mailing list archive.

Yes, there's a looong discussion in saag/ipsec about these things now...

>  - same (comment)
> 
>    o  The Redirect function is used for automatically redirecting hosts
>       to an alternate router.  Redirect is specified in Section 8 of RFC
>       2461 [6].  It is similar to the ICMPv4 Redirect message [19].
> 
>   => this is *not* true: IPv6 redirect has 3 functions:
>    - change the router for a better one (the function you described)
>    - change the link-layer address (target == destination). This should
>      be in general by the peer itself with a NA at the exception of the
>      last case.
>    - give the link-layer address of an off-link destination which is
>      in fact on-link. This "external redirect" is used for IPv6 over
>      ATM to implement NHRP short cuts for instance.

Oops. These new functions may also need some security thinking,
whether they pose some problem to the currently specified Redirect
handling rules in SEND.

>  - 4. Secure Neighbor Discovery Overview (comment)
> 
>       Optionally, an authorization certificate can specify the prefixes
>       for which the router is allowed to act as a router.
> 
>   => I don't understand at all this statement: prefix discovery
>   is not bound to the default router function... I believe that
>   you mean "is allowed to advertise"??

Yes, this was commented by some others as well. Its really about
whether the router is allowed to advertise the prefixes, as
you suggest.

>  - same (comment/request for improvement)
> 
>    o  Cryptographically Generated Addresses are used to assure that the
>       sender of a Neighbor or Router Advertisement is the owner of an
>       the claimed address.  A public-private key pair needs to be
>       generated by all nodes before they can claim an address.
> 
>   => this suggests that all addresses should be CGAs. Of course this
>   is only one of the two cases:
>    - certified addresses (always the case for universal or static IID)
>    - CGAs (which always give local IID)

Right. Should be fixed.

>  - same (comment)
> 
>    o  A new transform for IPsec AH allows public keys to be used on a
>       security association directly without the involvement of a key...
> 
>   => I propose to talk about inline signature, look at SKIP documents.

Assuming we use AH, I'll do that.

>  - same (comment)
> 
>    The Authorization Delegation Discovery process does not exclude other
>    forms of discovering the certificate chains.  For instance, during
> 
>   => IMHO this is the right place to introduce interaction with AAA systems.
>   If you'd like to use SEND in 802.11 hot spots, you have to talk about
>   this!

Do you have a specific suggestion regarding the interaction? Do
you wish to download certs from the AAA, or what?

>  - 6.3 Trusted Root Option (comment)
> 
>   => you don't support two root certificates for the same root...
>   I propose to add a name type where one can put a hash of the
>   certificate. For the hash itself the objectDigest seems perfect.

Sounds good. Pekka?

>   BTW I don't understand why we should not put PKIX certificates?
>   IKEv2 does this, and it can make interoperability between implementations
>   less problematic.

There's a pending discussion about the exact certificate types
used.

>  - 6.5 Router Authorization Certificate Format (comment)
> 
>    MUST consist of standard Public Key Certificates (PKC, in the sense
>    of [11]) for identity from the trusted root shared with the host to
> 
>  => [11] (PKIX) doesn't use this term... IMHO the right reference is [12]
>  and the introduction text of [12] about PKC and AC should be copied!

Sounds right. Pekka?

>  - same (comment)
> 
>    acinfo.attributes
> 
>       This field MUST contain a list of prefixes that the router is
>       authorized to route
> 
>   => I disagree: a router is not authorized to route a prefix, it is
>   authorized to advertise/annonce a prefix. About routing perhaps
>   it should be useful to authorize (or not) a router to be a default
>   router?

Right. This has been covered under issue #5.

>  - same (comment)
> 
>       If the router is authorized only to route specific prefixes, the
>       ipAddress values consist of IPv6 addresses in standard RFC 3513
>       [13] prefix format.
> 
>   => my problem is that ipAddress can't encode prefix in RFC 3513 format
>   (i.e., ipAddress can get a mask but not <address>/<prefix_len>).
>   Please clarify, for instance with an example. RFC 3280 one is:
>     For example, a name
>     constraint for "class C" subnet 10.9.8.0 is represented as the octets
>     0A 09 08 00 FF FF FF 00, representing the CIDR notation
>     10.9.8.0/255.255.255.0.

Ok.

>  - 6.6  Processing Rules for Routers (comment)
> 
>    their trusted root.  When such advertisements are sent, their timing
>    MUST follow the rules given for Router Advertisements in RFC 2461
>    [6].  The only defined option that may appear is the Certificate
>    option.  At least one such option MUST be present.  Router SHOULD
>    also include at least one Trusted Root option to indicate the trusted
>    root on which the Certificate is based.
> 
>   => the wording is too loose about what to do if the chain doesn't fit
>   inside one advertisement message:
>    - fragment DCA in place of distributing certs in DCAs (of course
>      the second is better)
>    - back to back DCAs for long chains
>    etc.

I think the text is clear that the chain is sent in separate DCAs. However,
there could still be an overflow from the link MTU for one cert, and for
that we use fragmentation. Does this work for you?

>  - 6.7  Processing Rules for Hosts (comment)
> 
>    o  IP Source Address is a unicast address.  Note that routers may use
>       multiple addresses, so this address not sufficient for the unique
>       identification of routers.
> 
>   => RA sources are always link-local for this reason. Should we enforce
>   routers to use only link-local source for DCAs?

Yes, thanks for noting this.

>  - 7.1.4 Replay Protection (comments)
> 
>    The format is 64
>    bits, and the contents are the number of milliseconds since January
>    1, 1970 00:00 UTC.
> 
>   => the millisecond unit is too small for data but not for ND. Perhaps
>   we should add a rationale saying it is not a problem to have no support
>   for more than one ND message per ms.

Noted by others, too. Issue #6.

>    If anti-replay has been enabled, receivers MUST be configured with an
>    allowed Delta value and maintain a cache of messages received within
>    this time period from each specific source address.
> 
>   => is it really important to support not-in-order messages? Reordering
>   link-layers are not so frequent, and we talk about ND...

I don't know. Seems like for solicited case nonces take care of all
this, and for unsolicited case.... if I receiver reordered adverts, I'm
not sure I care. But wait: what if a RA is split due to MTU and large
content, we wouldn't want to drop the reordered "fragment" of the RA.

>       Recommended default value for the allowed Delta is 3,600 seconds.
> 
>   => this is far too large, especially for a single mechanism.

Can you justify this? Too much memory, or what? We were thinking that
most machines that are at all in the right time, are within this Delta...

>    o  A packet that passes both of the above tests MUST be registered in
>       the cache for the given source address.
> 
>   => it is too soon to register it in the cache: the packet should pass
>   the AH signature check too.

Yes.

>    o  If the cache becomes full, the receiver SHOULD temporarily reduce
>       the Delta value for that source address so that all messages
>       within that value can still be stored.
> 
>   => this doesn't solve the problem but opens doors to DoS...
> 
>   I propose for not reordering link-layers (the reordering case can be
>   supported with small modifs but this should be clearer):
>    - a per-peer (using the source address of received messages as the index)
>      cache entry with:
>     * last received time stamp (TSlast)
>     * date of reception of last message (RDlast)
> 
>    - when a message is received from a new peer (i.e., a new source),
>      the packet is accepted if the timestamp is in the range:
>      - Max_delta < RDnew - TSnew < + Max_delta
>      An entry is created when the signature check passes.
>      
>    - when a message is received from a known peer, the time stamp (TSnew)
>      is checked against the last valid message:
>       TSlast + (RDnew - RDlast) x (1 - allowed_drift) < TSnew and
>       TSnew < TSlast + (RDnew - RDlast) x (1 + allowed_drif)
> 
>   - parameters are max_Delta and allowed_drift (10% ?)
> 
>   For reordering link-layer (i.e., complete rules) we need:
>    - max_link_layer_delay in the last rules
>    - retain only the valid message with the higher timestamp.

This sounds pretty good. What do others think?

>  - 7.1.6 Processing Rules for Receivers (comment)
> 
>    Packets that do not pass all the above tests MUST be silently
>    discarded.
> 
>   => this is the place where to update the timestamp cache. Note that
>   "silently discarded" should imply "doesn't update the cache"...

Ok.

>   - 8.1.1 Sending Secure Neighbor Solicitations (comment)
> 
>    The source address of the message MUST NOT be the unspecified
>    address.  A Neighbor Solicitation sent as a part of Duplicate Address
>    Detection MUST use as a source address the tentative address for
>    which the Duplicate Address Detection is being run.
> 
>   => NO: NS used in DAD are recognized because they are sent from
>   the unspecified source. You are specifying a new DAD protocol...

I agree, but what else can we do if AH needs to use the source
address? Of course, draft-arkko-send-ndopt-00.txt does not
have this problem ;-)

>  - same (same)
> 
>    When an interface is
>    initialized, a node MUST join securely-solicited-node multicast
>    address corresponding to each of the IP addresses assigned to the
>    interface.
> 
>   => we need to specify more: what source address for MLD joins for
>   instance...

Yes. Do you have a suggestion?

>  - 8.3 Other Requirements (comment)
> 
>    Hosts that use stateless address autoconfiguration MUST generate a
>    new CGA as specified in Section 4 of [27] for each new
>    autoconfiguration run.
> 
>   => I disagree: nodes should have the choice between using a certified
>   IID or a CGA based IID. My main name-server is a host and I don't
>   want to use CGA for it for many reasons. Of course, I use stateless
>   autoconfig even I've switched from EID64 IID to ::1 IID some months
>   ago.

Sounds reasonable.

>    It is outside the scope of this specification to describe the use of
>    trusted root authorization between hosts with dynamically changing
>    addresses.  Such dynamically changing addresses may be the result of
>    stateful or stateless address autoconfiguration or through the use of
>    RFC 3041 [9].  If the CGA method is not used, hosts would be required
>    to exchange certificate chains that terminate in a certificate
>    authorizing a host to use an IP address having a particular interface
>    identifier.  This specification does not specify the format of such
>    certificates, since there are currently a few cases where such
>    certificates are required by the link layer and it is up to the link
>    layer to provide certification for the interface identifier.  This
>    may be the subject of a future specification.
> 
>   => this is not sound with the MUST of the previous paragraph.
>   And not with all the CGA=yes/no in next sections...

Ok.

>   Please fix this and don't forget that mandatory encumbered technologies
>   like CGA won't pass last calls (so don't make them mandatory).

The intention is to not make them mandatory. By the way,
the Ericsson license for CGA IPRs should not block
the use of this technology...

>  - 10. Co-Existence of SEND and ND (comment)
> 
>   => another solution is to make the legacy ND prefixes off-link.
>   The wording should clarify it is not the case.

My personal preference is the ND option solution where we don't
have to play tricks with the prefixes.

>  - same (comment)
> 
>   => the standard response to a DAD NS probe is a NA, can you
>   explain the change?

This is used to "spoof" a parallel DAD process, making the
other node give up the address.

>  - same (comment)
> 
>       Secure Router and Neighbor Advertisements MUST use a source
>       address that satisfies the security properties outlined in Section
> 
>   => don't forget that RAs are sent from a link-local address.

Yes.

>  - 11. Performance Considerations (comment)
> 
>    Given that the IPv6 header is
>    covered by the AH integrity protection, it is typically not possible
>    to precompute solicited advertisements.
> 
>   => IMHO anti-replay stuff is enough to make precomputation impossible (:-).

Precomputation is still possible, but unfortunately such precomputed
messages can only be used once, at the designated time ;-) We are
moving the computational effort, not reducing it.

>  - 13.1 Threats to the Local Link Not Covered by SEND (comment)
> 
>    To protect against such attacks,
>    link layer security MUST be used.  An example of such for 802 type
>    networks is port-based access control [34].
> 
>   => can you explain how 802.1X or any link-layer security can help here?
>   I claim that you have no way in the layer 2 or 3 themselves to protect
>   the layer 2 - layer 3 address binding! The only thing that SEND gives
>   is the attacker must be a node one trusts.

Hmm.. with CGA it appears to give more. But I'll leave this question
for Pekka to answer.

>  - 13.2.5 Replay Attacks (comment/wording)
> 
>    Since most SEND nodes are likely to use fairly coarse grained
>    timestamps, as explained in Section 7.1.4, this may affect some
>    nodes.
> 
>   => a millisecond is not so coarse grained. IMHO the statement
>   is more about the fairly large one hour delta...

But the delta does not affect replay attacks, only memory usage.

> PS: I can't find how to verify certified addresses, even for routers.
> (this is not in 9.2)

Indeed this is missing!

Thanks again for your comments.

--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: Francis Dupont <[email-masked]>
Date: Thu, 10 Jul 2003 10:20:44 +0200

=> you proposal (download certs from the AAA system as a side effect
of the network access control) is fine.

   I think the text is clear that the chain is sent in separate DCAs.

=> I don't think so: please make clear that there is one cert per DCA.

   >   => this is far too large, especially for a single mechanism.
   
   Can you justify this?

=> I never saw one hour delta without a timezone mismatch. Even with poor
clocks usually the maximum delta is some minutes. BTW if my proposal
is adopted this delta should become the initial delta.

   
=> most implementations use the unspecified address as the source of
the joins for the solicited-node address. But you have the choice for
the securily-solicited node, I suggest to give the issue to the magma
WG as to secure MLD is not a goal here.

Thanks

[email-masked]