[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ipsec] new ICMP text for 2401bis



Stephen Kent writes:
> >Having picture here would really make things easier understand.
> >Something like:
> >
> >          (1)              (3)        (5)               (7)
> >+------+/     +---------+/              \+---------+      \+------+
> >|Host A|------|SGW A(3a)|=== Internet ===|(5a)SGW B|-------|HOST B|
> >+------+     /+---------+      //        +---------+\      +------+
> >           (2)                 //                     (6)
> >                      (4)     //
> >   +----------------+/       //
> >   |IPsec HOST C(4a)|=======//
> >   +----------------+
>
> we'll see what makes sense in terms of describing what sets of 
> traffic is addressed by each part of section 6. based on your 
> comments below, I'm not quite sure how to interpret (2) and (6) 
> above, so we probably need a diagram plus some notes to clarify this 
> complex issue.

The (2) is the traffic coming from the host A and going to host B
throught the SGW A and B using IPsec tunnel between the SGWs. I.e. it
didn't include traffic destioned to the SGW A.

I agree that was not clear in from the picture, and trying to get that
distinction in to the picture is little hard... Perhaps:


          (1)                (3)      (5)                  (7)
+------+/     +------------+/            \+------------+      \+------+
|Host A|------|(2)SGW A(3a)|===Internet===|(5a)SGW B(6)|-------|HOST B|
+------+     /+------------+      //      +------------+\      +------+
           (9)                   //                      (10)
                        (4)     //
     +----------------+/       //
     |IPsec HOST C(4a)|=======//
     +----------------+

Hmm.. probably not. I think it is simply better to explain that in the
text saying that (2) and (6) only cover the traffic destinoned to the
tunnel, not the traffic destioned to the SGWs themselves. 

> >>  B. The following text will be added to Security Considerations:
> >>
> >>  An IPsec implementation is configured to pass ICMP error packets over
> >>  SAs based on the ICMP header values, without checking the header info
> >>  from the ICMP packet payload.
> >
> >I think that needs some kind of rewording like "An IPsec
> >implementation can be configured ..." or similar.
> 
> I should have said: "if an IPsec implementation is configured to pass ..."

What happens if it is configured that way? It does not tell that
either... Perhaps it should say:

----------------------------------------------------------------------
If an IPsec implementation is configure to pass ICMP error packets
over SAs based on the ICMP header values, without checking the header
infor from the ICMP packet payload, then the attackers can cause DoS
attacks by sending the ICMP packets through the SGW to the other end,
just like they could if the hosts would be on the same network. 
----------------------------------------------------------------------

> >>  For example, a tunnel may be created between two sites that uses ANY
> >>  for protocol and port fields and IP address ranges that encompass
> >>  all systems behind the security gateways serving each site. In such
> >>  cases, the hosts behind the security gateways will be vulnerable to
> >>  DoS attacks that might be launched by other peers with which there
> >>  are active SAs.
> >
> >Perhaps we should describe the situation more here?
> suggestions?

Hmmm.. not really, but remembering the items raised in the IESG to the
UDP encapsulation draft, they always wanted to see the real attacks,
not just text saying there are some attacks.

Perhaps it is just enough to say that the attacker can do all same
attacks with ICMP messages, it could if it would be on the same
network (including faking the header and contained payload IP
addresses). 

> >BTW, what about the old PMTU text? Do we copy the old RFC2401 PMTU/DF
> >processing stuff from there (section 6 and appendix B)?
> Yes, Karen has not yet added back the PMTU text.

After we have this ICMP and that PMTU text done, we should be ready...
I do not know anything else missing...
-- 
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec