Re: [Mip6] AD review of draft-ietf-mip6-bootstrapping-split

["James Kempf" <[e-mail]>]

>>> >    Mobile IPv6 bootstrapping recommends the Home Agent to update the
>>> >    Mobile Node's FQDN with a dynamically assigned home address rather
>>> >    than have the Mobile Node itself do it (see Section 6 above). This
>>> >    choice was motivated by a concern for preventing redirection-based
>>> >    flooding attacks (see draft-ietf-mip6-ro-sec [21] for more
>>> >    information about redirection-based flooding attacks and the role
>>> >    preventing them played in the design of Mobile IPv6 route
>>> >    optimization security). Exactly as for route optimization, it is
>>> >    possible for a node that is the legitimate owner of a DNS FQDN -
>>> >    in the sense that it has a security association with the DNS
>>> >    server allowing it to perform dynamic DNS update of its FQDN - to
>>> >    bind its FQDN to the address of a victim, then redirect large
>>> >    volumes of traffic at the victim. The attack may be propagated
>>> >    without the owner's knowledge, for example, if the node is
>>> >    compromised by malware, or it may be intentional if the node
>>> >    itself is the attacker.
>>> >
>>> >    While it is possible to prevent redirection attacks through
>>> >    ingress filtering on access routers, ISPs have little or no
>>> >    incentive to deploy ingress filtering. In some cases, if an attack
>>> >    could result in substantial financial gain, it is even possible
>>> >    that a corrupt ISP may have an incentive not to deploy ingress
>>> >    filters such as has been the case for spam. Consequently, the
>>> >    security for dynamic Mobile Node FQDN update has been assigned to
>>> >    the Home Agent, where active network administration and vigilant
>>> >    defense measures are more likely to (but are not assured of)
>>> >    mitigating problems, and the owner of the Mobile Node is more
>>> >    likely to detect a problem if it occurs.
>>> There are good reasons why using a proxy to do the
>>> DynDNS update from your behalf makes sense. But I
>>> don't think the above is such a good reason.  The
>>> route optimization redirect problem assumes that
>>> traffic from an ongoing session is suddenly moved
>>> to a new address. If you just change the DNS information,
>>> ongoing sessions are not affected, and all new sessions
>>> go through the usual TCP slow start etc.
>>>
>>> (A good reason why it makes sense to use a proxy
>>> is that then you just need a secret between the
>>> DNS server and the home agent, not between the
>>> DNS server and every mobile node.)
>>>
>>
>> I'm fine with removing that text. However, I would like to hear
>> thoughts from James, since he has been very active in that part of the
>> draft.
>
> Ok.
>

Sure, go ahead and remove it. The point Jari raised about maintaining a 
single SA between the DNS server and the HA rather than multiple ones should 
be sufficient motivation.

>>
>>> >    Notice that if certificates are used in
>>> >    IKEv2, the authorization information about the FQDN for DNS update
>>> >    MUST be present in the certificate provided by the Mobile Node.
>>> Yes -- but can you write this in more explicit
>>> form? For instance, I assume that you meant
>>> the FQDN must appear in some specific field
>>> in the certificate.
>>>
>>
>> Yes, this is certainly one option. Again I would leave to James the
>> proposed text on this.
>>
>
> Ok. James?
>

It is a little tough to be more precise about this since the IKEv2 spec 
defines no less that 12 different certificate formats that may be used, and 
ultimately concludes that the exact certificate encoding is out of scope of 
the spec. In RFC 4718, Paul and Pasi recommend restricting use to only four 
types to facilitate interoperability. One of the recommended types in both 
documents is "X.509 Certificate - Signature". We could put more text in as 
follows:

       Since the IKEv2 specification [ref] does not include a required 
certificate
       type, it is not possible to specify precisely how the Moible Node's 
FQDN
       should appear in the certificate. However, as an example, if the 
certificate
       type is "X.509 Certificate - Signature" (one of the recommended 
types)
       then the FQDN may appear in the subjectAltName attribute
      extension [ref2].

[ref2] Housley, R., Polk, W., Ford, W., and Solo, D., "Internet X.509 Public 
Key Infrastructure Certificate and Certificate Revocation List (CRL) 
Profile", RFC 3280, April, 2002.

How does that sound?

                    jak





_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6