Re: [mpls] AD review of draft-ietf-mpls-ldp-hello-crypto-auth

[Loa Andersson <[e-mail]>]

Adrian,

Sorry if I don't have the history right, but it is not really the that
is my problem.

It is the tension between

 > There is a risk with the Hello and it needs a solution.
 > No issue with that, and I support this draft.

and

 > why a bad actor within the network would waste its time attacking LDP
 > when there is so much else it can do!

The first seems says that there is a risk that needs to be taken care
of, the second seems to say that this is moot.

/Loa


On 2014-04-17 15:09, Adrian Farrel wrote:
> Hello,
>
> I don't think that is the history at all!
> This document started as draft-zheng-mpls-ldp-hello-crypto-auth in October 2010.
> Before that the issue with the Hello was discussed and batted around for a
> while.
> There is a risk with the Hello and it needs a solution.
> No issue with that, and I support this draft.
>
> RFC 6952 comes from draft-ietf-karp-routing-tcp-analysis-00.txt that was adopted
> by KARP in June 2011. That derives from draft-mahesh-bgp-ldp-msdp-analysis first
> posted in February 2011 (note that the discussion of LDP Hellos didn't make it
> into this document until -01 in May 2011).
>
> But who cares?
>
> RFC 6952 does not describe the attacks or their mitigations. It just notes that
> spoofing a Hello can have some bad effects.
>
> As a deployer, I need help to explain when I need to insist on having this
> feature implemented by my supplier (BTW, it looks like none of the suppliers is
> implementing it) and when I need to enable it. It seems to me that this feature
> is needed to protect against attacks (which 6952 claims have been seen in the
> wild), but that those attacks only arise in specific situations.
>
> Since the security mechanisms defined in this document are pretty heavy-weight
> (compare with simple text passwords so loved for IGP security :-) it would be
> great to get some help on this topic. Are all networks always exposed (if so it
> looks like a must-have feature)? Are the risks only significant for targeted
> LDP? Is the network safe if it applies access controls at the edges and assumes
> no subversion of routers? Does applying an access list at the LDP speakers
> provide protection against everything except address spoofing?
>
> Cheers,
> Adrian
>
>> -----Original Message-----
>> From: Loa Andersson [mailto:[e-mail]]
>> Sent: 17 April 2014 12:13
>> To: [e-mail];
> [e-mail]
>> Cc: [e-mail]
>> Subject: Re: AD review of draft-ietf-mpls-ldp-hello-crypto-auth
>>
>> Adrian,
>>
>> Given my limited understanding of the security mechanisms, I
>> nevertheless have one question I need to ask.
>>
>> You say:
>>
>> On 2014-04-13 20:10, Adrian Farrel wrote:
>>> It would help if the document was a
>>> little clearer about which attacks it is defending against and why normal
>>> protection at the edge of the network is not considered enough for the
> former,
>>> and why a bad actor within the network would waste its time attacking LDP
>> when
>>> there is so much else it can do!
>>
>> My understanding is that this document was written as a response to the
>> risk analysis in RFC 6952. If I remember correctly you had a number of
>> questions, but also said that you had no objections after having these
>> question answered.
>>
>> Since RFC 6952 says we have a security hole that we need to close, you
>> said that you approve of that, we tried to fill the hole; how should I
>> understand the comment above? Do you just want another reference to
>> RFC 6952?
>>
>> /Loa
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]